ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


FreeBSD Basics

Understanding the Automatons

11/08/2001

Last year, we took a look at the cron utility in Getting Cron To Do Our Bidding. In the next two articles, I'd like to take a closer look at the actual periodic scripts that cron calls to be executed on a daily, weekly, and monthly basis.

It's always a good idea to be aware of what scripts are running on your computer. Scripts, after all, do stuff that make them a double-edged sword. On the plus side, they can keep you posted on the overall health of your computer and take care of routine housekeeping tasks for you. With the built-in scripts, you don't have to know how to write a shell script in order to perform routine tasks as your FreeBSD system comes with many pre-made scripts that are automatically run for you. On the negative side, any script can be vulnerable to exploits by malicious users. Just as you shouldn't run services on your computer that you don't need, you should only run the scripts that are useful to you and disable the ones you don't need.

The scripts themselves are found in /etc/periodic and are placed in the appropriate subdirectory depending on whether they will be run daily, weekly, or monthly:

ls -F /etc/periodic
./		monthly/
../		weekly/
daily/

Each script begins with a number to indicate the order in which the scripts in that directory will be run. That is, a script beginning with the number "120" will run before the script beginning with the number "300". Also, these scripts are executable files as indicated by the * in the output of ls -F:

ls -F /etc/periodic/weekly
./			320.whatis*
../			330.catman*
120.clean-kvmdb*	340.noid*
300.uucp*		400.status-pkg*
310.locate*		999.local*

