Linux.com

More data: Branching out

With my top-level entry out of the way, it's time to think about how I want to divide up the entities within my organization. Without a doubt, I know that I want to keep track of users and groups on my systems. You may decide you want to keep track of hosts, mount maps, and NIS netgroups as well. However, these entities have among them a logical separation, so it would be nice to be able to look for, say, people under a People subtree, groups under a Group subtree, and so on. This is traditionally done by creating what are called organizationalUnit or "ou" objects, under which sit the subjects of that organizationalUnit.

For now, I'm going to keep things simple and create only People and Groups trees, with an entry or two under each tree. Here's some more LDIF:

dn: ou=People,dc=linuxlaboratory,dc=org
ou: People
objectClass: top
objectClass: organizationalUnit
description: Parent object of all UNIX accounts

dn: ou=Groups,dc=linuxlaboratory,dc=org
ou: Groups
objectClass: top
objectClass: organizationalUnit
description: Parent object of all UNIX groups

dn: cn=jonesy,ou=People,dc=linuxlaboratory,dc=org
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: inetLocalMailRecipient
objectClass: shadowAccount
uid: jonesy
sn: Jones
givenName: Brian
cn: jonesy
userPassword:: p455\^/0rD
loginShell: /bin/bash
uidNumber: 12
gidNumber: 12
homeDirectory: /home/jonesy
gecos: Brian K. Jones,IT,434,x231
mail: jonesy@linuxlaboratory.org
roomNumber: 434
telephoneNumber: x231
labeledURI: http://www.linuxlaboratory.org
description: All-around good guy
homePostalAddress: NONE
displayName: Brian K. Jones
homePhone: 000-000-0000
title: Chief

dn: cn=cartman,ou=People,dc=linuxlaboratory,dc=org
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: inetLocalMailRecipient
objectClass: shadowAccount
uid: cartman
sn: Cartman
givenName: Eric
cn: cartman
userPassword:: c4r7m@n!
loginShell: /bin/pdksh
uidNumber: 13
gidNumber: 12
homeDirectory: /home/cartman
gecos: Eric Cartman,IT,433,x233
mail: cartman@linuxlaboratory.org
roomNumber: 433
telephoneNumber: x233
labeledURI: http://www.linuxlaboratory.org
description: Round
homePostalAddress: NONE
displayName: Eric Cartman
homePhone: 000-000-0000
title: worker bee

dn: cn=staff,ou=Groups,dc=linuxlaboratory,dc=org
objectClass: posixGroup
objectClass: top
cn: staff
gidNumber: 12
memberUid: jonesy
memberUid: cartman

At this point, though we haven't done an actual import yet, we have designed an LDAP directory that can be drawn on paper, and it would look something like the figure in diagram 1.

How'd you do that?

How did that mass of LDIF magically appear? I started (in the case of the jonesy account) with an NIS map entry just like this one:

jonesy:p455\^/0rD:12:12:Brian K. Jones,IT,434,x231:/home/jonesy:/bin/bash

Then:

• Map the NIS map fields to actual LDAP attributes
• Figure out the objectclasses needed to support those attributes
• Figure out any additional attributes you'd like to keep track of that your current scheme lacks, and which objectclasses are needed for those attributes
• Write up a quick sample LDIF account entry, and test an import
• Automate, automate, automate!

In the LDIF I've presented, all of the NIS map fields map to attributes of the posixAccount object. Since I plan to employ some things in the future like password aging and expiration, I've also employed the shadowAccount class. It's currently unused, but this keeps me from having to add it to the users' account entries later. This foresight can potentially save gobs of time.

Some of the other account attributes, like room, mail, and telephoneNumber, are attributes that come from one or more of the other objectclasses used to define the entry. They can be used by application developers creating an online directory, and even by existing email clients like evolution or pine, which can be configured to perform email address auto-completion based on a search of the mail attributes under the People tree. Just remember to make sure your objectclasses don't form a clash.

Implementing the Design: Importation

Our final trick is to import the LDIF we've created. At this point I assume you have a running slapd server. Make sure that your slapd.conf file includes the core, cosine, inetorgperson, misc, and nis schema files. For the purposes of this example, I'll also assume your LDIF is stored in a file called my.ldif in your current working directory. Last but not least, I assume you've followed my slapd.conf example from our last article and used cn=Manager as your administrative user in slapd.conf, and that you've assigned (and remember) the password for this user.

With this in mind, the command to import your data into a running LDAP server is:

[jonesy@livid ~]$ ldapadd -x -W -D'cn=Manager,dc=linuxlaboratory,dc=org' -f my.ldif -c

You can find a quick explanation of the command's flags by running ldapadd by itself. The ones I've used here are:

• -c: This means don't die on every error; list errors, but continue and add those entries that did not contain errors
• -x: use simple authentication
• -W: prompt for the bind password
• -f filename: get entries from filename
• -D'binddn: Bind using binddn -- essentially a username expressed in LDAP's language, using the full dn. For admin functions, this will be the rootdn you specified in your slapd.conf file.

In closing

Don't get frustrated if you get errors on your first import. Take a deep breath. Check your slapd.conf file. Make sure you're importing the correct schemas. And make sure your rootdn and password are right. If you've made changes to slapd.conf, remember that slapd needs to be restarted in order to see the changes. When all else fails, I've had tremendous success with simply pasting the errors into the Google search box and clicking Go. Usually, data import errors are minor flubs in configuration or a typo in your LDIF.

In the next edition, we'll look at the automation end of things, and add some really helpful tools to your directory administration toolbox. We'll also use those tools to start poking at our directory server and have some fun.

Share    Print    Comments