LDAP System Administration [Electronic resources] نسخه متنی

6.3 Information Migration

While some organizations may have the resources (such as
undergraduate work study students) to re-enter the data held in the
NIS maps to the LDAP store, luckily, there are other means available.
In addition to the PAM and NSS LDAP reference modules available at
PADL Software's web
site, you'll also find a set of Perl scripts
designed to convert the various /etc system
files (e.g., /etc/passwd and
/etc/hosts) into LDIF format. Once
you've converted the system files to LDIF, you can
import them into your LDAP store either online using the
ldapadd(1) command or by using an offline
database creation utility such as the OpenLDAP
slapadd(8c) tool. These LDAP migration scripts can
be found at http://www.padl.com/OSS/MigrationToolsl.

After unpacking the migration scripts, you must customize the
migrate_common.ph script to fit your network settings.
Within this Perl script is a variable named
$DEFAULT_BASE, which is
used to define the base suffix under which the organizational units
that will serve as containers for migrated information will be
created.

The scripts accept input and output filenames as command-line
parameters. If no output filename is present, the scripts write the
converted entries to standard output. For example, the following
command converts /etc/passwd into an LDIF file:

root# migrate_passwd.pl /etc/passwd /tmp/passwd.ldif

Here's what a typical entry from
/etc/passwd looks like after it has been
translated:

dn: uid=gcarter,ou=people,dc=plainjoe,dc=org
uid: gcarter
cn: Gerald Carter
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}LnMJ/n2rQsR.c
shadowLastChange: 11108
shadowMax: 99999
shadowWarning: 7
shadowFlag: 134539460
loginShell: /bin/bash
uidNumber: 780
gidNumber: 100
homeDirectory: /home/gcarter
gecos: Gerald Carter

All the required fields (cn,
uid,
uidNumber,
gidNumber, and homeDirectory)
defined in the RFC schema for a posixAccount are
present. There are also a number of shadow fields
(shadowLastChange, etc.; see the
shadowAccount object in Figure 6-5), which hold values related to password aging.
These values are taken automatically from the
/etc/shadow file. If your system
doesn't use shadow passwords, the
shadowAccount object class values may not be
present.

Figure 6-5. Relationship between the shadowAccount object class and /etc/shadow file entry

Different scripts exist to translate each system file into LDIF
records. The information in each file is stored in a different
organzational unit directly beneath the base suffix (defined in
migrate_common.ph) in the directory. Each
ou listed next is used by convention. The
nss_ldap
library can be configured to pull information from other locations,
as we will see later. Currently, the migration scripts
support translating:

/etc/fstab (stored in
ou=Mounts)

/etc/hosts (stored in
ou=Hosts)

/etc/passwd and /etc/shadow
(stored in ou=People)

/etc/group (stored in
ou=Group)

/etc/protocols (stored in
ou=Protocols)

/etc/rpc (stored in ou=Rpc)

/etc/services (stored in
ou=Services)

/etc/networks (stored in
ou=Networks)

netgroups (stored in
ou=Netgroups)

In each case, the PADL migration scripts do not create the top-level
organization unit for you. Make sure that these exist prior to
attempting to generate LDIF files in the directory. Since we are
primarily dealing with users and groups in this chapter, the
following entries have already been added to the directory:

dn: ou=people,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: people
dn: ou=group,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: group