openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs