oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Learning the Terminal in Jaguar, Part 2
Pages: 1, 2, 3

NetInfo andsendmail

The version of sendmail included with Mac OS X is compiled to look at the NetInfo database for either its configuration information or a pointer to a config file.

In our case, we want sendmail to read from /etc/mail/ so you'll need to add a record pointing to that file to the NetInfo database. To do so, use the niutil command with these two command lines (the second line has been broken into two for the sake of space here, but it should be entered on one line):

sudo niutil -create . /locations/sendmail
sudo niutil -createprop . /locations/sendmail

niutil, or the Netinfo Utility, is a command line version of the GUI NetInfo Manager application found in /Applications/Utilities. The first of the two command lines creates a new record, and the second writes the properties of that record: the name of the configuration file, and its path.

Now when sendmail looks at NetInfo for its configuration information, it will find the pointer within this new record, and follow it to /etc/mail/ for that info.

One More Thing for sendmail

The final sendmail step is configuring it to start when the machine starts. sendmail will then continue to run in the background whenever the machine is on, watching for new mail to deliver, and making sure undeliverable messages don't accumulate. Such background processes (often called daemons), play a vital role in Mac OS X's operation, and most of the time use little memory or processing resources.

Though running sendmail as a daemon is not really necessary for the purpose of this tutorial, doing so will at least ensure that the mail-related housekeeping gets done. The configuration involves one simple step: making one change to the /etc/hostcofig file.

Open the file in pico as usual (though you might want to back it up first), using sudo since it's a root-owned file:

sudo pico /etc/hostconfig

Look for this line:


And just change the NO to YES, so it looks like this:


Save the file and close pico as usual, and your sendmail mail server will start with each boot. Since sendmail is not running on your machine yet, you can also start it without rebooting using this command:

sudo /System/Library/StartupItems/Sendmail/Sendmail start

This command manually runs the same sendmail startup script that the system runs once MAILSERVER is set to YES in /etc/hostconfig.

Checking Mail

Now that sendmail is ready to go, it's time to test it out by sending mail from the CLI. To do so, use the mail command to send mail to yourself like this:

[haru:~] chris% mail chris

You're now working inside the mail CLI application, so you'll see no more tcsh shell prompts until you exit mail. Enter any subject you would like and press return. Type in your message at the cursor. To end your message, send it, and exit mail, press return, type a period, and press return again. You'll then return to your shell prompt:

[haru:~] chris% mail chris
Subject: Test
This is only a test.
[haru:~] chris%

You can then check your mail by entering the mail command again, but this time with no arguments. If the message arrives, you'll see something like this:

[haru:~] chris% mail
Mail version 8.1 6/6/93.  Type ? for help.
"/var/mail/chris": 1 message 1 new
>N  1 chris         Fri Jan 17 13:50  13/399   "Test"

You're back in the mail application, but this time to view your new message. Press return at the "&" prompt to have a look:

Message 1:
From root  Fri Jan 17 13:50:30 2003
Date: Fri, 17 Jan 2003 13:50:30 -0800 (PST)
From: Chris Stone <chris>
To: chris
Subject: Test

This is only a test.


Type q and return at the prompt to exit mail:

& q
Saved 1 message in mbox
[haru:~] chris%

If for some reason your mail didn't arrive, you'll want to track the problem down by looking at the mail log /var/log/mail.log. A commonly used utility for viewing ever-growing log files is tail, which displays just the last few lines (the most recent) of a log file:

tail /var/log/mail.log

The output should provide some clues, but if you're having trouble deciphering them, feel free to ask for help in the Talkback section of this article.

Back to Periodic

Now that your MTA is working, there are only a couple of more steps to getting periodic's reports sent to you. The first is to configure periodic to email its reports to the root user account instead of saving them as files. The second step is to configure things so that any mail sent to the root account gets forwarded to your account.

Why root? Well, we could just have periodic send the reports directly to your account, and it would work fine. But there is a standard practice in Unix that has any system- generated email messages sent to root, which is an account always sure to exist. It's then easy enough to just change root's forwarding address once, instead of several times should the ultimate destination account name (yours, in this case) change in the future. For now though, it's unlikely you'll be getting system email from processes other than periodic, but you'll be ready if you do.

periodic reads its configuration information from the file /etc/defaults/periodic.conf. We actually won't be modifying this file, but having a look at it will be informative. The /etc/defaults/periodic.conf file is a bit too long, so you'll want to use an application that can display the files one bite-sized screen-full, or "page," at a time. Such applications are called pagers, and one of the most common pagers is more.

Enter more and the file's pathname to view the first page of the file. To view periodic's default configuration file, then, enter:

more /etc/defaults/periodic.conf

You should then see something like this:

Screen shot.

To move down to the next page, press the space bar. (To go back up, press B.) At the bottom of the more display, you'll see the name of the file being viewed, as well as an indicator of the percentage of the file read so far. To exit more, type Q.

As you peruse the file, you'll notice its three main options sections, one for each of the periodic maintenance jobs: daily, weekly, and monthly. For us, the output line for each section is of interest. For example, in the daily options section you'll find this line:

daily_output="/var/log/daily.out"  # user or /file

As you might guess, this line tells periodic to write the output of its daily maintenance job to the file var/log/daily.out. You'll find that each of the other two sections have a corresponding line as well.

To have the output sent to an email message instead of this file, you would simply replace that file's pathname in this line with the target account's username, root, in our case. You could just make the change in this default configuration file, but periodic allows you the option of using an override file with which to specify changes, thus keeping the default file pristine and easily reverted to.

To do this, you'll create a new file /etc/periodic.conf and add the desired output options lines to it, and periodic will know to abide by those specific settings in this file instead of those in its default configuration file.

You'll again use sudo with pico since /etc is only writable by root:

sudo pico /etc/periodic.conf

Since this file doesn't yet exist, this command will create it and open it for writing. Simply enter these three lines to specify that periodic sends the output from its daily, weekly, and monthly jobs to root:


Save the file and close pico as usual, and you're one step away from finishing. The last step, then, in getting the reports delivered is to direct them to your mailbox, instead of root's. And you'll do this using a .forward file.

A .forward file is just a text file containing nothing but the name of the account to which you want the mail forwarded (in this case, your account name). Once the .forward file is placed in the home directory of the original addressee (in this case, root), the mail gets forwarded as expected.

Pages: 1, 2, 3

Next Pagearrow