- openldap-bugs - openldap.org

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 24 Jul '07

24 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 23 Jul '07

23 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 23 Jul '07

23 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

ITS#5028 incomplete slapcat docs
by hyc＠symas.com 22 Jul '07

22 Jul '07

> From: Gavin Henry <openldap-its(a)OpenLDAP.org> > Date: Fri Jul 13 18:19:25 2007 > > The same sentance is in slapadd(8)/slapindex(8) too. That is correct; slapadd/slapindex must never be run while slapd is running. -- -- 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

ITS#5009 ldapsearch -C
by hyc＠symas.com 22 Jul '07

22 Jul '07

As noted elsewhere, the "-C" option is intentionally undocumented. Since the command line tools only support anonymous referral chasing, and referral chasing through untrusted servers is inherently unsafe, it's best not to do it. This ITS will be closed. -- -- 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(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. -- -- 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#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠suretecsystems.com 21 Jul '07

21 Jul '07

<quote who="hyc(a)symas.com"> > ando(a)sys-net.it wrote: >> ghenry(a)suretecsystems.com wrote: >>> <quote who="hyc(a)symas.com"> >>>> ghenry(a)OpenLDAP.org wrote: >>>>> Full_Name: Gavin Henry >>>>> Version: HEAD >>>>> OS: >>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>> Submission from: (NULL) (80.229.93.1) >>>>> Submitted by: ghenry >>>>> >>>>> >>>>> Dear All, >>>>> >>>>> It's not clear or explained what AVA means in slapd-meta(5) and >>>>> slapo-rwm(5) >>>> Standard terminology in X.500/LDAP. "Attribute Value Assertion" >>>>> A user was asking in #ldap >>>>> >>>>> I presume it means "Attribute Value"? >>>>> >>>>> If so, I will add an explaination in each man page. >>>> OpenLDAP docs are not intended to explain the basics of LDAP. You're >>>> expected >>>> to already know LDAP or refer to the RFCs for basic terminology. >>> Closing ITS. >> >> In any case, expanding acronyms when first used sounds "polite"; any >> further reference to the most appropriate RFC should allow newbie >> readers to learn more. > > Perhaps, in the Admin Guide. We have it in preamble.sdf already, so I think this is covered. > But in the man page? Where do you draw the line? > Do we have to start every man page with e.g. "the meta backend to slapd > (the > Standalone LDAP (Lightweight Directory Access Protocol) Daemon) performs > basic > LDAP proxying..." ? > > In this case, what good would it do? Would someone who hasn't read any > RFCs > know what "Attribute Value Assertion" means? Anyone who doesn't understand > the > X.500 information model has no business administering slapd. They need to > absorb that basic groundwork first, and IMO manpages are not the mechanism > for > teaching that. > -- > -- 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#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by hyc＠symas.com 21 Jul '07

21 Jul '07

ando(a)sys-net.it wrote: > ghenry(a)suretecsystems.com wrote: >> <quote who="hyc(a)symas.com"> >>> ghenry(a)OpenLDAP.org wrote: >>>> Full_Name: Gavin Henry >>>> Version: HEAD >>>> OS: >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (80.229.93.1) >>>> Submitted by: ghenry >>>> >>>> >>>> Dear All, >>>> >>>> It's not clear or explained what AVA means in slapd-meta(5) and >>>> slapo-rwm(5) >>> Standard terminology in X.500/LDAP. "Attribute Value Assertion" >>>> A user was asking in #ldap >>>> >>>> I presume it means "Attribute Value"? >>>> >>>> If so, I will add an explaination in each man page. >>> OpenLDAP docs are not intended to explain the basics of LDAP. You're >>> expected >>> to already know LDAP or refer to the RFCs for basic terminology. >> Closing ITS. > > In any case, expanding acronyms when first used sounds "polite"; any > further reference to the most appropriate RFC should allow newbie > readers to learn more. Perhaps, in the Admin Guide. But in the man page? Where do you draw the line? Do we have to start every man page with e.g. "the meta backend to slapd (the Standalone LDAP (Lightweight Directory Access Protocol) Daemon) performs basic LDAP proxying..." ? In this case, what good would it do? Would someone who hasn't read any RFCs know what "Attribute Value Assertion" means? Anyone who doesn't understand the X.500 information model has no business administering slapd. They need to absorb that basic groundwork first, and IMO manpages are not the mechanism for teaching that. -- -- 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#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ando＠sys-net.it 21 Jul '07

