openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠OpenLDAP.org 09 Jun '11

09 Jun '11

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The admin guide refers to "Start TLS" in multiple locations instead of "StartTLS", which leads to confusion among end users, and makes searching for the startTLS pieces a pain. I will fix shortly.

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > On 09/06/11 00:21, Quanah Gibson-Mount wrote: > >>> An update on this bug report: with a modified slapd.conf and a small >>> patch to the back-perl module, I can use the ACL mask to ensure that the >>> perl search function doesn't get invoked if disallowed by the ACLs. >>> >>> The patch works by creating a "fake" empty entry whose DN is the base of >>> the search, and then passing this entry into access_allowed() using code >>> borrowed from one of the other backends to either deny or allow access. >>> >>> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >>> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch >> >> These are not accessible. > > Hi Quanah, > > Ah yes indeed - that server was decommissioned last month. I've since > reinstated the files from a backup onto a new server and updated DNS to > point to it. Can you verify that you can now download them? Thanks, got it now. The patch leaks memory. I'll commit a fixed version of it shortly. -- -- 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#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 09 Jun '11

09 Jun '11

On 09/06/11 00:21, Quanah Gibson-Mount wrote: >> An update on this bug report: with a modified slapd.conf and a small >> patch to the back-perl module, I can use the ACL mask to ensure that the >> perl search function doesn't get invoked if disallowed by the ACLs. >> >> The patch works by creating a "fake" empty entry whose DN is the base of >> the search, and then passing this entry into access_allowed() using code >> borrowed from one of the other backends to either deny or allow access. >> >> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch > > These are not accessible. Hi Quanah, Ah yes indeed - that server was decommissioned last month. I've since reinstated the files from a backup onto a new server and updated DNS to point to it. Can you verify that you can now download them? Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6965) Ldap ld210_en for Mdaemon ver 11.0.1-urgent
by elena.morozova＠softline.ru 09 Jun '11

09 Jun '11

Full_Name: Elena Morozova Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.141.102.2) Hello, Earlier our client used Ldap ld210_en for Mdaemon ver 11.0.1. What can you advise to use instead of Ldap ld210_en for Mdaemon ver 11.0.1? Thank you.

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 09 Jun '11

09 Jun '11

Andrew Findlay wrote: > On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >>> slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema >>> fragments for pwdPolicySubentry and pwdAccountLockedTime. >> >> That's how they were defined in the IETF Draft. The schema fragments >> in the manpage were copied directly from the spec. The fact that the >> current implementation deviates from the spec is just out of >> necessity to make things work at all in our present code base. > > Certainly the use of pwdPolicySubentry differs from the > intention of the draft (which I believe was intending to use > real X.500-style subentries). > > The case of pwdAccountLockedTime is arguable. > draft-behera-ldap-password-policy-xx.txt says: > > This attribute holds the time that the user's account was locked. A > locked account means that the password may no longer be used to > authenticate. A 000001010000Z value means that the account has been > locked permanently, and that only a password administrator can unlock > the account. > > Unfortunately it says nothing about *how* a password > administrator should do that when the attribute is marked > NO-USER-MODIFICATION. I would argue that this is a > deficiency in the draft, and that the current OpenLDAP > behaviour is more useful. > >> Things will not always work this way... > > Indeed, but I would prefer the manpages to reflect the > reality of the current release! I note that in ppolicy.c we have: { "( 1.3.6.1.4.1.42.2.27.8.1.17 " "NAME ( 'pwdAccountLockedTime' ) " "DESC 'The time an user account was locked' " "EQUALITY generalizedTimeMatch " "ORDERING generalizedTimeOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " "SINGLE-VALUE " #if 0 /* Not until Relax control is released */ "NO-USER-MODIFICATION " #endif "USAGE directoryOperation )", We have in fact released support for the Relax control, so it's probably time to unifdef these bits and go back to the documented behavior. -- -- 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: [PATCH] More for ITS#6872
by hyc＠symas.com 09 Jun '11

09 Jun '11

cmikk(a)qwest.net wrote: > [Note: The previous patch did not fix the problem when > the consumer's access was restricted to the replicated > subtree. This patch fixes that.] Both applied to git master, thanks. > > Perform the internal FIND_CSN search based at the backend's suffix with the > privileges of the backend's root DN. > --- > servers/slapd/overlays/syncprov.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c > index 0c148f9..a058e19 100644 > --- a/servers/slapd/overlays/syncprov.c > +++ b/servers/slapd/overlays/syncprov.c > @@ -661,6 +661,8 @@ again: > if ( BER_BVISEMPTY(&cf.f_av_value )) { > cf.f_av_value = *csn; > } > + fop.o_dn = op->o_bd->be_rootdn; > + fop.o_ndn = op->o_bd->be_rootndn; > fop.o_req_dn = op->o_bd->be_suffix[0]; > fop.o_req_ndn = op->o_bd->be_nsuffix[0]; > /* Look for exact match the first time */ -- -- 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#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > bcolston(a)xtec.com wrote: >> Full_Name: Barry Colston >> Version: 2.4.23 >> OS: Fedora 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.255.208.200) > > I'm looking at your test case now. One thing to note, serverIDs must all be > non-zero in a multi-master configuration. serverID == 0 is only valid in > single-master replication. > >> When a "Refresh Present" phase is performed at a multi-master consumer, objects >> that were deleted at the provider >> while the consumer was down are not deleted from the multi-master consumer (if >> the provider is brought down and back up after the consumer is down). This >> problem can be duplicated as follows: >> 1. Start provider >> 2. Start consumer, which is configured as a multi-master server >> 3. Add 10 records to the provider and wait until the records are replicated to >> the multi-master consumer >> 4. Stop the consumer >> 5. Delete 3 of the records that were added to the provider >> 6. Stop the provider >> 7. Start the provider >> 8. Start the consumer >> 9. After giving the consumer time to perform the refresh present phase, the 3 >> records that were deleted at the provider while the consumer was down >> are still present on the consumer and were not deleted during the refresh >> present phase >> >> Note: the consumer database must have a contextCSN attribute value present for >> itself (e.g., there should be 2 contextCSN attribute values >> present in the consumer database, one for the provider (in my configuration, >> this is serverID 000), and one value for the consumer >> (in my configuration, this is serverID 001). An example of the contextCSN >> values follows: I see. This configuration is not supported. "Multi-Master" requires the servers to be full peers. In your configuration, you have a dedicated provider, it never pulls changes from the consumer, while your consumer is pulling from the provider and accepting local changes. Since the consumer has changes that the provider doesn't know about, the sync protocol is broken. The consumer cannot conclusively state that all entries the provider doesn't know about must be deleted, since some of those entries may have legitimately been created on the consumer, so it cannot execute the delete-nonpresent step. Closing this ITS. >> dn: dc=authentx >> objectClass: top >> entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f >> contextCSN: 20101012154030.379053Z#000000#000#000000 >> contextCSN: 20101012141508.956053Z#000000#001#000000 >> >> OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). >> >> Consumer log file from -d sync logging option: >> @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ >> Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd >> slapd starting >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT >> do_syncrep2: rid=001 >> cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 >> slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 >> slap_graduate_commit_csn: removing 0x1841b18 >> 20101012180219.072053Z#000000#000#000000 >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 1 operations/tasks to finish >> slapd stopped. >> >> Provider slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync1.pid >> argsfile /usr/local/var/slapd.sync1.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 000 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync1 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 150000 >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 500000 >> timelimit 36000 >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> Consumer slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync2.pid >> argsfile /usr/local/var/slapd.sync2.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 001 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync2 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 5000 >> >> # SLAVE server replication section >> syncrepl rid=001 >> provider=ldap://localhost:3891 >> type=refreshAndPersist >> retry="30 60 60 +" >> searchbase="dc=authentx" >> scope=sub >> schemachecking=off >> bindmethod=simple >> binddn="cn=xroot,dc=authentx" >> credentials="SECRET" >> >> mirrormode on >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 100000 >> timelimit 36000 >> # the authentx database access control directives >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> > > -- -- 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#6880) SECURITY: ldap_free_urllist segfault
by Howard Chu 08 Jun '11

08 Jun '11

> Full_Name: Marcus Rottensteiner > Version: 2.4.24 > OS: gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.20.205.34) > > > running a php program, openldap 2.4.24 has a problem in libldap_r-2.4.so.2 > > in conjunction with php 5.3 (tested 5.3.5 , 5.3.6) ? > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2 > (gdb) backtrace > #0 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2 > #1 0x00007ffff1a60c1b in ?? () from /usr/lib64/libldap_r-2.4.so.2 > #2 0x00007ffff1a4680e in ?? () from /usr/lib64/libldap_r-2.4.so.2 > #3 0x0000000000000030 in ?? () > #4 0x0000000000000000 in ?? () > > Reverting to openldap 2.4.23 does not cause a problem ! Your trace shows that both libldap and libldap_r are present. Your PHP is built incorrectly. You cannot link both libraries into the same program; they are not compatible. Closing this ITS.

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > ipuleston(a)SonicWALL.com wrote: >> The patch that I submitted above has a memory leak due not freeing "ber" > when returning error LDAP_X_CONNECTING from function > ldap_send_initial_request(). I have uploaded a new version of the patch with > this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note > the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode). > > Unfortunately the patch was made against 2.4.23 and not against HEAD. It does > not apply cleanly to current git. Patches must always be submitted against the > development code, not against released code. I've committed an alternate patch to git master. > > I'm pretty sure that this chunk can never do anything useful. > > diff -u libldap.orig/request.c libldap/request.c > --- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700 > +++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700 > @@ -446,7 +462,21 @@ > lc->lconn_server = ldap_url_dup( srv ); > } > > - lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED; > + if ( async ) { > +#ifdef HAVE_TLS > + void *ssl = NULL; > + ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); > + if ( ssl ) { > + /* the connect finished and tls was started */ > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + } else > +#endif > + { > + lc->lconn_status = LDAP_CONNST_CONNECTING; > + } > + } else { > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + } > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_lock(&ld->ld_conn_mutex ); > #endif > > The connection has just been created, asynchronously, so there's no way that > the TLS layer was already started when it got here. Also, even if this was > valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you > haven't checked that condition here. Ultimately it appears that this test is a > no-op. > > Also, I suggest that you only check for CONNST_CONNECTING in the callers, and > do the TLS check in the check function, like this: > > +int > +ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv, > ber_socket_t sd ) > +{ > + struct timeval tv = { 0 }; > + int rc; > + > + rc = ldap_int_poll( ld, sd,&tv ); > + switch ( rc ) { > + case 0: > + /* now ready to start tls */ > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + break; > + > + default: > + rc = -1; > + return rc; > + case -2: > + /* connect not completed yet */ > + ld->ld_errno = LDAP_X_CONNECTING; > + return rc; > + } > + > +#ifdef HAVE_TLS > + if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > + !strcmp( srv->lud_scheme, "ldaps" )) { > + > + ++lc->lconn_refcnt; /* avoid premature free */ > + > + rc = ldap_int_tls_start( ld, lc, srv ); > + > + --lc->lconn_refcnt; > + } > +#endif > + return rc; > +} > -- -- 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#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.23 > OS: Fedora 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.200) I'm looking at your test case now. One thing to note, serverIDs must all be non-zero in a multi-master configuration. serverID == 0 is only valid in single-master replication. > When a "Refresh Present" phase is performed at a multi-master consumer, objects > that were deleted at the provider > while the consumer was down are not deleted from the multi-master consumer (if > the provider is brought down and back up after the consumer is down). This > problem can be duplicated as follows: > 1. Start provider > 2. Start consumer, which is configured as a multi-master server > 3. Add 10 records to the provider and wait until the records are replicated to > the multi-master consumer > 4. Stop the consumer > 5. Delete 3 of the records that were added to the provider > 6. Stop the provider > 7. Start the provider > 8. Start the consumer > 9. After giving the consumer time to perform the refresh present phase, the 3 > records that were deleted at the provider while the consumer was down > are still present on the consumer and were not deleted during the refresh > present phase > > Note: the consumer database must have a contextCSN attribute value present for > itself (e.g., there should be 2 contextCSN attribute values > present in the consumer database, one for the provider (in my configuration, > this is serverID 000), and one value for the consumer > (in my configuration, this is serverID 001). An example of the contextCSN > values follows: > > dn: dc=authentx > objectClass: top > entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f > contextCSN: 20101012154030.379053Z#000000#000#000000 > contextCSN: 20101012141508.956053Z#000000#001#000000 > > OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). > > Consumer log file from -d sync logging option: > @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ > Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd > slapd starting > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT > do_syncrep2: rid=001 > cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 > slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 > slap_graduate_commit_csn: removing 0x1841b18 > 20101012180219.072053Z#000000#000#000000 > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 1 operations/tasks to finish > slapd stopped. > > Provider slapd.conf file: > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/authentx.schema > > pidfile /usr/local/var/slapd.sync1.pid > argsfile /usr/local/var/slapd.sync1.args > > allow bind_v2 > > threads 32 > > #loglevel 416 > password-hash {SSHA} > > serverID 000 > > database bdb > suffix "dc=authentx" > rootdn "cn=xroot,dc=authentx" > rootpw SECRET > directory /authentx/db/ldap/authentx-sync1 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 150000 > > # checkpoint<kbytes> <min> > checkpoint 128 20 > > #index for the objectclass > index objectClass eq,pres > index cid,eid,pid eq,pres > index gcoid eq,pres > index sysid,certid eq,pres > index imageid,bioid eq,pres > index addrid,emplid eq,pres > index acid,apid,aeid eq,pres > index acpid,agpid eq,pres > index deviceid eq,pres > index qid eq,pres > index scid eq,pres > index docid eq,pres > index procid eq,pres > index prochandlerid eq,pres > index ounit eq,pres > index credentials eq,pres > index entities eq,pres > index permissions eq,pres > index region eq,pres > index aliasedObjectName eq,pres > index proctype eq,pres > index procname eq,pres > index status eq,pres > index upi,ediident eq,pres > index xsync eq,pres > index role,xrole eq,pres > index eroid eq,pres > index esfunction eq,pres > index nippsector eq,pres > index ercog,ercoop eq,pres > index eropron eq,pres > index xsyncid eq,pres > index stockid eq,pres > index stocktypecode eq,pres > index lotserialin eq,pres > index lotserialout eq,pres > index entryCSN,entryUUID eq > index incl eq,pres > > cachesize 10000 > dncachesize 20000 > idlcachesize 1000 > > sizelimit 500000 > timelimit 36000 > include /usr/local/etc/openldap/acl.authentx > > database monitor > > Consumer slapd.conf file: > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/authentx.schema > > pidfile /usr/local/var/slapd.sync2.pid > argsfile /usr/local/var/slapd.sync2.args > > allow bind_v2 > > threads 32 > > #loglevel 416 > password-hash {SSHA} > > serverID 001 > > database bdb > suffix "dc=authentx" > rootdn "cn=xroot,dc=authentx" > rootpw SECRET > directory /authentx/db/ldap/authentx-sync2 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 5000 > > # SLAVE server replication section > syncrepl rid=001 > provider=ldap://localhost:3891 > type=refreshAndPersist > retry="30 60 60 +" > searchbase="dc=authentx" > scope=sub > schemachecking=off > bindmethod=simple > binddn="cn=xroot,dc=authentx" > credentials="SECRET" > > mirrormode on > > # checkpoint<kbytes> <min> > checkpoint 128 20 > > #index for the objectclass > index objectClass eq,pres > index cid,eid,pid eq,pres > index gcoid eq,pres > index sysid,certid eq,pres > index imageid,bioid eq,pres > index addrid,emplid eq,pres > index acid,apid,aeid eq,pres > index acpid,agpid eq,pres > index deviceid eq,pres > index qid eq,pres > index scid eq,pres > index docid eq,pres > index procid eq,pres > index prochandlerid eq,pres > index ounit eq,pres > index credentials eq,pres > index entities eq,pres > index permissions eq,pres > index region eq,pres > index aliasedObjectName eq,pres > index proctype eq,pres > index procname eq,pres > index status eq,pres > index upi,ediident eq,pres > index xsync eq,pres > index role,xrole eq,pres > index eroid eq,pres > index esfunction eq,pres > index nippsector eq,pres > index ercog,ercoop eq,pres > index eropron eq,pres > index xsyncid eq,pres > index stockid eq,pres > index stocktypecode eq,pres > index lotserialin eq,pres > index lotserialout eq,pres > index entryCSN,entryUUID eq > index incl eq,pres > > cachesize 10000 > dncachesize 20000 > idlcachesize 1000 > > sizelimit 100000 > timelimit 36000 > # the authentx database access control directives > include /usr/local/etc/openldap/acl.authentx > > database monitor > > -- -- 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

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