openldap-technical

openldap-technical@openldap.org

7 participants
9901 discussions

[Openldap] Add new node in existant n-way multimaster environment
by coma 13 Jan '15

13 Jan '15

Dear list, I'm currently trying to understand how to adding a new node (new master server) in an existant n-way multimaster environment by adding the new node as a "scratch node" (without any data, and without declare all the other servers in the cn=config), so, to do that, i'm would to know if it's possible to add a new master but force an "initial replication" (force it first to replicate config and data from an other master)? Thank you in advance for any answers,

1 0

slapcat command
by Eileen(=^ω^=) 12 Jan '15

12 Jan '15

Hi team! I face a question. When I use "slapcat -l filename.ldif ", the output file will include the createTimestamp、modifyTimestamp、entrycsn and entryUUID etc. These attributes will cause the output file can not put back to the bdb database. ‍ could you pls kindly tell me how can use this slapcat without these attibutes ? thanks and best wishes Eileen~

4 7

replace: olcAccess
by Igor Shmukler 07 Jan '15

07 Jan '15

Hello, With help from various generous people on this list, I am finishing up with my project. Among other things, I need to perform a non-interactive OpenLDAP configuration. I install the server with apptitude and have LDIFs to change the root password and suffix. However, it seems that I still need to correctly adjust olcAccess so my searches work. The olcAccess is the part that is not working as I expected. My LDIF runs just fine changing the name, and domain suffix. Yet, after the operation is complete, ldapsearch(1) start returning errors. When the suffix was nodomain [default left by the install] searches worked. Please advise. The LDIF is below: dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=example,dc=com" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by * read dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcSuffix olcSuffix: dc=example,dc=com dn: olcDatabase={1}hdb,cn=config changetype: modify replace: olcRootDN olcRootDN: cn=admin,dc=example,dc=com I don't see any errors. Nothing throws me off when I run slapcat(8). Please advise. Thank you, Igor Shmukler

5 6

back-sql deployment woes
by thelastknowngod 05 Jan '15

05 Jan '15

I've finished moving my existing LDAP user data into MySQL for use with back-sql on my testing machine and everything is working perfectly. Trying to switch production over to it is giving me some headaches though. The two environments are configured the same way as far as I can tell and I can startup the service without issue. However when I try to authenticate on the production environment after swapping the backend out it fails. Here are the logs when I tried to authenticate from IRC: Jan 5 17:37:21 new-ldap slapd[14406]: <==backsql_search() Jan 5 17:37:21 new-ldap slapd[14406]: connection_get(14): got connid=1001 Jan 5 17:37:21 new-ldap slapd[14406]: connection_read(14): checking for input on id=1001 Jan 5 17:37:21 new-ldap slapd[14406]: op tag 0x60, time 1420497441 Jan 5 17:37:21 new-ldap slapd[14406]: conn=1001 op=2 do_bind Jan 5 17:37:21 new-ldap slapd[14406]: >>> dnPrettyNormal: <cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local> Jan 5 17:37:21 new-ldap slapd[14406]: <<< dnPrettyNormal: <cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local>, <cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local> Jan 5 17:37:21 new-ldap slapd[14406]: do_bind: version=3 dn="cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local" method=128 Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_bind() Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_get_db_conn() Jan 5 17:37:21 new-ldap slapd[14406]: <==backsql_get_db_conn() Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_attrlist_add(): adding "userPassword" to list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_attrlist_add(): attribute "userPassword" is in list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_attrlist_add(): adding "objectClass" to list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_dn2id("cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local") Jan 5 17:37:21 new-ldap slapd[14406]: backsql_dn2id("cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local"): id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?" Jan 5 17:37:21 new-ldap slapd[14406]: backsql_dn2id("cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local"): id=13 keyval=1 oc_id=8 dn=cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local Jan 5 17:37:21 new-ldap slapd[14406]: >>> dnPrettyNormal: <cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local> Jan 5 17:37:21 new-ldap slapd[14406]: <<< dnPrettyNormal: <cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local>, <cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local> Jan 5 17:37:21 new-ldap slapd[14406]: <==backsql_dn2id("cn=irc,ou=accounts,cn=USERNAME,ou=people,dc=ls,dc=local"): err=0 Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_attrlist_add(): attribute "userPassword" is in list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_attrlist_add(): attribute "objectClass" is in list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_attrlist_add(): adding "ref" to list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_id2entry() Jan 5 17:37:21 new-ldap slapd[14406]: backsql_id2entry(): custom attribute list Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_get_attr_vals(): oc="ircAccount" attr="userPassword" keyval=1 Jan 5 17:37:21 new-ldap slapd[14406]: backsql_get_attr_vals(): number of values in query: 1 Jan 5 17:37:21 new-ldap slapd[14406]: <==backsql_get_attr_vals() Jan 5 17:37:21 new-ldap slapd[14406]: ==>backsql_get_attr_vals(): oc="ircAccount" attr="objectClass" keyval=1 Jan 5 17:37:21 new-ldap slapd[14406]: backsql_get_attr_vals(): number of values in query: 0 Jan 5 17:37:21 new-ldap slapd[14406]: backsql_id2entry(): attribute "ref" is not defined for objectlass "ircAccount" Jan 5 17:37:21 new-ldap slapd[14406]: <==backsql_id2entry() The attribute the IRC server is looking for is "ircuid" but I'm not seeing that in the log. Could it be that, because this is a custom attribute, it isn't being passed along and/or searched for? It works with that attribute in the old configuration.

2 1

cannot start instance
by Brendan Kearney 05 Jan '15

05 Jan '15

i have been doing a bunch of testing and now have an instance that wont start up. if i run: /usr/sbin/slapd -u ldap -h "ldapi:/// ldap:///" -4 -d9 it runs through and fails with: 54a45a96 read_config: no serverID / URL match found. Check slapd -h arguments. not sure where to look for issues. the ldapi and ldap listeners start up during daemon_init: 54a45551 daemon_init: listen on ldapi:/// 54a45551 daemon_init: listen on ldap:/// 54a45551 daemon_init: 2 listeners to open... ldap_url_parse_ext(ldapi:///) 54a45551 daemon: listener initialized ldapi:/// ldap_url_parse_ext(ldap:///) 54a45551 daemon: listener initialized ldap:/// 54a45551 daemon_init: 2 listeners opened the olcServerID lines are in cn=config.ldif: olcServerID: 1 ldap://ldap1.bpk2.com olcServerID: 2 ldap://ldap2.bpk2.com not sure what is wrong. can someone point me in the right direction?

3 8

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 30 Dec '14

30 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical