openldap-bugs

openldap-bugs@openldap.org

20960 discussions

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 06 Feb '09

06 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 06 Feb '09

06 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 06 Feb '09

06 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs