LDIF syntax explanation: Difference between revisions
(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?
- 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
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?