Essential System Administration
`
`Sebastopol, CA 95472
`
`Eleen Frisch
`
`O’Reilly & Associates, Inc.
`103 Morris Street, Suite A
`
`Oracle Exhibit 1003, page 1
`
`Oracle Exhibit 1003, page 1
`
`

`

`Editor: Mike Loukides
`
`Printing History”
`October 1991:
`
`First Edition.
`
`January 1992:
`
`Minor corrections.
`
`August 1992;
`January 1993:
`
`Minor corrections.
`L Minor corrections.
`
`Nutshell Handbook and the Nutshell Handbook logo are registered trademarks of O’Reilly
`& Associates, Inc.
`
`Many‘of the designations used by manufacturers and sellers to distinguish their products
`are claimed as trademarks. Where those designations appear in this book, and O’Reilly and
`Associates. Inc. was aware of a trademark Claim, £116 designations have hem 1311mm in caps
`or initial caps.
`
`While every precaution has been taken in the preparation of this book, the publisher
`assumes no responsibility for errors or omissions, or for damages resulting from the use of
`_ theinfonnation containedherein.
`
`’
`
`-
`
`xviii
`UNIX Versions Discussed
`Audience xix
`Organization
`xx
`Conventions Used in this Handbook
`xxii
`Acknowledgments
`XXIII
`
`[7/94]
`
`Preface
`
`Chapter 1 Introduction to System Administration
`
`The System Administrator’s lob
`Becoming Superuser
`Communicating with Users
`Interactive Communication with Users
`
`Sending a Message to All Users
`The Message of the Day
`System V Local System News
`Sending Mail to a Group of Users
`Essential Administrative Tools .
`Menu Interfaces for System Administration
`
`Chapter 2 The UNIX Way
`Files
`File Ownership
`File Protection
`How to Recognize a File Access Problem
`Mapping Files to Disks
`File Types
`Processes
`
`xv
`
`. 1
`
`1
`5
`7
`7
`
`8
`9
`9
`10
`12
`17
`
`20
`21
`22
`25
`32
`34
`35
`40
`
`..
`
`..
`
`r’
`
`Oracle Exhibit 1003, page 2
`
`Oracle Exhibit 1003, page 2
`
`

`

`
`
`Automating Routine
`Tasks
`Using Scripts Effectively
`Periodic Program Execution: The cron
`Facility
`
`
`
`.
`.
`.
`tasks.
`This chapter discusses ways to automate various system management
`automation offers many advantages over performing such tasks by hand, mclud-
`mg:
`
`tasks are performed in the same (correct) way every time.
`' Greater reliability:
`Once you have automated a task, its correct and complete performance no
`longer depends on your alertness or your memory.
`
`
`
`,
`tasks can be performed according to whatever sched-
`' Guaranteed regularity:
`ule seems appropriate and need not depend on your availability or even your
`presence.
`:
`
`.
`
`,
`
`.
`
`.
`
`.
`
`V
`
`‘
`
`.
`
`.
`
`_
`
`
`
`in this section, we’ll consider two system monitoring tasks as examples of creat-
`ing and using administrative shell scripts. The discussions are meant to consider
`not only these tasks in themselves but also the process of and alternatives avail-
`able when using scripts. All examples use the Bourne shell, but you can use any
`shell you choose; it’s merely a UNIX prejudice that “real shell programmers use
`the Bourne shell,” however prevalent that attitude may be.
`
`Example: Password File Security
`
`We discussed the various security issues surrounding the password file in Chapter
`5, Security, The various commands used to check it and its contents could be
`combined easily in a shell script. Here is one version (named ckpwd):
`#l/bin/sh
`# ckpwd — check password file (run as root)
`mnask 077
`# move to dirt. with stored passwd
`cd lusrllocal/binlold
`echo ">>> Password file check for ~date”: echo ""
`
`echo "*** Accounts without passwords:"
`grep "[‘:]*::'
`/etc/passwd
`
`n
`e9 1 1
`if 13):?
`echo "None found."
`fi
`echo
`
`# grep failed
`
`echo "*** Non—root UID=0 or GIIFO accounts:"
`grep ':00*:'
`lets/passwd I \
`awk -F:
`’BEGIN
`{n=0}
`$1!=‘r00t"
`{print $0 ; nil}
`m
`{if ("=0) Punt “we f°““d‘ )
`
`echo
`
`sort </etc/passwd >tmpl
`
`Oracle Exhibit 1003, page 3
`
`

`

