December 2013 - openldap-technical

by Ulrich Windl

Hi! I had a problem with "empty groups": object class groupOfNames has a MUST member attribute, so you cannot create an empty group. I consider this to be a bug in the object class definition, specifically as groupOfNames is structural, and not auxillary. So in SLES empty (POSIX) groups are created with a namedObject structural class. Unfortunately because of "structural object class modification from 'namedObject' to 'groupOfNames' not allowed", the entry has to be recreated whenever the first member is added or the last member is removed to/from a group. While examining the problem,. I found out that the namedObject (rfc2307bis.schema) has ist "cn" attribute optional: ## namedObject is needed for groups without members objectclass ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top STRUCTURAL MAY cn ) I'd consider this workaround as a bug also. Two questions remaining: 1) is there a technical reason against empty groups? I'd consider them as valid as empty arrays. 2) Is it an LDAP requirement to forbid structural changes in object classes, or is it an implementation restriction? In my experience the ID of an entry is (if not the entry's UUID) more the value of DN rather than the structural objectClass... Insights? Regards, Ulrich

9 years, 9 months

4
6
0 / 0

OPENLDAP HANGS DAILY

by Borresen, John - 0442 - MITLL

All, I just restarted with the group, and the OpenLDAP software has not been upgraded - currently 2.4.23 (that will be coming...hopefully). Anyway, an issue that was brought to my attention upon starting was that slapd needs to be restarted daily. It is still running, it just stops responding (no one can log in). Nothing has, previously, been found in the logs. The other day, during my initial search through the slapd logs I found: conn=1144 op=1 SRCH attr=automountKey automountInformation <= bdb_equality_candidates: (automountKey) not indexed <= bdb_equality_candidates: (automountKey) not indexed <= bdb_equality_candidates: (automountKey) not indexed Which I added "olcDbIndex: automountKey eq" to the cn=config/olcDatabase={1}bdb.ldif. Took care of that one. But, under further investigation I am finding this, repeatedly (for slapcat, slapd, and others): Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF class: ELFCLASS32 Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/libplain.so.2: /usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32 Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/libsasldb.so.2: /usr/lib/sasl2/libsasldb.so.2: wrong ELF class: ELFCLASS32 Dec 5 00:00:02 server_name slapcat: unable to dlopen /usr/lib/sasl2/liblogin.so.2: /usr/lib/sasl2/liblogin.so.2: wrong ELF class: ELFCLASS32 Dec 5 02:00:02 server_name setroubleshoot: SELinux is preventing sendmail (system_mail_t) "read" to libsasl2.so.2 (usr_t). For complete SELinux messages. run sealert -l c4516acc-2dde-4dca-973e-86cd6686ee9f Dec 5 02:30:02 server_name setroubleshoot: SELinux is preventing sendmail (system_mail_t) "read" to libsasl2.so.2 (usr_t). For complete SELinux messages. run sealert -l c4516acc-2dde-4dca-973e-86cd6686ee9f Dec 5 02:31:08 server_name tar: nss-ldap: do_open: do_start_tls failed:stat=-1 Not sure why it should even been trying to use the these lib files, as one, we are not using SASL. Looking at "ldd slapd" it is seeing only 64-bit libraries. Anyone have any suggestions? John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Surveillance Systems Group 244 Wood St Lexington, MA 02420 Ph: (781) 981-1609 Email: john.borresen(a)ll.mit.edu<mailto:john.borresen@ll.mit.edu>

9 years, 9 months

5
7
0 / 0

Mysql to Ldap

by Burk Al

Hi, I am using mysql to store my users and mailbox information on my email server (postfix & dovecot). And I am using Postfix Admin as my front end to manage domains, users and such. I want to replace mysql with ldap server. Somehow, I need to find a way to create the same or similar structure of mysql schema on ldap server. I am not expecting a tool, magic wand to make that conversion but what is the easiest and right approach to do this? Any sample, documentation etc etc would help greatly. Thanks...

9 years, 9 months

1
0
0 / 0

[LMDB] Problem with extending size on Windows

