openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5306) install ladp
by ando＠sys-net.it 04 Jan '08

04 Jan '08

aslang(a)ntu.edu.sg wrote: > I keep having this error: please advice > > slapadd -l init.ldif > /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. > /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. > str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and > "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" > slapadd: could not parse entry (line=52) > > In my init.ldif, I do have line 52, my last line is 51 > This is the content of my init.ldif file > > dn: dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: dcObject > objectClass: organizationalUnit > dc: 4g > ou: NTU 4G Lab > dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: people > dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: staff > dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: students > dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg > objectClass: organizationalUnit > ou: visitors > dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: shadowAccount > uid: linda > sn: Ang > givenName: Linda > cn: Linda Ang > displayName: Linda Ang > uidNumber: 1000 > gidNumber: 10000 > userPassword: password > gecos: Linda Ang > loginShell: /bin/bash > homeDirectory: /home/linda > shadowExpire: -1 > shadowFlag: 0 > shadowWarning: 7 > shadowMin: 8 > shadowMax: 999999 > shadowLastChange: 10877 > mail: linda_yong(a)hotmail.com > postalCode: 31000 > l: Toulouse > o: Example > mobile: +65 (0)6 12345678 > homePhone: +33 (0)5 12345678 > title: System Administrator > postalAddress: > initials: LA > dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg > objectClass: posixGroup > cn: 4g > gidNumber: 10000 The error you see represents the expected behavior, since your LDIF file is invalid; please check your syntax. As there appears to be no OpenLDAP software bug, this ITS will be closed. Please direct further discussion to OpenLDAP-software. 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#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by josemarcodelarosa＠gmail.com 04 Jan '08

04 Jan '08

------=_Part_27665_28430263.1199452056921 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes, you are completely right. The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example. URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right). ------=_Part_27665_28430263.1199452056921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline   Yes, you are completely right.  The only reason I can think of using the DN version is because you are forced by your schema (attribute types for the expansion source attribute differ). I emphasize that the implementation of both is quite different. The DN version uses recursivity while the URL version relies in slapd's search-reply mechanism. I just added the first one as an example.   URL version is much more powerful and more elegant. You suggested subGroupURL: ldap:///<dn>??base, but even subGroupURL: ldap:///<dn> works ok (if I remember right). ------=_Part_27665_28430263.1199452056921--

1 0

(ITS#5306) install ladp
by aslang＠ntu.edu.sg 03 Jan '08

03 Jan '08

Full_Name: Linda Ang Version: OpenLDAP: slapd 2.3.35 OS: Ububtu 1.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.69.2.5) I keep having this error: please advice slapadd -l init.ldif /etc/ldap/slapd.conf: line 91: rootdn is always granted unlimited privileges. /etc/ldap/slapd.conf: line 112: rootdn is always granted unlimited privileges. str2entry: entry -1 has multiple DNs "dc=4g,dc=ntu,dc=edu,dc=sg" and "ou=people,dc=4g,dc=ntu,dc=edu,dc=sg" slapadd: could not parse entry (line=52) In my init.ldif, I do have line 52, my last line is 51 This is the content of the /etc/ldap/slapd.conf file ######################### /etc/ldap/slapd.conf ######################### # http://homex.subnet.at/~max/ldap/ # # Basic slapd.conf # # 2005.02.08 ZHANG.Guiyu(a)example.com ######################################################################## # Global Directives: # # Features to permit #allow bind_v2 # Schema and objectClass definitions # not all required, if you get errors about missing schema, comment out the missing schema here # some are provided by other packages such as samba include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/samba.schema # Schema check allows for forcing entries to # match schemas for their objectClasses's schemacheck on # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd.args # Read slapd.conf(5) for possible values loglevel 0 # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_bdb #moduleload back_passwd ####################################################################### # Specific Backend Directives for ldbm: # Backend specific directives apply to this backend until another # backend' directive occurs backend bdb ####################################################################### # Specific Backend Directives for 'other': # Backend specific directives apply to this backend until another # 'backend' directive occurs # backend <other> ####################################################################### # Specific Directives for database #1, of type ldbm: # Database specific directives apply to this databasse until another # 'database' directive occurs # # important: use bdb format, other formats like ldbm can cause data corruption database bdb # The base of your directory in database #1 suffix "dc=4g,dc=ntu,dc=edu,dc=sg" rootdn "cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" password-hash {CRYPT} #rootpw {CRYPT}asdfghjkl # # use "/usr/sbin/slappasswd -h {CRYPT}" to create a rootpw-string below rootpw {CRYPT}1zLLT3DU571FM # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only # access to attrs=userPassword,sambaLMPassword,sambaNTPassword by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by anonymous auth by self write by * none access to * by dn="cn=nss,dc=ntu,dc=edu,dc=sg" read by * auth # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. #access to dn.base="" by * read # The admin dn has full write access, everyone else # can read everything. access to * by dn="cn=root,dc=4g,dc=ntu,dc=edu,dc=sg" write by * read # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=admin,dc=mail,dc=example,dc=com" write # by dnattr=owner write ####################################################################### # Specific Directives for database #2, of type 'other' (can be bdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # #The base of your directory for database #2 #suffix "dc=debian,dc=org" ####################################################################### This is the content of my init.ldif file dn: dc=4g,dc=ntu,dc=edu,dc=sg objectClass: dcObject objectClass: organizationalUnit dc: 4g ou: NTU 4G Lab dn: ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: people dn: ou=staff,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: staff dn: ou=students,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: students dn: ou=visitors,ou=people,dc=4g,dc=ntu,dc=edu,dc=sg objectClass: organizationalUnit ou: visitors dn: uid=linda,ou=visitors,ou=people,dc=ntu,dc=edu,dc=sg objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: linda sn: Ang givenName: Linda cn: Linda Ang displayName: Linda Ang uidNumber: 1000 gidNumber: 10000 userPassword: password gecos: Linda Ang loginShell: /bin/bash homeDirectory: /home/linda shadowExpire: -1 shadowFlag: 0 shadowWarning: 7 shadowMin: 8 shadowMax: 999999 shadowLastChange: 10877 mail: linda_yong(a)hotmail.com postalCode: 31000 l: Toulouse o: Example mobile: +65 (0)6 12345678 homePhone: +33 (0)5 12345678 title: System Administrator postalAddress: initials: LA dn: cn=4g,ou=staff,ou=people,dc=ntu,dc=edu,dc=sg objectClass: posixGroup cn: 4g gidNumber: 10000

