[ Team LiB ] Previous Section Next Section

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/MigrationTools.html.

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
figs/ldap_0605.gif

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
    [ Team LiB ] Previous Section Next Section