Description of problem: In our environment we have configured chain-on-update on our clients ldap systems to chain updates to a hub ldap server. The hub ldap server is configured has configured two master ldap servers to chain updates too. nsfarmserverurl: ldap://serverA:389 ldap://serverB:389 If serverA becomes unavailable the updates are never sent to serverB. All authentications on the client systems fail. Updating nsframserverurl by removing serverA restores authentication and chaining resumes on serverB It is my understanding that defining multiple servers is to provide a level of redundancy in the event of failure to one of master servers. This is not working as expected Version-Release number of selected component (if applicable): 389-dsgw-1.1.4-1.el5 389-ds-console-1.2.0-5.el5 389-adminutil-1.1.8-4.el5 389-ds-base-1.2.5-1.el5 389-admin-console-1.1.4-3.el5 389-ds-console-doc-1.2.0-5.el5 389-console-1.1.3-6.el5 389-ds-1.1.3-6.el5 389-admin-1.1.10-1.el5 389-admin-console-doc-1.1.4-3.el5 How reproducible: We have been able to reproduce this in several of our environments using the 389 directory server Steps to Reproduce: 1. Configure two or more master ldap servers 2. Configure a hub ldap server 3. Configure a client ldap server 4. Follow the HowTo directions for ChainOnUpdate on the Hub server configure nsfarmserverurl to contain the two master ldap server urls 5. On the client system configure the client to chain updates to the Hub server 6. Verify authentication works correctly when both masters are available. On the client system perform a simple ldapsearch 7. Shutdown the first master server defined in nsfarmserverurl 8. Attempt to authenticate on the client system by using a simple ldapsearch Actual results: Authentication fails Expected results: Hub ldap server to rollover to second master ldap server allowing for authentications to succeed Additional info:
(In reply to comment #0) > Description of problem: > In our environment we have configured chain-on-update on our clients ldap > systems to chain updates to a hub ldap server. The hub ldap server is > configured has configured two master ldap servers to chain updates too. > > nsfarmserverurl: ldap://serverA:389 ldap://serverB:389 This is incorrect. The format should be nsfarmserverurl: ldap://serverA:389 serverB:389/ Is the documentation wrong? > > If serverA becomes unavailable the updates are never sent to serverB. All > authentications on the client systems fail. > > Updating nsframserverurl by removing serverA restores authentication and > chaining resumes on serverB > > It is my understanding that defining multiple servers is to provide a level of > redundancy in the event of failure to one of master servers. This is not > working as expected > > Version-Release number of selected component (if applicable): > 389-dsgw-1.1.4-1.el5 > 389-ds-console-1.2.0-5.el5 > 389-adminutil-1.1.8-4.el5 > 389-ds-base-1.2.5-1.el5 > 389-admin-console-1.1.4-3.el5 > 389-ds-console-doc-1.2.0-5.el5 > 389-console-1.1.3-6.el5 > 389-ds-1.1.3-6.el5 > 389-admin-1.1.10-1.el5 > 389-admin-console-doc-1.1.4-3.el5 > > How reproducible: > We have been able to reproduce this in several of our environments using the > 389 directory server > > Steps to Reproduce: > 1. Configure two or more master ldap servers > 2. Configure a hub ldap server > 3. Configure a client ldap server > 4. Follow the HowTo directions for ChainOnUpdate on the Hub server configure > nsfarmserverurl to contain the two master ldap server urls > 5. On the client system configure the client to chain updates to the Hub server > 6. Verify authentication works correctly when both masters are available. On > the client system perform a simple ldapsearch > 7. Shutdown the first master server defined in nsfarmserverurl > 8. Attempt to authenticate on the client system by using a simple ldapsearch > > Actual results: > Authentication fails > > > Expected results: > Hub ldap server to rollover to second master ldap server allowing for > authentications to succeed > > > Additional info:
No the information on the documentation is correct. We have our configuration incorrect. I made the assumption that the that "ldap://" was required for each server listed. Will test and verify later today.
Ok. Waiting for confirmation. I've done some testing of this. One thing I've found is that the first operation after one of the servers is down does not failover. Instead, the client gets an OPERATIONS_ERROR (err=1). Subsequent operations will succeed. So it does failover, just not as smoothly as it could.
I ran a test earlier today and with the corrected format and chain-on-upate is working correctly. I also noticed a sort period of errors with authentication which I believe is the issue that stated above (OPERATIONS_ERROR). After about 5 to 10 seconds slapd flips to the secondary server.
Thanks.