openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Work Queues, MDB_NOTLS, MDB_NOLOCK, and Concurrent Map() Over Sub Database
by A R 17 Feb '16

17 Feb '16

Hello, I’m using a work queue to manage concurrency. Currently jobs manage their own transactions, and barriers are used to enforce exclusive writer access. Naturally, MDB_NOTLS and MDB_NOLOCK are set on the environment. However, I need to implement a concurrent map algorithm over a sub database. The algorithm would be simple: a reader would enqueue worker jobs–each having a strong, immutable reference to the transaction and cursor, and copies of the key and value pointers. The transaction and cursor would only be destroyed after all of the sibling jobs have completed/canceled/failed. I’ve read that transactions and cursors should not be shared between threads, but in this use case, the creation and destruction operations are atomic since only 1 thread, or 2 distinct threads, receive the “beginReadTransaction” and “endReadTransaction” jobs at two distinct moments in time, in a guaranteed order. Are there any caveats in this approach? Thanks, A. Robinson

1 0

Shutting down some slapd listeners
by Hallvard Breien Furuseth 16 Feb '16

16 Feb '16

Sometimes I want slapd to stop listening for new connections to ldap:// and ldaps://, but keep listening to ldapi://, for maintenance before shutdown. One way would be to extend the 'gentlehup' config option with a list of which URIs it should affect. Or we could add some sort of 'command language' to cn=config/cn=monitor. Or should I play some temporary tricks with iptables or whatever, so new connections never reach slapd? I've never tried that. -- Hallvard

3 2

Re: SSL/TLS passphrase not being prompted for at startup
by Raja T Nair 16 Feb '16

16 Feb '16

Hi Quanah, Thanks for the response. I will try LTB builds. But just curious, I am using centos. are centos builds also known to be buggy? Warm Regards, Raja. On 16 February 2016 at 03:21, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Monday, February 15, 2016 11:34 PM +0530 Raja T Nair < > rtnair(a)gmail.com> wrote: > > >> >> >> Hi, >> >> >> OpenLDAP version: 2.4.40-8.el7.x86_64 >> >> OS: CentOS 7.0.1406 >> > > Builds from RedHat link to the very broken MozNSS libraries, which are > likely the source of your issue. You should avoid their broken builds > entirely. I would suggest getting the LTB project builds that are sanely > linked to OpenSSL. > > <http://ltb-project.org/wiki/download#openldap> > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc > -- :^)

2 1

Disallow ldap operations without start_tls
by Joshua Schaeffer 16 Feb '16

16 Feb '16

I have setup my OpenLDAP server to use TLS and I can successfully bind/search/update/etc over a TLS connection. I have also set olcSecurity. Here is my database: root@baneling:~/ldif_files# slapcat -F /etc/ldap/slapd.d -s olcDatabase={1}mdb,cn=config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=harmonywave,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=harmonywave,dc=com olcRootPW:: e1NTSEF9dUhDcE1jUUJoWlpuc0twRHBNQkVCUGtmTFA5SC9EYUU= olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: caa04334-6857-1035-9fbb-dd6671002504 creatorsName: cn=admin,cn=config createTimestamp: 20160215174631Z olcSecurity: simple_bind=256 olcSecurity: ssf=256 entryCSN: 20160215210910.287865Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20160215210910Z When I try to do any sort of ldap operation without the -ZZ option then slapd returns a "TLS confidentiality required" message as it should and as I expect. However, If I sniff the wire, I still see the attempted bind request with my DN and password in plaintext. Is there any way to force clients to use start_tls without sending any credentials over the wire (a.k.a. return an error message before a bind request is actually submitted) or does this have to be controlled outside of OpenLDAP? Thanks, Joshua

4 7

SSL/TLS passphrase not being prompted for at startup
by Raja T Nair 15 Feb '16

15 Feb '16

Hi, OpenLDAP version: 2.4.40-8.el7.x86_64 OS: CentOS 7.0.1406 While starting openldap service with command line: systemctl start slapd, it does start well, but does not ask for passphrase of the TLS certificate included. The service listens on ports 636 and 389. When the first request over port 636 is received, the server prompts for passphrase in the console. While this behavior is fine when I run slapd on an attached console, it stops me from running it as a system startup service. Can somebody help me to make slapd to prompt for passphrase during startup? Thanks and Regards, Raja. -- :^)

