- openldap-bugs - openldap.org

(ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by daniel＠ncsu.edu 26 Jan '07

26 Jan '07

Full_Name: Daniel Henninger Version: 2.3.32 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (152.1.4.40) Using ldapmodify to replace an attribute, 'ou', with it's new settings (in this case, two ou entries): dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL Caused an error: Jan 26 08:07:18 uni00ds.unity.ncsu.edu slapd[13230]: [ID 588225 local4.debug] co nn=62 op=4011 RESULT tag=103 err=20 text=modify/replace: ou: value #0 already ex ists (both are multivalued fields and should be fine) The way I had to fix it was to remove the attributes and retry: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify delete: ou - replace: ou ou: B A - Physics ou: B S - Philosophy - delete: ncsucurriculumcode - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL After that I can perform the original: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL set as many times as I want just fine. I've had "one a day" of these since upgrading to 2.3.32. (note that we do daily updates) It appears to have something to do with the order in which I slapadd'd these. Here's the LDIF (via slapcat) from before I 'fixed' it: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu objectClass: person objectClass: inetOrgPerson objectClass: ncsuPerson uid: XXX cn: XXX sn: XXX title: Senior ncsuTwoPartName: XXX organizationalStatus: registered o: NC State University gn: XXX initials: XXX displayName: XXX ncsuAltDisplayName: XXX ncsuCampusID: XXX ncsuClassCode: SR ou: Physics ncsuCurriculumCode: PY ou: B S - Philosophy ncsuCurriculumCode: LSL mail: XXX(a)unity.ncsu.edu ncsuPrimaryEMail: XXX(a)unity.ncsu.edu registeredAddress: XXX postalAddress: XXX telephoneNumber: XXX l: Raleigh st: NC postalCode: 27603 ncsuPrimaryRole: staff Obviously I XXX'd out everything sensitive. Note the ordering of ou and ncsucurriculumcode and ou again and ncsucurriculumcode. (this worked fine in the 2.2 series which I migrated from, and as far as I can tell is perfectly legit =) ) According to Howard Chu from the mailing list, this appears to have to do with.. well I'll quote him: I see that slapadd is doing a case-sensitive comparison on its input attribute names, when it should be using case-insensitive. That's probably the problem. Once the data's gone into the DB and come out again via slapcat, all of the attribute names are normalized, so any case differences would have disappeared.

1 0

(ITS#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 26 Jan '07

26 Jan '07

Full_Name: Gaël Roualland Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/gael.roualland-070126.diff Submission from: (NULL) (213.56.0.199) Hello, Slurpd has a bug when replicating, in the way it generates the LDAPMod array of the add and modify operations : if the same attribute is present several times (for add) or in multiple change blocks (for modify) in the replication log, it simply adds all occurences to the LDAPMod array, hence having one or more attributes repeated serveral times which violates the protocol. This is usually fine with slapd because there is code there to accept invalid queries from the updatedn, but it is rejected if you're not using updatedn (which happens to be our case in a custom floating master scenario). The uploaded patch fixes this in slurpd by replacing its LDAPmod logic by one based on ldapmodify which generates proper requests. I know slurpd is considered deprecated, however this might be useful to others still using it and would allow to remove the exception from slapd code. Regards,

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 25 Jan '07

25 Jan '07

hyc(a)symas.com wrote: >> The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get >> rid of those "cn=Database X", "cn=Overlay Y" stuff and so. > > One approach would be to add a pointer to the backend struct that points to > its cn=config entry. Then back-monitor can simply pull the DN from there and > strip the cn=config suffix. I think this should be first well integrated with back-config itself; for example, for what concerns private BackendDB structures. One case I've been trying to deal with for a while was the cached instances of back-ldap that are created by slapo-chain. I'm not sure I ever got it working, though. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 25 Jan '07

25 Jan '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> hyc(a)OpenLDAP.org wrote: >> >> >>> I presume there's some kind of callback for registering new suffixes >>> but I >>> haven't looked very hard. >>> >> >> This highlights some other issues lurking in here - back-monitor >> basically doesn't deal with dynamic configuration well at all. It >> assumes that all databases and overlays have been fully configured by >> the time it starts - an assumption that was valid for old-style >> slapd.conf use, but not with back-config. >> >> The monitor_subsys_database_init_one() function probably needs to be >> split into separate pieces so that database and overlay info can be >> set up and removed incrementally. >> > The point is that back-monitor has no clean means to detect what > database is serving what naming context, since it was designed way ahead > of back-config. So when time came to introduce monitor customization, > the best mechanism I could find was the extended filter on the naming > context. This is really creating trouble. The best solution would be to > re-design back-monitor so that the database section mimics back-config > using X-ORDERED 'SIBLING' style (and is updated accordingly, especially > when entry renaming will be supported by back-config). > > The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get > rid of those "cn=Database X", "cn=Overlay Y" stuff and so. One approach would be to add a pointer to the backend struct that points to its cn=config entry. Then back-monitor can simply pull the DN from there and strip the cn=config suffix. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4805) memory leak in syncrepl code
by hyc＠symas.com 25 Jan '07

25 Jan '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > There seems to be few memory leaks in syncrepl code (detected by valgrind when > running test048); one is when parsing an entry and sync "present" or "done". > It's now fixed in HEAD/re23. Others are being investigated I've plugged everything that I saw in test048 in HEAD. As you can tell by the number of commits, there were several loose ends to chase down. Not sure how many are directly relevant to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 24 Jan '07

24 Jan '07

dieter(a)dkluenter.de wrote: > Hi, > this is my test setup OK. This was a bug in back-bdb/id2entry.c, syncprov is fine. Fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think > I understand part of the problem. > > The particular entry was modified after the current refresh session began, so > that entry is omitted from the current refresh results. Since the entry is > actually missing from the refresh data, the consumer treats it as deleted. > Since the entry has children, it cannot actually be deleted, so it gets > turned into a glue entry. > > So there's two issues - the provider should still send the UUID of the entry, > so that the consumer doesn't consider it deleted. But also, this problem > ought to have self-corrected. Once the replication transitioned from Refresh > to Persist phase, the modified entry should have been sent to the consumer, > and the glue entry should have been replaced by the correct data. > > Looks like both problems are in the syncprov overlay. syncprov.c is now patched in HEAD to always send the UUIDs of the present entries. That appears to prevent the problem from arising. It's a bit difficult to automate a test for this because it requires such exact timing; a modification must occur on the provider while the consumer is just beginning its refresh search. Currently I can only test this by inserting a Debug message and a sleep() in the provider to indicate that the consumer is connected, and to give time to issue a modification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by ando＠sys-net.it 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > wells_robert_frank(a)yahoo.com wrote: >> --0-2146048140-1169674999=:43135 >> Content-Type: text/plain; charset=iso-8859-1 >> Content-Transfer-Encoding: 8bit >> >> Apologies - >> >> This did in fact work. I had not been aware of the backend DB functionality. > > Apparently few people are, since most other LDAP servers don't support this > part of the LDAP specification. Although he claimed he needed subtree rename, in his example all was needed was just plain rename, which has been supported by OpenLDAP since ever (when LDAPv3 introduced rename, i.e. modrdn with new rdn). p.

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

hyc(a)symas.com wrote: > Allan E. Johannesen wrote: >>>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: >> hyc> Since you mention that this occurs more often in 2.3.33 than in "previous >> hyc> releases" - what previous version are you comparing to? >> >> Well, I should have said I've never seen it before. I've generally been >> running the new releases within a day of release, and I rebuild the data at >> each release, so everything starts clean. Therefore, it _may_ have existed >> previously, but never showed up in the days during which the given releases >> ran. >> >> I guess I only mentioned that since someone saw it several releases ago in a >> different ITS. I never saw it before. >> In 2.3.33, it happened right after loading the data. I thought I did it wrong, >> so I loaded things again and it was fine. After some days, though, it (meaning >> the change to "objectClass: glue") happened again. > > The only change to syncrepl between 2.3.32 and .33 was one or two debug > messages, no functional changes. In 2.3.32 there was no change to syncrepl at > all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only > change in 2.3.31 was also in debug messages, not functional changes. So as > unlikely as it seems, at the moment this appears to be a coincidence and the > bug must be older. > > If you see this happening repeatedly, turn on the sync debug level and > capture that output for a while. When you notice the problem, you should also > see some number of "syncrepl_del_nonpresent" messages in the log. We'll > probably need to see a large chunk of the log to be able to follow the > sequence of events. Hm, in re-reading ITS#4626, I see a pertinent detail in followup #2. I think I understand part of the problem. The particular entry was modified after the current refresh session began, so that entry is omitted from the current refresh results. Since the entry is actually missing from the refresh data, the consumer treats it as deleted. Since the entry has children, it cannot actually be deleted, so it gets turned into a glue entry. So there's two issues - the provider should still send the UUID of the entry, so that the consumer doesn't consider it deleted. But also, this problem ought to have self-corrected. Once the replication transitioned from Refresh to Persist phase, the modified entry should have been sent to the consumer, and the glue entry should have been replaced by the correct data. Looks like both problems are in the syncprov overlay. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

Allan E. Johannesen wrote: >>>>>> "hyc" == Howard Chu <hyc(a)symas.com> writes: > > hyc> Since you mention that this occurs more often in 2.3.33 than in "previous > hyc> releases" - what previous version are you comparing to? > > Well, I should have said I've never seen it before. I've generally been > running the new releases within a day of release, and I rebuild the data at > each release, so everything starts clean. Therefore, it _may_ have existed > previously, but never showed up in the days during which the given releases > ran. > > I guess I only mentioned that since someone saw it several releases ago in a > different ITS. I never saw it before. > > These are the build times of the past few releases: > > drwxrwxr-x 10 imphss 2000 4096 Dec 19 08:57 .snapshot/weekly.0/openldap-2.3.31/ > drwxrwxr-x 10 imphss 2000 4096 Jan 7 10:33 .snapshot/weekly.0/openldap-2.3.32/ > drwxrwx--- 10 aej 101 4096 Jan 18 14:29 .snapshot/weekly.0/openldap-2.3.33/ > > In 2.3.33, it happened right after loading the data. I thought I did it wrong, > so I loaded things again and it was fine. After some days, though, it (meaning > the change to "objectClass: glue") happened again. The only change to syncrepl between 2.3.32 and .33 was one or two debug messages, no functional changes. In 2.3.32 there was no change to syncrepl at all (the bug in ITS#4790 was in connection.c, not syncrepl.c). The only change in 2.3.31 was also in debug messages, not functional changes. So as unlikely as it seems, at the moment this appears to be a coincidence and the bug must be older. If you see this happening repeatedly, turn on the sync debug level and capture that output for a while. When you notice the problem, you should also see some number of "syncrepl_del_nonpresent" messages in the log. We'll probably need to see a large chunk of the log to be able to follow the sequence of events. > > hyc> Please provide the relevant section of your slave slapd.conf - the > hyc> database clause and its syncrepl statement at least. Are there any ACLs on > hyc> the provider that would prevent the slave from seeing parts of the > hyc> affected entries? > > In the client: > > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > > # limits for different users > > limits dn=wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=People,dc=WPI,dc=EDU size=unlimited time=unlimited > limits dn=cn=application,ou=access,dc=wpi,dc=edu size=unlimited time=unlimited > limits dn="cn=pam,ou=access,dc=wpi,dc=edu" size=unlimited time=unlimited > limits users size=200 time=10 > limits anonymous size=20 time=1 > > directory /var/openldap-data > > # replication > > syncrepl rid=1 provider=ldap://ldapv2.wpi.edu type=refreshAndPersist retry="60 +" > searchbase="dc=WPI,dc=EDU" scope=sub starttls=yes bindmethod=sasl saslmech=gssapi > > > > Its keytab is k5start'd as ldap-manager, this is from the provider: > > > > sasl-regexp uid=ldap-manager/.*,cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=access,dc=WPI,dc=EDU??one?(cn=manager) > sasl-regexp uid=(.*),cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=people,dc=WPI,dc=EDU??one?(uid=$1) > > ####################################################################### > # bdb database definitions > ####################################################################### > > database bdb > suffix "dc=WPI,dc=EDU" > rootdn "cn=Manager,ou=Access,dc=wpi,dc=edu" > checkpoint 256 15 > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by hyc＠symas.com 24 Jan '07

24 Jan '07

wells_robert_frank(a)yahoo.com wrote: > --0-2146048140-1169674999=:43135 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > > Apologies - > > This did in fact work. I had not been aware of the backend DB functionality. Apparently few people are, since most other LDAP servers don't support this part of the LDAP specification. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by hyc＠symas.com 24 Jan '07

24 Jan '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.28 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in > cn=config Thanks for the report. The libldap function to retrieve this option was actually missing. Fixed now in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4815) TLSCipherSuite conversion to olcTLSCipherSuite
by erici＠motown.cc.utexas.edu 24 Jan '07

24 Jan '07

Full_Name: Eric Irrgang Version: 2.3.28 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) TLSCipherSuite in slapd.conf does not get converted into olcTLSCipherSuite in cn=config

1 0

Re: (ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

--0-2146048140-1169674999=:43135 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work. I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote: --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html --0-2146048140-1169674999=:43135 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Apologies - This did in fact work.  I had not been aware of the backend DB functionality. Regards, RFW Quanah Gibson-Mount <quanah(a)stanford.edu> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> --On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html </blockquote> --0-2146048140-1169674999=:43135--

1 0

Re: (ITS#4813) glue/syncrepl
by hyc＠symas.com 24 Jan '07

24 Jan '07

aej(a)wpi.edu wrote: > Full_Name: Allan E. Johannesen > Version: 2.3.33 > OS: Linux EL 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.215.24.208) > > > I have two synrepl slaves and entries in both of them seem to degrade, over > time, into "objectClass: glue" entities. > > These entries are not updated, so this degradation appears to be autonomous in > the slaves. The slaves have identical problems, the master retains the > structure of the entries. > > I see IS#4626 which has this same sort of problem, and perhaps I should have > followed on to that, but I can say that this problem must be much worse in > 2.3.33 than previously, since this has only happened to me since upgrading to > this release. > > My ou people is reduced to glue as is the ou access. The simplesecurity object > is gone entirely from the slaves' database. This is only the beginning of the > display of differences in the data. > > These entries were not modified since the database creation, and the > disintegration only occurs in the slaves. > > Let me know if more info is needed. Since you mention that this occurs more often in 2.3.33 than in "previous releases" - what previous version are you comparing to? Please provide the relevant section of your slave slapd.conf - the database clause and its syncrepl statement at least. Are there any ACLs on the provider that would prevent the slave from seeing parts of the affected entries? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4814) Tree Archiving
by quanah＠stanford.edu 24 Jan '07

24 Jan '07

--On Wednesday, January 24, 2007 6:55 PM +0000 wells_robert_frank(a)yahoo.com wrote: > Full_Name: Bob Wells > Version: 2.3.33 > OS: Linux RH 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.81.96.200) Isn't this just the modrdn operation? It is supported when using the back-hdb database. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4814) Tree Archiving
by wells_robert_frank＠yahoo.com 24 Jan '07

24 Jan '07

Full_Name: Bob Wells Version: 2.3.33 OS: Linux RH 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.81.96.200) REQUEST FEATURE: Need capability to move an entire entry beneath another branch in the tree. Example: uid=jdoe,ou=customers,dc=acme,dc=com (Customer exists) uid=jdoe,ou=archive,ou=customers,dc=acme,dc=com (Customer account deleted from within application and moved to archive tree branch) Currently, we do not believe openLDAP supports this capability. We have used rebind and rename. We are unable to find a way to do what we need it to do. Therefore, we request this type of feature in the product. Thanks in advance, Bob Wells-070124

