LPI Linux Certification in a Nutshell (56 page)

Read LPI Linux Certification in a Nutshell Online

Authors: Adam Haeder; Stephen Addison Schneiter; Bruno Gomes Pessanha; James Stanger

Tags: #Reference:Computers

BOOK: LPI Linux Certification in a Nutshell
13.75Mb size Format: txt, pdf, ePub
Configuration of Exim

Exim, like postfix and qmail, was designed to be a
sendmail replacement. Therefore, it has helper programs and supports
command-line options to enable a smooth transition from sendmail. Exim
is monolithic like sendmail, in that the exim program handles the
acceptance of email on TCP port 25 and the delivery of mail. There are a
number of helper programs that come with exim, however. Some of the more
common ones are listed in
Table 17-3
.

Table 17-3. Exim programs

Program name

Description

/usr/bin/mailq.exim

Drop-in replacement for sendmail’s
mailq
command.

/usr/bin/newaliases.exim

Drop-in replacement for sendmail’s
newaliases
command.

/usr/bin/runq.exim

Alias for
/usr/sbin/exim
. Running this command is the
same as running
exim –q
. This forces a
single run through the mail queue, attempting a resend on every
item.

/usr/lib/sendmail.exim

Handles sendmail command-line options
and passes them to exim.

/usr/sbin/exim

The main exim binary, this process
listens on TCP port 25 for incoming SMTP connections and hands
incoming mail to the local delivery agent.

/usr/sbin/eximstats

Generates statistics from exim
mainlog
or
syslog
files.

/usr/sbin/exiwhat

Describes what the exim process is
currently doing.

/usr/sbin/exinext

Gives specific information about retry
efforts for an email address.

/usr/sbin/exipick

Displays individual messages from the
exim mail queue.

/usr/sbin/exiqgrep

Searches for strings in the mail
queue.

/usr/sbin/exiqsumm

Summarizes the current contents of the
mail queue.

On the Exam

It is not necessary to know the detailed configuration options
of each MTA for the LPI 102 exam. You need to understand the basic
purpose of an MTA and know how to handle aliasing and email
forwarding. You should also be familiar with the
sendmail-compatibility commands included with qmail, postfix, and
exim.

Name

mail

Syntax
mail [
options
]
Description

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

Example

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.

Name

Mail queuing

Description

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
.

mailq
Syntax
mailq [
options
]
Description

Displays the items in the mail queue.

Example

Attempt to send mail to a host that is not currently
accepting email:

#
echo "Failure Test" | mail [email protected]
View the mail queue
#
mailq
o1591AmX005615 7182 Fri Feb 5 03:01 MAILER-DAEMON
8BITMIME (Deferred: Connection refused by unknown.com.)

This mail will remain in the queue for a default time of 5
days, with retry attempts every 4 hours. You can force sendmail to
attempt a resend of every item in the mail queue with the command
sendmail –q –v
.

Chapter 18. Manage
Printers and Printing (Topic 108.4)

Chapter 18
contains
the final Objective in Topic 108:

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.

Objective 4: Manage Printers and Printing

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.

An Overview of Printing

The various printing implementations available for Linux
systems have a basic architecture in common. In every printing system, a
central daemon (or service) receives print jobs, via either a user command
(such as
lpr
) or the network. The print job is then
processed through input filters if necessary, and sent to either a local
printer or another printing daemon.

Printing documents is a slow and error-prone process. Printers
accept data in small amounts. They are prone to run out of paper, jam, and
go offline for other reasons. Printers also must accept requests from
multiple system users. As a result, by design, the end user is isolated
from printing functions on most computer systems. This isolation comes in
the form of a
print queue
, which holds print requests
until the printer is ready for them. It also manages the order in which
print jobs are processed. Feeding print jobs to printers is often called
spooling
, and the program that manages
the print queues is sometimes called a
spooler
. It
can also be called a
scheduler
.

BSD and System V Interfaces

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

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

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:

  1. A print job is generated by an application locally on the
    client side.

  2. The print job is sent to the print server specified by the
    protocol selected for that queue (e.g., IPP or CIFS).

  3. On the CUPS server, the spooler process
    cupsd
    fetches the data stream and saves it in
    the print spool directory. The default directory is
    /var/spool/cups
    .

  4. If an input filter is specified in the configuration,
    CUPS will pass the job to it. In any case, after any filtering, the
    job is sent to the backend. Many filters create formats for
    particular printers from generic input, such as PostScript or a
    PDF.

  5. The backend sends the printer-specific data to the
    printer.

  6. Once the job is completed,
    cupsd
    removes
    the respective files from the spool directory, depending on the
    retention time configured.

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

CUPS printing overview

On Linux, the CUPS printing system consists of the following
elements:

cupsd

This daemon is started at boot time and runs
continuously, listening for print requests directed at multiple
printers. When a job is submitted to a print queue,
cupsd
handles jobs on that queue. The copy
exits when the queue is emptied.

/etc/cups/cupsd.conf

This file configures the
cupsd
daemon. It is normally located in the
/etc/cups
directory.

Each line in the file can be a configuration directive, a
blank line, or a comment. The configuration directives are
intentionally similar to those used by the popular Apache web
server software.

/etc/cups/printers.conf

This file defines available local printers. It is
generated automatically by
cupsd
when
printers are added, deleted, or changed. This file shouldn’t be
changed manually.

/etc/printcap

This file is still present on the system to allow older
printing applications that rely on it to keep functioning. Under
CUPS, the file is automatically generated by
cupsd
from the
/etc/cups/printers.conf
file. All
changes to the file are lost if the CUPS service is
restarted.

lp

The
lp
(line print) program
submits both files and information piped to its standard input
to print queues.

lpq

This program queries and displays the status and
contents of print queues.

lprm

This program removes print jobs from print
queues.

lpadmin

This program configures printer and class queues
provided by CUPS. It can also be used to set the server default
printer or class.

lpc

Nowadays,
lpc
provides
limited control over printer and class queues provided by CUPS.
It can also be used to query the state of queues. The command
lpadmin
should be used instead.

Spool directories

The
cupsd
daemon uses
/var/spool/cups
for the spooling of data
awaiting
printing
.

Print jobs

Each print request submitted is spooled to a queue
and assigned a unique number. The print jobs can be examined and
manipulated as needed.

Other files are also used by particular parts of the system,
such as input filters.

CUPS backends

Several backends are available for CUPS: parallel,
serial, SCSI, and USB ports, as well as network backends that operate
via the Internet Printing Protocol (HTTP, HTTPS, and IPP), JetDirect
(AppSocket port 9100), Line Printer Daemon (LPD), CIFS (which used to
be called SMB) protocols, and more.
PDF generators are also available. These backends
usually live in the directory
/usr/lib/cups/backend
, and can be compiled
programs or scripts written in any scripting language, such as Perl or
Python.

The backend is always the last program executed for processing a
print job.
Table 18-1
lists the
most popular backends.

Table 18-1. Backend processors under CUPS

Backend

URI syntax

Example URI

Parallel

parallel:/dev/lp
number

parallel:/dev/lp0

USB

usb://
make
/
model
?serial=
number

usb://vendor/printer%201000?serial=A1B2C3

ipp

ipp://
host
/printers/
queue

ipp://host/printers/printer1000

LPD

lpd://
host
/
queue

lpd://host/printer

socket

socket://
host
:
port

socket://ip:9100

CIFS (Common Internet Filesystem,
the protocol Microsoft Windows-based systems use for file and
printer communication across a network)

see the
smbspool
(8) manpage

smb://user:password@workgroup/host/share

CUPS filters

The core of the CUPS filtering system is based on
Ghostscript, part of the GNU project. It consults PPD
files, which are an industry standard for representing printer
capabilities (two-sided printing, four-to-a-page, etc.).

For
PostScript printers, the
PPD file contains the printer-specific options (and
nothing else) together with the corresponding PostScript code snippets
that must be sent to the PostScript interpreter in order to activate a
certain option.

For non-PostScript printers, the PPD file contains additional
information about which printer driver program to use and the options
available for the particular driver. If several drivers can be used
for a given printer, several PPD files are found on the system.

Depending on the printer-specific options set for a certain
print job (e.g.,
-o PageSize=A4
),
the filter system reads the suitable PostScript code snippets (the
so-called “PostScript invocation values”) from the PPD file and
inserts them in the PostScript data stream.

The original data has a MIME type determined by configuration
options in
/etc/cups/mime.types
.
If the type is not
application/postscript
, the data is
converted to PostScript according to the
/etc/cups/mime.convs
configuration file.
For example,
text/plain
is
converted to PostScript with the
/usr/lib/cups/filter/texttops
program.

These filter files are usually found in the directory
/usr/lib/cups/filter
and, like CUPS
backends, can be compiled code or shell scripts.

Managing CUPS print queues

As a system administrator, you’ll likely be asked to
manage and manipulate printer more often. On Linux, the
lp
,
lpq
,
lpstat
,
lprm
, and
lpadmin
commands are your tools. Other tools
include
lpoptions
,
accept
,
reject
, and
cancel
.

Other books

Creatures: Thirty Years of Monsters by Barker, Clive, Golden, Christopher, Lansdale, Joe R., McCammon, Robert, Mieville, China, Priest, Cherie, Sarrantonio, Al, Schow, David, Langan, John, Tremblay, Paul
Irish Moon by Amber Scott
Throy by Vance, Jack
Her Own Rules by Barbara Taylor Bradford
Girl Missing by Tess Gerritsen
Inferno-Kat 2 by Vivi Anna
Secret Meeting by Jean Ure
Crucifixion - 02 by Dirk Patton
The Sorcerer's Legacy by Brock Deskins