openldap-devel

openldap-devel@openldap.org

1416 discussions

Re: commit: ldap/tests/scripts test049-sync-config
by Howard Chu 28 Jan '07

28 Jan '07

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/tests/scripts > > Modified Files: > test049-sync-config 1.3 -> 1.4 > > Log Message: > make sure replication finished before comparing data (under valgrind, replication may take ages) I debated adding such a check before. I think the first check you added should be removed. In my initial testing there were timing-dependent errors that cropped up when refreshing was occurring while the ldapadd was running. I think it's important that we continue to test for this case, however crudely it's done. Too bad we don't have a reliable means to notify the test script when the consumer has actually started its work. We could query back-monitor but normally (not under valgrind) the refresh could complete before we got the back-monitor search result. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

2 1

Re: cn=include
by Eric Irrgang 26 Jan '07

26 Jan '07

Since 1) the behavior is different 2) the slapd.conf to cn=config conversion sucks in the relevant information anyway and 3) use of includes is inappropriate under cn=config is it maybe time for the slap* tools stop creating cn=Includes? On Tue, 23 Jan 2007, Howard Chu wrote: > Eric Irrgang wrote: >> Are olcInclude attributes in cn=config honored as per the Admin Guide >> section 5.2.2 or is that documentation misleading? > > Good question. The short answer is - the use of include files is not > recommended for cn=config. They really only work correctly when slapd is using > slapd.conf. > > Keep in mind - in slapd.conf, you can insert include statements anywhere at > all in the config file, you can order them completely arbitrarily, > interleaving them with any other config statements. Under cn=config, all of > the cn=Includes are grouped under one place, they can't have anything else > inserted between them, so if they needed to have other intervening directives > processed first, they would fail. > > Also, the point of using cn=config is to make every part of the configuration > accessible/modifiable using LDAP. slapd.conf-formatted files (e.g. include > files) are not accessible or modifiable using LDAP. > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ > -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

3 3

Search timeout?
by Pierangelo Masarati 25 Jan '07

25 Jan '07

I'm facing an issue: when a proxy is searching a remote server, and the server does not respond in the sense that it happily accepts a search request but never returns any type of response (a "silly" way of reproducing this issue consists in sending a SIGSTOP to the remote server: it accepts requests but does nothing), right now the proxy honors the timelimit. However, if the search is performed as the rootdn of the proxy, it will last forever. So I'd like to introduce the concept of "search timeout". This differs from the already existing "timelimit" in that it is not a client-requested (or server-imposed) limit on the overall duration of a search operation, but rather a server-imposed limitation on how long the proxy can wait consecutively for any sort of response from a remote server. This should, optionally, apply to the rootdn as well, since it's more about the sanity of the connection than on the properties of the operation. This type of limitation has already been introduced for other operations, including compare and all write operations, for a similar purpose. Comments? p.

2 1

Re: commit: ldap/tests/scripts test049-sync-config defines.sh
by Howard Chu 23 Jan '07

23 Jan '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/tests/scripts > > Modified Files: > defines.sh 1.147 -> 1.148 > Added Files: > test049-sync-config NONE -> 1.1 > > Log Message: > Test slave bootstrapping via syncrepl For anyone curious, this test shows how to use back-config and syncrepl to dynamically configure and populate a server. Two stub entries (cn=config and olcdatabase=config,cn=config) are slapadded to initialize the master and slave configurations. Then ldapadd/ldapmodify are used to load the syncprov module, add a syncrepl consumer to the config database, and add the syncprov overlay to the config database on the master. Then ldapmodify is used to start a syncrepl consumer on the slave's config database. The rest of the script adds schema, a database backend and content for the backend on the master, all of which get replicated to the slave. The dilemma of how not to wipe out the consumer configuration once the complete master configuration is replicated onto it is solved with this trick: the master has both a provider and a consumer configured on it, and the consumer points at the master. The syncrepl config handler checks to see if its providerURI matches any of the current server's listenerURIs. If there's a match, the config is a no-op. (It gets parsed but no consumer task is triggered.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

2 3

Modrdn replication
by Pierangelo Masarati 21 Jan '07

21 Jan '07

ITS#4809 reports that when replicating modrdn via slurpd, operational attributes don't get replicated. This appears to be intrinsically caused by the definition of the modrdn operation, which, unlike the modify and add operations, doesn't contemplate the possibility to add/modify attributes other than the naming ones. So add/modify can be easily exploited for replication by adding/modifying the write-related operational attributes during replication, while modrdn can't. Assuming there's any intention to fix slurpd replication until slurpd is dismissed, we need to find a means to attach modification of write-related operational attributes to a modrdn operation, to complement the modrdn operation itself. The proposed solution consists in explicitly modifying the necessary (operational) attributes by means of an additional modify operation that is attached to modrdn. This may be occasionally useful regardless of slurpd replication, which makes it more appealing for OpenLDAP developers, so that the required effort wouldn't be just wasted by slurpd dismissal. The additional modify could be wrapped into a control's value, and that control might be the "relax" control itself, so that the original operation, augmented by the optional modify, would need to succeed as a whole or abort, extending the capabilities of the "relax" control by allowing extra modifications to be added, in order to preserve the integrity of the object after the operation. Comments? p.

3 4

Re: commit: ldap/servers/slapd acl.c slap.h
by Pierangelo Masarati 16 Jan '07

16 Jan '07

ando(a)OpenLDAP.org wrote: > allow to specify the required access privileges in internal operations (ITS#4806) > Note that one does not need to use the same access privileges for testing the filter and testing data return: in fact, when issuing an internal search, when required one could set o_acl_priv to the privilege desired for filter testing; then, in sc_response(), one could change it to the privilege desired for data return testing, and return it back in sc_cleanup(), and so back and forth. p.

1 0

Re: slapo-dynlist desgin question(s)
by Quanah Gibson-Mount 16 Jan '07

16 Jan '07

--On January 16, 2007 6:34:39 PM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > Quanah Gibson-Mount wrote: > >> This patch also does not work, continuing to use the credentials of the >> bound user. > > > What operation are you performing when it gets to evaluate that filter? > Can you describe it a little bit further? ldapsearch -LLL -Q -h ldap-dev1 -b "cn=groups,cn=applications,dc=stanford,dc=edu" cn=registry-consult -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

subclass matching in be_fetch()
by Pierangelo Masarati 11 Jan '07

11 Jan '07

I think in many cases it would be useful to have be_entry_get_rw() match entries based on their class not only exactly, as now, but also if the entry's class is subordinate to the one passed to be_entry_get_rw(). I have a patch that adds a flag parameter for the objectClass value. In most cases, to preserve the current behavior, the flag is set to 0; however I believe in many cases where be_entry_get_rw() or be_fetch() are used, it should definitely be set to SLAP_OCF_CHECK_SUP. If there's no objection, and I didn't overlook anything serious, I'd commit it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

rootdn -> admindn?
by Hallvard B Furuseth 10 Jan '07

10 Jan '07

I've had it with explaining that the suffix is the root of the database which is not the rootdn which is not the Unix user "root". Any hope of renaming rootdn and rootpw to admindn and adminpw, with rootdn/pw as backwards-compatible and eventually undocumented aliases? -- Hallvard

8 10

Notice of disconnection
by Lars Hesel Christensen XX (AH/LMD) 10 Jan '07

10 Jan '07

Hi all I've been looking at the Notice of disconnection handling in OpenLDAP and there is a thing that is confusing me a bit. in result.c, the function try_read1msg reads data from socket and creates a new message from that. If we receive an unsolicited message, e.g, notice of disconnection, then the msgId will be zero, and we will go through the following code(taken from /* $OpenLDAP: /libraries/libldap/result.c,v 1.144 2006/12/17 21:04:25 ando Exp $ */): /* message id */ if ( ber_get_int( ber, &id ) == LBER_ERROR ) { ber_free( ber, 1 ); ld->ld_errno = LDAP_DECODING_ERROR; return( -1 ); } /* if it's been abandoned, toss it */ if ( ldap_abandoned( ld, id, &idx ) ) { <REMOVED since the msgId is not abandoned> retry_ber: ber_free( ber, 1 ); if ( ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_DATA_READY, NULL ) ) { goto retry; } --> return( LDAP_MSG_X_KEEP_LOOKING ); /* continue looking */ } lr = ldap_find_request_by_msgid( ld, id ); if ( lr == NULL ) { const char *msg = "unknown"; /* the message type */ tag = ber_peek_tag( ber, &len ); switch ( tag ) { case LBER_ERROR: break; default: msg = ldap_int_msgtype2str( tag ); break; } Debug( LDAP_DEBUG_ANY, "no request for response on ld %p msgid %ld message type %s (tossing)\n", (void *)ld, (long)id, msg ); goto retry_ber; } Assuming there is no more data to be read from the socket we will return in the line marked with the arrow '-->' since ldap_find_request_by_msgid() returns NULL. What confuses me is that later on in try_read1msg we get to (after constructing the message: /* is this the one we're looking for? */ if ( msgid == LDAP_RES_ANY || id == msgid ) { if ( all == LDAP_MSG_ONE || ( newmsg->lm_msgtype != LDAP_RES_SEARCH_RESULT && newmsg->lm_msgtype != LDAP_RES_SEARCH_ENTRY && newmsg->lm_msgtype != LDAP_RES_SEARCH_REFERENCE ) ) { *result = newmsg; ld->ld_errno = LDAP_SUCCESS; return( tag ); } else if ( newmsg->lm_msgtype == LDAP_RES_SEARCH_RESULT) { foundit = 1; /* return the chain later */ } } Do we have a test case testing notice of disconnection? I tried to grep the 'tests' directory for 'notice', 'disconnection' and 'unsolicited' but nothing came up. Perhaps I'm misunderstanding something here, so if I am I would very much appreciate a hint. Happy newyear everyone, Lars Hesel Christensen -- Lars Hesel Christensen Ericsson Denmark A/S, Telebit lars.hesel.xx.christensen(a)ericsson.com

3 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel