Chris Stone, coauthor of Mac OS X in a Nutshell
Author's Note -- In Part 1 of this series focusing on using the
Terminal application in Jaguar, you learned how to reschedule default
cron jobs by modifying the system crontab
Here in Part 2, I'll show you how to configure
to email you a report each time it runs one of these jobs.
If you're running Mac OS X 10.1 (or something even older), please see Learning the Mac OS X Terminal: Part 1, which is written for earlier versions on Mac OS X.
First, let's take another look at the pertinent lines in
/etc/crontab. Since you only want to look at the file and
not modify it, you don't need to use a text editor like
pico. Instead, to only display short files like this, use
cat utility, which dumps the entire text file into
your window and exits:
[haru:~] chris% cat /etc/crontab
You might notice a couple of interesting things about this command
line. First, since the permissions for
anyone to read it (but only
root to modify it), using
sudo is not necessary.
Second, this command line allows you to access a file in a directory
other than your working directory by specifying, in this case, the
full (or absolute) pathname to that file. (You didn't first
/etc to open
you did in Part 1.) An absolute path describes the directory hierarchy
from the very top of the file system (the root directory or "/"), down
to the file.
Finally, because some of the
crontab lines might be too
long for your window, you'll need to widen the window by dragging its
lower right corner to the right until all lines fit without wrapping.
Look now at the line specifying the daily
which, depending on how you configured the time segment in Part 1,
looks something like this:
15 3 * * * root periodic daily
Following the first five time fields is the user field. In this case
the user field tells
cron to run the job as if
root were doing it. This is necessary here because these
maintenance procedures require the full access to the system allowed
Following the user field is the sixth and final field, which holds the
actual command line that
cron passes on to a shell to
execute. The heart of the command,
periodic daily, tells
cron to run the
periodic utility with its
A command's arguments are any of the additional bits of text in
the command line, including option flags, that further specify how the
command should behave. In this case,
argument specifies that
periodic run its daily job.
As you'll see more and more as you peer into Mac OS X's Unix
underpinnings, there's a lot of labor sharing among the many
specialized tools included with the system. Typically, for the system
to get a larger job done, a single, small utility will do its part,
and then pass the work on to another tool, which steps in and performs
the job it was designed for. The main duty of
example, is to launch scheduled jobs. Its strength, however, is not in
organizing, prioritizing, or reporting on those jobs (though
cron can do some of these things, and in fact did so in
Mac OS X versions prior to 10.2).
To best handle those facets of the routine maintenance jobs,
cron calls on
periodic, a utility designed
specifically to run such system jobs. In this case, the daily argument
periodic refers to a directory of the same
name. The daily directory exists in
periodic knows to look for executable files to
/etc/periodic/daily, then, are the actual
shell scripts that perform the daily maintenance jobs.
A shell script is a file holding a series of command lines that can be batch-executed by the shell. Much like an AppleScript, a shell script allows you to create and save long automated procedures that you can run at any time using a single command.
If you would like to have a look at the entire contents of the
/etc/periodic directory, you can do so using
ls and its
-R flag (for recursive list), like this:
[haru:/etc/periodic] chris% ls -R /etc/periodic daily monthly weekly /etc/periodic/daily: 100.clean-logs 500.daily /etc/periodic/monthly: 500.monthly /etc/periodic/weekly: 500.weekly
-R option flag, then, displays the contents of
that directory as well as all of its subdirectories and their
contents, completely down through the hierarchy.
As you see, there are three directories in
monthly. Within each of these is at least one shell
script file (
daily has two), whose name begin with a three-digit
number. This number specifies the order that
periodic should run the
scripts, with the lower numbers running first
100.clean-logs will run before
We'll take a closer look at these scripts in Part 3, but the next
steps here are to configure Mac OS X's built-in mail transfer agent
sendmail so it will operate properly, and then configure
periodic so it will email you the output of the scripts
as each is completed.
Mail user agents (MUAs) are those applications that allow you to personally send, receive, and otherwise work with your email messages. Outlook, Eudora, and Mac OS X's Mail application are familiar examples of MUAs.
Mail transfer agents (MTAs), on the other hand, are the
not-so-familiar applications that receive the messages from the MUA
and pass them on to other users on the same machine, or to MTAs on
other machines for ultimate delivery to users elsewhere. The
sendmail MTA included with OS X is one of the most
popular, used on servers large and small across the Internet.
The following procedure will walk you through the steps necessary
sendmail running on your machine so that it will
at least deliver the reports generated by
sendmail to run in an actual server
environment, see this
The first step to getting
sendmail to successfully
launch in Mac OS X is to address a permissions issue. As a security
sendmail will not run with OS X's default
permissions, namely those for the root directory.
Eliminating sendmail Permissions Errors
There are actually two ways to address this issue. The first and
most obvious is to simply change the offending permissions, and allow
sendmail to run. The other, less obvious solution is to
sendmail so it will ignore the somewhat
insecure permissions and run anyway.
The first method involves one simple change: eliminating write
permission for the group assigned to the
directory. The CLI makes it very easy to view and change the various
permission settings for any item, but the procedures are still too
involved to detail here. (Of course, Mac OS X: The Missing
Manual does include an in-depth look at permissions and the
Instead, I'll zero in on the single command line required to get
sudo chmod g-w /
Since you're modifying the settings for a root-owned directory, the
command line starts with
sudo. Next comes the
chmod command, for "change (file) modes." File modes are
the settings that specify whether an item can be read or written to,
for example, and by which kind of user -- the owner of the item, its
group, or any user of the machine. (These settings correspond, of
course, with the Ownership & Permissions settings that are accessible
via Finder's Get Info window.)
Following a space are
chmod's arguments, the first of
which specifies the modes to be changed. This argument says to take
the group ("
g") and remove ("
permission to write ("
w") to the file or directory
specified in the next argument (again followed by a space), which in
this case is the root directory, ("
Your next step, then, is to run the command line:
[haru:~] chris% sudo chmod g-w /
If you ever want to revert the permissions back to group-writable, run this command, which uses the plus sign ("
However, there are some important caveats with this method. First,
Mac OS X upgrade installers and some application installers change the
root directory back to group-writable, so you'll need to re-run the
chmod command line whenever this happens.
Secondly, and more importantly, there's a reason why Apple wants the root directory to be group-writable. Many Classic installer applications (and even some native ones) are programmed to place items in the root directory, and unless you've given these applications admin privileges to do this, they just might choke during an installation. Apple's workaround for this possibility, then, is to keep the root directory group-writable.
Of course, that causes problems for
requires these permissions for security reasons. At this point, then,
you might feel stuck between a rock and a hard place. But wouldn't it
be great if you could just tell
sendmail (as Ben Franklin
might), "Hey, I'm willing to give up a little security if you just
give me the liberty to keep my permissions!"
sendmail allows you to set just that option
by adding a single line to its configuration file. This is from the
"You may have to tweak your environment to make it safer for sendmail to run. If you find that some of the safeties in sendmail are too restrictive for your environment, they can be turned off by setting the option DontBlameSendmail. The option is appropriately named as sendmail is not to be blamed for problems resulting from unsafe permissions on directories and files."
As long as you're using
sendmail as described in the
tutorial and are the primary user of the machine, the security risk is
small in setting this option. If, however, you aren't able to control
access to your machine either physically or remotely, and you are
compromised, please don't blame me
So if this method sounds better for you than the first (running
sudo chmod g-w /), then the file you need to edit is
/etc/mail/sendmail.cf. You'll first want to make a
backup. Since the
/etc/mail directory is only
root-writable, you'll need
sudo cp -p sendmail.cf sendmail.cf.bak
Note the use of the
-p option flag in this command
line, which preserves the permissions settings of the original in the
copy of the file. This will make things a little easier, should you
need to quickly restore the file.
You can then edit this file using
pico, as you have
with others. Since
sendmail.cf is only writable by root,
you'll need to use
sudo here as well.
sudo pico /etc/mail/sendmail.cf
This file is over 1,200 lines long and might be intimidating, but since you'll just be adding a single line near the top and then getting the heck out, you should have nothing to worry about.
As you view the file, keep in mind that lines beginning with the
#character are ignored by
sendmail as it
reads the file. Typically, such lines contain descriptive comments
about the configuration settings, but they can also be actual settings
that for various reasons are turned off, or "commented out."
The line you're looking for is a commented-out "DontBlameSendmail"
line about 70 lines down from the top. The quickest way to get there
pico is by pressing Control + W, entering
DontBlame, and pressing Return. You should then see these
# level 10 config file format V10/Berkeley # override file safeties - setting this option compromises system security, # addressing the actual file configuration problem is preferred # need to set this before any file actions are encountered in the cf file #O DontBlameSendmail=safe # default LDAP map specification
Next, add a new line after the found line and enter (or paste in) this line:
When you're done, the lines should look like this:
# override file safeties - setting this option # compromises system security, addressing the actual # file configuration problem is preferred # need to set this before any file actions are # encountered in the cf file #O DontBlameSendmail=safe O DontBlameSendmail=GroupWritableDirPathSafe # default LDAP map specification
As usual, press Control + O to save the file, Return to confirm the
name, and Control + X to exit
If everything went well,
sendmail will attempt to send
its mail the next time it's asked, even with a group-writable root