[SOLVED] Ldap replica promoted as master and store still looking for the old master

[nlebihan]

Release 6.0.6_GA_2330.UBUNTU8_64 UBUNTU8_64 NETWORK edition.

Hi,
To replace a crashed ldap master in a multii server architecture, i've just promoted a replica to be the new master following this how-to: Promoting Replica to LDAP Master 6.0 - Zimbra :: Wiki

All works fine but an error message still remain on the store server:

Jun 28 10:54:53 store1 slapd[16797]: slap_client_connect: URI=ldap://ldap1.domain.com:389 Error, ldap_start_tls failed (-1)

There isn't any reference about ldap1 on the localconfig file.
All seems to be working fine except the pagination of the users administration web gui (can only see the 25th first accounts)

Is there any remaining ldap modification i have to do ?

Thanks in advance

[nlebihan]

as i can see when editing the ldap directly on the ldap new master and on the store (that is also ldap embedded) is a new account created on store1 can be seen on ldap new master but not on store1 ldap database.

So store is updating ldap new master but not himself as still trying to reach ldap old master...

[Krishopper]

I had an issue similar to this, and needed to re-install my commercial ssl certificates.
Not sure if its the same issue you are having, but something to think about.

[nlebihan]

First, thanks for your answer.
In fact my problem is that store1 is still asking ldap connection to the old and unused ldap master server.
It should try this connection to the new ldap master server.
All localsettings are set to the new one but slapd still trying to ask the unused ldap server. So the certificates aren't the problem to my mind.
I want to make the store1 asking to new master ldap server but not the old one...

[Krishopper]

I know you said that there isn't any reference about ldap1 on the localconfig file, but does "zmlocalconfig ldap_master_url ldap_url ldap_host" show ONLY the new master server?

[nlebihan]

Yes there isn't any references about the wrong/unused server.

I've just sent a search about the oldname within all zimbra files and get it here:
/opt/zimbra/data/ldap/config/cn=config/olcDatabase={2}hdb.ldiflcUpdateRef: ldap://ldap1.domain.com:389

and


/opt/zimbra/data/ldap/config/cn=config/olcDatabase={2}hdb.ldiflcSyncrepl: {0}rid=100 provider=ldap://ldap1.domain.com:389 bindmethod
=simple timeout=0 network-timeout=0 binddn=uid=zmreplica,cn=admins,cn=zimbra
credentials=password starttls=critical filter="(objectclass=*)" searchbase="
" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=acces
slog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdat
a=accesslog tls_cacertdir=/opt/zimbra/conf/ca


So i will modify it using vi and will restart the server to see if all is fine after that.

[Krishopper]

Step 2 c in the Wiki manages that attribute. Perhaps it didn't execute successfully when you went through it.

Be careful about editing those files with vi, as they're meant to be edited with the noted ldapmodify commands.

[nlebihan]

OK, that solved my problem...

Dunno why this wasn't updated using the How To, perhaps some element to add in ?

[nlebihan]

To be more specific, the /opt/zimbra/data/ldap/config/cn=config/olcDatabase={2}hdb.ldif wasn't updated using the how to you and I mentioned.

Editing the olcSyncrepl: and olcUpdateRef: values manually solved my problem.

Thanks for your interest !

[phoenix]

Originally Posted by nlebihan

OK, that solved my problem...

Dunno why this wasn't updated using the How To, perhaps some element to add in ?

You should file a bug report if you think that article is missing some information, include all the relevant details of your problem and solution.