`
`
`echo "*** Password file protection:"
`>>> correct values”
`echo "~m—r—r—— 1 root
`wheel
`# leave off “9" under: System V
`ls —lg letc/passwd
`
`echo ""; echo “>>> End of report."; echo “"
`
`The script surrounds each checking operation with echo and other commands
`designed to make the output more readable so that it can be scanned quickly for
`problems. For example, the grep command which searches the password file for
`non—root accounts with UID 0 is now preceded by an echo command which cut-
`puts a descriptive header, and it is piped to an awk command which removes the
`root entry from its output and displays the string “None found.” if no other UID
`or GID 0 accounts are present:
`echo "1*“ Nonvroot UID=0 or GID:0 accountsz“
`grep ':00*:'
`late/passwd l \
`awk 4': 'BEGIN
`{11:0}
`$ll=“root"
`{print $0 ; n=1}
`END
`{if (or-0) print "None found."}'
`
`echo ""
`
`Instead of using diff to compare the current password file with the saved version,
`the script uses comm twice,
`to present the added and deleted lines separately
`(entries that have changed will appear in both lists). The script ends with a
`simple 15 command; the administrator must manually compare its output to the
`string displayed by the preceding echo command. However, this comparison
`could be automated as well by piping ls’s output to awk and explicitly comparing
`the relevant fields to their correct values.
`
`Here is some sample output from ckpwd:
`>>> Password file check for Fri Jul 19 15:48:26 EDT 1991
`
`*** Accounts without passwords:
`None found.
`
`*** Non—root UID=0 or GID=0 accounts:
`badboy:lso9/.7sJUhhs:000:203:Bad Boy:/u/bb:/bin/csh
`
`*** Accounts added:
`chavez:981.sd/i7snso: 190:20:Rachel Chavez:/u/chavez:/bin/csh
`wang:l9jsmn7flg./a:308=302:Rick Wangzlu/vrangzlhin/sh
`
`If you don’t like all the bells and whistles, the script needn’t be this fancy. For
`example, its two sort, two comm, and five other commands in the section compar—
`ing the current and saved password files could easily be replaced by the diff com~
`mand we looked at in Chapter 5, Security, (and possibly one echo command to
`print a header).
`In the extreme case, the entire script could consist of just the four
`commands we looked at previously:
`#l/bin/sh # minimalist version of ckpwd
`grep “[“:]*::' Iota/passwd
`grep ':OD*:'
`loco/passwd
`diff late/passwd lust/locallbin/old/opg
`ls —1g letc/passwd
`
`How much complexity is used is up your to own taste and free time. More com-
`plex means it takes longer to debug.
`
`Whatever approach you take, ckpwd needs to be run regularly to be effective.
`This can be accomplished via the cron facility, described later in this chapter.
`
`Example: Monitoring Disk Usage
`
`It seems that no matter how much disk storage a system has, the users’ needs (or
`wants) will eventually exceed it. Keeping an eye on the situation is a very impor—
`tant part of system management, and this monitoring task is well‘suited to auto—
`mation viarshell scripts. The following commands are helpful in this task:
`
`df
`
`du
`
`Show disk use by physical device.
`
`Show disk use under a directory.
`
`These commands are discussed in detail in the section entitled “Managing Disk
`Space Usage,” in Chapter 8, Filesysiems and Disks. Here are some brief
`examples using them (from a BSD system):
`% of
`Show how full the disks are.
`kbytes
`Filesystem
`used
`avail capacity Mounted on
`889924
`/dev/disk0a
`576340
`224588
`72%
`/
`923044
`Idev/diskde
`806004
`24732
`97%
`Irocks
`% du lu/chavez/progs
`Show space used under this directory.
`43
`lu/chavez/progs/new
`
`
`
`Oracle Exhibit 1003, page 4
`
`

`

`The script we’ll consider in this sectionwckdsk—is designed to compare current
`disk use with what it was yesterday and to save today’s data for comparison
`tomorrow. We’ll build the script up gradually, starting with this simple version:
`#llbin/sh
`; then
`if [
`l —-s du.sav ]
`echo ”ckdsk: can’t find old data file du.sav."
`exit 1
`
`fi
`du fiago/hotre/martin > du.leg
`cat durlog I xargs -n2 crup_size 40 100 du.sav
`mv -f du.log du.sav
`
`
`
`After making sure yesterday’s data is available, this script checks the disk usage
`under the directory ,liago/home/martin using du, saving the output to the file
`dulog. Each line of (15¢.ng is fed by xargs to another script,a cmpgsize, which
`does the actual comparison, passing it the arguments 40, 100, and “dusav” as
`well as the line from the db! command. Thus, the first invocation of cmp_size
`would look something like this:
`cxrpvsize 40 100 du.sav 876 liago/home/martin/bin
`1‘ Output from du begins here.
`
`On systems without xargs (usually BSD systems), the following commands can
`substitute for the cat command piped to xargs shown previously:
`
`\
`cat du.1og I
`awk "(print \“rzmp_size 40 100 du.sav\", "$1, $2}' >tmp.sh
`. tmp.sh
`m trrrp.sh
`
`The awk command constructs each cmp_size command explicitly, placing them
`into tmpch, which is then executed via the shell’s dot command (which reads a
`file’s contents into the command stream, like the C shellis source command).
`
`ckdsk ends by replacing the old data file with the saved output from today’s du
`command, in preparation for running again tomorrow.
`
`This simple ckdsk script is not very general; it works only on a single directory.
`After looking at cmp_size in detail, we’ll consider ways of expanding its useful—
`ness. Here is cmpgize:
`
`$5 (file)=pathname of directory
`#
`osize=previous size (extracted from stile)
`#
`diff=size difference between yesterday & today
`#
`if[$#u1t5];then
`echo "Usage: crnp.sh newlim oldlim datafifile size dir"
`exit 1
`
`fi
`# save initial parameters
`lindt=$1; d1imit=$2; sfile=$3; file=$5; csize=$4
`# get yesterday's data
`osizy‘grep ”$file\$“ Sofile I awk ’{print \$1}"
`if [ —z ”$08129" ]
`;
`then
`# it's a new dir.
`; then
`if [ Scsize —ge slimit 1
`# report if size >= limit
`echo “new\t$csize\t$file'
`fi
`exit 0
`
`ii
`# canpute the size change from yesterday
`if I $osize —eq $csize ]
`then
`exit 0
`elif [ sosize ~gt $csize ]
`then
`dif£=‘expr Sosize - $csize‘
`else
`diff=‘expr sceize — $osize‘
`
`fi
`# check if size change is big enough to report on
`if [ $diff —ge Sdlimit }
`;
`then
`echo "$osize\t$csize\t$file“
`
`fi
`
`cmp_size first checks to see that it was passed the right number of arguments.
`Then it sets its arguments to shell variables for readability. The first two parame-
`ters are cutoff values for new and existing directories respectively. If the size of
`the directory specified as its fifth parameter has changed by an amount greater
`than the cutoff value, cmp__size will print its name and old and new sizes; other-
`wise, cmp__size will return silently. This is to allow you to tell cmp_si:ze how
`much of a change is too small to be interesting (since you don’t necessarily care
`about minor disk usage changes).
`
`cmp_size finds yesterday’s size by grep-mg for the directory name in the data file
`
`Oracle Exhibit 1003, page 5
`
`

`

`"
`echo —-———~—-—~—--———-—--—-———~-———-——«-—-—~--—————~-——~-—-——-—————-
`echo ' '
`mv —f du.log du.sav
`exit 0
`
`u
`
`This script uses a function named du_it to perform the du command and pass its
`output to cmp_size using xargs. The function takes four arguments:
`the cutoffs
`for old and new directories (for cmp_size), the starting directory for the du com—
`mand, and any additional flags to pass to du (optional).
`
`du_it saves du’s output into a temporary file, dutmp, which it appends to the file
`du.log afterwards. dialog thus accumulates the data from multiple directory
`checks and will eventually become the new saved data file, replacing yesterday’s
`version.
`
`The script proper begins by removing any old temporary files from previous runs
`and making sure its data file (still hardwired as du.sav) is available.
`It then runs
`df and prints some header lines for the output from cmp_size. This version of the
`script then calls du_z't three times:
`
`du_it: 40 100 Iiago/home/martin
`du_it 1 1 lusr/lib
`clu__it 1 1000 /u/\* —s
`
`to the saved data for the directories
`It will run du and compare its output
`/iag0/home/martin, lusr/Iib, and all of the subdirectories of la, passing the chi
`command the -s option in the latter case.
`In the third command, the wildcard is
`passed through to the actual du command line by quoting it to duJ‘t. Different
`cutoffs are used for each call. When checking /usr/lib, this version asks to be told
`about any change in the size of any directory (size or size change greater than or
`equal to one).
`In contrast, when checking the users’ home directories under /u,
`the report will include new directories of any size but only existing directories
`that changed size by at least 1000 blocks.
`
`ckdsk ends by moving the accumulated output file, dulog, on to the saved data
`file, du.sav, saving the current data for future comparisons.
`
`Here is some sample output from ckdsk:
`
`Daily disk usage report for Tue Jul 30 09:52:46 nor 1991
`
`
`
`from the larger. cmpfisize then compares the size difference to the old directory
`cutoff (passed in as its second argument), and displays the old and new sizes if it
`15 large enough.
`
`This version of cmp_sz'ze reports on directories that either increased or decreased
`in Size by the amount of the cutoff. If you are only interested in size increases,
`you could replace the if statement which computes the difi' variable with a much
`simpler one:
`if [ Sosize -le $csize ]
`then
`exit 0
`else
`diff=‘expr sosize — $csize‘
`
`# only care if it’s bigger
`
`fi
`
`Unlike the simple version of ckdsk, cmp__size is fairly general; it could also be
`used, for example, to process output from the quot command (described in “quot:
`gepkosrt Usage by User (BSD, XENIX, and V.4),” in Chapter 8, Filesystems and
`IS
`.
`
`One way to make ckdsk more useful is to enable it to check more than one start-
`ing directory, with different cutoffs for each one. Here is a version which can do
`that:
`
`#l/bin/sh
`du__it()
`ll
`
`{#
`
`cutoff in blocks for new directories
`$1
`# $2 a cutoff as block change for old directories
`# $3 = starting directory; $4 = flags to do
`du $4 $3 > du.tmp
`cat dummy 1 xargs -n2 carip_size $1 $2 du.sav
`cat du.tmp >> du.log; m du.tmp
`
`} u
`
`mask 077
`rm -f 611.109 du.tnp 2>il >/dev/null
`if [
`! -s du.sav }
`; then
`echo “run_cmp: can't find old data file."
`exit 1
`
`
`
`Oracle Exhibit 1003, page 6
`
`

`

`
`
`new
`2000
`new
`355
`34323
`9834
`new
`
`52
`1012
`912
`356
`32797
`32 14
`300
`
`liago/home/martin/test
`liege/hatte/mmttin
`lusr/ lib/acct.bio
`I’usr/lib/spell
`Ill/Chavez
`lufng
`lu/paxk
`
`The echo commands set off the output from cmp‘size and make it easy to scan.
`
`This version of ckdsk requires new du commands to be added by hand. The script
`could be refined further by allowing this information to be external as well. Simi—
`larly, the script currently checks all users’ home directories. If only some of them
`need to be checked, th
`th
`.
`this one:
`en
`6 final du command could be replaced by a loop like
`for user in Chavez have]. martin ng smith tedesco ‘ do
`du_it 1 1000 lu/suser -s
`'
`done
`
`The cron facility is also the most sensible way to run ckdsk; we’ll look at how it
`might do so in the section entitled “Execution Scheduling,” later in this chapter.
`
`
`
`eron is a UNIX facility that allows you to schedule programs for periodic execu-
`tion. For example, you can use cron to call a particular uucp site every hour, to
`clean up editor backup files every night, or to perform any number of other tasks.
`Under cron, administrative functions are performed silently, without any inter-
`vention‘by the system’s users. However, cron is not a general facility for
`scheduling program execution off-hours; for the latter, use the at command.
`
`For administrative purposes, cron is useful for running commands and scripts
`according to a preset schedule. cron can send their output to a log file or to any
`username Via the mail system.
`
`
`
`files, all cron scheduling must go through the system administrator. This can be
`either an advantage or a disadvantage, depending on the needs and personality of
`your site.
`
`Under System V (and ATX 3.1, XENIX, and SunOS), any user may add entries to
`the cron schedule. Crontab entries are stored in separate files for each user in the
`directory ,/usr/spool/cron/crantabs
`(or
`/var/spool/cron/crontab5 for V4 and
`SunOS); users’ crontab files are named after their username (for example, root’s
`crontab file is ,lusr/spool/cmn/crantabs/raot). The crontab files are not edited
`directly by ordinary users, but are placed there with the crontab command
`(described later in this section).
`
`crontah entries direct cron to run commands at regular intervals. Each one-line
`entry in the crontab file has the following format:
`mills hrs day-of—month month weekday username cmd
`mins hrs day-of—month month weekday cmd
`
`(BSD)
`(System V)
`
`Spaces separate the fields. However, the final field, cmd, can contain spaces
`within it (i.e., the cmd field consists of everything after the space following week,
`day); the other fields must not contain spaces. The username field is used in the
`BSD version only and specifies the username under which to run the command.
`Under System V, commands are run by the user who owns the crontab in which
`they appear (and for whom it is named).
`
`The first five fields specify the times at which cram should execute cmd. Their
`meanings are described in Table 6-1.
`
`Table 6-1. Crontab Entry Time Fields
`
`
`
` Field Meaning Range
`
`
`
`mins
`hrs
`day—of—month
`month
`weekday
`
`The minutes after the hour.
`The hours of the day.
`The day within a month.
`The month of the year.
`i The day of the week.
`
`059
`0—23 (0 = midnight)
`1-31
`1—12
`1—7 (1 = Monday) BSD
`0-6 (0=Sunday) System V
`
`=
`
`Oracle Exhibit 1003, page 7
`
`

`

`
`
`If the first character in an entry is a number sign (#), cron will treat the entry as a
`comment and ignore it. This is an easy way to temporarily disable an entry with-
`out permanently deleting it.
`
`Here are some example crontab entries (shown in System V format):
`30,45 * * * *
`(echo «n '
`'; date; echo "") >/dev/console
`,20,30,40,50 7—18 * * * /usr/lib/atrun
`* 4* *
`find / -name "hbak" -type f -atime +7 oexec m {} \;
`* * ' kin/sh lusrlam/ckdsk 2>&1 >lusr/adm/disk.log
`i' * *
`ibin/sh lust/adulckpwd 2>51 I mail root
`3O 3 * * l [bin/cab /uar/1ib/uucp/uu.week1y 2>&1 >/dev/null
`#30 2 * * 0,6 /usr/lib/newsbin/news.weekend
`
`The first entry displays the date on the console terminal every fifteen minutes (on
`the quarter hour); notice that multiple commands are enclosed in parentheses in
`order to redirect their output as a group.
`(Technically, this says to run the com»
`mands together in a subshell.) The second entry runs lusr/lib/atmn every ten
`minutes from 7:00 am.
`to 6:00 pm. daily. The third entry runs a find command
`to remove all .bak files not accessed in seven days.
`
`The fourth and fifth lines run a shell script every day, at 4:00 am. and 2:00 am,
`respectively. The shell to execute the script is specified explicitly on the com-
`mand line in both cases; the system default shell, usually the Bourne shell, is used
`if none is explicitly specified. Both lines’ entries redirect standard output and
`standard error, sending it to a file in one case and mailing it to root in the other.
`
`The sixth entry executes a C shell script named uu.weekly, stored in lusr/lib/uucp,
`at 3:30 am. on Monday mornings. Notice that the command format—specifi—
`cally the output redirection—4s for the Bourne shell even though the script itself
`will be run under the C shell. The final entry would run the command
`/usr/lib/newsbin/news.weekend at 2:30 am. on Saturday and Sunday mornings if
`it were not disabled.
`
`three active entries illustrate three output-handling alternatives:
`The final
`redirecting it to a file, piping it through mail, and discarding it to /dev/null. If no
`output redirection is performed, the output is sent via mail to the user who ran the
`command.
`
`If the command contains a percent sign (0/0), cron will use any text following this
`sign as standard input for cmd. Additional percent signs can be used to subdivide
`this text into lines. For example, the following crontab entry:
`30 11 31 12 * /etc/wall%Happy New Year!%let's make next year great!
`
`runs the wall command at 11:30 am. on December 3lst, using the text:
`
`Happy New Year!
`Let's make next year great!
`
`as standard input. This entry also illustrates how cron makes use of the date fields
`under BSD. On these systems, if both the date in the month and day of the week
`are specified, then the crontab entry is only run when that date falls on one of the
`specified days of the week.
`
`By contrast, on System V—based systems and under SunOS, the day of the week
`and day of the month fields are effectively OR’ed: if both are filled in, then the
`entry is run on that day of the month and on matching days of the week. Thus,
`the following entry would run on January first and every Monday on these sys-
`tems:
`
`* * 1 1 1 lusr/local/bin/testSS
`
`crrm reads the crontab file(s) every minute to see whether or not there have been
`changes. Therefore, any change to its schedule will take effect within one min—
`utc.
`
`The area command starts the area program. It has no options. Once started, cron
`never terminates.
`It is normally started automatically by one of the system mitlal-
`ization scripts.
`
`Adding Crontab Entries
`
`Under BSD, new crontab entries are created simply by editing one of the crontab
`files. Either crontab file may be used, although non—system—related entries may be
`separated out into the crontablocal file if desired.
`
`Under System V, AIX 3.i, XENIX, and SunOS, the normal way to create crontab
`
`
`
`Oracle Exhibit 1003, page 8
`
`

`

`
`
`user Chavez executes the command below, the tile mycron will be installed as
`/usr/Spool/cron/cr0rttabs/Chavez :
`S crontab mycron
`
`If Chavez had previously installed crontab entries, they will be replaced by those
`in mycron;
`thus, any current entries that Chavez wishes to keep must also be
`present in mycron.
`
`The -l option to crontab lists the current crontab entries, and redirecting its output
`to a file will allow them to be captured and edited?
`5 crontab -1 >mycron
`5 vi mycron
`$ crontab mycron
`
`The —r option will remove all current crontab entries. Under SunOS, crontab has
`an additional -e option which lets you directly edit your current crontab entries in
`a single step.
`
`The preceding discussion describes the normal, officially recommended way of
`creating crontab entries, a somewhat
`tedious process (except under SunOS).
`However, the files in the cron spool area are just plain ASCII files. Users can’t
`edit them directly, but you can as root, greatly speeding up changing them for
`administrative purposes.
`
`Under both System V and BSD, the system administrator must consider what user
`should execute each command run by cron. Under BSD, the sixth field of a cron—
`tab entry is the username under which to run the command. Under System V,
`crontab entries must be added to the correct crontab file. The following list des—
`ribes common system users and the sorts of crontab entries they conventionally
`control:
`
`root
`
`adm
`
`General system functions and filesystem cleanup.
`
`Accounting.
`
`uucp
`
`uucp scripts.
`
`The System V cron Log File
`
`Under System V and XENIX, cron will keep a log of its activity if the variable
`CRONLOG is set to YES in the file letc/default/cron:
`GONIDG—“YES
`
`Logging will be sent to the file /u$r/lib/cron/log under V3 and XENIX and to the
`file /usr/sbin/cron.d/log under VA. Under some System V versions, logging is
`automatic (and there is no CRONLOG variable). Under AIX 3.1, logging is auto-
`matic and goes to the file lusr/adm/cron/log. If logging is enabled, this file should
`be periodically truncated, as it grows extremely quickly.
`
`Using cron to Automate System Administration
`
`The sample crontab entries we looked at previously provide some simple
`examples of using cron to automate various system tasks. cron provrdes the ideal
`way to run scripts like ckpwd and ckdsk according to a fixed schedule.
`
`Another common way to use cron for regular administrative tasks is through the
`use of a series of scripts designed to run every night, once a week, and once'a
`month, often named daily, weekly, and monthly, respectively. The commands in
`daily would need to get done every night (more specialized scripts ckpwd and
`ckdsk could be run from it); the other two would handle tasks to be performed less
`frequently.
`
`Here are examples of what each one might do:
`
`' Daily:
`
`~— Remove junk files more than 3 days old from ltmp and other scratch
`directories.
`
`- Run accounting summary commands.
`
`—— Run calendar.
`
`M Rotate log files cycled daily.
`
`
`
`Oracle Exhibit 1003, page 9
`
`

`

`
`
`—— Rebuild the catman database for use by man -k.
`
`—— Run fsck -n to list any disk problems.
`
`~ Monthly:
`
`~ List files not accessed that month.
`
`~— Produce monthly accounting reports.
`
`—— Rotate log files cycled monthly.
`
`Additional or other activities might make more sense on your system. The scripts
`might be run late at night:
`
`0 3 * * *
`0 2 * * l
`0 1 1 * *
`
`2>&1 I mil root
`lbiri/sh lusr/adm/daily
`/bin/sh lust/adm/weekly 2>&1 I mail root
`lbin/sh mar/ackn/monthly 2>&1 I mail root
`
`In this example, the daily script runs every night atg3:00 a.m., weekly runs every
`Monday at 2:00 am, and monthly runs on the first day of every month at 1:00
`a.rn.
`
`cron need not only be used for tasks to be performed periodically forever, year
`after year.
`It can also be used to run a command repeatedly over a limited period
`of time, after which the crontab entry would be disabled or removed. For
`example, if you were trying to track certain kinds of security problems, you might
`want. to use cron to run a script repeatedly to gather data. As a concrete example
`consrder this short script
`to check for large numbers of unsuccessful
`logitl
`attempts under AIX 3.1 (although the script applies only to AIX 3.1, the general
`princrples are useful on all systems):
`#! /bin/sh
`date >> lusr/adm/bl
`egrep "["*]-*:$Igin_coun' /etc/security/user I \
`awk 'BEGIN {n=0}
`(if (m1 as $3>3) {print 5,30; n=1)}
`{5:50}
`END {if (n=0) {print "Everything ok.“}}' \
`>> lust/adm/bl
`
`Similarly, if you are having a performance problem, you could use cmn to auto-
`matically run various system performance monitoring commands at regular inter-
`vals to track performance problems over time.
`
`cron Security issues
`
`cron’s security issues are of two main types: making sure the system crontab files
`are secure, and making sure unauthorized users don’t run commands using it. The
`first problem may be addressed by setting (if necessary) and checking the owner—
`ship and protection on the crontab files appropriately. (In particular, they should
`not be world-writable.) Naturally,
`they should be included in any filesystcm
`security monitoring that you do. Addressing the second problem is the subject of
`the next section.
`
`Limiting Access to cron Under System V, XENIX, and SunOS
`
`The files cron.allow and crowdeny," stored in lusr/spool/cron under V3,
`lvar/spool/cron under SunOS, /usr/lib/cron under XENIX, /usr/adm/cron under
`AIX 3.1, and late/cram! under v.4, enable you to restrict access to cran. Both
`files contain lists of usernames, one per line. Access to arm: is controlled in the
`following way:
`
`'
`
`‘
`
`If cron.allow exists, then a username must be listed within it in order to access
`cron.
`
`If cron.allow does not exist and cron.deny exists, then any user not listed in
`cron.deny may access cran. cramdeny may be empty to allow unlimited
`access to cran.
`
`’
`
`if neither file exists, then only root may access cron.
`
`Under BSD, access to cron is controlled solely via the protection on the crontab
`files. Thus, it is imperative that they be owned by root and not writable by any-
`one other than the owner. They should be includcd in any filesystem security
`monitoring that you do.
`
`
`
`Oracle Exhibit 1003, page 10
`
`