openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

ldapmodify crashes with long-ish input for an entry
by Dameon Wagner 05 Jan '15

05 Jan '15

Dear openldap-bugs, I've had a reasonable trawl through the archives, and not found anything that matches the issue I'm seeing, but please point me in the right direction if I've missed anything. (Apologies to anyone receiving this more than once, I tried sending this report to to openldap-bugs and openldap-its over the last few days seen no sign of it in the archives, and not received any message about pending moderation, so thought I would try openldap-technical which might be more appropriate anyway.) We use OpenLDAP for a few directories, one of which is in the process of being migrated to newer hardware, with OS upgrade thrown in, and I've noticed an issue with ldapmodify that I thought was worth reporting. The directory in question has some scripted tooling around it to manage updates from a number of sources, which are staged in a Postgresql database before having some LDIF generated to update the directory itself. During the course of my testing (we've not seen this in production, thankfully) I've noticed that, with reasonably lengthy updates for an entry, ldapmodify dies with an error like the following: #---8<--- Command Output ---------------------------------------------- modifying entry "<DN-FOR-FAILED-ENTRY>" ldap_result: Can't contact LDAP server (-1) #---8<----------------------------------------------------------------- There are matching log-entries in the system's syslog (timestamp, hostname and PID trimmed off to save some linewrapping) and slapd logs (we run slapd under daemontools supervision, and capture it's stdout/stderr): #---8<---- SysLog Output ---------------------------------------------- local4.debug slapd: conn=1002 op=3158 MOD dn="<DN-OF-LAST-GOOD-ENTRY>" local4.debug slapd: conn=1002 op=3158 MOD attr=member local4.debug slapd: conn=1002 op=3158 RESULT tag=103 err=0 text= local4.debug slapd: conn=1002 fd=13 closed (connection lost) #---8<----------------------------------------------------------------- #---8<---- Slapd Output ----------------------------------------------- 54a2e47f conn=1002 op=3158 MOD dn="<DN-OF-LAST-GOOD-ENTRY>" 54a2e47f conn=1002 op=3158 MOD attr=member 54a2e47f conn=1002 op=3158 RESULT tag=103 err=0 text= sb_sasl_cyrus_decode: failed to decode packet: generic failure sb_sasl_generic_read: failed to decode packet 54a2e47f conn=1002 fd=13 closed (connection lost) #---8<----------------------------------------------------------------- The LDIF for the failed entry consists of: #---8<----------------------------------------------------------------- dn: <DN-FOR-FAILED-ENTRY> changetype: modify replace: member member: <DN-FOR-MEMBER> ... member: <DN-FOR-ANOTHER-MEMBER> #---8<----------------------------------------------------------------- where the list of members was, in this case, 9799 long. The LDIF itself is 30097 lines long, and was happy for the first ~15000 lines. If I prune out the modifications for the troublesome DN, the remainder of the file also goes through happily. As a work-around I can manually split up the list into several blocks (tested with roughly 1000 member updates per block) with "replace: member" for the first, to match the current behaviour, and "add: member" for the rest. In this format, ldapmodify is happy to process the LDIF (all in one connection, but as discreet operations). (Note: the authenticated user has "unlimited" limits in the config) Given that, it sounds like it could be a bug in ldapmodify (I don't think it's on the slapd end). I've tested on both the debian stable package (version 2.4.31-1+nmu2), and with a locally compiled build direct from the project's download pages (also 2.4.31 to start with, to see if it was an introduced bug). Has anyone else on the list seen anything like this before? Thanks for your time and any hints and tips. Cheers. Dameon. -- ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< Dr. Dameon Wagner, Systems Development and Support IT Services, University of Oxford ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

3 6

Non OpenLDAP use of LMDB
by Harry B 04 Jan '15

04 Jan '15

Hello, I am planning to use LMDB to create a resonably large database, few TBs, > 500mil keys, on a Fusion IO flash storage. Memory to storage ratio of the available hardware is about 1:10 Assuming the caching of "5 to 10%" of most-frequently-accessed data is good enough for my use-case, is this a valid/legitimate use of LMDB ? Or am I using the wrong tool for the job? My other choices are RocksDB (haven't looked at it) or Postgres (using a limited subset of features), the latter mainly because we already use it across the company. Any advice is appreciated. Thanks -- Harry

2 2

GSSAPI vs GSS-SPNEGO
by Brendan Kearney 31 Dec '14

31 Dec '14

i am in the process of updating all of my systems to fedora 20 from fedora 16, and am using all the latest available builds for openldap, cyrus-sasl and mit kerberos. i have put everything together as i had on fedora 16, and i am finding that the sasl instance is using sasl/gss-spnego, and not sasl/gssapi like it did on the older version. i am not sure if i should be concerned about this, but it feels like i should be. i am not able to find anything that allow me to configure things one way or another, so i can force the use of gssapi from configs, it seems. can anyone point me in a direction about this, tell me if i should be concerned, or if you might have come across this before what i should be doing that i am not? thank you, brendan

4 11

DB_Config
by Craig White 22 Dec '14

22 Dec '14

I inherited an OpenLDAP server that is in production use and it suffers from a lack of knowledge and I am slowly trying to remedy that. One of the things I noticed was that it complained at startup about the lack of a DB_Config and a caution about it being slow - which it definitely seems to be. As this server is in production use, I am not allowed to do anything to impact it without thorough testing - which I think I have done. Does anyone see any problems if I just drop the following DB_Config file in a data directory so the next time the server is restarted, it takes effect? (Yes, it's a DBD configuration) # cat DB_CONFIG set_cachesize 0 10485760 1 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 set_lg_dir /var/tmp/bdb-log set_flags DB_LOG_AUTOREMOVE Seems safe and I do back it up regularly but if I drop the file in the data directory, I may not be watching when the server is patched/restarted. Comments? Thanks Craig

3 2

Upgrade Ubuntu server will purge OpenLDAP data
by Onno van der Straaten 22 Dec '14

22 Dec '14

Because this is so unexpected and it impacts OpenLDAP installations, I though I share this information here. Ubuntu server upgrade from 12.04 to 14.04 LTS will purge the OpenLDAP directory data. I don't understand why the or a upgrade would want to purge data but that is what happens. I can't find anything on the internet explaining why this is unavoidable and necessary. >From what I have learned so far the best way to recover from this is to completly remove OpenLDAP and start a fresh installation and import data from backup. I'm sure you will have it, for exactly this types of situations that are I'm afraid typical for OpenLDAP. The reason is that it is unclear what state the upgrade leaves OpenLDAP in. I think it will take more time to figure out what was purged, what not, what was changed than it takes to do a complete reinstall.

7 9

OpenLDAP and FIM 2010 R2
by Darouichi, Aziz 19 Dec '14

19 Dec '14

Hello everyone, The management asked me to looking into Forefront Identity Management (FIM) to synch Passwords between our Microsoft AD and OpenLDAP. Openldap is used for SSO hosted by the vendor. Is this something worth exploring for 2 way password synch? Will this need custom APIs to make it work? Or would it work out of the box? Thank you for your input and happy new year all...!! Aziz Darouichi

2 1

help with back-sql setup
by thelastknowngod 17 Dec '14

17 Dec '14

Hey guys, I'm getting an "operation not permitted within namingContext" error when trying to add an entry into a test environment using back-sql. I created the database using the backsql_create.sql,testdb_create.sql,testdb_data.sql, and testdb_metadata.sql files in the OpenLDAP source. I've also tried just using one of the entries in the testdb as a template. Still didn't work. Not sure where the issue is. If you guys can help point me in the right direction that would be awesome. Thanks! I'm building using version 2.4.40 on Linux Mint 17. More relevant info: /etc/odbc.ini: [openldap] Description = Example for OpenLDAP's back-sql Driver = MySQL Trace = No Database = openldap Servername = localhost UserName = openldap Password = thisisatest ReadOnly = No RowVersioning = No ShowSystemTables = No ShowOidColumn = No FakeOidIndex = No ConnSettings = SOCKET = /var/run/mysqld/mysqld.sock /etc/odbcinst.ini: [MySQL] Description = ODBC for MySQL Driver = /usr/lib/odbc/libmyodbc.so FileUsage = 1 /usr/local/openldap/slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args database sql suffix "dc=example,dc=com" rootdn "cn=root,dc=example,dc=com" rootpw thisisatest dbname openldap dbuser openldap dbpasswd thisisatest subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)" insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)" has_ldapinfo_dn_ru no File permissions: srwxrwxrwx 1 mysql mysql 0 Dec 8 12:22 /var/run/mysqld/mysqld.sock lrwxrwxrwx 1 root root 43 Dec 8 16:25 /usr/lib/odbc/libmyodbc.so -> /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so -r--r--r-- 1 root root 20499 Dec 15 11:52 /usr/local/etc/openldap/schema/core.schema -r--r--r-- 1 root root 73994 Dec 15 11:52 /usr/local/etc/openldap/schema/cosine.schema -r--r--r-- 1 root root 6267 Dec 15 11:52 /usr/local/etc/openldap/schema/inetorgperson.schema -rw-r--r-- 1 openldap openldap 29 Dec 15 12:00 /usr/local/var/run/slapd.args -rw-r--r-- 1 openldap openldap 6 Dec 15 12:00 /usr/local/var/run/slapd.pid

2 3

openldap group issue on centos 5.5 - all users automatically get put into newly created group
by Janet Houser 14 Dec '14

14 Dec '14

Hi, I created a dit on a Centos 6.5 box that looks something like this: ........dc=name,dc=com................................ | | | | | | ou=users ou=systems........... ou=policies | | | | | | | | user1 cn=group1 cn=group2 cn=ppolicy user2 | | user3 | | | | user1 user2 user2 user3 I created my users, and I added sever "linux groups" using the ldif file: dn: cn=dev,ou=systems,dc=ehs,dc=edu cn: dev gidNumber: 4005 objectClass: posixGroup My goal was to simulate an entry that you'd find in the /etc/group file on a linux system. So if I added people to this group using the ldif file: dn: cn=dev,ou=systems,dc=ehs,dc=edu changetype: modify add: memberuid memberuid: user1 memberuid: user2 So while user1 and user2 are in the default group "users", I wanted them to be able to change the group on their files to "dev" in order to protect their development files. Now, this seemed to work, and when I went on my client and did a command "groups user1", I saw "users" and "dev" However yesterday I added another group called "team0" with gid 22222 using the following ldif file: dn: cn=team0,ou=systems,dc=ehs,dc=edu cn: team0 gidNumber: 22222 objectClass: posixGroup When I was logged into my client machine (Centos 5.5 box) and did a groups on an old user, it showed "users", "dev" and now "team0" although I never added that user to the new group. I cleaned the client cache using the nscd -i invalidate=group command, and then I removed all the cached directories in /var/db/nscd, and rebooted, but that new group seems to have been applied to everyone. I might have screwed up the creation of my DIT, but I was thinking that things were working ok since I could added "unix groups" that are visible with the "getent group" command on a client, I could add users into these groups and changed the group of files to lock out some users, but I don't understand this behavior now. I have about 6 groups defined and the last one I created yesterday is the only one that seems to get applied to all users. I'd appreciate any help you could give.... I'm scratching my head on this one. Thanks.

2 3

DOS/Windows command to query OpenLDAP
by Scott Gates 13 Dec '14

13 Dec '14

Hello, I have a question. I support a Windows Server based application that connects to several forms of LDAP, including OpenLDAP. Occasionally, for debugging purposes, I need to see if we're on speaking terms with the OpenLDAP server and are getting proper information from it. In a DOS window using Active Directory, I'd type >net user john.doe /domain and get back. C:\Users\john.doe.VB>net user john.doe /domain The request will be processed at a domain controller for domain company.loc. User name john.doe Full Name John Doe Comment Product Support Engineer User's comment Country code (null) Account active Yes Account expires Never Password last set 11/30/2014 7:46.29 AM Password expires 12/30/2014 7:46.29 AM Password changeable 11/30/2014 7:46.29 AM Password required Yes User may change password Yes Workstations allowed All Logon script User profile Home directory Last logon 12/12/2014 8:06:11 AM Logon hours allowed All Local Group Memberships Global Group memberships *FSUSERS *Network Support Engin *SupportSecGroup *Domain Users *Network Engineers The command completed successfully. Is there a command I can run from a Windows DOS prompt that would show me essentially the same info for OpenLDAP. When my customers are using OpenLDAP and having issues, I'm usually flying blind. Scott Gates Production Support Engineer VBrick Systems, Inc.

2 1

modify jpegPhoto => segfault
by Raffael Sahli 11 Dec '14

11 Dec '14

Hi Is there a known problem with the attribute jpegPhoto (InetOrgPerson) on 2.4.40 ? If I update or add the attribute with data bigger than ~27KB the slapd crash (`/usr/local/libexec/slapd': free(): invalid next size (normal):) (Tried with builds on ubuntu lts 12.04, 14.04 and with bdb or mdb, results all in the problem above) Going back to 2.4.39 solves the problem. -- Raffael Sahli

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical