Classnotes | LDAP01 | RecentChanges | Preferences While some organizations may have the resources (such as undergraduate work study students) to re-enter the data held in NIS, /etc/passwd, etc., into the LDAP store, luckily, there are other means available.
You can obtain a suite of Migration Tools from PADL Software's web-site here:
Download them and unpack them. After unpacking them, you must modify the $DEFAULT_BASE variable in migrate_common.ph to the default base DN for your organization (eg dc=odyssey,dc=com).
Inside the archive, you will find a number of shell scripts which take various items of information and convert them into LDIF file formats suitable for inclusion in a directory. For example, there is a password migration tool to migrate from /etc/passwd into an LDIF. It's basic usage is as follows:
./migrate_passwd.pl /etc/passwd passwd.ldif
Which results in an LDIF file containing entries such as this:
dn: uid=sam,ou=People,dc=odyssey,dc=com
uid: sam
cn: Samuel Hart
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}LvMjdI2Pksa10S?.c
shadowLastChange?: 12145
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/sam
gecos: Samuel Hart
Different scripts exist to translate each system file into LDIF records. The information in each file is stored in a different organizational unit directly beneath the base suffix (base DN). Currently, the migration scripts support translating the following:
/etc/fstab (stored in ou=Mounts)
/etc/hosts (store in ou=Hosts)
/etc/passwd (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)
/etc/groups (stored in ou=Netgroups)
In each case, the PADL scripts do not create the top-level organizational unit for you. Make sure that these exist prior to attempting to insert these LDIF files into the directory.
For example, if we wer primarily deailing with users and groups (which we are) we would need the following entries already:
dn: ou=people,dc=odyssey,dc=com
objectClass: organizationalUnit
ou: people
dn: ou=group,dc=odyssey,dc=com
objectClass: organizationalUnit
ou: group
