openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

Re: (ITS#5572) Append global ACL to new backends
by hyc＠symas.com 20 Jun '08

20 Jun '08

Rein Tollevik wrote: > Howard Chu wrote: >> rein(a)OpenLDAP.org wrote: >>> The global ACLs are not added to newly created backends, i.e a server >>> restart >>> must be done before they are included. The patch at the end should >>> fix this. OK >>> to commit Howard? >> My preference here would be to rip out everything that appends the >> global ACLs and instead change the access_allowed checker to reference >> the global ACLs directly when needed. > > Agreed, that would also fix the problem that dynamic updates to the > global ACLs requires a restart to be effective. I can look into this > next week. To be sure I have the semantics correct, it should be to > evalutate ALCs local to the backend first, then the global, until a > matching entry has been found? Right. Thanks for investigating this. -- -- 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#5565) slapd crashes due to SIGPIPE
by hyc＠symas.com 20 Jun '08

20 Jun '08

John Morrissey wrote: > On Tue, Jun 17, 2008 at 03:44:39PM -0700, Howard Chu wrote: >>> We had been running 2.3.41 plus the fix for ITS 5469, but upgraded to >>> RE23 as of about a week ago to make sure a fix wasn't already present. >>> Below is a representative backtrace. >> This trace is not indicative of a crash. You have to tell gdb not to stop >> when SIGPIPE is received in order to get an accurate view of the program >> behavior: "handle SIGPIPE nostop" > > Ach, I didn't consider that gdb would be stopping on these signals on its > own. New backtrace is below. > > BTW, how does one retitle a Jitterbug bug? I didn't see a way to > authenticate to the web interface; does Jitterbug accept e-mail commands to > manipulate bugs? Only OpenLDAP engineering team members can authenticate. We don't re-title bug reports. > Program received signal SIGABRT, Aborted. > [Switching to Thread -1963996240 (LWP 22635)] > 0xb7bb1947 in raise () from /lib/tls/libc.so.6 This trace resembles ITS#5401, which was only fixed in RE24. You can look at the patch to syncprov.c there. There's no plan to make another 2.3 release at the moment. > Thread 12 (Thread -1963996240 (LWP 22635)): > #0 0xb7bb1947 in raise () from /lib/tls/libc.so.6 > No symbol table info available. > #1 0xb7bb30c9 in abort () from /lib/tls/libc.so.6 > No symbol table info available. > #2 0xb7bab05f in __assert_fail () from /lib/tls/libc.so.6 > No symbol table info available. > #3 0x0806bba2 in connection_state_closing (c=0x90342f48) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/connection.c:765 > state =<value optimized out> > __PRETTY_FUNCTION__ = "connection_state_closing" > #4 0x0807bc34 in send_ldap_ber (conn=0x90342f48, ber=0x8aefbdac) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:162 > err = 6 > sd = 135491153 > bytes =<value optimized out> > #5 0x0807dd19 in slap_send_search_entry (op=0x8aefbf20, rs=0x8aefc1cc) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/result.c:1137 > a_flags = 0x1<Address 0x1 out of bounds> > berbuf = {buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000$Ñ\237\212\232Ñ\237\212Rá\237\212\000\000\000\000\000\000\000\000\210À\"\b\000\000\000\000\210À\"\b\000\000\000\000Ì\rò·\030\000\000\000Ì\rò·\000\000\000\000xÂï\212\030Ÿï\212ÜÀñ·\r\000\000\000\210À\"\b\000\000\000\000ÔÉñ·\f\000\000\000xÂï\2128Ÿï\212ðÅñ·\fÀ\237\212hŸï\212\f\000\000\000tŸï\212\001\000\000\000 ¿ï\212ÈŸï\212\231t\f\bhŸï\212\f\000\000\000\001\000\000\000xÂï\212\210À\"\blŸï\212hŸï\212\206µñ·\001\000\000\000\000\000\000\000csn=,rid=001"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002<Address 0x10002 out of bounds>} > ber = (BerElement *) 0x8aefbdac > a = (Attribute *) 0x6 > i = 1 > j =<value optimized out> > rc =<value optimized out> > edn = 0x94abb97 "reqStart=20080604231418.000048Z,cn=log" > userattrs = 1 > acl_state = {as_recorded = 0, as_vd_acl = 0x0, as_vi_acl = 0x0, as_vd_acl_mask = 0, as_vd_acl_matches = {{rm_so = 0, rm_eo = 0}<repeats 100 times>}, as_vd_acl_count = 0, as_vd_access = 0x0, as_vd_access_count = 0, as_result = 0, as_vd_ad = 0x0} > attrsonly = 0 > ad_entry = (AttributeDescription *) 0x814ad90 > e_flags = (char **) 0x0 > #6 0xb79c3eaa in syncprov_qtask (ctx=0x8aefc2c8, arg=0x856d058) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/servers/slapd/overlays/syncprov.c:798 > so = (syncops *) 0x856d088 > on = (slap_overinst *) 0x819da60 > opbuf = {buffer = "ð¿ï\212c\000\000\000i¥YH\000\000\000\000ÌÀï\212\006\000\000\000\201D\207\006\000\000\000\210D\207\002\000\000\000\000\000\000\000ÿÿÿÿÿÿÿÿ\\Ø\031\b\000\000\000\000\204C\207ž\201¬\207.\000\000\000\217D\207", '\0'<repeats 12 times>, "\001", '\0'<repeats 39 times>, "LÀï\212\200", '\0'<repeats 11 times>, "\025\000\000\000kD\207\025\000\000\000kD\207", '\0'<repeats 48 times>, "\001\000\000\000&\000\000\000H/4\220\002\000\000\000\003\000\000\000\000\000\000\000ÈÂï\212\210À\"\bP»\023\bconn=38 op=1", '\0'<repeats 171 times>, ialign = -1963999248, lalign = -1963999248, falign = -2.30870617e-32, dalign = 2.1122923453963239e-312, palign = 0x8aefbff0 "\001"} > op = (Operation *) 0x8aefbf20 > be = {bd_info = 0x819d960, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0'<repeats 17 times>, "\001", be_flags = 256, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x819d728, be_nsuffix = 0x819d740, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 14, bv_val = 0x819d5e0 "cn=root,cn=log"}, be_rootndn = {bv_len = 14, bv_val = 0x819d7c8 "cn=root,cn=log"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x819d7b8, be_acl = 0x818c9e8, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8217320, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x819d440, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xb79f5660, be_private = 0x819d478, be_next = {stqe_next = 0x819dc98}} > rc =<value optimized out> > #7 0xb7f2deff in ldap_int_thread_pool_wrapper (xpool=0x814d358) at /var/jwm/ldap/openldap2.3-2.3.42-cvs-20080612/libraries/libldap_r/tpool.c:478 > ctx = (ldap_int_thread_ctx_t *) 0x8d66c548 > ltc_key = {{ltk_key = 0x80b73c0, ltk_data = 0x822c088, ltk_free = 0x80b6f10<slap_sl_mem_destroy>}, {ltk_key = 0x8218160, ltk_data = 0xbb, ltk_free = 0xb79ee2e0<bdb_locker_id_free>}, {ltk_key = 0xb79e1800, ltk_data = 0x861fd008, ltk_free = 0xb79e18d0<search_stack_free>}, {ltk_key = 0x8217638, ltk_data = 0x3a, ltk_free = 0xb79ee2e0<bdb_locker_id_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}<repeats 28 times>} > tid = 2330971056 > i = 756 > hash =<value optimized out> > #8 0xb7cc00bd in start_thread () from /lib/tls/libpthread.so.0 > No symbol table info available. > #9 0xb7c5501e in clone () from /lib/tls/libc.so.6 > No symbol table info available. -- -- 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#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Howard Chu wrote: > rein(a)OpenLDAP.org wrote: >> The global ACLs are not added to newly created backends, i.e a server >> restart >> must be done before they are included. The patch at the end should >> fix this. OK >> to commit Howard? > > My preference here would be to rip out everything that appends the > global ACLs and instead change the access_allowed checker to reference > the global ACLs directly when needed. Agreed, that would also fix the problem that dynamic updates to the global ACLs requires a restart to be effective. I can look into this next week. To be sure I have the semantics correct, it should be to evalutate ALCs local to the backend first, then the global, until a matching entry has been found? Rein

1 0

Re: (ITS#5568) Multiple Suffix not working in 2.3.39 Release.
by hyc＠symas.com 20 Jun '08

20 Jun '08

h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> Multiple suffixes are indeed supported, but your configuration is >> completely invalid. > > Why so? Looks to me like a doc bug at best - the doc should say > that _some_ backends support multiple suffixes, and for others one > can use multiple databases instead. > > Though the latter may indeed be what the poster needed. > > BDB does support multiple suffixes #if defined(BDB_MULTIPLE_SUFFIXES), > but it's undocumented except for a FAQ entry which doesn't look right: > http://www.openldap.org/faq/data/cache/342.html > I don't see how subordinates can be a substitute for multiple suffixes > in a single database, since such suffixes should presumably not be > subordinates of each other. Indeed, the idea of "multiple suffixes" is that you're using suffixes with no subordinate relation. However in that case, there is no logical reason to keep them all within the same database either. They represent totally independent namespaces then, and keeping them in a single database offers no advantages. -- -- 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#5570) Error while using MirrorMode Replication
by hyc＠symas.com 20 Jun '08

20 Jun '08

shravan.rathore(a)polaris.co.in wrote: > Full_Name: Shravan R > Version: 2.3.39 > OS: Linux 2.4.9 > URL: > Submission from: (NULL) (202.168.89.5) > > > Hi, > > I am trying the MirrorMode Replication using syncrepl on 2 Linux machines. > I followed the below configuration, but found an error. MirrorMode was not released in OpenLDAP 2.3. 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

Re: (ITS#5572) Append global ACL to new backends
by hyc＠symas.com 20 Jun '08

20 Jun '08

rein(a)OpenLDAP.org wrote: > The global ACLs are not added to newly created backends, i.e a server restart > must be done before they are included. The patch at the end should fix this. OK > to commit Howard? My preference here would be to rip out everything that appends the global ACLs and instead change the access_allowed checker to reference the global ACLs directly when needed. -- -- 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#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein The global ACLs are not added to newly created backends, i.e a server restart must be done before they are included. The patch at the end should fix this. OK to commit Howard? Rein Tollevik Basefarm AS diff -u -r1.335 bconfig.c --- servers/slapd/bconfig.c 16 Jun 2008 12:45:30 -0000 1.335 +++ servers/slapd/bconfig.c 20 Jun 2008 16:51:03 -0000 @@ -4351,6 +4355,9 @@ /* Newly added databases and overlays need to be started up */ if ( CONFIG_ONLINE_ADD( ca )) { if ( colst[0]->co_type == Cft_Database ) { + /* append global access controls */ + acl_append( &ca->be->be_acl, frontendDB->be_acl, -1 ); + rc = backend_startup_one( ca->be, &ca->reply ); } else if ( colst[0]->co_type == Cft_Overlay ) {

1 0

(ITS#5571) Don't renumber the config database
by rein＠OpenLDAP.org 20 Jun '08

20 Jun '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Dynamically adding databases that requires renumbering of the existing olcDatabase values could also renumber the config database. But the code expects that to always be index 0, and slapd fails to start again. The "prod" server from test053-syncprov-glue shows a case where this would happen. The patch at the end prevents config_renumber_one() from renumbering the config database. Howard, is this OK? Rein Tollevik Basefarm AS diff -u -r1.335 bconfig.c --- servers/slapd/bconfig.c 16 Jun 2008 12:45:30 -0000 1.335 +++ servers/slapd/bconfig.c 20 Jun 2008 14:39:41 -0000 @@ -3762,6 +3762,10 @@ char ibuf[32], *ptr1, *ptr2 = NULL; int rc = 0; + if ( !strncmp( e->e_nname.bv_val, "olcDatabase={0}config,", + STRLENOF("olcDatabase={0}config,") )) + return 0; + rc = config_rename_attr( rs, e, &rdn, &a ); if ( rc ) return rc;

1 0

(ITS#5570) Error while using MirrorMode Replication
by shravan.rathore＠polaris.co.in 20 Jun '08

20 Jun '08

Full_Name: Shravan R Version: 2.3.39 OS: Linux 2.4.9 URL: Submission from: (NULL) (202.168.89.5) Hi, I am trying the MirrorMode Replication using syncrepl on 2 Linux machines. I followed the below configuration, but found an error. # Global section serverID 1 # database section # syncrepl directives syncrepl rid=001 provider=ldap://ldap-ridr1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" syncrepl rid=002 provider=ldap://ldap-rid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +" mirrormode on The error is as follows: Config: ** successfully added syncrepl "ldap://ldap-ridr1.example.com" line 105 (syncrepl ***) /usr/local/etc/openldap/slapd.conf: line 105: syncrepl: database already shadowed. /usr/local/etc/openldap/slapd.conf: line 105: <syncrepl> handler exited with 1! This error occurs when it reads the 2nd occurance of syncrepl at retry="60 +" Please let me know, what went wrong in the configuration resulting in this error. Also, there is a warning for serverID, while reading the config file. Is this fine? reading config file /usr/local/etc/openldap/slapd.conf line 2 (serverID 1) /usr/local/etc/openldap/slapd.conf: line 2: unknown directive <serverID> outside backend info and database definitions (ignored). Thanks... Shravan R

1 0

(ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by bgmilne＠staff.telkomsa.net 19 Jun '08

19 Jun '08

Full_Name: Buchan Milne Version: 2.3.41 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.207.32.38) When both the smbk5pwd and ppolicy overlays are loaded, and an entry is in a state that requires a password change (I tested with 'pwdReset: TRUE' on the entry), the entry cannot change its password via an LDAP password change extended operation: $ ldapsearch -H ldapi:// -LLL -x "(uid=bgmilne)" pwdReset pwdPolicySubEntry dn: uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com pwdPolicySubentry: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=co m pwdReset: TRUE $ ldapsearch -H ldapi:// -LLL -x -s base -b 'cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com' @pwdPolicy dn: cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com objectClass: pwdPolicy objectClass: namedObject pwdAttribute: userPassword pwdLockout: TRUE pwdMustChange: TRUE $ ldappasswd -H ldapi:// -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Insufficient access (50) Additional info: Operations are restricted to bind/unbind/abandon/StartTLS/modify password The relevant parts of the slapd.conf follow: [...] include /usr/share/openldap/schema/ppolicy.schema include /etc/openldap/schema/local.schema pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args modulepath /usr/lib64/openldap moduleload back_monitor.la moduleload syncprov.la moduleload ppolicy.la moduleload auditlog.la moduleload smbk5pwd.so moduleload allop.so moduleload rwm.la moduleload back_relay.la TLSCertificateFile /etc/ssl/openldap/ldap.pem TLSCertificateKeyFile /etc/ssl/openldap/ldap.pem TLSCACertificateFile /etc/ssl/openldap/ldap.pem localSSF 56 loglevel 256 access to dn.exact="" by * read access to dn.exact="cn=Subschema" by * read overlay allop database bdb suffix "dc=ranger,dc=dnsalias,dc=com" directory /var/lib/ldap rootdn "cn=manager,dc=ranger,dc=dnsalias,dc=com" checkpoint 256 5 cachesize 1000 idlcachesize 3000 index objectClass eq index uidNumber,gidNumber,memberuid,member eq index uid eq,subinitial index cn,mail,surname,givenname eq,subinitial index sambaSID eq,sub index sambaDomainName,displayName,sambaGroupType eq index sambaSIDList eq index krb5PrincipalName eq index uniqueMember pres,eq index zoneName,relativeDomainName eq index sudouser eq,sub index entryCSN,entryUUID eq index dhcpHWAddress,dhcpClassData eq authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "uid=Account Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" sasl-regexp uid=(.*),cn=ranger.dnsalias.com,cn=gssapi,cn=auth ldap:///dc=ranger,dc=dnsalias,dc=com??sub?(krb5PrincipalName=$1@RANGER.DNSALIAS.COM) authz-regexp "" "" include /etc/openldap/mandriva-dit-access.conf overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 overlay ppolicy ppolicy_default "cn=default,ou=Password Policies,dc=ranger,dc=dnsalias,dc=com" overlay smbk5pwd overlay auditlog auditlog /var/lib/ldap/audit.log database monitor access to dn.subtree="cn=Monitor" by group.exact="cn=LDAP Monitors,ou=System Groups,dc=ranger,dc=dnsalias,dc=com" read by group.exact="cn=LDAP Admins,ou=System Groups,dc=ranger,dc=dnsalias,dc=com" read by * none database config rootdn cn=config rootpw xxxxx Commenting out the 'overlay smbk5pwd' results in the user being able to change their password (with identical input to the previous case): $ ldappasswd -H ldapi:// -x -D uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com -W -S New password: Re-enter new password: Enter LDAP Password: Result: Success (0) Changing the order the modules are stacked in does not seem to make a difference. I could find no other reason why the password change was not being allowed, except that smbk5pwd is interfering. I have not run this same test case on 2.4.x yet, but I remember having problems trying to change passwords on 2.4.10 with a very similar configuration, so I think it exists in 2.4.10 as well.

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs