by July 7, 2001 0 comments



PAM,
or Pluggable Authentication Mechanism, provides a powerful and flexible way
to extend the operating system’s built-in authentication systems
transparently, to applications. PAM is the default authentication system
built into every single Linux distribution. It’s always installed (it
controls the logins, so it has to be). Almost all standard Linux apps,
including Samba, and almost all new apps include PAM. So, what’s PAM?

Imagine a server installation
at a high security industrial complex, military, or secret service
establishments. Do you imagine that the mainframes there have a login prompt
flashing all day long waiting for someone to login as “root” with
password “password”?

The security setup you see in
movies such as Mission Impossible may be a bit far-fetched, but is still
closer to reality than you’d think. Authentication mechanisms such as
retinal and fingerprint scanners, smart cards, voice recognition, even
facial recognition, are all possible and in fact, very much a reality today.
While you’re unlikely to need such levels of security on any of your home
or office machines, the technology is fairly common. Even Compaq has
launched machines with fingerprint scanners for authenticating Windows users
in India.

But, what does all this
have to do with PAM?

Imagine what
would happen if every authentication mechanism you used required you to
compile support for it into your applications. While in the world of free,
open-source software, this is quite possible, it’s not necessarily
efficient. What you need is a generic interface to different mechanisms that
basically do the same thing–authenticate users. This is where PAM comes
into the picture. PAM acts as a middle man, whose primary task (among other
things) is to authenticate users, and inform applications of their identity.

PAM was originally developed
by Sun Microsystems. However, most development in recent days is being
carried out by the open-source community. Today almost all Linux
applications include PAM, which means that you can authenticate against a
directory service via LDAP, a Novell Server with NDS, a Windows NT domain
controller, etc.

Applications authenticate
users by calling a standard set of PAM functions. When an application wants
to authenticate a user, it makes a generic call to PAM to handle the
authentication process. Each application has a configuration file associated
with it (usually in/etc/pam.d), specifying which modules to use for
authentication. At this stage, the appropriate PAM module takes over. It
could prompt the user for a password, or perhaps inject her with a complex
protein dye that binds with DNA to generate a unique triple helix pattern,
which can be matched against a database of cloned and radioactive DNA.
Whatever it does, at the end, it passes a simple message to the application
calling it–PAM_SUCCESS or PAM_ FAILURE. That’s all the application needs
to know.

By simply editing their
configuration files, each application can be made to authenticate against
different or even multiple data sources. You can, for example, have modules
that authenticate against the standard Unix password file, as well as
against an LDAP directory (see the article “Setting Up LDAP”, page
97 in this issue). Hence, by simply switching the module used in the
configuration file, you can switch which service is used.

Sounds simple?

PAM does a lot of other
things as well. Broadly, you can divide all that PAM can do into four
categories–user authentication, session management, account management,
and password management.

User Authentication is what
we have already discussed–simply determining whether a user is whom he or
she claims to be.

Session management applies to
tasks that are performed at the time of login and logout. This could include
dynamically mounting a user’s home directory, logging information, etc.

Account management includes
restricting the length of time a user can be logged in, what hours he is
permitted to access the system, etc.

To understand what logrotate can do….

To understand what logrotate
can do, first ask yourself what you want to do with your log files. The
table "Planning for a log processing and archiving policy" might
help you to start. The first row lists the processing and reporting to be
done, while the first column lists the files on which the processing is to
be done. Put down the different log files in column 1, tick out the log
processing of your choice, and you can come up with a policy for using
logrotate.

Let me briefly explain what
each column implies. A "yes" on column 2 indicates that you want
to retain the log file as a record, so it’s best kept compressed.
Similarly, a "yes" in column 3 indicates that you merely want to
scan the file, look for the unusual, and then discard it. You might want to
mail this file to yourself or to the relevant administrator. Column 4 says
that you want to discard the file straightaway. In the sysadmin world, this
obviously doesn’t qualify for best practice. Columns 5 and 6
mention the actions you want to perform before and after you do the log
processing. Column 7 is for an e-mail address to which errors during log
processing are to be reported, and column 8 indicates how often you want the
processing to be done. Note that you might want a time threshold with a
granularity of a day or choose to have a file size threshold to rotate the
logs. This table is not exhaustive or mandatory in nature–it’s is merely
an example of how you would go about the policy-making exercise. So, don’t
implement this, as is, as a policy. Evolve one to suit your needs.

If you’re ready with a
table such as the one above, you have a policy. You can now use logrotate to
implement this policy.

The policy is specified using
keywords, as well as with a script-like language comprising keywords
specific to logrotate. The script is intuitive and easy to understand. By
default, most logs are rotated four times, uncompressed, before they’re
removed from the system. This should explain the presence of files with the
extensions .1, .2, .3 and .4 in the /var/log directory. Take the file /var/log/messages
as an example. After a certain time period or after a certain file size is
reached (as specified in /etc/logrotate. conf), this file is renamed to
messages.1 and an empty file called messages is created to take in the new
log input. This is repeated until they’re rotated four times.

Let’s look at a portion of
the configuration from /etc/logrotate.conf from a standard install. The
first line mentions the name of the file for which the policy is laid out.
Notice the intuitive keywords–"monthly" indicates that the
rotation cycle is monthly, "create" specifies the permissions and
ownerships to be used when the old file is moved to another name and an
empty file is created. "Rotate 1" indicates that one rotated
logfile will be retained:

/var/log/wtmp
{ monthly

create 0664
root utmp

rotate 1

}

Here’s a portion of the
file /etc/logrotate.d/apache–the policy for processing apache log files.
The keyword missingok implies that if the log file isn’t found, continue
processing the rest. Notice the command in between the keywords postrotate
and endscript. This command is executed after log processing is done.
Surprisingly, you don’t find any other instructions such as the frequency
of rotation or the number of rotations, as in the previous case. When there’s
no explicit mention made, the definitions in the global configuration file
will apply.

/var/log/httpd/access_log
{

missingok

postrotate

/usr/bin/killall -HUP httpd 2> /dev/null || true

endscript

}

logrotate is typically run
once a day by the cron. If you are logged in as superuser, you would see an
entry similar to the one below in the crontab file:

0 0 * * * /usr/sbin/logrotate

The utility runs every
midnight. You can run it more often if you need to.

A good start towards
minimizing disk storage space would be to uncomment the compress option in
/etc/logrotate. conf, so that all the rotated log files are kept compressed.

Avinash
Shenoy
is a systems and network administrator at the NCBS, Bangalore,
and Gopi Garge is a technology
consultant with Exocore Consulting <www.exocore.com>

No Comments so far

Jump into a conversation

No Comments Yet!

You can be the one to start a conversation.

<