Re: entry has multiple objectClass attributes

["Pierangelo Masarati" <ando@sys-net.it>]

> Agreed. Do you think I should file this as a bug?

Not really a bug, but I don't know why it was done; perhaps it's
a legacy of UMich stuff, since slurpd didn't receive as much
attention as slapd did by OpenLDAP developers.  I'd like to hear
from someone that knows the rationale behind it.

>
> Meanwhile, I've been delving a little deeper into this problem, and have
> I think figured out why it's not an issue when slurpd processes a replog
> created by slapd...
>
> slapd's replog includes a bunch of extra attributes, some of which I
> recognise,
> others are new to me:
>
> replica: localhost:9999
> time: 1042007086
> dn: dc=my-domain,dc=com
> changetype: add
> objectClass: dcObject
> objectClass: organization
> dc: my-domain
> o: my-domain # <-- This is the last of my attributes
> structuralObjectClass: organization
> entryUUID: a0a1acca-b71d-1026-87b3-ead925592f3d
> creatorsName: cn=Manager,dc=my-domain,dc=com
> createTimestamp: 20030108062446Z
> entryCSN: 2003010806:24:46Z#0x0001#0#0000
> modifiersName: cn=Manager,dc=my-domain,dc=com
> modifyTimestamp: 20030108062446Z
>
> The interesting attribute here is structuralObjectClass, as the error
> that
> I'm seeing is coming from a function that is attempting to determine the
> Structural Object Class... I'm still not 100% on why this is necessary,
> it's
> something to do with the internals of slapd, and it's new since I
> understood
> most of how slapd worked. I can easily add this attribute to the replog
> I
> create, I'm wondering if I should be adding entryCSN and entryUUID? What
> are the rules for the values of those attributes? What are they used
> for?

These are operational attributes that are automatically
generated/updated by slapd; you don't need to deal with
them.  Actually, you can't change them unless you authenticate
yourself to a slave as the updatedn.  Slurpd is not aware
of their special meaning, they're treated to all extents
as regular attributes.  But I'm afraid they won't be
generated if you log in as the updatedn, so we've a chicken
and egg problem.

>
> My original plan was to just create a replog with the changes I wanted,
> and to let slurpd apply them to the directory for me. I was hoping that
> the create and modify name and timestamp attributes would be added by
> the
> directory when slapd performed the operations specified (I wasn't going
> to specify updatedn on the target directory). Doesn't look like it's
> quite
> as simple as I had hoped.
>
> I know, slurpd isn't necessarily intended to be used in the way I'm
> using it,
> but it is very convenient as a way of handing off responsibility for
> getting
> updates done asynchronously and relatively reliably. I think it would
> be a
> good thing if this worked, without requiring the writer of the replog
> to jump
> through hoops and know how the internals of slapd work. The man page for
> slapd.replog seems to imply that this is something that you should be
> able
> to do, but it doesn't mention any of the extra attributes you need to
> include
> to make it work.
>
> So, should I file this as a bug? Is it a bug in slurpd or slapd or both?
>
> Alternatively, if I should be adding the magic attributes to my replog,
> can anyone tell me how I should construct the values for entry[CSN|UUID]
> and what those attributes are actually used for?

I suggest you don't use slurpd, and use
ldapadd/ldapmodify into a script that's run every now and
then; you may also find a way to trigger the script when
the replication log is modified.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it