Understanding LDAP

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>