2 1

Incomplete members from dynlist group when Paged Results control is specified
by Kartik Subbarao 15 Feb '16

15 Feb '16

I'm using Google Apps Directory Sync (GADS) to synchronize group memberships from an OpenLDAP (2.4.41) directory. GADS uses the Paged Results control (1.2.840.113556.1.4.319) to retrieve results in batches of 1000. One of the searches that it does is as follows: base: ou=groups,dc=example,dc=com filter: (mail=*(a)example.com) attributes requested: member owner [and some others] There are more than 1000 groups that match, so it returns the results in batches as expected. Some of these groups are dynlist groups that have memberURL attributes set, which dynamically expand the member attribute when retrieved. For dynlist groups that show up in the first page of results, their members are properly retrieved. But after the first page, the results for dynlist groups only return a subset of the proper membership. As a result, an incomplete membership is being synced to Google for those subsequent groups, and the missing members are causing problems. To rule out GADS from being the root cause of the problem, I ran a standalone perl script to search with the Paged Results control, with the page size set to a small number of entries. Just as with GADS, after the first page of results, the entries started to return fewer members from dynlist groups than should be returned. With a page size of 1, the second dynlist group started to show fewer members (125 vs 127). My guess is that the dynlist code is somehow getting confused by the presence of the Paged Results control in the top-level search, when it does its internal searches to retrieve the individual group memberships. I wanted to ask whether this is enough detail to file an ITS, or whether more information was desired. It could take some more time to put together a generically reproducible LDIF file, so I figured I would post this now in case someone familiar with the dynlist code might recognize this and see how the presence of the Paged Results control might be interfering with its behavior. Thanks, -Kartik

1 1

LDAP log lags in the ldap.log
by Daniel Jung 12 Feb '16

12 Feb '16

based on the timestamp in the ldap.log, it is about 10-15 minutes older than current time. I see a lot of ABANDON msgs which i suspect that there are way too many queries (not ldap connection itself) in a connection. Also, the log shows the constant logs of follwing as well: connection_input: conn=321629 deferring operation: pending operations connection_input: conn=318818 deferring operation: too many executing Looking thru the archive that this is an issue on the client side, and I believe that's true based on the ABANDON msgs on long lasted session ids. I was using logging set to stats, sync . I have changed to none and the symptom of lagging of log timestamp has disappeared and queries are working properly again. My question is, is there a way to safely log stats without hampering performance to the point queries are not returing at all ? I am using openldap-2.4.39 ( yes i should upgrade soon :( ) Thanks

2 1

Member of nested groups of different classes
by Chris 12 Feb '16

12 Feb '16

Dear All, some users are member of a groupOfNames (RFC2307bis Schema). This group is member of a mailGroup (Postfix Schema). This mailGroup is member of another mailGroup. (Nested) membership in this last group defines access rights for an application. My question: is the memberOf overlay able to recursively find all groups one is member of, if they use all the same "member" attribute (memberof.member-ad), but have different structural classes (memberof-group-oc)? Is there a (perl?) script that is able to find all groups one is member-of? - Chris

2 1

Re: rebuilding the DIT
by Timothy Keith 12 Feb '16

12 Feb '16

On Thu, Feb 11, 2016 at 7:05 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > If you want answers, keep your replies on the list. > > Thanks. > > > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > A division of Synacor, Inc I used this slapcat, I did not specific a config database. slapcat -v -l backup.ldif Tim

3 3

paged results control results in full db search?
by Geert Hendrickx 12 Feb '16

12 Feb '16

Hi, We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by defaults uses the paged results control (RFC 2696) to limit search results. This client initially issues an objectclass=* search with one-level scope to list the first-level objects/trees on the LDAP DIT, which you can then browse/expand by clicking on them. On a large db, we noticed this initial search hits the timelimit, even though the equivalent command line search is instant. I found the difference is in using the paged result control: ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow ldapsearch -s one objectclass=\* objectclass => fast The slapd stats+trace logging of each is in attachment. Notice the large number of objects being skipped with "scope not okay" in the first, where this does not happen in the second. This slows down the search, and on a very large db, makes it exceed the configured 60 seconds timelimit. A third variant, setting the sizelimit explicitly, avoids the issue: ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast Is this expected behaviour? Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical