Hi, I'm trying to migrate from OpenLDAP 2.3.43-12.el5_6.7 to OpenLDAP 2.4.23-20.el6.x86_6. In 2.3, we currently have one master, replicating changes to 2 consumers via slurpd.
I'm trying to configure 2.4 w/ syncrepl, and have tried using refreshAndPersist to mimic that same routine of pushing changes from the master. I'm getting failures though:
on the master:
ay 25 13:55:25 slapd[6855]: send_search_entry: conn 1064 ber write failed. May 25 13:55:45 slapd[6855]: send_search_entry: conn 1066 ber write failed. May 25 13:56:45 slapd[6855]: send_search_entry: conn 1068 ber write failed. May 25 13:57:45 slapd[6855]: send_search_entry: conn 1078 ber write failed. May 25 13:58:45 slapd[6855]: send_search_entry: conn 1084 ber write failed. May 25 13:59:05 slapd[6855]: send_search_entry: conn 1086 ber write failed. May 25 13:59:15 slapd[6855]: send_search_entry: conn 1087 ber write failed.
on a consumer: May 25 13:45:15 slapd[28707]: do_syncrepl: rid=002 rc 68 retrying (9 retries left) May 25 13:45:25 slapd[28707]: syncrepl_entry: rid=002 be_add cn=XXXXXXX,dc=edu failed (68)
here are snippets from the master's slapd.conf and from one of the consumers:
master - -------
database hdb include /etc/openldap/slapd.access suffix "dc=XXXXdc=edu" checkpoint 1024 5 cachesize 30000 idlcachesize 90000 rootdn "cn=Manager,XXXXX,dc=edu" # NOTE: "updatedn" MUST BE COMMENTED OUT FOR INITIAL CREATION/LOAD OF # ROOT INFO
overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100
# Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. #rootpw secret # needs to be changed to something someone knows. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain # review these index default pres,eq index uid eq,sub index entryUUID,entryCSN index cn,sn,givenName,ou,mail,telephoneNumber pres,eq,sub index employeeNumber,mailAlternateAddress,eduPersonPrincipalName index eduPersonAffiliation,eduPersonPrimaryAffiliation index objectClass,serialNumber eq index isMemberOf eq,subany TLSCertificateFile /etc/openldap/newcert.pem TLSCertificateKeyFile /etc/openldap/newkey.pem TLSCACertificateFile /etc/openldap/chain.pem
consumer - ------------------ database hdb suffix "dc=XXXXX=edu" checkpoint 1024 5 cachesize 30000 idlcachesize 90000 rootdn "cn=Manager,dc=XXXX,dc=edu" # NOTE: "updatedn" MUST BE COMMENTED OUT FOR INITIAL CREATION/LOAD OF # ROOT INFO
# Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. #rootpw secret # needs to be changed to something someone knows. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain # review these index default pres,eq index uid eq,sub index entryUUID,entryCSN index cn,sn,givenName,ou,mail,telephoneNumber pres,eq,sub index employeeNumber,mailAlternateAddress,eduPersonPrincipalName index eduPersonAffiliation,eduPersonPrimaryAffiliation index objectClass,serialNumber eq index isMemberOf eq,subany TLSCertificateFile /etc/openldap/newcert.pem TLSCertificateKeyFile /etc/openldap/newkey.pem TLSCACertificateFile /etc/openldap/chain.pem
syncrepl rid=002 provider=ldap://providername-taken-out-here:389 type=refreshAndPersist retry="10 10 60 +" searchbase="dc=XXXX,dc=edu" filter="(objectClass=*)" attrs="*" scope=sub schemachecking=off bindmethod=simple binddn="cn=Replicator,dc=XXXX,dc=edu" credentials="password"
updateref ldap://providername-takenout-here:389
the account I"m using to bind from the consumer has read access to everything on the master. Thanks in advance
On 25/5/2012 9:15 μμ, Steve Reveliotty wrote:
I'm trying to migrate from OpenLDAP 2.3.43-12.el5_6.7 to OpenLDAP 2.4.23-20.el6.x86_6.
Can't tell you about the specific issue, but, as has been discussed numerous times in this list, avoid using the distro-provided RPMs, esp. if you are using replication.
Obviously you went from CentOS / RHEL 5 to CentOS / RHEL 6.
In any case, use a package with 2.4.31.
Copying from another thread:
From experience, I recommend using ready-made RPMs (or building from SRPMs) rather than building from source. This way you can upgrade at will and fully control your system in a way compatible with RHEL/CentOS package practices.
Of those I have worked with, I would propose you try using Symas Silver (excluding syncrepl providers - if you cannot afford paid support - otherwise check gold), or full-featured LTB project's RPMs (free, with on-line issue system). We use the latter.
For example, download the latest RPMs and install, e.g. here (for LTB): http://ltb-project.org/wiki/download#openldap
Nick
Hi Nick,
Sorry, I probably wasn't clear. One of the main reasons for this upgrade, was to get off RHEL5, and move to RHEL6, the updated openldap packages being more of a side effect.
I'm hoping I just missed something in the configuration, and that 2.4.23-20.el6.x86_6 (which looks to be the latest in RedHat's repo), will work, rather than build 2.4.31 from source. We use Puppet to manage as much as possible, and while we do have our own in house repo for custom packages, I'd want to have more of an idea that the distro provided rpms definitely won't work with replication before bothering to build one, though I can certainly test from ltb (though that thread mentions "excluding synrepl providers"?).
thanks
On Fri, May 25, 2012 at 3:00 PM, Nick Milas nick@eurobjects.com wrote:
On 25/5/2012 9:15 μμ, Steve Reveliotty wrote:
I'm trying to migrate from OpenLDAP 2.3.43-12.el5_6.7 to OpenLDAP
2.4.23-20.el6.x86_6.
Can't tell you about the specific issue, but, as has been discussed numerous times in this list, avoid using the distro-provided RPMs, esp. if you are using replication.
Obviously you went from CentOS / RHEL 5 to CentOS / RHEL 6.
In any case, use a package with 2.4.31.
Copying from another thread:
From experience, I recommend using ready-made RPMs (or building from SRPMs) rather than building from source. This way you can upgrade at will and fully control your system in a way compatible with RHEL/CentOS package practices.
Of those I have worked with, I would propose you try using Symas Silver (excluding syncrepl providers - if you cannot afford paid support - otherwise check gold), or full-featured LTB project's RPMs (free, with on-line issue system). We use the latter.
For example, download the latest RPMs and install, e.g. here (for LTB): http://ltb-project.org/wiki/**download#openldaphttp://ltb-project.org/wiki/download#openldap
Nick
On 25/5/2012 10:20 μμ, Steve Reveliotty wrote:
I'm hoping I just missed something in the configuration, and that 2.4.23-20.el6.x86_6 (which looks to be the latest in RedHat's repo), will work, rather than build 2.4.31 from source. We use Puppet to manage as much as possible, and while we do have our own in house repo for custom packages, I'd want to have more of an idea that the distro provided rpms definitely won't work with replication before bothering to build one, though I can certainly test from ltb (though that thread mentions "excluding synrepl providers"?).
I don't see anything bad in your config (though I am not an expert). Someone else might provide better feedback on that.
v2.4.23 available from the RHEL repo should work without problems, but I would not advise you to use it in production. Retry by recreating (slapadd) / re-indexing your db and restart the server. You could also try re-installing your OL server RPM.
However, it is strongly suggested to use v2.4.31. LTB is free and full-featured (this is what we use). Symas Silver is free but does not offer syncrepl provider. Symas Gold is full-featured but not free.
Also, no need to specify filter, scope and attrs since you are replicating everything.
Here is my working consumer setup:
syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="cn=someuser,dc=example,dc=com" credentials="password"
Nick
Hi Nick,
Thanks again. I definitely read plenty of praise for LTB, so I will investigate for sure. Also, thanks on the pointer about scope, filter, etc. If I can determine anything specific I've done wrong, etc. I'll certainly update.
thanks Steve
On Fri, May 25, 2012 at 4:48 PM, Nick Milas nick@eurobjects.com wrote:
On 25/5/2012 10:20 μμ, Steve Reveliotty wrote:
I'm hoping I just missed something in the configuration, and that
2.4.23-20.el6.x86_6 (which looks to be the latest in RedHat's repo), will work, rather than build 2.4.31 from source. We use Puppet to manage as much as possible, and while we do have our own in house repo for custom packages, I'd want to have more of an idea that the distro provided rpms definitely won't work with replication before bothering to build one, though I can certainly test from ltb (though that thread mentions "excluding synrepl providers"?).
I don't see anything bad in your config (though I am not an expert). Someone else might provide better feedback on that.
v2.4.23 available from the RHEL repo should work without problems, but I would not advise you to use it in production. Retry by recreating (slapadd) / re-indexing your db and restart the server. You could also try re-installing your OL server RPM.
However, it is strongly suggested to use v2.4.31. LTB is free and full-featured (this is what we use). Symas Silver is free but does not offer syncrepl provider. Symas Gold is full-featured but not free.
Also, no need to specify filter, scope and attrs since you are replicating everything.
Here is my working consumer setup:
syncrepl rid=111 provider=ldaps://ldap.example.**com http://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="cn=someuser,dc=**example,dc=com" credentials="password"
Nick
openldap-technical@openldap.org
-
Nick Milas -
Steve Reveliotty