- openldap-bugs - openldap.org

(ITS#5928) build without SSL fails
by quanah＠OpenLDAP.org 06 Feb '09

06 Feb '09

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If you build OpenLDAP with --without-tls and --without-cyrus-sasl, the build fails: Entering subdirectory libldap make[3]: Entering directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries/libldap' /bin/sh ../../libtool --mode=compile cc -g -O0 -I../../include -I../../include -I/opt/zimbra/bdb-4.7.25.3/include -I/opt/zimbra/libtool-2.2.6a/include -DLDAP_LIBRARY -c tls2.c cc -g -O0 -I../../include -I../../include -I/opt/zimbra/bdb-4.7.25.3/include -I/opt/zimbra/libtool-2.2.6a/include -DLDAP_LIBRARY -c tls2.c -fPIC -DPIC -o .libs/tls2.o tls2.c: In function `ldap_pvt_tls_ctx_free': tls2.c:81: error: `tls_imp' undeclared (first use in this function) tls2.c:81: error: (Each undeclared identifier is reported only once tls2.c:81: error: for each function it appears in.) tls2.c: At top level: tls2.c:85: error: syntax error before '*' token tls2.c: In function `tls_ctx_ref': tls2.c:87: error: `ctx' undeclared (first use in this function) tls2.c:89: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_destroy': tls2.c:102: error: structure has no member named `ldo_tls_ctx' tls2.c:103: error: structure has no member named `ldo_tls_ctx' tls2.c:104: error: structure has no member named `ldo_tls_ctx' tls2.c:107: error: structure has no member named `ldo_tls_certfile' tls2.c:108: error: structure has no member named `ldo_tls_certfile' tls2.c:109: error: structure has no member named `ldo_tls_certfile' tls2.c:111: error: structure has no member named `ldo_tls_keyfile' tls2.c:112: error: structure has no member named `ldo_tls_keyfile' tls2.c:113: error: structure has no member named `ldo_tls_keyfile' tls2.c:115: error: structure has no member named `ldo_tls_dhfile' tls2.c:116: error: structure has no member named `ldo_tls_dhfile' tls2.c:117: error: structure has no member named `ldo_tls_dhfile' tls2.c:119: error: structure has no member named `ldo_tls_cacertfile' tls2.c:120: error: structure has no member named `ldo_tls_cacertfile' tls2.c:121: error: structure has no member named `ldo_tls_cacertfile' tls2.c:123: error: structure has no member named `ldo_tls_cacertdir' tls2.c:124: error: structure has no member named `ldo_tls_cacertdir' tls2.c:125: error: structure has no member named `ldo_tls_cacertdir' tls2.c:127: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:128: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:129: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:131: error: structure has no member named `ldo_tls_crlfile' tls2.c:132: error: structure has no member named `ldo_tls_crlfile' tls2.c:133: error: structure has no member named `ldo_tls_crlfile' tls2.c: In function `ldap_pvt_tls_destroy': tls2.c:148: error: `tls_imp' undeclared (first use in this function) tls2.c: At top level: tls2.c:156: error: syntax error before '*' token tls2.c: In function `tls_init': tls2.c:166: error: `impl' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_init': tls2.c:182: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_init_ctx': tls2.c:192: error: `tls_impl' undeclared (first use in this function) tls2.c:192: error: `ti' undeclared (first use in this function) tls2.c:192: error: `tls_imp' undeclared (first use in this function) tls2.c:193: error: variable `lts' has initializer but incomplete type tls2.c:193: error: structure has no member named `ldo_tls_info' tls2.c:193: error: storage size of 'lts' isn't known tls2.c:195: error: structure has no member named `ldo_tls_ctx' tls2.c:237: error: structure has no member named `ldo_tls_ctx' tls2.c:238: error: structure has no member named `ldo_tls_ctx' tls2.c:249: error: structure has no member named `ldo_tls_ctx' tls2.c:250: error: structure has no member named `ldo_tls_ctx' tls2.c:251: error: structure has no member named `ldo_tls_ctx' tls2.c: At top level: tls2.c:283: error: syntax error before '*' token tls2.c: In function `alloc_handle': tls2.c:286: error: `tls_ctx' undeclared (first use in this function) tls2.c:286: error: `ctx' undeclared (first use in this function) tls2.c:287: error: `tls_session' undeclared (first use in this function) tls2.c:287: error: `ssl' undeclared (first use in this function) tls2.c:294: error: structure has no member named `ldo_tls_ctx' tls2.c:297: error: `tls_imp' undeclared (first use in this function) tls2.c: At top level: tls2.c:306: error: syntax error before "tls_session" tls2.c: In function `update_flags': tls2.c:308: error: `sb' undeclared (first use in this function) tls2.c:311: error: `tls_imp' undeclared (first use in this function) tls2.c:311: error: `ssl' undeclared (first use in this function) tls2.c:311: error: `rc' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_connect': tls2.c:332: error: `tls_session' undeclared (first use in this function) tls2.c:332: error: `ssl' undeclared (first use in this function) tls2.c:338: error: `tls_ctx' undeclared (first use in this function) tls2.c:338: error: `ctx' undeclared (first use in this function) tls2.c:340: error: structure has no member named `ldo_tls_ctx' tls2.c:350: error: `tls_imp' undeclared (first use in this function) tls2.c:355: error: structure has no member named `ldo_tls_ctx' tls2.c:356: error: structure has no member named `ldo_tls_ctx' tls2.c:359: error: structure has no member named `ldo_tls_connect_cb' tls2.c:360: error: structure has no member named `ldo_tls_connect_cb' tls2.c:361: error: structure has no member named `ldo_tls_connect_arg' tls2.c:362: error: structure has no member named `ldo_tls_connect_cb' tls2.c:362: error: structure has no member named `ldo_tls_connect_cb' tls2.c:363: error: structure has no member named `ldo_tls_connect_cb' tls2.c:364: error: structure has no member named `ldo_tls_connect_cb' tls2.c:364: error: structure has no member named `ldo_tls_connect_arg' tls2.c: In function `ldap_pvt_tls_accept': tls2.c:414: error: `tls_session' undeclared (first use in this function) tls2.c:414: error: `ssl' undeclared (first use in this function) tls2.c:426: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_get_peer_dn': tls2.c:483: error: `tls_session' undeclared (first use in this function) tls2.c:483: error: `session' undeclared (first use in this function) tls2.c:487: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_check_hostname': tls2.c:498: error: `tls_session' undeclared (first use in this function) tls2.c:498: error: `session' undeclared (first use in this function) tls2.c:500: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_get_option': tls2.c:604: error: structure has no member named `ldo_tls_mode' tls2.c:607: error: structure has no member named `ldo_tls_ctx' tls2.c:608: error: structure has no member named `ldo_tls_ctx' tls2.c:609: error: structure has no member named `ldo_tls_ctx' tls2.c:613: error: structure has no member named `ldo_tls_cacertfile' tls2.c:614: error: structure has no member named `ldo_tls_cacertfile' tls2.c:617: error: structure has no member named `ldo_tls_cacertdir' tls2.c:618: error: structure has no member named `ldo_tls_cacertdir' tls2.c:621: error: structure has no member named `ldo_tls_certfile' tls2.c:622: error: structure has no member named `ldo_tls_certfile' tls2.c:625: error: structure has no member named `ldo_tls_keyfile' tls2.c:626: error: structure has no member named `ldo_tls_keyfile' tls2.c:629: error: structure has no member named `ldo_tls_dhfile' tls2.c:630: error: structure has no member named `ldo_tls_dhfile' tls2.c:633: error: structure has no member named `ldo_tls_crlfile' tls2.c:634: error: structure has no member named `ldo_tls_crlfile' tls2.c:637: error: structure has no member named `ldo_tls_require_cert' tls2.c:640: error: structure has no member named `ldo_tls_crlcheck' tls2.c:643: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:644: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:647: error: structure has no member named `ldo_tls_protocol_min' tls2.c:650: error: structure has no member named `ldo_tls_randfile' tls2.c:651: error: structure has no member named `ldo_tls_randfile' tls2.c:666: error: structure has no member named `ldo_tls_connect_cb' tls2.c:669: error: structure has no member named `ldo_tls_connect_arg' tls2.c: In function `ldap_pvt_tls_set_option': tls2.c:710: error: structure has no member named `ldo_tls_mode' tls2.c:718: error: structure has no member named `ldo_tls_ctx' tls2.c:719: error: structure has no member named `ldo_tls_ctx' tls2.c:720: error: structure has no member named `ldo_tls_ctx' tls2.c:721: error: structure has no member named `ldo_tls_ctx' tls2.c:724: error: structure has no member named `ldo_tls_connect_cb' tls2.c:727: error: structure has no member named `ldo_tls_connect_arg' tls2.c:730: error: structure has no member named `ldo_tls_cacertfile' tls2.c:730: error: structure has no member named `ldo_tls_cacertfile' tls2.c:731: error: structure has no member named `ldo_tls_cacertfile' tls2.c:734: error: structure has no member named `ldo_tls_cacertdir' tls2.c:734: error: structure has no member named `ldo_tls_cacertdir' tls2.c:735: error: structure has no member named `ldo_tls_cacertdir' tls2.c:738: error: structure has no member named `ldo_tls_certfile' tls2.c:738: error: structure has no member named `ldo_tls_certfile' tls2.c:739: error: structure has no member named `ldo_tls_certfile' tls2.c:742: error: structure has no member named `ldo_tls_keyfile' tls2.c:742: error: structure has no member named `ldo_tls_keyfile' tls2.c:743: error: structure has no member named `ldo_tls_keyfile' tls2.c:746: error: structure has no member named `ldo_tls_dhfile' tls2.c:746: error: structure has no member named `ldo_tls_dhfile' tls2.c:747: error: structure has no member named `ldo_tls_dhfile' tls2.c:750: error: structure has no member named `ldo_tls_crlfile' tls2.c:750: error: structure has no member named `ldo_tls_crlfile' tls2.c:751: error: structure has no member named `ldo_tls_crlfile' tls2.c:761: error: structure has no member named `ldo_tls_require_cert' tls2.c:771: error: structure has no member named `ldo_tls_crlcheck' tls2.c:776: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:776: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:777: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:782: error: structure has no member named `ldo_tls_protocol_min' tls2.c:788: error: structure has no member named `ldo_tls_randfile' tls2.c:788: error: structure has no member named `ldo_tls_randfile' tls2.c:789: error: structure has no member named `ldo_tls_randfile' tls2.c:794: error: structure has no member named `ldo_tls_ctx' tls2.c:795: error: structure has no member named `ldo_tls_ctx' tls2.c:796: error: structure has no member named `ldo_tls_ctx' tls2.c: In function `ldap_int_tls_start': tls2.c:822: error: `tls_imp' undeclared (first use in this function) tls2.c:838: error: structure has no member named `ldo_tls_require_cert' tls2.c: In function `ldap_pvt_tls_get_strength': tls2.c:863: error: `tls_session' undeclared (first use in this function) tls2.c:863: error: `session' undeclared (first use in this function) tls2.c:865: error: `tls_imp' undeclared (first use in this function) make[3]: *** [tls2.lo] Error 1 make[3]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries/libldap' make[2]: *** [all-common] Error 1 make[2]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z' make: *** [build] Error 2

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 06 Feb '09

06 Feb '09

michael(a)stroeder.com wrote: > I'd recommend not to mess around with the hostport portion of the LDAP > URL. In opposite to Hallvard I'm not even sure whether a distinction is > really needed when invoking ldap_initialize(). ok ... The rfc 2255 defined the LDAP URL syntaxe as : scheme "://" [hostport] ["/" [dn etc... where host (rfc1738) must be a fully qualified domain name of a network host or IP address. (a fully qualified domain name cannot effectiely begin with a '.' ;-) Therefore, transforming a fully qualified domain name in a IP adress remains to be a DNS job. But, "My.domain.[:port]" is actually a fully qualified domain name and produce effectively one (at least) IP address of a network host when a SRV rr is defined and an authoritative answer can be obtained from a DNS. Of course I admit it could be not very efficient to try systematically a SRV resolution on every domain name of a LDAP URLS chain ... So I propose to add an extension (something like "forceSrvSearch") which will indicate that the library must perform a SRV request on this URL to find the IP address from the hostname (or hostport) parameter specified. It'll be a bit more complex to patch up ... :( -- PE

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 06 Feb '09

06 Feb '09

Some additional information: Some objects being returned from AD have very large multi-valued attributes (for example, member). AD is returning them in the ";range" format, but they are not getting past back-meta. For example, a direct search for the object in AD will return stuff like this: member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User Accounts,OU=Common,DC=my-company,DC=com but doing the same search through slapd/back-meta using the same credentials, the member attribute is not displayed at all. There are no attribute maps in place that would cause this. -Matt

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 06 Feb '09

06 Feb '09

On Feb 6, 2009, at 12:29 AM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> Hi All, >> We have an LDAP server that is proxying for Active Directory. >> Periodically slapd >> throws an assertion: >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: >> octetStringIndexer: >> Assertion `i > 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted >> (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> Howard Chu's examination of the core file showed that the remote AD >> server >> returned a member attribute with no values. This is only legal in >> LDAP when a >> client sets the attrsonly flag in its search request, and that flag >> was not set >> here. >> The indexer rightly asserts because pcache handed it an attribute >> with nothing >> to index. >> I'm not sure what the correct thing to do might be here, but it >> should not take >> down the slapd. > > The entry should not be cached, IMHO. Fair enough, I think. -Matt > > > 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 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- >

1 0

Re: (ITS#5927) assertion error when using pcache
by michael＠stroeder.com 06 Feb '09

06 Feb '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> mhardin(a)symas.com wrote: >>> Howard Chu's examination of the core file showed that the remote AD server >>> returned a member attribute with no values. This is only legal in LDAP when a >>> client sets the attrsonly flag in its search request, and that flag was not set >>> here. > [..] > AD is flaky enough already, but it's possible that back-meta may have dropped > the attr values during rewriting, etc. FWIW: I never saw an empty attribute value list returned by AD. I've added code to web2ldap to handle that case since I had this issue with various other LDAP servers but not AD. Ciao, Michael.

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ghenry＠suretecsystems.com 06 Feb '09

06 Feb '09

----- "Quanah Gibson-Mount" <quanah(a)zimbra.com> wrote: > --On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org > wrote: > > > Awww, aren't we nice! ;-) > > > > Patch applied, > > The new patch is definitely an improvement, however it fails to > document > the hexadecimal notation for log levels, which is also perfectly > valid. > See slapd.conf(5): > > 1 (0x1 trace) trace function calls > 2 (0x2 packets) debug packet handling > 4 (0x4 args) heavy trace debugging (function args) In the admin guide patch, I see: -1 Any enable all debugging 0 no debugging Do we now use: \".TP \".B 4096 \".B (0x1000 cache) \"caching (unused) \".TP \".B 8192 \".B (0x2000 index) \"data indexing (unused) This is from slapd.conf(5), but it appears in the patch. Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 06 Feb '09

06 Feb '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > ando(a)sys-net.it wrote: > > mhardin(a)symas.com wrote: > >> Full_Name: Matthew Hardin > >> Version: 2.4.13 > >> OS: Red Hat Enterprise Linux 4 i686 > >> URL: ftp://ftp.openldap.org/incoming/ > >> Submission from: (NULL) (74.38.114.185) > >> > >> > >> Hi All, > >> > >> We have an LDAP server that is proxying for Active Directory. > Periodically slapd > >> throws an assertion: > >> > >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: > octetStringIndexer: > >> Assertion `i> 0' failed. > >> /etc/init.d/solserver: line 192: 6620 Aborted > (core dumped) > >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS > >> > >> Howard Chu's examination of the core file showed that the remote AD > server > >> returned a member attribute with no values. This is only legal in > LDAP when a > >> client sets the attrsonly flag in its search request, and that flag > was not set > >> here. > >> > >> The indexer rightly asserts because pcache handed it an attribute > with nothing > >> to > >> index. > >> > >> I'm not sure what the correct thing to do might be here, but it > should not take > >> down the slapd. > > > > The entry should not be cached, IMHO. > > Perhaps. But then the entire query cannot be cached, because its > result set > would be known to be incomplete. Of course, I meant the whole query. > There's something more going on here, because the query in question > was > searching for > (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There > was no memberUid at all in the returned entry, so it must have matched > on > member, so the member attr should not have been empty. > > AD is flaky enough already, but it's possible that back-meta may have > dropped > the attr values during rewriting, etc. It is perfectly legitimate for back-meta to return attrs with no values, AFAIK; only, the a_vals should contain the address of slap_dummy_bv... 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5925
by tchemineau＠linagora.com 06 Feb '09

06 Feb '09

Le Thu, 5 Feb 2009 21:04:08 GMT, hyc(a)symas.com a écrit : > ando(a)sys-net.it wrote: > > If it works, then we still have an issue: operations for "o=1,o=2" > > will probably be intercepted by the back-bdb. However, I > > understand that since the first database is glued, it wants to know > > whom it's glued to. > > A fix is in HEAD. It will allow this scenario to succeed, but it will > also allow completely broken subordinate configs to be dynamically > created in cn=config. (configs read from slapd.conf/slapd.d will > still be error checked appropriately.) As such, it needs a bit more > thought. I confirm that we can not create subordinate configs dynamically in cn=config now. I used a previously build version to realize it, just for testing it. There is still errors with slaptest, even on slapd.d. Same errors when I want to start OpenLDAP. 8<-------- ldif_read_file: read entry file: "/usr/local/openldap-2.4/etc/openldap/slapd.d/cn=config/olcDatabase={4}bdb/olcOverlay={0}glue.ldif" => str2entry: "dn: olcOverlay={0}glue objectClass: olcOverlayConfig olcOverlay: {0}glue structuralObjectClass: olcOverlayConfig entryUUID: 939c8813-5218-44bb-a344-bcef144a7b72 creatorsName: cn=config createTimestamp: 20090206104810Z entryCSN: 20090206104810.538680Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20090206104810Z " >>> dnPrettyNormal: <olcOverlay={0}glue> <<< dnPrettyNormal: <olcOverlay={0}glue>, <olcOverlay={0}glue> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> <= str2entry(olcOverlay={0}glue) -> 0x1658c958 => test_filter PRESENT => access_allowed: search access to "olcOverlay={0}glue,olcDatabase={4}bdb,cn=config" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 slaptest: backglue.c:1126: glue_sub_attach: Assertion `on != ((void *)0)' failed. 8<-------- Thomas. -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

1 0

Re: ITS#5924
by tchemineau＠linagora.com 06 Feb '09

06 Feb '09

Le Thu, 5 Feb 2009 18:55:14 GMT, ando(a)sys-net.it a écrit : > Should be fixed in HEAD; please test. Test OK for me. Thanks a lot :) Cheers, Thomas. -- Thomas Chemineau Groupe LINAGORA - http://www.linagora.com Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 06 Feb '09

06 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at > begining of the hostname to say "use SRV record" of this domain - search > domain(s) if only '.') ?... I'd recommend not to mess around with the hostport portion of the LDAP URL. In opposite to Hallvard I'm not even sure whether a distinction is really needed when invoking ldap_initialize(). Ciao, Michael.

1 0

Re: (ITS#5927) assertion error when using pcache
by hyc＠symas.com 06 Feb '09

06 Feb '09

hyc(a)symas.com wrote: > There's something more going on here, because the query in question was > searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). I meant (&(objectclass=posixgroup)(|(memberUid=foo)(member=foo-DN))) > There > was no memberUid at all in the returned entry, so it must have matched on > member, so the member attr should not have been empty. > > AD is flaky enough already, but it's possible that back-meta may have dropped > the attr values during rewriting, etc. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5927) assertion error when using pcache
by hyc＠symas.com 06 Feb '09

06 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We have an LDAP server that is proxying for Active Directory. Periodically slapd >> throws an assertion: >> >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: >> Assertion `i> 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> >> Howard Chu's examination of the core file showed that the remote AD server >> returned a member attribute with no values. This is only legal in LDAP when a >> client sets the attrsonly flag in its search request, and that flag was not set >> here. >> >> The indexer rightly asserts because pcache handed it an attribute with nothing >> to >> index. >> >> I'm not sure what the correct thing to do might be here, but it should not take >> down the slapd. > > The entry should not be cached, IMHO. Perhaps. But then the entire query cannot be cached, because its result set would be known to be incomplete. There's something more going on here, because the query in question was searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There was no memberUid at all in the returned entry, so it must have matched on member, so the member attr should not have been empty. AD is flaky enough already, but it's possible that back-meta may have dropped the attr values during rewriting, etc. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 05 Feb '09

05 Feb '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.13 > OS: Red Hat Enterprise Linux 4 i686 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.185) > > > Hi All, > > We have an LDAP server that is proxying for Active Directory. Periodically slapd > throws an assertion: > > slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: > Assertion `i > 0' failed. > /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) > "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS > > Howard Chu's examination of the core file showed that the remote AD server > returned a member attribute with no values. This is only legal in LDAP when a > client sets the attrsonly flag in its search request, and that flag was not set > here. > > The indexer rightly asserts because pcache handed it an attribute with nothing > to > index. > > I'm not sure what the correct thing to do might be here, but it should not take > down the slapd. The entry should not be cached, IMHO. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my,dc=domaine)
by philippe.eychart＠informatique.gov.pf 05 Feb '09

05 Feb '09

Sorry : -ldap_initialize( LDAP **ldp, LDAP_CONST char *url ) +ldap_initialize( LDAP **ldp, LDAP_CONST char *url_in ) -- PE

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 05 Feb '09

05 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C987A2.419734D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit and patch could be something like that ... -- pe -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoye : jeudi 5 fevrier 2009 11:33 A : h.b.furuseth(a)usit.uio.no; ando(a)sys-net.it Cc : openldap-its(a)openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard ------=_NextPart_000_00B1_01C987A2.419734D0 Content-Type: application/octet-stream; name="open.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.patch" --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = 13:23:58.000000000 -1000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-05 = 14:34:14.000000000 -1000=0A= @@ -212,19 +212,33 @@=0A= return( ld );=0A= }=0A= =0A= +char *=0A= +url_expand_on_srv_search ( const char *url_in )=0A= +{=0A= + // soon=0A= +=0A= + return LDAP_STRDUP( url_in );=0A= +}=0A= +=0A= =0A= int=0A= -ldap_initialize( LDAP **ldp, LDAP_CONST char *url )=0A= +ldap_initialize( LDAP **ldp, const char *url_in )=0A= {=0A= int rc;=0A= LDAP *ld;=0A= + char *url;=0A= =0A= *ldp =3D NULL;=0A= rc =3D ldap_create(&ld);=0A= if ( rc !=3D LDAP_SUCCESS )=0A= return rc;=0A= =0A= - if (url !=3D NULL) {=0A= + if (url_in !=3D NULL) {=0A= + url =3D url_expand_on_srv_search ( url_in );=0A= + if ( url =3D=3D NULL ) {=0A= + return LDAP_URL_ERR_MEM;=0A= + }=0A= +=0A= rc =3D ldap_set_option(ld, LDAP_OPT_URI, url);=0A= if ( rc !=3D LDAP_SUCCESS ) {=0A= ldap_ld_free(ld, 1, NULL, NULL);=0A= @@ -234,6 +248,7 @@=0A= if (ldap_is_ldapc_url(url))=0A= LDAP_IS_UDP(ld) =3D 1;=0A= #endif=0A= + LDAP_FREE( url );=0A= }=0A= =0A= *ldp =3D ld;=0A= ------=_NextPart_000_00B1_01C987A2.419734D0--

1 0

(ITS#5927) assertion error when using pcache
by mhardin＠symas.com 05 Feb '09

05 Feb '09

Full_Name: Matthew Hardin Version: 2.4.13 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We have an LDAP server that is proxying for Active Directory. Periodically slapd throws an assertion: slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: Assertion `i > 0' failed. /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS Howard Chu's examination of the core file showed that the remote AD server returned a member attribute with no values. This is only legal in LDAP when a client sets the attrsonly flag in its search request, and that flag was not set here. The indexer rightly asserts because pcache handed it an attribute with nothing to index. I'm not sure what the correct thing to do might be here, but it should not take down the slapd. Thanks, -Matt

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > gavin.henry(a)gmail.com wrote: >> Ok, but wouldn't that detail be best served staying in the man page? I >> mean, what "user" will want to enter hex for loglevels? > > Actually, I wonder what user would use the decimal notation. I > introduced the hexadecimal because I find it a little more intuitive in > terms of bitwise (then I decided to move to string-based :) After giving many training sessions, I can assure you many "doing their best" users trust the decimal notation. Their managers, trying to help analyze problems, also. I know one such guy, head of infrastructure for a multinational company, with little or no background in IT, who speaks fluently in decimal OpenLDAP log levels :) Also, specifying "255" is much shorter than "Trace Packets Args Conns BER Filter Config Args". Thus, I feel it's still useful to find decimal notations in the guide. At least, to understand existing configs. On the same basis, hex could be useful. Jonathan

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 05 Feb '09

05 Feb '09

And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: ITS#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> ando(a)sys-net.it wrote: >>> If it works, then we still have an issue: operations for "o=1,o=2" will >>> probably be intercepted by the back-bdb. However, I understand that >>> since the first database is glued, it wants to know whom it's glued to. >> A fix is in HEAD. It will allow this scenario to succeed, but it will >> also allow completely broken subordinate configs to be dynamically >> created in cn=config. (configs read from slapd.conf/slapd.d will still >> be error checked appropriately.) As such, it needs a bit more thought. > > Need ldap-txn, don't we? I guess that could help. We haven't figured out yet how to propagate TXNs in syncrepl though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > If it works, then we still have an issue: operations for "o=1,o=2" will > probably be intercepted by the back-bdb. However, I understand that > since the first database is glued, it wants to know whom it's glued to. A fix is in HEAD. It will allow this scenario to succeed, but it will also allow completely broken subordinate configs to be dynamically created in cn=config. (configs read from slapd.conf/slapd.d will still be error checked appropriately.) As such, it needs a bit more thought. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Howard Chu wrote: > ando(a)sys-net.it wrote: >> If it works, then we still have an issue: operations for "o=1,o=2" will >> probably be intercepted by the back-bdb. However, I understand that >> since the first database is glued, it wants to know whom it's glued to. > > A fix is in HEAD. It will allow this scenario to succeed, but it will > also allow completely broken subordinate configs to be dynamically > created in cn=config. (configs read from slapd.conf/slapd.d will still > be error checked appropriately.) As such, it needs a bit more thought. Need ldap-txn, don't we? 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 05 Feb '09

05 Feb '09

This is now fixed in HEAD: modifications to the objectClass attribute that change the structural objectClass are automatically reflected by in the structuralObjectClass attribute. What's missing right now is that structuralObjectClass should no longer be manageable (I believe). test037 also needs to be cleaned up. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

ITS#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Does it work if you change the order of the databases? I mean: +++ original dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] +++ original +++ modified dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn: olcDatabase={3}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] +++ modified If it works, then we still have an issue: operations for "o=1,o=2" will probably be intercepted by the back-bdb. However, I understand that since the first database is glued, it wants to know whom it's glued to. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: ITS#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Should be fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5926) slapd proxying AD with back-meta locks up
by mhardin＠symas.com 05 Feb '09

05 Feb '09

Full_Name: Matthew Hardin Version: 2.4.12 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We are using a pair of OpenLDAP 2.4.12 servers with back-meta to proxy an active directory domain. The clients are all current versions of PADL's nss_ldap libraries. Every once in a while (sometimes twice a day, sometimes once every two weeks) one of the slapd servers will peg CPU use at 100% and stop answering requests. The only way to stop slapd is with a kill -9. There doesn't seem to be anything to explain the lockup or allow us to reproduce it. We are using redundant AD servers and they are not going offline. A third slapd server running as a test server using the same AD servers and configured identically but serving a much lighter nss_ldap load does not fail at all. We have ruled out hardware, OS, and connectivity as possible causes. We are unfortunately unable to attach gdb to the running processes, as these are production servers and need to be restarted immediately. Our smaller test system does not exhibit the same behavior, either. There is nothing unusual in the server logs, either. We do have core files generated from kill -6 commands, and they are all eerily similar to the back-trace below in that they have one or more threads waiting for a search or a bind response from AD. I am also enclosing relevant portions of slapd.conf for these systems. Please let me know if any additional information would be useful. Thanks, -Matt ----- (gdb) thr apply all bt Thread 18 (process 24520): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038b557 in pthread_join () from /lib/libpthread.so.0 #2 0x00a118dc in ldap_pvt_thread_join (thread=20691856, thread_return=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:197 #3 0x08070f79 in slapd_daemon () at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:2656 #4 0x08058544 in main (argc=7, argv=0xbf90dec4) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/main.c:948 Thread 17 (process 24525): #0 0x005fa410 in __kernel_vsyscall () #1 0x005862c6 in epoll_wait () from /lib/libc.so.6 #2 0x080704ab in slapd_daemon_task (ptr=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:2291 #3 0x0038a45b in start_thread () from /lib/libpthread.so.0 #4 0x00585c4e in clone () from /lib/libc.so.6 Thread 16 (process 24526): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 15 (process 24527): #0 0x005fa410 in __kernel_vsyscall () #1 0x00586ca8 in send () from /lib/libc.so.6 #2 0x00582269 in __vsyslog_chk () from /lib/libc.so.6 #3 0x005825aa in syslog () from /lib/libc.so.6 #4 0x08085093 in slap_send_ldap_result (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/result.c:656 #5 0x00149c3c in bdb_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/back-bdb/search.c:1025 #6 0x080e09b1 in overlay_op_walk (op=0x9b5d968, rs=0x17bc120, which=op_search, oi=0x95d0e90, on=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:667 #7 0x080e0b41 in over_op_func (op=0x9b5d968, rs=0x17bc120, which=op_search) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:719 #8 0x080e0bb9 in over_op_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:741 #9 0x08076577 in fe_op_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:366 #10 0x08075fa2 in do_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:217 #11 0x08073682 in connection_operation (ctx=0x17bc220, arg_v=0x9b5d968) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1084 #12 0x08073acf in connection_read_thread (ctx=0x17bc220, argv=0x19c) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1210 #13 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #14 0x0038a45b in start_thread () from /lib/libpthread.so.0 #15 0x00585c4e in clone () from /lib/libc.so.6 Thread 14 (process 24528): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 13 (process 24935): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 12 (process 26566): #0 0x005fa410 in __kernel_vsyscall () #1 0x0057c033 in poll () from /lib/libc.so.6 #2 0x00a2af30 in ldap_int_select (ld=0xaaf60a28, timeout=0x1bbbdb0) at os-ip.c:1053 #3 0x00a12eb8 in wait4msg (ld=0xaaf60a28, msgid=59, all=2, timeout=0x1bbc028, result=0x1bbbeb4) at result.c:355 #4 0x00a12881 in ldap_result (ld=0xaaf60a28, msgid=59, all=2, timeout=0x1bbc028, result=0x1bbbeb4) at result.c:127 #5 0x00d73bba in meta_back_search (op=0xaaff7ce0, rs=0x1bbd120) ---Type <return> to continue, or q <return> to quit--- at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/back-meta/search.c:1027 #6 0x08076577 in fe_op_search (op=0xaaff7ce0, rs=0x1bbd120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:366 #7 0x08075fa2 in do_search (op=0xaaff7ce0, rs=0x1bbd120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:217 #8 0x08073682 in connection_operation (ctx=0x1bbd220, arg_v=0xaaff7ce0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1084 #9 0x08073acf in connection_read_thread (ctx=0x1bbd220, argv=0x146) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1210 #10 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #11 0x0038a45b in start_thread () from /lib/libpthread.so.0 #12 0x00585c4e in clone () from /lib/libc.so.6 Thread 11 (process 26567): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 10 (process 29015): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 9 (process 11659): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 ---Type <return> to continue, or q <return> to quit--- #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 8 (process 29762): #0 0x005fa410 in __kernel_vsyscall () #1 0x005925ee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x0058267d in _L_lock_700 () from /lib/libc.so.6 #3 0x005821a9 in __vsyslog_chk () from /lib/libc.so.6 #4 0x005825aa in syslog () from /lib/libc.so.6 #5 0x080727c1 in connection_destroy (c=0xb7d7c450) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:664 #6 0x08072d05 in connection_close (c=0xb7d7c450) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:799 #7 0x080741e3 in connection_read (s=333, cri=0x328b1a0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1386 #8 0x08073a4d in connection_read_thread (ctx=0x328b220, argv=0x14d) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1203 #9 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #10 0x0038a45b in start_thread () from /lib/libpthread.so.0 #11 0x00585c4e in clone () from /lib/libc.so.6 Thread 7 (process 29763): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 6 (process 29764): #0 0x005fa410 in __kernel_vsyscall () #1 0x005925ee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x0058267d in _L_lock_700 () from /lib/libc.so.6 #3 0x005821a9 in __vsyslog_chk () from /lib/libc.so.6 #4 0x005825aa in syslog () from /lib/libc.so.6 #5 0x080d36b9 in do_syncrep2 (op=0x3a8cd70, si=0x95d0ff8) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/syncrepl.c:1174 #6 0x080d3b93 in do_syncrepl (ctx=0x3a8d220, arg=0x95d1250) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/syncrepl.c:1301 ---Type <return> to continue, or q <return> to quit--- #7 0x08073aeb in connection_read_thread (ctx=0x3a8d220, argv=0xe) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1212 #8 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #9 0x0038a45b in start_thread () from /lib/libpthread.so.0 #10 0x00585c4e in clone () from /lib/libc.so.6 Thread 5 (process 29765): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 4 (process 29766): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 3 (process 29767): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 2 (process 29768): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 ---Type <return> to continue, or q <return> to quit--- #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 1 (process 29769): #0 0x005fa410 in __kernel_vsyscall () #1 0x004ddd10 in raise () from /lib/libc.so.6 #2 0x004df621 in abort () from /lib/libc.so.6 #3 0x004d715b in __assert_fail () from /lib/libc.so.6 #4 0x0806eec8 in slap_listener (sl=0x9583108) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1803 #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1997 #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 #8 0x00585c4e in clone () from /lib/libc.so.6 (gdb) ------ slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include /opt/symas/etc/openldap/schema/core.schema #include /opt/symas/etc/openldap/schema/ppolicy.schema #include /opt/symas/etc/openldap/schema/corba.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema #include /opt/symas/etc/openldap/schema/eduperson.schema #include /opt/symas/etc/openldap/schema/java.schema #include /opt/symas/etc/openldap/schema/krb5-kdc.schema #include /opt/symas/etc/openldap/schema/misc.schema include /opt/symas/etc/openldap/schema/nis.schema.my-customer #include /opt/symas/etc/openldap/schema/connexitor.schema #include /opt/symas/etc/openldap/schema/openldap.schema #include /opt/symas/etc/openldap/schema/samba.schema # TLS Setup Section # # TLSCACertificateFile <filename> # Specifies the file that contains certificates for all # of the Certificate Authorities that slapd will # recognize. #TLSCACertificateFile /opt/symas/ssl/cacert.pem TLSCACertificatePath /opt/symas/ssl/certs # # TLSCertificateFile <filename> # Specifies the file that contains the slapd server # certificate. TLSCertificateFile /opt/symas/etc/openldap/ldap-server1-4-cert.pem # # TLSCertificateKeyFile <filename> # Specifies the file that contains the slapd server # private key that matches the certificate stored in the # TLSCertificateFile file. Currently, the private key # must not be protected with a password, so it is of # critical importance that it is protected carefully. TLSCertificateKeyFile /opt/symas/etc/openldap/ldap-server1-4-key.pem # # TLSRandFile <filename> # Specifies the file from which to obtain random bits when # /dev/[u]random is not available. Generally set to the # name of the EGD/PRNGD socket. The environment variable # RANDFILE can also be used to specify the filename. #TLSRandFile /var/symas/egd-pool TLSVerifyClient never pidfile /var/symas/slapd.pid argsfile /var/symas/slapd.args modulepath /opt/symas/lib/openldap moduleload back_bdb.la moduleload syncprov.la moduleload back_ldap.la moduleload back_meta.la moduleload back_monitor.la # Access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn="" by * read access to * by self write by users read by anonymous auth # # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! ####################################################################### # Logging configuration loglevel none ####################################################################### # bdb database definitions ####################################################################### database bdb suffix "ou=nisdata" rootdn "ou=nisdata" rootpw xxxxxx # Indices to maintain. index default eq index objectClass index cn,sn,uid index uidNumber,gidNumber,memberUid,uniqueMember index oncRpcNumber,ipServicePort,ipServiceProtocol index ipNetworkNumber,ipHostNumber,ipProtocolNumber index entryCSN index entryUUID directory /var/symas/openldap-data/my-customer-nis cachesize 5000 idlcachesize 5000 checkpoint 512 60 # syncrepl consumer # Note that RIDs in mirrormode pair must be identical syncrepl rid=7 provider=ldaps://server01.my-customer.com searchbase=ou=nisdata type=refreshAndPersist retry="30 +" bindmethod=simple binddn=ou=nisdata credentials=xxxxxx tls_cacertdir=/opt/symas/ssl/certs tls_cert=/opt/symas/etc/openldap/ldap-server1-4-cert.pem tls_key=/opt/symas/etc/openldap/ldap-server1-4-key.pem tls_reqcert=demand syncdata=default # syncrepl Provider overlay syncprov syncprov-checkpoint 1000 60 mirrormode on ####################################################################### # Definitions for proxy and cache to AD ####################################################################### database meta suffix "dc=my-customer,dc=com" rootdn "cn=proxy,dc=my-customer,dc=com" rootpw xxxxxx limits users time.soft=30 time.hard=soft # The link to AD: uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my-customer,dc=com ldaps://ldap-prd-dc02.my-customer.com/ # Switch(es) we need for this target rewriteEngine on chase-referrals no conn-ttl 300 network-timeout 10 pseudoroot-bind-defer yes idassert-bind bindmethod=simple binddn="cn=cnsproxy,ou=service,ou=accounts,ou=restricted,dc=my-customer,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,ou=principals,dc=nis,dc=my-customer,dc=com" idassert-bind bindmethod=simple binddn="cn=cnsproxy,ou=service,ou=accounts,ou=restricted,dc=my-customer,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,dc=my-customer,dc=com" # We are putting the AD information under 'dc=ad' because it's going to # end up there in an upcoming change to the AD environment. This is also # a good thing because it helps back-meta unambiguously resolve references # to the AD target. # This suffixmassage rewites the foreign DN suffix ("dc=my-customer,dc=com") # to the one we'll be using within the combined directory # ("dc=ad,dc=my-customer,dc=com"). This suffixmassage can be removed when that # change has been made in AD. suffixmassage "dc=ad,dc=my-customer,dc=com" "dc=my-customer,dc=com" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. This section takes # care of that. map objectClass posixAccount user map attribute uid samAccountName map attribute "" gecos map attribute gecos displayName map attribute homeDirectory unixHomeDirectory map attribute "" homeDirectory map attribute shadowLastChange pwdLastSet map attribute cn * map attribute gidNumber * map attribute sn * map attribute uidNumber * map attribute loginShell * map attribute "" accountExpires map attribute "" badPasswordTime map attribute "" badPwdCount map attribute "" codePage map attribute "" company map attribute "" countryCode map attribute "" department map attribute "" distinguishedName map attribute "" homeDrive map attribute "" initials map attribute "" instanceType map attribute "" lastLogoff map attribute "" lastLogon map attribute "" lastLogonTimeStamp map attribute "" logonCount #map attribute "" memberOf map attribute "" name map attribute "" objectCategory map attribute "" objectGuid map attribute "" objectSid map attribute "" primaryGroupId map attribute "" samAccountType map attribute "" userAccountControl map attribute "" userPrincipalName map attribute "" usnChanged map attribute "" usnCreated map attribute "" whenChanged map attribute "" whenCreated map attribute "" dscoRepropagationData map attribute "" groupType map objectClass posixGroup group # # The link to the NIS data directory (yes, we could chain/glue, that's # for later) uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my-customer,dc=com # Switch(es) needed for this target rewriteEngine on idassert-authzFrom "cn=proxy,dc=my-customer,dc=com" idassert-bind bindmethod=simple binddn="cn=proxy,ou=principals,dc=nis,dc=my-customer,dc=com" credentials=xxxxxxx mode=legacy # We are putting the NIS information under 'dc=nis' so that back-meta can # unambiguously resolve references to the NIS target. # This suffixmassage rewites the foreign DN suffix ("dc=my-customer,dc=com") # to the one we'll be using within the combined directory # ("dc=nis,dc=my-customer,dc=com"). suffixmassage "dc=nis,dc=my-customer,dc=com" "ou=nisdata" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. This section takes # care of that. map attribute member uniqueMember ####################################################################### # Monitor database ####################################################################### database monitor

1 0

ITS#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Using valgrind, I note few issues conn=0 op=1 MODRDN dn="olcDatabase={2}bdb,cn=config" ==17038== Thread 3: ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715C1: config_rename_kids (bconfig.c:3816) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F140 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071583: config_rename_kids (bconfig.c:3814) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715EE: config_rename_kids (bconfig.c:3818) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F1A0 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071594: config_rename_kids (bconfig.c:3815) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) conn=0 op=1 RESULT tag=109 err=0 text= which eventually result in the screwed name of the children entries of the renamed database. I'm investigating... 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ando＠sys-net.it 05 Feb '09

05 Feb '09

gavin.henry(a)gmail.com wrote: > Ok, but wouldn't that detail be best served staying in the man page? I > mean, what "user" will want to enter hex for loglevels? Actually, I wonder what user would use the decimal notation. I introduced the hexadecimal because I find it a little more intuitive in terms of bitwise (then I decided to move to string-based :) 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by gavin.henry＠gmail.com 05 Feb '09

05 Feb '09

Ok, but wouldn't that detail be best served staying in the man page? I mean, what "user" will want to enter hex for loglevels? I'll make the same anyway. Thanks. On 05/02/2009, quanah(a)zimbra.com <quanah(a)zimbra.com> wrote: > --On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > >> Awww, aren't we nice! ;-) >> >> Patch applied, > > The new patch is definitely an improvement, however it fails to document > the hexadecimal notation for log levels, which is also perfectly valid. > See slapd.conf(5): > > 1 (0x1 trace) trace function calls > 2 (0x2 packets) debug packet handling > 4 (0x4 args) heavy trace debugging (function args) > > > and the description therein: > > The desired log level can be input as a single integer that > combines the (ORed) desired levels, both in decimal or in > hexadecimal notation, as a list of integers (that are ORed > internally), or as a list of the names that are shown between > brackets, such that > > loglevel 129 > loglevel 0x81 > loglevel 128 1 > loglevel 0x80 0x1 > loglevel acl trace > > are equivalent. > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Fixed in HEAD for back-bdb & back-hdb; back-ldif does not suffer from this issue. proxy backends and so should neither. Not sure about other backends like back-sql and back-ndb. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > A fix is coming (hopefully for 2.4.14 :). p. Fixed in HEAD. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5925) [backend config] glue: no superior found in N-Way Multi-Master replication
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) When : when a replica replicates its entire cn=config from a provider, and the configuration has gluing databases. Suppose you have into your config backend the following : 8<-------- dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://1.2.3.4/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 olcSyncrepl: {1}rid=002 provider=ldap://1.2.3.5/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 [...] dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config [...] dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config [...] 8<-------- slaptest passes successfully, and OpenLDAP starts. When a new provider joins the N-Way Multi-Master replication, it replicates all the configuration from the primary provider (which is indicated in its minimalistic configuration). But, the replication failed on the following error : 8<-------- Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_search (0) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 olcDatabase={2}ldap,cn=config Feb 5 18:25:04 server2 slapd[6202]: glue: no superior found for sub o=1,o=2! Feb 5 18:25:04 server2 slapd[6202]: olcSubordinate: value #0: <olcSubordinate> handler exited with 32! Feb 5 18:25:04 server2 slapd[6202]: null_callback : error code 0x50 Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add (80) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add failed (80) Feb 5 18:25:04 server2 slapd[6202]: do_syncrepl: rid=001 retrying 8<-------- It appears that ldap's backend which is subordinate to an other backend should be declared after this gluing database. This is exactly the contrary on how works slapd.conf. Thomas.

1 0

(ITS#5924) [backend config] modify rdn on a backend entry will cause bad renaming of all subentries when retrieving by ldapsearch
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Renaming an entry of a configugred OpenLDAP backend causes bad renaming of its subentries and all subentries of all other backends, when retrieving them by a simple LDAP search. For example, suppose you have these configuration into slapd.conf : 8<-------- database bdb suffix "o=1" directory /usr/local/openldap-2.4/var/openldap-data-1 overlay rwm rwm-suffixmassage o=1 dc=1 database bdb suffix "o=2" overlay glue rootdn "cn=Directory Manager,o=2" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-2 database bdb suffix "o=3" rootdn "cn=Directory Manager,o=3" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-3 8<-------- When you convert slapd.conf to slapd.d (backend config), then you should obtain something like the following (slapcat -b cn=config -F ...) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=1 [...] dn: olcOverlay={0}rwm,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}glue dn: olcDatabase={4}bdb,cn=config olcSuffix: o=3 [...] 8<-------- Now, for some reason, you want to rename olcDatabase={2}bdb,cn=config into olcDatabase={3}bdb,cn=config (to invert declaration for example). This operation works successfully but causes all subentries DN to be rename improperly. You obtain someting like the following via ldapsearch (not via slapcat) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn:: IHFbGSxvbGNEYXRhYmFzZT17Mn1iZGIsY249Y29uZmlnAGJkYixjbj1jb25maWc= objectClass: olcOverlayConfig olcOverlay: {0}glue [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=1 [...] dn:: LG9sY0RhdGFiYXNlPXszfWJkYixjbj1jb25maWcAezJ9YmRiLGNuPWNvbmZpZw== objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={4}bdb,cn=config [...] 8<-------- When decoding DN, we obtain bad characters. This issue provide broken replication in a N-Way Multi-Master cluster. Thomas.

1 0

Re: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

adrien.futschik(a)atosorigin.com wrote: > >> No. Replication is supposed to work regardless of mode, refreshOnly / >> refreshAndPersist should yield identical results. > ... > >> There is still a bug here. > > You mean that the fact that N-way Multi-master doesn't replicate deletes properly when using "refreshOnly" is a bug ? > > But N-way Multi-master seams to be working correctly when using "refreshAndPersist". I see some reasons why using "refreshOnly" instead of "refreshAndPersist", will this be corrected in the next release of OpenLDAP ? > > What is recommended with OpenLDAP 2.4.11. Should we wait for the next stable release if we intend to use N-way Multi-master in production ? I would wait for 2.4.14. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by quanah＠zimbra.com 05 Feb '09

05 Feb '09

--On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > Awww, aren't we nice! ;-) > > Patch applied, The new patch is definitely an improvement, however it fails to document the hexadecimal notation for log levels, which is also perfectly valid. See slapd.conf(5): 1 (0x1 trace) trace function calls 2 (0x2 packets) debug packet handling 4 (0x4 args) heavy trace debugging (function args) and the description therein: The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that loglevel 129 loglevel 0x81 loglevel 128 1 loglevel 0x80 0x1 loglevel acl trace are equivalent. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) Submitted by: ando A fix is coming (hopefully for 2.4.14 :). p.

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ghenry＠OpenLDAP.org 05 Feb '09

05 Feb '09

----- jclarke(a)linagora.com wrote: > Gavin Henry wrote: > > Can you follow the IPR notice details at: > > > > http://www.openldap.org/devel/contributing.html > > > > Since this is a patch, we need the above adhering to. > > Gavin, > > Of course. Thanks Jonathan. > I, Jonathan Clarke, 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. > > URL: > ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch > > Since this is not new code (mostly simple copy and paste from the man > > pages), I have not included a notice of origin in the patch file. I > hope > this is correct. Let me know, otherwise. > > > Thanks for your work, it's always appreciated when someone take time > to > > contribute! > > My pleasure, it's always nice to have such a great base to contribute > to :) Awww, aren't we nice! ;-) Patch applied, Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

Gavin Henry wrote: > Can you follow the IPR notice details at: > > http://www.openldap.org/devel/contributing.html > > Since this is a patch, we need the above adhering to. Gavin, Of course. I, Jonathan Clarke, 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. URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch Since this is not new code (mostly simple copy and paste from the man pages), I have not included a notice of origin in the patch file. I hope this is correct. Let me know, otherwise. > Thanks for your work, it's always appreciated when someone take time to > contribute! My pleasure, it's always nice to have such a great base to contribute to :) Jonathan

1 0

Re: (ITS#5922) progress bar proposal
by ghenry＠OpenLDAP.org 05 Feb '09

05 Feb '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > Gavin Henry wrote: > > ----- hyc(a)symas.com wrote: > > > >> hyc(a)symas.com wrote: > >>> progress seems a bit too generic; the names probably should be > >> prefixed with > >>> lutil. Also I suggest using "meter" instead of "progress". > >>> > >>> lutil-meter.h, meter.c. > >> Currently it's enabled by default. I have a feeling it should be > >> disabled when > >> various debug flags are set. Any thoughts? Would there ever be a > >> situation > >> where you want debug enabled *and* the progress meter enabled? > > > > How would that work? The debug message would stream down your > console > > and then the meter would have to consistently return to the start of > the > > prompt/window to make any sense? Or would it would it switch to just > showing > > an elapsed time and the end of the run? > > > The messages would all be interleaved; it would be rather ugly. Thought so. So off when debug is on make perfect sense to me. -- 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#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

Gavin Henry wrote: > ----- hyc(a)symas.com wrote: > >> hyc(a)symas.com wrote: >>> progress seems a bit too generic; the names probably should be >> prefixed with >>> lutil. Also I suggest using "meter" instead of "progress". >>> >>> lutil-meter.h, meter.c. >> Currently it's enabled by default. I have a feeling it should be >> disabled when >> various debug flags are set. Any thoughts? Would there ever be a >> situation >> where you want debug enabled *and* the progress meter enabled? > > How would that work? The debug message would stream down your console > and then the meter would have to consistently return to the start of the > prompt/window to make any sense? Or would it would it switch to just showing > an elapsed time and the end of the run? > The messages would all be interleaved; it would be rather ugly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5922) progress bar proposal
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

----- hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > > progress seems a bit too generic; the names probably should be > prefixed with > > lutil. Also I suggest using "meter" instead of "progress". > > > > lutil-meter.h, meter.c. > > Currently it's enabled by default. I have a feeling it should be > disabled when > various debug flags are set. Any thoughts? Would there ever be a > situation > where you want debug enabled *and* the progress meter enabled? How would that work? The debug message would stream down your console and then the meter would have to consistently return to the start of the prompt/window to make any sense? Or would it would it switch to just showing an elapsed time and the end of the run? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

hyc(a)symas.com wrote: > progress seems a bit too generic; the names probably should be prefixed with > lutil. Also I suggest using "meter" instead of "progress". > > lutil-meter.h, meter.c. Currently it's enabled by default. I have a feeling it should be disabled when various debug flags are set. Any thoughts? Would there ever be a situation where you want debug enabled *and* the progress meter enabled? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5922) progress bar proposal
by hyc＠symas.com 04 Feb '09

04 Feb '09

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, head > OS: any > URL: > Submission from: (NULL) (76.88.99.93) > > > Here is a proposal for a progress bar reporting tool, to appear in > slapadd and other long running tools. A similar version was used > previously in Symas's OpenLDAP 2.3 (CDS3) product. This version is > significantly more modular, so that alternative estimators and display > systems may be added. > > By default, it displays a text bar showing activity, progress, percent > completion, estimated time to completion, elapsed time, and speed in > bytes of ldif per second. > > The display functions are modular so that we could add a running trace > of numbers that a graphical front-end might read and transform into > pretty animated pie charts, or potentially fancier display within > these tools. > > The default (and only) supplied display system currently relies only > on carriage return, with no external libraries needed or dependencies > on terminal features. > > Estimators are modular as well, as the default linear estimator can be > frustratingly poor for very large, poorly tuned databases with > extremely non-linear load times. > > Progress is estimated by fstat()ing the ldif file and ftell()ing to > see the position. As a result, ldif read from stdin automatically > disables the progress bar. > > Files are available at: > > http://lirone.symas.net/lucca/progress-bar/ > > * Apply progress.patch > * Copy progress.c into libraries/liblutil/progress.c > * Copy progress.h into include/progress.h progress seems a bit too generic; the names probably should be prefixed with lutil. Also I suggest using "meter" instead of "progress". lutil-meter.h, meter.c. > We should probably make this configurable via the commandline (on/off, > as well as which display and estimator systems to use), but currently > it is always on provided stderr is a tty and the ldif is a file. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5922) progress bar proposal
by mbackes＠symas.com 04 Feb '09

04 Feb '09

In clarification of software origins, the progress bar code is my own original work (as a Symas employee). Symas retains copyright but licenses it under the OpenLDAP Public License. Patches to makefiles and slapd.c are derivative of work by the OpenLDAP project. "progress.c" and "progress.h" are Copyright 2009 by Symas Corporation and myself. Redistribution and use in source and binary forms, with or without modification, are permitted as authorized by the OpenLDAP Public License. progress.patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the patch were developed by myself at Symas Corporation. We have not assigned rights and/or interest in this work to any party. I, Matthew Backes, am authorized by Symas Corporation, my employer, to release this work under the terms of the OpenLDAP Public License, as available from http://www.OpenLDAP.org/license.html . Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#5922) progress bar proposal
by mbackes＠symas.com 04 Feb '09

04 Feb '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: Submission from: (NULL) (76.88.99.93) Here is a proposal for a progress bar reporting tool, to appear in slapadd and other long running tools. A similar version was used previously in Symas's OpenLDAP 2.3 (CDS3) product. This version is significantly more modular, so that alternative estimators and display systems may be added. By default, it displays a text bar showing activity, progress, percent completion, estimated time to completion, elapsed time, and speed in bytes of ldif per second. The display functions are modular so that we could add a running trace of numbers that a graphical front-end might read and transform into pretty animated pie charts, or potentially fancier display within these tools. The default (and only) supplied display system currently relies only on carriage return, with no external libraries needed or dependencies on terminal features. Estimators are modular as well, as the default linear estimator can be frustratingly poor for very large, poorly tuned databases with extremely non-linear load times. Progress is estimated by fstat()ing the ldif file and ftell()ing to see the position. As a result, ldif read from stdin automatically disables the progress bar. Files are available at: http://lirone.symas.net/lucca/progress-bar/ * Apply progress.patch * Copy progress.c into libraries/liblutil/progress.c * Copy progress.h into include/progress.h We should probably make this configurable via the commandline (on/off, as well as which display and estimator systems to use), but currently it is always on provided stderr is a tty and the ldif is a file. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: Most of system définitions may also be centralized without any used of Active Directory. Redundance notions are nevertheless necessary, also inside Linux-land ... ;-) Used of SRV rr is a good reponse, (in particular in case of large Intranet with many remote sites -islands in pacific- and poor communication ressources - satellite) but require to be performed in all client applications : nssldap, samba, ldap client tools for rsync/mail/DNS/proxy/supervision definitions, ... or openldap.

1 0

Re: (ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > This can be solved along with ITS#5792 relatively easily from within > entry_schema_check(), provided the structuralObjectClass attribute is not > indexed. Otherwise, things get a little bit more complicated. Fixed in HEAD, including the (unlikely) case structuralObjectClass is indexed. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.100.26) Submitted by: ando When the structural objectClass of an entry is modified, the corresponding structuralObjectClass attr is not modified accordingly. While addressing ITS#5792, I found out that the only other case that allows modification of the structural objectClass of an object, from "glue" to any other class using the manageDSAit control, results in an entry with the objectClass attribute set to the modified values, while the structuralObjectClass attribute remains "glue". This can be solved along with ITS#5792 relatively easily from within entry_schema_check(), provided the structuralObjectClass attribute is not indexed. Otherwise, things get a little bit more complicated. p.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > I'm not quite sure if it's a good idea to move ldap SRV lookup into > ldap_initialize(), since ldap:/// is also means "this LDAP server" in > referral objects and some slapd backends. Possibly some other syntax > should be used to say "use SRV record", e.g. "ldap://./", or another > function could work like ldap_initialize() but be more clever. Though > a > helper function which copies clients/tools/common.c:tool_conn_setup() > functionality could in any case be useful. Probably the cleanest solution is to use extensions. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: I don't see why. > On a site which has Windows and Active Directory, _ldap._tcp.domain > is normally required to refer to Active Directory. Thus if such > a site uses another LDAP server for their public LDAP data, they > can't _ldap._tcp.domain for that. Off course you should use distinct "domains" (better say dc-style naming contexts for MS AD and other OpenLDAP DSAs). But then it won't collide. Ciao, Michael.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by h.b.furuseth＠usit.uio.no 04 Feb '09

04 Feb '09

I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > Philippe.eychart(a)informatique.gov.pf wrote: > >> The "tool_conn_setup" function (in common.c) autorise the Url synthaxe >> "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server >> to request (not yet according the rfc 2782 - I've made dnssrv.c patch to >> implement priorities and I try to implement weight before submit this work). So, >> the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via >> "ldap_dn2domain" and "ldap_domain2hostlist" functions). > > This was done to allow testing client-side the DNS SRV feature. > >> Unfortunately, ldap_initialize() doesn't use these functions (but only >> ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages >> (like SAMBA) doesn't enjoy this capability : "passdb backend = >> ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition >> "_ldap._tcp.my.domain. IN SRV ..." >> >> Is there any reason for that ? Can we envisage to increase this possibility ? > > None that I'm aware of. Feel free to move that code from tools to > libldap. Patches are welcome, as usual. But please put a note into the accompanying man-page with a strong recommendation not to use it without further security mechs. I wouldn't configure Samba like this. (Similar problems like DNS lookups in Kerberos implementations for realm- and KDC-discovery.) I've implemented something like this in web2ldap but the SRV mech causes an user interaction on the UI. So the user has a vague chance to determine whether he's tricked to another DSA by DNS spoofing. Ciao, Michael.

1 0

Re: (ITS#5920) segfault in sockbuf.c
by hyc＠symas.com 04 Feb '09

04 Feb '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 01/30/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I link postfix against OpenLDAP libraries for its ldap lookups. With my > previous CVS checkout of RE24 (12/9/2008) there were no problems with this. > However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap > binary always segfaults: > This is likely related to the recent TLS changes in RE24. Yes, fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 03 Feb '09

03 Feb '09

Philippe.eychart(a)informatique.gov.pf wrote: > The "tool_conn_setup" function (in common.c) autorise the Url synthaxe > "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server > to request (not yet according the rfc 2782 - I've made dnssrv.c patch to > implement priorities and I try to implement weight before submit this work). So, > the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via > "ldap_dn2domain" and "ldap_domain2hostlist" functions). This was done to allow testing client-side the DNS SRV feature. > Unfortunately, ldap_initialize() doesn't use these functions (but only > ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages > (like SAMBA) doesn't enjoy this capability : "passdb backend = > ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition > "_ldap._tcp.my.domain. IN SRV ..." > > Is there any reason for that ? Can we envisage to increase this possibility ? None that I'm aware of. Feel free to move that code from tools to libldap. Patches are welcome, as usual. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5920) segfault in sockbuf.c
by quanah＠zimbra.com 03 Feb '09

03 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 01/30/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I link postfix against OpenLDAP libraries for its ldap lookups. With my previous CVS checkout of RE24 (12/9/2008) there were no problems with this. However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap binary always segfaults: Core was generated by `proxymap -t unix -u'. Program terminated with signal 11, Segmentation fault. [New process 19154] #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 168 sockbuf.c: No such file or directory. in sockbuf.c (gdb) bt #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 #1 0xb7e21eaf in ldap_pvt_tls_inplace (sb=0x807bfc0) at tls2.c:456 #2 0xb7e21f2c in ldap_tls_inplace (ld=0x807ce18) at tls2.c:475 #3 0xb7e22e84 in ldap_start_tls_s (ld=0x807ce18, serverctrls=0x0, clientctrls=0x0) at tls2.c:922 #4 0x080514aa in dict_ldap_connect (dict_ldap=0x807ca08) at dict_ldap.c:711 #5 0x0805257e in dict_ldap_lookup (dict=0x807ca08, name=0x807cbc8 "*") at dict_ldap.c:1123 #6 0x0804b590 in proxymap_service (client_stream=0x80799a8, unused_service=0xbf8cbf6d "proxymap", argv=0xbf8c9f24) at proxymap.c:354 #7 0x0804c5d2 in multi_server_execute (unused_event=1, context=0x80799a8 "") at multi_server.c:311 #8 0x0805b08d in event_loop (delay=-1) at events.c:1079 #9 0x0804bee0 in multi_server_main (argc=4, argv=0xbf8c9f14, service=0x804b1b0 <proxymap_service>) at multi_server.c:841 #10 0x0804add4 in main (argc=4, argv=0xbf8c9f14) at proxymap.c:651 (gdb) print *sb $2 = {sb_opts = {lbo_valid = 3, lbo_options = 0, lbo_debug = 0}, sb_iod = 0x0, sb_fd = -1, sb_max_incoming = 0, sb_trans_needs_read = 0, sb_trans_needs_write = 0} This is likely related to the recent TLS changes in RE24.

1 0

(ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 03 Feb '09

03 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C985F1.ABA10980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My first work ... -----Message d'origine----- De : openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Envoy=E9 : mardi 3 f=E9vrier 2009 11:02 =C0 : Philippe.eychart(a)informatique.gov.pf Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=3Dmy%2cdc=3Ddomaine) *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5919. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#5919) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#5919) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D5919 Please remember to retain your issue tracking number (ITS#5919) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. ------=_NextPart_000_002C_01C985F1.ABA10980 Content-Type: application/octet-stream; name="openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.patch" --- openldap-2.4.13/libraries/libldap/dnssrv.c 2009-01-23 = 20:56:43.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/dnssrv.c 2009-01-24 = 01:00:47.000000000 +0000=0A= # This patch file is derived from OpenLDAP Software. All of the = modifications to OpenLDAP Software represented in the following = patch(es) were developed by Philippe.EYCHART(a)mail.pf. I have not = assigned rights and/or interest in this work to any party.=0A= # this patch for more compliance with RFC 2782 : the result string is = sorted by priorities (SRV rr) in function ldap_domain2hostlist() ... not = yet according weight :-(=0A= @@ -223,10 +223,14 @@=0A= #endif=0A= if (len >=3D 0) {=0A= unsigned char *p;=0A= - char host[DNSBUFSIZ];=0A= + struct hostInfo {=0A= + char name[DNSBUFSIZ];=0A= + int priority;=0A= + /* int weight; */=0A= + u_short port;=0A= + } *host =3D NULL;=0A= + int curhost=3D0;=0A= int status;=0A= - u_short port;=0A= - /* int priority, weight; */=0A= =0A= /* Parse out query */=0A= p =3D reply;=0A= @@ -242,8 +246,15 @@=0A= p +=3D sizeof(HEADER);=0A= #endif=0A= =0A= - status =3D dn_expand(reply, reply + len, p, host, sizeof(host));=0A= + host =3D (struct hostInfo *) LDAP_MALLOC (sizeof (struct hostInfo));=0A= + if ( ! host ) {=0A= + rc =3D LDAP_NO_MEMORY;=0A= + goto out;=0A= + }=0A= +=0A= + status =3D dn_expand(reply, reply + len, p, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= p +=3D status;=0A= @@ -251,8 +262,9 @@=0A= =0A= while (p < reply + len) {=0A= int type, class, ttl, size;=0A= - status =3D dn_expand(reply, reply + len, p, host, sizeof(host));=0A= + status =3D dn_expand(reply, reply + len, p, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= p +=3D status;=0A= @@ -265,35 +277,61 @@=0A= size =3D (p[0] << 8) | p[1];=0A= p +=3D 2;=0A= if (type =3D=3D T_SRV) {=0A= - int buflen;=0A= - status =3D dn_expand(reply, reply + len, p + 6, host, sizeof(host));=0A= + status =3D dn_expand(reply, reply + len, p + 6, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= - /* ignore priority and weight for now */=0A= - /* priority =3D (p[0] << 8) | p[1]; */=0A= - /* weight =3D (p[2] << 8) | p[3]; */=0A= - port =3D (p[4] << 8) | p[5];=0A= + host[curhost].priority =3D (p[0] << 8) | p[1];=0A= + /* ignore weight for now */=0A= + /* host[curhost].weight =3D (p[2] << 8) | p[3]; */=0A= + host[curhost].port =3D (p[4] << 8) | p[5];=0A= =0A= - if ( port =3D=3D 0 || host[ 0 ] =3D=3D '\0' ) {=0A= + if ( host[curhost].port =3D=3D 0 || host[curhost].name[ 0 ] =3D=3D = '\0' ) {=0A= goto add_size;=0A= }=0A= =0A= - buflen =3D strlen(host) + STRLENOF(":65355 ");=0A= - hostlist =3D (char *) LDAP_REALLOC(hostlist, cur + buflen + 1);=0A= - if (hostlist =3D=3D NULL) {=0A= + curhost++;=0A= + host =3D (struct hostInfo *) LDAP_REALLOC (host, (curhost + 1) * = sizeof (struct hostInfo));=0A= + if ( ! host ) {=0A= rc =3D LDAP_NO_MEMORY;=0A= goto out;=0A= }=0A= - if (cur > 0) {=0A= - /* not first time around */=0A= - hostlist[cur++] =3D ' ';=0A= - }=0A= - cur +=3D sprintf(&hostlist[cur], "%s:%hd", host, port);=0A= +=0A= }=0A= add_size:;=0A= p +=3D size;=0A= }=0A= +=0A= + if ( host[0].name[ 0 ] ) {=0A= + int nbhosts=3Dcurhost, bull;=0A= + unsigned char buffer[sizeof (struct hostInfo)]; // :(=0A= +=0A= + // sort hosts by priorities ...=0A= + for (bull=3D(char)1; bull; ) { bull=3D(char)0;=0A= + for ( curhost=3D1; curhost < nbhosts; curhost++ ) {=0A= + if ( host[curhost].priority < host[curhost-1].priority ) {=0A= + bull =3D (char)1;=0A= + memcpy ( (struct hostInfo *)buffer, &host[curhost-1], sizeof = (struct hostInfo));=0A= + memcpy ( &host[curhost-1], &host[curhost], sizeof = (struct hostInfo));=0A= + memcpy ( &host[curhost], (struct hostInfo *)buffer, sizeof = (struct hostInfo));=0A= + } } }=0A= +=0A= + // do hostlist, string result ...=0A= + for ( cur=3Dcurhost=3D0; curhost < nbhosts; curhost++ ) {=0A= +=0A= + hostlist =3D (char *) LDAP_REALLOC (hostlist, cur + = strlen(host[curhost].name) + STRLENOF(":65535 ") + 1);=0A= + if (hostlist =3D=3D NULL) {=0A= + rc =3D LDAP_NO_MEMORY;=0A= + LDAP_FREE (host);=0A= + goto out;=0A= + }=0A= + cur +=3D sprintf(&hostlist[cur], "%s:%hd ", host[curhost].name, = host[curhost].port);=0A= +=0A= + } hostlist[cur] =3D '\0'; /* remove last ' ' */=0A= + }=0A= +=0A= + LDAP_FREE (host);=0A= }=0A= if (hostlist =3D=3D NULL) {=0A= /* No LDAP servers found in DNS. */=0A= ------=_NextPart_000_002C_01C985F1.ABA10980--

1 0

(ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by Philippe.eychart＠informatique.gov.pf 03 Feb '09

03 Feb '09

Full_Name: Philippe EYCHART Version: 2.4.13 OS: slack12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.82.141) Hi, The "tool_conn_setup" function (in common.c) autorise the Url synthaxe "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server to request (not yet according the rfc 2782 - I've made dnssrv.c patch to implement priorities and I try to implement weight before submit this work). So, the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via "ldap_dn2domain" and "ldap_domain2hostlist" functions). Unfortunately, ldap_initialize() doesn't use these functions (but only ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages (like SAMBA) doesn't enjoy this capability : "passdb backend = ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition "_ldap._tcp.my.domain. IN SRV ..." Is there any reason for that ? Can we envisage to increase this possibility ? Regards

1 0

(ITS#5918) slapacl(8c) badly worded
by quanah＠zimbra.com 03 Feb '09

03 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Slapacl is used to check the behavior of the slapd in verifying access to data according to ACLs, as specified in slapd.access(5). It opens the slapd.conf(5) configuration file, reads in the access directives, and then parses the attr list given on the command-line; if none is given, access to the entry pseudo-attribute is tested. Besides the bit about "of the slapd", the first sentence is rather awkward.

1 0

RE: (ITS#5912) Meta modify increment feature
by jorge.nevado＠ericsson.com 03 Feb '09

03 Feb '09

Hi We have tested the solution. It works OK. Greetings, Jorge. -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: jueves, 29 de enero de 2009 20:34 To: Jorge Nevado Cc: openldap-its(a)openldap.org Subject: Re: (ITS#5912) Meta modify increment feature Fixed in HEAD; please test. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5398) An account locked in a consumer is only unlocked when the password is changed two times
by hyc＠symas.com 02 Feb '09

02 Feb '09

ssnet(a)ua.es wrote: > Full_Name: maria saez > Version: 2.4.8 > OS: debian etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.145.230.2) > > > > An account locked in a consumer needs two password changes in the provider to be > unlocked. I'm unable to reproduce this behavior in current code. > The first time that we change the password in the provider the password change > is replicated in the consumer but the account remains locked. A single password change on the provider results in unlocking on the consumer for me. > > Can you help us? > We have openldap-2.4.7 and openldap-2.4.8 > > Is this situation normal? > > We have the following configuration: > > Provider > ------------------------------------------- > database bdb > suffix "dc=xx,dc=es" > rootdn "cn=config" > directory /xx/data > index entryCSN eq > index entryUUID eq > index objectClass eq > index mail eq > # define the replica provider for this database > # (last directives in database section) > overlay ppolicy > ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es" > ppolicy_use_lockout > > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > > Consumer > ---------------------------------------------------------------- > database bdb > suffix "dc=xx,dc=es" > rootdn "cn=config" > directory /xx/data > index entryCSN eq > index entryUUID eq > index objectClass eq > index mail eq > > overlay ppolicy > ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es" > ppolicy_use_lockout > > syncrepl rid=123 > provider=ldaps://xx.xx.es:xx/ > binddn="cn=config" > bindmethod=simple > credentials=xx > searchbase="dc=xx,dc=es" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > overlay syncprov > ------------------------------------------------------------------- > The policy we have defined: > > dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es > cn: Standard Policy > objectClass: top > objectClass: device > objectClass: pwdPolicy > pwdAttribute: 2.5.4.35 > pwdLockout: TRUE > pwdLockoutDuration: 0 > pwdInHistory: 6 > pwdCheckQuality: 2 > pwdExpireWarning: 10 > pwdMaxAge: 120 > pwdMinLength: 5 > pwdGraceAuthnLimit: 3 > pwdAllowUserChange: TRUE > pwdMustChange: TRUE > pwdMaxFailure: 3 > pwdFailureCountInterval: 120 > pwdSafeModify: TRUE > pwdMinAge: 120 > ------------------------------------------------------------- > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5917) slapd crashes with assertion failed and SIGABRT
by guido＠keamera.org 02 Feb '09

02 Feb '09

Full_Name: Guido Landi Version: 2.3.43 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.246.126.62) Hello, I'm using OpenLDAP 2.3.43 with ldap backend as a proxy to Active Directory for users autentication on linux(gentoo). OpenLDAP keep on crashing while testing it through the nss_ldap module using the "id" unix command. It often crashes for an assertion failed(that i can easily reproduce) but sometimes with a segmentation fault or a glibc error related to free()(heap corruption?). I found as a workaround that if I set the maximum threads number to 2 it works just fine. I'm using glibc-2.6.1 with NPTL and I have compiled OpenLDAP with gcc-4.1.2 and 3.4.6. Here is my slapd.conf, ldap.conf(used by the nss_ldap module) and some backtraces. #### slapd.conf #### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/local.schema modulepath /usr/lib/openldap/openldap moduleload rwm overlay rwm rwm-map attribute cn sAMAccountName database ldap suffix "dc=mydomain,dc=it" rootdn "ou=CV Utenti,dc=mydomain,dc=it" lastmod off uri ldaps://mydc.mydomain.it/ rebind-as-user chase-referrals YES index objectClass eq,sub index uidNumber,gidNumber eq index memberUid eq index sAMAccountName eq,subinitial #concurrency 0 #threads 2 TLSCACertificateFile /etc/openldap/ssl/cacert.pem TLSCertificateFile /etc/openldap/ssl/server.pem TLSCertificateKeyFile /etc/openldap/ssl/server.key TLSCipherSuite ALL TLSCRLCheck none TLSReqCert none TLSVerifyClient never #### ldap.conf #### uri ldaps://ldap-proxy.mydomain.it port 636 base OU=mygroup,dc=mydomain,dc=it scope sub binddn CN=myaccount,DC=mydomain,DC=it bindpw password bind_policy soft ldap_version 3 #nss_schema rfc2307bis #debug 1000 REFERRALS no pam_login_attribute cn pam_filter objectClass=user pam_password ad pam_groupdn CN=UNIX Admins,DC=mydomain,DC=it #pam_groupdn CN=UNIX-USERS,DC=mydomain,DC=it pam_member_attribute member nss_base_passwd OU=Users,DC=mydomain,DC=it nss_base_shadow OU=Users,DC=mydomain,DC=it nss_base_group DC=mydomain,DC=it?(objectClass=group) nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid uid nss_map_attribute uniqueMember member #nss_map_attribute uniqueMember msSFU30PosixMemberOf nss_map_attribute userPassword unixUserPassword nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute loginShell loginShell nss_map_attribute gecos name nss_map_objectclass posixGroup group nss_reconnect_tries 4 nss_reconnect_sleeptime 1 #nss_reconnect_maxsleeptime 16 nss_reconnect_maxconntries 6 #nss_initgroups backlink #nss_max_group_depth 100 ssl yes #### backtraces #### put_simple_filter: "member=cn=certsvc_dcom_access,cn=users,dc=mydomain,dc=it" ldap_send_initial_request ldap_send_server_request ldap_back_retry: conn 0x826a628 refcnt=2 unable to retry. slapd: bind.c:157: ldap_back_conn_delete: Assertion `!(*(&((lc))->lc_lcflags) & (((0x00000020U))))' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0xb722eb90 (LWP 25435)] 0xb7b711c7 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b711c7 in raise () from /lib/libc.so.6 #1 0xb7b72998 in abort () from /lib/libc.so.6 #2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6 #3 0x081147d8 in ldap_back_conn_delete () #4 0x081150e1 in ?? () #5 0x08217930 in ?? () #6 0x0826a628 in ?? () #7 0xb722cde8 in ?? () #8 0x081166f5 in ldap_back_release_conn_lock () Backtrace stopped: frame did not save the PC ber_flush: 104 bytes to sd 11 ldap_result ld 0x825dfb0 msgid 5 ldap_chkResponseList ld 0x825dfb0 msgid 5 all 0 ldap_chkResponseList returns ld 0x825dfb0 NULL Program received signal SIGABRT, Aborted. [Switching to Thread 0xb692db90 (LWP 25728)] 0xb7b711c7 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b711c7 in raise () from /lib/libc.so.6 #1 0xb7b72998 in abort () from /lib/libc.so.6 #2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6 #3 0xb7f8da8c in ber_flush () from /usr/lib/liblber-2.3.so.0 #4 0xb7fb9005 in ldap_int_flush_request () from /usr/lib/libldap_r-2.3.so.0 #5 0xb7fb94da in ldap_send_server_request () from /usr/lib/libldap_r-2.3.so.0 #6 0xb7fb8fa9 in ldap_send_initial_request () from /usr/lib/libldap_r-2.3.so.0 #7 0xb7fa8188 in ldap_search_ext () from /usr/lib/libldap_r-2.3.so.0 #8 0x080f6eb0 in ldap_back_search () #9 0x08079a9f in fe_op_search () #10 0x080df1fa in overlay_op_walk () #11 0x080df3b1 in ?? () #12 0x082968d0 in ?? () #13 0xb692d18c in ?? () #14 0x00000002 in ?? () #15 0x08217190 in ?? () #16 0x00000000 in ?? () put_simple_filter: "member=cn=unix admins,ou=cv acl,dc=mydomain,dc=it" ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: slapd: io.c:210: ber_flush: Assertion `( (sb)->sb_opts.lbo_valid == 0x3 )' failed. ** ld 0xb560f238 Response Queue: Empty ldap_chkResponseList ld 0xb560f238 msgid 5 all 0 ldap_chkResponseList returns ld 0xb560f238 NULL ldap_int_select Program received signal SIGABRT, Aborted. [Switching to Thread 0xb722eb90 (LWP 29674)] ---Type <return> to continue, or q <return> to quit--- 0xb7b711c7 in raise () from /lib/libc.so.6 (gdb) bt #0 0xb7b711c7 in raise () from /lib/libc.so.6 #1 0xb7b72998 in abort () from /lib/libc.so.6 #2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6 #3 0xb7f8da70 in ber_flush () from /usr/lib/liblber-2.3.so.0 #4 0xb7fb9005 in ldap_int_flush_request () from /usr/lib/libldap_r-2.3.so.0 #5 0xb7fb94da in ldap_send_server_request () from /usr/lib/libldap_r-2.3.so.0 #6 0xb7fb8fa9 in ldap_send_initial_request () from /usr/lib/libldap_r-2.3.so.0 #7 0xb7fa8188 in ldap_search_ext () from /usr/lib/libldap_r-2.3.so.0 #8 0x080f6e10 in ldap_back_search () #9 0x08079a97 in fe_op_search () #10 0x080df15a in overlay_op_walk () #11 0x080df311 in over_op_func () #12 0x080df395 in over_op_search () #13 0x08079549 in do_search () #14 0x0807677a in connection_operation () #15 0xb7fa30a9 in ldap_int_thread_pool_wrapper () from /usr/lib/libldap_r-2.3.so.0 #16 0xb7e5a013 in start_thread () from /lib/libpthread.so.0 #17 0xb7c0948e in clone () from /lib/libc.so.6

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 02 Feb '09

02 Feb '09

michael(a)stroeder.com wrote: > Hmm, maybe I missed something in this discussion and about the usage of > client controls. > > But I'd vote for another function which provides a complete set of > arguments for sending search requests. So if ldap_search_ext is > considered incomplete regarding alias dereferencing I'd vote for > introducing ldap_search_ext2 (or whatever name) with an additional argument. Well, that's ldap_int_search*(); let's vote for the "public" name. As I said, I think it makes sense, since alias dereferencing has always been explicitly required in the request. OTOH, I have no objection to using a client-side control, as it wouldn't add too much complexity (well, it'd require to parse a list of strings with a worst-case of N * M, with N: number of known client controls; M: client controls passed to the request), and it would pave the way for client controls in libldap :) I see Hallvard already has a request for another one. One consideration: I'm not overlooking the value of not changing the API too often; also, I fear client-side controls could be another way to wind up with revitalizing the old API instead of designing a new one - if anyone ever seriously considered the opportunity to design it. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by h.b.furuseth＠usit.uio.no 01 Feb '09

01 Feb '09

michael(a)stroeder.com writes: > But I'd vote for another function which provides a complete set of > arguments for sending search requests. So if ldap_search_ext is > considered incomplete regarding alias dereferencing I'd vote for > introducing ldap_search_ext2 (or whatever name) with an additional > argument. Yes, the missing aliases argument is an API design bug. The API almost but not quite has functions that match the protocol messages. If we are going to export yet another search function, I'd like to see another feature added as well: A way to pass the BER form of a filter to the search function. And some helpers to build the BER form, and to parse it back into the string form of a filter. Filters are complex enough that it can be a pain to deal with the string form and its quoting at times. Of course, that one could be a client control too - e.g. combined with passing NULL as the filter... -- Hallvard

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by michael＠stroeder.com 01 Feb '09

01 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> ando(a)sys-net.it writes: >>>>> Proxy backends use ldap_set_option(3) to set alias >>>>> dereferencing when requested by a search operation (and do >>>>> not clean it up afterwards, as far as I can tell). Since >>>>> LDAP handlers are pooled and reused, this behavior is >>>>> inherently broken. >> [..] >> I recall complaining about this deficiency in the API back in 1998, >> when I >> first wrote back-ldap. Alias deref has always been a part of the >> protocol, but >> it has always been missing from the API. Perplexing... > > Yes, of course, one might use the client control mechanism to add an > ability to set deref on a call by call basis instead of introducing > yet another function. Hmm, maybe I missed something in this discussion and about the usage of client controls. But I'd vote for another function which provides a complete set of arguments for sending search requests. So if ldap_search_ext is considered incomplete regarding alias dereferencing I'd vote for introducing ldap_search_ext2 (or whatever name) with an additional argument. Ciao, Michael.

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by Kurt＠OpenLDAP.org 31 Jan '09

31 Jan '09

On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> h.b.furuseth(a)usit.uio.no wrote: >>> ando(a)sys-net.it writes: >>>> Proxy backends use ldap_set_option(3) to set alias dereferencing >>>> when >>>> requested by a search operation (and do not clean it up >>>> afterwards, as >>>> far as I can tell). Since LDAP handlers are pooled and reused, >>>> this >>>> behavior is inherently broken. >>> I note you committed this with an ldap_int_* interface. >> >> Yes, that's because I needed it internally. > > I think ldap_pvt would make more sense. _int_ means internal to the library. _pvt_ means private to OpenLDAP Software. > I recall complaining about this deficiency in the API back in 1998, > when I > first wrote back-ldap. Alias deref has always been a part of the > protocol, but > it has always been missing from the API. Perplexing... Yes, of course, one might use the client control mechanism to add an ability to set deref on a call by call basis instead of introducing yet another function. > > >>> But it could >>> be useful outside OpenLDAP code too. >> >> Yes, that will probably be the next step. But to make it publicly >> available I should have called it ldap_search_ext2, or >> ldap_search_really_ext or something like that. I think we need to >> make >> it public based on demand and after a ballot on the name. > > Ok. > >>> Seems to me this is what client-side controls are for. Extending >>> the >>> client-side functionality without needing a new API. >> >> Well, since alias dereferencing is part of the protocol, I think >> using a >> client-side control is sort of an overkill :) > > Agreed. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by hyc＠symas.com 31 Jan '09

31 Jan '09

ando(a)sys-net.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> ando(a)sys-net.it writes: >>> Proxy backends use ldap_set_option(3) to set alias dereferencing when >>> requested by a search operation (and do not clean it up afterwards, as >>> far as I can tell). Since LDAP handlers are pooled and reused, this >>> behavior is inherently broken. >> I note you committed this with an ldap_int_* interface. > > Yes, that's because I needed it internally. I think ldap_pvt would make more sense. I recall complaining about this deficiency in the API back in 1998, when I first wrote back-ldap. Alias deref has always been a part of the protocol, but it has always been missing from the API. Perplexing... >> But it could >> be useful outside OpenLDAP code too. > > Yes, that will probably be the next step. But to make it publicly > available I should have called it ldap_search_ext2, or > ldap_search_really_ext or something like that. I think we need to make > it public based on demand and after a ballot on the name. Ok. >> Seems to me this is what client-side controls are for. Extending the >> client-side functionality without needing a new API. > > Well, since alias dereferencing is part of the protocol, I think using a > client-side control is sort of an overkill :) Agreed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 31 Jan '09

31 Jan '09

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> Proxy backends use ldap_set_option(3) to set alias dereferencing when >> requested by a search operation (and do not clean it up afterwards, as >> far as I can tell). Since LDAP handlers are pooled and reused, this >> behavior is inherently broken. > > I note you committed this with an ldap_int_* interface. Yes, that's because I needed it internally. > But it could > be useful outside OpenLDAP code too. Yes, that will probably be the next step. But to make it publicly available I should have called it ldap_search_ext2, or ldap_search_really_ext or something like that. I think we need to make it public based on demand and after a ballot on the name. > Seems to me this is what client-side controls are for. Extending the > client-side functionality without needing a new API. Well, since alias dereferencing is part of the protocol, I think using a client-side control is sort of an overkill :) 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5916) Allow alias dereferencing in search C API
by h.b.furuseth＠usit.uio.no 31 Jan '09

31 Jan '09

ando(a)sys-net.it writes: > Proxy backends use ldap_set_option(3) to set alias dereferencing when > requested by a search operation (and do not clean it up afterwards, as > far as I can tell). Since LDAP handlers are pooled and reused, this > behavior is inherently broken. I note you committed this with an ldap_int_* interface. But it could be useful outside OpenLDAP code too. Seems to me this is what client-side controls are for. Extending the client-side functionality without needing a new API. -- Hallvard

1 0

(ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it 31 Jan '09

31 Jan '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Proxy backends use ldap_set_option(3) to set alias dereferencing when requested by a search operation (and do not clean it up afterwards, as far as I can tell). Since LDAP handlers are pooled and reused, this behavior is inherently broken. The only reason for doing this is that the C API does not allow to explicitly define alias dereferencing when sending a search request. This is a feature request for an internal API extension (ldap_int_search*) that allows alias dereferencing. The current C API (essentially, ldap_search_ext*) should wrap the new one, until promoted to public. A patch is coming. p.

1 0

Re: (ITS#5889) [PATCH] Sending dereference field when retrying connection in meta backend
by ando＠sys-net.it 31 Jan '09

31 Jan '09

jorge.perez(a)adaptia.net wrote: > When we have two slapds with a established meta connection between them and the > connection is reset, for example by a router, the next search query will always > be send with never in dereferencing. > > Steps to reproduce: > > - Established a meta connection between 2 slapds > - Reset the connection, for example with cutter > - Send a search dereferencing with something different to never. > - See the results are no dereferenced. Actually, I was reviewing this fix, and it seems that the code for alias dereferencing is inherently broken, essentially because the (C) API for alias dereferencing is broken. In fact, back-ldap and back-meta reuse and pool connections, so setting this parameter using ldap_set_option() will actually affect all (search) operations occurring simultaneously in an unprotected manner. I think this needs to be fixed. The simplest (and my favorite) solution would be to have back-ldap and back-meta discontinue aliasing support. Another option, which I do not consider particularly viable, is to separately pool connections with different alias dereferencing strategies Finally (my second favorite option) is to add a new C API for ldap_search* operations that allows to explicitly set the alias dereferencing parameter. This API does not need to be public, since it is mostly useful inside the proxy backends. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 30 Jan '09

30 Jan '09

Ok, but we should mention this somewhere like in the admin guide perhaps. ------Original Message------ From: Quanah Gibson-Mount Sender: To: Gavin Henry To: openldap-its(a)openldap.org Subject: Re: slapo-unique man page misleading (ITS#5908) Sent: 30 Jan 2009 19:13 --On Friday, January 30, 2009 7:08 PM +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > Ok, so this should be in the man page. Where else should this be listed > that affects other overlays? Eh, I'm not sure it should be in the man page. The point is, if you ever want guaranteed atomic writes, you have to use slapo-accesslog to serialize them. That's an issue that affects other LDAP servers as well. AS Pierangelo said: There is no guarantee of DSA-wide or even database-wide atomicity in write operations, including internal ones. This was never even intended to be in place. This is a known design limitation not only of slapo-unique, but also of slapd (and, I'd say, of LDAP itself). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 30 Jan '09

30 Jan '09

--On Friday, January 30, 2009 7:08 PM +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > Ok, so this should be in the man page. Where else should this be listed > that affects other overlays? Eh, I'm not sure it should be in the man page. The point is, if you ever want guaranteed atomic writes, you have to use slapo-accesslog to serialize them. That's an issue that affects other LDAP servers as well. AS Pierangelo said: There is no guarantee of DSA-wide or even database-wide atomicity in write operations, including internal ones. This was never even intended to be in place. This is a known design limitation not only of slapo-unique, but also of slapd (and, I'd say, of LDAP itself). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 30 Jan '09

30 Jan '09

Ok, so this should be in the man page. Where else should this be listed that affects other overlays? ------Original Message------ From: Quanah Gibson-Mount Sender: To: Gavin Henry To: openldap-its(a)openldap.org Subject: Re: slapo-unique man page misleading (ITS#5908) Sent: 30 Jan 2009 19:04 --On Thursday, January 29, 2009 3:48 PM +0000 ghenry(a)suretecsystems.com wrote: >> Huh? slapo-unique only does internal searches. The writes are all user >> ops, >> and accesslog will serialize all of them. > > So, where does this leave us? If you want guaranteed atomic writes, use slapo-accesslog on your master to serialize them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 30 Jan '09

30 Jan '09

--On Thursday, January 29, 2009 3:48 PM +0000 ghenry(a)suretecsystems.com wrote: >> Huh? slapo-unique only does internal searches. The writes are all user >> ops, >> and accesslog will serialize all of them. > > So, where does this leave us? If you want guaranteed atomic writes, use slapo-accesslog on your master to serialize them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5898) test044 abort with back-ldif
by ando＠sys-net.it 30 Jan '09

30 Jan '09

Hallvard B Furuseth wrote: > Pierangelo Masarati writes: >> I don't know how useful it would be to have back-ldif directly implement >> compare, as soon as one only uses it for back-config and not for a real >> storage with stacked overlays (however I note that back-config needs at >> least to nicely interoperate with one overlay: slapo-syncprov). > > Syncprov does use compare, and back-config doesn't provide it. > I don't know if that's a problem. In any case, the fallthru compare works fine, except for those cases that require overlay manipulation of the call before actually comparing data. This is what happens to slapo-dynlist: compare gets straight to back-ldif without prior generating the dynamic listing. > I forgot, back-config doesn't fall back to back-ldif for reads. > So I guess it's just as well to leave back-ldif as it is. :) 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 30 Jan '09

30 Jan '09

Pierangelo Masarati writes: > I don't know how useful it would be to have back-ldif directly implement > compare, as soon as one only uses it for back-config and not for a real > storage with stacked overlays (however I note that back-config needs at > least to nicely interoperate with one overlay: slapo-syncprov). Syncprov does use compare, and back-config doesn't provide it. I don't know if that's a problem. I forgot, back-config doesn't fall back to back-ldif for reads. So I guess it's just as well to leave back-ldif as it is. -- Hallvard

1 0

Re: (ITS#5898) test044 abort with back-ldif
by ando＠sys-net.it 30 Jan '09

30 Jan '09

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> Probably related; in any case, misused in slapo-dynlist(5). Now slapd >> doesn't assert() any more. However, the test fails because back-ldif >> does not implement compare, and falls back to be_fetch(), which does not >> trigger dynlist expansion. > > Yes, the "compare without help from the backend" functionality has been > broken for years - which I presume means it's hard to fix, or needs a > different design. > > Should we patch it over by adding Compare to back-ldif and whatever else > lacks it? Or is this a "fix coming Real Soon Now" issue so it's good > to have this reminder from a backend which doesn't provide Compare? Not sure whether it's about to come sooner or later, but the issue is always about be_fetch, aka bi_entry_get_rw() whose design Is Broken (TM) (actually, it broke when overlays came into play). I don't know how useful it would be to have back-ldif directly implement compare, as soon as one only uses it for back-config and not for a real storage with stacked overlays (however I note that back-config needs at least to nicely interoperate with one overlay: slapo-syncprov). 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5898) test044 abort with back-ldif
by h.b.furuseth＠usit.uio.no 30 Jan '09

30 Jan '09

Pierangelo Masarati writes: > Probably related; in any case, misused in slapo-dynlist(5). Now slapd > doesn't assert() any more. However, the test fails because back-ldif > does not implement compare, and falls back to be_fetch(), which does not > trigger dynlist expansion. Yes, the "compare without help from the backend" functionality has been broken for years - which I presume means it's hard to fix, or needs a different design. Should we patch it over by adding Compare to back-ldif and whatever else lacks it? Or is this a "fix coming Real Soon Now" issue so it's good to have this reminder from a backend which doesn't provide Compare? -- Hallvard

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by h.b.furuseth＠usit.uio.no 30 Jan '09

30 Jan '09

hyc(a)symas.com writes: > I guess for this release (and probably for 2.5) we're just going to > have to document both, as cumbersome as that will be. When we get to > to 2.6/3.0 and drop support for slapd.conf we'll have to come back > thru again and delete the slapd.conf references from all the > docs. Unless anyone has a better idea... I'm not sure I see the problem, except that Someone(TM) must do the work... For each configuration keyword, use two headers in the manpages: Both the slapd.conf syntax and the cn=config syntax. Explain at the beginning of slapd.conf.5 or slapd-config.5. We'll be deleting most of the other one, since they are mostly duplicates. Other manpages need just one-line reminder for explanation. There'll be exceptions that spell things out too differently, or use slightly different parameters in slapd.conf and cn=config. Keep them in just slapd.conf-syntax, and add a separate cn=config attribute description below. Likely that'll only need to explain the difference. Don't go trough literary contortions to fit them both into the same description. Some of these will likely be things that could use some cleanup in the code anyway, bringing the two config formats in sync. Take a random sample of the slapd.conf-syntax example sections and replace with their cn=config equivalent. Ensure all example sections say either "slapd.conf example" or "cn=config example". slapd.conf.5 and slapd-config.5 themselves will need sections about how they work as interfaces to configuration, separate from the configuration keywords/attributes themselves. Since we are moving towards cn=config, I suppose it's that one which should keep the actual keyword/attribute descriptions. Or they could move to a third file. -- Hallvard

1 0

Re: (ITS#5898) test044 abort with back-ldif
by ando＠sys-net.it 29 Jan '09

29 Jan '09

h.b.furuseth(a)usit.uio.no wrote: >> When using the back-ldif backend with test044, it aborts: > > Probably ITS#5340. Probably related; in any case, misused in slapo-dynlist(5). Now slapd doesn't assert() any more. However, the test fails because back-ldif does not implement compare, and falls back to be_fetch(), which does not trigger dynlist expansion. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5913) supportedSASLMechanisms EXTERNAL not Work
by ando＠sys-net.it 29 Jan '09

29 Jan '09

jarbas.peixoto(a)gmail.com wrote: > Full_Name: Jarbas Peixoto Junior > Version: 2.4.11 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.152.43.195) > > > I have two servers: > > * Server A: Debian Etch - Works Fine > > * Server B: Debian Lenny - Do not Works supportedSASLMechanisms EXTERNAL > > In Server A I have: > > # ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms > -ZZ > ldap_initialize( ldap://server-Etch ) > SASL/EXTERNAL authentication started > SASL username: emailAddress=jarbas.peixoto(a)previdencia.gov.br,CN=jarbas.peixoto,OU=DATAPREV,O=Previdencia > Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR > SASL SSF: 0 > filter: (objectclass=*) > requesting: supportedSASLMechanisms > dn: > supportedSASLMechanisms: PLAIN > supportedSASLMechanisms: DIGEST-MD5 > supportedSASLMechanisms: LOGIN > supportedSASLMechanisms: NTLM > supportedSASLMechanisms: CRAM-MD5 > supportedSASLMechanisms: EXTERNAL > > In Server B I have: > > # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base > supportedSASLMechanisms -ZZ > ldap_initialize( ldap://server-Lenny:389/??base ) > ldap_start_tls: Connect error (-11 ^^^ start TLS is failing. There is no evidence of a bug in the software; likely either the client or the server's TLS is misconfigured. Please direct software usage questions to the openldap-software list. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5915) Some man pages still only talk about slapd.conf
by hyc＠symas.com 29 Jan '09

29 Jan '09

ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.41.236.102) > Submitted by: ghenry > > > Some discussion will be needed on the best way to talk about config. We don't > want to list everything twice for both formats...lots of slapd.conf written > throughout most (5/8) man pages. I guess for this release (and probably for 2.5) we're just going to have to document both, as cumbersome as that will be. When we get to to 2.6/3.0 and drop support for slapd.conf we'll have to come back thru again and delete the slapd.conf references from all the docs. Unless anyone has a better idea... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5915) Some man pages still only talk about slapd.conf
by ghenry＠OpenLDAP.org 29 Jan '09

29 Jan '09

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.41.236.102) Submitted by: ghenry Some discussion will be needed on the best way to talk about config. We don't want to list everything twice for both formats...lots of slapd.conf written throughout most (5/8) man pages. Thanks.

1 0

(ITS#5914) Update all man pages that only "SEE ALSO slapd.conf(5)" to list slapd-config(5)
by ghenry＠OpenLDAP.org 29 Jan '09

29 Jan '09

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.41.164.91) Submitted by: ghenry Will commit shortly.

1 0

(ITS#5913) supportedSASLMechanisms EXTERNAL not Work
by jarbas.peixoto＠gmail.com 29 Jan '09

29 Jan '09

Full_Name: Jarbas Peixoto Junior Version: 2.4.11 OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.152.43.195) I have two servers: * Server A: Debian Etch - Works Fine * Server B: Debian Lenny - Do not Works supportedSASLMechanisms EXTERNAL In Server A I have: # ldapsearch -v -H ldap://server-Etch -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Etch ) SASL/EXTERNAL authentication started SASL username: emailAddress=jarbas.peixoto(a)previdencia.gov.br,CN=jarbas.peixoto,OU=DATAPREV,O=Previdencia Social,L=Campo Grande,ST=Mato Grosso do Sul,C=BR SASL SSF: 0 filter: (objectclass=*) requesting: supportedSASLMechanisms dn: supportedSASLMechanisms: PLAIN supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: LOGIN supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: EXTERNAL In Server B I have: # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ ldap_initialize( ldap://server-Lenny:389/??base ) ldap_start_tls: Connect error (-11 # ldapsearch -v -H ldap://server-Lenny -b "" -LLL -s base supportedSASLMechanisms -ZZ -d 1 ldap_url_parse_ext(ldap://server-Lenny) ldap_create ldap_url_parse_ext(ldap://server-Lenny:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-Lenny:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.82.0.234:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x9d73280 msgid 1 wait4msg ld 0x9d73280 msgid 1 (infinite timeout) wait4msg continue ld 0x9d73280 msgid 1 all 1 ** ld 0x9d73280 Connections: * host: www-mmldap port: 389 (default) refcnt: 2 status: Connected last used: Thu Jan 29 18:17:22 2009 ** ld 0x9d73280 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9d73280 request count 1 (abandoned 0) ** ld 0x9d73280 Response Queue: Empty ld 0x9d73280 response count 0 ldap_chkResponseList ld 0x9d73280 msgid 1 all 1 ldap_chkResponseList returns ld 0x9d73280 NULL ldap_int_select read1msg: ld 0x9d73280 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x9d73280 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x9d73280 0 new referrals read1msg: mark request completed, ld 0x9d73280 msgid 1 request done: ld 0x9d73280 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree ldap_err2string ldap_start_tls: Connect error (-11) In the /var/log/syslog I have: Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 ACCEPT from IP=10.82.0.234:50441 (IP=0.0.0.0:389) Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 STARTTLS Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 op=0 RESULT oid= err=0 text= Jan 29 18:17:22 server-Lenny slapd[12945]: conn=99 fd=21 closed (TLS negotiation failure) This is very important for use openldap with user certificates. Anybody have a help for me? Tanks!

1 0

Re: (ITS#5912) Meta modify increment feature
by ando＠sys-net.it 29 Jan '09

29 Jan '09

Fixed in HEAD; please test. Thanks, 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5912) Meta modify increment feature
by ando＠sys-net.it 29 Jan '09

29 Jan '09

jorge.nevado(a)ericsson.com wrote: > Full_Name: Jorge Nevado > Version: 2.4.12 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > > > We are trying to send an increment modify operation on an entry. This request > has to be proxied using the meta to a backend we have developed. When we send > the operation directly to the backend it works without any problem. But when we > have to pass through the meta backend we receive the following error: > > ldapmodify -x -H ldap://localhost:9090 -D "cn=manager,dc=operator,dc=com" -w > manager -f ldif/nam.ldif modifying entry > "appName=CsPs,subsId=10000000000000000000000000000000,ou=subscribers,dc=operator,dc=com" > ldap_modify: Server is unwilling to perform (53) > additional info: modify/increment not supported in context > > However we see that the operation has been performed and the attribute > incremented. The same problem occurs in back-ldap. The frontend is sending the error message, but it allows the operation to continue, and eventually it succeeds. I'm fixing it. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 29 Jan '09

29 Jan '09

----- hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: > > quanah(a)zimbra.com wrote: > >> --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com > wrote: > >> > >>> Hi, > >>> Please see this thread for background info: > >>> > http://www.openldap.org/lists/openldap-software/200901/msg00112.html > >>> > >>> To me, something is either guaranteed or not. And I think > "enforce" means > >>> something that is guaranteed. In this case, the uniqueness is not > >>> guaranteed, therefore it is not enforced. > >> Set up slapo-accesslog on your master. Then uniqueness is > guaranteed. > > > > Are you sure about this? I didn't look in detail to the code, so I > > can't tell whether serializing writes that way will cause the > desired > > behavior, since slapo-unique is using internal writes. > > Huh? slapo-unique only does internal searches. The writes are all user > ops, > and accesslog will serialize all of them. So, where does this leave us? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by h.b.furuseth＠usit.uio.no 29 Jan '09

29 Jan '09

ulrich.windl(a)rz.uni-regensburg.de writes: > To make a long discussion short, you cold add a comment regarding the > use of "8". The 8 should be CHAR_BIT. /* Maximum tree depth this host's address space could support */ #define MAX_TREE_DEPTH (sizeof(void *) * CHAR_BIT) -- Hallvard

1 0

(ITS#5912) Meta modify increment feature
by jorge.nevado＠ericsson.com 29 Jan '09

29 Jan '09

Full_Name: Jorge Nevado Version: 2.4.12 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) We are trying to send an increment modify operation on an entry. This request has to be proxied using the meta to a backend we have developed. When we send the operation directly to the backend it works without any problem. But when we have to pass through the meta backend we receive the following error: ldapmodify -x -H ldap://localhost:9090 -D "cn=manager,dc=operator,dc=com" -w manager -f ldif/nam.ldif modifying entry "appName=CsPs,subsId=10000000000000000000000000000000,ou=subscribers,dc=operator,dc=com" ldap_modify: Server is unwilling to perform (53) additional info: modify/increment not supported in context However we see that the operation has been performed and the attribute incremented. The request we are sending is the following: dn: msisdn=910000000000000,dc=msisdn,ou=identities,dc=operator,dc=com changetype:modify increment: usageCnt usageCnt:4

1 0

Re: slapo-unique man page misleading (ITS#5908)
by hyc＠symas.com 29 Jan '09

29 Jan '09

ando(a)sys-net.it wrote: > quanah(a)zimbra.com wrote: >> --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: >> >>> Hi, >>> Please see this thread for background info: >>> http://www.openldap.org/lists/openldap-software/200901/msg00112.html >>> >>> To me, something is either guaranteed or not. And I think "enforce" means >>> something that is guaranteed. In this case, the uniqueness is not >>> guaranteed, therefore it is not enforced. >> Set up slapo-accesslog on your master. Then uniqueness is guaranteed. > > Are you sure about this? I didn't look in detail to the code, so I > can't tell whether serializing writes that way will cause the desired > behavior, since slapo-unique is using internal writes. Huh? slapo-unique only does internal searches. The writes are all user ops, and accesslog will serialize all of them. > As Gavin says,. > if this is the case then it should be at least documented, and not only > in slapo-unique, but also for any overlay/module that does internal writes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ando＠sys-net.it 29 Jan '09

29 Jan '09

quanah(a)zimbra.com wrote: > --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: > >> Hi, >> Please see this thread for background info: >> http://www.openldap.org/lists/openldap-software/200901/msg00112.html >> >> To me, something is either guaranteed or not. And I think "enforce" means >> something that is guaranteed. In this case, the uniqueness is not >> guaranteed, therefore it is not enforced. > > Set up slapo-accesslog on your master. Then uniqueness is guaranteed. Are you sure about this? I didn't look in detail to the code, so I can't tell whether serializing writes that way will cause the desired behavior, since slapo-unique is using internal writes. As Gavin says,. if this is the case then it should be at least documented, and not only in slapo-unique, but also for any overlay/module that does internal writes. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: slapo-unique man page misleading (ITS#5908)
by ghenry＠suretecsystems.com 29 Jan '09

29 Jan '09

----- quanah(a)zimbra.com wrote: > --On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: > > > Hi, > > Please see this thread for background info: > > > http://www.openldap.org/lists/openldap-software/200901/msg00112.html > > > > To me, something is either guaranteed or not. And I think "enforce" > means > > something that is guaranteed. In this case, the uniqueness is not > > guaranteed, therefore it is not enforced. > > Set up slapo-accesslog on your master. Then uniqueness is > guaranteed. We don't document this requirement in slapo-unique.5 though. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by ulrich.windl＠rz.uni-regensburg.de 29 Jan '09

29 Jan '09

On 29 Jan 2009 at 2:21, Howard Chu wrote: > Hardcoding arbitrary limits in portable code is stupid. ("No one will ever > need more than 640K...") What may seem (im)practical to you today may be > commonplace tomorrow. This code will be maintenance-free no matter what class > of machine it's built on, forever. That's *excellent* programming. Howard, my proposals were related to the virtual address space, and the specific value for 64 bit was assuming that no more than 800GB of tree nodes are allocated. Your settings relate the depth of the tree to the width of a pointer multiplied by a hardcoded value without further explanation. > > There is no bug here, this ITS is closed. To make a long discussion short, you cold add a comment regarding the use of "8". Regards, Ulrich > > Ulrich Windl wrote: > > On 28 Jan 2009 at 13:06, Howard Chu wrote: > > > >> Ulrich.Windl(a)rz.uni-regensburg.de wrote: > >>> Full_Name: Ulrich Windl > >>> Version: 2.4.11 > >>> OS: Linux > >>> URL: ftp://ftp.openldap.org/incoming/ > >>> Submission from: (NULL) (132.199.156.178) > >>> > >>> > >>> Looking for a threaded AVL tree implementation that is supposed to work, I found > >>> libraries/liblutil/tavl.c in openLDAP. I'm no expert on threaded AVL trees, but > >>> there's thing that worries me: > >>> tavl_delete uses two stacks (pptr, pdir) with a size of 8 elements on the > >>> routine' stack. While locating the element to delete, it pushes the parent node > >>> onto the stack. > >> You're misreading the code. The stack is 8*sizeof(void *) which means 32 > >> elements deep on a 32 bit machine, and 64 deep on a 64 bit machine. There is > >> no possibility of overflow now or for several years to come. > > > > OK! I was confused by the terrible programming style at that point: as the array > > elements are of the proper type (and not bytes), there is no need for a sizeof > > here: I see no reason why the depth of the tree to be allowed should depend on the > > length of a pointer, maning: If you want 32, why don't you write 32? So the worst > > case stack depth would be something like "log2(2^32/(sizeof(void *) * 5))" ("5" > > being 2 links + 2 threading marks + 1 data pointer), something near 32-5 == 27 > > (for 32-bit machines) and 64-6 == 58. Practically the latter could be safely > > reduced to a value around 42 IMHO. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by hyc＠symas.com 29 Jan '09

29 Jan '09

Hardcoding arbitrary limits in portable code is stupid. ("No one will ever need more than 640K...") What may seem (im)practical to you today may be commonplace tomorrow. This code will be maintenance-free no matter what class of machine it's built on, forever. That's *excellent* programming. There is no bug here, this ITS is closed. Ulrich Windl wrote: > On 28 Jan 2009 at 13:06, Howard Chu wrote: > >> Ulrich.Windl(a)rz.uni-regensburg.de wrote: >>> Full_Name: Ulrich Windl >>> Version: 2.4.11 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (132.199.156.178) >>> >>> >>> Looking for a threaded AVL tree implementation that is supposed to work, I found >>> libraries/liblutil/tavl.c in openLDAP. I'm no expert on threaded AVL trees, but >>> there's thing that worries me: >>> tavl_delete uses two stacks (pptr, pdir) with a size of 8 elements on the >>> routine' stack. While locating the element to delete, it pushes the parent node >>> onto the stack. >> You're misreading the code. The stack is 8*sizeof(void *) which means 32 >> elements deep on a 32 bit machine, and 64 deep on a 64 bit machine. There is >> no possibility of overflow now or for several years to come. > > OK! I was confused by the terrible programming style at that point: as the array > elements are of the proper type (and not bytes), there is no need for a sizeof > here: I see no reason why the depth of the tree to be allowed should depend on the > length of a pointer, maning: If you want 32, why don't you write 32? So the worst > case stack depth would be something like "log2(2^32/(sizeof(void *) * 5))" ("5" > being 2 links + 2 threading marks + 1 data pointer), something near 32-5 == 27 > (for 32-bit machines) and 64-6 == 58. Practically the latter could be safely > reduced to a value around 42 IMHO. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by ulrich.windl＠rz.uni-regensburg.de 29 Jan '09

29 Jan '09

On 28 Jan 2009 at 13:06, Howard Chu wrote: > Ulrich.Windl(a)rz.uni-regensburg.de wrote: > > Full_Name: Ulrich Windl > > Version: 2.4.11 > > OS: Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (132.199.156.178) > > > > > > Looking for a threaded AVL tree implementation that is supposed to work, I found > > libraries/liblutil/tavl.c in openLDAP. I'm no expert on threaded AVL trees, but > > there's thing that worries me: > > tavl_delete uses two stacks (pptr, pdir) with a size of 8 elements on the > > routine' stack. While locating the element to delete, it pushes the parent node > > onto the stack. > > You're misreading the code. The stack is 8*sizeof(void *) which means 32 > elements deep on a 32 bit machine, and 64 deep on a 64 bit machine. There is > no possibility of overflow now or for several years to come. OK! I was confused by the terrible programming style at that point: as the array elements are of the proper type (and not bytes), there is no need for a sizeof here: I see no reason why the depth of the tree to be allowed should depend on the length of a pointer, maning: If you want 32, why don't you write 32? So the worst case stack depth would be something like "log2(2^32/(sizeof(void *) * 5))" ("5" being 2 links + 2 threading marks + 1 data pointer), something near 32-5 == 27 (for 32-bit machines) and 64-6 == 58. Practically the latter could be safely reduced to a value around 42 IMHO. > > > So from my knowledge this means that for a perfectly filled balanced tree, the > > stack will overflow when the tree consists of 2^8 (2^0 + 2^1 + 2^2 + ... + 2^7) > > or more nodes, and you are locating a leaf node. Maybe even with fewer nodes. > > As the algorithm also pushes an other element onto the stack, the problem could > > appear even before 128 nodes. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: slapo-unique man page misleading (ITS#5908)
by quanah＠zimbra.com 28 Jan '09

28 Jan '09

--On January 28, 2009 10:39:41 PM +0000 Magne.Land(a)citrix.com wrote: > Hi, > Please see this thread for background info: > http://www.openldap.org/lists/openldap-software/200901/msg00112.html > > To me, something is either guaranteed or not. And I think "enforce" means > something that is guaranteed. In this case, the uniqueness is not > guaranteed, therefore it is not enforced. Set up slapo-accesslog on your master. Then uniqueness is guaranteed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5911) password policy - alternate lockout mechanism
by aravind＠freeshell.org 28 Jan '09

28 Jan '09

Full_Name: Aravind Gottipati Version: 2.4.13 OS: Linux - RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.245.220.241) I'd like to propose a change to how the password lockouts work. The current system does not differentiate between multiple bind attempts with a single (or even a few) incorrect password(s) vs. multiple bind attempts with different incorrect passwords. In our case, this results in a ton of false positives when folks change their password, but don't propagate their password change to all the applications/machines that use it. This causes a bunch of un-necessary lockouts. A real crack attempt on the other hand would most likely try a bunch of passwords (none of which repeat). I have posted the same on the openldap-software mailing lists and Jeff Clowser proposed a scheme that should work to solve the problem. Record each failed bind attempt as a (hash,timestamp) pair. If there is another failed attempt, check the password against these (hash, timestamp) pairs and update the timestamp if the hash is found. If its a new password that hasn't been attempted before, then create a new (hash,timestamp) pair. Lock the account out if there are more than pwdMaxFailure hashes stored. http://www.openldap.org/lists/openldap-software/200901/msg00147.html

1 0

Re: slapo-unique man page misleading (ITS#5908)
by Magne.Land＠citrix.com 28 Jan '09

28 Jan '09

Hi, Please see this thread for background info: http://www.openldap.org/lists/openldap-software/200901/msg00112.html To me, something is either guaranteed or not. And I think "enforce" means something that is guaranteed. In this case, the uniqueness is not guaranteed, therefore it is not enforced. Regards, Magne Land On 1/28/09 2:33 PM, "Gavin Henry" <openldap-its(a)OpenLDAP.org> wrote: > Full_Name: Magne Land > Version: 2.3.43 > OS: RHEL 5.1 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (72.37.244.20) > > > Currently the man page of slapo-unique says "enforce uniqueness", which I find > misleading. > Would it be possible to change it to say "makes the best effort to enforce > uniqueness" or something to that effect? > > It would need more words than that to comment on what exactly happens i.e. why it is a "best effort".

1 0

Re: (ITS#5909) stack overflow in tavl_delete (libraries/liblutil/tavl.c)?
by hyc＠symas.com 28 Jan '09

28 Jan '09

Ulrich.Windl(a)rz.uni-regensburg.de wrote: > Full_Name: Ulrich Windl > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.199.156.178) > > > Looking for a threaded AVL tree implementation that is supposed to work, I found > libraries/liblutil/tavl.c in openLDAP. I'm no expert on threaded AVL trees, but > there's thing that worries me: > tavl_delete uses two stacks (pptr, pdir) with a size of 8 elements on the > routine' stack. While locating the element to delete, it pushes the parent node > onto the stack. You're misreading the code. The stack is 8*sizeof(void *) which means 32 elements deep on a 32 bit machine, and 64 deep on a 64 bit machine. There is no possibility of overflow now or for several years to come. > So from my knowledge this means that for a perfectly filled balanced tree, the > stack will overflow when the tree consists of 2^8 (2^0 + 2^1 + 2^2 + ... + 2^7) > or more nodes, and you are locating a leaf node. Maybe even with fewer nodes. > As the algorithm also pushes an other element onto the stack, the problem could > appear even before 128 nodes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5910) Minor fixes to test scripts
by rein＠OpenLDAP.org 28 Jan '09

28 Jan '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein test006 truncates its log file instead of appending to it. test048 substitutes pathnames wrong if it happens to be run from a directory which includes ".2." in the path. Fixes are coming.. Rein Tollevik Basefarm AS

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs