- openldap-bugs - openldap.org

Re: (ITS#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 20 Sep '08

20 Sep '08

On Sat, 20 Sep 2008, Pierangelo Masarati wrote: > connection_next()? Or even better, the whole *c structure? Sure... (dbx) print *c *c = { c_struct_state = 2 c_conn_state = 2 c_conn_idx = 21 c_sd = 21 c_close_reason = 0x1002979d0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x1006af890 c_starttime = 1221349177 c_activitytime = 1221349191 c_connid = 41U c_peer_domain = { bv_len = 7U bv_val = 0x105d3ab40 "unknown" } c_peer_name = { bv_len = 18U bv_val = 0x1117714e0 "IP=127.0.0.1:51374" } c_listener = 0x1004acec0 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = 0x1005510b0 c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 28U bv_val = 0x11177ea00 "cn=Manager,dc=example,dc=com" } sai_ndn = { bv_len = 28U bv_val = 0x111771900 "cn=manager,dc=example,dc=com" } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 3 c_ops = { stqh_first = (nil) stqh_last = 0x10059e658 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x10059e668 } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = 0x10c759540 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x1081466b0 c_sasl_sockctx = (nil) c_sasl_extra = 0x105d38370 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 861 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 861 c_n_get = 861 c_n_read = 861 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x100071348 = &slap_send_ldap_result() c_send_search_entry = 0x1000727c8 = &slap_send_search_entry() c_send_search_reference = 0x1000753b8 = &slap_send_search_reference() c_send_ldap_extended = 0x100072038 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x100072458 = &slap_send_ldap_intermediate() } *c = { c_struct_state = 2 c_conn_state = 2 c_conn_idx = 26 c_sd = 26 c_close_reason = 0x1002979d0 "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x1041453f0 c_starttime = 1221416361 c_activitytime = 1221416386 c_connid = 24U c_peer_domain = { bv_len = 7U bv_val = 0x106754ec0 "unknown" } c_peer_name = { bv_len = 18U bv_val = 0x106753aa0 "IP=127.0.0.1:49627" } c_listener = 0x1004acec0 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = 0x1005510b0 c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 80U bv_val = 0x10c75ba20 "cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com" } sai_ndn = { bv_len = 80U bv_val = 0x1006b3530 "cn=barbara jensen,ou=information technology division,ou=people,dc=example,dc=com" } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 3 c_ops = { stqh_first = (nil) stqh_last = 0x10059f0f8 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x10059f108 } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = 0x1006bd3f0 c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x107755210 c_sasl_sockctx = (nil) c_sasl_extra = 0x10674d4a0 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 817 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 817 c_n_get = 817 c_n_read = 817 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x100071348 = &slap_send_ldap_result() c_send_search_entry = 0x1000727c8 = &slap_send_search_entry() c_send_search_reference = 0x1000753b8 = &slap_send_search_reference() c_send_ldap_extended = 0x100072038 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x100072458 = &slap_send_ldap_intermediate() } *c = { c_struct_state = 1 c_conn_state = 9578416 c_conn_idx = 0 c_sd = 99 c_close_reason = 0x48cd983e "<bad address 0x48cd983e>" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '' __pthread_mutex_type = 0 __pthread_mutex_magic = 0 } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 1U __pthread_lockword = 5577376U } __pthread_mutex_owner64 = 4300544672U } __pthread_mutex_data = 10U } c_sb = 0x10071ac88 c_starttime = 10 c_activitytime = 4302417080 c_connid = 8589934592U c_peer_domain = { bv_len = 2147483651600U bv_val = 0x100551b7c "" } c_peer_name = { bv_len = 0 bv_val = 0x10071ad08 "" } c_listener = 0x10071acd0 c_sasl_bind_mech = { bv_len = 15U bv_val = 0x10071acf0 "(objectClass=*)" } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 0 sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = 0x1009228f8 "" } sai_ndn = { bv_len = 128U bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 28U } c_protocol = 1 c_ops = { stqh_first = 0x1c stqh_last = 0x109753c70 } c_pending_ops = { stqh_first = (nil) stqh_last = (nil) } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 0 __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\001' __pthread_mutex_type = 450U __pthread_mutex_magic = 60032U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 0 } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = (nil) c_sasl_sockctx = (nil) c_sasl_extra = 0xf c_sasl_bindop = 0x43 c_pagedresults_state = { ps_be = 0x1005a00f0 ps_size = 16 ps_count = 3 ps_cookie = 12884901888U ps_cookieval = { bv_len = 18446744071444626464U bv_val = 0x10054a1a0 "" } } c_n_ops_received = 4299177360 c_n_ops_executing = 4302412176 c_n_ops_pending = 7165066951922169632 c_n_ops_completed = 8029985417153478656 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = (nil) c_send_search_entry = (nil) c_send_search_reference = (nil) c_send_ldap_extended = (nil) c_send_ldap_intermediate = (nil) }

1 0

Re: (ITS#5701) connection.c asserting during test008
by ando＠sys-net.it 20 Sep '08

20 Sep '08

richton(a)nbcs.rutgers.edu wrote: > Rare connection.c assertion during test008s of RE24. Here are three different > examples: > [6] monitor_subsys_conn_create(op = 0x103a359b0, rs = 0xffffffff76bff998, ndn > = (nil), e_parent = 0x1005c03d8, ep = 0xffffffff76bff230), line 500 in "conn.c" > [6] monitor_subsys_rww_update(op = 0x102c3dd70, rs = 0xffffffff6dbff998, e = > 0x1005c1b98), line 187 in "rww.c" > [7] monitor_subsys_rww_update(op = 0x100922640, rs = 0xffffffff78fff998, e = > 0x1005c1b98), line 185 in "rww.c" Sorry, I overlooked the fact that all those issues are occurring from within back-monitor. In all cases, it's within code that loops through the connection array using connection_{first,next,close}(). Apparently, those calls are used in the right way. Can you print more information about those connections? E.g. c->c_struct_state, and *index from within connection_next()? Or even better, the whole *c structure? 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#5654) memberof syntax clunky
by ando＠sys-net.it 20 Sep '08

20 Sep '08

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.176.63.104) > > > As instructed by Howard: > > From: Howard Chu <hyc(a)highlandsun.com> > To: samba-technical(a)lists.samba.org > Subject: Re: samba4-ol-mmr > Date: Mon, 11 Aug 2008 21:09:52 -0700 (Tue, 14:09 EST) > > > >> # Generated from schema in /usr/local/samba/private/ldap/schema-tmp.ldb >> overlay memberof >> memberof-dn cn=samba-admin,cn=samba >> memberof-dangling error >> memberof-refint TRUE >> memberof-group-oc top >> memberof-member-ad msDS-ObjectReference >> memberof-memberof-ad msDS-ObjectReferenceBL >> memberof-dangling-error 32 > > (repeats once per attribute link) > > ... > > Mmm, that's really clunky. Someone should file an OpenLDAP enhancement request > on the memberof config syntax. You should only need to instantiate the overlay > once, and then it should just take a list of oc/forward-ad/back-ad config > options. > >> Look closely at how we sub in memberof configuration into the >> slapd.conf. I suggest that you could add a ${REPL_CONFIG} after each >> database, which the script could sub with either "" or by reading and >> subing in a slapd-replica.conf It's not the syntax that's clunky. You're (ab)using slapo-memberof(5), which was designed to deal with *just one* pair of member/reverse-link attribute relationship. Probably the overlay needs to be entirely reworked to provide a many-to-many relationship. At this point, I'd rather design a new one, giving up some of the not so useful extra features implemented in slapo-memberof(5), and focusing on the many-to-many main requirement. 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#5656) Bind operations with translucent overlay
by ando＠sys-net.it 20 Sep '08

20 Sep '08

RFC 3062 password modification extended operation on locally stored credentials is now in HEAD; please test and report. 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#5706) slapo-collect(5) is missing
by hyc＠symas.com 18 Sep '08

18 Sep '08

ghenry(a)suretecsystems.com wrote: > ----- ando(a)sys-net.it wrote: > >> ghenry(a)OpenLDAP.org wrote: >>> ----- ando(a)sys-net.it wrote: >>> >>>> ando(a)sys-net.it wrote: >>>> >>>>> Slapo-collect is now in re24, but no man page is available. >>>> Added to HEAD; please review. >>> If it supports cn=config, that should be mentioned in the man page. >> It does. Fixed, thanks. I'd note that only few man pages mention >> this >> fact, while most overlays do support back-config. > > Are there any left that don't? Just retcode. > Another one of my goals is to add a cn=config example > to each as well as the slapd.conf examples. > -- -- 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#5706) slapo-collect(5) is missing
by ghenry＠suretecsystems.com 18 Sep '08

18 Sep '08

----- ando(a)sys-net.it wrote: > ghenry(a)OpenLDAP.org wrote: > > ----- ando(a)sys-net.it wrote: > > > >> ando(a)sys-net.it wrote: > >> > >>> Slapo-collect is now in re24, but no man page is available. > >> Added to HEAD; please review. > > > > If it supports cn=config, that should be mentioned in the man page. > > It does. Fixed, thanks. I'd note that only few man pages mention > this > fact, while most overlays do support back-config. Are there any left that don't? Another one of my goals is to add a cn=config example to each as well as the slapd.conf examples. -- 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#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

ghenry(a)OpenLDAP.org wrote: > ----- ando(a)sys-net.it wrote: > >> ando(a)sys-net.it wrote: >> >>> Slapo-collect is now in re24, but no man page is available. >> Added to HEAD; please review. > > If it supports cn=config, that should be mentioned in the man page. It does. Fixed, thanks. I'd note that only few man pages mention this fact, while most overlays do support back-config. 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#5706) slapo-collect(5) is missing
by ghenry＠OpenLDAP.org 18 Sep '08

18 Sep '08

----- ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > > > Slapo-collect is now in re24, but no man page is available. > > Added to HEAD; please review. If it supports cn=config, that should be mentioned in the man page. 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: (ITS#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> ando(a)sys-net.it wrote: >> >>> Slapo-collect is now in re24, but no man page is available. >> >> Added to HEAD; please review. > > I'm not sure the reference to collectiveAttributeSubentry is helpful > here; this overlay was written independently of RFC3671. Its behavior > was based on my dim memory of how collective attributes behaved in the > last X.500 server I worked with, plus a lot of expedience - something > quick and easy to implement. Note that subentries cannot have children, > and the premise of this overlay is to propagate attributes from a parent > entry (not subentry) to all of its children. Right. In fact, I was a little bit confused after comparing the code with RFC 3671 & 3672. I fixed the man page. 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#5706) slapo-collect(5) is missing
by hyc＠symas.com 18 Sep '08

18 Sep '08

ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Slapo-collect is now in re24, but no man page is available. > > Added to HEAD; please review. I'm not sure the reference to collectiveAttributeSubentry is helpful here; this overlay was written independently of RFC3671. Its behavior was based on my dim memory of how collective attributes behaved in the last X.500 server I worked with, plus a lot of expedience - something quick and easy to implement. Note that subentries cannot have children, and the premise of this overlay is to propagate attributes from a parent entry (not subentry) to all of its children. -- -- 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#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

quanah(a)zimbra.com wrote: > --On Thursday, September 18, 2008 8:12 PM +0000 ando(a)sys-net.it wrote: > >> ando(a)sys-net.it wrote: >> >>> Slapo-collect is now in re24, but no man page is available. >> Added to HEAD; please review. > > Do we need to acknowledge the work done on it by Brett Maxfield? Well, it's up to those who took care of it. I didn't quite followed that thread, and only credited Howard based on his initial submission in 2003. 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#5706) slapo-collect(5) is missing
by quanah＠zimbra.com 18 Sep '08

18 Sep '08

--On Thursday, September 18, 2008 8:12 PM +0000 ando(a)sys-net.it wrote: > ando(a)sys-net.it wrote: > >> Slapo-collect is now in re24, but no man page is available. > > Added to HEAD; please review. Do we need to acknowledge the work done on it by Brett Maxfield? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

ando(a)sys-net.it wrote: > Slapo-collect is now in re24, but no man page is available. Added to HEAD; please review. 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#5706) slapo-collect(5) is missing
by ando＠sys-net.it 18 Sep '08

18 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Slapo-collect is now in re24, but no man page is available. p.

1 0

(ITS#5705) [enhancement] slapo-constraint could honor "relax" by not checking for constraints
by ando＠sys-net.it 18 Sep '08

18 Sep '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando See subject. p.

1 0

Issue in syncprov findcsn code
by Pierangelo Masarati 17 Sep '08

17 Sep '08

Not sure this is a bug, but I'm curious... I hit this while checking for ITS#5661. The code below is from HEAD's syncprov.c:613 (not changed recently; pardon any unintended line wrapping): <snip> again: switch( mode ) { case FIND_MAXCSN: cf.f_choice = LDAP_FILTER_GE; /* If there are multiple CSNs, use the one with our serverID */ for ( i=0; i<si->si_numcsns; i++) { if ( slap_serverID == si->si_sids[i] ) { maxid = i; break; } } </snip> When run by a consumer, with no serverID set (and thus slap_serverID == 0), it causes the consumer to use the contextCSN with SID == "000" instead of the most recent one. As a consequence, if one searches the contextCSN within that consumer, slapo-syncprov's syncprov_operational() causes only that value to be returned, instead of all contextCSNs. After the consumer is restarted, all values are correctly returned. To reproduce: - populate a DSA (SIDs in CSNs will default to "000") - turn it into a (multi)master by adding the serverID statement (with SID > "000") and so - perform a modification (so that the most recent contextCSN will have SID != "000") - create a consumer (no serverID statement, so that it defaults to "000") and let it pull data from the producer - search the contextCSN of the consumer I'm not sure this is a bug; it might be harmless, apart from being definitely misleading. There might be multiple solutions: - don't let syncprov_operational() muck with contextCSN that way - make syncprov_findcsn() search the newest contextCSN instead of the one with its SID - initialize slapd_serverID with some SID_UNDEFINED in order to take the action above only when SID is not defined 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 -----------------------------------

4 8

syncrepl failed without errors when a put a TAB character in slapd.conf
by liandro sg 17 Sep '08

17 Sep '08

Running slapd 2.4.10-3 version on debian 2.6.25-2-686 If I put a TAB (ascii character decimal 9) starting a line in slapd.conf , in front of syncrepl configuration option, the syncrepl funcionlity don't starts . The fonfiguration test ( slaptest) return success. If I delete the TAB character, syncrepl run ok

2 1

Re: (ITS#5704) [enhancement] allow restrictions in slapo-constraint(5)
by ando＠sys-net.it 17 Sep '08

17 Sep '08

ando(a)sys-net.it wrote: > This patch allows to restrict a constraint to entries matching an LDAP URI; > complements ITS#5702. ... in the sense that a constraint like constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" needs to be restricted to entries whose objectClass is derived from inetOrgPerson. This is accomplished by using constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" restrict="ldap:///dc=example,dc=com??sub?(objectClass=inetOrgPerson)" 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#5704) [enhancement] allow restrictions in slapo-constraint(5)
by ando＠sys-net.it 17 Sep '08

17 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando This patch allows to restrict a constraint to entries matching an LDAP URI; complements ITS#5702. p.

1 0

(ITS#5703) slapo-constraint(5) rename issue
by ando＠sys-net.it 17 Sep '08

17 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.148) Submitted by: ando I see an issue in slapo-constraint(5): it does not handle rename ops; as a consequence, a rename could result in violating constraints on the values of the naming attributes. p.

1 0

(ITS#5702) [enhancement] allow cross-attribute constraints in slapo-constraint(5)
by ando＠sys-net.it 16 Sep '08

16 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I've added a "set" type to slapo-constraint(5) that allows to write complex constraints like constraint_attribute cn,sn,givenName set "(this/givenName + [ ] + this/sn) & this/cn" forcing a relationship between the values of cn, sn and givenName. The possibility to enforce the same constraint on multiple attributes separated by commas is given to all constraint types, as a side-effect. The check is passed the entry during add operations, while it attempts to build the entry resulting from a set of modifications during modify operations. p.

1 0

Re: (ITS#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

ando(a)sys-net.it wrote: > BTW: there are some minor bugs in that patch; for example, don't start > slapd with -F :). Michael, please try this one instead: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-17.patch>. I won't probably be able to work at this stuff for a few days. Cheers, 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#5663) Declaring substitute syntax as LDAP syntax
by hyc＠symas.com 16 Sep '08

16 Sep '08

ando(a)sys-net.it wrote: > I'd note rfc4517 does not > mention extensions, either... RFC4512 does. -- -- 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#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

michael(a)stroeder.com wrote: > You rock! I'll give it a try. BTW: there are some minor bugs in that patch; for example, don't start slapd with -F :). I should either submit a new one, or commit the whole stuff, but perhaps I'd wait for 2.4.12 to be out. 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#5663) Declaring substitute syntax as LDAP syntax
by ando＠sys-net.it 16 Sep '08

16 Sep '08

Michael Ströder wrote: > Pierangelo Masarati wrote: >> I have a patch >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-x-subst-2008-09-16.patch> >> that implements support for "ldapsyntax" (slapd.conf) and >> "olcLdapSyntaxes" (back-config) in order to allow run-time configuration >> of syntaxes that have NULL handlers and thus need to have the X-SUBST >> extension in place. > > You rock! I'll give it a try. > >> ldapsyntax ( <my-syntax-oid> NAME 'MySyntax' >> DESC 'this is the description' >> X-SUBST 1.3.6.1.4.1.1466.115.121.1.15 ) > > Looking at RFC 4512 the SyntaxDescription does not mention NAME > (although I'd appreciate it would). Correct. I was mistaken by the presence of the field in the schema stucture of include/ldap_schema.h: typedef struct ldap_syntax { char *syn_oid; /* REQUIRED */ char **syn_names; /* OPTIONAL */ char *syn_desc; /* OPTIONAL */ LDAPSchemaExtensionItem **syn_extensions; /* OPTIONAL */ } LDAPSyntax; We should probably trim it, although it could (would) break binary interoperability at the libldap level. I'd note rfc4517 does not mention extensions, either... 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs