openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org 02 May '08

02 May '08

luca(a)OpenLDAP.org wrote: > This is a multi-part message in MIME format. > --------------080809000906010300090306 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Howard Chu wrote: > >> Thanks. Please try HEAD again. >> > No way. > new testrun directory in > ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz > > backtrace attached > recent commits seem to have fixed it (at least, right now I'm not able to reproduce it anymore...)

1 0

Potential deadlock in back-monitor cache
by Yin Wang 01 May '08

01 May '08

We are working on a project that could relieve from programmer the burden of reasoning about deadlocks, races etc. Our study of the latest OpenLDAP source code shows the following susceptible to deadlock. - monitor_cache_get at servers/slapd/back-monitor/cache.c:163 waiting for mp_mutex while holding mi_cache_mutex - monitor_cache_release at servers/slapd/back-monitor/cache.c:366 waiting for mi_cache_mutex while holding mp_mutex We have not verified this in production run, which could be difficult. Any comment would be greatly appreciated. Yin Wang

1 0

Re: (ITS#5491) slapd crashes with ldappasswd
by quanah＠zimbra.com 30 Apr '08

30 Apr '08

--On Wednesday, April 30, 2008 10:34 PM +0000 Deepak.Cheema(a)emerson.com wrote: > Full_Name: Deepak Cheema > Version: 2.4.8 > OS: Red Hat Linux 3.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (144.189.5.201) > > > Just built, installed openldap 2.4.8 and slapd starts up fine using the > following > > slapd -f slapd.conf -u root > > as root user on default port 389 > > [root@dl2k245 libexec]# ps -ef|grep slapd > root 15065 1 0 15:31 ? 00:00:00 ./slapd -f > /dbapps/informatica/l > dap/etc/openldap/slapd.conf -u root > > The process stays up as long as I don't type the ldappasswd command to > get the encrypted password a new user... > > once I type in ldappasswd... this is what happens.. > > [root@dl2k245 bin]# ldappasswd > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > additional info: SASL(0): successful result: security flags do not > match > required > [root@dl2k245 bin]# ps -ef|grep lapd > root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd > > and the slapd process is no longer there... > > Any ideas why it might be happening or how to debug this? > I tried dbg but it did not tell me much.. maybe I did not use it > correctly... > > Any help is appreciated ! gdb the slapd process, let it run, and then run your ldappasswd command and see where it is segfaulting. Provide a backtrace, etc. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5492)
by hyc＠symas.com 30 Apr '08

30 Apr '08

huynh.tuan(a)comcast.net wrote: > --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 > Content-Type: text/plain > Content-Transfer-Encoding: 8bit > > I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. > > Used crypt to hash password. DES-based Unix crypt only checks the first 8 characters. As I said, if you want longer passwords, then your current choice of password hash is no good. Use some other hash instead. This ITS will be closed. -- -- 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#5492)
by huynh.tuan＠comcast.net 30 Apr '08

30 Apr '08

--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. Used crypt to hash password. --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0 Content-Type: text/html Content-Transfer-Encoding: 8bit <html><body> <DIV> <DIV>I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same.  </DIV> <DIV> </DIV> <DIV>Used crypt to hash password.</DIV></DIV></body></html> --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0--

1 0

Re: (ITS#5492) Ignore password longer than pwdMinLength specified in PPOLICY
by hyc＠symas.com 30 Apr '08

30 Apr '08

huynh.tuan(a)comcast.net wrote: > Full_Name: Tuan Huynh > Version: 2.3.39 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.39.129.66) > > > My password is 10 characters long, however system allowed me to login as long as > I enter first 8 characters and it ignored the rest even if I enter garbage. For > example: > > my password is !thisIsATest! > when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdkdkdk > > I used ppolicy and pwdMinLength is set at 8 Sounds like a configuration error in your Solaris system, or possibly a poor choice of password hash mechanism. I don't see any evidence of an OpenLDAP bug here. -- -- 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#5492) Ignore password longer than pwdMinLength specified in PPOLICY
by huynh.tuan＠comcast.net 30 Apr '08

30 Apr '08

Full_Name: Tuan Huynh Version: 2.3.39 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.39.129.66) My password is 10 characters long, however system allowed me to login as long as I enter first 8 characters and it ignored the rest even if I enter garbage. For example: my password is !thisIsATest! when I login it'll accept password such as !thisIsA or !thisIsAdkdkdkdkdkdkdkdk I used ppolicy and pwdMinLength is set at 8

1 0

Re: (ITS#5488) syncrepl received contextCSN not passed on to syncprov consumers
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > When syncrepl and syncprov are both used on a glue database, the > contextCSN received from the syncrepl producers are not passed on to the > syncprov consumers when changes in subordinate databases are received. > The reason is that syncrepl queues the CSNs in the glue backend, while > syncprov fetches them from the backend where the changes are made. As a > consequence, the consumers will be passed a cookie without any csn > value. > > My first attempt at fixing this was to change syncprov to fetch the > queued csn values from the glue backend where it was used. But that > failed as other modules queues the csn values in their own backend when > they changes things. What other modules? Generally there cannot be any other sources of changes. > Instead I changed ctxcsn.c so that it always > queues them in the glue backend where syncprov is used. But I don't > feel that my understanding of this stuff is good enough to be sure that > this is the optimal solution.. I definitely don't like references to the syncprov overlay appearing in main slapd code like that. We need a different solution. At one point in the past, I had changed syncrepl.c to queue the CSNs in both places, but that seemed rather sloppy. Still, it may work best here. > Btw, in syncprov_checkpoint() there is a similar SLAP_GLUE_SUBORDINATE > test, should that have included an overlay_is_inst() clause as well? Perhaps. You would have to use op->o_bd->bd_self instead of op->o_bd on that call. > Rein Tollevik > Basefarm AS > > Index: OpenLDAP/servers/slapd/ctxcsn.c > diff -u OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 > OpenLDAP/servers/slapd/ctxcsn.c:1.2 > --- OpenLDAP/servers/slapd/ctxcsn.c:1.1.1.11 Sat Mar 22 16:47:49 2008 > +++ OpenLDAP/servers/slapd/ctxcsn.c Wed Apr 30 19:44:25 2008 > @@ -37,67 +37,78 @@ > ) > { > struct slap_csn_entry *csne, *committed_csne = NULL; > + Backend *be = op->o_bd; > > if ( maxcsn ) { > BER_BVZERO( maxcsn ); > } > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > csne->ce_state = SLAP_CSN_COMMIT; > break; > } > } > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_state == SLAP_CSN_COMMIT ) committed_csne = csne; > if ( csne->ce_state == SLAP_CSN_PENDING ) break; > } > > if ( committed_csne&& maxcsn ) *maxcsn = committed_csne->ce_csn; > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > void > slap_rewind_commit_csn( Operation *op ) > { > struct slap_csn_entry *csne; > + Backend *be = op->o_bd; > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > csne->ce_state = SLAP_CSN_PENDING; > break; > } > } > > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > void > slap_graduate_commit_csn( Operation *op ) > { > struct slap_csn_entry *csne; > + Backend *be; > > if ( op == NULL ) return; > if ( op->o_bd == NULL ) return; > > + be = op->o_bd; > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + > #if 0 > /* it is NULL when we get here from the frontendDB; > * alternate fix: initialize frontendDB like all other backends */ > - assert( op->o_bd->be_pcl_mutexp != NULL ); > + assert( be->be_pcl_mutexp != NULL ); > #endif > > - if ( op->o_bd->be_pcl_mutexp == NULL ) return; > + if ( be->be_pcl_mutexp == NULL ) return; > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > - LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) { > + LDAP_TAILQ_FOREACH( csne, be->be_pending_csn_list, ce_csn_link ) { > if ( csne->ce_opid == op->o_opid&& csne->ce_connid == op->o_connid ) { > - LDAP_TAILQ_REMOVE( op->o_bd->be_pending_csn_list, > + LDAP_TAILQ_REMOVE( be->be_pending_csn_list, > csne, ce_csn_link ); > Debug( LDAP_DEBUG_SYNC, "slap_graduate_commit_csn: removing %p %s\n", > csne->ce_csn.bv_val, csne->ce_csn.bv_val, 0 ); > @@ -110,7 +121,7 @@ > } > } > > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > > return; > } > @@ -161,22 +172,25 @@ > struct berval *csn ) > { > struct slap_csn_entry *pending; > + Backend *be = op->o_bd; > > pending = (struct slap_csn_entry *) ch_calloc( 1, > sizeof( struct slap_csn_entry )); > > Debug( LDAP_DEBUG_SYNC, "slap_queue_csn: queing %p %s\n", csn->bv_val, > csn->bv_val, 0 ); > > - ldap_pvt_thread_mutex_lock( op->o_bd->be_pcl_mutexp ); > + if ( SLAP_GLUE_SUBORDINATE( be )&& !overlay_is_inst( be, "syncprov" )) > + be = select_backend(&be->be_nsuffix[0], 1 ); > + ldap_pvt_thread_mutex_lock( be->be_pcl_mutexp ); > > ber_dupbv(&pending->ce_csn, csn ); > ber_bvreplace_x(&op->o_csn,&pending->ce_csn, op->o_tmpmemctx ); > pending->ce_connid = op->o_connid; > pending->ce_opid = op->o_opid; > pending->ce_state = SLAP_CSN_PENDING; > - LDAP_TAILQ_INSERT_TAIL( op->o_bd->be_pending_csn_list, > + LDAP_TAILQ_INSERT_TAIL( be->be_pending_csn_list, > pending, ce_csn_link ); > - ldap_pvt_thread_mutex_unlock( op->o_bd->be_pcl_mutexp ); > + ldap_pvt_thread_mutex_unlock( be->be_pcl_mutexp ); > } > > int > > > -- -- 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#5491) slapd crashes with ldappasswd
by Deepak.Cheema＠emerson.com 30 Apr '08

30 Apr '08

Full_Name: Deepak Cheema Version: 2.4.8 OS: Red Hat Linux 3.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.189.5.201) Just built, installed openldap 2.4.8 and slapd starts up fine using the following slapd -f slapd.conf -u root as root user on default port 389 [root@dl2k245 libexec]# ps -ef|grep slapd root 15065 1 0 15:31 ? 00:00:00 ./slapd -f /dbapps/informatica/l dap/etc/openldap/slapd.conf -u root The process stays up as long as I don't type the ldappasswd command to get the encrypted password a new user... once I type in ldappasswd... this is what happens.. [root@dl2k245 bin]# ldappasswd SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Can't contact LDAP server additional info: SASL(0): successful result: security flags do not match required [root@dl2k245 bin]# ps -ef|grep lapd root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd and the slapd process is no longer there... Any ideas why it might be happening or how to debug this? I tried dbg but it did not tell me much.. maybe I did not use it correctly... Any help is appreciated !

1 0

Re: (ITS#5487) syncprov_findbase must search the backend from the syncrepl search
by hyc＠symas.com 30 Apr '08

30 Apr '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > syncprov_findbase() must search the backend saved with the syncrepl operation, > not the one from the operation passed as argument. The backend in the op > argument can be a subordinate database, in which case the search for the base in > the superior database will fail, and syncrepl consumers will be force to do a an > unneccessary full refresh of the database. OK. > The patch at the end should fix > this. Note that both fop.o_bd and fop.o_bd->bd_info can be changed by the > overlay_op_walk() call, which is the reason for the long pointer traversal to > find the correct bd_info to save and restore. But the overlay_op_walk call is only appropriate when the DB to be searched is the current database, and the current DB is an overlay DB structure. Your patch causes fc->fss->s_op->o_bd's bd_info pointer to change, which is not allowed. That's in the original backendDB, which must be treated as read-only since multiple threads may be accessing it. The correct approach here is to use a new local backendDB variable, copy the s_op->o_bd into it, and then just do a regular be_search invocation instead of using overlay_op_walk. But, this patch must not take effect on the first call to syncprov_findbase (which occurred in syncprov_op_search) - in that case, the current code is correct. So, you need to tweak things based on whether (s_flags & PS_IS_REFRESHING) is true or not - if true, this is the first search, and it should use the original code. Else, it must use be_search. > Rein Tollevik > Basefarm AS > > diff -u OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 > OpenLDAP/servers/slapd/overlays/syncprov.c:1.19 > --- OpenLDAP/servers/slapd/overlays/syncprov.c:1.1.1.18 Wed Apr 30 13:17:58 > 2008 > +++ OpenLDAP/servers/slapd/overlays/syncprov.c Wed Apr 30 19:34:00 2008 > @@ -404,7 +404,7 @@ > slap_callback cb = {0}; > Operation fop; > SlapReply frs = { REP_RESULT }; > - BackendInfo *bi; > + BackendInfo *bi = fc->fss->s_op->o_bd->bd_info; > int rc; > > fc->fss->s_flags ^= PS_FIND_BASE; > @@ -413,10 +413,8 @@ > fop = *fc->fss->s_op; > > fop.o_hdr = op->o_hdr; > - fop.o_bd = op->o_bd; > fop.o_time = op->o_time; > fop.o_tincr = op->o_tincr; > - bi = op->o_bd->bd_info; > > cb.sc_response = findbase_cb; > cb.sc_private = fc; > @@ -435,7 +433,7 @@ > fop.ors_filterstr = generic_filterstr; > > rc = overlay_op_walk(&fop,&frs, op_search, on->on_info, on ); > - op->o_bd->bd_info = bi; > + fc->fss->s_op->o_bd->bd_info = bi; > } else { > ldap_pvt_thread_mutex_unlock(&fc->fss->s_mutex ); > fc->fbase = 1; > > > -- -- 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