openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

ghenry(a)OpenLDAP.org wrote: > Too tired today :-( For some reason I was talking about slapo-unique, as I'm > writing that up just now. Just to avoid (or increase :) confusion when you'll be back from relax, I don't recall working at slapo-unique recently. AFAIK, the old and the new config statements live together in perfect harmony, although unique_uri is preferable as it is more expressive. I have added a restrict=<uri> parameter to slapo-constraint, which allows to optionally restrict the entries the constraint would apply to. I have also allowed the <attr> to actually be an attribute list, in case one needs to apply the same constraint to more than one. Finally, the "set" type is now available. It uses the ACL sets' syntax, which, AFAIK, is still undocumented. 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 ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- ando(a)sys-net.it wrote: > Gavin Henry wrote: > > >> A note should already be in HEAD's slapo-translucent(5). > > > > Yeah, I saw that. I was reading the code and if I understand > correctly, old > > config directives will still work as long as the new URI directive > isn't present? > > Not sure what you mean there. The uri directive, afaik, is related to > > the captive database, and (relatively) transparent to the overlay. If > > you use translucent on a local instance of back-sql, there would be no > > uri directive at all. Too tired today :-( For some reason I was talking about slapo-unique, as I'm writing that up just now. Sorry for the confusion. -- 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#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

Gavin Henry wrote: >> A note should already be in HEAD's slapo-translucent(5). > > Yeah, I saw that. I was reading the code and if I understand correctly, old > config directives will still work as long as the new URI directive isn't present? Not sure what you mean there. The uri directive, afaik, is related to the captive database, and (relatively) transparent to the overlay. If you use translucent on a local instance of back-sql, there would be no uri directive at all. 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 ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- "Pierangelo Masarati" <ando(a)sys-net.it> wrote: > Gavin Henry wrote: > > ----- ando(a)sys-net.it wrote: > > > >> RFC 3062 password modification extended operation on locally stored > > >> credentials is now in HEAD; please test and report. > >> > > > > I'll hold back adding a note in the Admin Guide about this. I think > it's best placed in the man page anyway. > > A note should already be in HEAD's slapo-translucent(5). Yeah, I saw that. I was reading the code and if I understand correctly, old config directives will still work as long as the new URI directive isn't present? My reason for asking is that I thought I might need to update the Upgrading section of the Admin Guide? > Perhaps we want the config statements sorted differently (e.g. lexicographically)? Doesn't bother me. 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#5656) Bind operations with translucent overlay
by ando＠sys-net.it 22 Sep '08

22 Sep '08

Gavin Henry wrote: > ----- ando(a)sys-net.it wrote: > >> RFC 3062 password modification extended operation on locally stored >> credentials is now in HEAD; please test and report. >> > > I'll hold back adding a note in the Admin Guide about this. I think it's best placed in the man page anyway. A note should already be in HEAD's slapo-translucent(5). Perhaps we want the config statements sorted differently (e.g. lexicographically)? 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 ghenry＠OpenLDAP.org 22 Sep '08

22 Sep '08

----- ando(a)sys-net.it wrote: > RFC 3062 password modification extended operation on locally stored > credentials is now in HEAD; please test and report. > I'll hold back adding a note in the Admin Guide about this. I think it's best placed in the man page anyway. 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#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

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