Re: Single Master Replication Authentication Issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> On 21 Feb 2020, at 00:28, Thad <thadbrownsc@xxxxxxxxx> wrote:
> 
> Ok. Thanks William and Thierry. I took a look back at the entry in dse.ldif and somehow my userPassword entry didn't save. I put it back and carefully put in a new complex (not too much) password and restarted everything. It is working now so it was missing field in the dse file and a password issue. 

dse.ldif is written by the server on shutdown. So you either need to ldapmodify via cn=config while the server is running, or stop dirsrv, change dse.ldif, and the start it again. If you make a change to dse.ldif wile the server is running, it's "blown away" on shutdown as we write out the consistent in memory dse.ldif. That could be why the change disappeared. 

> 
> Now I have and issue with replication. Specifically "Replication error acquiring replica. replica busy error code 1."  This is in the Consumer initialization status area. in the Status field last update message is "Replica acquired successfully. Incremental update succeeded." This for both NetscapeRoot and userRoot.
> 
> However I think I see the issue. When setting up the replication agreement the FQDN for the supplier is automatically given. Since both servers are named the same thing (based on the documentation) shouldn't this cause an issue? 
> 
> 
> I just re-read the documentation again...like I said newbie here. It seems I put the agreement on the consumer and I should have created it on the supplier server to push the data to the consumer. The flow of instructions here wasn't crystal clear to me. So now I am configuring the agreement on the the supplier. The error message I am receiving now is "Consumer server unreachable or invalid credentials supplied. Unable to perform subtree duplication verification." And I think have figured it out, the supplier can reach out to consumer but the traffic isn't coming back. So going to add an entry to the consumer /etc/hosts file and get back with the results.


I'd say look at the DS 10 and DS 11 docs. 

We did a lot of work through DS 10 and 11 with the docs and we have documented a lot more on the lifecycles such as removal of a replica in a topology. This in mind, ds 11 has a new CLI suite so the commands may not match what you have, so DS 10 could be better to look at.

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/removing-supplier-cleanly


> 
> Glad to say replication is working now. It looks like all of the entries have been replicated. I will keep checking for any errors. Once I got the replication agreement on the correct side I ran into some LDAP issues but worked through them. Not sure why the userPassword field on the replication manager entry kept disappearing but had to edit dse.ldif and enter it again. Next up is decommissioning the master server and repeating the whole process a few more times until I am on a current version. So pretty sure you will be hearing from me again if I can't find any good decommission documentation of master/replica setup.


See above - you need to stop dirsrv, edit dse.ldif, then start it OR use ldapmodify on cn=config.

Hope that helps! 

> 
> Thanks for the help. 

> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux