㈠ suse linux
Newbie: Intro to cron
Date: 30-Dec-99
Author: cogNiTioN <[email protected]>
Cron
This file is an introction to cron, it covers the basics of what cron does,
and how to use it.
What is cron?
Cron is the name of program that enables unix users to execute commands or
scripts (groups of commands) automatically at a specified time/date. It is
normally used for sys admin commands, like makewhatis, which builds a
search database for the man -k command, or for running a backup script,
but can be used for anything. A common use for it today is connecting to
the internet and downloading your email.
This file will look at Vixie Cron, a version of cron authored by Paul Vixie.
How to start Cron
Cron is a daemon, which means that it only needs to be started once, and will
lay dormant until it is required. A Web server is a daemon, it stays dormant
until it gets asked for a web page. The cron daemon, or crond, stays dormant
until a time specified in one of the config files, or crontabs.
On most Linux distributions crond is automatically installed and entered into
the start up scripts. To find out if it's running do the following:
cog@pingu $ ps aux | grep crond
root 311 0.0 0.7 1284 112 ? S Dec24 0:00 crond
cog 8606 4.0 2.6 1148 388 tty2 S 12:47 0:00 grep crond
The top line shows that crond is running, the bottom line is the search
we just run.
If it's not running then either you killed it since the last time you rebooted,
or it wasn't started.
To start it, just add the line crond to one of your start up scripts. The
process automatically goes into the back ground, so you don't have to force
it with &. Cron will be started next time you reboot. To run it without
rebooting, just type crond as root:
root@pingu # crond
With lots of daemons, (e.g. httpd and syslogd) they need to be restarted
after the config files have been changed so that the program has a chance
to reload them. Vixie Cron will automatically reload the files after they
have been edited with the crontab command. Some cron versions reload the
files every minute, and some require restarting, but Vixie Cron just loads
the files if they have changed.
Using cron
There are a few different ways to use cron (surprise, surprise).
In the /etc directory you will probably find some sub directories called
'cron.hourly', 'cron.daily', 'cron.weekly' and 'cron.monthly'. If you place
a script into one of those directories it will be run either hourly, daily,
weekly or monthly, depending on the name of the directory.
If you want more flexibility than this, you can edit a crontab (the name
for cron's config files). The main config file is normally /etc/crontab.
On a default RedHat install, the crontab will look something like this:
root@pingu # cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
The first part is almost self explanatory; it sets the variables for cron.
SHELL is the 'shell' cron runs under. If unspecified, it will default to
the entry in the /etc/passwd file.
PATH contains the directories which will be in the search path for cron
e.g if you've got a program 'foo' in the directory /usr/cog/bin, it might
be worth adding /usr/cog/bin to the path, as it will stop you having to use
the full path to 'foo' every time you want to call it.
MAILTO is who gets mailed the output of each command. If a command cron is
running has output (e.g. status reports, or errors), cron will email the output
to whoever is specified in this variable. If no one if specified, then the
output will be mailed to the owner of the process that proced the output.
HOME is the home directory that is used for cron. If unspecified, it will
default to the entry in the /etc/passwd file.
Now for the more complicated second part of a crontab file.
An entry in cron is made up of a series of fields, much like the /etc/passwd
file is, but in the crontab they are separated by a space. There are normally
seven fields in one entry. The fields are:
minute hour dom month dow user cmd
minute This controls what minute of the hour the command will run on,
and is between '0' and '59'
hour This controls what hour the command will run on, and is specified in
the 24 hour clock, values must be between 0 and 23 (0 is midnight)
dom This is the Day of Month, that you want the command run on, e.g. to
run a command on the 19th of each month, the dom would be 19.
month This is the month a specified command will run on, it may be specified
numerically (0-12), or as the name of the month (e.g. May)
dow This is the Day of Week that you want a command to be run on, it can
also be numeric (0-7) or as the name of the day (e.g. sun).
user This is the user who runs the command.
cmd This is the command that you want run. This field may contain
multiple words or spaces.
If you don't wish to specify a value for a field, just place a * in the
field.
e.g.
01 * * * * root echo "This command is run at one min past every hour"
17 8 * * * root echo "This command is run daily at 8:17 am"
17 20 * * * root echo "This command is run daily at 8:17 pm"
00 4 * * 0 root echo "This command is run at 4 am every Sunday"
* 4 * * Sun root echo "So is this"
42 4 1 * * root echo "This command is run 4:42 am every 1st of the month"
01 * 19 07 * root echo "This command is run hourly on the 19th of July"
Notes:
Under dow 0 and 7 are both Sunday.
If both the dom and dow are specified, the command will be executed when
either of the events happen.
e.g.
* 12 16 * Mon root cmd
Will run cmd at midday every Monday and every 16th, and will proce the
same result as both of these entries put together would:
* 12 16 * * root cmd
* 12 * * Mon root cmd
Vixie Cron also accepts lists in the fields. Lists can be in the form, 1,2,3
(meaning 1 and 2 and 3) or 1-3 (also meaning 1 and 2 and 3).
e.g.
59 11 * * 1,2,3,4,5 root backup.sh
Will run backup.sh at 11:59 Monday, Tuesday, Wednesday, Thursday and Friday,
as will:
59 11 * * 1-5 root backup.sh
Cron also supports 'step' values.
A value of */2 in the dom field would mean the command runs every two days
and likewise, */5 in the hours field would mean the command runs every
5 hours.
e.g.
* 12 10-16/2 * * root backup.sh
is the same as:
* 12 10,12,14,16 * * root backup.sh
*/15 9-17 * * * root connection.test
Will run connection.test every 15 mins between the hours or 9am and 5pm
Lists can also be combined with each other, or with steps:
* 12 1-15,17,20-25 * * root cmd
Will run cmd every midday between the 1st and the 15th as well as the 20th
and 25th (inclusive) and also on the 17th of every month.
* 12 10-16/2 * * root backup.sh
is the same as:
* 12 10,12,14,16 * * root backup.sh
When using the names of weekdays or months, it isn't case sensitive, but only
the first three letters should be used, e.g. Mon, sun or Mar, jul.
Comments are allowed in crontabs, but they must be preceded with a '#', and
must be on a line by them self.
Multiuser cron
As Unix is a multiuser OS, some of the apps have to be able to support
multiple users, cron is one of these. Each user can have their own crontab
file, which can be created/edited/removed by the command crontab. This
command creates an indivial crontab file and although this is a text file,
as the /etc/crontab is, it shouldn't be edited directly. The crontab file is
often stored in /var/spool/cron/crontabs/<user> (Unix/Slackware/*BSD),
/var/spool/cron/<user> (RedHat) or /var/cron/tabs/<user> (SuSE),
but might be kept elsewhere depending on what Un*x flavor you're running.
To edit (or create) your crontab file, use the command crontab -e, and this
will load up the editor specified in the environment variables EDITOR or
VISUAL, to change the editor invoked on Bourne-compliant shells, try:
cog@pingu $ export EDITOR=vi
On C shells:
cog@pingu $ setenv EDITOR vi
You can of course substitute vi for the text editor of your choice.
Your own personal crontab follows exactly the same format as the main
/etc/crontab file does, except that you need not specify the MAILTO
variable, as this entry defaults to the process owner, so you would be mailed
the output anyway, but if you so wish, this variable can be specified.
You also need not have the user field in the crontab entries. e.g.
min hr dom month dow cmd
Once you have written your crontab file, and exited the editor, then it will
check the syntax of the file, and give you a chance to fix any errors.
If you want to write your crontab without using the crontab command, you can
write it in a normal text file, using your editor of choice, and then use the
crontab command to replace your current crontab with the file you just wrote.
e.g. if you wrote a crontab called cogs.cron.file, you would use the cmd
cog@pingu $ crontab cogs.cron.file
to replace your existing crontab with the one in cogs.cron.file.
You can use
cog@pingu $ crontab -l
to list your current crontab, and
cog@pingu $ crontab -r
will remove (i.e. delete) your current crontab.
Privileged users can also change other user's crontab with:
root@pingu # crontab -u
and then following it with either the name of a file to replace the
existing user's crontab, or one of the -e, -l or -r options.
According to the documentation the crontab command can be confused by the
su command, so if you running a su'ed shell, then it is recommended you
use the -u option anyway.
Controlling Access to cron
Cron has a built in feature of allowing you to specify who may, and who
may not use it. It does this by the use of /etc/cron.allow and /etc/cron.deny
files. These files work the same way as the allow/deny files for other
daemons do. To stop a user using cron, just put their name in cron.deny, to
allow a user put their name in the cron.allow. If you wanted to prevent all
users from using cron, you could add the line ALL to the cron.deny file:
root@pingu # echo ALL >>/etc/cron.deny
If you want user cog to be able to use cron, you would add the line cog
to the cron.allow file:
root@pingu # echo cog >>/etc/cron.allow
If there is neither a cron.allow nor a cron.deny file, then the use of cron
is unrestricted (i.e. every user can use it). If you were to put the name of
some users into the cron.allow file, without creating a cron.deny file, it
would have the same effect as creating a cron.deny file with ALL in it.
This means that any subsequent users that require cron access should be
put in to the cron.allow file.
Output from cron
As I've said before, the output from cron gets mailed to the owner of the
process, or the person specified in the MAILTO variable, but what if you
don't want that? If you want to mail the output to someone else, you can
just pipe the output to the command mail.
e.g.
cmd | mail -s "Subject of mail" user
If you wish to mail the output to someone not located on the machine, in the
above example, substitute user for the email address of the person who
wishes to receive the output.
If you have a command that is run often, and you don't want to be emailed
the output every time, you can redirect the output to a log file (or
/dev/null, if you really don't want the output).
e,g
cmd >> log.file
Notice we're using two > signs so that the output appends the log file and
doesn't clobber previous output.
The above example only redirects the standard output, not the standard error,
if you want all output stored in the log file, this should do the trick:
cmd >> logfile 2>&1
You can then set up a cron job that mails you the contents of the file at
specified time intervals, using the cmd:
mail -s "logfile for cmd" <log.file
Now you should be able to use cron to automate things a bit more.
A future file going into more detail, explaining the differences between
the various different crons and with more worked examples, is planned.
Additional Reference:
Man pages: cron(8) crontab(5) crontab(1)
Book: _Running Linux_ (O'Reilly ISBN: 1-56592-469-X)
cog
© Copyright 2000 cogNiTioN <[email protected]>
㈡ suse 系統的評估代碼怎麼獲得
SUSE Linux 原來是德國的 SuSE Linux AG公司發行維護的Linux發行版。
1、SUSE集成管理界面不僅僅是軟體，SUSE可以使管理員不需要對組件進行深入研究而進行配置，SUSE可以配置管理需要或者不需要的所有組件。
2、在SUSE LinuxEnterprise Server里卻不是這樣。SUSE依賴於另一個安裝工具，SUSE在系統的每一個版本更新中都有做改進，通過在SUSE的現狀可以看出。
3、SUSE有一個綜合管理程序控制面板，這很重要。管理員可以方便的通過SUSE的綜合管理工具面板來獲得新的軟體。
4、SUSE的使用案例是與混合伺服器操作系統的環境，那裡的管理員管理系統只有一個膚淺的認識：UNIX和Linux編程。
5、SUSE Linux的YaST可以和命令行交叉工作，SUSE之間可以互補，所以習慣用SUSE編程命令行來管理伺服器也可以達到相應的效果。
6、在SUSE早期版本，SUSE會損壞一些手動創建的配置。Linux的早起管理員都有過這種經歷：SUSE損壞了管理大量手工創建的配置。然而，SUSE的配置改變現在已經有完善的告警機制，管理員們可以放心的使用SUSE。
7、在新近的SUSE版本里，SUSE會自動備份配置文件和顯示手動修改過的配置，SUSE這樣的機制可以保證最大化的配置丟失風險
㈢ suse linux這是什麼系統（普通電腦可以裝嗎向華碩可以嗎）
一樓真可笑。suse是一種linux系統，用rpm軟體包。在大部分pc機上都能裝，我的小Y第二系統就是opensuse12.1。suse是企業用的，需要付費，opensuse是免費的下載安裝就好，官網有一些指南(
)。不過suse似乎構架跟別人不一樣，像gtk的使用跟ubuntu就不一樣。總的來說適合使用不適合玩系統，裡面有個軟體叫yast跟windows的控制面板差不多，windows用戶比較容易上手。opensuse對硬體的要求稍高些，安裝kde的suse被稱為最漂亮的操作系統，但是建議使用gnome桌面，因為許可權爭執比較小
㈣ 請問SUSE Linux Enterprise Server 11激活代碼去哪找
安裝個桌面版本就好了
如果實在要伺服器版本就安裝CentOS吧
㈤ Suse Linux的Yast2相對於cmd命令有什麼優勢
YAST2是圖形化界面,對於不熟悉命令的同學有很大的幫助
㈥ opensuse和suse的區別
SUSE linux原來是德國的一個linux發行版本,在歐洲很流行,有廣闊的市場.2003年的時候被NOVELL收購,成為其旗下的一個產品.它開發的XGL是第一個真正意義上實現3D桌面效果的OS.suse linux在9.0的時候是要收錢的,後來受的壓力太大了，從10.0才開始免費的.
NOVELL公司有兩種linux版本,一個是OPEN SUEE,另一個是Enterprise linux,後一個是為企業而設計的,要長期使用,是要收一定的費用的.而前一個是完全按照開源社區的要求,是免費的和放開源代碼的.
SUSE linux界面華麗,不過也很占資源,一般不建議配置比較低的用戶的安裝!運行SUSE 好像你的電腦運行VISTA一樣!
suse linux10.0以後的版本都叫 openSUSE,目前Novell官方網站上公布的最高版本是Suse Linux Enterprise SP2 。
openSUSE 項目是由Novell公司資助的全球性社區計劃，旨在推進 Linux 的廣泛使用。這個計劃提供免費的 openSUSE 操作系統。
openSUSE 是 Novell 公司發行的企業級 Linux 產品的系統基礎。
openSUSE 項目的目標是:
使 SUSE Linux 成為所有人都能夠得到的最易於使用的 Linux 發行版，同時努力使其成為使用最廣泛的開放源代碼平台。
為開放源代碼合作者提供一個環境來把 SUSE Linux 建設成世界上最好的 Linux 發行版，不論是為新用戶或者有經驗的 Linux 用戶。
大大簡化並開放開發和打包流程，以使 openSUSE 成為 Linux 黑客和應用軟體開發者的首選平台
捎帶一講：
openSUSE 項目和Fedora有什麼區別？
Fedora 項目，被紅帽公司支持，是一個強大的社區對開源的貢獻。還有其它大型開源項目，比如Debian和Ubuntu，提供活躍的用戶開發社區。總體來講，這些開源項目桌面更注重以工程為中心的技術問題，把它們提供給 Linux 用戶開發者的技術性社區。
openSUSE 項目不會區分技術性社區和由 Linux 用戶組成的非技術性社區。openSUSE 項目通過公開透明的開發流程，創造一個穩定精良的 Linux 發行版（ SUSE Linux ），提供 Linux 用戶所需要的一切。（ SUSE Linux 一直被評論為最設計最好而且最好用的 Linux 。）為實現把 Linux 帶給每個人的目標，openSUSE 項目使潛在 Linux 用戶能通過各種渠道更容易的獲得 SUSE Linux ，包括帶文檔的用戶端零售版。只有 openSUSE 項目為了讓業余用戶能夠有最好的 Linux 體驗而不斷改善 Linux 發行版。
當具體的和Fedora相比，openSUSE 項目開發並包含了很多Fedora所沒有的其它重要開放標准，比如CIM (the Common Information Model)和YaST (一個標准開源的 Linux 配置管理套件）。此外，openSUSE 項目在桌面和易用性方面努力良多，被許多全球頂尖的開源GUI設計者所強化
㈦ Suse12.3怎樣掛載安裝鏡像文件
mkdir /mnt/cd2
mount -o loop /../LabVIEW fo Linux.iso /mnt/cd2
或用虛擬光碟機軟體。。。。
編輯grub.conf
root (hd0,6)#iso文件所在位置
kernel /vmlinuz boot=casper iso-scan/filename=/LabVIEW fo Linux.iso
initrd /initrd.gz
㈧ suse linux是啥系統和linux、unix 有什麼區別，solaris有是啥東西啊，各位大俠幫忙解釋一下！
solaris是SUN公司的unix操作系統
suse linux是linux操作系統的一個分支版本
linux和unix的區別是，先有unix，再有的linux，一般企業和個人用linux就可以了，unix對硬體有要求
㈨ suse linux 如何關閉selinux
SUSE Linux 默認不會開啟 SELinux
YaST-->系統-->運行級別-->關閉SELinux 即可.
---
如果你用了內核參數的形式的,必須修改GRUB,在 引導代碼後添加:
selinux=0
㈩ SUSE Linux亂碼問題
解決方案無非就是把python的代碼的開頭編碼用utf-8，打開資料庫連接的時候也用charset='utf8'，還搞什麼sys.setdefaultencoding('gbk')，mysql的my.cnf配置文件裡面配置為utf-8。等等之類的東西，無效，插入中文還是亂碼，就是插到資料庫裡面，直接看資料庫里的中文都是編碼，或者是????什麼的。
把問題簡單化，mysql的默認編碼為latin1，查找mysqldb的源碼關鍵報錯的地方是cursor.execute，這里要執行一下encode(charset)，既然這里要encode，那就在外面先decode一下，果然什麼都不改，在自己的調用函數里做decode。
sql
=
'insert
into
aa
values('測試')'
sql
=
sql.decode('latin1')
cursor.execute(sql)
這樣就解決問題了，中文插入，中文顯示，在終端命令行直接查看資料庫也是中文。
試試，建表的時候不需要指定編碼。