On 09/03/2013 09:30 AM, Wick, Samson wrote:
The number of “userPassword;vucsn-#####;deleted:” for these three
particular users is apparently so high that it makes the object too
big to import into a new replica.
Understood.
Is there a way to verify that these are being trimmed like they
should?
The fact that they are there suggests that trimming is not taking place
as it should.
Does this behavior have something to do with the replica’s “Purge
Delay” value?
Yes.
Is there a way to find date and time from the vucsn number?
Yes. The first 8 bytes of the CSN are the time_t value.
Is there a way to manually purge these entries, or to shorten the
interval between trimmings?
For an import, I suppose you could just edit the ldif file to remove them.
Thanks
I would still like to know what version of 389-ds-base you are using -
rpm -qi 389-ds-base
>
> *From:*Rich Megginson [mailto:rmeggins@redhat.com]
> *Sent:* Tuesday, September 03, 2013 10:15 AM
> *To:* Wick, Samson
> *Cc:* General discussion list for the 389 Directory server project.
> *Subject:* Re: [389-users] Consumer Initialization Failure
>
> On 09/03/2013 08:47 AM, Wick, Samson wrote:
>
> It probably doesn’t make a lot of difference but I used:
>
> rpm -qi 389 and used the metadata to determine the version rather
> than the name of the rpm.
>
> What is the preferred method of determining version number?
>
>
> rpm -qi 389-ds-base
>
> Is there a good place I can go to educate myself on what a “vucsn”
> actually means, and possibly why I have hundreds of thousands of them
> for userPassword in my initialization files?
>
>
> It is replication meta-data which is supposed to be automatically trimmed.
>
>
Thanks
> *From:*Rich Megginson [mailto:rmeggins@redhat.com]
> *Sent:* Friday, August 30, 2013 2:43 PM
> *To:* General discussion list for the 389 Directory server project.
> *Cc:* Wick, Samson
> *Subject:* Re: [389-users] Consumer Initialization Failure
>
> On 08/30/2013 01:24 PM, Wick, Samson wrote:
>
> Running 389-ds version 1.2.2-1 (according to the rpm)
>
> rpm -q 389-ds-base
>
> version of 389-ds is almost meaningless
>
>
> In attempting to stand up a new consumer in our environment, the
> process of allowing the supplier to initialize the consumer directly
> would corrupt the consumer irrevocably.
>
> I have ruled out firewalls, SSL issues etc.
>
> When attempting to initialize via an ldif, I get errors on three user
> accounts more or less identical to this:
>
> WARNING: skipping entry “uid=<etc…..>” ending line 296901 of file
> “<path to my ldif file>”
>
> REASON: entry too large (15503712 bytes) for the buffer size (8388608
> bytes)
>
> When I examine the ldif file that the supplier created, the three user
> objects it’s complaining about all have +/- 100,000 entries like this:
>
> userPassword;vucsn-520b35cb000000010000;deleted:
> {SSHA256}5WJ9hosO3JO9VLa32nqxmGjn3XoShD1c1g+abekZDCFTX1MM187Bjg==
>
> Each line has a different hash. But most of the other user objects
> only have a couple of these lines.
>
> Clearly 100k+ password changes is a little excessive and it’s
> something I’ll need to look into, but in the meantime, can anyone help
> me figure out what has caused all of these to remain in the directory,
> and what can I do to clean them up?
>
> Thanks,
>
> Samson
>
>
>
>
>
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org>
>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>