Consumer Initialization Failure

[Wick, Samson]

Running 389-ds version 1.2.2-1 (according to the rpm)

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

[Rich Megginson]

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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Wick, Samson]

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?

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?

Thanks

From: Rich Megginson [mailto:[e-mail]]
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

[e-mail]

https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

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:[e-mail]]
> *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
> [e-mail]  
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Wick, Samson]

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.

Is there a way to verify that these are being trimmed like they should?  Does this behavior have something to do with the replica’s “Purge Delay” value?

Is there  a way to find date and time from the vucsn number?

Is there a way to manually purge these entries, or to shorten the interval between trimmings?

Thanks

From: Rich Megginson [mailto:[e-mail]]
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:[e-mail]]
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

[e-mail]

https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

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:[e-mail]]
> *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:[e-mail]]
> *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
> [e-mail]  
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Wick, Samson]

Here is the full output of ‘rpm -qi 389-ds-base’:

Name        : 389-ds-base                  Relocations: (not relocatable)
Version     : 1.2.10.12                         Vendor: (none)
Release     : 1.el6                         Build Date: Thu 28 Jun 2012 11:24:45 AM CDT
Install Date: Mon 06 Aug 2012 04:01:03 PM CDT      Build Host: vmhost
Group       : System Environment/Daemons    Source RPM: 389-ds-base-1.2.10.12-1.el6.src.rpm
Size        : 4852149                          License: GPLv2 with exceptions
Signature   : (none)
URL         : http://port389.org/
Summary     : 389 Directory Server (base)
Description :
389 Directory Server is an LDAPv3 compliant server.  The base package includes
the LDAP server and command line utilities for server administration.

I have my purge delay set to 7 days on all replicas, and based on the date information on the oldest entries “vucsn-520c709e000000010000”, this doesn’t appear to be getting enforced.  What’s the next step I should take in determining why?

I’m not sure if it’s relevant, but I did notice a bad RUV entry while troubleshooting this:

