Learning the Terminal in Jaguar, Part 2

Author's Note -- In Part 1 of this series focusing on using the Terminal application in Jaguar, you learned how to reschedule default system cron jobs by modifying the system crontab file.

Here in Part 2, I'll show you how to configure cron 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 the 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 /etc/crontab allow 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 cd to /etc to open crontab, as 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 cron job, 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 to the root account.

Related Reading Mac OS X in a Nutshell A Desktop Quick Reference By Jason McIntosh, Chuck Toporek, Chris Stone

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 daily argument.

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, periodic's single argument specifies that periodic run its daily job.

Periodic

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 cron, for 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 given to periodic refers to a directory of the same name. The daily directory exists in /etc/periodic, a place periodic knows to look for executable files to launch. Inside /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

The -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 /etc/periodic: daily, weekly, and 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 500.daily).

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.

sendmail

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 to get sendmail running on your machine so that it will at least deliver the reports generated by periodic. For help getting sendmail to run in an actual server environment, see this article.

The first step to getting sendmail to successfully launch in Mac OS X is to address a permissions issue. As a security measure, 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 instead configure 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 root 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 CLI.)

Instead, I'll zero in on the single command line required to get sendmail going:

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 ("-") its 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 /

[haru:~] chris% sudo chmod g+w /

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 sendmail, which 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!"

In fact, sendmail allows you to set just that option by adding a single line to its configuration file. This is from the sendmail documentation:

"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 either ;-)

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:

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 in pico is by pressing Control + W, entering DontBlame, and pressing Return. You should then see these lines:

# 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:

O DontBlameSendmail=GroupWritableDirPathSafe

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 pico.

If everything went well, sendmail will attempt to send its mail the next time it's asked, even with a group-writable root directory.