Finally, these are Bourne shell scripts (that is, they all begin with the line #!/bin/sh) meaning you can test the output of any of these scripts by running it with sh like so:

cd /etc/periodic/daily
sh 430.status-rwho

Local system status:
 8:25AM up 19 days, 21:34, 7 users, load averages: 0.41, 0.38, 0.29

You may remember that cron uses the system crontab file to determine when the scripts in each directory are to be run. I'll show the relevant output here:

more /etc/crontab
<snip>
# do daily/weekly/monthly maintenance
1	3	*	*	*	root	periodic daily
15	4	*	*	6	root	periodic weekly
30	5	1	*	*	root	periodic monthly
<snip>

That is, cron is told to call a program named periodic to run the desired daily scripts every morning at 3:01, the desired weekly scripts every Saturday morning at 4:15, and the desired monthly scripts at 5:30 in the morning on the first day of each month. The periodic program has its own separate configuration file called periodic.conf which is used to specify which of the daily, weekly, and monthly scripts you want to be included in the run, and which you wish to disable.

Your FreeBSD system comes with a default periodic.conf file; let's take a look at the top portion of that file:

head -20 /etc/defaults/periodic.conf
#!/bin/sh
#
# This is defaults/periodic.conf - a file full 
# of useful variables that you can set to change 
# the default behaviour of periodic jobs on your
# system.  You should not edit this file!  Put any 
# overrides into one of the $periodic_conf_files 
# instead and you will be able to update these defaults
# later without spamming your local configuration 
# information.
#
# The $periodic_conf_files files should only contain 
# values which override values set in this file.  This 
# eases the upgrade path when defaults are changed and 
# new features are added.
#
# $FreeBSD: src/etc/defaults/periodic.conf,v 1.7.2.8 
#   2001/07/28 11:44:22 brian Exp $
#
# What files override these defaults ?
periodic_conf_files="/etc/periodic.conf /etc/periodic.conf.local"
# periodic script dirs
local_periodic="/usr/local/etc/periodic /usr/X11R6/etc/periodic"
This file makes it pretty clear that you should not make any changes to it and offers two locations to store your own customized version of periodic.conf. If you try to find the files that override the defaults, you'll see that they don't exist as it is up to you to create them:
more /etc/periodic.conf
/etc/periodic.conf: No such file or directory
more /etc/periodic.conf.local
/etc/periodic.conf.local: No such file or directory

Before you start making your customized file, it is a good idea to know what each script does so you can decide whether or not you want it to be executed by the periodic program.

Let's take a quick look at each script, what it does, and whether or not it runs by default. These details are described in man periodic.conf which I've summarized in the following chart:

Name of script Action Default
Daily scripts:
100.clean_disks removes all matching files NO
110.clean_tmps clears temporary directories NO
120.clean_preserve removes old files from /var/preserve YES
130.clean_msgs old system messages purged YES
140.clean_rwho old files in /var/rwho purged YES
150.clean_hoststat old files in /var/spool/.hoststat purged. YES
200.backup_passwd /etc/master.passwd and /etc/group files backed up and modifications reported YES
210.backup_aliases /etc/mail/aliases file backed up and modifications displayed YES
220.backup_distfile /etc/Distfile file backed up and modifications displayed YES
300.calendar runs calendar -a daily NO
310.accounting rotates daily accounting files YES
320.distfile runs rdist(1) daily YES
330.news runs /etc/news.expire YES
340.uucp runs /etc/uuclean.daily YES
400.status_disks runs df(1) and dump -W YES
410.status_uucp runs uustat -a YES
420.status_network runs netstat -i YES
430.status_rwho runs uptime(1) YES
440.status_mailq runs mailq(1) YES
450.status_security runs /etc/security YES
460.status_mail_rejects summarizes mail rejections logged to /var/log/maillog YES
470.status_named summarizes denied zone transfers YES
500.queuerun manually runs the mail queue YES
999.local list of extra scripts in /etc/daily.local  
Weekly Scripts
120.clean_kvmdb purges old /var/db/kvm_*.db files YES
300.uucp runs /usr/libexec/uucp/clean.weekly YES
310.locate runs /usr/libexec/locate.updatedb YES
320.whatis runs /usr/libexec/makewhatis.local YES
330.catman runs /usr/libexec/catman.local NO
340.noid locate files with an invalid owner or group (orphans) NO
400.status_pkg uses pkg_version(1) to list out of date installed packages NO
999.local list of extra scripts in /etc/weekly.local  
Monthly Scripts
200.accounting does login accounting using the ac(8) command YES
999.local list of extra scripts in /etc/monthly.local  

You'll notice that there are quite a few scripts and most of them are enabled by default. Let's become the superuser and copy the default file to the file that we'll customize:

su
Password:
cp /etc/defaults/periodic.conf /etc/periodic.conf

I'll then open up /etc/periodic.conf in my favorite text editor and pick through the interesting lines. Let's start with this bit:

<snip>
# Daily options
# These options are used by periodic(8) itself to 
# determine what to do with the output of the sub-programs
# that are run, and where to send that output.  $daily_output
# might be set to /var/log/daily.log if you wish to log the 
# daily output and have the files rotated by newsyslog(8)
#
daily_output="root"         # user or /file
daily_show_success="YES"    # scripts returning 0
daily_show_info="YES"       # scripts returning 1
daily_show_badconfig="NO"   # scripts returning 2

You'll note that by default, the results of running the daily scripts are emailed to root. If you check root's email, you'll see messages with the subject "hostname daily run output" and if you read one of those messages, the output should match up to the daily scripts that are marked as "YES". You can have the output sent to another user by replacing "root" with a user name on the "daily_output" line.

Alternatively, you can specify that the output be sent to a file, usually /var/log/daily.log. This file doesn't exist by default, so you'll want to create it by using touch /var/log/daily.log.

Let's continue by taking a look at the daily scripts. You'll note there is a logic to the layout of the scripts: The first scripts clean out old files, these are followed by backup scripts, which are followed by scripts which run some useful utilities.

# 100.clean-disks
daily_clean_disks_enable="NO"      # Delete files daily
daily_clean_disks_files="[#,]* .#* a.out *.core *.CKP .emacs_[0-9]*"
daily_clean_disks_days=3           # If older than this
daily_clean_disks_verbose="YES"    # Mention files deleted

This script is disabled by default but you may want to consider enabling it if disk space is an issue on your system. If you do enable this option, backup your important files first and check the output to ensure this script didn't delete any files you were attached to. This is especially important if you decide to add your own extensions to the files list.

The next script is also disabled by default and may be worth enabling if disk space is an issue:

# 110.clean-tmps
daily_clean_tmps_enable="NO"      # Delete stuff daily
daily_clean_tmps_dirs="/tmp"      # Delete under here
daily_clean_tmps_days="3"         # If not accessed for
daily_clean_tmps_ignore=".X*-lock quota.user quota.group" 
    # Don't delete these
daily_clean_tmps_verbose="YES"    # Mention files deleted

Related Reading

UNIX Power ToolsUNIX Power Tools
By Jerry Peek, Tim O'Reilly & Mike Loukides
Table of Contents
Index
Full Description

Before enabling the clean-tmps script, you should be aware that there is a security advisory regarding this script which may affect you, depending on which version of FreeBSD you are running. If you're not yet aware of FreeBSD's security advisories (SAs), you should bookmark and spend some time reading this site.

And, as mentioned at this URL, subscribe to one of the mailing lists that the security advisories are sent to so you will be aware of any new exploits as they are found and fixed. The security advisory that deals with this particular script is FreeBSD-SA-01:40.fts.v1.1.asc.

The next script cleans out /var/preserve. If you don't know what a directory does on your FreeBSD system, man hier is the best place to look. Here I'll search that man page for the word "preserve":

man hier
/preserve
preserve/  temporary home of files preserved after 
           an accidental death of an editor; see (ex)1

Now that you know what preserve is for, you can decide whether or not to keep this script enabled.

# 120.clean-preserve
daily_clean_preserve_enable="YES"   # Delete files daily
daily_clean_preserve_days=7         # If not modified for
daily_clean_preserve_verbose="YES"  # Mention files deleted

The next script cleans out messages sent by the msgs utility. If you don't use this utility, you can disable this script as there won't be any messages to delete. If you're not sure if you're using this utility, you probably aren't, but you can doublecheck by reading man msgs.

# 130.clean-msgs
daily_clean_msgs_enable="YES"   # Delete msgs daily
daily_clean_msgs_days=          # If not modified for

For the next script, it is again helpful to read the man page for the utility, in this case rwho. If your FreeBSD computer is not hooked up to a Unix LAN, you can disable this script as /var/rwho will always be empty.

# 140.clean-rwho
daily_clean_rwho_enable="YES"   # Delete rwho daily
daily_clean_rwho_days=7         # If not modified for
daily_clean_rwho_verbose="YES"  # Mention files deleted

You may or may not have a hoststat on your computer. To see why, check out this thread.

I don't, so I've disabled this script on my computer.

# 150.clean-hoststat
daily_clean_hoststat_enable="YES"   # Delete .hoststat daily
daily_clean_hoststat_days=3         # If not modified for
daily_clean_hoststat_verbose="YES"  # Mention files deleted

Now we get to the three backup scripts. You definitely want your password and group files backed up daily. This script not only backs them up, it will also report if either of those two files had any changes made to them that day. The output of this script should be checked on a daily basis.

# 200.backup-passwd
daily_backup_passwd_enable="YES"  # Backup passwd & group

It is a good idea to have a backup of your mail aliases file; whether or not you want to have it backed up daily is up to you.

# 210.backup-aliases
daily_backup_aliases_enable="YES"  # Backup mail aliases

Unless you are using rdist to maintain identical copies of files over multiple hosts, you won't have an /etc/Distfile and you can disable the script that backs it up.

# 220.backup-distfile
daily_backup_distfile_enable="YES"  # Backup /etc/Distfile

The calendar utility is interesting, but not enabled by default. If you like the fortune program and enjoy reading trivia, you might consider running the calendar program. There are a few steps involved in setting up calendar.

First, decide which calendar file you think you or your users would enjoy reading. The possible files are found in /usr/share/calendar:

cd /usr/share/calendar
ls -F .
./				calendar.holiday
../				calendar.judaic
calendar.all			calendar.music
calendar.birthday		calendar.russian
calendar.christian		calendar.usholiday
calendar.computer		calendar.world
calendar.croatian		de_DE.ISO_8859-1/
calendar.german			hr_HR.ISO_8859-2/
calendar.history		ru_SU.KOI8-R/

Each of the files are in plain text so you can safely send them to a pager to see their contents or edit the contents as you wish. Some calendar files contain the actual trivia:

more calendar.computer
<snip>
01/01&bnsp; AT&T officially divests its local Bell companies, 1984
01/01&bnsp; The Epoch (Time 0 for UNIX systems, Midnight GMT, 1970)
01/03&bnsp; Apple Computer founded, 1977
01/08&bnsp; American Telephone and Telegraph loses antitrust case, 1982
01/08&bnsp; Herman Hollerith patents first data processing computer, 1889
01/08&bnsp; Justice Dept. drops IBM suit, 1982
01/10&bnsp; First CDC 1604 delivered to Navy, 1960
01/16&bnsp; Set uid bit patent issued, to Dennis Ritchie, 1979
01/17&bnsp; Justice Dept. begins IBM anti-trust suit, 1969 (drops it, 01/08/82)
01/24&bnsp; DG Nova introduced, 1969
<snip>

While other calendar files are used to specify which trivia files to include:

more calendar.all
<snip>
#include <calendar.world>
#include <calendar.german>
#include <calendar.usholiday>
#include <calendar.croatian>
#include <calendar.russian>
<snip>

Any user aware of this directory can see what trivia is suited to today's and tomorrow's date by invoking the desired calendar file with the f switch like so:

calendar -f calendar.birthday
Nov  4 	King William III of Orange born, 1650
Nov  5 	Roy Rogers born, 1912

By default, if a user isn't in this directory or doesn't specify the full path name to the desired calendar file, they'll receive this error message:

cd
calendar -f calendar.birthday
calendar: no calendar file: ''calendar.birthday'' or ''~/.calendar/calendar.birthday

To fix this, tell the user to create a directory in their home directory and to copy the desired calendar file(s) to it:

cd
mkdir .calendar
cp /usr/share/calendar/calendar.world .calendar/calendar

I like calendar.world as it includes birthdays, computer, music, history, and holidays. Since I've saved the file as "calendar", I can now simply type calendar with no arguments, regardless of what directory I'm in:

calendar
Nov  4  King William III of Orange born, 1650
Nov  5  Roy Rogers born, 1912
Nov  4  UNIVAC I program predicts Eisenhower victory based on 7% of votes, 1952
Nov  4  Iranian militants seize US embassy personnel in Teheran, 1979
Nov  4  Soviet forces crush the anti-communist revolt in Hungary, 1956
Nov  5  Guy Fawkes' Plot, 1605
Nov  4  Flag Day in Panama
Nov  4  Will Rogers Day

Which brings us back to the periodic script that deals with calendar. If you enable this script, it will email the customized calendar output to every user who has created a .calendar file in their home directory. As a side note, the superuser can do this at any time. Once you've set up your calendar directory, become the superuser and type:

calendar -a

If you check your email, you'll have a new message with a subject of "Day_of_the_Week Calendar". If your users think this is a cool feature, enable the periodic script and show them how to set up their calendar directory.

# 300.calendar
daily_calendar_enable="NO"   # Run calendar -a

Let's stop here for this week and we'll finish looking at the rest of the periodic scripts in the next article.

Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.


Read more FreeBSD Basics columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.