4.9. System Administration.
Section quotes:
- "Testing can show the presense of bugs, but not their absence."
-- Dijkstra
- "Whenever anyone says, ``theoretically,'' they really mean, ``not really.''"
-- Dave Parnas
Section contents:
4.9.1. Introduction.
Although it very difficult responsibility to administrate a computer system,
there are many complicated things you have to manage from securing the network,
watch permissions (who is allowed to do what), securing secrit files
and make sure other files will not be changed or compromised,
discover cracking trials, and keep your system 'UP AND RUNNING' specially
that there are some crackers want to prove that they are smarter by cracking others
systems. Fortunately this job is more simple with our robust Linux kernel and
powerful GNU tools. I'll keep this section simple that any user can understand
it, if you want to be a real administrator you have more books and articles to read.
You may need only a small part of this section, but I recommend that you
read it all first, it could be confusing at first look, but later
every thing will be clear.
We will not discuss physical security like to protect your computer
case from being opened, your password protection on BIOS setup,
 Tip
Password protection provided by BIOS is very weak, you could bypass it with
one of those manufacturer BIOS defualt passwords:
'j262', 'AWARD_SW', 'AWARD_PW',
'lkwpeter', 'Biostar', 'AMI',
'Award', 'bios', 'BIOS',
'setup', 'cmos', 'AMI!',
'SW1', 'AMI?SW1', 'password',
'hewittrand' and 'SHIFT + s y x z'
see 'http://astalavista.box.sk',
another way is to remove the CMOS battary,
any way don't trust this password as your only hope, see hard drisk encryption
on '4.8. Disk Managment.' .
The most risk is from external network attacks, attackers could
use a vulnerability in a server you run to compromise your system
then they could access to files they should not, and miss with files.
First of all make sure you have a strong root password!!
complicated strong root password, avoid weak passwords like:
repeated letters, sequential (like 123,abc and ZYXW),
your name, a special date, a dictionary word, any thing
of that with numbers in between or any thing of that spelled backword.
All those are VERY WEAK passwords, because cracking programs
can guess them very fast, the only "efficient" way to crack passwords
is to try all possibilities one by one but trying common weak passwords frist.
Strong passwords should seem random,
to make one get a long sentence like "He is stupid, not like me. I'm using Linux"
then take the initials (keeping punctuation marks)
to get "His,nlm.I'muL" then use 'lEEt-1337' trick that
is to replace each l with '1'(one), O with '0'(zero), E with '3', t with '7',
S with '5', g with '9', a with '@' and i with '!'.
Our example password is "H!5,n1m.I'mu1" then select
a repeated letter like 'm' make it in upper case to have a mixed case password
like "H!5,n1M.I'Mu1" and the last tip is not to use passwords you found
here or there but ones that your made.
'sudoers' (users allowed to run things as root) passwords should be
strong too, and their 'sudo' privileges should be minimalized,
and better if they do NOT exists, also users allowed to access
files, network,... etc, because the cracker will crack their passwords
then use their accounts to compromise the system.
GNU/Linux is very secure, no creature can unencrypt your password
even Linus himself or Mr. RMS himself can't, no user (even the root)
could tell others' password. How could you (the administrator) know
that a user in any host, you are responsible for, uses a weak password ?
the idea is very simple use the same method crackers use,
yes! using crack programs, we recommend to change password each 6 months,
do not write passwords in any word readable file (shell scripts),on papers or
any place near the computer.
Tip
The best method to protect your system, is to think like a cracker,
use cracker tools and crack your own system if you are allowed to do so,
and when any tool find any thing wrong, it should send a warning.
Tip
You ask me 'Why no creature can unencrypt passwords in GNU/Linux ?',
thats because we use asymmetric one way encryption, it's an algorithm
uses two keys, a public encryption key and a secrit private unencryption key.
Public key can be generated from the private one (along with random string),
to encrypt you only need the public key, but to unencrypt you need
the private key (or both keys), the private key is choosen to be your password,
and the public key is made by transformation of random numbers generator and
the private key, then your password is encrypted using the public key
and it's stored in 'passwd' file along with the public key,
to unencrypt the password hash you need the private key which is the same
unknown password, it's like a closed safe that its key is locked inside.
Now if the private key is your password and it's not saved (unencrypted)
on any file, how can GNU/Linux know that you enter the correct password,
even though it don't know the private password needed to unencrypt it
and do the comparison ? simply it use the public key to encrypt what
you enter then compare the two encrypted passwords, without knowing
the password or unencrypt it.
Now you are wondering why don't some one reverse the encryption transformation
using the public encryption key ('+' becomes '-' and '*' becomes '/') ?
that's because some mathematical operation is more simple and others are very complicated
that need guessing in order to get a result, for example it's simple to find '23*17*13'
but it's more diffecult to find prime factorization of '5083' (you have to try them all),
the calculations used to encrypt with public key is very straight forward
but the inverse calculations are very complicated and need more digits than
the computer could calculate and if you use arbitrary precision calculators
like GNU 'bc' it will take too long time and consume too large memory.
Tip
Assuming that the cracker has access to your computer and bypass the firewall,
the only "efficient" way to unencrypt your passwords is to try and guess all possibilities
using special programs. To make it diffecult to be cracked, you should make
sure that the public key is random enough, but there are no real random functions,
distributions boot scripts do an entropy loop operation, it take informations
that the cracker won't know, like the current time and a random file
saved from last boot, and seed them to the fast random generator '/dev/urandom',
then seed the random generator '/dev/random' by the fast random generator,
then those pseudorandom generator become more secure after this loop.
For more protection we don't depend on encryption only,
password hashes is not saved in a world readable
file (the user accounts file), but instead in a root only readable file,
this method is called shadow passwords, because what can be done in
years can be done in months using super computers or main frame,
if you have information that worth billions the cracker could
buy one for some millions and use it to get billions
by running cracking programs on your world readable password file.
Make sure you set a password on your BIOS settings, and boot priority
is for hard disk, because as you know boot from a rescue disk
or a live CD then 'mount' the Linux root file system from the hard disk,
then use 'passwd' to change it!! Put passwords on GRUP and LILO
to prevent one from passing argument to the kernel
(for example 'linux 1' will boot Linux then enter to single user runlevel
and give you a shell as root)
Having an installed other closed source untrusted systems
(like Windows) in your boot menu (unlocked) is like having a hole in you security,
you had better emulate Windows with WINE, and if you install WINE configure
it to display a warning that a Windows program is working.
Using pre-compiled packages (unsigned and from untrusted sites) is
NOT recommened, you should get it from source or as package from trusted sites
and signed with packager GPG signature, and remember to NEVER login as root to the
GUI, this will case many damage.
Tip
Make sure that you are using password shadow, the tool 'pwcon' will convert
passwords to shadow. Make sure you use MD5 hash enryption method
NOT the old DES used in old Unix systems, make sure this line
'MD5_CRYPT_ENAB yes' in '/etc/login.defs'
file, and update PAM files to have 'password required pam_unix.so md5 shadow'
in '/etc/pam.d/login' and other related PAM files,
after this new passwords will use MD5, see PAM subsection.
4.9.2. Administration commands.
We talked about 'chmod','chown' and 'chgrp' refere to them,
to change your password type 'passwd' and follow it by user name for others
(if you are root, you can change others passwords),
to add a user use 'useradd' then interacte with it, to remove him
use 'userdel' folloed by his login name (use '--remove-home option to delete his home) ,
they are also work as 'adduser' and 'deluser'.
Tip
When you add a new user, his home directory is created to contain
configuration files, an initial configuration is copied from
'/etc/skel'.
To add a group use 'groupadd', to add a user to group use
'gpasswd -a myuser mygroup', and to know what groups
some user is member in use something like 'groups myuser',
to set an expiry date for a user account use 'chage'
for example to give 'student1' one year use 'chage -M 365 student1'.
To login as another user use 'su' followed by his login name,
if NOT specified it will be assumed to be root (you will be asked for password)
when the root uses it he will not be asked for password.
It's a good practice not to give priviligers per users but to give it per group,
for example, if you want only to trust Ali to use the floppy device,
do not make Ali the owner of '/dev/floppy' and give him an execlusive
access to it (ie. mode 700) but instead you should make a group called floppy
and make '/dev/floppy' owned by root user and floppy group
accessed only by them (ie. mode 770) and them add Ali to that group
so that when you in future want to trust Ahmad to use the floppy
then you just add him to that group and if you no more trust Ali to use
it you remove him from the group, in this way files permissions are studied and
done once and kept as is.
'su' tool will not change to the user home directory, nor it will
call '~/.bashrc' or run his default shell, to open a full
session of the user add '-', for example 'su -' will open a
root session.
Tip
'su' is short for Super User, because the administrator is supposed to run
his work as a regular user, and when he wants to use his power he becomes a
super user with it.
If you are an 'sudoer' you may run programs as other
users using your password (not their password) by typing 'sudo'
followed by the command to execute. Only users that the root
put them in the 'sudoers' list, and the root specify what programs
that each can 'sudo', editing this list is done through 'visudo'
which uses vi text editor.
If you miss use this then you create a security hole,
usually root is the only is sudoer, in some old distribution
they add users as sudoers and allow them to shutdown,reboot or change time,
in new distribution we use PAM and consolehelper.
4.9.3. Password database.
The file '/etc/passwd' is the file where users accounts
data base is stored, lines look like this:
'myname:x:1000:100:mygroup:/home/myname:/bin/bash'
the first field is the login name, some of them are not human
they are program (we will discuss why later), change their passwords
and make there default shell to be '/bin/nologin' (using chsh),
the second field is the encrypted password, it's a text string
using alphanumeric,'.' and '/' characters, if it's an MD5 hash
it will start with '$1$' followed by the public encryption key
(GNU documents call it 'salt') upto 8 characters ends with '$',
followed by the encrypted password upto 22 characters, on the other hand
DES passwords start with two character salt in other words it does not start
with '$1$', after that an 11 character, make sure your
passwords are NOT encrypted using DES, in other words they should start with '$1$',
 Warning
Make sure your last modification time to '/etc/passwd',
because pseudorandom number generators could depend in time of call,
so that the cracker could predicate it's state,
at any time run 'touch /etc/passwd'.
Warning
Do NOT modify passwd or shadow files directely, instead use system tools.
No UID should be zero except root, no one (except you) should be member of root
group, minimize membership of special groupd like root,admin and weel groups.
Years ago, a method of giving the same UID of many users to have
the same privileges and rights, this makes your system complicated,
if you want to give the same rights to some users create a group
and let them in it.
Extra account information could be set for a user (by the user himself or root)
using 'chfn' which set the user full name with '-f', his work
phone '-w', his home phone '-h' and his room number '-r' (all those
fields could be long or hold printable special characters except ',:='):
bash# chfn -f 'Muayyad al-Sadi' -r 'R2,101' alsadi
4.9.4. Programs permissions.
A program has rights the same as the running user, for example
'ls' run by Ahmad can list Ahmad's home files, but it can't
if Ali is running it. When a program forks another program,
it's privileges will be as the parent program.
This is not a rule, for example 'su' run by Ali could fork 'bash'
as root! 'login', 'sudo' and many other programs can do that,
how thet did it ? If the owner of the file set the SUID flag
on it, then when any one run it (allowed with execution flags) , it
work as the owner user of the file (not the caller),
a file owned by root having SUID flag gain the root privileges,
no passwords needed. SGID flag work similarily but with the
privileges of the file group. Those flags can be set
using 'chmod' tool using symbols; SUID with 'chmod u+s file'
and GUID with 'chmod g+s file'
or in octal code where SUID is 4 and SGID is 2
(1 is for sticky bit) in the forth octal digit (first from the left),
those marks can only be set by the root or the owner of the file.
Programs with those flags are very dangerous, a program
with SUID could choose between the owner privileges(default)
and the caller privileges.
This flag makes 'sudo' possible (it's owned by root and has SUID flag),
but in many cases this flag is very useful, for example if we have
a game, any one could play, but only the game (called by any one)
could edit the high score file, another example a web program (a PHP file)
that allow visitors to download files (mobile phone pictures)
after they provide a code (from charging cards) to prove payment,
the only way to access those files is through the program.
We can do things like this, create a special group and use 'chgrp'
or 'chown' to make the program and secrit files owned by root user
and this neww group, now use 'chmod' like this 'chmod 770 secritfile'
to allow root and group members to read and write and others can't do both,
but our new group has no members, now give the program SGID flag
with 'chmod 2755 myprog', when the program is called
by any one it will have the right of the group and access the files
but only root can access them without the program.
We can do the same effect by creating a new user (with no login) and give the program
SUID flag, but I like groups more.
The program having those two flags is the one which tell to allow or not
one from using it's special privileges (that's how 'sudo' allow you to be
other user using your password not his password),
the system administrator should make sure that
those programs does not open a hole in security, check those basic rules:
- It should be open source, you(or one you trust) read it and understand each line.
- It should not be a script.
- The program should drop the new owner/group rights when it is started to
get back the real caller rights and use the special rights only when it's needed
and password is checked or payment code is entered or the game is over ...
- Does not call programs using shells.
- Call programs using only its full absolute path like '/bin/ls' NOT 'ls'.
because the cracker could change PATH to make it call his own '~/ls'
which could use the special rights.
- It should NOT call any programs others has write access,
because some one could use this right to change the program (overwrite it) to his own
version that use the special rights. The program it self should also
be writable only be you(root).
- It should reset resources (eg. memory) before return them to the operating system.
4.9.5. PAM aware programs.
To have better powerful authentication, GNU system was the first to add support
to MD5 encryption to replace DES, they rewrite their 'su', 'login' and other
related tools, question is do we have to rewrite all programs that need
to use authentication each time a new better technology appear ?
those sensitive programs should be stable, so is there a way to set what ever
authentication method without the need to rewrite or recompile programs ?
The answer is Linux Pluggable Authentication Module (PAM), but first
what is authentication all about ? Authenication is the procedure
used to prove that one is what he clams to be. PAM-aware programs can
switch between different authentication machanisms by editing its
PAM configuration file to load and use some module, no rewriting
no recompiling, for example you can configure a PAM-aware game
for your son not work on his final exams days, you may disable
a user from login if he has empty password or forbid users from having
week passwords, you may move from one password encrypttion to another,
and any thing you can imagine like using
PAM-aware fingerprint reader :) , see www.kernel.org/pub/linux/libs/pam/modules.html.
There are two methods to configure PAM-aware programs, one is to use single
file '/etc/pam.conf', and the other is to configure each program
in different file like '/etc/pam.d/NAME' where NAME is the
program name, it could be 'su','login','ftp','ssh', and many other
(in lower case letters), configuration files could contain comment lines
(a line start with '#'), comments should be on a line by itself.
It it's not a comment then it starts with a specifier in the first column
which should be one of the following
'auth', 'account', 'password' and 'session' it specify the operation you
are setting, 'auth' is for authentication (asking for password for example),
'account' is non authentication based process for example time,limits,
existence of a file, 'password' controls password chaning process, 'session'
is post login process like display Message of the Day (MOD/MOTD), check your
mail and display "you have a new email", each can appear in more than one
line but they should be in the same order. The second column specify how
necessary it is to success, it will be one of the following:
| required | The success of this module
is required, if it fail it will try others and ignore them (just to
report them if asked to).
|
| requisite | The success of this module
is also required, if it fail it won't try any thing else.
|
| sufficient | The success of this module
is sufficient even if others fail.
|
| optional | The success of this module
is optional, if it fail and others success you are in.
|
the next columns are the module (plugin) you want to load and it's
arguments, a PAM module is a '.so' file that can be found
in '/lib/security/', each do different job and accept
different types of arguments, the next table show some of them:
- /lib/security/pam_warn.so
-
It will write a warning in log files and always return success.
- /lib/security/pam_deny.so
-
Always fail, "what ever you do, you are not him!".
- /lib/security/pam_premit.so
-
Always success, "You are him even if all the world says not!"
- /lib/security/pam_securetty.so
-
Success if the request is from a terminal mentioned in '/etc/securetty'.
- /lib/security/pam_cracklib.so retry=K difok=L minlen=M Xcredite=N
-
Success if the password is strong enough, it will use cracklib to test the new password (with K trials)
to have at least L characters not found on the old one, at least M character long,
N in Xcredite which is one or more of 'dcredite','lcredite', 'ucredite' and 'ocredite'
for having at least N more digits,lower case letters,upper case letters
and non alphanumeric characters respectively beside the minimum len M
(for example with M=7 and dcredite=1 then 'voodoo1' will fail)
all arguments are optional but the defaults sometimes make it impossible
to change the password (if all letters are used and the default is to have
some letters that was not used in the old password)
- /lib/security/pam_unix.so nullok md5 shadow
-
The classical standard Unix way, 'nullok' argument success
even if the password is empty, 'shadow' and 'md5' is obvious
(all arguments are optional, and there are more)
- /lib/security/pam_nologin.so
-
If the file '/etc/nologin' exists then only root can login.
- /lib/security/pam_stack.so service=FOO
-
Include file '/etc/pam.d/FOO' contents,
used in RedHat Linux to unify different tools settings
for example 'auth' sections in all PAM files use this module
'pam_stack.so service=system-auth' so that
it's enough to edit '/etc/pam.d/system-auth'
to change all system tools authentication configuration.
for more information refere to PAM documents (PAM guide by Andrew G. Morgan, see pam-doc package).
If you are using the single file configuration then we add a first column
to specify the tool we are configuring, you need some examples!
We have a special name that is OTHER it's used to configure PAM-aware program
that has no configuration file with its name, for example if you are very paraniod
then any (PAM-aware) non configured program should not work but log it first
then create '/etc/pam.d/other' file to be:
# this is /etc/pam.d/other
# deny every thing but log them 1st
auth required /lib/security/pam_warn.so
auth required /lib/security/pam_deny.so
account required /lib/security/pam_warn.so
account required /lib/security/pam_deny.so
password required /lib/security/pam_warn.so
password required /lib/security/pam_deny.so
session required /lib/security/pam_warn.so
session required /lib/security/pam_deny.so
# this is /etc/pam.d/other
# allow every thing
auth required /lib/security/pam_premit.so
account required /lib/security/pam_premit.so
session required /lib/security/pam_premit.so
# this is /etc/pam.d/other
# do normal unix
auth required /lib/security/pam_unix.so md5 shadow
account required /lib/security/pam_unix.so
password required /lib/security/pam_unix.so md5 shadow
session required /lib/security/pam_unix.so
#/etc/pam.conf
# ...
OTHER auth required /lib/security/pam_unix.so md5 shadow
OTHER account required /lib/security/pam_unix.so
OTHER password required /lib/security/pam_unix.so md5 shadow
OTHER session required /lib/security/pam_unix.so
# ...
auth required /lib/security/pam_securetty.so
password required /lib/security/pam_cracklib.so minlen=6
password required /lib/security/pam_unix.so shadow md5 use_authtok
# this is /etc/pam.d/something
# include system-* files here
auth required /lib/security/pam_stack.so service=system-auth
account required /lib/security/pam_stack.so service=system-account
password required /lib/security/pam_stack.so service=system-password
session required /lib/security/pam_stack.so service=system-session
4.9.6. System log reports and local intrusion detection.
You could know what user you are logged as, just type 'whoami', or with
more human style type 'who am i', or kids style 'who mom likes',
the last two commands are a special case of 'who'
which can tell all logged users (if you run it without argument
it will show login name,line and period).
You may specify details you want with arguments like 'a'
which display all details, 'H' will add column headers line at the top,
'u' will display names, 'q' will count how many logins for each user,
and many more options. A related tool is 'users' which diplay
logged users.
Tip
The file in which raw login data is saved is '/var/run/utmp'
or '/var/log/wtmp', they should not be edited or viewed directely.
The attacker (cracker) could know the password by guessing it, then
encrypted and compare it with the encrypted password hash
using the cracking programs, the most famous is 'crack'
see http://users.dircon.co.uk/~crypto/index.html,
'johen the ripper' see www.openwall.com/john
and 'slurpie' (see www.ussrback.com/distributed.htm)
that is superior to the previous tools because it could
distribute the task to many computers at the same time.
Another package called 'tiger' (included in Debian) do some checks then
report known ways that could be used against your system to compromise
the root account to warn you from possible local intrusion risks.
Those tools are not common and they are not included usual distributions (except Debian).
If you are a system administrator investigating an internal cracking trial,
then you may use 'last' tool, it tells the last login trials,
and logout time, for example 'last -n 20' will display
last 20 lines of login (or trial) and logout, 'last -t 20031231103000'
will display all after the day '2003-12-31' and time
'10:30:00', the option '-da' used to display
host names not address, and '-x' is used to display shutdown times.
The tool 'lastb' is used to display only faild login trials.
Tip
If you are too busy to be infront of the computer to reboot it
if any thing goes wrong, install a package called 'watchdog'
(which need a kernel newer than 1.3.52 compiled with software watchdog support)
which will write things to /dev/watchdog every ten seconds.
If the device is open but not written to within a minute, the computer
is considered in bad state and it will reboot automatically!
Some file permissions are very risky specially SUID and GUID, a change
in file permissions of such files could indicate an intrusion or a stage
of some attack. Debian offers a regular check of change in such permissions
and report them to the root via email, that was through a script
of 'cron' package (see subsection 4.9.8. Automated scheduled jobs.)
it's now in a separate package called 'checksecurity'.
A package called Advanced Intrusion Detection Environment (AIDE)
detects changes to files on the local system and creates a database
used to verify the integrity of the files.
When kernel log daemon ('klogd') and system log daemon ('syslogd')
are running, kernel and system messages are reported to '/var/log/messages'.
Each message record includes its date, time, hostname, message type and imporance
level. Many system programs uses the system log service to report actions
(others has their own file some where in '/var/log/' directory),
such information could be critical when investigating some problem.
You could display the last some lines
of this file by typing 'tail /var/log/messages'
and you may prefare to use a GUI log viewer (eg. 'system-logviewer' in Fedora Core),
one that gives different colors for wanrings and errors.
Log files could be converted to nice human readable reports (printable PDF or web HTML file)
using programs like Lire which supports the log format of many system services
like email servers, web servers, firewall, printing, DNS and database services.
Log files could just be a wast of your disk space
type 'head /var/log/messages' to see some very old messages,
a trick used by few systems to empty logs every boot before starting
log daemons through init scripts using ':>/var/log/messages'
but this is a very bad practice,
A tool called Logrotate which is usualy set to run every day through
'cron' (see subsection 4.9.8. Automated scheduled jobs.)
handle log files automatically to remove messages, send them to a compressed
file, or even email them. It's called rotating because old messages
are taken from the log file leaving fresh messages at the top of the file.
It can be set to work when the log file gets to a specified size instead
period of time.
4.9.7. System limits.
The following 'bash' script is taken from 'Advanced Bash-Scripting Guide':
#!/bin/bash
# this is a hang script
while 1 # Endless loop.
do
$0 & # This script invokes itself . . .
#+ forks an infinite number of times . . .
#+ until the system freezes up because all resources exhausted.
done # This is the notorious "sorcerer's appentice" scenario.
exit 0 # Will not exit here, because this script will neve
# end of hang script
Tip
Maybe this is the source of the 'fortune-mod' joke
that Linux is very fast, it can do infinite loop in 5 seconds.
You may specify a limit on file size, core-dump file size (0 to disable them, with 'ulimit -Hc 0')
and so on, limits are two types hard-limit that only root could explicitly
change it and soft-limit is a recommended limit that can be broken
explicitly by any one as long as it's below the hard-limit.
The option '-H' for hard-limit, '-S'
for 'soft-limit' and it's the default:
| Limit type | Unit | Option |
|---|
| core file | block* | c |
| data segment size | KB | d |
| file size | block* | f |
| locked memory size | KB | l |
| memory block | KB | m |
| number of open files | file | n |
| pipe buffer size | 512 byte | p |
| stack size | KB | s |
| CPU time | second | t |
| processes for each user | process | u |
| virtual memory | KB | v |
* the block unit depends on the file system.
4.9.8. Automated scheduled jobs.
Some times the administrator need to do many boring tasks,
to be executed in specific periods of time, for example
archiving, backup, sanity checks, generating reports from logs and log rotating,
there are two types to do this one is to do it at cerain time point
(if the computer is on at that point)
and the other is to do it frequently each some period (eg. once a month).
If this job is a sequence of commands put it one file (shell script)
see '6.2. Programming with bash, shell scripts.' section.
You can accomplish this in very weird method using 'sleep' for example
to execute COMMAND after one hour:
bash# sleep 3600 ; COMMAND &
#!/bin/bash
function doit() {
sleep 3600
COMMAND
doit
}
doit
To run a job once at single point of time we run 'at' daemon first
using your distribution graphical or console service management tool (refere to
'4.3. Linux under microscope.' section), in Red Hat :
bash# chkconfig --levels 345 atd on
bash# service atd start
To run programs frequently (not once) then use 'cron' or 'anacron'
daemons, the first smallest unit is a minute and the other's a day.
'cron' waits for a specified point of time (the computer is assumed to be working at that time)
it could be fooled by daylight saving manual change of clock so it
could run it twice or not run it at all, on the other hand
because 'anacron' measured by days, it won't affect if the time is
changed some hours or the computer was off for some hours.
Usually distribution configure them both to add all jobs (shell scripts)
in those directories:
'/etc/cron.daily', '/etc/cron.weekly' and
'/etc/cron.monthly' to be executed as their names imply
(there are 'cron.hourly' for 'cron'), if you want custom period (eg. each 3 days)
you have to configure them by hand. Only one service of the two daemons can be activated.
'cron' allow regular users to add jobs if the root put their names in
'cron.allow' or not be in 'cron.deny'.
to display current jobs:
'crontab -l [-u USER]'
to remove one:
'crontab -r [-u USER]'
to edit the table jobs:
'crontab -e [-u USER]'
this will open your favorite text editor specified by 'VISUAL'
or 'EDITOR' enironment variables
This file format is to start with setting some variables:
'VARIABLE=VALUE' like 'SHELL=/bin/bash',
then followed by the table like this
MIN HOUR DAY_OF_MONTH MONTH DAY_OF_WEEK COMMAND
On the other hand 'anacron' it keeps settings on '/etc/anacrontab'
file with this format:
DAYS MINUTS_DELAY ID_STRING COMMAND
|
Best viewed with free web browsers
You may get more high quality software
from here for free
Generously Hosted by www.JadMadi.net
|
