at and cron vs. ldap SOLUTION!!

[Bevan C. Bennett]

Stephen Walton wrote:

> Yeah, but I can't use it.  Consider the following LDIF:
> 
> dn: uid=testuser,ou=people,dc=domain,dc=com
 > objectClass: top
> 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