openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#8616) olcSpNopresent and olcSpReloadHint can't be modified dynamically
by elecharny＠symas.com 14 Mar '17

14 Mar '17

Full_Name: Emmanuel Lecharny Version: 2.4.44 OS: CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.246.56.212) Adding either the olcSpNoPresent/olcSpReloadHint into a syncprov overlay is possible using slapd.d. It the values are set to TRUE, you can remove them. If you set them to FALSE, trying to remove the value get you an error 80. Second thing : set the value to TRUE (works), then change it to FALSE (works). Now, you are stuck : you can't revert it to TRUE or remove them. Third thing : set the value to FALSE (works), then you can't change it to TRUE or delete the attribute. There is no other way that modifyin the ldif file to get it back on its feet.

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by quanah＠symas.com 13 Mar '17

13 Mar '17

--On Monday, March 13, 2017 12:55 PM -0400 Matthew Berg <mberg(a)synacor.com> = wrote: > "After investigating the server setup, there are a few problems here. > The new server was being configured with sid=3D001 which was already > assigned to=C2=A0the original master. That's clearly going to screw = things > up." I'm aware of what Howard's original response was. That has nothing to do=20 with what the problem was, or the later 100% reproducible test I provided=20 him that did not have that problem. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog
by mberg＠synacor.com 13 Mar '17

13 Mar '17

"After investigating the server setup, there are a few problems here. The new server was being configured with sid=001 which was already assigned to the original master. That's clearly going to screw things up." On Mon, 2017-03-06 at 10:03 -0800, Quanah Gibson-Mount wrote: > --On Monday, March 06, 2017 5:24 PM +0000 mberg(a)synacor.com wrote: > > > Reading back over the report on ITS-8281, the reported behavior > > would have been a collision of generating a new contextCSN as well > > as duplicating the producer's SID. So it's generated contextCSN > > would have masked the one it never committed from the original > > master. > > I'm not sure what you mean by duplicating the producer's SID. Both > nodes > had unique SID values. There were no duplicated SIDs. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP: > <http://www.symas.com> > -- Matthew Berg <mberg(a)synacor.com> This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.

1 0

