First, i am a noob to ldap and directory server. I have been at this for 30+ days in various scenarios to move off of directory server 8.2 to 11. In my latest iteration I am just trying to step through the major upgrades os/ds one at time to get to my end result. I am trying to replicate databases from directory server 8.2 to 9. I have followed the redhat documentation but still struggling. On the consumer, I am getting the error message, slapi_ldap_bind - error: could not bind id [cn=replication manager,cn=config] mech [SIMPLE]: error 48 (inappropriate authentication) errno 0 (Success)
I have changed the password do it wouldn't be too simple. Made sure that supplier dn is cn=replication manager,cn=config as well as simple bind userid. How can I check if security and what type is on supplier?
On 20 Feb 2020, at 07:35, Thaddeus Brown thadbrownsc@gmail.com wrote:
First, i am a noob to ldap and directory server.
All good, happy to have you here!
I have been at this for 30+ days in various scenarios to move off of directory server 8.2 to 11. In my latest iteration I am just trying to step through the major upgrades os/ds one at time to get to my end result. I am trying to replicate databases from directory server 8.2 to 9. I have followed the redhat documentation but still struggling. On the consumer, I am getting the error message, slapi_ldap_bind - error: could not bind id [cn=replication manager,cn=config] mech [SIMPLE]: error 48 (inappropriate authentication) errno 0 (Success)
I have changed the password do it wouldn't be too simple. Made sure that supplier dn is cn=replication manager,cn=config as well as simple bind userid. How can I check if security and what type is on supplier?
On the consumer, you should check the cn=replication manager,cn=config exists, and you can do an ldapwhoami -H ldaps://consumer.ldap.example.com -D "cn=replication manager,cn=config" -w -x
On the supplier you need to look for the replication agreements, you can use ldapsearch -H ldaps://supplier.ldap.example.com -D 'cn=Directory Manager' -b cn=config -x -w '(objectClass=nsds5ReplicationAgreement)' to show these. You need to check the bind method is SIMPLE, the bind dn is correct, and the nsds5replicacredentials is correct password. It's also worth checking the port and hostnames too.
For replication logging you can set the error log level to 8192 in cn=config as well.
As always, if possible create a "staging" or "development" environment that matches your production, and try things out there too.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/h...
Hope that helps, if you have more questions, please let us know!
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
On 2/19/20 10:35 PM, Thaddeus Brown wrote:
First, i am a noob to ldap and directory server. I have been at this for 30+ days in various scenarios to move off of directory server 8.2 to 11. In my latest iteration I am just trying to step through the major upgrades os/ds one at time to get to my end result. I am trying to replicate databases from directory server 8.2 to 9. I have followed the redhat documentation but still struggling. On the consumer, I am getting the error message, slapi_ldap_bind - error: could not bind id [cn=replication manager,cn=config] mech [SIMPLE]: error 48 (inappropriate authentication) errno 0 (Success)
Hi,
the supplier fails to authenticate on the consumer. It tries to authenticate with 'cn=replication manager,cn=config" using simple authentication. Does 'cn=replication manager,cn=config" entry exist ? does it contain a userpassword ?
best regards thierry
I have changed the password do it wouldn't be too simple. Made sure that supplier dn is cn=replication manager,cn=config as well as simple bind userid. How can I check if security and what type is on supplier?
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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@lists.fedoraproject....
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.
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.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/h...
On 21 Feb 2020, at 00:28, Thad thadbrownsc@gmail.com 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/ht...
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
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.
Thanks for the help.
389-users@lists.fedoraproject.org
-
Thad -
Thaddeus Brown
-
thierry bordaz -
William Brown