FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 05-20-2011, 11:18 AM
Jim Tyrrell
 
Default Delete object on Consumer

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?

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
 
Old 05-20-2011, 02:43 PM
Rich Megginson
 
Default Delete object on Consumer

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

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/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts

> 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
 
Old 05-20-2011, 02:47 PM
Rich Megginson
 
Default Delete object on Consumer

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/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts
>
>> 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
 
Old 05-20-2011, 03:20 PM
Jim Tyrrell
 
Default Delete object on Consumer

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/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts
>>
>>> 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..

Ta.

Jim.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-20-2011, 03:40 PM
Rich Megginson
 
Default Delete object on Consumer

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/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts
>>>
>>>
>>>> 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.

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-23-2011, 12:30 PM
Jim Tyrrell
 
Default Delete object on Consumer

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/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts
>>
>>> 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?

Thanks.

Jim.





--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-23-2011, 02:27 PM
Rich Megginson
 
Default Delete object on Consumer

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/Administration_Guide/index.html#Managing_Replication-Solving_Common_Replication_Conflicts
>>>
>>>> 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

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

Thread Tools




All times are GMT. The time now is 05:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org