- openldap-bugs - openldap.org

Re: (ITS#8621) Unique through multiple attribute
by michael＠stroeder.com 19 Mar '17

19 Mar '17

tatarenko(a)alpha-it.ru wrote: > When use Unique overlay it is not possible to prevent users from inserting value > in attributeA (like otherMailbox) that is already was used in attributeB (like > mail) through whole domain. > If i put multiple attributes to Unique overlay it still search through one > attribute. > If i use > olcUniqueURI: ldap:///dc=instatsport,dc=com?mail,otherMailbox,proxyAddresses?sub > Unique overlay still make this search for mail: > unique_search (|(mail=123(a)example.com)) > And this search for otherMailbox > unique_search (|(otherMailbox=123(a)example.com)) I'd say it works as designed and there is no bug. The work-around for your use-case is to use SUP to derive from a common attribute type. But this should be discussed on openldap-technical mailing list. Ciao, Michael.

1 0

(ITS#8621) Unique through multiple attribute
by tatarenko＠alpha-it.ru 18 Mar '17

18 Mar '17

Full_Name: Tatarenko Vasily Version: 2.4.44 OS: Freebsd 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.74.103.57) When use Unique overlay it is not possible to prevent users from inserting value in attributeA (like otherMailbox) that is already was used in attributeB (like mail) through whole domain. If i put multiple attributes to Unique overlay it still search through one attribute. If i use olcUniqueURI: ldap:///dc=instatsport,dc=com?mail,otherMailbox,proxyAddresses?sub Unique overlay still make this search for mail: unique_search (|(mail=123(a)example.com)) And this search for otherMailbox unique_search (|(otherMailbox=123(a)example.com))

1 0

Re: (ITS#8620) GCC error undeclared PTHREAD_MUTEX_ROBUST
by blissend＠gmail.com 18 Mar '17

18 Mar '17

--94eb2c184874dd3bec054af90cab Content-Type: text/plain; charset=UTF-8 Ahah, it compiles if you remove lines 277-279 which was... #if defined(MDB_OWNERDEAD) && (MDB_USE_ROBUST) #define MDB_ROBUST_SUPPORTED 1 #endif However, I'm not sure that's what one should do. --94eb2c184874dd3bec054af90cab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Ahah, it compiles if you remove lines 277-279 which was...= <div><br></div><div><div>#if defined(MDB_OWNERDEAD) && (MDB_USE_ROB= UST)</div><div>#define MDB_ROBUST_SUPPORTED<span class=3D"gmail-Apple-tab-s= pan" style=3D"white-space:pre"> </span>1</div><div>#endif</div></div><div><= br></div><div>However, I'm not sure that's what one should do.</div= ></div> --94eb2c184874dd3bec054af90cab--

1 0

(ITS#8620) GCC error undeclared PTHREAD_MUTEX_ROBUST
by blissend＠gmail.com 18 Mar '17

18 Mar '17

Full_Name: Adam Carlin Version: lmdb 0.9.20 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.27.217.230) I'm using Windows 10 with msys2 64bit (http://www.msys2.org/) which utilizes mingw-w64. When I compile lmdb (https://github.com/LMDB/lmdb/tree/mdb.RE/0.9) v0.9.20 it spits out the error message below... blissend@shockedloris MSYS /c/Compile/lmdb/libraries/liblmdb $ make gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized -c mdb.c mdb.c: In function mdb_env_setup_locks: mdb.c:4853:17: warning: implicit declaration of function pthread_mutexattr_setrobust [-Wimplicit-function-declaration] if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); ^~~~~~~~~~~~~~~~~~~~~~~~~~~ mdb.c:4853:53: error: PTHREAD_MUTEX_ROBUST undeclared (first use in this function) if (!rc) rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST); ^~~~~~~~~~~~~~~~~~~~ mdb.c:4853:53: note: each undeclared identifier is reported only once for each function it appears in mdb.c: In function mdb_mutex_failed: mdb.c:362:37: warning: implicit declaration of function pthread_mutex_consistent [-Wimplicit-function-declaration] #define mdb_mutex_consistent(mutex) pthread_mutex_consistent(mutex) ^ mdb.c:10220:10: note: in expansion of macro mdb_mutex_consistent rc2 = mdb_mutex_consistent(mutex); ^~~~~~~~~~~~~~~~~~~~ make: *** [Makefile:83: mdb.o] Error 1 Anyway to fix this? If this helps, I've noticed that line 4853 for above error has an if check for MDB_ROBUST_SUPPORTED which gets defined on line 278. However the missing declaration of pthread_mutexattr_setrobust is in another if check above line 278.

1 0

Re: (ITS#8506) Authentication issue in ldap client machine after successfully integrating ldap in freenas OS
by quanah＠symas.com 18 Mar '17

18 Mar '17

Hello, There is no evidence of a bug with OpenLDAP based on your report. The OpenLDAP ITS is for bug reports. Usage/configuration questions such as this report should be directed to the OpenLDAP Technical mailing list. <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. --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#8614) Test suite fails when using --with-threads=no
by quanah＠symas.com 18 Mar '17

18 Mar '17

--On Friday, March 10, 2017 9:43 PM +0000 bwright(a)intacct.com wrote: > 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. Thanks for the report and great suggestion. --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#8500) typo in slapo-ppolicy(5)
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Monday, September 12, 2016 3:39 PM +0000 michael(a)stroeder.com wrote: Thanks for the report. This was fixed as part of the work on ITS#8185. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8619) Enhancement request: Nested group support using dynlist recursion
by christ.klinge＠web.de 17 Mar '17

17 Mar '17

Full_Name: Christopher Klinge Version: 2.4.44 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.193.142.51) As of right now, dynlist can be used to expand one level of nesting: overlay dynlist dynlist-attrset parentGroup childGroup dn: cn=Parent Group,ou=Groups,dc=example,dc=com objectClass: parentGroup cn: Parent Group childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub? dn: cn=Child Group,ou=Groups,dc=example,dc=com objectClass: childGroup cn: Child Group member: cn=User A,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com Querying the parent group will return: dn: cn=Parent Group,ou=Groups,dc=example,dc=com objectClass: parentGroup cn: Parent Group childGroupURL: ldap:///cn=Child Group,ou=Groups,dc=example,dc=com?member?sub? member: cn=User A,ou=People,dc=example,dc=com member: cn=User B,ou=People,dc=example,dc=com member: cn=User C,ou=People,dc=example,dc=com If cn=Child Group were to be a parent group itself, no further expansion would take place. I propose enabling dynlist recursion and adding a new configuration directive: dynlist-rec-attrset <group-oc> [<URI>] <URL-ad> <rec-ad> [[<mapped-ad>:]<member-ad>] Except for rec-ad, all parameters behave exactly like those of dynlist-attrset. The attribute rec-ad is mandatory. It is a comma separated list of attributes for which dynlist recursion is enabled. By adding a new directive, backwards compatibility is guaranteed. I suggest using a depth counter to prevent infinite loops. A configurable threshold with a fairly small default value is both light weight and sufficiently rigorous. Logging a suitable warning message upon reaching the threshold would inform the administrator about possible loops.

1 0

Re: (ITS#8465) ldapsearch & slapcat : different output
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Friday, July 15, 2016 4:15 PM +0000 norbert.massa(a)yopmail.com wrote: > Full_Name: Norbert MASSA > Version: 2.4.40 > OS: CentOS 7.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.240.254.57) Hi Norbert, There's virtually nothing to go on in this bug report. I.e. no configuration information, etc. What backend were you using (bdb? hdb? mdb?) etc. I'd also note that the ldapsearch you provided would not give a complete backup (It's missing dumps of the operational attributes). --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#8470) LastBind Module Issue
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Thursday, July 28, 2016 12:59 PM +0000 avijeett007(a)gmail.com wrote: Hello, This does not sound like a report for a bug in the OpenLDAP Software. OpenLDAP does not distribute startup scripts. I would suggest following up with your OS provider, since running slapd manually works as expected. Regards, 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#8477) OpenLDAP.org has a broken TLS certificate
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Thursday, August 11, 2016 5:53 AM +0000 demiobenour(a)gmail.com wrote: > Also, why the self-signed certificate at all? ??Let's Encrypt is > providing free certificates. This should now be fixed. --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#8617) Seg-fault while using meta database and rwm overlay together
by quanah＠symas.com 17 Mar '17

17 Mar '17

--On Wednesday, March 15, 2017 11:51 PM +0000 jaroslaw.wencel(a)gmail.com wrote: > Full_Name: Jaroslaw Wencel > Version: 2.4.42 > OS: Ubuntu 16.04.1 > URL: > Submission from: (NULL) (46.227.243.233) > > > Hi > > I'm trying to develop configuration which includes Active Directory > catalogue into main LDAP tree I have in my configuration. Everything > works well while using slapd-meta as long as I do not try to combine it > with rwm overlay. > > LDAP crashes while invoking modrdn change (refer to attached > crashme.ldif) with the configuration as in config.ldif. > > modrdn change works well until I add dn: > olcOverlay={0}rwm,olcDatabase={1}meta,cn=config to the configuration. > > I'm using OpenLDAP 2.4.42 installed from Ubuntu repositories (latest > version from 16.04.01). > I have uploaded > ftp://ftp.openldap.org/incoming/Jaroslaw-Wencel-170315.tgz to the ftp > server, archive file contains: > - config.ldif - dump of ldap configuration from the moment modrdn > operation crashes the server > - crashme.ldif - the ldif file I'm using for invoking modrdn operation > - crash.logs - slapd daemon log > > Please let me know if you have any further questions Hi, Thanks for the report! There are a number of known existing issues with slapo-rwm, so the detail provided here is quite useful. Regards, 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#8615) Dovecot can't connect to openldap over starttls
by quanah＠symas.com 16 Mar '17

16 Mar '17

--On Saturday, March 11, 2017 11:55 AM +0000 info(a)gwarband.de wrote: > 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. Hi Tobias, The ITS system is for reporting bugs in OpenLDAP. Nothing in this report indicates a bug with OpenLDAP. In fact the information you provide about other processes being able to connect to OpenLDAP without inssue further indicate no bug with OpenLDAP. Generally, I would advise you seek support from the Dovecot authors, as it is their product that is having issues, and they should be able to provide accurate and detailed information on how to properly configure their software to interface with LDAP. Alternatively, you may wish to try the openldap-technical list if discussing with the Dovecot community does not resolve the problem. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8618) ldapsearch - unexpected behavior with "-h URI -p PORT"
by alex＠r42.ch 16 Mar '17

16 Mar '17

Full_Name: Alexandre Rosenberg Version: 2.4.44 OS: Linux - CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (125.30.6.137) I found some unexpected behavior when using both '-h' and '-p' option with ldapserach. == Reproduce: - Use the '-h' option with an invalid hostname such as a URI - Also set a (valid) port using the '-p' option == Result: If those condition are met, ldapearch seem to always connect to localhost on port 389 $ ldapsearch -x -d 255 -h ldap://localhost -p 10389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 == Expected behavior: Failure due to invalid hostname == Note: This *only* happens when both '-h' and '-p' are used. When only '-h' is used, following happens which seem fine: $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine == Additional example: Bellow are some more example - note adding "/" to the hostname is enough to trigger the issue. 1. $ ldapsearch -x -d 255 -h example.org -p 10636 -> Connects to example.org on port 10636 (as expected) 2. $ ldapsearch -x -d 255 -h /example.org -p 10636 -> Connects to localhost on port 389 (!) - note the added "/" 3. $ ldapsearch -x -d 255 -h /example.org Running the command will give you the debug output (which I omitted here). Note I am using openldap 2.4.44.

1 0

(ITS#8617) Seg-fault while using meta database and rwm overlay together
by jaroslaw.wencel＠gmail.com 15 Mar '17

15 Mar '17

Full_Name: Jaroslaw Wencel Version: 2.4.42 OS: Ubuntu 16.04.1 URL: Submission from: (NULL) (46.227.243.233) Hi I'm trying to develop configuration which includes Active Directory catalogue into main LDAP tree I have in my configuration. Everything works well while using slapd-meta as long as I do not try to combine it with rwm overlay. LDAP crashes while invoking modrdn change (refer to attached crashme.ldif) with the configuration as in config.ldif. modrdn change works well until I add dn: olcOverlay={0}rwm,olcDatabase={1}meta,cn=config to the configuration. I'm using OpenLDAP 2.4.42 installed from Ubuntu repositories (latest version from 16.04.01). I have uploaded ftp://ftp.openldap.org/incoming/Jaroslaw-Wencel-170315.tgz to the ftp server, archive file contains: - config.ldif - dump of ldap configuration from the moment modrdn operation crashes the server - crashme.ldif - the ldif file I'm using for invoking modrdn operation - crash.logs - slapd daemon log Please let me know if you have any further questions Thanks Jaroslaw Wencel

1 0

(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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs