LDIF syntax explanation: Difference between revisions

From SaruWiki
Jump to navigation Jump to search
(Page started)
 
(completed group object description)
Line 33: Line 33:
The first set of six lines describe an object of class posixGroup. The posixGroup class is part of the NIS schema, and an object of this class is "an abstraction of a group of accounts" (according to the description with the class definition. This means that in our example, the object with distinguished name ''cn=networkusers,ou=groups,dc=saruman,dc=biz'' will be a representation of a group as we know it from ''/etc/group''. So how do the six lines create this group?
The first set of six lines describe an object of class posixGroup. The posixGroup class is part of the NIS schema, and an object of this class is "an abstraction of a group of accounts" (according to the description with the class definition. This means that in our example, the object with distinguished name ''cn=networkusers,ou=groups,dc=saruman,dc=biz'' will be a representation of a group as we know it from ''/etc/group''. So how do the six lines create this group?


# The first line begins with a hash sign (#) making it a comment. It does nothing to create the object, only to clarify the LDIF file. We recomment strongly in favour of using comments, whenever your LDIF file must be kept longer than 10 minutes after creation :-).
# '''dn:''' means the Distinguished Name; it tells the LDIF that this is the dn with which to address the object.
# '''objectClass:''' this defines what attributes the object must and may have. Want to know which attributes? Look into /etc/ldap/schema/nis.schema and find the string 'posixGroup'. You'll see that the mandatory attributes are ''cn'' and ''gidNumber'', and optional attributes ''userPassword'', ''memberUid'' and ''description''
# '''description:''' hey, that's one of them optional attributes! It has no equivalent in the Posix ''group'' definition, but it can ofcourse clarify the purpose of said group in the LDAP directory.
# '''gidNumber:''' mandatory attribute, that holds the "numerical value of the group's ID"
# '''cn:''' this is the second mandatory attribute, and holds the name of the group


Since there's an empty line after these six lines, the rest of the LDIF file does not concern the group object; all adjacent lines are held to be a declaration of one single object.
It should be clear that the above information is sufficient to create in LDAP an object that holds all information that any POSIX compliant group would need. Creating an object of type posixGroup in this manner makes it possible to use the object in LDAP as if it were a group on the local Linux/UNIX machine.


== User object attributes ==
== User object attributes ==
The next section of this particular LDIF file consists of 21 adjacent lines, of which five begin with a hash sign. The other 16 lines comprise the actual object. So how does this object form in LDAP when you feed it this LDIF file?

Revision as of 21:16, 26 September 2008

Suppose you use an LDIF file like this:

# Create the user group
dn: cn=networkusers,ou=groups,dc=saruman,dc=biz
objectClass: posixGroup
description: Internal network users
gidNumber: 10001
cn: TestGroup

# Create a new user:
dn: uid=sixpacjo,ou=people,dc=saruman,dc=biz
objectclass: top
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: shadowAccount
cn: Joe Sixpack
description: Your Average Network User
givenName: Joe
sn: Sixpack
mail: joe.sixpack@saruman.biz
# The Unix login-name for the user:
uid: sixpacjo
# The group and user IDs:
gidNumber: 10001
uidNumber: 10001
# The Unix account data:
homeDirectory: /home/sixpacjo
loginShell: /bin/bash
# The encrypted password for the user:
userPassword: {crypt}$1$qs70ynbk$UBuewN7ZdIvqavIxkxdmX0

What are you then actually doing? Well, you're adding two objects; the different attributes in this LDIF file are explained below.

Group object attributes

The first set of six lines describe an object of class posixGroup. The posixGroup class is part of the NIS schema, and an object of this class is "an abstraction of a group of accounts" (according to the description with the class definition. This means that in our example, the object with distinguished name cn=networkusers,ou=groups,dc=saruman,dc=biz will be a representation of a group as we know it from /etc/group. So how do the six lines create this group?

  1. The first line begins with a hash sign (#) making it a comment. It does nothing to create the object, only to clarify the LDIF file. We recomment strongly in favour of using comments, whenever your LDIF file must be kept longer than 10 minutes after creation :-).
  2. dn: means the Distinguished Name; it tells the LDIF that this is the dn with which to address the object.
  3. objectClass: this defines what attributes the object must and may have. Want to know which attributes? Look into /etc/ldap/schema/nis.schema and find the string 'posixGroup'. You'll see that the mandatory attributes are cn and gidNumber, and optional attributes userPassword, memberUid and description
  4. description: hey, that's one of them optional attributes! It has no equivalent in the Posix group definition, but it can ofcourse clarify the purpose of said group in the LDAP directory.
  5. gidNumber: mandatory attribute, that holds the "numerical value of the group's ID"
  6. cn: this is the second mandatory attribute, and holds the name of the group

Since there's an empty line after these six lines, the rest of the LDIF file does not concern the group object; all adjacent lines are held to be a declaration of one single object.

It should be clear that the above information is sufficient to create in LDAP an object that holds all information that any POSIX compliant group would need. Creating an object of type posixGroup in this manner makes it possible to use the object in LDAP as if it were a group on the local Linux/UNIX machine.

User object attributes

The next section of this particular LDIF file consists of 21 adjacent lines, of which five begin with a hash sign. The other 16 lines comprise the actual object. So how does this object form in LDAP when you feed it this LDIF file?