21 Jul '07

ghenry(a)suretecsystems.com wrote: > <quote who="hyc(a)symas.com"> >> ghenry(a)OpenLDAP.org wrote: >>> Full_Name: Gavin Henry >>> Version: HEAD >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (80.229.93.1) >>> Submitted by: ghenry >>> >>> >>> Dear All, >>> >>> It's not clear or explained what AVA means in slapd-meta(5) and >>> slapo-rwm(5) >> Standard terminology in X.500/LDAP. "Attribute Value Assertion" >>> A user was asking in #ldap >>> >>> I presume it means "Attribute Value"? >>> >>> If so, I will add an explaination in each man page. >> OpenLDAP docs are not intended to explain the basics of LDAP. You're >> expected >> to already know LDAP or refer to the RFCs for basic terminology. > > Closing ITS. In any case, expanding acronyms when first used sounds "polite"; any further reference to the most appropriate RFC should allow newbie readers to learn more. 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#5053) openldap 2.3.36 crashing
by hyc＠symas.com 21 Jul '07

21 Jul '07

igbed(a)wmin.ac.uk wrote: > Full_Name: Damian Igbe > Version: 2.3.6 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (161.74.11.24) > > > I have a delta-syncrepl replication working with password policy in place. > Authentication to the master works fine but when a client tries to authenticate > to the replica server, the following bug is encountered and the system crashes. There is not enough information in this bug report. Please include a copy of your slapd.conf from the replica, and a copy of your password policy. Please also show the LDAP request that was issued when the crash occurred. -- -- 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#4959) replica seg faults if syncrepl searchbase =""
by hyc＠symas.com 21 Jul '07

21 Jul '07

ali.pouya(a)free.fr wrote: > h.b.furuseth(a)usit.uio.no wrote : > >> That's from ITS#4975: The code was broken for builds without TLS. >> It's been fixed in HEAD. Does it work now? > > Hi Hallvard, > Yes I confirm that the problem with TLS compilation is fixed now. > > But the main problem of this ITS still remains (replica seg faults if syncrepl > searchbase =""). > > Sorry for this late answer. > Best regards > Ali If the current HEAD still crashes for you, please attach your slapd.conf files in a followup to this ITS, thanks. -- -- 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#4961) If database suffix is ""
by hyc＠symas.com 21 Jul '07

21 Jul '07

ali.pouya(a)free.fr wrote: > Unfortunately the problem has not been completely fixed in the HEAD. > With the fix in the head the error message disappears but the contextCSN ins NOT > ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is > missing. An the servers hav to resynchronize. In fact the contextCSN was getting written out, but not getting read back in on the next startup. This should now be working in HEAD, 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: Contrib: addpartial overlay (ITS#3593)
by hyc＠symas.com 20 Jul '07

20 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. That's correct. If there was no config needed under the old mechanism, then none is needed with the new either. -- -- 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: Contrib: addpartial overlay (ITS#3593)
by dhawes＠vt.edu 20 Jul '07

20 Jul '07

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

1 0

Re: (ITS#5056) ldap_add_result_entry crashes when starting a new list
by pturgyan＠umich.edu 20 Jul '07

20 Jul '07

On Jul 20, 2007, at 3:31 PM, Howard Chu wrote: > pturgyan(a)umich.edu wrote: >> Full_Name: Paul Turgyan >> Version: 2.3.35 >> OS: linux 2..6.18 from source URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (141.213.231.171) >> When calling ldap_add_result_entry with an empty list or when >> starting a new >> list, ldap_add_result_entry crashes >> with a SEGFAULT at line 67. >> Here is a patch: > > A different fix is now in HEAD, 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/ Works for me! Thanks.

1 0

Re: (ITS#5056) ldap_add_result_entry crashes when starting a new list
by hyc＠symas.com 20 Jul '07

20 Jul '07

pturgyan(a)umich.edu wrote: > Full_Name: Paul Turgyan > Version: 2.3.35 > OS: linux 2..6.18 from source > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.213.231.171) > > > When calling ldap_add_result_entry with an empty list or when starting a new > list, ldap_add_result_entry crashes > with a SEGFAULT at line 67. > > Here is a patch: A different fix is now in HEAD, 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

(ITS#5056) ldap_add_result_entry crashes when starting a new list
by pturgyan＠umich.edu 20 Jul '07

20 Jul '07

Full_Name: Paul Turgyan Version: 2.3.35 OS: linux 2..6.18 from source URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.213.231.171) When calling ldap_add_result_entry with an empty list or when starting a new list, ldap_add_result_entry crashes with a SEGFAULT at line 67. Here is a patch: *** addentry.c Tue Jan 2 16:43:48 2007 --- addentry.c+ Fri Jul 20 13:48:41 2007 *************** *** 64,69 **** --- 64,72 ---- assert( e != NULL ); e->lm_chain = *list; + if (*list) e->lm_chain_tail = (*list)->lm_chain_tail; + else + e->lm_chain_tail = NULL; *list = e; }

1 0

Re: (ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠suretecsystems.com 20 Jul '07

20 Jul '07

<quote who="hyc(a)symas.com"> > ghenry(a)OpenLDAP.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.229.93.1) >> Submitted by: ghenry >> >> >> Dear All, >> >> It's not clear or explained what AVA means in slapd-meta(5) and >> slapo-rwm(5) > > Standard terminology in X.500/LDAP. "Attribute Value Assertion" >> >> A user was asking in #ldap >> >> I presume it means "Attribute Value"? >> >> If so, I will add an explaination in each man page. > > OpenLDAP docs are not intended to explain the basics of LDAP. You're > expected > to already know LDAP or refer to the RFCs for basic terminology. Closing ITS. > > -- > -- 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#5055) index generation failure with empty suffix
by hyc＠symas.com 20 Jul '07

20 Jul '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.34 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (71.202.148.128) > > > If a database has a zero-length suffix, the NULL context entry gets an entry ID > of zero, which is usually an invalid ID number and always omitted from indexing. > But it looks like with slapadd -q, it is possible for this entry to get > included in various indices, which will totally confuse them. > > (per Howard) I actually filed this already instead of waiting for you (ITS#5052). A patch is already in HEAD for testing. This ITS will be closed. -- -- 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#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by hyc＠symas.com 20 Jul '07

20 Jul '07

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.229.93.1) > Submitted by: ghenry > > > Dear All, > > It's not clear or explained what AVA means in slapd-meta(5) and slapo-rwm(5) Standard terminology in X.500/LDAP. "Attribute Value Assertion" > > A user was asking in #ldap > > I presume it means "Attribute Value"? > > If so, I will add an explaination in each man page. OpenLDAP docs are not intended to explain the basics of LDAP. You're expected to already know LDAP or refer to the RFCs for basic terminology. -- -- 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

(ITS#5055) index generation failure with empty suffix
by quanah＠zimbra.com 20 Jul '07

20 Jul '07

Full_Name: Quanah Gibson-Mount Version: 2.3.34 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.202.148.128) If a database has a zero-length suffix, the NULL context entry gets an entry ID of zero, which is usually an invalid ID number and always omitted from indexing. But it looks like with slapadd -q, it is possible for this entry to get included in various indices, which will totally confuse them. (per Howard) --Quanah

1 0

Re: (ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by ghenry＠suretecsystems.com 20 Jul '07

20 Jul '07

<quote who="Ralf Haferkamp"> > On Friday 20 July 2007 16:45, ghenry(a)openldap.org wrote: >> Full_Name: Gavin Henry >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (80.229.93.1) >> Submitted by: ghenry >> >> >> Dear All, >> >> It's not clear or explained what AVA means in slapd-meta(5) and >> slapo-rwm(5) >> >> A user was asking in #ldap >> >> I presume it means "Attribute Value"? > It means "Attribute Value Assertion", normally. Doh, helped if I read the RFCs. Oh but look who has a nice page in it: https://www.opends.org/wiki//page/DefinitionAttributeValueAssertion Maybe we need a nice OpenLDAP Wiki? (one for -devel list I think) > >> If so, I will add an explaination in each man page. > > -- > Ralf >

1 0

Re: (ITS#5054) AVA in slapd-meta(5) and slapo-rwm(5)
by rhafer＠suse.de 20 Jul '07

20 Jul '07

On Friday 20 July 2007 16:45, ghenry(a)openldap.org wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.229.93.1) > Submitted by: ghenry > > > Dear All, > > It's not clear or explained what AVA means in slapd-meta(5) and > slapo-rwm(5) > > A user was asking in #ldap > > I presume it means "Attribute Value"? It means "Attribute Value Assertion", normally. > If so, I will add an explaination in each man page. -- Ralf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs