- openldap-bugs - openldap.org

Re: (ITS#5065) out of order ctxcsn from old entryCSN
by hyc＠symas.com 10 Aug '07

10 Aug '07

donn(a)u.washington.edu wrote: > Full_Name: Donn Cave > Version: 2.4.4 > OS: RH Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.95.135.150) > > > Old entryCSN values imported into the data from another server, can crash > replicas. > > In loop at top of syncrepl_updateCookie, replica encounters a syncCookie whose > value is less than its matching si_cookieState->cs_val. This breaks out of the > inner loop, and the outer loop, without copying anything into `first', so > slap_queue_csn crashes on the null csn. Both are element 0 of their respective > arrays. I assume it is no surprise that syncCookie takes its value from an > entryCSN attribute. > > To duplicate, add an entry with an explicit entryCSN, with value less than the > current contextCSN. In my case, the entryCSN is of the format without the > `decimal fraction' field, but I doubt that matters. > > I don't want to say OpenLDAP needs to support this, but maybe it would be better > to catch the problem in the master, than crash the replicas. You didn't mention how your syncrepl is configured but it seems that this can only occur for refreshAndPersist mode, with old entries being ldapadd'd to the running master. As you say, this is not a supported mode of operation. New data in the server should always have a new entryCSN as well. In fact, since entryCSN is NO-USER-MODIFICATION it shouldn't even be possible to add entries this way to a running server. Before we can "catch the problem in the master" we need more information on how the problem was caused. As for crashing the replicas - the only sure solution is to patch the code in the replicas - "catching the problem in the master" isn't really a proper solution anyway. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5082
by hyc＠symas.com 10 Aug '07

10 Aug '07

ando(a)sys-net.it wrote: > See also discussion in thread > <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> The fix currently in CVS HEAD is to remove the olcPasswordHash attribute from the olcGlobal entry and move it to the frontendDB entry. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5085) slapo-translucent has wrong Debug message
by ghenry＠OpenLDAP.org 10 Aug '07

10 Aug '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > Inside: > > translucent_db_destroy > > Debug: > > Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0); > > Should be: > > Debug(LDAP_DEBUG_TRACE, "==> translucent_db_destroy\n", 0, 0, 0); > > Probably copy and paste error. > > Correcting. > > Gavin. > > This is missing from RE_23, but obviously not going to be added. There is another error in RE_23 though: Debug(LDAP_DEBUG_TRACE, "==> translucent_init\n", 0, 0, 0); should be translucent_db_init. Will change under this ITS. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5086) back-bdb bug when add is used with snapshot isolation
by stelios.xx.grigoriadis＠ericsson.com 10 Aug '07

10 Aug '07

Full_Name: Stelios Grigoriadis Version: 2.3.32 OS: Linux, (SLES 10) URL: http://ninikos.freehostia.com/bdb_idl_cache_bug.tar.gz Submission from: (NULL) (194.237.142.7) When using slapd with the snapshot isolation level in DB (version 4.5.20) it is possible that added entries don't appear in subsequent searches. Scenario: A client is adding new information while at the same time another is initiating an LDAP search with the same searchbase as the "parent" of the added information. If the search is executed after the add operation has cleared the IDL-cache but before the changes has been committed, the added entries will not appear in any subsequent searches unless slapd is restarted. The problem is that, in the bdb_idl_insert_key-function, the key is deleted from the IDL-cache but the newly added keys in the database are not yet committed, so clients that re-read the information will not have those updated keys. The solution would be to clear the relevant IDL-cache entries after the changes has been committed. This behaviour is demonstrated by the program cache_test_fork.c which is supplied in bdb_idl_cache_bug.tar.gz along with the slapd configuration. I am currently working on the solution but would greatly appreciate any help from you as I am not nearly as familiar with the code as you are.

1 0

(ITS#5085) slapo-translucent has wrong Debug message
by ghenry＠OpenLDAP.org 10 Aug '07

10 Aug '07

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Inside: translucent_db_destroy Debug: Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0); Should be: Debug(LDAP_DEBUG_TRACE, "==> translucent_db_destroy\n", 0, 0, 0); Probably copy and paste error. Correcting. Gavin.

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize '1.1' to describe an empty attribute set
by ando＠sys-net.it 10 Aug '07

10 Aug '07

> On Aug 6, 2007, at 6:43 AM, Pierangelo Masarati wrote: >> I believe there's something odd in pcache's current behavior. In >> fact, right now "proxyattrset 0" is already a valid directive, but >> it implies "proxyattrset 0 *", which means all attributes. >> Unfortunately, this seems to only work if no attribute is >> requested, while it fails if a "*" is explicitly requested. > > Ah, I was not aware of this behaviour! I've noticed it from the sources, I don't think it was noted anywhere. >> I've modified the propxycache code in HEAD so that a "1.1" can only >> explicitly appear in a list if it's the only string. An empty >> attribute set is no longer valid, to avoid confusion about the >> meaning of non-explicit attribute sets. A "*" or a "+" can >> explicitly appear in a proxyattrset statement, resulting in the >> expected behavior. Use both to indicate that all attributes are in >> the set. > > Let me confirm, that I should specify "proxyattrset 0 1.1" to match > an empty attribute list, and only an empty attribute list. Will a > '*' than match emptiness as well, or does it only match where there > is some attribute specified by the client? No: you need to specify proxyattrset <#idx> "*" in order to have either nothing or "*" return all attributes. In short, an empty attribute set and "*" are now recognized as equivalent. You need to specify proxyattrset <#idx> "1.1" in order to have searches requesting "1.1", namely no attributes, be cached. > I will work on this as soon as I am able to, although it seems this > won't be for a couple of weeks. I will be in touch. Thanks again > for your work and for your very timely response. Right now, I'm not planning to backport this fix to re23 because it seems to be an enhancement rather than a bugfix, and 2.4 __should be__ just 'round the corner. 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#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep＠ni.enate.org 09 Aug '07

09 Aug '07

On Aug 6, 2007, at 6:43 AM, Pierangelo Masarati wrote: > I believe there's something odd in pcache's current behavior. In > fact, right now "proxyattrset 0" is already a valid directive, but > it implies "proxyattrset 0 *", which means all attributes. > Unfortunately, this seems to only work if no attribute is > requested, while it fails if a "*" is explicitly requested. Ah, I was not aware of this behaviour! > I've modified the propxycache code in HEAD so that a "1.1" can only > explicitly appear in a list if it's the only string. An empty > attribute set is no longer valid, to avoid confusion about the > meaning of non-explicit attribute sets. A "*" or a "+" can > explicitly appear in a proxyattrset statement, resulting in the > expected behavior. Use both to indicate that all attributes are in > the set. Let me confirm, that I should specify "proxyattrset 0 1.1" to match an empty attribute list, and only an empty attribute list. Will a '*' than match emptiness as well, or does it only match where there is some attribute specified by the client? > Please test. I will work on this as soon as I am able to, although it seems this won't be for a couple of weeks. I will be in touch. Thanks again for your work and for your very timely response. -Mike

1 0

ITS#4868
by ando＠sys-net.it 09 Aug '07

09 Aug '07

There remains an issue in back-sql: if a ';binary' attr is used in the filter, and the same attribute is requested with the ';binary' option, the latter is treated as a different attribute, and no value is returned because of sort of a malformed attribute inheritance test. For example, a search requesting 'userCertificate;binary' with a filter '(userCertificate=*)' would return no values for the userCertificate attribute, while if no ';binary' were used, userCertificate values would be returned. I'll commit a fix shortly. 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#5083) LDAP configuration problem
by quanah＠zimbra.com 09 Aug '07

09 Aug '07

--On Thursday, August 09, 2007 12:41 PM +0000 ranju(a)isl-bd.com wrote: > Full_Name: Mohammad nurul Huda > Version: 2.2.13-6.4E > OS: RedHat ES 4.0 Update 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.49.33.141) > > > When we run the following command in the LDAP configuration time it shows > the following error in the time of running below command: Please use openldap-software(a)openldap.org for software usage questions (i.e., I see no bug here). I will also note that OpenLDAP 2.2 is extremely old. I advise upgrading to a current, supported release. The current release is OpenLDAP 2.3.37. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5080) LDAP setup
by quanah＠zimbra.com 09 Aug '07

09 Aug '07

--On Thursday, August 09, 2007 4:29 AM +0000 srinibashudayasingh(a)gmail.com wrote: > Full_Name: srinibash udayasingh > Version: 2.3.7 > OS: red heart linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.14.7.138) This is not a bug. Please use openldap-software(a)openldap.org for usage questions. Please upgrade to a recent release before doing so (current release is 2.3.37). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5084) back-ldap does not return if remote server is unreachable
by ando＠sys-net.it 09 Aug '07

09 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando This is HEAD only as of today (re23 as of today works as expected). To reproduce: configure slapd with an ldap database pointing nowhere. p.

1 0

(ITS#5083) LDAP configuration problem
by ranju＠isl-bd.com 09 Aug '07

09 Aug '07

Full_Name: Mohammad nurul Huda Version: 2.2.13-6.4E OS: RedHat ES 4.0 Update 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.49.33.141) When we run the following command in the LDAP configuration time it shows the following error in the time of running below command: # ldapadd -x -D "cn=Manager,dc=<Domain>,dc=com" -W -f /etc/openldap/domain.com.ldif #Enter LDAP passwd: After puuting the ldap password it shows the following error message ldap_bind invalid credential (49) Another issue when i am seeing the log messages it shows the following error sql_select option missing auxprobfunce error no mechanisam available.

1 0

ITS#5082
by ando＠sys-net.it 09 Aug '07

09 Aug '07

See also discussion in thread <http://www.openldap.org/lists/openldap-software/200708/msg00063.html> 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

(ITS#5082) olcPasswordHash: Scheme not available
by mahashmi＠gmail.com 09 Aug '07

09 Aug '07

Full_Name: Mustafa A. Hashmi Version: 2.3.30 OS: Debian Etch (4.0) URL: Submission from: (NULL) (202.5.145.13) When slapd is initialized to read configuration via cn=config (-F /path/to/slapd.d), configuration directives are read before modules are loaded. This can result in slapd exiting when a configuration option, provided by a specific module, is found before the module is loaded. As an example: the directive password-hash {K5KEY} results in slapd existing with the following message: olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({K5KEY}) olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found config error processing cn=config: <olcPasswordHash> no valid hashes found The smbk5pwd module is loaded at a later stage during the initialization process. Please note: If cn=config.ldif is edited and the option removed, slapd will start normally and allow the option to be added at runtime.

1 0

(ITS#5081) [enhancement] hot startup for pcache?
by ando＠sys-net.it 09 Aug '07

09 Aug '07

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando What about a hot startup for pcache? Right now, if a slapd with a fresh pcache is stopped and restarted, the contents of the cache are ignored since the pcache has no notion of the cached queries. They could be saved (routinely, or at shutdown), in an operational attribute attached to the root entry, to allow hot startup. p.

1 0

(ITS#5080) LDAP setup
by srinibashudayasingh＠gmail.com 08 Aug '07

08 Aug '07

Full_Name: srinibash udayasingh Version: 2.3.7 OS: red heart linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.14.7.138) Hi I am new in open LDAP.i am unable to setup.Last 1 month i am trying to setup.I have follow the steps in openldap.org.I find the following error.Can you please help me to setup.I am using version :2.3.7 and softerra Adminstrative 3.4 tool. <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=3 p=3 send_ldap_result: err=32 matched="" text="" send_ldap_response: msgid=43 tag=101 err=32

1 0

Re: (ITS#5079) Sourious warnings in slapd-bdb/hdb about missing objectClass at add
by ando＠sys-net.it 08 Aug '07

08 Aug '07

quanah(a)zimbra.com wrote: > CVS log for servers/slapd/back-bdb/search.c > 1.221.2.16 Fri Jul 20 22:42:26 2007 UTC; 2 weeks, 4 days ago by hyc > Branch: OPENLDAP_REL_ENG_2_3 > Changed since 1.221.2.15: +2 -1 lines > Diffs to 1.221.2.15 (colored diff) > > Set e_ocflags on dummy context entry That's for search; I'm seeing it during add. I copied the fix from HEAD, mine differs from that of Howard. Maybe we should converge to a common one... 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#5073) Syncrepl spinlock
by quanah＠zimbra.com 08 Aug '07

08 Aug '07

--On Wednesday, August 08, 2007 1:05 PM +0000 ando(a)sys-net.it wrote: > I vote for the first. Me too. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5079) Sourious warnings in slapd-bdb/hdb about missing objectClass at add
by quanah＠zimbra.com 08 Aug '07

08 Aug '07

--On Wednesday, August 08, 2007 4:24 PM +0000 ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: 2.3 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > When adding an entry rooted at "" to a back-bdb/hdb configured for the > empty suffix, warnings about the objectClass attribute being missing are > issued because a dummy root entry is checked for being an alias, a > referral and so. This has already been fixed in HEAD long ago, but > apparently, since no ITS was opened, the fix was not backported to 2.3. > It is not a showstopper, but it causes annoying spurious warnings to be > logged. I thought Howard fixed this just a little while ago? CVS log for servers/slapd/back-bdb/search.c 1.221.2.16 Fri Jul 20 22:42:26 2007 UTC; 2 weeks, 4 days ago by hyc Branch: OPENLDAP_REL_ENG_2_3 Changed since 1.221.2.15: +2 -1 lines Diffs to 1.221.2.15 (colored diff) Set e_ocflags on dummy context entry --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5079) Sourious warnings in slapd-bdb/hdb about missing objectClass at add
by ando＠sys-net.it 08 Aug '07

08 Aug '07

Full_Name: Pierangelo Masarati Version: 2.3 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When adding an entry rooted at "" to a back-bdb/hdb configured for the empty suffix, warnings about the objectClass attribute being missing are issued because a dummy root entry is checked for being an alias, a referral and so. This has already been fixed in HEAD long ago, but apparently, since no ITS was opened, the fix was not backported to 2.3. It is not a showstopper, but it causes annoying spurious warnings to be logged. p.

1 0

Re: (ITS#5073) Syncrepl spinlock
by ando＠sys-net.it 08 Aug '07

08 Aug '07

> Okay, I figured it out -- This is definitely a misconfiguration type > scenario... > > The database is something like: > > database bdb > base "dc=example,dc=com" > > ... > > Then the syncrepl config has: > searchbase="" > > I'm not sure this is something that should be allowed -- where the search > base is broader than the database. I'm not sure either, but in any case this is triggering a bug: an internal search is performed with base "" and scope "sub"; even though the database is configured to serve "dc=example,dc=com", it answers "success" with no data, since it erroneously treats itself as if handling the empty suffix. I think the bug here is that an internal search should never be invoked without making sure whether the base is within the naming context of the database. If the above configuration does not make sense, the check can be done at configuration; otherwise, it needs to be dealt with from within syncrepl_entry(). I vote for the first. 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#5078) slapd high cpu usage
by marg＠rz.tu-clausthal.de 08 Aug '07

08 Aug '07

Hello, Babu.Suresh(a)pacificlife.com wrote: > bdb_db_open: Warning - No DB_CONFIG file found in directory=20 > Expect poor performance for suffix o=3Dpacificlife.com. Well, slapd even gives you hints for better performance... > <=3D bdb_equality_candidates: (uid) index_param failed (18) > <=3D bdb_equality_candidates: (cn) index_param failed (18) > <=3D bdb_equality_candidates: (uniqueMember) index_param failed (18) Obviously there are some indices missing in the Database. First add configuration for indices cn, uniquemember then re-index/rebuild database. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

1 0

Re: (ITS#5078) slapd high cpu usage
by ando＠sys-net.it 07 Aug '07

07 Aug '07

Please do not post in HTML. p. Babu.Suresh(a)pacificlife.com wrote: > This is a multi-part message in MIME format. <snip> 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: Re: (ITS#5078) slapd high cpu usage
by Babu.Suresh＠pacificlife.com 07 Aug '07

07 Aug '07

This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D93E.7410BF9A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable OpenLDAP version we are using is - 2.3.32=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DHere is the debug log of one = login=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bdb_db_open: Warning - No DB_CONFIG file found in directory=20 Expect poor performance for suffix o=3Dpacificlife.com. slapd starting conn=3D0 fd=3D10 ACCEPT from IP=3Dxxxxxxxxx) conn=3D0 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D0 op=3D0 RESULT tag=3D97 err=3D0 text=3D conn=3D0 op=3D1 SRCH base=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxxm= "= scope=3D1 deref=3D0 filter=3D"(&(uid=3Dxxxxxxx)(objectClass=3Dperson))" conn=3D0 op=3D1 SRCH attr=3D1.1 <=3D bdb_equality_candidates: (uid) index_param failed (18) conn=3D0 op=3D2 BIND anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D2 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D2 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D0 op=3D2 RESULT tag=3D97 err=3D0 text=3D conn=3D0 op=3D3 BIND anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D3 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D3 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D0 op=3D3 RESULT tag=3D97 err=3D0 text=3D conn=3D1 fd=3D12 ACCEPT from IP=3D12.12.1.11:40660 = (IP=3D10.141.1.217:121212) conn=3D1 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D1 op=3D0 BIND dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = mech=3DSIMPLE ssf=3D0 conn=3D1 op=3D0 RESULT tag=3D97 err=3D0 text=3D conn=3D1 op=3D1 SRCH base=3D"ou=3DPeople,ou=3DInternet,o=3Dpacificlife.com"= = scope=3D1 deref=3D0 filter=3D"(&(uid=3Dplevone)(objectClass=3Dperson))" conn=3D1 op=3D1 SRCH attr=3D1.1 <=3D bdb_equality_candidates: (uid) index_param failed (18) conn=3D1 op=3D2 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(&(uniqueMember=3Duid=3Dplevone,ou=3Dpeople,ou=3Dinternet,o=3Dp= acificlife. com)(objectClass=3DgroupOfUniqueNames))" conn=3D1 op=3D2 SRCH attr=3Dcn <=3D bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D0 op=3D4 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(|(&(cn=3Dpresenters)(objectClass=3DgroupOfUniqueNames))(&(cn= =3Dpresen ters)(objectClass=3DgroupOfURLs)))" conn=3D0 op=3D4 SRCH attr=3D1.1 <=3D bdb_equality_candidates: (cn) index_param failed (18) <=3D bdb_equality_candidates: (cn) index_param failed (18) conn=3D0 op=3D5 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(&(uniqueMember=3Dcn=3Dpresenters,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxx= xxx)(object Class=3DgroupOfUniqueNames))" conn=3D0 op=3D5 SRCH attr=3Dcn <=3D bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D1 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D4 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D5 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D3 SRCH base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 = deref=3D0 =66ilter=3D"(objectClass=3DgroupOfURLs)" conn=3D1 op=3D3 SRCH attr=3Dcn memberURL conn=3D1 op=3D3 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D1 text=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ---------------------------------------------------------------------------= --- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------_=_NextPart_001_01C7D93E.7410BF9A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7651.59"> <TITLE>RE: Re: (ITS#5078) slapd high cpu usage</TITLE> </HEAD> <BODY>  OpenLDAP version we are = using is - 2.3.32 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DHere is the debug log of = one login=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D bdb_db_open: Warning - = No DB_CONFIG file found in directory Expect poor performance= = =66or suffix o=3Dpacificlife.com. slapd starting conn=3D0 fd=3D10 ACCEPT= = =66rom IP=3Dxxxxxxxxx) conn=3D0 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D0 op=3D0 RESULT = tag=3D97 err=3D0 text=3D conn=3D0 op=3D1 SRCH = base=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxxm" scope=3D1= = deref=3D0 = =66ilter=3D"(&(uid=3Dxxxxxxx)(objectClass=3Dperson))"<= /P> conn=3D0 op=3D1 SRCH = attr=3D1.1 <=3D = bdb_equality_candidates: (uid) index_param failed (18) conn=3D0 op=3D2 BIND = anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D2 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D2 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D0 op=3D2 RESULT = tag=3D97 err=3D0 text=3D conn=3D0 op=3D3 BIND = anonymous mech=3Dimplicit ssf=3D0 conn=3D0 op=3D3 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D0 op=3D3 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D0 op=3D3 RESULT = tag=3D97 err=3D0 text=3D conn=3D1 fd=3D12 ACCEPT= = =66rom IP=3D12.12.1.11:40660 (IP=3D10.141.1.217:121212) conn=3D1 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" = method=3D128 conn=3D1 op=3D0 BIND = dn=3D"uid=3Dxxxxxx,ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" mech=3DSIMPL= E= ssf=3D0 conn=3D1 op=3D0 RESULT = tag=3D97 err=3D0 text=3D conn=3D1 op=3D1 SRCH = base=3D"ou=3DPeople,ou=3DInternet,o=3Dpacificlife.com" scope=3D1 = deref=3D0 = =66ilter=3D"(&(uid=3Dplevone)(objectClass=3Dperson))"<= /P> conn=3D1 op=3D1 SRCH = attr=3D1.1 <=3D = bdb_equality_candidates: (uid) index_param failed (18) conn=3D1 op=3D2 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(&(uniqueMember=3Duid=3Dplevone,ou=3Dpeople,ou=3Dinter= net,o=3Dpacificlife.com)(objectClass=3DgroupOfUniqueNames))" conn=3D1 op=3D2 SRCH = attr=3Dcn <=3D = bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D0 op=3D4 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(|(&(cn=3Dpresenters)(objectClass=3DgroupOfUniqueNames= ))(&(cn=3Dpresenters)(objectClass=3DgroupOfURLs)))" conn=3D0 op=3D4 SRCH = attr=3D1.1 <=3D = bdb_equality_candidates: (cn) index_param failed (18) <=3D = bdb_equality_candidates: (cn) index_param failed (18) conn=3D0 op=3D5 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(&(uniqueMember=3Dcn=3Dpresenters,ou=3Dxxxxxxx,ou=3Dxx= xx,o=3Dxxxxx)(objectClass=3DgroupOfUniqueNames))" conn=3D0 op=3D5 SRCH = attr=3Dcn <=3D = bdb_equality_candidates: (uniqueMember) index_param failed (18) conn=3D1 op=3D2 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D4 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D conn=3D0 op=3D5 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D3 SRCH = base=3D"ou=3Dxxxxxxx,ou=3Dxxxx,o=3Dxxxxx" scope=3D1 deref=3D0 = =66ilter=3D"(objectClass=3DgroupOfURLs)" conn=3D1 op=3D3 SRCH = attr=3Dcn memberURL conn=3D1 op=3D3 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D0 text=3D conn=3D1 op=3D1 SEARCH = RESULT tag=3D101 err=3D0 nentries=3D1 text=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D <pre = wrap>----------------------------------------------------------------------= -------- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D </pre></BODY> </HTML> ------_=_NextPart_001_01C7D93E.7410BF9A--

1 0

Re: (ITS#5078) slapd high cpu usage
by Babu.Suresh＠pacificlife.com 07 Aug '07

07 Aug '07

This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D93C.273C1782 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable thank you Quanah for your quick response. see bellow.. What version of OpenLDAP 2.3=3F -->V2.3.4 Have you configured the DB_CONFIG file=3F -->NO You can still use cachesize whether or not it is restarted nightly. -->will do Have you examined the logs at loglevel 256 to see what kind of searches are being performed, so you can optimize your indices=3F -->yes, we did but I didn't put much attention to this. I will perform again and post the output. thank you ---------------------------------------------------------------------------= --- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------_=_NextPart_001_01C7D93C.273C1782 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7651.59"> <TITLE>Re: (ITS#5078) slapd high cpu usage</TITLE> </HEAD> <BODY>  thank you Quanah for your quick = response. see bellow.. What version of OpenLDAP = 2.3=3F -->V2.3.4 Have you configured the DB_CONFIG = =66ile=3F -->NO You can still use cachesize whether= = or not it is restarted nightly. -->will do Have you examined the logs at = loglevel 256 to see what kind of searches are being performed, so you can = optimize your indices=3F -->yes, we did but I didn't put = much attention to this. I will perform again and post the output. thank you <pre = wrap>----------------------------------------------------------------------= -------- The information in this e-mail and any attachments are for the sole use of = the intended recipient and may contain privileged and confidential = information. If you are not the intended recipient, any use, disclosure, = copying or distribution of this message or attachment is strictly = prohibited. If you believe that you have received this e-mail in error, = please contact the sender immediately and delete the e-mail and all of its = attachments. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D </pre></BODY> </HTML> ------_=_NextPart_001_01C7D93C.273C1782--

1 0

Re: (ITS#5078) slapd high cpu usage
by quanah＠zimbra.com 07 Aug '07

07 Aug '07

--On Tuesday, August 07, 2007 6:25 PM +0000 babu.suresh(a)pacificlife.com wrote: > Full_Name: Babu > Version: 2.3 > OS: RedHAT3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.181.11.27) > > > Hello, > > > We are using openldap2.3, BDB 4.5.20 and Rehat3..seeing having high cpu > usage of the slapd process. What version of OpenLDAP 2.3? Have you configured the DB_CONFIG file? You can still use cachesize whether or not it is restarted nightly. Have you examined the logs at loglevel 256 to see what kind of searches are being performed, so you can optimize your indices? In any case, I see no bug here. Please redirect further questions and response to openldap-software(a)openldap.org --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5078) slapd high cpu usage
by babu.suresh＠pacificlife.com 07 Aug '07

07 Aug '07

Full_Name: Babu Version: 2.3 OS: RedHAT3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.181.11.27) Hello, We are using openldap2.3, BDB 4.5.20 and Rehat3..seeing having high cpu usage of the slapd process. Tried with bellow indexes, we can't use "cachesize" as we have nightly restart of the process and cache go away (let me know there is way to save cache and it will be available even after restart of slapd); also we have yearly onetime users in our system. Please let me know what are can be done to solve slapd high cpu utilization problem. ====indexes in slapd.conf==== index objectClass eq index uid pres, eq ========= =========CPU usage with 3/4 users concurrent login========= 321 processes: 319 sleeping, 2 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 28.0% 0.0% 7.8% 0.0% 0.0% 7.9% 56.0% cpu00 47.6% 0.0% 8.9% 0.0% 0.3% 2.3% 40.6% cpu01 32.8% 0.0% 7.7% 0.0% 0.0% 0.7% 58.6% cpu02 19.4% 0.0% 8.1% 0.0% 0.0% 14.1% 58.2% cpu03 12.1% 0.0% 6.5% 0.0% 0.0% 14.5% 66.7% PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 30973 xxxxx 19 0 148M 148M 2224 R 15.4 3.1 4:44 0 slapd 30975 xxxxx 18 0 148M 148M 2224 S 9.5 3.1 3:51 3 slapd 32030 xxxxxx 19 0 148M 148M 2224 S 7.9 3.1 3:59 1 slapd

1 0

Coredump on ACLs for nonexistent Attributes. Is it a bug?
by Christian Marg 07 Aug '07

07 Aug '07

Hello, I didn't find an ITS concerning what I encountered yesterday: I had ACLs defined for undefined attributes (e.g. a schema file was missing some entries) and slaptest etc. crashed with dumped core. The message I got was: slaptest in free(): error: junk pointer, too high to make sense Abort (core dumped) I'm using v 2.3.34 on FreeBSD 6.2-RELEASE-p3. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

2 2

Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 07 Aug '07

07 Aug '07

ando(a)sys-net.it wrote: > At this point, it sounds like that your contribution could be > __entirely__ reworked into simply adding caching capabilities into the > current {SASL} password scheme (implemented in servers/slapd/sasl.c), > preserving the logics you're using right now. You'd probably need to > define your own "cachedUserPassword" attribute to temporarily store the > cached credentials, unless something like this: > > userPassword: {SASL}user > userPassword: {<hash>}<hashed password> > > allows the {SASL} module to fetch the next value of the userPassowrd and > treat it as the cached value. The rest would be adding some TTL mech, > configurable via back-config, and that should be it. > > Yet another option would be to allow per-entry caching, by defining a > new {CACHED-SASL} scheme. This way, one could fine-grain decide whose > credentials can be cached and whose can't, letting the two cases share > most of the code. I'd allow {SASL} to be cached as well, in case the > administrator just wants to allow all {SASL} auths to be cached. For this purpose, it might be necessary to change the API of password scheme handling, so that it gets passed a pointer to the entire entry, read-only locked, so that attributes like the "cachedPwd" and the "cachedPwdTimestamp" can be fetched and used. With respect to updating them, we might need to add some means to schedule internal modifications to be performed as soon as the entry lock is released. Thoughts? 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: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 07 Aug '07

07 Aug '07

s.hetze(a)linux-ag.de wrote: > Renaming the variables is no problem. What would you say extpwc stands > for? EXT ernal P ass W ord C ache? > I can imagine to call the module krb5pwc and head the README > "Kerberos V/Active Directory Password Cache" Right; but, this would limit yourself to Kerberos V; see my other posting about rather delegating auth to SASL. >> Well, that could be a parameter that is provided through the >> configuration (caching TTL, optional negative caching TTL, and so). It >> doesn't need to be stored in the entry, or in a subentry, since dynamic >> configuration would allow to modify it run-time anyway. >> > > If I understand it correct, you suggest to let the cached password > expire after some configurable time. To achieve this, I would need to > keep a timestamp when the password was cached. > Is there any other way than to add an attribute holding this timestamp? > ... > Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any > and use the sambaPwdLastSet attribute. Right; I think a specific operational attribute would be better. 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: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de 07 Aug '07

07 Aug '07

Hi Pierangelo, On Tue, Aug 07, 2007 at 11:41:58AM +0200, Pierangelo Masarati wrote: > s.hetze(a)linux-ag.de wrote: > > >>2) you could try to rework the overlay to avoid any specific reference > >>to Active Directory, since your cache should apply to any remote system > >>implementing Kerberos V. It could be abstracted even more, to act as a > >>replacement of saslauthd, by allowing it to auth via LDAP, pam and more, > >>not just Kerberos. > > > >Actually, the software was built and tested agains MIT and Heimdal > >Kerberos V in the first place, so there is no dependency on AD > >whatsoever. The reference to AD is more a marketing issue. I assume > >more users looking for an AD password cache than for an Kerberos V > >password cache. So I would perfer to keep it. > > I understand this, and I think it's just fine to advertise it like that, > but in the code I'd prefer to avoid, for example, naming all variables > after "ad" something. Perhaps s/adpwc/extpwc/ would be a little bit better? Renaming the variables is no problem. What would you say extpwc stands for? I can imagine to call the module krb5pwc and head the README "Kerberos V/Active Directory Password Cache" > > >>3) you should add a (configurable) TTL, so that the cache could > >>eventually be notified of an account lockout at the remote server's side. > > > >I tried to avoid introduction of new attributes for the module. Do you > >have any suggestions how this TTL should be stored? Adding pwdPolicy > >from ppolicy seems a bit like an overkill to me. > > Well, that could be a parameter that is provided through the > configuration (caching TTL, optional negative caching TTL, and so). It > doesn't need to be stored in the entry, or in a subentry, since dynamic > configuration would allow to modify it run-time anyway. > If I understand it correct, you suggest to let the cached password expire after some configurable time. To achieve this, I would need to keep a timestamp when the password was cached. Is there any other way than to add an attribute holding this timestamp? ... Actually, I could make this feature depend on the {ad|krb5}pw-cache-mode=any and use the sambaPwdLastSet attribute. > >>4) you should add support for dynamic configuration, so that the module > >>can fit into the new configuration paradigm for possible release with 2.4. > > > >I'll look into that. > > If you need help, please holler. However, I see that for such a simple > (from a configuration point of view) module, looking into smbk5pwd > should suffice. Thanx for your offer, and I agree to look into the existing overlays (again ;-) That's the fun with free software! Regards, Sebastian

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 07 Aug '07

07 Aug '07

s.hetze(a)linux-ag.de wrote: > I don't see the benefit of delegating the password cache mechanism to > saslauthd or a possible replacement. Wouldn't I have to implement each > possible password store anyway? > If I understand it correct, the {SASL} userPassword mechanism delegates > authentication to saslauthd. > saslauthd can easily authenticate against Kerberos and AD and it is > possible let it cache the password for its own authentication purposes. > If I want the sambaNTPassword attribute to be available (to be able to > run samba as a NT4 PDC independent of AD ) or if I want to have the > password additionally cached as MIT Kerberos credential, I would need > to implement both individually one way or another. > So why not going the short way and let the overlay module do this? The {SASL} userPassword delegates authentication to SASL; then, by configuring SASL to use saslauthd, SASL delegates authentication to saslauthd, but it can be delegated to anything else. I think the point is: you should isolate what your piece of software is originally contributing, and what it's "reinventing". The original contribution, as far as I understand, is the capability to cache athentication rather than always propagating it. This capability is not currently present in OpenLDAP. What is already present is the SASL, which is an abstraction layer for authentication; think of it as a superset of Kerberos, which is the only authentication method you're considering in your piece of software. At this point, it sounds like that your contribution could be __entirely__ reworked into simply adding caching capabilities into the current {SASL} password scheme (implemented in servers/slapd/sasl.c), preserving the logics you're using right now. You'd probably need to define your own "cachedUserPassword" attribute to temporarily store the cached credentials, unless something like this: userPassword: {SASL}user userPassword: {<hash>}<hashed password> allows the {SASL} module to fetch the next value of the userPassowrd and treat it as the cached value. The rest would be adding some TTL mech, configurable via back-config, and that should be it. Yet another option would be to allow per-entry caching, by defining a new {CACHED-SASL} scheme. This way, one could fine-grain decide whose credentials can be cached and whose can't, letting the two cases share most of the code. I'd allow {SASL} to be cached as well, in case the administrator just wants to allow all {SASL} auths to be cached. 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: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de 07 Aug '07

07 Aug '07

Hi Kurt, On Mon, Aug 06, 2007 at 12:55:11PM -0700, Kurt Zeilenga wrote: > >2) you could try to rework the overlay to avoid any specific reference > >to Active Directory, since your cache should apply to any remote > >system > >implementing Kerberos V. It could be abstracted even more, to act > >as a > >replacement of saslauthd, by allowing it to auth via LDAP, pam and > >more, > >not just Kerberos. > > s/to act as a replacement/to defer external authentication to saslauthd > or the like/ > > In slapd(8), we deferred verification against external password > stores to saslauthd > via the {SASL} userPassword mechanism, thus avoiding needing to > implement > and support each possible external password store (such as a KDC). > This module > should likewise avoid supporting (some subset of) external passwords > stores. > saslauthd(8) can easily be extended (or replaced) to support additional > password stores as needed. As provided in Cyrus SASL today, it > supports both > LDAP and Kerberos as external password stores. > I don't see the benefit of delegating the password cache mechanism to saslauthd or a possible replacement. Wouldn't I have to implement each possible password store anyway? If I understand it correct, the {SASL} userPassword mechanism delegates authentication to saslauthd. saslauthd can easily authenticate against Kerberos and AD and it is possible let it cache the password for its own authentication purposes. If I want the sambaNTPassword attribute to be available (to be able to run samba as a NT4 PDC independent of AD ) or if I want to have the password additionally cached as MIT Kerberos credential, I would need to implement both individually one way or another. So why not going the short way and let the overlay module do this? Regards, Sebastian

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 07 Aug '07

07 Aug '07

s.hetze(a)linux-ag.de wrote: >> 2) you could try to rework the overlay to avoid any specific reference >> to Active Directory, since your cache should apply to any remote system >> implementing Kerberos V. It could be abstracted even more, to act as a >> replacement of saslauthd, by allowing it to auth via LDAP, pam and more, >> not just Kerberos. > > Actually, the software was built and tested agains MIT and Heimdal > Kerberos V in the first place, so there is no dependency on AD > whatsoever. The reference to AD is more a marketing issue. I assume > more users looking for an AD password cache than for an Kerberos V > password cache. So I would perfer to keep it. I understand this, and I think it's just fine to advertise it like that, but in the code I'd prefer to avoid, for example, naming all variables after "ad" something. Perhaps s/adpwc/extpwc/ would be a little bit better? >> 3) you should add a (configurable) TTL, so that the cache could >> eventually be notified of an account lockout at the remote server's side. > > I tried to avoid introduction of new attributes for the module. Do you > have any suggestions how this TTL should be stored? Adding pwdPolicy > from ppolicy seems a bit like an overkill to me. Well, that could be a parameter that is provided through the configuration (caching TTL, optional negative caching TTL, and so). It doesn't need to be stored in the entry, or in a subentry, since dynamic configuration would allow to modify it run-time anyway. >> 4) you should add support for dynamic configuration, so that the module >> can fit into the new configuration paradigm for possible release with 2.4. > > I'll look into that. If you need help, please holler. However, I see that for such a simple (from a configuration point of view) module, looking into smbk5pwd should suffice. >> 5) you should follow coding guidelines (indentation and so) as in most >> of the code. > > I did not find any guidelines other than "Adapt your style to match that > of the block, file, directory, or package that you are working in." > Can you point me to a more detailed explanation of the required > indentation? There isn't actually, but looking into any "recent" piece of code would suffice; things like: use tabs for indent, leave spaces in brackets and so... not a big deal, though. Cheers, 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: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de 07 Aug '07

07 Aug '07

Hi Pierangelo, thanx for your comments. On Mon, Aug 06, 2007 at 09:32:27PM +0200, Pierangelo Masarati wrote: > Sebastian, > > Thanks for the contribution. > > I have a few comments (also gathered from others): > > 1) you should provide patches against HEAD code; there has been some > limited changes in the API related to overlay initialization and so. No problem, I will look into that shortly. > > 2) you could try to rework the overlay to avoid any specific reference > to Active Directory, since your cache should apply to any remote system > implementing Kerberos V. It could be abstracted even more, to act as a > replacement of saslauthd, by allowing it to auth via LDAP, pam and more, > not just Kerberos. Actually, the software was built and tested agains MIT and Heimdal Kerberos V in the first place, so there is no dependency on AD whatsoever. The reference to AD is more a marketing issue. I assume more users looking for an AD password cache than for an Kerberos V password cache. So I would perfer to keep it. > > 3) you should add a (configurable) TTL, so that the cache could > eventually be notified of an account lockout at the remote server's side. I tried to avoid introduction of new attributes for the module. Do you have any suggestions how this TTL should be stored? Adding pwdPolicy from ppolicy seems a bit like an overkill to me. > > 4) you should add support for dynamic configuration, so that the module > can fit into the new configuration paradigm for possible release with 2.4. I'll look into that. > > 5) you should follow coding guidelines (indentation and so) as in most > of the code. I did not find any guidelines other than "Adapt your style to match that of the block, file, directory, or package that you are working in." Can you point me to a more detailed explanation of the required indentation? Regards, Sebastian

1 0

(ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 06 Aug '07

06 Aug '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) In "while" loop at 2656, I find old->a_vals are like [..., a, b, ...] and new->a_vals are like [..., b, a, ...]. Matches are found at old [i] == new [k = j+1] and old [k = i+1] == new [j], but this just shows that neither an add nor a delete is called for, and the loop end is reached without having incremented i or j. Actual attribute values I'm looking at right now in the debugger are eduPersonAffiliation: old [ member, alum, employee, faculty ], new [ member, alum, faculty, employee ]. I built the replica from a slapcat dump on the idle master, started the slapd syncrepl client and applied a lot of normal modifications to the master, until it hit the infinite loop. It has been a recurrent problem.

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by kurt＠OpenLDAP.org 06 Aug '07

06 Aug '07

On Aug 6, 2007, at 7:31 PM, ando(a)sys-net.it wrote: > Sebastian, > > Thanks for the contribution. > > I have a few comments (also gathered from others): > > 1) you should provide patches against HEAD code; there has been some > limited changes in the API related to overlay initialization and so. > > 2) you could try to rework the overlay to avoid any specific reference > to Active Directory, since your cache should apply to any remote > system > implementing Kerberos V. It could be abstracted even more, to act > as a > replacement of saslauthd, by allowing it to auth via LDAP, pam and > more, > not just Kerberos. s/to act as a replacement/to defer external authentication to saslauthd or the like/ In slapd(8), we deferred verification against external password stores to saslauthd via the {SASL} userPassword mechanism, thus avoiding needing to implement and support each possible external password store (such as a KDC). This module should likewise avoid supporting (some subset of) external passwords stores. saslauthd(8) can easily be extended (or replaced) to support additional password stores as needed. As provided in Cyrus SASL today, it supports both LDAP and Kerberos as external password stores. > > 3) you should add a (configurable) TTL, so that the cache could > eventually be notified of an account lockout at the remote server's > side. > > 4) you should add support for dynamic configuration, so that the > module > can fit into the new configuration paradigm for possible release > with 2.4. > > 5) you should follow coding guidelines (indentation and so) as in most > of the code. > > p.

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by ando＠sys-net.it 06 Aug '07

06 Aug '07

Sebastian, Thanks for the contribution. I have a few comments (also gathered from others): 1) you should provide patches against HEAD code; there has been some limited changes in the API related to overlay initialization and so. 2) you could try to rework the overlay to avoid any specific reference to Active Directory, since your cache should apply to any remote system implementing Kerberos V. It could be abstracted even more, to act as a replacement of saslauthd, by allowing it to auth via LDAP, pam and more, not just Kerberos. 3) you should add a (configurable) TTL, so that the cache could eventually be notified of an account lockout at the remote server's side. 4) you should add support for dynamic configuration, so that the module can fit into the new configuration paradigm for possible release with 2.4. 5) you should follow coding guidelines (indentation and so) as in most of the code. 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#5073) Syncrepl spinlock
by quanah＠zimbra.com 06 Aug '07

06 Aug '07

--On August 6, 2007 5:01:08 PM +0000 quanah(a)zimbra.com wrote: > > > --On August 6, 2007 9:17:01 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.37 >>> OS: Linux >>> URL: >>> Submission from: (NULL) (71.202.148.128) >>> >>> >>> If you create a syncrepl master that serves the "" base, and then set up >>> a syncrepl consumer to pull down "dc=example,dc=com", which does *not* >>> exist on the master, the replica will sit at 100% CPU, endlessly trying >>> to add nothing. >> >> I'm not observing this with either re23 nor HEAD. The initial search >> correctly fails with noSuchObject, and then both slapds sit at 0% CPU. >> Can you give further details? > > I'll look at reproducing it again. > > In this particular case, the master had a database rooted at "", with > some data around "cn=zimbra" contained in it. A replica was configured > as a syncrepl client, but with "dc=example,dc=com" as its base, by > mistake. This resulted in the CPU usage shooting to 100% on the replica, > and the logs showing it trying to add without success. Okay, I figured it out -- This is definitely a misconfiguration type scenario... The database is something like: database bdb base "dc=example,dc=com" ... Then the syncrepl config has: searchbase="" I'm not sure this is something that should be allowed -- where the search base is broader than the database. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5073) Syncrepl spinlock
by quanah＠zimbra.com 06 Aug '07

06 Aug '07

--On August 6, 2007 9:17:01 AM +0000 ando(a)sys-net.it wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.37 >> OS: Linux >> URL: >> Submission from: (NULL) (71.202.148.128) >> >> >> If you create a syncrepl master that serves the "" base, and then set up >> a syncrepl consumer to pull down "dc=example,dc=com", which does *not* >> exist on the master, the replica will sit at 100% CPU, endlessly trying >> to add nothing. > > I'm not observing this with either re23 nor HEAD. The initial search > correctly fails with noSuchObject, and then both slapds sit at 0% CPU. > Can you give further details? I'll look at reproducing it again. In this particular case, the master had a database rooted at "", with some data around "cn=zimbra" contained in it. A replica was configured as a syncrepl client, but with "dc=example,dc=com" as its base, by mistake. This resulted in the CPU usage shooting to 100% on the replica, and the logs showing it trying to add without success. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5076) Spell checking man pages
by ghenry＠OpenLDAP.org 06 Aug '07

06 Aug '07

Full_Name: Gavin Henry Version: HEAD adn RE_23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry Dear all, Just creating a ticket for CHANGES, as I'm running: aspell --lang=en_US -c on all our manpages in HEAD and RE_23. Will query if I haev any concerns. Gavin.

1 0

Re: ITS#5075
by ando＠sys-net.it 06 Aug '07

06 Aug '07

ando(a)sys-net.it wrote: > fixed in HEAD; please test. also fixed in re23; please test. 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

ITS#5075
by ando＠sys-net.it 06 Aug '07

06 Aug '07

fixed in HEAD; please test. 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

(ITS#5075) openldap is not compilable with newest glibc and -D_FORTIFY_SOURCE=2
by jsafranek＠redhat.com 06 Aug '07

06 Aug '07

Full_Name: Jan Safranek Version: 2.3.37 OS: Linux (Fedora rawhide) URL: http://people.redhat.com/jsafrane/openldap-2.3.37-fortify-open.patch Submission from: (NULL) (62.40.79.66) Recently we have integrated glibc 2.6.90 into Fedora Linux distribution and OpenLDAP is not compilable anymore. We use -D_FORTIFY_SOURCE=2 to check for common errors on compile time and this switch causes that open() in fcntl.h is not a function name but a macro in the new glibc headers. Berkeley DB often uses 'something->open(...)' to open database, which is expanded by the compiler using the macro from fcntl.h -> compilation error. Compilation can be easily fixed by using additional braces around open, like '(something->open)(...)'. I do not like open() being macro, but POSIX allows it and glibc guys seems to be quite strict in this. The new glibc shall be released in fall and all major distributions will use it sooner or later, therefore I would suggest to adapt few OpenLDAP sources to it.

1 0

Re: (ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by ando＠sys-net.it 06 Aug '07

06 Aug '07

zep-openldap-software(a)ni.enate.org wrote: > For an application which specifies LDAP_NO_ATTRS to the attributes parameter of > ldap_search_st(), it seems not possible to cache its results using > slapo-pcache. > > It would be great to be able to define within "overlay pcache", something like: > > proxyattrset 0 (1.1) > > or, simply > > proxyattrset 0 > > Which would match queries which provide LDAP_NO_ATTRS. This would allow the > ability to cache responses for routines which are interested only in the > presence of a result set, but not in the contents of that set, without the > additional overhead of trasnferring the result. I believe there's something odd in pcache's current behavior. In fact, right now "proxyattrset 0" is already a valid directive, but it implies "proxyattrset 0 *", which means all attributes. Unfortunately, this seems to only work if no attribute is requested, while it fails if a "*" is explicitly requested. I've modified the propxycache code in HEAD so that a "1.1" can only explicitly appear in a list if it's the only string. An empty attribute set is no longer valid, to avoid confusion about the meaning of non-explicit attribute sets. A "*" or a "+" can explicitly appear in a proxyattrset statement, resulting in the expected behavior. Use both to indicate that all attributes are in the set. Please test. 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#5073) Syncrepl spinlock
by ando＠sys-net.it 06 Aug '07

06 Aug '07

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: Linux > URL: > Submission from: (NULL) (71.202.148.128) > > > If you create a syncrepl master that serves the "" base, and then set up a > syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on > the master, the replica will sit at 100% CPU, endlessly trying to add nothing. I'm not observing this with either re23 nor HEAD. The initial search correctly fails with noSuchObject, and then both slapds sit at 0% CPU. Can you give further details? 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

(ITS#5074) slapo-pcache's proxyattrset does not recognize "1.1" to describe an empty attribute set
by zep-openldap-software＠ni.enate.org 04 Aug '07

04 Aug '07

Full_Name: Mike Malsman Version: 2.3.33 OS: FreeBSD 6 URL: Submission from: (NULL) (65.12.196.28) For an application which specifies LDAP_NO_ATTRS to the attributes parameter of ldap_search_st(), it seems not possible to cache its results using slapo-pcache. It would be great to be able to define within "overlay pcache", something like: proxyattrset 0 (1.1) or, simply proxyattrset 0 Which would match queries which provide LDAP_NO_ATTRS. This would allow the ability to cache responses for routines which are interested only in the presence of a result set, but not in the contents of that set, without the additional overhead of trasnferring the result.

1 0

(ITS#5073) Syncrepl spinlock
by quanah＠OpenLDAP.org 03 Aug '07

03 Aug '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: Linux URL: Submission from: (NULL) (71.202.148.128) If you create a syncrepl master that serves the "" base, and then set up a syncrepl consumer to pull down "dc=example,dc=com", which does *not* exist on the master, the replica will sit at 100% CPU, endlessly trying to add nothing. --Quanah

1 0

(ITS#5072) Possibly incorrect certificateExactAssertion()
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.35) Submitted by: ando A certificate in certificateExactAssertion GSER form should be something like (wrapped for readability) { serialNumber 3, issuer rdnSequence:email=ca@example.com,cn=example ca,o=example,st=xx,c=us } according to RFC4523 & RFC3687, as far as I understand it. However, OpenLDAP HEAD uses the form { serialNumber 3, issuer "email=ca(a)example.com,cn=example ca,o=example,st=xx,c=us" } Note the quotes around the DN and the missing "rdnSequence:" prefix. p.

1 0

Re: (ITS#5069) SyncRepl on request
by bgmilne＠staff.telkomsa.net 03 Aug '07

03 Aug '07

On Wednesday 01 August 2007 23:53:22 hadmut(a)danisch.de wrote: > Full_Name: Hadmut Danisch > Version: 2.3.35 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.180.64.215) > > > This is an enhancement request: > > When having a distributed LDAP structure with a master and several SyncRepl > clients, the clients can do the SyncRepl only on fixed refresh intervals > (e.g. type=refreshOnly, > interval=00:00:20:00) > > However, there are many situations where this is inappropriate, e.g. on > dial-on connections, roaming notebooks, and things like that. > > Therefore, slapd should have a client mode where the SyncRepl process is > performed only on request, but then immediately. There should be an > external trigger to pull, e.g. send a signal oder do a special LDAP > request. slapd should then start a SyncRepl. > > E.g. this could be put in scripts run at connect-time (pppd provides that > kind of scripting), or when notebook autoconfiguration detects (e.g. with > tools like guessnet) that it is connected to the home network to update > it's local slapd. While I'm not saying this feature should not be implemented, I note that there are other solutions for doing off-line authentication on (e.g.) laptops that don't expose the whole DIT (but only credentials that have already been used on the client).

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 03 Aug '07

03 Aug '07

Kurt Zeilenga wrote: > This and other RFC 4511 BER restrictions do not apply to > BER/DER-encoded attribute values, such as certificates. A cleaner and simpler solution is in HEAD for those serials that fit into a long long, when it's available. Otherwise, arbitrary precision support is required (OpenSSL's bignum, GNU's GMP or so). Please test. 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#5071) ;binary issue
by kurt＠OpenLDAP.org 02 Aug '07

02 Aug '07

On Aug 2, 2007, at 11:01 PM, ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > > > I've noticed an issue related to operating on certificates with/ > without ;binary, > as detailed in the table below > > slapadd filter requested attrs > > | ;binary | no ;binary | ;binary | > no ;binary > -------------+--------------+--------------+-------------- > +--------------- > ;binary | results | results | returned | returned > -------------+--------------+--------------+-------------- > +--------------- > no ;binary | no results | results | not returned | returned > > So it seems that if data is loaded with ;binary then search > operations work > regardless of having specified ;binary in search filters or in > requested > attributes, while if data is loaded without, then search operations > only work if > ;binary is omitted. RFC 4523 states that ;binary MUST be used when > transferring > certificates, so perhaps slapd should be either liberal enough to > allow any > combination, or strict enough to prevent those data types from > working without > ;binary. The bug is in allowing a certificate to be loaded without ;binary. -- Kurt

1 0

(ITS#5071) ;binary issue
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) I've noticed an issue related to operating on certificates with/without ;binary, as detailed in the table below slapadd filter requested attrs | ;binary | no ;binary | ;binary | no ;binary -------------+--------------+--------------+--------------+--------------- ;binary | results | results | returned | returned -------------+--------------+--------------+--------------+--------------- no ;binary | no results | results | not returned | returned So it seems that if data is loaded with ;binary then search operations work regardless of having specified ;binary in search filters or in requested attributes, while if data is loaded without, then search operations only work if ;binary is omitted. RFC 4523 states that ;binary MUST be used when transferring certificates, so perhaps slapd should be either liberal enough to allow any combination, or strict enough to prevent those data types from working without ;binary. p.

1 0

Re: (ITS#5070) Issues in X.509 certificate parsing
by kurt＠OpenLDAP.org 02 Aug '07

02 Aug '07

On Aug 2, 2007, at 10:48 PM, ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> I've an issue with X.509 certificate parsing in HEAD/re24. The >> certificate, >> according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa >> and HEAD fails >> to parse it because it is an integer with length equal to 9, which >> is larger >> than sizeof(ber_int_t), as tested in ber_getnint() at decode.c: >> 254. The DER >> encoded value is: 2 9 0 200 91 154 221 234 191 249 250. >> Seems to be time >> to get past the sizeof(ber_int_t) limitation... > > ... which would violate RFC 4511 where it states that INTEGER means > from > 0 up to 2^31-1... This and other RFC 4511 BER restrictions do not apply to BER/DER-encoded attribute values, such as certificates. > I have a simple solution for this problem, at the > cost of partially violating rfc 4523: if an integer is larger than > 2^31-1, it could be represented in the certificateExactMatch > normalization in hexadecimal form, much like OpenSSL does. This would > increase interoperability with OpenSSL and be at least self- > consistent, > since all serialNumbers that large would be consistently expanded that > way. Another solution, preserving the decimal representation, would > probably require some arbitrary precision support from external > libraries. If there's consensus, I'd post my simple patch. > > 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#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

ando(a)sys-net.it wrote: > I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, > according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails > to parse it because it is an integer with length equal to 9, which is larger > than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER > encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time > to get past the sizeof(ber_int_t) limitation... ... which would violate RFC 4511 where it states that INTEGER means from 0 up to 2^31-1... I have a simple solution for this problem, at the cost of partially violating rfc 4523: if an integer is larger than 2^31-1, it could be represented in the certificateExactMatch normalization in hexadecimal form, much like OpenSSL does. This would increase interoperability with OpenSSL and be at least self-consistent, since all serialNumbers that large would be consistently expanded that way. Another solution, preserving the decimal representation, would probably require some arbitrary precision support from external libraries. If there's consensus, I'd post my simple patch. 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

(ITS#5070) Issues in X.509 certificate parsing
by ando＠sys-net.it 02 Aug '07

02 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've an issue with X.509 certificate parsing in HEAD/re24. The certificate, according to OpenSSL, has a SerialNumber c8:5b:9a:dd:ea:bf:f9:fa and HEAD fails to parse it because it is an integer with length equal to 9, which is larger than sizeof(ber_int_t), as tested in ber_getnint() at decode.c:254. The DER encoded value is: 2 9 0 200 91 154 221 234 191 249 250. Seems to be time to get past the sizeof(ber_int_t) limitation... p.

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by bgmilne＠staff.telkomsa.net 02 Aug '07

02 Aug '07

On Friday 27 July 2007 17:19:26 pbrinette(a)cc.in2p3.fr wrote: > > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is > > about to exit beta stage. Unless the problem is related to a real > > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this > > ITS will be closed. > > Currently, I've no mean to use an openldap 2.3 unless exists an RPM > update package for RHEL 4 (or CentOS). There is no update from RHEL or CentOS, but there are these (mine): http://staff.telkomsa.net/packages/rhel4/openldap/ Since you can install them in parallel, the upgrade path is quite easy ... (slapcat|slapadd2.3 after configuration). There is also: http://staff.telkomsa.net/packages/rhel3/openldap/ Regards, Buchan

1 0

(ITS#5069) SyncRepl on request
by hadmut＠danisch.de 01 Aug '07

01 Aug '07

Full_Name: Hadmut Danisch Version: 2.3.35 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.180.64.215) This is an enhancement request: When having a distributed LDAP structure with a master and several SyncRepl clients, the clients can do the SyncRepl only on fixed refresh intervals (e.g. type=refreshOnly, interval=00:00:20:00) However, there are many situations where this is inappropriate, e.g. on dial-on connections, roaming notebooks, and things like that. Therefore, slapd should have a client mode where the SyncRepl process is performed only on request, but then immediately. There should be an external trigger to pull, e.g. send a signal oder do a special LDAP request. slapd should then start a SyncRepl. E.g. this could be put in scripts run at connect-time (pppd provides that kind of scripting), or when notebook autoconfiguration detects (e.g. with tools like guessnet) that it is connected to the home network to update it's local slapd. regards Hadmut

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

Quanah Gibson-Mount wrote: > --On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.3.37 >>> OS: NA >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (66.92.25.194) >>> >>> >>> When using cn=config with a slapd.conf driven slapd, the value for >>> olcLogLevel is not correct: >>> >>> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >>> olcLogLevel >>> Enter LDAP Password: >>> dn: cn=config >>> olcLogLevel: None >>> >>> However: >>> >>> grep loglevel conf/slapd.conf >>> loglevel 32768 >>> >>> And the logging that is happening is actually for level 32768. >>> Modifying the loglevel works, and once that is done, the right loglevel >>> is shown. However, this makes it impossible to know what loglevel is >>> set via a remote query unless it has been changed. >> >>> From slapd.conf(5), loglevel: >> 32768 (0x8000 none) only messages that get logged >> whatever log level is set >> >> Seems to be correct. > > Yet if I modify it to be "256", then olcLogLevel is "256". If I modify > it to be "32768", then it is "32768". That's because in EMIT the loglevel goes through loglevel2bvarray(), which turns the level into an array of pretty values. You're supposed to modify the loglevel by adding multiple values, each with the descriptive name of the level you're using. The use of loglevel with OR'ed integers is stylistically deprecated. > So if the loglevel setting in > slapd.conf is "32768", then that is what it should match. In any case, > "None" has the unfortunate ring of sounding like an unset value. In LDAP, if the value were unset, the attribute would be missing, which is what you get if, for example, you set loglevel to 0. 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#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On Tuesday, July 31, 2007 4:35 AM +0000 ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.37 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (66.92.25.194) >> >> >> When using cn=config with a slapd.conf driven slapd, the value for >> olcLogLevel is not correct: >> >> ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W >> olcLogLevel >> Enter LDAP Password: >> dn: cn=config >> olcLogLevel: None >> >> However: >> >> grep loglevel conf/slapd.conf >> loglevel 32768 >> >> And the logging that is happening is actually for level 32768. >> Modifying the loglevel works, and once that is done, the right loglevel >> is shown. However, this makes it impossible to know what loglevel is >> set via a remote query unless it has been changed. > >> From slapd.conf(5), loglevel: > 32768 (0x8000 none) only messages that get logged > whatever log level is set > > Seems to be correct. Yet if I modify it to be "256", then olcLogLevel is "256". If I modify it to be "32768", then it is "32768". So if the loglevel setting in slapd.conf is "32768", then that is what it should match. In any case, "None" has the unfortunate ring of sounding like an unset value. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5067) olcLogLevel value is incorrect
by ando＠sys-net.it 30 Jul '07

30 Jul '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.37 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel > is not correct: > > ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W > olcLogLevel > Enter LDAP Password: > dn: cn=config > olcLogLevel: None > > However: > > grep loglevel conf/slapd.conf > loglevel 32768 > > And the logging that is happening is actually for level 32768. Modifying the > loglevel works, and once that is done, the right loglevel is shown. However, > this makes it impossible to know what loglevel is set via a remote query unless > it has been changed. >From slapd.conf(5), loglevel: 32768 (0x8000 none) only messages that get logged whatever log level is set Seems to be correct. 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#5068) buglet in charray.c
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

--On July 30, 2007 9:28:06 PM +0000 mb(a)g10code.com wrote: > Full_Name: Marcus Brinkmann > Version: 2.1.30 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.123.156.61) OpenLDAP 2.1 is no longer a supported release. The current release branch is OpenLDAP 2.3. Please do not file ITSes on dead releases. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5068) buglet in charray.c
by mb＠g10code.com 30 Jul '07

30 Jul '07

Full_Name: Marcus Brinkmann Version: 2.1.30 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.123.156.61) This fixes a warning and seems locally correct. I did not check the expected semantics of this code. Thanks, Marcus. diff -ru openldap2-2.1.30-orig/libraries/libldap/charray.c openldap2-2.1.30/libraries/libldap/charray.c --- openldap2-2.1.30-orig/libraries/libldap/charray.c 2003-03-03 18:10:04.000000000 +0100 +++ openldap2-2.1.30/libraries/libldap/charray.c 2007-07-30 23:24:30.000000000 +0200 @@ -183,7 +183,7 @@ i = 1; for ( s = str; *s; s++ ) { - if ( ldap_utf8_strchr( brkstr, s ) != NULL ) { + if ( ldap_utf8_strchr( brkstr, *s ) != NULL ) { i++; } }

1 0

(ITS#5067) olcLogLevel value is incorrect
by quanah＠zimbra.com 30 Jul '07

30 Jul '07

Full_Name: Quanah Gibson-Mount Version: 2.3.37 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) When using cn=config with a slapd.conf driven slapd, the value for olcLogLevel is not correct: ldapsearch -LLL -x -h build -b "cn=config" -s base -D "cn=config" -W olcLogLevel Enter LDAP Password: dn: cn=config olcLogLevel: None However: grep loglevel conf/slapd.conf loglevel 32768 And the logging that is happening is actually for level 32768. Modifying the loglevel works, and once that is done, the right loglevel is shown. However, this makes it impossible to know what loglevel is set via a remote query unless it has been changed.

1 0

Re: Contribution: Active Directory Password Cache (ITS#5042)
by s.hetze＠linux-ag.de 30 Jul '07

30 Jul '07

Hi Gavin, I just uploaded a patch for my contribution as Sebastian-Hetze-070630.patch (sorry for the wrong date) The adpwc as contributed has a dependency to samba3.schema to be present, which is fixed with this patch. The patch also makes adpwc fold realm names to upper case since AD stores them mixed case and gives tickets upper case. I introduced a new config option adpw-cache-keep-realm-case to keep the old behaviour if needed. It looks like I cannot add this patch to ticket #5042, so I ask you to attach it if possible. Thanx alot, Sebastian On Thu, Jul 19, 2007 at 09:48:58AM +0000, Gavin Henry wrote: > Hi, > > This looks like it is in the correct format for our contrib section. Just > testing is needed. As I don't have access to an Active Directory server I can't > test. > > Anyone else? > > Gavin. -- Sebastian Hetze Mitglied des Vorstands Linux Information Systems AG Ehrenbergstr. 19, D-10245 Berlin Fon: +49 30 726238-0, Fax: +49 30 726238-99 s.hetze(a)linux-ag.com, http://www.linux-ag.com ---------------------------------------------------------- Sitz der Gesellschaft: Stefan-George-Ring 8, 81929 München Amtsgericht München: HRB 128 019 Vorstand: Rudolf Strobl, Sebastian Hetze Aufsichtsrat: Michael Tarabochia (Vorsitzender)

1 0

(ITS#5066) ldap error :server down
by jalali_azam＠yahoo.com 30 Jul '07

30 Jul '07

Full_Name: Azam Jalali Version: 2.2.29 OS: windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.207.237.38) I installed openldap 2.2.9 and set sldap.conf as following: /////////////////////////////////////////////////////////////////////////// ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/inetorgperson.schema include ./schema/nis.schema include ./schema/dyngroup.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # 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 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory ./data # Indices to maintain index objectClass eq access to attr=userpassword by anonymous auth by self write by dn="cn=Manager,dc=my-domain,dc=com" write by * none access to * by dn="cn=Manager,dc=my-domain,dc=com" write by users write by self write by * read by * write /////////////////////////////////////////////////////////////////////////// After running some query on this openldap i got ldap error:server down. This event occurs every time i reinstalled it and ran some query on it? How i fix this error? Thanks in advance Azam Jalali

1 0

Slapd doesn't start after update
by ツ Leandro Sales 27 Jul '07

27 Jul '07

Hello folks... I update the openldap from version 2.2.28-r7 to 2.3.35-r1 using emerge. After update the slapd deamon didn't start. I enabled the log and realized that the problem was the incompatible version of the database. I then downgrade to the 2.2.28 version and when I started slapd I got the message: "/usr/lib64/openldap/slapd: error while loading shared libraries: liblber-2.3.so.0: cannot open shared object file: No such file or directory". I then reinstall and this problem doesn't happen anymore, but slapd still doesn't start and print the following messages in the log file: Jul 27 17:55:11 embedded slapd[2957]: bdb_db_init: Initializing BDB database Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): Program version 4.5 doesn't match environment version 0.22 Jul 27 17:55:11 embedded slapd[2958]: bdb_db_open: dbenv_open failed: DB_VERSION_MISMATCH: Database environment version mismatch (-30972) Jul 27 17:55:11 embedded slapd[2958]: backend_startup: bi_db_open failed! (-30972) Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem Jul 27 17:55:11 embedded slapd[2958]: bdb(o=Embedded,c=BR): txn_checkpoint interface requires an environment configured for the transaction subsystem Jul 27 17:55:11 embedded slapd[2958]: bdb_db_destroy: txn_checkpoint failed: Invalid argument (22) Please, help me on this. []s Leandro.

2 1

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

ando(a)sys-net.it wrote: > What would make things totally different is the persistence of a problem > in 2.3 and 2.4. But the very existence of a problem has to be proven > yet. If you look at my analysis with dntest, you'll see that your DN I confirm that using the schema extracted from <ldap://cclcgtopbdii01.in2p3.fr:2170/>, 2.3/2.4 slapdn can successfully handle the offending DN: $ slapdn \ 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid' DN: <GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid> check succeeded normalized: <GlueVOViewLocalID=/vo\3Dswetest/group\3D/swetest/role\3Dswadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,Mds-Vo-name=uporto,Mds-Vo-name=local,o=grid> pretty: <GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,Mds-Vo-name=UPorto,Mds-Vo-name=local,o=grid> I'd consider this ITS closed. 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

(ITS#5065) out of order ctxcsn from old entryCSN
by donn＠u.washington.edu 27 Jul '07

27 Jul '07

Full_Name: Donn Cave Version: 2.4.4 OS: RH Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) Old entryCSN values imported into the data from another server, can crash replicas. In loop at top of syncrepl_updateCookie, replica encounters a syncCookie whose value is less than its matching si_cookieState->cs_val. This breaks out of the inner loop, and the outer loop, without copying anything into `first', so slap_queue_csn crashes on the null csn. Both are element 0 of their respective arrays. I assume it is no surprise that syncCookie takes its value from an entryCSN attribute. To duplicate, add an entry with an explicit entryCSN, with value less than the current contextCSN. In my case, the entryCSN is of the format without the `decimal fraction' field, but I doubt that matters. I don't want to say OpenLDAP needs to support this, but maybe it would be better to catch the problem in the master, than crash the replicas.

1 0

Re: (ITS#5058) LDAP/Egroupware addressbook issue
by ando＠sys-net.it 27 Jul '07

27 Jul '07

chandra(a)sentienthealth.com wrote: > Jul 23 13:39:35 shs slapd[20739]: SRCH "o=sen,dc=domainname,dc=com" 2 0 > Jul 23 13:39:35 shs slapd[20739]: 300 0 0 > Jul 23 13:39:35 shs slapd[20739]: begin get_filter > Jul 23 13:39:35 shs slapd[20739]: OR > Jul 23 13:39:35 shs slapd[20739]: begin get_filter_list > Jul 23 13:39:35 shs slapd[20739]: begin get_filter > Jul 23 13:39:35 shs slapd[20739]: EQUALITY > > Its stop here and hang and we have to restart ldap to make it work. Seems to be related to filter parsing, but we don't get any logging about the filter, and there's too little information to detect what's the issue. You might add "packets" to the log level to see what actually gets sent along with the request (beware that log level will be very verbose, then), and post the output concerning the sole initiation of the search request up to the hang. 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#5062) back-sql with non-integer keycol's
by ando＠sys-net.it 27 Jul '07

27 Jul '07

lehner(a)webdynamite.com wrote: > Full_Name: GeorgLehner > Version: 2.3.30 > OS: Debian Gnu/Linux i386 > URL: > Submission from: (NULL) (83.64.52.210) > > > The slapd-sql(5) man page states: > > '- the key must be an integer. ... > If anyone needs support for different types for keys > - he may want to write a patch,' > > I am configuring back-sql as a frontend to the SugarCRM Customer Database. > SugarCRM uses UUID's as keys: > > http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#functio… > > so I want (to write) a patch. Can you please give me some hint where > to start? Actually, I think this has been already implemented (although possibly experimental). You need to rebuild back-sql after manually defining BACKSQL_ARBITRARY_KEY in <servers/slapd/back-sql/back-sql.h>. In that case, however, all keys need to be strings. Please test and report. 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#5062) back-sql with non-integer keycol's
by ando＠sys-net.it 27 Jul '07

27 Jul '07

lehner(a)webdynamite.com wrote: > Full_Name: GeorgLehner > Version: 2.3.30 > OS: Debian Gnu/Linux i386 > URL: > Submission from: (NULL) (83.64.52.210) > > > The slapd-sql(5) man page states: > > '- the key must be an integer. ... > If anyone needs support for different types for keys > - he may want to write a patch,' > > I am configuring back-sql as a frontend to the SugarCRM Customer Database. > SugarCRM uses UUID's as keys: > > http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#functio… > > so I want (to write) a patch. Can you please give me some hint where > to start? Actually, I think this has been already implemented (although possibly experimental). You need to rebuild back-sql after manually defining BACKSQL_ARBITRARY_KEY in <servers/slapd/back-sql/back-sql.h>. In that case, however, all keys need to be strings. Please test and report. 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#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

Pierre-Emmanuel Brinette wrote: > > > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is > > about to exit beta stage. Unless the problem is related to a real > > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this > > ITS will be closed. > > Currently, I've no mean to use an openldap 2.3 unless exists an RPM > update package for RHEL 4 (or CentOS). > > But the problem is that the request like > "attribute=a_string=another_string,..." worked fine with openldap 2.0 > but not with openldap 2.2. I'm not sure I made the point: both 2.0 and 2.2 are ancient. The fact that something worked with 2.0 doesn't prove anything, as that software was very poor in validating things, and very forgiving with respect to syntax and specs compliance errors (which I value as a defect, while others might see it as a "feature"). The fact that something does no longer work with 2.2 while it worked with 2.0 is a pity, but it doesn't mean anything as well. Either (a) 2.0 was wrong, and 2.2 correctly detects an error, or (b) 2.0 was right, and 2.2 introduced a bug, or (c) both were plainly wrong. In any case 2.2 is historical and no longer supported, so in cases (b) and (c) no one on the OpenLDAP side is going to fix 2.2. You could try asking the distributor of the packages you're using (YMMV). What would make things totally different is the persistence of a problem in 2.3 and 2.4. But the very existence of a problem has to be proven yet. If you look at my analysis with dntest, you'll see that your DN 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid' is split in ldap_rdn2str() = "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\ 3Dswadmin" ldap_rdn2str() = "GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge -swetest" ldap_rdn2str() = "mds-vo-name=UPorto" ldap_rdn2str() = "mds-vo-name=local" ldap_rdn2str() = "o=grid" Is this what you'd expect? Note that in GlueVOViewLocalID embedded '=' are expanded as '\3D'. If any of the commas/equals in the DN are actually parts of the IA5 string, you'll need to escape them to have them parsed as expected. 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#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by pbrinette＠cc.in2p3.fr 27 Jul '07

27 Jul '07

> 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is > about to exit beta stage. Unless the problem is related to a real > software bug, and it persists either in HEAD/2.4 or in 2.3 code, this > ITS will be closed. Currently, I've no mean to use an openldap 2.3 unless exists an RPM update package for RHEL 4 (or CentOS). But the problem is that the request like "attribute=a_string=another_string,..." worked fine with openldap 2.0 but not with openldap 2.2. [..CUT..] > > 2) were GlueCEUniqueID and mds-vo-name declared anywhere? There seems > to be nothing wrong with your DN per se; in fact, dntest yields [..CUT..] > > But apparently some attribute declarations are missing; in fact, slapdn > (after declaring GlueVOViewLocalID as indicated above) yields > > slapdn -f testrun/slapd.1.conf > 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid' > > DN: > <GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid> > check failed 21 (Invalid syntax) > > where the failure refers exactly to the fact that GlueCEUniqueID was not > declared. > If you want some informations regarding the schema used, you will find here : http://glueschema.forge.cnaf.infn.it/Spec/V13 And you ca download the schema here : https://forge.cnaf.infn.it/plugins/scmsvn/viewcvs.php/v_1_3/mapping/ldap/sc… if you want to import some datas with slapadd, you could find here a reference ldiff file : ldap://cclcgtopbdii01.in2p3.fr:2170/ root : o=grid Regards. Pierre-Emmanuel -- Pierre-Emmanuel Brinette Grid computing - EGEE/LCG team IN2P3/CNRS Computing Centre - Lyon (France) 27 bd du 11 novembre, F-69622 Villeurbanne cedex pbrinette(a)cc.in2p3.fr - Tél. : +33 (0) 4 78 93 08 80

1 0

Re: (ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by ando＠sys-net.it 27 Jul '07

27 Jul '07

pbrinette(a)cc.in2p3.fr wrote: > Openldap is used as information provider in a GRID middleware project > (http://www.eu-egee.org/). This information provider is known as BDII. > > The information about grid nodes are published via openldap. > > Until now, the platform supported by the middleware is Scientific Linux 3 (a > RHEL 3 clone like CentOS). The openldap version provided with this system is > openldap 2.0.27. > > We updated our systems with Scientific Linux 4.4 (RHEL 4.4) for new hardware > support. The openldap version provided is now 2.2.13. > > When I put the new service in production, I find some issues with some > attributes that disappears from the directory. > > In our openldap schema, we have an attribute declared like this: > > attributetype ( 1.3.6.1.4.1.8005.100.2.2.7.1 > NAME 'GlueVOViewLocalID' > DESC 'Local ID for this VO view' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 > SINGLE-VALUE) > > > This attribute may containt string like these: > > GlueVOViewLocalID=dteam > GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin, > > It seem that theses both sample strings are IA5 compliant. > > When I ask the openldap server with this request, Ive got different results > regarding the openldap version : > > ------------ Openldap 2.0.27 ----------------------- > > ldapsearch -x -P3 -H ldap://cclcgtopbdii01.in2p3.fr:2170 -b > "GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid" > version: 2 > > # > # filter: (objectclass=*) > # requesting: ALL > # > > # /VO=swetest/GROUP=/swetest/ROLE=swadmin, grid001.fc.up.pt:2119/jobmanager-l > cgsge-swetest, UPorto, local, grid > dn: GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=g > rid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name > =local,o=grid > objectClass: GlueCETop > objectClass: GlueVOView > objectClass: GlueCEInfo > objectClass: GlueCEState > objectClass: GlueCEAccessControlBase > objectClass: GlueCEPolicy > objectClass: GlueKey > objectClass: GlueSchemaVersion > GlueVOViewLocalID: /VO=swetest/GROUP=/swetest/ROLE=swadmin > GlueCEAccessControlBaseRule: VOMS:/VO=swetest/GROUP=/swetest/ROLE=swadmin > GlueCEAccessControlBaseRule: DENY:dteam > GlueCEAccessControlBaseRule: DENY:ops > GlueCEAccessControlBaseRule: DENY:swetest > GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=lcgadmin > GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=production > GlueCEAccessControlBaseRule: DENY:/VO=ops/GROUP=/ops/ROLE=lcgadmin > GlueCEStateRunningJobs: 0 > GlueCEStateWaitingJobs: 0 > GlueCEStateTotalJobs: 0 > GlueCEStateFreeJobSlots: 22 > GlueCEStateEstimatedResponseTime: 0 > GlueCEStateWorstResponseTime: 0 > GlueCEInfoDefaultSE: hades.up.pt > GlueCEInfoApplicationDir: /vosoft/swetestsoft > GlueCEInfoDataDir: unset > GlueChunkKey: GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest > GlueSchemaVersionMajor: 1 > GlueSchemaVersionMinor: 2 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > > --------------------- openldap 2.2.13 ------------------------ > > ldapsearch -P3 -x -H ldap://cclcgtopbdii02.in2p3.fr:2170 -b > "GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid" > version: 2 > > # > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 2 > result: 34 Invalid DN syntax > text: invalid DN > > # numResponses: 1 > > --------------------------------------------------- > > > > Each time a dn contain an attribute of the following form : > "attribute=a_string=another_string,..." (eg: > "/VO=swetest/GROUP=/swetest/ROLE=swadmin") openldap 2.2 produce an error "could > not parse entry" > > In fact, each time the attribute value contain more that one equal ("=") > character, openldap failed to handle the string, even though this character is > included in the IA5 table. > > Best regards. > > 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is about to exit beta stage. Unless the problem is related to a real software bug, and it persists either in HEAD/2.4 or in 2.3 code, this ITS will be closed. 2) were GlueCEUniqueID and mds-vo-name declared anywhere? There seems to be nothing wrong with your DN per se; in fact, dntest yields $ dntest \ 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid' ldap_rdn2str() = "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\ 3Dswadmin" ldap_rdn2str() = "GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge -swetest" ldap_rdn2str() = "mds-vo-name=UPorto" ldap_rdn2str() = "mds-vo-name=local" ldap_rdn2str() = "o=grid" ldap_dn2str(ldap_str2dn("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadm in,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UP orto,mds-vo-name=local,o=grid")) = "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueC EUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds -vo-name=local,o=grid" ldap_dn2domain("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCE UniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds- vo-name=local,o=grid") = "" ldap_dn2ufn("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUni queID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo- name=local,o=grid") = "/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin, grid001.fc.up.pt:2119/ jobmanager-lcgsge-swetest, UPorto, local, grid" ldap_dn2dcedn("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEU niqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-v o-name=local,o=grid") = "/o=grid/mds-vo-name=local/mds-vo-name=UPorto/GlueCEUniqueID=grid001.f c.up.pt:2119\/jobmanager-lcgsge-swetest/GlueVOViewLocalID=\/VO\=swetest\/GROUP\= \/swetest\/ROLE\=swadmin" ldap_dcedn2dn("/o=grid/mds-vo-name=local/mds-vo-name=UPorto/GlueCEUniqueID=grid0 01.fc.up.pt:2119\/jobmanager-lcgsge-swetest/GlueVOViewLocalID=\/VO\=swetest\/GRO UP\=\/swetest\/ROLE\=swadmin") = "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueC EUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds -vo-name=local,o=grid" ldap_dn2ad_canonical("GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin, GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPort o,mds-vo-name=local,o=grid") = "grid/local/UPorto/grid001.fc.up.pt:2119\/jobmanager-lcgsge-swetest/\/ VO\=swetest\/GROUP\=\/swetest\/ROLE\=swadmin/" ldap_explode_dn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin ,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPor to,mds-vo-name=local,o=grid"): "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin" ldap_explode_rdn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\ 3Dswadmin") 'GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin ' ldap_explode_rdn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\ 3Dswadmin") (no types) "/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin" "GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest" ldap_explode_rdn("GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge -swetest") 'GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest' ldap_explode_rdn("GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge -swetest") (no types) "grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest" "mds-vo-name=UPorto" ldap_explode_rdn("mds-vo-name=UPorto") 'mds-vo-name=UPorto' ldap_explode_rdn("mds-vo-name=UPorto") (no types) "UPorto" "mds-vo-name=local" ldap_explode_rdn("mds-vo-name=local") 'mds-vo-name=local' ldap_explode_rdn("mds-vo-name=local") (no types) "local" "o=grid" ldap_explode_rdn("o=grid") 'o=grid' ldap_explode_rdn("o=grid") (no types) "grid" ldap_explode_dn("GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin ,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPor to,mds-vo-name=local,o=grid") (no types): "/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin" "grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest" "UPorto" "local" "grid" "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,GlueCEUniqueID= grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=l ocal,o=grid" == "GlueVOViewLocalID=/VO\3Dswetest/GROUP\3D/swetest/ROLE\3Dswadmin,Glu eCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,m ds-vo-name=local,o=grid" ? yes But apparently some attribute declarations are missing; in fact, slapdn (after declaring GlueVOViewLocalID as indicated above) yields slapdn -f testrun/slapd.1.conf 'GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid' DN: <GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid> check failed 21 (Invalid syntax) where the failure refers exactly to the fact that GlueCEUniqueID was not declared. p. PS: don't look for those tools in ancient software; they've been introduced only in recent times (dntest: October 2001; slapdn: March 2004). 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

(ITS#5064) Issues with openldap 2.2 (Error 34 Invalid DN syntax )
by pbrinette＠cc.in2p3.fr 27 Jul '07

27 Jul '07

Full_Name: Pierre-Emmanuel Brinette Version: 2.2.13 (openldap-2.2.13-6.4E) OS: Scientific Linux 4.4 (RHEL 4.4 clone) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (134.158.71.215) Hello, Openldap is used as information provider in a GRID middleware project (http://www.eu-egee.org/). This information provider is known as BDII. The information about grid nodes are published via openldap. Until now, the platform supported by the middleware is Scientific Linux 3 (a RHEL 3 clone like CentOS). The openldap version provided with this system is openldap 2.0.27. We updated our systems with Scientific Linux 4.4 (RHEL 4.4) for new hardware support. The openldap version provided is now 2.2.13. When I put the new service in production, I find some issues with some attributes that disappears from the directory. In our openldap schema, we have an attribute declared like this: attributetype ( 1.3.6.1.4.1.8005.100.2.2.7.1 NAME 'GlueVOViewLocalID' DESC 'Local ID for this VO view' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) This attribute may containt string like these: GlueVOViewLocalID=dteam GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin, It seem that theses both sample strings are IA5 compliant. When I ask the openldap server with this request, Ive got different results regarding the openldap version : ------------ Openldap 2.0.27 ----------------------- ldapsearch -x -P3 -H ldap://cclcgtopbdii01.in2p3.fr:2170 -b "GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid" version: 2 # # filter: (objectclass=*) # requesting: ALL # # /VO=swetest/GROUP=/swetest/ROLE=swadmin, grid001.fc.up.pt:2119/jobmanager-l cgsge-swetest, UPorto, local, grid dn: GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=g rid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name =local,o=grid objectClass: GlueCETop objectClass: GlueVOView objectClass: GlueCEInfo objectClass: GlueCEState objectClass: GlueCEAccessControlBase objectClass: GlueCEPolicy objectClass: GlueKey objectClass: GlueSchemaVersion GlueVOViewLocalID: /VO=swetest/GROUP=/swetest/ROLE=swadmin GlueCEAccessControlBaseRule: VOMS:/VO=swetest/GROUP=/swetest/ROLE=swadmin GlueCEAccessControlBaseRule: DENY:dteam GlueCEAccessControlBaseRule: DENY:ops GlueCEAccessControlBaseRule: DENY:swetest GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=lcgadmin GlueCEAccessControlBaseRule: DENY:/VO=dteam/GROUP=/dteam/ROLE=production GlueCEAccessControlBaseRule: DENY:/VO=ops/GROUP=/ops/ROLE=lcgadmin GlueCEStateRunningJobs: 0 GlueCEStateWaitingJobs: 0 GlueCEStateTotalJobs: 0 GlueCEStateFreeJobSlots: 22 GlueCEStateEstimatedResponseTime: 0 GlueCEStateWorstResponseTime: 0 GlueCEInfoDefaultSE: hades.up.pt GlueCEInfoApplicationDir: /vosoft/swetestsoft GlueCEInfoDataDir: unset GlueChunkKey: GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest GlueSchemaVersionMajor: 1 GlueSchemaVersionMinor: 2 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 --------------------- openldap 2.2.13 ------------------------ ldapsearch -P3 -x -H ldap://cclcgtopbdii02.in2p3.fr:2170 -b "GlueVOViewLocalID=/VO=swetest/GROUP=/swetest/ROLE=swadmin,GlueCEUniqueID=grid001.fc.up.pt:2119/jobmanager-lcgsge-swetest,mds-vo-name=UPorto,mds-vo-name=local,o=grid" version: 2 # # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 34 Invalid DN syntax text: invalid DN # numResponses: 1 --------------------------------------------------- Each time a dn contain an attribute of the following form : "attribute=a_string=another_string,..." (eg: "/VO=swetest/GROUP=/swetest/ROLE=swadmin") openldap 2.2 produce an error "could not parse entry" In fact, each time the attribute value contain more that one equal ("=") character, openldap failed to handle the string, even though this character is included in the IA5 table. Best regards. -- Pierre-Emmanuel Brinette Grid computing - EGEE/LCG team IN2P3/CNRS Computing Centre - Lyon (France) 27 bd du 11 novembre, F-69622 Villeurbanne cedex pbrinette(a)cc.in2p3.fr - Tél. : +33 (0) 4 78 93 08 80

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 27 Jul '07

27 Jul '07

Hi David, http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/addpartial/ Will be pushed out in the next 2.4 beta. Please bear in mind that you will be looking after this overlay, so test as often as you can and re-submit and changes during our release cycle. Thank you for your contribution. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 27 Jul '07

27 Jul '07

David Hawes wrote: > On Thursday 26 July 2007 09:15, you wrote: >> dhawes(a)vt.edu wrote: >>> On Thursday 19 July 2007 17:18, ghenry(a)suretecsystems.com wrote: >>>> <quote who="dhawes(a)vt.edu"> >>>> >>>>> On Thursday 19 July 2007 05:35, Gavin Henry wrote: >>>>>>> An updated version of addpartial is available at: >>>>>>> >>>>>>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz >>>>>>> >>>>>>> This version includes changes to work with OpenLDAP 2.3 as well as >>>>>>> ensuring syncrepl works properly. >>>>>>> >>>>>>> david hawes >>>>>> If this hasn't been added to 2.4/HEAD yet, would you consider updating >>>>>> it >>>>>> for inclusion in 2.4 contrib? >>>>> Absolutely, I've been meaning to test with 2.4. I'll bump it to the >>>>> top of >>>>> the list. >>>> Can you make sure that is dynamically configurable via cn=config like >>>> everything else in 2.4. >>>> >>>> Thanks. >>> I have tested the overlay at >>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz, and it >>> works with 2.4.4alpha, including dynamic loading via cn=config. >>> >>> Apart from using "overlay addpartial", there is no slapd configuration >>> for addpartial. I believe this means it doesn't need its own schema to >>> work correctly. Please correct me if I am wrong about this. >>> >>> Thanks, >>> >>> dave >> Anyone mind if I commit this to contrib in HEAD? > > I don't think you were asking me about this, but I certainly have no problem > with it. If I need to state the disclaimer I'll gladly do so. The OpenLDAP > public license is included, so that may be all that is needed. > > dave Committed. Closing ITS. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 27 Jul '07

27 Jul '07

David Hawes wrote: > On Thursday 26 July 2007 09:15, you wrote: >> dhawes(a)vt.edu wrote: >>> On Thursday 19 July 2007 17:18, ghenry(a)suretecsystems.com wrote: >>>> <quote who="dhawes(a)vt.edu"> >>>> >>>>> On Thursday 19 July 2007 05:35, Gavin Henry wrote: >>>>>>> An updated version of addpartial is available at: >>>>>>> >>>>>>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz >>>>>>> >>>>>>> This version includes changes to work with OpenLDAP 2.3 as well as >>>>>>> ensuring syncrepl works properly. >>>>>>> >>>>>>> david hawes >>>>>> If this hasn't been added to 2.4/HEAD yet, would you consider updating >>>>>> it >>>>>> for inclusion in 2.4 contrib? >>>>> Absolutely, I've been meaning to test with 2.4. I'll bump it to the >>>>> top of >>>>> the list. >>>> Can you make sure that is dynamically configurable via cn=config like >>>> everything else in 2.4. >>>> >>>> Thanks. >>> I have tested the overlay at >>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz, and it >>> works with 2.4.4alpha, including dynamic loading via cn=config. >>> >>> Apart from using "overlay addpartial", there is no slapd configuration >>> for addpartial. I believe this means it doesn't need its own schema to >>> work correctly. Please correct me if I am wrong about this. >>> >>> Thanks, >>> >>> dave >> Anyone mind if I commit this to contrib in HEAD? > > I don't think you were asking me about this, but I certainly have no problem > with it. If I need to state the disclaimer I'll gladly do so. The OpenLDAP > public license is included, so that may be all that is needed. > > dave Yes, that is all that is needed. Adding shortly. Gavin. -- 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#4920) bad connection sequencing
by hyc＠symas.com 27 Jul '07

27 Jul '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Statslog() from even successful tests can show strange sequencing. > > grep '^conn=' testrun/slapd.*.log from a test032-chain run shows > - Operations logged on connections before ACCEPT > (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) > - Operations on a connection with no ACCEPT (slapd.1.log conn=10), > but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', > and valgrind shows memory errors between the close and the ACCEPT. > The enclosed URL gives the testrun directory and test output. The ACCEPT statslog call occurs after connection_init(). Once connection_init unlocks the connection mutex, any other thread can run, and it looks like in your case the actual operation threads got started first. We can simply move the statslog call a bit earlier. Go ahead and move it if you think this is really a problem, to me it's just cosmetic. I don't see how this can be responsible for memory access errors. That must be something unrelated. What valgrind output do you have for that? Most likely that's your ITS#5050. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5063) its 5059 has vanished!!
by ghenry＠suretecsystems.com 26 Jul '07

26 Jul '07

<quote who="kurt(a)OpenLDAP.org"> > > A feature, not a bug. ITS#5059 was submitted as a "Major Security" > issue. > Ah, very nice feature. Gavin.

1 0

Re: (ITS#5063) its 5059 has vanished!!
by m.d.t.evans＠qmul.ac.uk 26 Jul '07

26 Jul '07

On Thu, 2007-07-26 at 09:06 -0500, Kurt Zeilenga wrote: > On Jul 26, 2007, at 11:40 AM, m.d.t.evans(a)qmul.ac.uk wrote: > > > Full_Name: Martin Evans > > Version: n/a > > OS: fc6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (138.37.8.140) > > > > > > Issue 5059 has vanished from the its: > > > > http://www.OpenLDAP.org/its/index.cgi?findid=5059 > > > > The web page shows: > > > > The system encountered a fatal error > > > > can't get info in find_id > > > > The last error code was: No such file or directory > > > > > > A feature, not a bug. ITS#5059 was submitted as a "Major Security" > issue. Not intentionally + I could see it after i submitted it. It must have changed at some point by a mouse slip. Martin. > > -- Kurt -- -- Dr MDT Evans, Computing Services, Queen Mary, University of London

1 0

Re: (ITS#5063) its 5059 has vanished!!
by kurt＠OpenLDAP.org 26 Jul '07

26 Jul '07

On Jul 26, 2007, at 11:40 AM, m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: n/a > OS: fc6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.8.140) > > > Issue 5059 has vanished from the its: > > http://www.OpenLDAP.org/its/index.cgi?findid=5059 > > The web page shows: > > The system encountered a fatal error > > can't get info in find_id > > The last error code was: No such file or directory > > A feature, not a bug. ITS#5059 was submitted as a "Major Security" issue. -- Kurt

1 0

Re: (ITS#5063) its 5059 has vanished!!
by m.d.t.evans＠qmul.ac.uk 26 Jul '07

26 Jul '07

On Thu, 2007-07-26 at 14:45 +0100, Gavin Henry wrote: > m.d.t.evans(a)qmul.ac.uk wrote: > > Full_Name: Martin Evans > > Version: n/a > > OS: fc6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (138.37.8.140) > > > > > > Issue 5059 has vanished from the its: > > > > http://www.OpenLDAP.org/its/index.cgi?findid=5059 > > > > The web page shows: > > > > The system encountered a fatal error > > > > can't get info in find_id > > > > The last error code was: No such file or directory > > > > > > Strange, I can see it when logged in. > > It should be public even though it's not been moved into the right queue? > I think it should be public. I've submitted several reports in the past and none of them have disappeared like that. If you search for it by number it appears in the "Incoming" topic: To view messages select a directory from the list below: Build 0 Contrib 0 Development 0 Documentation 0 Historical 0 Incoming 1 Software Bugs 0 Software Enhancements 0 Web 0 But that is all. M. -- -- Dr MDT Evans, Computing Services, Queen Mary, University of London

1 0

Re: (ITS#5063) its 5059 has vanished!!
by ghenry＠OpenLDAP.org 26 Jul '07

26 Jul '07

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: n/a > OS: fc6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.8.140) > > > Issue 5059 has vanished from the its: > > http://www.OpenLDAP.org/its/index.cgi?findid=5059 > > The web page shows: > > The system encountered a fatal error > > can't get info in find_id > > The last error code was: No such file or directory > > Strange, I can see it when logged in. It should be public even though it's not been moved into the right queue? -- 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#4890) Enhancement: Default Values overlay (patch)
by ghenry＠OpenLDAP.org 26 Jul '07

26 Jul '07

docelic(a)mail.inet.hr wrote: > Full_Name: Davor Ocelic > Version: CVS-HEAD > OS: Linux > URL: http://www.hcoop.net/~docelic/openldap-slapd.overlays.defvals.patch > Submission from: (NULL) (213.147.110.16) > > > > Hello, > > Attached is a patch which adds a "Default Attribute Values" functionality > to OpenLDAP. It is implemented as an overlay named "defvals", and the patch > is done against cvs-head of today. > > Complete documentation is included in the slapo-defvals(5) manual page. > The overlay code itself is commented as well, as a help for others writing > overlays. > > Feel free to trim comments or improve code as you see fit. > > Davor Ocelic > > Hi Davor, Do you want to test this with the latest 2.4 and make it into a slapd module format like in: http://www.openldap.org/its/index.cgi/Contrib?id=3593;selectid=3593;statety… -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 26 Jul '07

26 Jul '07

dhawes(a)vt.edu wrote: > On Thursday 19 July 2007 17:18, ghenry(a)suretecsystems.com wrote: >> <quote who="dhawes(a)vt.edu"> >> >>> On Thursday 19 July 2007 05:35, Gavin Henry wrote: >>>>> An updated version of addpartial is available at: >>>>> >>>>> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz >>>>> >>>>> This version includes changes to work with OpenLDAP 2.3 as well as >>>>> ensuring syncrepl works properly. >>>>> >>>>> david hawes >>>> If this hasn't been added to 2.4/HEAD yet, would you consider updating >>>> it >>>> for inclusion in 2.4 contrib? >>> Absolutely, I've been meaning to test with 2.4. I'll bump it to the top >>> of >>> the list. >> Can you make sure that is dynamically configurable via cn=config like >> everything else in 2.4. >> >> Thanks. > > I have tested the overlay at > ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz, and it > works with 2.4.4alpha, including dynamic loading via cn=config. > > Apart from using "overlay addpartial", there is no slapd configuration for > addpartial. I believe this means it doesn't need its own schema to work > correctly. Please correct me if I am wrong about this. > > Thanks, > > dave > > Anyone mind if I commit this to contrib in HEAD? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5063) its 5059 has vanished!!
by m.d.t.evans＠qmul.ac.uk 26 Jul '07

26 Jul '07

Full_Name: Martin Evans Version: n/a OS: fc6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (138.37.8.140) Issue 5059 has vanished from the its: http://www.OpenLDAP.org/its/index.cgi?findid=5059 The web page shows: The system encountered a fatal error can't get info in find_id The last error code was: No such file or directory

1 0

(ITS#5062) back-sql with non-integer keycol's
by lehner＠webdynamite.com 24 Jul '07

24 Jul '07

Full_Name: GeorgLehner Version: 2.3.30 OS: Debian Gnu/Linux i386 URL: Submission from: (NULL) (83.64.52.210) The slapd-sql(5) man page states: '- the key must be an integer. ... If anyone needs support for different types for keys - he may want to write a patch,' I am configuring back-sql as a frontend to the SugarCRM Customer Database. SugarCRM uses UUID's as keys: http://dev.mysql.com/doc/refman/5.0/en/miscellaneous-functions.html#functio… so I want (to write) a patch. Can you please give me some hint where to start? Thank you in advance, Jorge-León

1 0

Re: (ITS#5035) Warning patrol
by hyc＠symas.com 23 Jul '07

23 Jul '07

h.b.furuseth(a)usit.uio.no wrote: >>> #2. The return value from op->o_callback->sc_cleanup() is never >>> used. Should it be? I noticed because the pcache_op_cleanup() >>> function does not return anything. What should it return? >> two possibilities: >> a) ignore it: cleanup could occur too late, when response has already >> been returned to client; in this case a return code is there only >> because of the standard API >> b) handle it: cleanup return code could be usefully returned to caller >> >> if (a), then the return code can be safely ignored > > If (a), I suggest the prototype should be changed to return void. > I'll leave that to whoever knows overlays well though. > > For now, Ralf updated pcache_op_cleanup() to return SLAP_CB_CONTINUE, > and I've copied that to RE23. > Yes, the _cleanup return code is ignored; all cleanup handlers are called regardless of what any previous handler returned. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5035) Warning patrol
by h.b.furuseth＠usit.uio.no 23 Jul '07

23 Jul '07

I listed two "#7"s, let's call the second #8. Items #3-5 and 7 done. (#5 and #7 in 2.3.37, forgot to update CHANGES.) Pierangelo Masarati writes: >h.b.furuseth(a)usit.uio.no wrote: >> #1. slapd/frontend.c:frontend_init() has the statement (...) > > Probably a leftover of a time when slap_known_controls was a pointer Likely a non-bug then. Leaving it there as a reminder until someone (me?) gets around to checking that the current code is OK. >> #2. The return value from op->o_callback->sc_cleanup() is never >> used. Should it be? I noticed because the pcache_op_cleanup() >> function does not return anything. What should it return? > > two possibilities: > a) ignore it: cleanup could occur too late, when response has already > been returned to client; in this case a return code is there only > because of the standard API > b) handle it: cleanup return code could be usefully returned to caller > > if (a), then the return code can be safely ignored If (a), I suggest the prototype should be changed to return void. I'll leave that to whoever knows overlays well though. For now, Ralf updated pcache_op_cleanup() to return SLAP_CB_CONTINUE, and I've copied that to RE23. -- Regards, Hallvard

1 0

(ITS#5061) client/tools: Password Policy control handling
by kurt＠OpenLDAP.org 23 Jul '07

23 Jul '07

Full_Name: Kurt Zeilenga Version: 2.3 OS: Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.129.101.249) Submitted by: kurt 2.3 (and 2.4) client tools only send the password policy control with the Bind requests. However, the control is not only valid with most every request, but useful to send with every request. HEAD has been updated to send, when -e ppolicy is selected, the control with every request, and to print the control details on return. While this could be viewed as a new feature by some it could abe viewed as a bug fix by others. Given this change scope is quite narrow (should only effect -e ppolicy users), I recommend it inclusion in the next patch release of 2.3.

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by hyc＠symas.com 23 Jul '07

23 Jul '07

Sorry for the late reply, I never saw this followup until now. The idea of using multiple contexts is good. I'm thinking though that we can do this simply by copying LDAP* session handles around, rather than introducing a new LDAPContext structure. That will minimize the impact on application writers, and allow us to continue using the current ldap_set_option() unchanged. timo(a)physik.uni-potsdam.de wrote: > Hi, > > OpenLDAP issue ITS#4750 is still unresolved (it affects current > versions of nss_ldap and pam_ldap), and I consider it to be pretty > serious: > - Even security-conscious applications like pam_ldap still parse > files from unsafe locations, including the current directory. > - Attempting to read from a file in the current directory can > cause problems on its own, e.g. when the directory is an autofs > mountpoint (In fact, I became aware of this issue by investigating > deadlocks occurring in such a situation) > - If an application uses LDAP in more than one context, like a > program using LDAP while also linking to nss_ldap and pam_ldap, > the settings can interfere (unless very much care is taken, see > below). This is bad, as the very purpose of nss and pam is to > make the underlying mechanisms completely transparent to the > application. > - The existing LDAPNOINIT mechanism is only effective for the first > call which initializes the global option structure. Thus, almost > no one can reliably use it: the options may already have been > initialized e.g. by nss_ldap which nearly every program might > link to. > > The suggested workaround so far is to force nss_ldap, pam_ldap, and > possibly others, to override all relevant options with safe values. > To me, this seems to be quite error-prone and not a satisfactory > solution: > - it requires duplication of much of the configuration parsing code, > which needs to be kept in sync with OpenLDAP's syntax and semantics > (or worse, allow the syntax to diverge), and > - it requires users to think of and nail down each and every potentially > relevant option separately (note that current versions of libldap and > pam_ldap silently ignore syntax errors in the config file, so one may > very easily be in a false sense of security). > - It does not stop libldap from opening files it shouldn't open in the > first place. > As Kurt Zeilenga already noted, a proper solution will require some > redesign, so... > > I include 3 patches: one for libldap (against HEAD as of 20070216), and > corresponding patches for nss_ldap-254 and pam_ldap-183. > > The first lines of the openldap patch (the changes to ldap.h) and > the nss_ldap patch should tell you how it is supposed to work: > libraries can obtain a private copy of the "globaloptions", > in an opaque "LDAPContext" object, to be initialized in a safe way > and independently from other copies of that structure. > The existing struct globaloptions is used by default to stay compatible > with existing programs. > > I'm willing to write more documentation too but I would like to get > some some feedback on it first, > > Regards, > > Timo Felbinger > > > --pf9I7BMVVzbSWLtt > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="openldap.patch" > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Timo Felbinger <timo(a)physik.uni-potsdam.de>. > These modifications are not subject to any license of University of Potsdam. > > I, Timo Felbinger, hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. > Hence, these modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > diff -Nru openldap-src/include/ldap.h openldap-src-context/include/ldap.h > --- openldap-src/include/ldap.h 2007-02-12 10:53:59.000000000 +0000 > +++ openldap-src-context/include/ldap.h 2007-02-17 13:22:45.000000000 +0000 > @@ -696,6 +696,8 @@ > */ > typedef struct ldap LDAP; > > +typedef struct ldapoptions LDAPContext; > + > #define LDAP_DEREF_NEVER 0x00 > #define LDAP_DEREF_SEARCHING 0x01 > #define LDAP_DEREF_FINDING 0x02 > @@ -890,6 +892,12 @@ > int option, > LDAP_CONST void *invalue)); > > +LDAP_F( int ) > +ldap_set_option_in_context LDAP_P(( > + LDAPContext *context, > + int option, > + LDAP_CONST void *invalue)); > + > /* V3 REBIND Function Callback Prototype */ > typedef int (LDAP_REBIND_PROC) LDAP_P(( > LDAP *ld, LDAP_CONST char *url, > @@ -1382,10 +1390,30 @@ > LDAP **ldp )); > > LDAP_F( int ) > +ldap_create_in_context LDAP_P(( > + LDAP **ldp, > + LDAPContext *context )); > + > +LDAP_F( int ) > ldap_initialize LDAP_P(( > LDAP **ldp, > LDAP_CONST char *url )); > > +LDAP_F( int ) > +ldap_initialize_in_context LDAP_P(( > + LDAP **ldp, > + LDAP_CONST char *url, > + LDAPContext *context )); > + > +LDAP_F( int ) > +ldap_create_context LDAP_P(( > + LDAPContext **context, > + char **directives )); > + > +LDAP_F( int ) > +ldap_destroy_context LDAP_P(( > + LDAPContext *context )); > + > /* > * in tls.c > */ > diff -Nru openldap-src/include/ldap_pvt.h openldap-src-context/include/ldap_pvt.h > --- openldap-src/include/ldap_pvt.h 2007-02-12 03:20:24.000000000 +0000 > +++ openldap-src-context/include/ldap_pvt.h 2007-02-17 13:22:45.000000000 +0000 > @@ -278,6 +278,8 @@ > int option, void *arg )); > LDAP_F (int) ldap_pvt_tls_set_option LDAP_P(( struct ldap *ld, > int option, void *arg )); > +LDAP_F (int) ldap_pvt_tls_set_option_2 LDAP_P(( struct ldapoptions *lo, struct ldap *ld, > + int option, void *arg )); > > LDAP_F (void) ldap_pvt_tls_destroy LDAP_P(( void )); > LDAP_F (int) ldap_pvt_tls_init LDAP_P(( void )); > diff -Nru openldap-src/libraries/libldap/init.c openldap-src-context/libraries/libldap/init.c > --- openldap-src/libraries/libldap/init.c 2007-02-05 19:32:44.000000000 +0000 > +++ openldap-src-context/libraries/libldap/init.c 2007-02-17 13:22:45.000000000 +0000 > @@ -124,6 +124,7 @@ > #define MAX_LDAP_ENV_PREFIX_LEN 8 > > static void openldap_ldap_init_w_conf( > + struct ldapoptions *gopts, > const char *file, int userconf ) > { > char linebuf[ AC_LINE_MAX ]; > @@ -131,10 +132,11 @@ > int i; > char *cmd, *opt; > char *start, *end; > - struct ldapoptions *gopts; > > - if ((gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { > - return; /* Could not allocate mem for global options */ > + if( ! gopts ) { > + if ((gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { > + return; /* Could not allocate mem for global options */ > + } > } > > if (file == NULL) { > @@ -244,7 +246,7 @@ > * (char**) p = LDAP_STRDUP(opt); > break; > case ATTR_OPTION: > - ldap_set_option( NULL, attrs[i].offset, opt ); > + ldap_set_option_in_context( gopts, attrs[i].offset, opt ); > break; > case ATTR_SASL: > #ifdef HAVE_CYRUS_SASL > @@ -253,7 +255,7 @@ > break; > case ATTR_TLS: > #ifdef HAVE_TLS > - ldap_int_tls_config( NULL, attrs[i].offset, opt ); > + ldap_int_tls_config_in_context( gopts, attrs[i].offset, opt ); > #endif > break; > case ATTR_OPT_TV: { > @@ -285,7 +287,7 @@ > > static void openldap_ldap_init_w_sysconf(const char *file) > { > - openldap_ldap_init_w_conf( file, 0 ); > + openldap_ldap_init_w_conf( NULL, file, 0 ); > } > > static void openldap_ldap_init_w_userconf(const char *file) > @@ -314,11 +316,11 @@ > > /* try ~/file */ > sprintf(path, "%s" LDAP_DIRSEP "%s", home, file); > - openldap_ldap_init_w_conf(path, 1); > + openldap_ldap_init_w_conf(NULL, path, 1); > > /* try ~/.file */ > sprintf(path, "%s" LDAP_DIRSEP ".%s", home, file); > - openldap_ldap_init_w_conf(path, 1); > + openldap_ldap_init_w_conf(NULL, path, 1); > } > > if(path != NULL) { > @@ -326,7 +328,7 @@ > } > > /* try file */ > - openldap_ldap_init_w_conf(file, 1); > + openldap_ldap_init_w_conf(NULL, file, 1); > } > > static void openldap_ldap_init_w_env( > @@ -466,9 +468,10 @@ > void ldap_int_initialize_global_options( struct ldapoptions *gopts, int *dbglvl ) > { > if (dbglvl) > - gopts->ldo_debug = *dbglvl; > + /* FIXME: currently ldo_debug is an always global option only, so we set both places: */ > + gopts->ldo_debug = LDAP_INT_GLOBAL_OPT()->ldo_debug = *dbglvl; > else > - gopts->ldo_debug = 0; > + gopts->ldo_debug = LDAP_INT_GLOBAL_OPT()->ldo_debug = 0; > > gopts->ldo_version = LDAP_VERSION2; > gopts->ldo_deref = LDAP_DEREF_NEVER; > @@ -531,7 +534,10 @@ > char * ldap_int_hostname = NULL; > #endif > > -void ldap_int_initialize( struct ldapoptions *gopts, int *dbglvl ) > +void ldap_int_initialize( > + struct ldapoptions *gopts, > + int *dbglvl, > + char **directives ) > { > if ( gopts->ldo_valid == LDAP_INITIALIZED ) { > return; > @@ -593,6 +599,19 @@ > > ldap_int_initialize_global_options(gopts, NULL); > > + if( directives ) { > + for( ; *directives; ++directives ) { > + if( ! strncmp( *directives, "file=", 5 ) ) { > + openldap_ldap_init_w_conf( gopts, *directives + 5, 1 ); > + continue; > + } > + /* add more directives here... */ > + gopts->ldo_valid = LDAP_TRASHED_SESSION; > + return; > + } > + return; > + } > + > if( getenv("LDAPNOINIT") != NULL ) { > return; > } > diff -Nru openldap-src/libraries/libldap/ldap-int.h openldap-src-context/libraries/libldap/ldap-int.h > --- openldap-src/libraries/libldap/ldap-int.h 2007-02-15 00:42:23.000000000 +0000 > +++ openldap-src-context/libraries/libldap/ldap-int.h 2007-02-17 13:22:45.000000000 +0000 > @@ -417,7 +417,7 @@ > > LDAP_V ( struct ldapoptions ) ldap_int_global_options; > > -LDAP_F ( void ) ldap_int_initialize LDAP_P((struct ldapoptions *, int *)); > +LDAP_F ( void ) ldap_int_initialize LDAP_P((struct ldapoptions *, int *, char **directives )); > LDAP_F ( void ) ldap_int_initialize_global_options LDAP_P(( > struct ldapoptions *, int *)); > > @@ -652,6 +652,9 @@ > LDAP_F (int) ldap_int_tls_config LDAP_P(( LDAP *ld, > int option, const char *arg )); > > +LDAP_F (int) ldap_int_tls_config_in_context LDAP_P(( struct ldapoptions *lo, > + int option, const char *arg )); > + > LDAP_F (int) ldap_int_tls_start LDAP_P(( LDAP *ld, > LDAPConn *conn, LDAPURLDesc *srv )); > > diff -Nru openldap-src/libraries/libldap/open.c openldap-src-context/libraries/libldap/open.c > --- openldap-src/libraries/libldap/open.c 2007-02-12 03:20:24.000000000 +0000 > +++ openldap-src-context/libraries/libldap/open.c 2007-02-17 13:45:19.000000000 +0000 > @@ -87,27 +87,88 @@ > return ld; > } > > +int > +ldap_free_context_internals( LDAPContext *context ) > +{ > + ldap_free_urllist( context->ldo_defludp ); > +#ifdef HAVE_CYRUS_SASL > + LDAP_FREE( context->ldo_def_sasl_authzid ); > + LDAP_FREE( context->ldo_def_sasl_authcid ); > + LDAP_FREE( context->ldo_def_sasl_realm ); > + LDAP_FREE( context->ldo_def_sasl_mech ); > +#endif > + return LDAP_SUCCESS; > +} > + > +/* public destructor of LDAPContext */ > +int > +ldap_destroy_context( LDAPContext *context ) > +{ > + if( context ) { > + ldap_free_context_internals( context ); > + free( context ); > + } > + return LDAP_SUCCESS; > +} > + > +/* public constructor of LDAPContext */ > +int > +ldap_create_context( > + LDAPContext **context, > + /* directives: NULL-terminated list of initialization directives: > + * - NULL: default initialization procedure (see ldap.conf(5)) > + * - { NULL }: equivalent to LDAPNOINIT > + * - { ..., "file=path", ... }: parse path like user-config file > + */ > + char **directives ) > +{ > + LDAPContext *lo; > + > + *context = NULL; > + lo = ( LDAPContext * ) LDAP_CALLOC( 1, sizeof( LDAPContext ) ); > + if( ! lo ) > + return LDAP_NO_MEMORY; > + > + Debug( LDAP_DEBUG_TRACE, "ldap_create_context %p\n", lo, 0, 0 ); > + > + lo->ldo_valid = LDAP_UNINITIALIZED; > + ldap_int_initialize( lo, NULL, directives ); > + if( lo->ldo_valid != LDAP_INITIALIZED ) > + return LDAP_LOCAL_ERROR; > > + *context = lo; > + > + return LDAP_SUCCESS; > +} > > int > ldap_create( LDAP **ldp ) > { > + return ldap_create_in_context( ldp, NULL ); > +} > + > +int > +ldap_create_in_context( LDAP **ldp, LDAPContext *gopts ) > +{ > LDAP *ld; > - struct ldapoptions *gopts; > > *ldp = NULL; > - /* Get pointer to global option structure */ > - if ( (gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { > - return LDAP_NO_MEMORY; > - } > > - /* Initialize the global options, if not already done. */ > - if( gopts->ldo_valid != LDAP_INITIALIZED ) { > - ldap_int_initialize(gopts, NULL); > - if ( gopts->ldo_valid != LDAP_INITIALIZED ) > - return LDAP_LOCAL_ERROR; > + if( ! gopts ) { > + /* default is the global context */ > + if ( (gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { > + return LDAP_NO_MEMORY; > + } > + > + /* Initialize the global options, if not already done. */ > + if( gopts->ldo_valid != LDAP_INITIALIZED ) { > + ldap_int_initialize(gopts, NULL, NULL); > + } > } > > + if( gopts->ldo_valid != LDAP_INITIALIZED ) > + return LDAP_LOCAL_ERROR; > + > Debug( LDAP_DEBUG_TRACE, "ldap_create\n", 0, 0, 0 ); > > if ( (ld = (LDAP *) LDAP_CALLOC( 1, sizeof(LDAP) )) == NULL ) { > @@ -167,13 +228,7 @@ > > nomem: > ldap_free_select_info( ld->ld_selectinfo ); > - ldap_free_urllist( ld->ld_options.ldo_defludp ); > -#ifdef HAVE_CYRUS_SASL > - LDAP_FREE( ld->ld_options.ldo_def_sasl_authzid ); > - LDAP_FREE( ld->ld_options.ldo_def_sasl_authcid ); > - LDAP_FREE( ld->ld_options.ldo_def_sasl_realm ); > - LDAP_FREE( ld->ld_options.ldo_def_sasl_mech ); > -#endif > + ldap_free_context_internals( &ld->ld_options ); > LDAP_FREE( (char *)ld ); > return LDAP_NO_MEMORY; > } > @@ -215,11 +270,17 @@ > int > ldap_initialize( LDAP **ldp, LDAP_CONST char *url ) > { > + return ldap_initialize_in_context( ldp, url, NULL ); > +} > + > +int > +ldap_initialize_in_context( LDAP **ldp, LDAP_CONST char *url, LDAPContext *context ) > +{ > int rc; > LDAP *ld; > > *ldp = NULL; > - rc = ldap_create(&ld); > + rc = ldap_create_in_context(&ld, context); > if ( rc != LDAP_SUCCESS ) > return rc; > > diff -Nru openldap-src/libraries/libldap/options.c openldap-src-context/libraries/libldap/options.c > --- openldap-src/libraries/libldap/options.c 2007-02-06 22:02:47.000000000 +0000 > +++ openldap-src-context/libraries/libldap/options.c 2007-02-17 13:22:45.000000000 +0000 > @@ -97,16 +97,6 @@ > { > struct ldapoptions *lo; > > - /* Get pointer to global option structure */ > - lo = LDAP_INT_GLOBAL_OPT(); > - if (NULL == lo) { > - return LDAP_NO_MEMORY; > - } > - > - if( lo->ldo_valid != LDAP_INITIALIZED ) { > - ldap_int_initialize(lo, NULL); > - } > - > if(ld != NULL) { > assert( LDAP_VALID( ld ) ); > > @@ -117,6 +107,18 @@ > lo = &ld->ld_options; > } > > + if( lo == NULL ) { > + /* Get pointer to global option structure */ > + lo = LDAP_INT_GLOBAL_OPT(); > + if (NULL == lo) { > + return LDAP_NO_MEMORY; > + } > + > + if( lo->ldo_valid != LDAP_INITIALIZED ) { > + ldap_int_initialize(lo, NULL, NULL); > + } > + } > + > if(outvalue == NULL) { > /* no place to get to */ > return LDAP_OPT_ERROR; > @@ -347,19 +349,35 @@ > } > > int > +ldap_set_option_in_context( > + LDAPContext *context, > + int option, > + LDAP_CONST void *invalue) > +{ > + return ldap_set_option_2( context, NULL, option, invalue ); > +} > + > +int > ldap_set_option( > LDAP *ld, > int option, > LDAP_CONST void *invalue) > { > - struct ldapoptions *lo; > - int *dbglvl = NULL; > + return ldap_set_option_2( NULL, ld, option, invalue ); > +} > > - /* Get pointer to global option structure */ > - lo = LDAP_INT_GLOBAL_OPT(); > - if (lo == NULL) { > - return LDAP_NO_MEMORY; > - } > +/* > + * ldap_set_option_2: can set options per LDAP handle or per context. > + * if handle is given, the context is ignored. > + */ > +int > +ldap_set_option_2( > + struct ldapoptions *lo, > + LDAP *ld, > + int option, > + LDAP_CONST void *invalue) > +{ > + int *dbglvl = NULL; > > /* > * The architecture to turn on debugging has a chicken and egg > @@ -370,10 +388,6 @@ > dbglvl = (int *) invalue; > } > > - if( lo->ldo_valid != LDAP_INITIALIZED ) { > - ldap_int_initialize(lo, dbglvl); > - } > - > if(ld != NULL) { > assert( LDAP_VALID( ld ) ); > > @@ -384,6 +398,17 @@ > lo = &ld->ld_options; > } > > + if( lo == NULL ) { > + /* Get pointer to global option structure */ > + lo = LDAP_INT_GLOBAL_OPT(); > + if (lo == NULL) { > + return LDAP_NO_MEMORY; > + } > + if( lo->ldo_valid != LDAP_INITIALIZED ) { > + ldap_int_initialize(lo, dbglvl, NULL); > + } > + } > + > switch(option) { > case LDAP_OPT_REFERRALS: > if(invalue == LDAP_OPT_OFF) { > @@ -668,7 +693,7 @@ > > default: > #ifdef HAVE_TLS > - if ( ldap_pvt_tls_set_option( ld, option, (void *)invalue ) == 0 ) > + if ( ldap_pvt_tls_set_option_2( lo, ld, option, (void *)invalue ) == 0 ) > return LDAP_OPT_SUCCESS; > #endif > #ifdef HAVE_CYRUS_SASL > diff -Nru openldap-src/libraries/libldap/tls.c openldap-src-context/libraries/libldap/tls.c > --- openldap-src/libraries/libldap/tls.c 2007-01-24 22:38:26.000000000 +0000 > +++ openldap-src-context/libraries/libldap/tls.c 2007-02-17 13:22:45.000000000 +0000 > @@ -1178,8 +1178,20 @@ > } > > int > +ldap_int_tls_config_in_context( struct ldapoptions *lo, int option, const char *arg ) > +{ > + return ldap_int_tls_config_2( lo, NULL, option, arg ); > +} > + > +int > ldap_int_tls_config( LDAP *ld, int option, const char *arg ) > { > + return ldap_int_tls_config_2( NULL, ld, option, arg ); > +} > + > +int > +ldap_int_tls_config_2( struct ldapconfig *lo, LDAP *ld, int option, const char *arg ) > +{ > int i; > > switch( option ) { > @@ -1190,7 +1202,7 @@ > case LDAP_OPT_X_TLS_RANDOM_FILE: > case LDAP_OPT_X_TLS_CIPHER_SUITE: > case LDAP_OPT_X_TLS_DHFILE: > - return ldap_pvt_tls_set_option( ld, option, (void *) arg ); > + return ldap_pvt_tls_set_option_2( lo, ld, option, (void *) arg ); > > case LDAP_OPT_X_TLS_REQUIRE_CERT: > case LDAP_OPT_X_TLS: > @@ -1216,7 +1228,7 @@ > } > > if (i >= 0) { > - return ldap_pvt_tls_set_option( ld, option, &i ); > + return ldap_pvt_tls_set_option_2( lo, ld, option, &i ); > } > return -1; > #ifdef HAVE_OPENSSL_CRL > @@ -1230,7 +1242,7 @@ > i = LDAP_OPT_X_TLS_CRL_ALL ; > } > if (i >= 0) { > - return ldap_pvt_tls_set_option( ld, option, &i ); > + return ldap_pvt_tls_set_option_2( lo, ld, option, &i ); > } > return -1; > #endif > @@ -1334,7 +1346,12 @@ > int > ldap_pvt_tls_set_option( LDAP *ld, int option, void *arg ) > { > - struct ldapoptions *lo; > + return ldap_pvt_tls_set_option_2( NULL, ld, option, arg ); > +} > + > +int > +ldap_pvt_tls_set_option_2( struct ldapoptions *lo, LDAP *ld, int option, void *arg ) > +{ > > if( ld != NULL ) { > assert( LDAP_VALID( ld ) ); > @@ -1345,7 +1362,8 @@ > > lo = &ld->ld_options; > > - } else { > + } > + if( lo == NULL ) { > /* Get pointer to global option structure */ > lo = LDAP_INT_GLOBAL_OPT(); > if ( lo == NULL ) { > > --pf9I7BMVVzbSWLtt > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="nss_ldap.patch" > > This patch file is derived from PADL Software (nss_ldap). > All of the modifications to PADL Software represented in the following > patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. > These modifications are not subject to any license of University of Potsdam. > > I, Timo Felbinger, hereby place the following modifications to PADL Software > (and only these modifications) into the public domain. > Hence, these modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > diff -Nru nss_ldap-254/config.h.in nss_ldap-254-context/config.h.in > --- nss_ldap-254/config.h.in 2006-12-18 08:12:56.000000000 +0000 > +++ nss_ldap-254-context/config.h.in 2007-02-17 14:46:02.000000000 +0000 > @@ -132,6 +132,9 @@ > /* Define to 1 if you have the `ldap_initialize' function. */ > #undef HAVE_LDAP_INITIALIZE > > +/* Define to 1 if you have the `ldap_create_context' function. */ > +#undef HAVE_LDAP_CREATE_CONTEXT > + > /* Define to 1 if you have the `ldap_ld_free' function. */ > #undef HAVE_LDAP_LD_FREE > > diff -Nru nss_ldap-254/configure nss_ldap-254-context/configure > --- nss_ldap-254/configure 2006-12-18 08:12:56.000000000 +0000 > +++ nss_ldap-254-context/configure 2007-02-17 14:46:37.000000000 +0000 > @@ -1,4 +1,6 @@ > #! /bin/sh > +echo please run autoconf first! > +exit 1 > > # Guess values for system-dependent variables and create Makefiles. > # Generated automatically using autoconf version 2.13 > diff -Nru nss_ldap-254/configure.in nss_ldap-254-context/configure.in > --- nss_ldap-254/configure.in 2006-12-18 08:12:56.000000000 +0000 > +++ nss_ldap-254-context/configure.in 2007-02-17 14:46:02.000000000 +0000 > @@ -297,7 +297,7 @@ > AC_CHECK_FUNCS(sasl_auxprop_request) > AC_CHECK_FUNCS(ldap_init ldap_get_lderrno ldap_parse_result ldap_memfree ldap_controls_free) > AC_CHECK_FUNCS(ldap_ld_free ldap_explode_rdn ldap_set_option ldap_get_option) > -AC_CHECK_FUNCS(ldap_sasl_interactive_bind_s ldap_initialize ldap_search_ext) > +AC_CHECK_FUNCS(ldap_sasl_interactive_bind_s ldap_initialize ldap_search_ext ldap_create_context) > AC_CHECK_FUNCS(ldap_create_control ldap_create_page_control ldap_parse_page_control) > if test "$enable_ssl" \!= "no"; then > AC_CHECK_FUNCS(ldapssl_client_init ldap_start_tls_s ldap_pvt_tls_set_option ldap_start_tls) > diff -Nru nss_ldap-254/ldap-nss.c nss_ldap-254-context/ldap-nss.c > --- nss_ldap-254/ldap-nss.c 2006-12-18 08:12:56.000000000 +0000 > +++ nss_ldap-254-context/ldap-nss.c 2007-02-17 14:46:02.000000000 +0000 > @@ -137,7 +137,7 @@ > /* > * Global LDAP session. > */ > -static ldap_session_t __session = { NULL, NULL, 0, LS_UNINITIALIZED }; > +static ldap_session_t __session = { NULL, NULL, NULL, 0, LS_UNINITIALIZED }; > > #if defined(HAVE_PTHREAD_ATFORK) || defined(HAVE_LIBC_LOCK_H) || defined(HAVE_BITS_LIBC_LOCK_H) > static pthread_once_t __once = PTHREAD_ONCE_INIT; > @@ -1003,7 +1003,7 @@ > } > > static NSS_STATUS > -do_init_session (LDAP ** ld, const char *uri, int defport) > +do_init_session ( LDAPContext **ldap_context, LDAP ** ld, const char *uri, int defport) > { > int rc; > int ldaps; > @@ -1011,6 +1011,17 @@ > char *p; > NSS_STATUS stat; > > +#ifdef HAVE_LDAP_CREATE_CONTEXT > + if( ! *ldap_context ) > + { > + /* make sure ldap config is read in a safe way */ > + static const char *directives[2] = { "file=" NSS_LDAP_PATH_CONF, NULL }; > + int rc = ldap_create_context( ldap_context, directives ); > + if (rc != LDAP_SUCCESS) > + return NSS_UNAVAIL; > + } > +#endif > + > ldaps = (strncasecmp (uri, "ldaps://", sizeof ("ldaps://") - 1) == 0); > p = strchr (uri, ':'); > /* we should be looking for the second instance to find the port number */ > @@ -1028,7 +1039,11 @@ > uri = uribuf; > } > > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_initialize_in_context (ld, uri, *ldap_context); > +# else > rc = ldap_initialize (ld, uri); > +# endif > #else > if (strncasecmp (uri, "ldap://", sizeof ("ldap://") - 1) != 0) > { > @@ -1311,7 +1326,7 @@ > assert (__session.ls_current_uri <= NSS_LDAP_CONFIG_URI_MAX); > assert (cfg->ldc_uris[__session.ls_current_uri] != NULL); > > - stat = do_init_session (&__session.ls_conn, > + stat = do_init_session ( &__session.ldap_context, &__session.ls_conn, > cfg->ldc_uris[__session.ls_current_uri], > cfg->ldc_port); > if (stat != NSS_SUCCESS) > diff -Nru nss_ldap-254/ldap-nss.h nss_ldap-254-context/ldap-nss.h > --- nss_ldap-254/ldap-nss.h 2006-12-18 08:12:56.000000000 +0000 > +++ nss_ldap-254-context/ldap-nss.h 2007-02-17 14:46:02.000000000 +0000 > @@ -416,12 +416,19 @@ > > typedef enum ldap_session_state ldap_session_state_t; > > +/* for readability, make sure LDAPContext is at least a dummy type: */ > +#ifndef HAVE_LDAP_CREATE_CONTEXT > +# define LDAPContext void > +#endif > + > /* > * convenient wrapper around pointer into global config list, and a > * connection to an LDAP server. > */ > struct ldap_session > { > + /* the context, if supported */ > + LDAPContext *ldap_context; > /* the connection */ > LDAP *ls_conn; > /* pointer into config table */ > > --pf9I7BMVVzbSWLtt > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; filename="pam_ldap.patch" > > This patch file is derived from PADL Software (pam_ldap). > All of the modifications to PADL Software represented in the following > patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. > These modifications are not subject to any license of University of Potsdam. > > I, Timo Felbinger, hereby place the following modifications to PADL Software > (and only these modifications) into the public domain. > Hence, these modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > diff -Nru pam_ldap-183/config.h.in pam_ldap-183-context/config.h.in > --- pam_ldap-183/config.h.in 2006-10-19 13:22:27.000000000 +0000 > +++ pam_ldap-183-context/config.h.in 2007-02-17 14:55:38.000000000 +0000 > @@ -33,6 +33,9 @@ > /* Define if you have the ldap_initialize function. */ > #undef HAVE_LDAP_INITIALIZE > > +/* Define if you have the ldap_create_context function. */ > +#undef HAVE_LDAP_CREATE_CONTEXT > + > /* Define if you have the ldap_memfree function. */ > #undef HAVE_LDAP_MEMFREE > > diff -Nru pam_ldap-183/configure pam_ldap-183-context/configure > --- pam_ldap-183/configure 2006-10-19 13:22:27.000000000 +0000 > +++ pam_ldap-183-context/configure 2007-02-17 14:55:38.000000000 +0000 > @@ -1,4 +1,6 @@ > #! /bin/sh > +echo Please run autoconf first! > +exit 1 > > # Guess values for system-dependent variables and create Makefiles. > # Generated automatically using autoconf version 2.13 > diff -Nru pam_ldap-183/configure.in pam_ldap-183-context/configure.in > --- pam_ldap-183/configure.in 2006-10-19 13:22:27.000000000 +0000 > +++ pam_ldap-183-context/configure.in 2007-02-17 14:55:38.000000000 +0000 > @@ -131,6 +131,7 @@ > AC_CHECK_FUNCS(ldapssl_init ldap_start_tls_s ldap_pvt_tls_set_option) > fi > AC_CHECK_FUNCS(ldap_initialize) > +AC_CHECK_FUNCS(ldap_create_context) > AC_CHECK_FUNCS(ldap_sasl_bind ldap_sasl_interactive_bind_s) > AC_CHECK_FUNCS(gethostbyname_r) > > diff -Nru pam_ldap-183/pam_ldap.c pam_ldap-183-context/pam_ldap.c > --- pam_ldap-183/pam_ldap.c 2006-10-19 13:22:27.000000000 +0000 > +++ pam_ldap-183-context/pam_ldap.c 2007-02-17 15:08:39.000000000 +0000 > @@ -155,6 +155,11 @@ > #endif > static int pam_debug_level __UNUSED__ = 0; > > +#ifndef HAVE_LDAP_CREATE_CONTEXT > +# typedef LDAPContext void; > +#endif > +static LDAPContext *ldap_context = 0; > + > #ifdef HAVE_LDAPSSL_INIT > static int ssl_initialized = 0; > #endif > @@ -1190,6 +1195,36 @@ > struct timeval tv; > #endif > > +#ifdef HAVE_LDAP_CREATE_CONTEXT > + /* make sure ldap config is read in a safe and transparent way */ > + if( ! ldap_context ) > + { > + char *directives[2]; > + int rc; > + > + if( session->conf->configFile == NULL ) > + { > + directives[0] = NULL; > + } > + else > + { > + directives[0] = malloc (strlen (session->conf->configFile) + 6); > + if( directives[0] == NULL ) > + return PAM_BUF_ERR; > + strcpy( directives[0], "file=" ); > + strcpy( directives[0]+5, session->conf->configFile ); > + } > + directives[1] = NULL; > + rc = ldap_create_context( &ldap_context, directives ); > + _pam_drop( directives[0] ); > + if (rc != LDAP_SUCCESS || ! ldap_context ) > + { > + syslog (LOG_ERR, "pam_ldap: ldap_create_context: %s", ldap_err2string (rc)); > + return PAM_SERVICE_ERR; > + } > + } > +#endif > + > #ifdef HAVE_LDAP_SET_OPTION > if (session->conf->debug) > { > @@ -1253,7 +1288,11 @@ > #ifdef HAVE_LDAP_INITIALIZE > if (session->conf->uri != NULL) > { > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + int rc = ldap_initialize_in_context (&session->ld, session->conf->uri, ldap_context); > +# else > int rc = ldap_initialize (&session->ld, session->conf->uri); > +# endif > if (rc != LDAP_SUCCESS) > { > syslog (LOG_ERR, "pam_ldap: ldap_initialize %s", > @@ -1400,8 +1439,12 @@ > /* rand file */ > if (session->conf->tls_randfile != NULL) > { > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_RANDOM_FILE, > - session->conf->tls_randfile); > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_RANDOM_FILE, session->conf->tls_randfile); > if (rc != LDAP_SUCCESS) > { > syslog (LOG_ERR, > @@ -1415,7 +1458,12 @@ > /* ca cert file */ > if (session->conf->tls_cacertfile != NULL) > { > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CACERTFILE, > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_CACERTFILE, > session->conf->tls_cacertfile); > if (rc != LDAP_SUCCESS) > { > @@ -1429,7 +1477,12 @@ > if (session->conf->tls_cacertdir != NULL) > { > /* ca cert directory */ > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CACERTDIR, > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_CACERTDIR, > session->conf->tls_cacertdir); > if (rc != LDAP_SUCCESS) > { > @@ -1443,7 +1496,12 @@ > if (session->conf->tls_checkpeer > -1) > { > /* require cert? */ > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_REQUIRE_CERT, > &session->conf->tls_checkpeer); > if (rc != LDAP_SUCCESS) > { > @@ -1457,7 +1515,12 @@ > if (session->conf->tls_ciphers != NULL) > { > /* set cipher suite, certificate and private key: */ > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CIPHER_SUITE, > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_CIPHER_SUITE, > session->conf->tls_ciphers); > if (rc != LDAP_SUCCESS) > { > @@ -1470,7 +1533,12 @@ > > if (session->conf->tls_cert != NULL) > { > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CERTFILE, > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_CERTFILE, > session->conf->tls_cert); > if (rc != LDAP_SUCCESS) > { > @@ -1483,7 +1551,12 @@ > > if (session->conf->tls_key != NULL) > { > - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_KEYFILE, > +# ifdef HAVE_LDAP_CREATE_CONTEXT > + rc = ldap_set_option_in_context ( ldap_context, > +# else > + rc = ldap_set_option (NULL, > +# endif > + LDAP_OPT_X_TLS_KEYFILE, > session->conf->tls_key); > if (rc != LDAP_SUCCESS) > { > > --pf9I7BMVVzbSWLtt-- > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by quanah＠zimbra.com 23 Jul '07

23 Jul '07

Hi Sebastian, Can you please follow up to this ITS with an IPR release, as detailed at: <http://www.openldap.org/devel/contributing.html> thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5060) slapi_entry_dup and leak
by m.d.t.evans＠qmul.ac.uk 23 Jul '07

23 Jul '07

Full_Name: Martin Evans Version: 2.3.37 OS: Linux/fc6 URL: ftp://ftp.openldap.org/incoming/addressbook.c Submission from: (NULL) (138.37.8.140) This problem seems similar to the solution suggested for ITS#4038. Id like to add an attribute to an entry in the result set during a SLAPI_PLUGIN_PRE_ENTRY_FN callback. According to 4038 the entry should be dupped. But I cannot free the entry afterwards without problems, and if I dont do that the server leaks memory at a high rate. I've left an example plugin in your ftp incoming directory as addressbook.c. The crucial bit of code is this: slapi_pblock_get(pb,SLAPI_SEARCH_RESULT_ENTRY,&e0); cn = slapi_entry_attr_get_charptr(e0, "cn"); DEBUG("found: %s",cn); /* dup the entry - leaks!! */ e1=slapi_entry_dup(e0); if (e1==NULL) { LOG("addressbook_result_entry failed to duplicate entry"); return PLUGIN_STOP; } slapi_entry_attr_set_charptr(e1,"telephoneNumber","12345"); /* set the dupped entry as the result */ slapi_pblock_set(pb, SLAPI_SEARCH_RESULT_ENTRY, e1); /* uncomment this for empty result set, otherwise leaks */ //slapi_entry_free(e1); /* uncomment this for crash */ //slapi_entry_free(e0); If I free e1, I get null results via an ldap search (only "dn:" is displayed for each entry. If I do that there is no leak. If I free e0 (not sure what handles that after the pblock_set call) the server crashes. Kind regards, Martin.

1 0

(ITS#5058) LDAP/Egroupware addressbook issue
by chandra＠sentienthealth.com 22 Jul '07

22 Jul '07

Full_Name: M.G.Chandra Babu Version: LDAPv3 OS: Linux - SuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (58.185.109.242) We are using latest Egroupware, and when we try to edit the address book entry, it hang, see the ldap log file : Jul 23 13:39:34 shs slapd[20739]: conn=165 op=0 BIND dn="uid=revathy,ou=People,dc=domainname,dc=com" mech=SIMPLE ssf=0 Jul 23 13:39:34 shs slapd[20739]: do_bind: v3 bind: "uid=revathy,ou=People,dc=domainname,dc=com" to "uid=revathy,ou=People,dc=domainname,dc=com" Jul 23 13:39:34 shs slapd[20739]: send_ldap_result: conn=165 op=0 p=3 Jul 23 13:39:34 shs slapd[20739]: send_ldap_result: err=0 matched="" text="" Jul 23 13:39:34 shs slapd[20739]: send_ldap_response: msgid=1 tag=97 err=0 Jul 23 13:39:34 shs slapd[20739]: conn=165 op=0 RESULT tag=97 err=0 text= Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=6 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=7 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=8 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=9 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: activity on 1 descriptors Jul 23 13:39:35 shs slapd[20739]: daemon: new connection on 18 Jul 23 13:39:35 shs slapd[20739]: conn=166 fd=18 ACCEPT from IP=192.168.1.1:20057 (IP=0.0.0.0:389) Jul 23 13:39:35 shs slapd[20739]: daemon: added 18r Jul 23 13:39:35 shs slapd[20739]: daemon: activity on: Jul 23 13:39:35 shs slapd[20739]: Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=6 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=7 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=8 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=9 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: activity on 1 descriptors Jul 23 13:39:35 shs slapd[20739]: daemon: activity on: Jul 23 13:39:35 shs slapd[20739]: 18r Jul 23 13:39:35 shs slapd[20739]: Jul 23 13:39:35 shs slapd[20739]: daemon: read activity on 18 Jul 23 13:39:35 shs slapd[20739]: connection_get(18) Jul 23 13:39:35 shs slapd[20739]: connection_get(18): got connid=166 Jul 23 13:39:35 shs slapd[20739]: connection_read(18): checking for input on id=166 Jul 23 13:39:35 shs slapd[20739]: do_bind Jul 23 13:39:35 shs slapd[20739]: ber_get_next on fd 18 failed errno=11 (Resource temporarily unavailable) Jul 23 13:39:35 shs slapd[20739]: >>> dnPrettyNormal: <uid=revathy,ou=People,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: <<< dnPrettyNormal: <uid=revathy,ou=People,dc=domainname,dc=com>, <uid=revathy,ou=people,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: do_bind: version=3 dn="uid=revathy,ou=People,dc=domainname,dc=com" method=128 Jul 23 13:39:35 shs slapd[20739]: conn=166 op=0 BIND dn="uid=revathy,ou=People,dc=domainname,dc=com" method=128 Jul 23 13:39:35 shs slapd[20739]: ==> bdb_bind: dn: uid=revathy,ou=People,dc=domainname,dc=com Jul 23 13:39:35 shs slapd[20739]: bdb_dn2entry("uid=revathy,ou=people,dc=domainname,dc=com") Jul 23 13:39:35 shs slapd[20739]: => access_allowed: auth access to "uid=revathy,ou=People,dc=domainname,dc=com" "userPassword" requested Jul 23 13:39:35 shs slapd[20739]: => dn: [1] Jul 23 13:39:35 shs slapd[20739]: => dn: [2] cn=subschema Jul 23 13:39:35 shs slapd[20739]: => acl_get: [3] attr userPassword Jul 23 13:39:35 shs slapd[20739]: => acl_mask: access to entry "uid=revathy,ou=People,dc=domainname,dc=com", attr "userPassword" requested Jul 23 13:39:35 shs slapd[20739]: => acl_mask: to all values by "", (=n) Jul 23 13:39:35 shs slapd[20739]: <= check a_dn_pat: self Jul 23 13:39:35 shs slapd[20739]: <= check a_dn_pat: * Jul 23 13:39:35 shs slapd[20739]: <= acl_mask: [2] applying auth(=x) (stop) Jul 23 13:39:35 shs slapd[20739]: <= acl_mask: [2] mask: auth(=x) Jul 23 13:39:35 shs slapd[20739]: => access_allowed: auth access granted by auth(=x) Jul 23 13:39:35 shs slapd[20739]: conn=166 op=0 BIND dn="uid=revathy,ou=People,dc=domainname,dc=com" mech=SIMPLE ssf=0 Jul 23 13:39:35 shs slapd[20739]: do_bind: v3 bind: "uid=revathy,ou=People,dc=domainname,dc=com" to "uid=revathy,ou=People,dc=domainname,dc=com" Jul 23 13:39:35 shs slapd[20739]: send_ldap_result: conn=166 op=0 p=3 Jul 23 13:39:35 shs slapd[20739]: send_ldap_result: err=0 matched="" text="" Jul 23 13:39:35 shs slapd[20739]: send_ldap_response: msgid=1 tag=97 err=0 Jul 23 13:39:35 shs slapd[20739]: conn=166 op=0 RESULT tag=97 err=0 text= Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=6 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=7 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=8 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: select: listen=9 active_threads=0 tvp=NULL Jul 23 13:39:35 shs slapd[20739]: daemon: activity on 1 descriptors Jul 23 13:39:35 shs slapd[20739]: daemon: activity on: Jul 23 13:39:35 shs slapd[20739]: 18r Jul 23 13:39:35 shs slapd[20739]: Jul 23 13:39:35 shs slapd[20739]: daemon: read activity on 18 Jul 23 13:39:35 shs slapd[20739]: connection_get(18) Jul 23 13:39:35 shs slapd[20739]: connection_get(18): got connid=166 Jul 23 13:39:35 shs slapd[20739]: connection_read(18): checking for input on id=166 Jul 23 13:39:35 shs slapd[20739]: do_search Jul 23 13:39:35 shs slapd[20739]: >>> dnPrettyNormal: <o=sen,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: <<< dnPrettyNormal: <o=sen,dc=domainname,dc=com>, <o=sen,dc=domainname,dc=com> Jul 23 13:39:35 shs slapd[20739]: SRCH "o=sen,dc=domainname,dc=com" 2 0 Jul 23 13:39:35 shs slapd[20739]: 300 0 0 Jul 23 13:39:35 shs slapd[20739]: begin get_filter Jul 23 13:39:35 shs slapd[20739]: OR Jul 23 13:39:35 shs slapd[20739]: begin get_filter_list Jul 23 13:39:35 shs slapd[20739]: begin get_filter Jul 23 13:39:35 shs slapd[20739]: EQUALITY Its stop here and hang and we have to restart ldap to make it work.

1 0

(ITS#5057) AVA_Sort doesn't
by hyc＠OpenLDAP.org 22 Jul '07

22 Jul '07

Full_Name: Howard Chu Version: 2.1+ OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.95.127.34) Submitted by: hyc The AVA_Sort function hasn't really been touched much since it was written in December 2001. It appears that it only works for sorting RDNs with two AVAs or less. With 3 or more, it stops prematurely.

1 0

Re: (ITS#5040) modifyTimestamp being updated on login (bind) failure
by hyc＠symas.com 22 Jul '07

22 Jul '07

hyc(a)symas.com wrote: > Dan Cushing wrote: >> I'd defer to those with more expertise, but my vote is to avoid changing >> the modifyTimestamp attribute. That attribute should be updated only >> when an ldapmodify operation is performed. >> >> I'm not familiar with the specifications, and perhaps this isn't >> addressed there. My intuition suggests that it shouldn't be modified by >> operations that are not directly under the control of the user or >> administrator. > > Already fixed in CVS HEAD and RE23, please test. I'll note that this change will prevent these operational attributes from being replicated in many cases. Of course, given that the replication behavior of these attributes is currently undefined, it may not be a problem right now. Down the road, I don't know. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5040) modifyTimestamp being updated on login (bind) failure
by hyc＠symas.com 22 Jul '07

22 Jul '07

Dan Cushing wrote: > I'd defer to those with more expertise, but my vote is to avoid changing > the modifyTimestamp attribute. That attribute should be updated only > when an ldapmodify operation is performed. > > I'm not familiar with the specifications, and perhaps this isn't > addressed there. My intuition suggests that it shouldn't be modified by > operations that are not directly under the control of the user or > administrator. Already fixed in CVS HEAD and RE23, please test. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5040) modifyTimestamp being updated on login (bind) failure
by dan.cushing＠netideasinc.com 22 Jul '07

22 Jul '07

I'd defer to those with more expertise, but my vote is to avoid changing the modifyTimestamp attribute. That attribute should be updated only when an ldapmodify operation is performed. I'm not familiar with the specifications, and perhaps this isn't addressed there. My intuition suggests that it shouldn't be modified by operations that are not directly under the control of the user or administrator. Dan Howard Chu wrote: > dan.cushing(a)netideasinc.com wrote: >> Full_Name: Dan Cushing >> Version: 2.3.36 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (71.76.187.82) >> >> >> When running OpenLDAP with the ppolicy overlay, the modifyTimestamp >> for a user >> entry is updated if the user attempts to login (bind) with an incorrect >> password. This is happening because the password lockout feature is >> enabled and >> the operational attribute 'pwdFailureTime' is being updated. It >> seems like this >> results in a misleading modifyTimestamp. Is it intended that the >> modifyTimestamp attribute be updated when operational attributes are >> updated? > > Hadn't really thought about it before. We can certainly avoid this > though. -- This electronic transmission is strictly confidential to NetIDEAS, Inc. and intended solely for the addressee. It may contain information, which is covered by legal, professional, or other privilege. If you are not the intended addressee, or someone authorized by the intended addressee to receive transmissions on the behalf of the addressee, you must not retain, disclose in any form, copy or take any action in reliance on this transmission. If you have received this transmission in error, please notify us as soon as possible and destroy this message.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs