Timestamps in LDAP are generally represented by a string of digits followed by Z. This is approximately an ISO 8601 format (ISO puts a T between the date and time). It breaks down as in: 20110523133732Z YYYYMMDDHHMMSSZ 2011 year 05 month 23 day of month 13 hour 37 minute 32 second Z indicates UTC (aka Zulu)

See: http://en.wikipedia.org/wiki/Iso_time#Combined_date_and_time_representations

Fat fingered from my iPad -- miscorrections happen.

On May 20, 2011, at 9:54, "Andrea Modesto Rossi" amrossi@linux.it wrote:

Hi all,

i've got a 389 installation up and running on Centos 5.6(i386) server.

I can define a password policy for subtree, then each users have some new fields such as PasswordHistory, PasswordMaxAge and so on.

My question, for example.

PasswordAllowChangeTime: 20110523133732Z

Whhat does it mean? OK:

2011: year 05: May, month

but what *23133732Z* is?

Thank you very much for your help!

Have a nice weekend.

Ciao

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

On 08/03/2011 08:09 AM, Andrea Modesto Rossi wrote:

Hi All,

i have a 389 DS installation deployed in 3 Server with MultiMaster Replication. It seems to be everything OK: if i change the password on Server A, i will have the same password on B and C too. But i have seen that there is a problem with others attributes, for example: passwordRetryCount

Indeed, i try to go to Server A by SSH with wrong password, then passwordRetryCount: 1:

[rossi@ServerA ~]$ ldapsearch -x -ZZ uid=PIPPO passwordRetryCount # extended LDIF # # LDAPv3 # base<> with scope subtree # filter: uid=PIPPO # requesting: passwordRetryCount #

# PIPPO, suppo.com dn: uid=PIPPO,ou=People,dc=it,dc=suppo,dc=boh passwordRetryCount: 1

# search result search: 3 result: 0 Success

# numResponses: 2 # numEntries: 1

But, on the Server B i have "passwordRetryCount == 0" yet. In my opinion this fild (passwordRetryCount) is not replicated.

[rossi@ServerB ~]$ ldapsearch -x -ZZ uid=PIPPO passwordRetryCount # extended LDIF # # LDAPv3 # base<> with scope subtree # filter: uid=PIPPO # requesting: passwordRetryCount #

# PIPPO, suppo.com dn: uid=PIPPO,ou=People,dc=it,dc=suppo,dc=boh

# search result search: 3 result: 0 Success

# numResponses: 2 # numEntries: 1

Any IDEA in order to solve this issue? maybe (i think it) should be an error of the Agreement policy..or not?

See http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...

Please help me :-D

have a nice day,

On Gio, 4 Agosto 2011 9:54 am, Andrea Modesto Rossi wrote:

On Mer, 3 Agosto 2011 8:21 pm, Rich Megginson wrote:

...

See http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...

It works now. Thank you veru much Rich.

have a nice day

Unfortunately i have a strange issue, because if i try to login to ServerA with wrong password then passwordRetryCount change from 0 to 1 in all my 3 LDAP Server (replication is OK) but the same operation on ServerB ( su - <user> with wrong password) does not provide any change on passwordRetryCount (always == 1). This happen with ssh, and local login as well!

Having 3 server with Multi_Master[1] replica i have changed this entry on all Servers:

dn: cn=config changetype: modify replace: passwordIsGlobalPolicy passwordIsGlobalPolicy: on

Any idea?

Thank you very much

[1] Replica:Agreement Schema: ServerA-->ServerB ServerA-->ServerC ServerB-->ServerA ServerB-->ServerC ServerC-->ServerA ServerC-->ServerB

On Gio, 4 Agosto 2011 4:35 pm, Rich Megginson wrote:

No. I guess check your access log to see if the same operation is sent to serverB as was sent to serverA.

Solved! It works fine now...

The problem was that i did not enable the "fine-grained password policy" on Server B and C:

In the directory server GUI --> go to configure tab --> "Data" --> then "Enable fine-grained password policy"

I hope this can help someone in the future.

Thank you very much.

Ciao Ciao,

On 05/20/2011 08:43 AM, Rich Megginson wrote:

On 05/20/2011 05:18 AM, Jim Tyrrell wrote:

...

Hi,

We have a setup with multiple masters which are replicating down to 389 Directory Server consumers via 2 hubs, but have a consistency issue.

It appears a few objects were deleted and re-added to the masters but the object was not deleted from the 389 consumers. We now have 1 object on the masters and 2 objects on the consumers which causes problems for the mail servers. If we delete the object from the master we are still left with one object on the slaves. The slaves currently have a few duplicate objects like this:

dn: cn=mx::10, cn=somedomain.co.uk, ou=dns, o=acmesystems.com cn: mx::10 mailtransport: nexthop:[mailserver.ourdomain.com] dnspreference: 10 dnstype: MX

