On Thu, 2004-01-08 at 17:22, Bevan C. Bennett wrote:
> Eureka! Victory is ours!
Amazing, ain't it.
> There's still a generic 'account' objectClass in the 'cosine' schema.
Yeah, but I can't use it. Consider the following LDIF:
dn: uid=testuser,ou=people,dc=domain,dc=com
uid: testuser
userid: testuser
cn: Test User
givenName: Test
sn: User
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: account
objectClass: top
objectClass: shadowAccount
shadowMax: 99999
shadowFlag: 0
loginShell: /bin/bash
uidNumber: 1985
gidNumber: 502
homeDirectory: /home/testuser
gecos: Test User
userPassword: test1234
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)
> account is a fairly sparse STRUCTURAL class, while posixaccount and
> sambasamaccount are AUXILIARY.
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?
> The defaults work fine for most. It's case insensitive, so there's
> difference between 'people' and 'People'.
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.
Steve
--
Stephen Walton <stephen.walton@xxxxxxxx>
Dept. of Physics & Astronomy, Cal State Northridge
