LPI Linux Certification in a Nutshell (56 page)

mail

mail [
options
]

A mail processing system that can be used to both send and
read Internet mail.

Start mail in interactive mode to read your mail:

#
mail
Send an email from the command line:
#
mail -s "This is the subject" -c "root" adamh
Hello
.
Cc:
root

This example shows some command-line options of
mail
, specifically the ability to indicate a
subject and Cc: list. In this example, the body of the message was
given interactively, ending with a “.” on a line by itself. You
could also
cat
an existing file and redirect
STDOUT
to the
mail
program
to make this noninteractive:

#
echo "Message body" > /tmp/body.msg
#
cat /tmp/body.msg | mail –s "This is the subject" –c "root" adamh

This email was delivered successfully because there was a user
account named
adamh
on this system. What if we
want to create
aliases for this user so he can get email to the same
inbox via a number of different email addresses? Sendmail handles
aliasing with the file
/etc/aliases
:

#
cat /etc/aliases
#
#  Aliases in this file will NOT be expanded in the header from
#  Mail, but WILL be visible over networks or from /bin/mail.
#
#       >>>>>>>>>>      The program "newaliases" must be run after
#       >> NOTE >>      this file is updated for any changes to
#       >>>>>>>>>>      show through to sendmail.
#
# Basic system aliases -- these MUST be present.
mailer-daemon:  postmaster
postmaster:     root
# General redirections for pseudo accounts.
bin:            root
daemon:         root
adm:            root
lp:             root
# User maintained aliases
adam:        adamh
adam.haeder:    adamh
haeder:        adamh

The lines in this file take the format “alias: user account”.
After you make modifications to this file, you must run the command
newaliases
as root. The
newaliases
command will take the
/etc/aliases
file and convert it to a
hashed Berkeley DB file. This is a standard method of configuration
for sendmail; changes are made to text-based configuration files,
and are then converted to Berkeley DB files for quicker parsing.
Emails that are sent to
adam
,
adam.haeder
, or
haeder
will all be delivered to the user
adamh
.

What if you want to forward all emails sent to a specific user
account to another account, either on the same system or to a
different email address? The easiest way to accomplish this is with
the file
~/.forward
. This is
simply a text file that lives in a user’s home directory and
contains one or more email addresses to forward all mail to. These
can be either local addresses (usernames) or complete Internet email
addresses (
[email protected]
). The advantage of
the
~/.forward
file is that the
user can maintain it himself, whereas the
/etc/aliases
file must be maintained by
the root user.

Mail queuing

Sendmail is an intelligent mail agent, and it tries to
deliver mail even when failures occur. For example, if a user
attempts to send email to
[email protected]
,
and the mail server for hostname.com is turned off, sendmail will be
unable to make a connection to TCP port 25 on the mail server for
hostname.com and consequently won’t be able to deliver the mail.
Instead of giving up, sendmail will place the email in a queue and
attempt redelivery. The default action of sendmail is to attempt
redelivery of queued mail every 4 hours for 5 days before giving up
and sending a “Delivery Failure” notification to the original
sender. Queued mail is stored in the directory
/var/spool/mqueue
and is managed by the
program
mailq
.

Objective 4: Manage Printers and
Printing

Candidates should be able to manage print queues and user print
jobs using CUPS and the LPD compatibility interface. Weight: 2.

As long as the paperless office remains a myth, printing will be an
important aspect of the computing experience. Even if you don’t deal with
it on a daily basis, as a system administrator printing will inevitably be
an important part of your job.

This topic also covers the setup, administration, and use of the
Common Unix Protocol (CUPS) and the Line Printer Daemon (LPD) legacy
interface (
lpr
,
lprm
,
lpq
, etc.). Although they are not covered in the
current LPI Objectives, this chapter also includes an introduction to
other printing systems that may be used on Linux
systems
.

In the current LPI exams, this objective weight was changed, the
content shrank from three objectives to one, and the objective was moved
to the Essential System Services topic. Bear in mind that CUPS is the main
thing to know here, but CUPS’s compatibility with the legacy LPD protocol
are also required.

Historically, there have been two competing printing
implementations on Unix systems, one invented for BSD Unix and another
for System V (SysV) Unix. Although the implementations are similar, they
have completely different commands. The BSD printing commands include
lpd
,
lpr
,
lprm
, and
lpc
. The System V
printing commands include
lp
,
enable
,
disable
,
cancel
,
lpstat
, and
lpadmin
. On System V-based systems, the
lpadmin
command manages print queues. There is no
equivalent to it on BSD-based systems, other than to simply edit
/etc/printcap
. Other than
lpadmin
, there is a one-to-one relationship between
BSD and System V printing commands. However, the internal details, such
as files used, vary considerably.

Older Linux distributions tended to use a port of the BSD
lpd
code (and related commands). Due to various
security issues with the BSD code (mostly the overuse of the
root
account through SUID executables), current
distributions have largely dropped the BSD code in favor of CUPS.

LPRng is a complete rewrite of the BSD utilities. It is
designed to be portable and secure. Unlike the BSD utilities, the client
programs do not need to run SUID. The server (still called
lpd
) is a complete implementation of the RFC 1179
Line Printer Daemon Protocol. It also includes
lp
and
lpstat
commands for System V
compatibility
.

Although LPRng is a complete rewrite, configuration is still
mostly the same as for the BSD utilities. It still uses
/etc/printcap
(described later in this chapter). It
also has two additional configuration files:
/etc/lpd.conf
, which controls details of LPRng’s
lpd
, and
/etc/lpd.perms
, which
configures access controls for
lpd
.

Sometimes it’s necessary to integrate the printing server into a
heterogeneous infrastructure, such as to serve systems using the LPD
legacy protocol. The embedded package
cups-lpd
is
the CUPS Line Printer Daemon (LPD) mini-server supporting these legacy
client systems.
cups-lpd
does not act as a
standalone network daemon, but instead operates using the Internet
inetd
or
xinetd
super-server.

The LPD server will listen on the default port specified in the
/etc/services
file:

printer         515/tcp          spooler         # line printer spooler
printer         515/udp          spooler         # line printer spooler

LPRng is available from
http://www.lprng.com
.

CUPS is a more recent printing system that was initially
designed to support the Internet Printing Protocol (IPP) but has evolved
into a drop-in replacement for both the BSD and System V utilities,
including client replacements for RFC 1179 (
lpd
protocol) support.

Although it retains backward compatibility with older printing
systems, the internal details of CUPS are significantly different. The
server component
cupsd
handles queuing, and
includes a web server for configuration and management. Nearly
everything can be configured through the web interface or the included
lpadmin
command. The various configuration files in
the
/etc/cups
directory rarely need to be edited by
hand.

The CUPS web interface, shown in
Figure 18-1
, is available on the machine
at
http://localhost:631
.

Figure 18-1. CUPS management web interface

In order to implement or troubleshoot a printing system, it’s very
important to understand the data flow and the steps taken on the server
and client side. In the case of CUPS, these are:

CUPS is available from
http://www.cups.org
.