dn: nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk, ou=dns,o=acmesystems.com cn: mx::10 mailtransport: nexthop:[mailserver.ourdomain.com] dnspreference: 10 dnstype: MX

The object showing nsuniqueid is the valid one that exists on the master. Is there a way to remove the 2nd object from the consumer without re-initialising?

not sure, but you could try this

1. make sure no supplier will attempt to send updates - you can do this

by "suspending" replication - how it works is that you first do a search on the suppliers for the replication agreement for this server a) ldapsearch -x -D "cn=directory manager" -W -b cn=config "objectclass=nsds5replicationagreement" find the one for your consumer, then note the dn: b) use ldapmodify to change the replication schedule to be "not now": ldapmodify -x -D "cn=directory manager" -W<<EOF dn: the dn of the replication agreement changetype: modify replace: nsds5replicaupdateschedule nsds5replicaupdateschedule: 2358-2359 0 EOF

2. shutdown the server you are attempting to fix
3. edit dse.ldif - find the mapping tree entry for the suffix

cn=somedomain.co.uk, ou=dns,o=acmesystems.com - change nsslapd-state: backend 4) start the server 5) ldapdelete -x -D "cn=directory manager" -W "nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk,

ou=dns,o=acmesystems.com"

or any other modify operation you might need to do

Whoops - almost forgot these steps, before resuming replication 6) stop the server 7) edit the mapping tree entry again - change nsslapd-state: referral on update 8) start the server then resume replication as below

6. on the suppliers, "resume" replication

ldapmodify -x -D "cn=directory manager" -W<<EOF dn: the dn of the replication agreement changetype: modify replace: nsds5replicaupdateschedule nsds5replicaupdateschedule: 0000-2359 0123456 EOF

see also http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...

...

I have seen this before on a single consumer so we re-initialised it, but its a much bigger problem to re-initialise all of the consumers. It would be ideal if there is a way to manually delete an object direct on a consumer?

Thanks.

Jim.

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

On 05/20/2011 09:20 AM, Jim Tyrrell wrote:

On 20/05/2011 15:47, Rich Megginson wrote:

...

On 05/20/2011 08:43 AM, Rich Megginson wrote:

...

On 05/20/2011 05:18 AM, Jim Tyrrell wrote:

...

Hi,

We have a setup with multiple masters which are replicating down to 389 Directory Server consumers via 2 hubs, but have a consistency issue.

It appears a few objects were deleted and re-added to the masters but the object was not deleted from the 389 consumers. We now have 1 object on the masters and 2 objects on the consumers which causes problems for the mail servers. If we delete the object from the master we are still left with one object on the slaves. The slaves currently have a few duplicate objects like this:

dn: cn=mx::10, cn=somedomain.co.uk, ou=dns, o=acmesystems.com cn: mx::10 mailtransport: nexthop:[mailserver.ourdomain.com] dnspreference: 10 dnstype: MX

dn: nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk,

ou=dns,o=acmesystems.com cn: mx::10 mailtransport: nexthop:[mailserver.ourdomain.com] dnspreference: 10 dnstype: MX

The object showing nsuniqueid is the valid one that exists on the master. Is there a way to remove the 2nd object from the consumer without re-initialising?

not sure, but you could try this

1. make sure no supplier will attempt to send updates - you can do this

by "suspending" replication - how it works is that you first do a search on the suppliers for the replication agreement for this server a) ldapsearch -x -D "cn=directory manager" -W -b cn=config "objectclass=nsds5replicationagreement" find the one for your consumer, then note the dn: b) use ldapmodify to change the replication schedule to be "not now": ldapmodify -x -D "cn=directory manager" -W<<EOF dn: the dn of the replication agreement changetype: modify replace: nsds5replicaupdateschedule nsds5replicaupdateschedule: 2358-2359 0 EOF

2. shutdown the server you are attempting to fix
3. edit dse.ldif - find the mapping tree entry for the suffix

cn=somedomain.co.uk, ou=dns,o=acmesystems.com - change nsslapd-state: backend 4) start the server 5) ldapdelete -x -D "cn=directory manager" -W "nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk,

ou=dns,o=acmesystems.com"

or any other modify operation you might need to do

Whoops - almost forgot these steps, before resuming replication 6) stop the server 7) edit the mapping tree entry again - change nsslapd-state: referral on update 8) start the server then resume replication as below

...

6. on the suppliers, "resume" replication

ldapmodify -x -D "cn=directory manager" -W<<EOF dn: the dn of the replication agreement changetype: modify replace: nsds5replicaupdateschedule nsds5replicaupdateschedule: 0000-2359 0123456 EOF

see also http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...

...

I have seen this before on a single consumer so we re-initialised it, but its a much bigger problem to re-initialise all of the consumers. It would be ideal if there is a way to manually delete an object direct on a consumer?

Thanks.

Jim.

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

Thanks for the info - I will give that a go.

I had been thinking about this and wondered if another solution would be to resurrect the tombstone entry on the master server and then perform a delete via the master? Is that possible - would removing the ObjectClass of nsTombstone undelete it and re-add it to the index? I have searched and found some mentions of doing that in Active Directory..

not sure - I suppose you could try it

Ta.

Jim.

On 05/23/2011 06:30 AM, Jim Tyrrell wrote:

On 20/05/2011 15:47, Rich Megginson wrote:

...

On 05/20/2011 08:43 AM, Rich Megginson wrote:

...

On 05/20/2011 05:18 AM, Jim Tyrrell wrote:

...

Hi,

We have a setup with multiple masters which are replicating down to 389 Directory Server consumers via 2 hubs, but have a consistency issue.

It appears a few objects were deleted and re-added to the masters but the object was not deleted from the 389 consumers. We now have 1 object on the masters and 2 objects on the consumers which causes problems for the mail servers. If we delete the object from the master we are still left with one object on the slaves. The slaves currently have a few duplicate objects like this:

dn: cn=mx::10, cn=somedomain.co.uk, ou=dns, o=acmesystems.com cn: mx::10 mailtransport: nexthop:[mailserver.ourdomain.com] dnspreference: 10 dnstype: MX

dn: nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk, ou=dns,o=acmesystems.com cn: mx::10 mailtransport: nexthop:[mailserver.ourdomain.com] dnspreference: 10 dnstype: MX

The object showing nsuniqueid is the valid one that exists on the master. Is there a way to remove the 2nd object from the consumer without re-initialising?

not sure, but you could try this

1. make sure no supplier will attempt to send updates - you can do this

by "suspending" replication - how it works is that you first do a search on the suppliers for the replication agreement for this server a) ldapsearch -x -D "cn=directory manager" -W -b cn=config "objectclass=nsds5replicationagreement" find the one for your consumer, then note the dn: b) use ldapmodify to change the replication schedule to be "not now": ldapmodify -x -D "cn=directory manager" -W<<EOF dn: the dn of the replication agreement changetype: modify replace: nsds5replicaupdateschedule nsds5replicaupdateschedule: 2358-2359 0 EOF

2. shutdown the server you are attempting to fix
3. edit dse.ldif - find the mapping tree entry for the suffix

cn=somedomain.co.uk, ou=dns,o=acmesystems.com - change nsslapd-state: backend 4) start the server 5) ldapdelete -x -D "cn=directory manager" -W "nsuniqueid=7edfa581-1dd211b2-8014f995-55bd0000+cn=mx::10,cn=somedomain.co.uk,

ou=dns,o=acmesystems.com"

or any other modify operation you might need to do

Whoops - almost forgot these steps, before resuming replication 6) stop the server 7) edit the mapping tree entry again - change nsslapd-state: referral on update 8) start the server then resume replication as below

...

6. on the suppliers, "resume" replication

ldapmodify -x -D "cn=directory manager" -W<<EOF dn: the dn of the replication agreement changetype: modify replace: nsds5replicaupdateschedule nsds5replicaupdateschedule: 0000-2359 0123456 EOF

see also http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/A...

...

I have seen this before on a single consumer so we re-initialised it, but its a much bigger problem to re-initialise all of the consumers. It would be ideal if there is a way to manually delete an object direct on a consumer?

Thanks.

Jim.

I tried the method to make the consumer effectively a master allowing updates but it didnt work. There is no entry in dse.ldif for "cn=somedomain.co.uk,ou=dns,o=acmesystems.com" so I assume I should be editing the parent of that object ie:

dn: cn="o=acmesystems.com",cn=mapping tree, cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree nsslapd-state: referral on update cn: "o=acmesystems.com" nsslapd-backend: acmeldap numSubordinates: 1 nsslapd-referral: ldap://Master2.eclipse.net.uk:389/o%3Dacmesystems.com nsslapd-referral: ldap://Master1.eclipse.net.uk:389/o%3Dacmesystems.com

I shutdown ldap, changed "referral on update" to "Backend" (also tried removing nsslapd-referral) and then restarted LDAP but the dse.ldif config seems to revert back to the original each time. The exact file I am editing is:

/etc/dirsrv/slapd-consumer01/dse.ldif

Is there another file I should be editing?

No. That is the right entry and the right file. Are you sure the server is not running when you edit the file? If you edit the file while the server is running your edits will be lost.

If you're sure the server is stopped, then it must be something done automatically by the replication code. Try this: 1) stop the server 2) find the entry the Multimaster Replication plugin 3) set nsslapd-pluginEnabled: off 4) edit the mapping tree entry above to make it nsslapd-state: backend

Thanks.

Jim.

-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users