In the last article, we started looking at the scripts that are run by
periodic program. Let's finish looking at the remaining scripts in
We left off at the accounting script. System accounting is off by default,
so disable this script if you don't plan on enabling system accounting. If
you're not sure what system accounting does,
man sa gives a list of what
statistics will be gathered. If you decide to enable system accounting,
YES and keep an eye on your
daily_accounting_enable="YES" # Rotate acct files
daily_accounting_compress="NO" # Gzip rotated files
daily_accounting_flags=-q # Flags to /usr/sbin/sa
daily_accounting_save=3 # How many files to save
This is another script that deals with
rdist, so if you're not maintaining identical copies of files over multiple hosts, disable it.
daily_distfile_enable="YES" # Run rdist daily
You should disable the news script; even if you are running a news server, it should have a built-in mechanism to handle expired news articles.
# 330.news daily_news_expire_enable="YES" # Run news.expire
Now we get to some UUCP stuff. There are three scripts that deal with UUCP, so I'll lump them together and talk about them at the same time. Scripts 340 and 410 are found in the daily section and script 300 is found in the weekly section:
# 340.uucp daily_uuclean_enable="YES" # Run uuclean.daily # 410.status-uucp daily_status_uucp_enable="YES" # Check uucp status # 300.uucp weekly_uucp_enable="YES" # Clean uucp weekly
Unfortunately, the UUCP program has been prone to several vulnerabilities
over the years, and just happens to be the subject of the latest security
advisory, FreeBSD-SA-01:62. It is a very good idea to disable the three scripts
that deal with UUCP. Furthermore, if you don't have a need to use the
cu utilities, you don't even need UUCP on your system. Follow the directions
in section IV of the advisory to see which binaries to remove and how to
prevent rebuilding these binaries when you remake your system.
# 400.status-disks daily_status_disks_enable="YES" # Check disk status daily_status_disks_df_flags="-k -t nonfs# df(1) flags for check
You'll probably want to keep the disk status script enabled, and you should
check its output on a daily basis to ensure you are not running out of disk
space. Note that you can change the flag line to include the switches you
prefer to pass to the
df utility. Since I don't use NFS and I like to keep
track of my free inodes and see the output in human readable format, my
line looks like this:
daily_status_disks_df_flags="-h -i# df(1) flags for check
Which gives me this output:
instead of the default output, which would look like this:
The first line in the network status script runs the
netstat utility; if
you don't want the script to resolve IP addresses to network names, change the
second line to
NO. It's up to you to decide if the output of this script
is useful enough to you to warrant keeping it enabled.
# 420.status-network daily_status_network_enable="YES" # Check network status daily_status_network_usedns="YES" # DNS lookups are ok
The output of the next script depends on whether or not the
is running. If it is not, it will show the uptime of your local system; if
it is, it will show the uptime for each machine in your LAN.
# 430.status-rwho daily_status_rwho_enable="YES" # Check system status
The next script runs
mailq, the output of which will let you know if there is
any mail stuck in the queue.
# 440.status-mailq daily_status_mailq_enable="YES" # Check mail status daily_status_mailq_shorten="NO" # Shorten output
The security script is probably the most important script run by
periodic, and its output should be checked on a daily basis. You'll note
that the output is mailed separately from the rest of the daily output
scripts, and can be mailed to a different user (the default user is root).
Also, keep the inline line set at
NO; if you set it to
YES, it will be
sent to the terminal instead of to a user. You do want a trusted user to
read this output on a daily basis, in case further investigation is
# 450.status-security daily_status_security_enable="YES" # Security check daily_status_security_inline="NO" # Run inline ? daily_status_security_output="root" # user or /file daily_status_security_noamd="NO" # Don't check amd mounts daily_status_security_nomfs="NO" # Don't check mfs mounts
The security check runs a script called
/etc/security. This script
checks for well-known vulnerabilities, meaning that anything in its output
should be looked at to ensure your system hasn't been compromised. If you
are new to security and aren't familiar with all of the terms mentioned in
man security is a good place to start. For additional
resources, the following URLs also have general security information:
Let's take a quick look at the checks that are run as part of the daily security output:
Also in FreeBSD Basics:
Setuid files are one of the oldest known vulnerabilities in Unix systems.
Fortunately, your FreeBSD system keeps a list of which files are
first thing the security check does each night is to see if there are any
differences between these two files; that is, it can notify you if a new
setuid file shows up on your system. If it does, you want to be aware of
uids of 0
By default, the only users on your system that have a UID of 0 are root and toor. An UID of 0 means that that user has root access to your FreeBSD system, so you should be VERY suspicious is a new user shows up under this section of the output.
We all know that user accounts without passwords are a bad thing. The daily security output will notify you if any passwordless accounts show up so you can rectify the situation.
Packets denied by ipfw
Remember how we took a look at
ipfw's logs in
IPFW Logging? This
portion of the security script will check
/var/log/ipfw.today for you
and give you the stats on how many packets were rejected for each of your
logged deny rules.
ipfw rules that have reached the log limit
This portion of the script will tell you which IPFW rules reached their logging limits.
ipv6 packets denied by ip6fw
ipv6 rules which reached ip6fw's log limit
Kernel log messages
This portion of the script will show the contents of
meaning it will show the system messages.
tcp_wrapper warning messages
If you've configured
tcp wrappers, any warning messages will be recorded
for you. If you don't know how to configure this program, see Securing
Leaving the security script, let's move on to the next script, which will show you if any mail was rejected.
# 460.status-mail-rejects daily_status_mail_rejects_enable="YES" # Check mail rejects daily_status_mail_rejects_logs=3 # How many logs to check
The status-named script can be disabled if you are not running a DNS server. If you are running a DNS server, check the output of this script, as it will let you know if your DNS server denied any zone transfers. A zone transfer request from a machine that is not one of your secondary DNS servers may indicate that someone is trying to gather information about your network. For more information on setting up a secure DNS server, you can read the security chapter of DNS and Bind, 4th Edition.
# 470.status-named daily_status_named_enable="YES" daily_status_named_usedns="YES" # DNS lookups are ok
The next script ensures that
sendmail's queue is processed at least once
per day. You don't have to run this script, as by default
check its queue every 30 minutes for undeliverable mail and will try to
resend any messages at that point.
# 500.queuerun daily_queuerun_enable="YES" # Run mail queue
That's it for the built-in daily scripts; let's move on to the weekly scripts. You'll note that you're once again given the option to specify where to send the weekly output, and again, the default is to email it to root.
# Weekly 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. $weekly_output # might be set to /var/log/weekly.log if you wish to log the # weekly output and have the files rotated by newsyslog(8) # weekly_output="root" # user or /file weekly_show_success="YES" # scripts returning 0 weekly_show_info="YES" # scripts returning 1 weekly_show_badconfig="NO" # scripts returning 2
The first script cleans out any
kvm* files in
/var/db. Since I don't
have any of these files on my system, I've disabled this script.
# 120.clean-kvmdb weekly_clean_kvmdb_enable="YES" # Clean kvmdb weekly weekly_clean_kvmdb_days=7 # If not accessed for weekly_clean_kvmdb_verbose="YES" # Mention files deleted
The next two scripts update the
whatis databases; if you've
ever heard your hard drive churning around 4:00 on a Saturday morning,
this is the reason why. Since
apropos are two of my
favorite commands, I keep these scripts enabled.
# 310.locate weekly_locate_enable="YES" # Update locate weekly # 320.whatis weekly_whatis_enable="YES" # Update whatis weekly
The next script is disabled by default; if you have lots of disk space and
read a lot of
man pages, you may find that enabling this script speeds up using
# 330.catman weekly_catman_enable="NO" # Preformat man pages
The next script is also disabled. Enable it if you want to be aware of any files on your system that don't have a valid owner or group.
# 340.noid weekly_noid_enable="NO" # Find unowned files weekly_noid_dirs="/" # Look here
The last built-in weekly script is interesting, and may be worth enabling
if you like to keep up-to-date with the ports tree. It will compare your
already installed ports with
/usr/ports/INDEX and make a list of which ports
have a newer version number and should be updated.
# 400.status-pkg weekly_status_pkg_enable="NO" # Find out-of-date pkgs
There is only one built-in monthly script and you are again given the option of where to send its output.
# Monthly 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. $monthly_output # might be set to /var/log/monthly.log if you # wish to log the monthly output and have the files rotated # by newsyslog(8) # monthly_output="root" # user or /file monthly_show_success="YES" # scripts returning 0 monthly_show_info="YES" # scripts returning 1 monthly_show_badconfig="NO" # scripts returning 2 # 200.accounting monthly_accounting_enable="YES" # Login accounting
This script will show the accounting statistics gathered by the
ac command. If these statistics aren't useful to you, disable this script.
We took a look at the
ac command in Monitoring Unix Logins.
I hope this article helped to de-mystify the scripts that came with your FreeBSD system. Until next time, happy BSDing.
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 © 2017 O'Reilly Media, Inc.