by July 7, 2001 0 comments



Centralized
network resources in heterogeneous networks have long been on every network
administrator’s wish list. LDAP (Lightweight Directory Access Protocol)
has been touted as a possible solution. In this article, we look at how LDAP
works.

NetWare and Unix have had
centralized network resource management tools available to them in the form
of NDS and NIS/NIS+ respectively. However, Microsoft has now added Active
Directory to Windows 2000 to put it on a comparable footing with other
platforms. What’s missing, however, is a way to integrate these
information resources within reasonably heterogeneous networks. The network
administrator today faces the challenge of having to provide unified
passwords for users logging into different operating systems within the same
domain, broadcast common network resource information, such as group and
access control, as well as passively store other resources such as network
printers, telephone, and e-mail directories, etc. This is exactly where LDAP
comes in handy.

We’ll take a look at this
protocol, and its scope to serve as an enterprise-wide directory service.

What’s a directory
service?

A directory
service is much like a telephone directory. It’s a hierarchical database
that stores information in an object-oriented, rather than a tabular form,
as an RDBMS does. The difference in the architecture is in the type of
services that a directory provides.

First, the directory is
predominantly used for read access, not write access–that is, you look up
user information more often than update it or add new users. Secondly, a
directory service tends to store data that can be structured more easily in
a hierarchical manner. Directory entries typically consist of
“entries” with “attributes”, while an RDBMS has
“tables” with “records”. Additionally, each attribute is
permitted to have more than one value (See figure).

What is LDAP?

LDAP, or
Lightweight Directory Access Protocol, is simply a protocol used to access a
directory service. The original directory services specification was X.500,
which, although powerful, had several drawbacks. It ran on top of the OSI
protocol and consumed network and system resources heavily. X.500, however,
had support for powerful querying features within the directory. DAP
(Directory Access Protocol) was used by clients to access the X.500
directory. LDAP was derived from this, with emphasis on the
“lightweight”. LDAP gateways were set up to enable relatively less
powerful PCs to access X.500 services.

Today’s LDAP services, in
the form of the LDAP V3 protocol, offer greatly enhanced functionality,
though the older X.500 still offers some advantages.

It’s important to note that
LDAP is an access protocol, and doesn’t specify how the data is actually
stored. The underlying data store could be files, such as Berkely DBM,
supported by OpenLDAP and Netscape’s directory server, or even an RDBMS
such as Oracle. LDAP itself provides a fairly simple API, which is used to
access, read, modify, delete, and search for data on a directory service.

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.

Your data will be safe!Your e-mail address will not be published. Also other data will not be shared with third person.