Stephen Walton wrote:
> objectClass: topYeah, but I can't use it. Consider the following LDIF:
dn: uid=testuser,ou=people,dc=domain,dc=com
objectClass: person* from 'core': a STRUCTURAL class (SUP top)
objectClass: organizationalPerson* from 'core': a STRUCTURAL class (SUP person)
objectClass: inetOrgPerson* from 'inetorgperson': a STRUCTURAL class (SUP organizationalPerson)
objectClass: posixAccount* from 'nis': an AUXILIARY class (SUP top)
objectClass: account* from 'cosine': a STRUCTURAL class (SUP top)
objectClass: shadowAccount
* from 'nis': an AUXILIARY class (SUP top)
Ok... so right off the bat we can ignore top, person, and organizationalPerson (like LDAP will) because they are already incorporated by reference from inetOrgPerson. That leaves us with:
objectClass: inetOrgPerson objectClass: account objectClass: posixAccount objectClass: shadowAccount
ldapadd gives the following error on FC1, though the above is identical to what I was using on RH8:
adding new entry "uid=testuser,ou=people,dc=domain,domain=com" ldapadd: update failed: uid=testuser,ou=people,dc=domain,dc=com ldap_add: Object class violation (65) additional info: invalid structural object class chain (inetOrgPerson/account)
Exactly, it's telling you that having two STRUCTURAL classes (inetOrgPerson and account), is illegal in the new, stricter, LDAP.
In this case, you'd want to drop 'account' because it isn't really adding anything.
The problem is that the following is also illegal: objectClass: posixAccount objectClass: shadowAccount
Because it has -no- structural objectclass. In this case (perhaps system accounts neccessary for running a SAMBA PDC) you might want to use 'account' rather than 'inetOrgPerson', since these aren't people and don't need all the 'people-ish' extra attributes.
Now we're into the hairy details of how LDAP works. I may never get this far; I'm just an astronomer pressed into part-time sysadmin service. But if I understand correctly, the 'testuser' LDIF above would, if I delete the 'objectclass: account' line, contain no structural class at all, which is strictly speaking illegal. Yes?
I know several astronomers... it's a fine and noble pursuit.
"Unfortunately" I am a full-time sysadmin, and thus get to learn all of this brain numbing stuff...
As I just explained, you missed that inetOrgPerson is also structural.
That's good to know, thanks. One further question if I may: since RH9 I've been seeing lines in /var/log/messages like:
Jan 8 14:23:55 server automount[21351]: lookup(ldap): query succeeded, no matches for (&(objectclass=nisObject)(cn=/))
These appear to do no harm other than showing up in logwatch output but I'm curious as to their source. I suspect some problem with my automount maps.
You'll get these if you have:
automount: files ldap
listed in your /etc/nsswitch.conf but don't have the automount info (specifically auto.master) in LDAP. I don't use LDAP for my automount info currently, but I think it's supposed to look something like this (I used the migrate_automount.pl script):
dn: nisMapName=auto.master,dc=padl,dc=com objectClass: nisMap nisMapName: auto.master
dn: cn=/mnt/fulcrum,nisMapName=auto.master,dc=padl,dc=com objectClass: nisObject cn: /mnt/fulcrum nisMapEntry: /etc/auto.home nisMapName: auto.master
dn: nisMapName=auto.home,dc=padl,dc=com objectClass: nisMap nisMapName: auto.home
dn: cn=home,nisMapName=auto.home,dc=padl,dc=com objectClass: nisObject cn: home nisMapEntry: -fstype=nfs,rsize=8192,wsize=8192,intr home:/vol/home nisMapName: auto.home
dn: cn=scratch1,nisMapName=auto.home,dc=padl,dc=com objectClass: nisObject cn: scratch1 nisMapEntry: -fstype=nfs,rsize=8192,wsize=8192,intr netscratch:/home/mnt nisMapName: auto.home
