So I copied slapd.d from 2.4.20 to 2.4.21 and that seems to get 2.4.21 slapd going. Is this going to cause me issues down the road? Can 2.4.21 use cn=config entries from 2.4.20? My single provider / multiple consumers syncrepl setup appears to be working as expected in 2.4.21.
Thanks, Hung On Wed, Jan 27, 2010 at 2:49 PM, Hung Luu <[email protected]> wrote: > OpenLDAP 2.4.20 does not have this problem. I compared the > olcDatabase={0}config.ldif and olcDatabase={1}hdb.ldif files between 2.4.20 > and 2.4.21 and noticed that the olcSyncrepl attribute value from 2.4.21 > contains a uri="" whereas the olcSyncrepl attribute from 2.4.20 (working > version) does not. > > Is there a workaround for this that will allow me to use 2.4.21 or should I > stick with 2.4.20? > > Thanks, > Hung. > > > On Sat, Jan 16, 2010 at 6:15 PM, Hung Luu <[email protected]> wrote: > >> >> >> On Fri, Jan 15, 2010 at 4:53 PM, Hung Luu <[email protected]> wrote: >> >>> Hello everyone, >>> >>> Has anyone experienced the "<olcSyncrepl> invalid URL" error from >>> starting up a consumer slapd? I've tried configuring the provider setting >>> for the syncrepl directive as a domain name and IP address but neither >>> works. >>> >>> Thanks in advance for your help. >>> >>> Here's the error from slapd: >>> >>> *olcSyncrepl: value #0: <olcSyncrepl> invalid URL >>> config error processing olcDatabase={1}hdb,cn=config: <olcSyncrepl> >>> invalid URL* >>> >>> Here's my consumer slapd.conf: >>> >>> include /opt/openldap-2.4.21/etc/openldap/schema/core.schema >>> include /opt/openldap-2.4.21/etc/openldap/schema/cosine.schema >>> include >>> /opt/openldap-2.4.21/etc/openldap/schema/inetorgperson.schema >>> >>> pidfile /opt/openldap-2.4.21/var/run/slapd.pid >>> argsfile /opt/openldap-2.4.21/var/run/slapd.args >>> >>> modulepath /opt/openldap-2.4.21/libexec/openldap >>> moduleload back_hdb.la >>> >>> # Overlay for reverse group membership >>> moduleload memberof.la >>> >>> loglevel 16383 >>> >>> # Global database directives >>> overlay memberof >>> memberof-group-oc groupOfNames >>> memberof-member-ad member >>> memberof-memberof-ad memberOf >>> memberof-dangling error >>> memberof-refint TRUE >>> >>> # Enable cn=config changes from LDAP browser >>> database config >>> rootdn "cn=admin,cn=config" >>> rootpw secret >>> >>> database hdb >>> suffix "dc=example,dc=com" >>> rootdn "cn=admin,dc=example,dc=com" >>> rootpw secret >>> directory /opt/openldap-2.4.21/var/openldap-data/example-com >>> # Indices to maintain >>> index default eq >>> index cn,uid,member >>> index entryCSN,entryUUID eq >>> index objectClass eq >>> # Other BDB/HDB directives >>> cachesize 10000 >>> checkpoint 1024 10 >>> # Replication >>> syncrepl rid=000 >>> provider=*ldap://192.168.56.3:389* >>> type=refreshAndPersist >>> retry="5 5 300 +" >>> searchbase="dc=example,dc=com" >>> attrs="*,+" >>> bindmethod=simple >>> binddn="cn=admin,dc=example,dc=com" >>> credentials=secret >>> >> >> I finally got syncrepl working by starting the consumer slapd with >> slapd.conf rather than cn=config. *What am I missing to get syncrepl to >> work with cn=config?* >> >> Additional info from consumer's ldap.log when starting slapd with >> cn=config: >> >> Jan 16 10:48:15 localhost slapd[4176]: olcSyncrepl: value #0: >> <olcSyncrepl> invalid URL >> Jan 16 10:48:15 localhost slapd[4176]: config error processing >> olcDatabase={1}hdb,cn=config: <olcSyncrepl> invalid URL >> Jan 16 10:48:15 localhost slapd[4176]: send_ldap_result: conn=-1 op=0 p=0 >> Jan 16 10:48:15 localhost slapd[4176]: send_ldap_result: err=80 matched="" >> text="" >> Jan 16 10:48:15 localhost slapd[4176]: slapd destroy: freeing system >> resources. >> Jan 16 10:48:15 localhost slapd[4176]: slapd stopped. >> Jan 16 10:48:15 localhost slapd[4176]: connections_destroy: nothing to >> destroy. >> >> >> Thanks, >> Hung. >> > >