by Alain

I encountered a problem trying to change the mapsize of an existing store. It turned out to be that the newsize argument to mdb_env_map wasn't set correctly when coming from mdb_env_open2. So I had to change the call to be: rc = mdb_env_map(env, meta.mm_address, newenv || env->me_mapsize != meta.mm_mapsize); (adding the || != test) Also I had some issues with large files (4GB) and I made some small changes which better match documentation and reported issues, but not sure if the original code was flawed or not. It is in mdb_env_map when we set the file pointer and EOF: if (newsize) { if ((SetFilePointer(env->me_fd, sizelo, &sizehi, 0) == INVALID_SET_FILE_POINTER && GetLastError() != ERROR_SUCCESS) || !SetEndOfFile(env->me_fd) || (SetFilePointer(env->me_fd, 0, NULL, 0) == INVALID_SET_FILE_POINTER && GetLastError() != ERROR_SUCCESS)) return ErrCode(); } Again, I made those changes according to what I noticed and this might not be the perfect final solution. Cheers, Alain

9 years, 9 months

2
2
0 / 0

RE: OPENLDAP HANGS DAILY

by Quanah Gibson-Mount

<http://ltb-project.org/wiki/download> --On December 5, 2013 at 2:36:07 PM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > This was built from source, the OS flavor is 5.9 (originally built on > 5.7). The rpm versions were/are too old. > > Is the link to the LTB packages? > http://ltb-project.org/wiki/documentation/openldap-rpm > > Thanks > Dave > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Thursday, December 05, 2013 2:19 PM > To: Borresen, John - 0442 - MITLL; Michael Ströder; > openldap-technical(a)openldap.org Subject: RE: OPENLDAP HANGS DAILY > > You can quickly upgrade if you use the LTB packages... Which are more > sanely built than the RH ones anyway, which I'm going to guess you are > using based on the version. > > --Quanah > > --On December 5, 2013 at 1:53:15 PM -0500 "Borresen, John - 0442 - MITLL" > <John.Borresen(a)ll.mit.edu> wrote: > >> Yea, I was afraid you were going to say that. >> >> -----Original Message----- >> From: Michael Ströder [mailto:michael@stroeder.com] >> Sent: Thursday, December 05, 2013 1:30 PM >> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org >> Subject: Re: OPENLDAP HANGS DAILY >> >> Borresen, John - 0442 - MITLL wrote: >>> I just restarted with the group, and the OpenLDAP software has not >>> been upgraded - currently 2.4.23 (that will be coming...hopefully). >>> Anyway, an issue that was brought to my attention upon starting was >>> that slapd needs to be restarted daily. It is still running, it just >>> stops responding (no one can log in). Nothing has, previously, been >>> found in the logs. The other day, during my initial search through >>> the slapd logs I found: >> >> Please upgrade first. Everything else is waste of yours and others time. >> >> Ciao, Michael. >> >> >> > > > > -- > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

9 years, 9 months

1
0
0 / 0

Re: Sync working in lab but not in production

by Philip Colmer

> Big mistake, as mentioned numerous times on the list. Use a current build. OK - I'll test the upgrade process. Thanks for the pointer on that. Philip On 5 December 2013 16:45, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Thursday, December 05, 2013 1:38 PM +0000 Philip Colmer > <philip.colmer(a)linaro.org> wrote: > >> I suspect I've broken a fundamental rule of how sync works on OpenLDAP >> but here goes ... >> >> We've been running a single OpenLDAP server for a while now so I >> wanted to get some resiliency into place. We are using version 2.4.28 >> on Ubuntu 12.04. > > > Big mistake, as mentioned numerous times on the list. Use a current build. > > Your log indicates that there is no accesslog DB, so I'd start with > investigating there after you fix the first problem. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

9 years, 9 months

1
0
0 / 0

Sync working in lab but not in production

by Philip Colmer

I suspect I've broken a fundamental rule of how sync works on OpenLDAP but here goes ... We've been running a single OpenLDAP server for a while now so I wanted to get some resiliency into place. We are using version 2.4.28 on Ubuntu 12.04. The original machine is a VM so I cloned it and built two further servers from that clone. I then followed the instructions in https://help.ubuntu.com/12.04/serverguide/openldap-server.html to add the provider bits to server A and the consumer bits to server B. That works fine. So, since I had a working consumer, I added the provider bits to the original LDAP server and changed the configuration on server B so that it queries that server and not server A. Syncing now fails and I'm getting the following in the log: slapd[8201]: conn=1059 fd=18 ACCEPT from IP=127.0.0.1:52374 (IP=0.0.0.0:389) slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" method=128 slapd[8201]: conn=1059 op=0 BIND dn="cn=XXX,dc=YYY,dc=ZZZ" mech=SIMPLE ssf=0 slapd[8201]: conn=1059 op=0 RESULT tag=97 err=0 text= slapd[8201]: conn=1059 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(?objectClass=auditWriteObject)(?reqResult=0))" slapd[8201]: conn=1059 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN slapd[8201]: conn=1059 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text= slapd[8201]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (32) No such object slapd[8201]: do_syncrep2: rid=000 (32) No such object slapd[8201]: conn=1059 op=2 UNBIND I've double-checked the configuration on the provider and if I revert the configuration on server B so that it consumes from server A, it all works again. Have I broken a fundamental rule? If I have, how can I fix it? If I haven't, what have I done wrong? Thanks. Philip

9 years, 9 months

3
3
0 / 0

Found bug in GET_BOTH_RANGE

by Alain

I found a bug where the data was not updated in a call to cursor get with GET_BOTH_RANGE Here is what I did to fix it, but not 100% sure it covers everything correctly: rc = mc->mc_dbx->md_dcmp(data, &d2); if (rc) { if (op == MDB_GET_BOTH || rc > 0) return MDB_NOTFOUND; data->mv_data = d2.mv_data; //added data->mv_size = d2.mv_size; //added rc = 0; } Please confirm. Thanks Alain

9 years, 9 months

1
0
0 / 0

2.4.26 : too many open files

by Aaron Bennett

Hi, I just ran into this yesterday on CentOS 6 / OpenLdap 2.4.36, my own build against bdb 5.1.29 and OpenSSL. Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): /var/lib/ldap/log.0000032796: log file unreadable: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: fatal region error detected; run recovery Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: fatal region error detected; run recovery Dec 2 16:55:40 animal slapd[13735]: null_callback : error code 0x50 I never did anything to change the default process limit, looks like it's set to 1024 in /proc/$(pidof slapd)/limits. Is there anything I can do short of an automatic restart to prevent that from cropping up again? I have an MMR via Syncrepl setup with nothing too complicated; can't think of any reason offhand that slapd would need to have more than 1024 files open. Best, Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS W:508.793.7315

9 years, 9 months

5
5
0 / 0

LDAP issue with SASL 2.1.26

by Sergey Emantayev

Hello, We successfully use OpenLDAP C SDK 2.4.36 integrated with Cyrus-SASL 2.1.23. Recently we have upgraded Cyrus-SASL to 2.1.26 and encountering the next issue. LDAP search consistently fails. We analyzed this issue and found the following behavior. When we use OpenLDAP with Cyrus-SASL 2.1.23 the LDAP Message Search Request payload is wrapped in GSS-API payload. When we use OpenLDAP with Cyrus-SASL 2.1.26 the LDAP Message Search Request payload is not wrapped in GSS-API payload at all. LDAP Search Request looks like clear text LDAP Search Request and not like LDAP SASL Search Request. In both cases - with Cyrus-SASL 2.1.23 and with Cyrus-SASL 2.1.26 – LDAP SASL Bind succeeds and LDAP SASL bindResponse looks identical with Cyrus-SASL 2.1.23 and with Cyrus-SASL 2.1.26. On the SASL support mail list I was suggested to setup minssf parameter. We have double checked that it's set correctly (=1). Please advise how to troubleshoot the issue. Thanks & Regards, Sergey

9 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2013