1 0

Crypt invalide credential
by Arrouan 24 Jan '07

24 Jan '07

Hi, I'm using OpenLDAP under Linux/Gentoo (with crypt enabled). I can bind user with SSHA password, but i can't bind user with CRYPT password. OpenLDAP is link with Postfix/Courier and need CRYPT password. I check the ACL and it seem the issue isn't there. Anyone know how to fix this issue ? I have other postfix+openldap server and they all work without any problem. Thanks

2 1

Re:(ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 23 Jan '07

23 Jan '07

Hi, this is my test setup ##provider### slapd.conf pidfile /tmp/run/slapd1.pid argsfile /tmp/run/slapd1.args loglevel sync modulepath /usr/local/libexec/openldap moduleload syncprov.la access to dn.base="" by * read access to dn.base="cn=Subschema" by * read suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/slapd1/ index objectClass eq overlay syncprov -------------------- initial.ldif dn: dc=my-domain,dc=com objectclass: domain dc: my-domain dn: ou=organisation 1,dc=my-domain,dc=com objectclass: organizationalUnit ou: organisation 1 dn: ou=organisation 2,dc=my-domain,dc=com objectclass: organizationalUnit ou: organisation 2 dn: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com objectclass: inetorgperson cn: Foo Bar sn: Bar mail: foobar(a)my-domain.com telephoneNumber: +49.40.2997714 dn: cn=Bar Foo,ou=organisation 2,dc=my-domain,dc=com objectclass: alias objectclass: extensibleObject aliasedObjectName: cn=Foo Bar,ou=organisation 1,dc=my-domain,dc=com cn: Bar Foo sn: Foo --------------- ## Consumer #### slapd.conf include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /tmp/run/slapd2.pid argsfile /tmp/run/slapd2.args loglevel sync access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" rootpw secret directory /tmp/slapd2/ index objectClass eq syncrepl rid=02 provider=ldap://localhost:9001 binddn=cn=Manager,dc=my-domain,dc=com bindmethod=simple credentials=secret searchbase="dc=my-domain,dc=com" scope=sub type=refreshAndPersist retry="5 5 300 5" -------------------- After starting the comsumer, the initial dataset gets replicated. If adding the following entries (using web2ldap) to the provider dn: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com sn: Miller cn: Mike Miller mail: mmiller(a)my-domain.com telephoneNumber: +49.40.4450003 objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person dn: cn=Miller Mike,ou=organisation 2,dc=my-domain,dc=com aliasedObjectName: cn=Mike Miller,ou=organisation 1,dc=my-domain,dc=com cn: Miller Mike objectClass: alias objectClass: extensibleObject dn: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com sn: Smith cn: Joe Smith mail: jsmith(a)my-domain.com telephoneNumber: +49.40.4450004 objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person dn: cn=Smith Joe,ou=organisation 2,dc=my-domain,dc=com aliasedObjectName: cn=Joe Smith,ou=organisation 1,dc=my-domain,dc=com cn: Smith Joe objectClass: alias objectClass: extensibleObject the alias objects are not replicated, only after a consumer restart. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4810) syncprov follows referrals
by dieter＠dkluenter.de 23 Jan '07

23 Jan '07

Am Montag, 22. Januar 2007 22:28 schrieb Pierangelo Masarati: > dieter(a)dkluenter.de wrote: > > Full_Name: Dieter Kluenter > > Version: 2.4.2alpha > > OS: linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (84.142.177.66) > > > > > > When adding a alias abject to the provider, syncprov fowllows the > > referral and is not updating the alias object to the consumer, > > Dieter, > > are you talking about aliases or referrals? Hi Ando, In this particular case I am talking about aliases. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4813) glue/syncrepl
by aej＠wpi.edu 23 Jan '07

23 Jan '07

Full_Name: Allan E. Johannesen Version: 2.3.33 OS: Linux EL 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.215.24.208) I have two synrepl slaves and entries in both of them seem to degrade, over time, into "objectClass: glue" entities. These entries are not updated, so this degradation appears to be autonomous in the slaves. The slaves have identical problems, the master retains the structure of the entries. I see IS#4626 which has this same sort of problem, and perhaps I should have followed on to that, but I can say that this problem must be much worse in 2.3.33 than previously, since this has only happened to me since upgrading to this release. My ou people is reduced to glue as is the ou access. The simplesecurity object is gone entirely from the slaves' database. This is only the beginning of the display of differences in the data. These entries were not modified since the database creation, and the disintegration only occurs in the slaves. Let me know if more info is needed. Thanks. *** users.ldapv2.2007.01.23.ldif.pure Tue Jan 23 09:10:50 2007 --- users.ldapv2back.2007.01.23.ldif.pure Tue Jan 23 09:10:53 2007 *************** *** 10,18 **** dn: ou=People,dc=WPI,dc=EDU objectClass: top ! objectClass: organizationalUnit ! ou: People ! structuralObjectClass: organizationalUnit dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU objectClass: top --- 10,17 ---- dn: ou=People,dc=WPI,dc=EDU objectClass: top ! objectClass: glue ! structuralObjectClass: glue dn: wpieduPersonUUID=62081c7c52ec30c556d6c558896983ee,ou=People,dc=WPI,dc=EDU objectClass: top *************** *** 1498,1514 **** dn: ou=Access,dc=WPI,dc=EDU objectClass: top ! objectClass: organizationalUnit ! ou: Access ! structuralObjectClass: organizationalUnit ! ! dn: cn=retiresql,ou=Access,dc=WPI,dc=EDU ! objectClass: top ! objectClass: simpleSecurityObject ! objectClass: applicationProcess ! cn: retiresql ! userPassword:: e1NTSEF9Qno0NllDM2pwRWZSZGh6OFdRY2RWNWpjdklaWHM0ekU= ! structuralObjectClass: applicationProcess dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU objectClass: top --- 1497,1504 ---- dn: ou=Access,dc=WPI,dc=EDU objectClass: top ! objectClass: glue ! structuralObjectClass: glue dn: wpieduPersonUUID=d9e775ae9449c616c6952d860e634ad6,ou=People,dc=WPI,dc=EDU objectClass: top