1 0

Re: (ITS#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by hyc＠symas.com 03 Jan '08

03 Jan '08

josemarcodelarosa(a)gmail.com wrote: > Full_Name: Jose Marco de la Rosa > Version: 2.3.39 > OS: Kubuntu 7.10 > URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-0… > Submission from: (NULL) (80.25.122.131) > > > Two overlays that implement dynamic group classes defined with URL attributes > and allowing nesting. > > - The first one is an extension of th overlay expandURL but allowing nesting > > - The second one changes the way groups are constructed in a more powerful way > * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. > * if both are active, some searches don't behave as expacted! > * Specifically, if you turn both overlays on and search for > * 'entries with member=<some member value>' won't work properly > * for one of the overlays (the firstly activated one) Seems there's really no need for the nestedAggregateAttrDN overlay, since that is just a proper subset of a URL. I.e., anywhere you would use a simple DN is just a case of subGroupURL: ldap:///<dn>??base -- -- 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#5305) Contribware: Two overlays for implementing NESTED dynamic groups
by josemarcodelarosa＠gmail.com 03 Jan '08

03 Jan '08

Full_Name: Jose Marco de la Rosa Version: 2.3.39 OS: Kubuntu 7.10 URL: ftp://ftp.openldap.org/incoming/Jose-Marco-de-la-Rosa-nestedAggregateAttr-0… Submission from: (NULL) (80.25.122.131) Two overlays that implement dynamic group classes defined with URL attributes and allowing nesting. - The first one is an extension of th overlay expandURL but allowing nesting - The second one changes the way groups are constructed in a more powerful way Examples of functioning follow for each version and are included in the overlays code archives (.c) The tarball Jose-Marco-de-la-Rosa-nestedAggregateAttr-080103.tgz was uploaded to openldap's server and it includes a webpage with further detail in the implementation and configuration of the overlay. Code files are appropriately linked in the web page mentioned (all is included in the tarball: there are no external references in the webpage). Both search and compare operations were implemented I hope you like it... ####################################################### First overlay: nestedAggregateAttrDN: * SYNTAX: * * In slapd.conf : * overlay nestedAggregateAttrDN * nestedAggregateAttrDN <objectClass> <source-attribute> <destination-attribute> [[<maximum-depth>] <TTL>] * Where: * <objectClass> specifies the class that should expand. * <source-attribute> establishes the attribute that contains information * about other entries where to gather destination attribute values from. * <destination-attribute> establishes the attribute that should present all the gathered values. * <maximum-depth> establishes the maximum nesting depth level. If not specified, it defaults * to 0 which means no nesting is allowed (not even one level). * <TTL> establishes the maximum time allowed to serve the query. You should take into account that: * If different TTLs are set for the different configurations the minimum * will be used for all configurations. * The TTL affects ALL searches done when the overlay is active and not only * those related to the configured clases. * * * EXAMPLE: * * NOTE: you will probably need/want to define some attributes and classes in your schema * example.schema: * ------------------- * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber> * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2 * * # Attribute type for new classes * * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1 * NAME 'subgroupDN' * DESC 'DN of a aggregable entry' * SUP distinguishedName ) * * # Classes for using overlay nestedAggregateAttrDN * * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1 * NAME 'subgroupedDNGroup' * DESC 'Sample class for nestedAggregateAttrDN (experimental purpose)' * SUP top STRUCTURAL * MUST cn * MAY ( member $ subgroupDN $ cn $ ou $ o $ description ) ) * * * slapd.conf: * ------------------- * overlay nestedAggregateAttrDN * # Configure class: subgroupedDNGroup * # Source attribute: subgroupDN * # Aggregated attribute: member * # Max depth in nesting: 4 * # TTL: 5 sec * nestedAggregateAttrDN subgroupedDNGroup subgroupDN member 4 5 * * * ldif: * ------------------- * * # Static1 * dn: cn=Static1,dc=test * cn: Static1 * objectClass: groupOfNames * member: cn=person1,dc=test * member: cn=person2,dc=test * * # Static2 * dn: cn=Static2,dc=test * cn: Static2 * objectClass: groupOfNames * member: cn=person3,dc=test * member: cn=person4,dc=test * * # SubgroupedLevel1 * dn: cn=SubgroupedLevel1,dc=test * cn: SubgroupedLevel1 * objectClass: subgroupedDNGroup * subgroupDN: cn=Static1,dc=test * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedDNGroup * subgroupDN: cn=SubgroupedLevel1,dc=test * subgroupDN: cn=Static2,dc=test * * * ------------------- * * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedDNGroup * subgroupDN: cn=SubgroupedLevel1,dc=test * subgroupDN: cn=Static2,dc=test * member: cn=person1,dc=test * member: cn=person2,dc=test * member: cn=person3,dc=test * member: cn=person4,dc=test * * * IMPORTANT: this overlay conflicts with nestedAggregateAttrURL. * if both are active, some searches don't behave as expacted! * Specifically, if you turn both overlays on and search for * 'entries with member=<some member value>' won't work properly * for one of the overlays (the firstly activated one) */ ####################################################### Second overlay: nestedAggregateAttrURL: * SYNTAX: * * In slapd.conf : * overlay nestedAggregateAttrURL * nestedAggregateAttrURL <objectClass> <source-attribute> <destination-attribute> [[<maximum-depth>] <TTL>] * Where: * <objectClass> specifies the class that should expand. * <source-attribute> establishes the attribute that contains information * about other entries where to gather destination attribute values from. * <destination-attribute> establishes the attribute that should present all the gathered values. * <maximum-depth> establishes the maximum nesting depth level. If not specified, it defaults * to 0 which means no nesting is allowed (not even one level). * <TTL> establishes the maximum time allowed to serve the query. You should take into account that: * If different TTLs are set for the different configurations the minimum * will be used for all configurations. * The TTL affects ALL searches done when the overlay is active and not only * those related to the configured clases. * * * EXAMPLE: * * NOTE: you will probably need/want to define some attributes and classes in your schema. You can use * netscape's groupOfURLs, anyway... * example.schema: * ------------------- * objectIdentifier YOUR_ENTERPRISE_Root 1.3.6.1.4.1.<somenumber> * objectIdentifier YOUR_ENTERPRISE_LDAP YOUR_ENTERPRISE_Root:3 * objectIdentifier YOUR_ENTERPRISE_LDAPattributeType YOUR_ENTERPRISE_LDAP:1 * objectIdentifier YOUR_ENTERPRISE_LDAPobjectClass YOUR_ENTERPRISE_LDAP:2 * * # Attribute type for new classes * * attributetype ( YOUR_ENTERPRISE_LDAPattributeType:1 * NAME 'subgroupURL' * DESC 'URL to search for aggregable entries' * SUP labeledURI ) * * # Classes for using overlay nestedAggregateAttrURL * * objectclass ( YOUR_ENTERPRISE_LDAPobjectClass:1 * NAME 'subgroupedURLGroup' * DESC 'Sample class for nestedAggregateAttrURL (experimental purpose)' * SUP top STRUCTURAL * MUST cn * MAY ( member $ subgroupURL $ cn $ ou $ o $ description ) ) * * attributetype ( IAVANTE_LDAPattributeType:2 * NAME 'subgroupURL' * DESC 'Identifies an URL containing a search for names of subgroups.' * SUP labeledURI ) * * * slapd.conf: * ------------------- * overlay nestedAggregateAttrURL * # Configure class: subgroupedURLGroup * # Source attribute: memberURL * # Aggregated attribute: member * # Max depth in nesting: 4 * # TTL: 5 sec * nestedAggregateAttrURL subgroupedURLGroup subgroupURL member 4 5 * * * ldif: * ------------------- * * # Static1 * dn: cn=Static1,dc=test * cn: Static1 * objectClass: groupOfNames * member: cn=person1,dc=test * member: cn=person2,dc=test * * # Static2 * dn: cn=Static2,dc=test * cn: Static2 * objectClass: groupOfNames * member: cn=person3,dc=test * member: cn=person4,dc=test * * # SubgroupedLevel1 * dn: cn=SubgroupedLevel1,dc=test * cn: SubgroupedLevel1 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///dc=test??one?(cn=Static*) * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test * * * ------------------- * * ldapsearch -x -b "SubgroupedLevel2,dc=test" will return * * # SubgroupedLevel2 * dn: cn=SubgroupedLevel2,dc=test * cn: SubgroupedLevel2 * objectClass: subgroupedURLGroup * subgroupURL: ldap:///cn=SubgroupedLevel1,dc=test * member: cn=person1,dc=test * member: cn=person2,dc=test * member: cn=person3,dc=test * member: cn=person4,dc=test * * IMPORTANT: this overlay conflicts with nestedAggregateAttrDN. * if both are active, some searches don't behave as expacted! * Specifically, if you turn both overlays on and search for * 'entries with member=<some member value>' won't work properly * for one of the overlays (the firstly activated one) * */

1 0

Re: (ITS#5281) doc contribution - set examples - following references
by ando＠sys-net.it 02 Jan '08

02 Jan '08

andreas(a)mandriva.com.br wrote: > On Wed, Jan 02, 2008 at 02:53:06PM +0000, Gavin Henry wrote: >> It's up for discussion if the ACL discussion in the current config sections >> of the admin guide should stay there or be moved out into their own. > > I think the ACLs should be moved to their own section, like the man > pages already have done. We have a man page for slapd.conf and another > specific one for the ACLs (slapd.access) ... but that was done essentially because ACL configuration amounts to ~30% of the total slapd.conf man page, but 90% of ACL documentation belongs to configuration. So it's not yet clear where they should be located in the Admin Guide. 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#5281) doc contribution - set examples - following references
by andreas＠mandriva.com.br 02 Jan '08

02 Jan '08

On Wed, Jan 02, 2008 at 02:53:06PM +0000, Gavin Henry wrote: > It's up for discussion if the ACL discussion in the current config sections > of the admin guide should stay there or be moved out into their own. I think the ACLs should be moved to their own section, like the man pages already have done. We have a man page for slapd.conf and another specific one for the ACLs (slapd.access)

1 0

Re: (ITS#5304) bug in source code: libldap/extended.c ?
by ando＠sys-net.it 02 Jan '08

02 Jan '08

I've patched it differently in HEAD (rev. 1.44); please check. 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#5304) bug in source code: libldap/extended.c ?
by mark.funkenhauser＠bluecoat.com 02 Jan '08

02 Jan '08

Correction to suggested fix: I think the code at line 374 should look like: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { ld->ld_errno = LDAP_DECODING_ERROR; ber_free( ber, 0 ); if( resoid != NULL ) LDAP_FREE( resoid ); if (resdata != NULL) ber_bvfree( resdata ); return ld->ld_errno; }

1 0

(ITS#5304) bug in source code: libldap/extended.c ?
by mark.funkenhauser＠bluecoat.com 02 Jan '08

02 Jan '08

Full_Name: Mark Funkenhauser Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.16.247.2) Looking at libldap/extended.c, rev 1.43, function ldap_parse_intermediate(), at line 374, the code is written as: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { rc = LDAP_DECODING_ERROR; goto free_and_return; } I think there's a problem here. 1) rc is defined to be a ber_tag_t type, which is not suitable for assignment to an LDAP_*_ERROR error code. ber_tag_t is an unsigned type, and LDAP_DECODING_ERROR is a negative number. 2) The use of LDAP_DECODING_ERROR here implies there is an error. I would have thought this function should be returning this error code using "return ld->ld_errno". Jumping to "free_and_return" is not the way to return an error. 3) the "goto free_and_return" is a jump to code to handle a successful return from this function. Assigning any value to rc before this "goto" becomes a no-op because the code after "free_and_return" does not use rc. I think the code at line 374 should look like: if ( ber_scanf( ber, /*{*/ "}" ) == LBER_ERROR ) { ld->ld_errno = LDAP_DECODING_ERROR; ber_free( ber, 0 ); if( resoid != NULL ) LDAP_FREE( resoid ); return ld->ld_errno; }

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