(ITS#8615) Dovecot can't connect to openldap over starttls
by info＠gwarband.de 11 Mar '17

11 Mar '17

Full_Name: Tobias Warband Version: 2.4.40+dfsg-1+deb8u2 OS: Debian 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (149.172.171.148) Hello, I'm trying to configure dovecot with ldapconnection over starttls (Secure LDAP). I belief the problem is something with the methode ldap_start_tls_s() or ldap_int_tls_connect() that's called from the first. Other software can connect to the openldapserver e.g. postfix, openxchange, apache. All logs and configs are in the URL below. https://gwarband.de/openldap/dovecot.log https://gwarband.de/openldap/dovecot-ldap.conf https://gwarband.de/openldap/openldap.log https://gwarband.de/openldap/trace.dump Greetings Tobias

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 11 Mar '17

11 Mar '17

> From: Ond=F8ej Kuzn=EDk > Sent: Thursday, March 9, 2017 5:32 AM >=20 > Is that something that you can replicate reliably? Would you be able = to > share the configuration (especially overlays)? Unfortunately it is not deterministically reproducible, it just randomly happens occasionally. I haven't noticed anything in particular that = seems to be a pattern or in common on each occurrence. I will shoot you a copy of = my configuration directly. > Based on the traces I've taken while testing, I haven't seen anything > suspicious that the perl library would generate, but if you have the > packets or slapd ber dumps, they might help confirm this for your case > as well. I haven't been able to get a packet capture or leave debugging on long enough to catch it since the crash is so sporadic and it only occurs on = a production system at widely interspersed intervals :(. Thanks for looking at it.

1 0

(ITS#8614) Test suite fails when using --with-threads=no
by bwright＠intacct.com 10 Mar '17

10 Mar '17

Full_Name: Brian Wright Version: 2.4.44 OS: CentOS 6.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.136.225.254) When configuring and compiling OpenLDAP using --with-threads=no flag, the test suite fails to complete. It seems the test suite appears to be dependent on threads for a successful run. Unfortunately, this test suite issue makes it difficult to know if LDAP is functioning correctly when compiled without threads. Reproduce this by using the following: ./configure --with-threads=no make depend make make test Note, all backends fail at least one test when threads are disabled. For example, if you set --enable-bdb=no --enable-hdb=no and leave only --enable-mdb=yes, mdb itself fails the test suite. The same for bdb and hdb if they are the only backends available. If you plan on retaining --with-threads=no feature, someone might want to update the test suite to properly test LDAP when threads are disabled. Or alternatively, inform the user that 'make test' doesn't support testing LDAP when threads are disabled.

1 0

Re: (ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by quanah＠symas.com 09 Mar '17

09 Mar '17

--On Thursday, March 09, 2017 12:54 AM +0000 quanah(a)openldap.org wrote: > It is possible to set up slapo-dynlist to operate as a replacement for > slapo-memberOf, and it is safe in a replicated environment. The tricky > part of using slapo-dynlist is that membership information must be > maintained by updating user objects rather than by updating group > objects, which may be difficult for end users depending on how they > perform group management. It's also possible to do this in the reverse direction. I.e., normal static groups that will populate memberOf in the user entry. To do this, you have to hack the dyngroup schema, changing groupOfURLs from STRUCTURAL to AUXILIARY. In the slapd config, the dynlist config looks like: dynlist-attrset groupOfUrls memberURL memberOf Then we can create some groups: root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=testgroup" dn: cn=testgroup,ou=Group,dc=example,dc=com objectClass: groupOfNames cn: testgroup member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=alttestgroup" dn: cn=alttestgroup,ou=Group,dc=example,dc=com objectClass: groupOfNames cn: alttestgroup member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com The user entry looks like: root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com "cn=Marice McCaugherty" objectClass memberOf memberURL dn: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: groupOfURLs memberURL: ldap:///dc=example,dc=com??sub?(member=cn=Marice McCaugherty,ou=Pro duct Testing,dc=example,dc=com) memberOf: cn=testgroup,ou=Group,dc=example,dc=com memberOf: cn=alttestgroup,ou=Group,dc=example,dc=com Doing it this way means that people currently using memberOf wouldn't need to change how group management is done. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 09 Mar '17

09 Mar '17

Hi Paul, I've tried to reproduce the issue you're seeing, setting up deltasync replication and trying to send various combinations of modifies to the master. However, none of that has crashed either the server receiving the modification, nor the other servers it replicated to. No change either when the second server has to replicate directly off the accesslog database without the benefit of syncprov's sessionlog. Is that something that you can replicate reliably? Would you be able to share the configuration (especially overlays)? Based on the traces I've taken while testing, I haven't seen anything suspicious that the perl library would generate, but if you have the packets or slapd ber dumps, they might help confirm this for your case as well. Regards, Ondrej

1 0

Re: (ITS#8613) slapo-memberOf documentation update (Unsafe to use with replication)
by michael＠stroeder.com 09 Mar '17

09 Mar '17

quanah(a)openldap.org wrote: > root@u16test:/opt/symas/etc/openldap# /opt/symas/bin/ldapsearch -x -LLL -H > ldap:/// -D dc=example,dc=com -w secret -b dc=example,dc=com cn=testgroup > dn: cn=testgroup,ou=Group,dc=example,dc=com > objectClass: groupOfURLs > cn: testgroup > memberURL: ldap:///dc=example,dc=com??sub?(memberOf=cn=testgroup,ou=Group,dc=e > xample,dc=com) > member: cn=Marice McCaugherty,ou=Product Testing,dc=example,dc=com For this particular use-case it would be nice if memberURL could automagically reference the group entry itself. Something similar to the set syntax: memberURL: ldap:///dc=example,dc=com??sub?(memberOf=*this/entryDN*) Well, a simple plugin class in web2ldap will also do... :-) Ciao, Michael.

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 09 Mar '17

09 Mar '17

The code making the update is in perl, using Net::LDAP, and looks like: $entry->replace(eduPersonAffiliation => \@eduPersonAffiliation); For the case of the crash, the array @eduPersonAffiliation is empty, effectively deleting the attribute. I'm not 100% sure what this generates on the wire, I'd have to debug it. I can say it's the same code that's been running for a decade or so with no issues. The schema that defines the attribute is available at: https://spaces.internet2.edu/display/macedir/OpenLDAP+eduPerson

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