1 0

(ITS#4812) ldapmodify doesn't report error when the server closed the connection
by rhafer＠suse.de 23 Jan '07

23 Jan '07

Full_Name: Ralf Haferkamp Version: 2.3, HEAD OS: Any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.166.107) ldapmodify doesn't report errors from a failed ldap_result() call. This can be reproduce by using ldapmodify via stdin and connecting to a server with a very short idletimeout. If the MODIFY operation is sent after the connection is closed no error message is shown to the user. The only indication of a failure is the EXIT code of ldapmodify. This is fixed in HEAD now.

1 0

Re: (ITS#4809) Replication of operational attributes when performing modrdn operation
by hyc＠symas.com 23 Jan '07

23 Jan '07

Thomas.Fritz(a)bam.de wrote: > Full_Name: Thomas Fritz > Version: 2.3.33 > OS: Debian Gnu/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.63.61.111) > > > We are using OpenLDAP 2.3.33 in a master/slave setup with slurpd and hdb > backend. > > When performing the modrdn operation against the master, no update directives > for the attributes 'modifiersName', 'modifyTimestamp', and 'entryCSN' are > written to the replog file. Hence, the databases of master and slave differ by > the values of these attributes after replication. > > This bug can be reproduced using e.g. the ldapmodrdn tool. OpenLDAP versions > back to (at least) 2.3.24 are affected. This is not a bug, it is a consequence of the design of slurpd. slurpd uses LDIF (RFC2849) for its replog format, and simply propagates LDAP operations as recorded there. In LDIF a modrdn record can only specify newrdn, deleteoldrdn, and newsuperior parameters. Likewise, these are the only parameters that can be specified in an LDAP modrdn operation. This design limitation is one of many reasons why slurpd has been deprecated. If you want to perform replication and preserve these attributes, you can use syncrepl instead. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by ando＠sys-net.it 22 Jan '07

22 Jan '07

This bug report is missing the most important part: a backtrace of the core dumped when the problem occurs. Please provide one. p.

1 0

(ITS#4811) refreshAndPersist and Monitor -> slapd core dump
by niels＠signaturgruppen.dk 22 Jan '07

22 Jan '07

Full_Name: Niels Frimodt Sørensen Version: 2.3.32 OS: Solaris URL: Submission from: (NULL) (80.160.139.81) Hi, refreshAndPersist mode of syncrepl seems to have problems with Monitor. The slave is dumping core when I do ldapsearch against cn=Connections, cn=Monitor. The system is running on Solaris 9 and based on OpenLDAP 2.3.32. Replication works just fine. If I change syncrepl type to refreshOnly then the ldapsearch is completed without core dump. Further information on configuration and debug below. The Master has the following conf: # slapd.conf # Schema include /opt/ldap/content2/schema/core.schema # Control files pidfile /opt/ldap/backend2/var/slapd.pid argsfile /opt/ldap/backend2/var/slapd.args database bdb suffix "c=NO" rootdn "cn=Manager,c=NO" rootpw Test1234 directory /opt/ldap/content2/data checkpoint 128 10 # Indices to maintain index objectclass,entryCSN,entryUUID eq index serialNumber pres,eq index mail pres,eq index cn pres,eq cachesize 100000 threads 64 overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 database monitor The slave has the following conf: # slapd.conf # Schema include /opt/ldap/content-buslave/schema/core.schema # Control files pidfile /opt/ldap/backend-buslave/var/slapd.pid argsfile /opt/ldap/backend-buslave/var/slapd.args # database defs database bdb suffix "c=NO" rootdn "cn=Manager,c=NO" rootpw Test1234 directory /opt/ldap/content-buslave/data checkpoint 128 10 # Indices to maintain index objectclass,entryCSN,entryUUID eq index serialNumber pres,eq index mail pres,eq index cn pres,eq cachesize 100000 threads 32 syncrepl rid=123 provider=ldap://127.0.0.1:3892 type=refreshAndPersist searchbase="c=NO" filter="(objectClass=*)" scobe=sub attrs="" schemachecking=off bindmethod=simple updatedn="cn=Manager,c=NO" binddn="cn=Manager,c=NO" credentials="Test1234" database monitor The ldapsearch output that indicate the problem: ldapsearch -h localhost -p 3891 -b "cn=Monitor" "cn=Connections" + # extended LDIF # # LDAPv3 # base <cn=Monitor> with scope subtree # filter: cn=Connections # requesting: + # # Connections, Monitor dn: cn=Connections,cn=Monitor structuralObjectClass: monitorContainer creatorsName: modifiersName: createTimestamp: 20070122103402Z modifyTimestamp: 20070122103402Z entryDN: cn=Connections,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE ldap_result: Can't contact LDAP server (-1) The slave debugs the following during the search: ... => test_filter EQUALITY => access_allowed: search access to "cn=Connections,cn=Monitor" "cn" requested => access_allowed: backend default search access granted to "(anonymous)" <= test_filter 6 => send_search_entry: conn 0 dn="cn=Connections,cn=Monitor" => access_allowed: read access to "cn=Connections,cn=Monitor" "entry" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "structuralObjectClass" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "creatorsName" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "modifiersName" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "createTimestamp" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "modifyTimestamp" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "entryDN" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "subschemaSubentry" requested => access_allowed: backend default read access granted to "(anonymous)" => access_allowed: read access to "cn=Connections,cn=Monitor" "hasSubordinates" requested => access_allowed: backend default read access granted to "(anonymous)" ber_flush: 308 bytes to sd 13 0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn= 0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M 0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st 0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl 0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo 0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat 0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m 0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1... 0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest 0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221 00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify 00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200 00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&.. 00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co 00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon 00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem 0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn= 0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has 0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1... 0130: 54 52 55 45 TRUE ldap_write: want=308, written=308 0000: 30 82 01 30 02 01 02 64 82 01 29 04 19 63 6e 3d 0..0...d..)..cn= 0010: 43 6f 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d Connections,cn=M 0020: 6f 6e 69 74 6f 72 30 82 01 0a 30 2b 04 15 73 74 onitor0...0+..st 0030: 72 75 63 74 75 72 61 6c 4f 62 6a 65 63 74 43 6c ructuralObjectCl 0040: 61 73 73 31 12 04 10 6d 6f 6e 69 74 6f 72 43 6f ass1...monitorCo 0050: 6e 74 61 69 6e 65 72 30 12 04 0c 63 72 65 61 74 ntainer0...creat 0060: 6f 72 73 4e 61 6d 65 31 02 04 00 30 13 04 0d 6d orsName1...0...m 0070: 6f 64 69 66 69 65 72 73 4e 61 6d 65 31 02 04 00 odifiersName1... 0080: 30 24 04 0f 63 72 65 61 74 65 54 69 6d 65 73 74 0$..createTimest 0090: 61 6d 70 31 11 04 0f 32 30 30 37 30 31 32 32 31 amp1...200701221 00a0: 30 30 39 34 32 5a 30 24 04 0f 6d 6f 64 69 66 79 00942Z0$..modify 00b0: 54 69 6d 65 73 74 61 6d 70 31 11 04 0f 32 30 30 Timestamp1...200 00c0: 37 30 31 32 32 31 30 30 39 34 32 5a 30 26 04 07 70122100942Z0&.. 00d0: 65 6e 74 72 79 44 4e 31 1b 04 19 63 6e 3d 43 6f entryDN1...cn=Co 00e0: 6e 6e 65 63 74 69 6f 6e 73 2c 63 6e 3d 4d 6f 6e nnections,cn=Mon 00f0: 69 74 6f 72 30 23 04 11 73 75 62 73 63 68 65 6d itor0#..subschem 0100: 61 53 75 62 65 6e 74 72 79 31 0e 04 0c 63 6e 3d aSubentry1...cn= 0110: 53 75 62 73 63 68 65 6d 61 30 19 04 0f 68 61 73 Subschema0...has 0120: 53 75 62 6f 72 64 69 6e 61 74 65 73 31 06 04 04 Subordinates1... 0130: 54 52 55 45 TRUE conn=0 op=1 ENTRY dn="cn=connections,cn=monitor" <= send_search_entry: conn 0 exit. Segmentation Fault - core dumped -- Venlig hilsen/Kind regards Niels Frimodt Sørensen Signaturgruppen A/S www.signaturgruppen.dk

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs