openldap-bugs April 2008

openldap-bugs@openldap.org

45 participants
192 discussions

(ITS#5468) You can put irrevant thing on LDIF file "add" line
by patrick.ni＠strangeloopnetworks.com 14 Apr '08

14 Apr '08

Full_Name: Patrick Ni Version: 2.3.30-5 OS: Linux version 2.6.18-4-486 (Debian 2.6.18.dfsg.1-12etch2) (dannf(a)debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.77.66.100) Hello, I have a group entry for myself "patrick" in the LDAP database as follows: dn: cn=patrick,ou=Group,dc=strangeloop,dc=net objectClass: posixGroup objectClass: top cn: patrick userPassword:: e1NTSEF9eA== gidNumber: 500 memberUid: patrick Recently, I realized I could add my 2nd openLDAP account "dn:uid=patrick2,ou=Accounts,dc=strangeloop,dc=net" into my group "patrick" using the following LDIF file: ldap1:~/ldap# more group2_patrick.ldif dn: cn=patrick,ou=Group,dc=strangeloop,dc=net changetype:modify add:membership memberUid:patrick2 This should not have succeeded because the "add:membership" line is wrong; It should have been "add:memberUid". thanks -Patrick

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ghenry＠OpenLDAP.org 14 Apr '08

14 Apr '08

>> People interested in the overlay are able to download it from >> the maintained location at: >> >> http://techpubs.spinlocksolutions.com/openldap/ > > Well, in that case you have to guarantee that the URL remains valid over > time. If you put it in contrib/ the OpenLDAP project guarantees (sort > of) it remains available. To the average potential user, I guess it's > the same level of guarantee :) > It could also be listed at: http://www.openldap.org/doc/admin24/appendix-contrib.html as it wasn't in contrib format when I wrote this section. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5467) aliases broke on hdb/bdb ?
by h.b.furuseth＠usit.uio.no 13 Apr '08

13 Apr '08

Not a bug. A search which dereferences aliases, checks the filter against the _aliased_ entry, not against the _alias_ entry. So, try ldapsearch -a always uid=wilfinge. -- Hallvard

1 0

(ITS#5467) aliases broke on hdb/bdb ?
by cowboy＠linux.vnet.ibm.com 12 Apr '08

12 Apr '08

Full_Name: Richard Nelson Version: 2.4.7-6.1 (Debian) OS: Linux (Debian) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.245.249.50) Here's the alias ldif (modelled after the FAQ 1111 entry) $ ldapsearch -a never uid=wilfing dn: uid=wilfing,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com uid: wilfing aliasedObjectName: uid=wilfinge,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com objectClass: alias objectClass: extensibleObject And the aliased entry: $ ldapsearch -a never uid=wilfinge dn # wilfinge, Users, cobpli.svl.ibm.com dn: uid=wilfinge,ou=Users,dc=cobpli,dc=svl,dc=ibm,dc=com When I try to actually use the alias, it fails: $ ldapsearch -a always uid=wilfing # base <dc=cobpli,dc=svl,dc=ibm,dc=com> (default) with scope subtree # filter: uid=wilfing # requesting: ALL # # search result search: 4 result: 0 Success The logs seemed to imply that, rather than the expect DN replacement and search, that the slapd-hdb actually scanned the entire subtree (curiously missing the alias entry) and returned no data In case it matters, here's the index entry for uid: index uid pres,eq,sub I renamed the alias from 'wilfing' to 'alias' to make sure it wasn't due to the alias being a substring of the true name - but that didn't help either

1 0

(ITS#5466) slapo-dynlist attribute remapping
by manu＠netbsd.org 12 Apr '08

12 Apr '08

Full_Name: Emmanuel Dreyfus Version: HEAD OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-20070412.patch Submission from: (NULL) (213.41.141.172) This patch adds attribute remapping capability to slapo-dynlist. If you configure it that way: overlay dynlist dynlist-attrset groupOfURLs memberURL bar:foo And if you have an object like this in your directory: dn: cn=list,o=home objectClass: groupOfURLs cn: list memberURL: ldap:///o=home?foo?sub?(objectClass=fooClass) Then searching for cn=list,o=home will display the expantion of the LDAP URI, with foo attributes been displayed as bar.

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Saturday, April 12, 2008 10:14 AM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > I realized last night that this is likely due to the race condition issue > between syncprov & syncrepl when check pointing the cookie. The > replica's run the syncprov overlay so that we can see the cookie as it's > a glue DB. They also have a check point line. I'll have the checkpoint > line removed on the replicas. Never mind, I was incorrect. The syncprov-checkpoint line is not present on the replicas, only "overlay syncprov", so this isn't it. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 12 Apr '08

12 Apr '08

--On Friday, April 11, 2008 9:33 PM +0000 quanah(a)zimbra.com wrote: > So it's clear that the update took on the replica. I restarted slapd, > and it started replicating correctly. So it looks like there's a problem > where internally it thinks it is on a previous cookie to what it has > already committed. I realized last night that this is likely due to the race condition issue between syncprov & syncrepl when check pointing the cookie. The replica's run the syncprov overlay so that we can see the cookie as it's a glue DB. They also have a check point line. I'll have the checkpoint line removed on the replicas. Does this sound correct, as per the note Howard made recently about this issue? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4890) Default Values overlay (patch)
by ando＠sys-net.it 12 Apr '08

12 Apr '08

docelic(a)spinlocksolutions.com wrote: > The contrib section does not have usable makefiles (nor the system > to create them). Usually, building a contrib does not require much makefile stuff. > Putting this overlay in contrib, where it would be unmaintained > and practically broken right away from the start (due to missing > build integration) doesn't make any sense. It makes sense: if we integrate it in the mainstream source and it breaks because it's unmaintained, then the distribution is broken > People interested in the overlay are able to download it from > the maintained location at: > > http://techpubs.spinlocksolutions.com/openldap/ Well, in that case you have to guarantee that the URL remains valid over time. If you put it in contrib/ the OpenLDAP project guarantees (sort of) it remains available. To the average potential user, I guess it's the same level of guarantee :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5408) back-ldif bugs
by hyc＠symas.com 11 Apr '08

11 Apr '08

h.b.furuseth(a)usit.uio.no wrote: > Here are a bunch of back-ldif bugs some questions. I have code for most > of it, but need advice/discussion on functionality changes. > - When back-ldif uses OS-specific escaping, we can't move a directory > tree between Windows and Unix hosts if some RDN in the tree contains > characters with OS-specific escaping. This is never a priority. The only documented way to move databases is via slapcat/slapadd. I'm perfectly fine with a Windows-specific special case that simply maps all forbidden characters to control-characters, or some other equally obscure approach. (E.g. map all forbidden characters to the same character.) The typical Windows admin will never see the raw filenames anyway. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5465) Delta-Syncrepl cookie problems
by quanah＠zimbra.com 11 Apr '08

11 Apr '08

Full_Name: Quanah Gibson-Mount Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.23.156.219) I have a replica spitting out the following error in its logs (master and replica running OpenLDAP 2.3.41): Apr 11 13:28:03 123-ldap-3 slapd[21846]: syncrepl_message_to_op: rid 100 be_modify uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu (20) It's syncrepl cookie is: contextCSN: 20080410145621Z#000000#00#000000 Looking at the accesslog on the master, I see (for this time period): dn: reqStart=20080410145621.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000001Z reqEnd: 20080410145621.000003Z reqType: modify reqSession: 190486 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: zimbraPasswordLockoutFailureTime:- 20080410145230Z reqMod: entryCSN:= 20080410145621Z#000000#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ac9202-9b5a-102c-8816-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000000#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z dn: reqStart=20080410145621.000027Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20080410145621.000027Z reqEnd: 20080410145621.000028Z reqType: modify reqSession: 190494 reqAuthzID: uid=zimbra,cn=admins,cn=zimbra reqDN: uid=yyyy_07,ou=people,dc=123,dc=abc,dc=edu reqResult: 0 reqMod: zimbraPasswordLockoutFailureTime:+ 20080410145621Z reqMod: entryCSN:= 20080410145621Z#000001#00#000000 reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra reqMod: modifyTimestamp:= 20080410145621Z entryUUID: 06ee59c6-9b5a-102c-8817-1596598f2bf0 creatorsName: cn=accesslog createTimestamp: 20080410145621Z entryCSN: 20080410145621Z#000001#00#000000 modifiersName: cn=accesslog modifyTimestamp: 20080410145621Z So as I understand (delta)syncrepl, the replica knows it already received the update for uid=xxxxx, and yet it is still trying to process that update, rather than the next one for uid=yyyy_07. The entry on the replica has: dn: uid=xxxxx,ou=people,dc=123,dc=abc,dc=edu zimbraPasswordLockoutFailureTime: 20080410145515Z zimbraPasswordLockoutFailureTime: 20080410145516Z zimbraPasswordLockoutFailureTime: 20080410145519Z zimbraPasswordLockoutFailureTime: 20080410145539Z zimbraPasswordLockoutFailureTime: 20080410145547Z zimbraPasswordLockoutFailureTime: 20080410145548Z zimbraPasswordLockoutFailureTime: 20080410145621Z So it's clear that the update took on the replica. I restarted slapd, and it started replicating correctly. So it looks like there's a problem where internally it thinks it is on a previous cookie to what it has already committed. --Quanah

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
20
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2008