[root@ldap1 slapd-ldap1]# ldapsearch -xLLL -h localhost -D "cn=directory manager" -W -b dc=ds,dc=example,dc=com  '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' | sed ':a;N;$!ba;s/\n //g'
Enter LDAP Password:
dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=ds,dc=west,dc=com
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 501c4709000000020000
nsds50ruv: {replica 1 ldap://ldap1.ds.example.com:389} 5021267f000000010000 52260a24000100010000
nsds50ruv: {replica 5 ldap://ldap5.ds.example.com:389}
nsds50ruv: {replica 2 ldap://ldap2.ds.example.com:389} 502505f1000000020000 522607ee000000020000
nsds50ruv: {replica 65535 ldap://lab-ldap1.ds.example.com:389} 5069a6bc0000ffff0000 5069a6bc0000ffff0000
nsds50ruv: {replica 4 ldap://ldap4.ds.example.com:389} 512b8650000000040000 515f081d000000040000
nsds50ruv: {replica 3 ldap://ldap3.ds.example.com:389} 512650e1000000030000 51c357e9000000030000
dc: ds
nsruvReplicaLastModified: {replica 1 ldap://ldap1.ds.example.com:389} 52260a22
nsruvReplicaLastModified: {replica 5 ldap://ldap5.ds.example.com:389} 00000000
nsruvReplicaLastModified: {replica 2 ldap://ldap2.ds.example.com:389} 522607eb
nsruvReplicaLastModified: {replica 65535 ldap://lab-ldap1.ds.example.com:389} 00000000
nsruvReplicaLastModified: {replica 4 ldap://ldap4.ds.example.com:389} 00000000
nsruvReplicaLastModified: {replica 3 ldap://ldap3.ds.example.com:389} 00000000

The replica “65535” was removed from the environment some time ago and the server is long gone, but evidently never purged from the directory.

Per instructions on the 389-ds site, I attempted to run CLEANRUV with this LDIF:

dn: cn=replica,cn=dc\3Dds\2Cdc\3Dwest\2Cdc\3Dcom,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task: CLEANRUV65535

And got this response:

[root@ldap1 etc]# ldapmodify -h localhost -D "cn=directory manager" -W -f /etc/ruvclean
Enter LDAP Password:
modifying entry "cn=replica,cn=dc\3Dds\2Cdc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config"
ldap_modify: Operations error (1)
        additional info: Invalid replica id for task - CLEANRUV65535

It’s good to know that it’s safe to remove the vucsn entries from the import file, however I’m hoping to be able to use the option to directly initialize consumers from the supplier again, so it’s important that I get them cleaned up on the supplier side.

Thanks for your help!
-Samson-

From: Rich Megginson [mailto:[e-mail]]
Sent: Tuesday, September 03, 2013 10:44 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 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:[e-mail]]
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:[e-mail]]
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

[e-mail]

https://admin.fedoraproject.org/mailman/listinfo/389-users

[Rich Megginson]

On 09/03/2013 10:27 AM, Wick, Samson wrote:
> Here is the full output of ‘rpm -qi 389-ds-base’:
>
> Name        : 389-ds-base                  Relocations: (not relocatable)
>
> Version     : 1.2.10.12                         Vendor: (none)
>
> Release     : 1.el6                         Build Date: Thu 28 Jun 
> 2012 11:24:45 AM CDT
>
> Install Date: Mon 06 Aug 2012 04:01:03 PM CDT      Build Host: vmhost
>
> Group       : System Environment/Daemons    Source RPM: 
> 389-ds-base-1.2.10.12-1.el6.src.rpm
>
> Size        : 4852149                          License: GPLv2 with 
> exceptions
>
> Signature   : (none)
>
> URL         : http://port389.org/
>
> Summary     : 389 Directory Server (base)
>
> Description :
>
> 389 Directory Server is an LDAPv3 compliant server.  The base package 
> includes
>
> the LDAP server and command line utilities for server administration.

I would suggest you upgrade to the epel6 testing version.
> I have my purge delay set to 7 days on all replicas, and based on the 
> date information on the oldest entries “vucsn-520c709e000000010000”, 
> this doesn’t appear to be getting enforced.  What’s the next step I 
> should take in determining why?

For meta-data in individual entries, purging is supposed to occur when 
the entry is updated.
> I’m not sure if it’s relevant, but I did notice a bad RUV entry while 
> troubleshooting this:
>
> [root@ldap1 slapd-ldap1]# ldapsearch -xLLL -h localhost -D 
> "cn=directory manager" -W -b dc=ds,dc=example,dc=com 
> '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' 
> | sed ':a;N;$!ba;s/\n //g'
>
> Enter LDAP Password:
>
> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,dc=ds,dc=west,dc=com
>
> objectClass: top
>
> objectClass: nsTombstone
>
> objectClass: extensibleobject
>
> nsds50ruv: {replicageneration} 501c4709000000020000
>
> nsds50ruv: {replica 1 ldap://ldap1.ds.example.com:389} 
> 5021267f000000010000 52260a24000100010000
>
> nsds50ruv: {replica 5 ldap://ldap5.ds.example.com:389}
>
> nsds50ruv: {replica 2 ldap://ldap2.ds.example.com:389} 
> 502505f1000000020000 522607ee000000020000
>
> nsds50ruv: {replica 65535 ldap://lab-ldap1.ds.example.com:389} 
> 5069a6bc0000ffff0000 5069a6bc0000ffff0000
>
> nsds50ruv: {replica 4 ldap://ldap4.ds.example.com:389} 
> 512b8650000000040000 515f081d000000040000
>
> nsds50ruv: {replica 3 ldap://ldap3.ds.example.com:389} 
> 512650e1000000030000 51c357e9000000030000
>
> dc: ds
>
> nsruvReplicaLastModified: {replica 1 ldap://ldap1.ds.example.com:389} 
> 52260a22
>
> nsruvReplicaLastModified: {replica 5 ldap://ldap5.ds.example.com:389} 
> 00000000
>
> nsruvReplicaLastModified: {replica 2 ldap://ldap2.ds.example.com:389} 
> 522607eb
>
> nsruvReplicaLastModified: {replica 65535 
> ldap://lab-ldap1.ds.example.com:389} 00000000
>
> nsruvReplicaLastModified: {replica 4 ldap://ldap4.ds.example.com:389} 
> 00000000
>
> nsruvReplicaLastModified: {replica 3 ldap://ldap3.ds.example.com:389} 
> 00000000
>
> The replica “65535” was removed from the environment some time ago and 
> the server is long gone, but evidently never purged from the directory.
>
> Per instructions on the 389-ds site, I attempted to run CLEANRUV with 
> this LDIF:
>
> dn: cn=replica,cn=dc\3Dds\2Cdc\3Dwest\2Cdc\3Dcom,cn=mapping tree,cn=config
>
> changetype: modify
>
> replace: nsds5task
>
> nsds5task: CLEANRUV65535
>
> And got this response:
>
> [root@ldap1 etc]# ldapmodify -h localhost -D "cn=directory manager" -W 
> -f /etc/ruvclean
>
> Enter LDAP Password:
>
> modifying entry 
> "cn=replica,cn=dc\3Dds\2Cdc\3Dexample\2Cdc\3Dcom,cn=mapping 
> tree,cn=config"
>
> ldap_modify: Operations error (1)
>
> additional info: Invalid replica id for task - CLEANRUV65535

Yeah, this is a bug with CLEANRUV - 65535 is the value which denotes a 
read-only replica, so it's not supposed to be allowed.
> It’s good to know that it’s safe to remove the vucsn entries from the 
> import file, however I’m hoping to be able to use the option to 
> directly initialize consumers from the supplier again, so it’s 
> important that I get them cleaned up on the supplier side.
>
> Thanks for your help!
>
> -Samson-
>
> *From:*Rich Megginson [mailto:[e-mail]]
> *Sent:* Tuesday, September 03, 2013 10:44 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 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:[e-mail]]
> *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:[e-mail]]
> *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
> [e-mail]  
> https://admin.fedoraproject.org/mailman/listinfo/389-users

[Ludwig Krispenz]

The csn in vucsn-520b35cb000000010000 contains a hexadecimal timestamp 
in the first 8 characters: 520b35cb This one is Aug, 14th...

You could check if the timestamps of your 100k userpasswords is within 
the replicaPurgDelay to see if trimming did work.

You could also remove these lines from the ldif to import.

Ludwig

On 09/03/2013 05:30 PM, 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.
>
> Is there a way to verify that these are being trimmed like they 
> should? Does this behavior have something to do with the replica’s 
> “Purge Delay” value?
>
> Is there  a way to find date and time from the vucsn number?
>
> Is there a way to manually purge these entries, or to shorten the 
> interval between trimmings?
>
> Thanks
>
> *From:*Rich Megginson [mailto:[e-mail]]
> *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:[e-mail]]
> *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
> [e-mail]  
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389 users mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/389-users