openldap-technical September 2017

openldap-technical@openldap.org

54 participants
164 discussions

Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount 26 Sep '17

26 Sep '17

--On Tuesday, September 26, 2017 9:56 AM +0900 Jorgen Lundman <lundman(a)lundman.net> wrote: > > Unfortunately, this is not our experience - although it is possible the > message is just a distraction. > > slapd stops all syncrepl, and responding, until they call us to restart > it. Interesting, I wonder if the BDB database has corrupted. Have you tried rebuilding the database(s) on the system via slapcat/slapadd? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount 25 Sep '17

25 Sep '17

--On Friday, September 22, 2017 4:26 PM +0900 Jorgen Lundman <lundman(a)lundman.net> wrote: > This has started to cause trouble, in the last month or so. The errors > are: > > Sep 22 06:08:26 vmx02 slapd[14039]: [ID 960831 local4.debug] => > bdb_idl_delete_key: c_get failed: DB_LOCK_DEADLOCK: Locker killed to > resolve a deadlock (-30994) These can be safely ignored. See <http://www.openldap.org/lists/openldap-software/200810/msg00055.html> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

need an example of using "ldap_search_s" function using the "attr" parameter.
by Don jessup 25 Sep '17

25 Sep '17

I trying to use the "ldap_serach_s" function and my filter works great if put NULL in for the "attrs" parameter. Here is example filter [(&(member=cn=Bob,ou=colo,dc=bigco,dc=com,dc=local)(objectCategory=Group))] To limit the information coming back from the server I only want the values of the "sAMAccountName" attribute. Every time I try populating the "attrs" parameter I get an error. I was wondering if I could be pointed to an example or 2 that uses the parameter. ThanksDon

1 0

Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount 25 Sep '17

25 Sep '17

--On Friday, September 22, 2017 10:15 PM -0700 "Paul B. Henson" <henson(a)acm.org> wrote: > I see there was a proposed patch posted on 8/25 that's been applied to > RE24, I'll add that to my system and see if the issue goes away. Am I > correct in my assumption that the patch only needs to be applied to the > system that is receiving the updates? I believe that is correct. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Olc deployment vs slapd.conf based deployment
by Howard Chu 25 Sep '17

25 Sep '17

Peter wrote: >> olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif >> olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif >> olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif > > That is a very nice proposal, it would sort of give us the good things of both > worlds. It means you would not be able to edit the schema contained within these directives over LDAP, since those elements aren't themselves part of the cn=config DIT. So no, it's not the good things of both worlds. > IMHO schema is the only thing where cn=config makes life harder than slapd.conf. > > Being a long time lurker on this list it is fun to see that although same > subjects like config alternatives, turn up again and again, the arguments and > solution proposals at least sometimes do progress. > > Cheers > > Peter > > > > Am 15.09.2017 um 20:33 schrieb Quanah Gibson-Mount: >> --On Friday, September 15, 2017 12:24 PM -0700 Ryan Tandy <ryan(a)nardis.ca> >> wrote: >> >> >>> There was some talk, either in IRC or on -devel, of creating a way for >>> cn=config to reference schema files (possibly LDIF) on disk rather than >>> importing them into the config database. I think that would be an >>> improvement. Importing schemas into cn=config is cool - especially if you >>> want to replicate the config - but I'm not sure it's a good default. >> >> Since ordering is mandatory, it would be nice if you could just do something >> like: >> >> olcSchemaFile: {0}include: file://$ABS_SCHEMADIR/core.ldif >> olcSchemaFile: {1}include: file://$ABS_SCHEMADIR/cosine.ldif >> olcSchemaFile: {2}include: file://$ABS_SCHEMADIR/inetorgperson.ldif >> >> >> etc. Then you could change the schema files on disk, and cn=config would >> just load them in when it started. It'd certainly make the behavior >> analagous to slapd.conf, and allow for easier rollback/testing. >> >> --Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >> >> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Quanah Gibson-Mount 23 Sep '17

23 Sep '17

--On Friday, September 22, 2017 5:32 PM -0400 Christopher Wood <christopher_wood(a)pobox.com> wrote: > Two things I notice from below: > > olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem > -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem > > Underscore in the first, dash in the second. Good catch! It's also important to note that RedHat links to MozNSS rather than GnuTLS or OpenSSL, so the standard caveats apply, and be sure to follow the documentation to MozNSS when setting up both the slapd and client (ldapsearch) side of things. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 2

Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Robert Heller 22 Sep '17

22 Sep '17

What is the *correct* way to set up Openldap to use SSL/TLS? The documentation is somewhat confusing. My cn=config.ldif file looks like this: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcTLSCACertificatePath: /etc/openldap/certs olcTLSCACertificateFile: /etc/openldap/certs/ca_cert.pem olcTLSCertificateFile: /etc/openldap/certs/c764guest.cert olcTLSCertificateKeyFile: /etc/openldap/certs/privkey.pem structuralObjectClass: olcGlobal entryUUID: 7e6a3298-30da-1037-9c4f-458bcc6c0ce0 creatorsName: cn=config createTimestamp: 20170918163057Z entryCSN: 20170918163057.597791Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20170918163057Z in /etc/openldap/certs are these files: [root@c764guest heller]# ls -l /etc/openldap/certs total 104 -rw-r--r--. 1 root root 5137 Sep 22 14:42 c764guest.cert -rw-r--r--. 1 root root 1074 Sep 22 14:37 c764guest.csr -rw-r--r--. 1 root root 1696 Sep 22 14:18 ca-cert.pem -rw-r--r--. 1 root root 65536 Sep 18 12:30 cert8.db -rw-r--r--. 1 root root 16384 Sep 18 12:30 key3.db -r--r-----. 1 root ldap 45 Jan 10 2016 password -rw-r--r--. 1 root root 1834 Sep 22 14:37 privkey.pem -rw-r--r--. 1 root root 16384 Jan 10 2016 secmod.db /etc/sysconfig/slapd contains: # OpenLDAP server configuration # see 'man slapd' for additional information # Where the server will run (-h option) # - ldapi:/// is required for on-the-fly configuration using client tools # (use SASL with EXTERNAL mechanism for authentication) # - default: ldapi:/// ldap:/// # - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:/// SLAPD_URLS="ldapi:/// ldap://127.0.0.1/ ldap://192.168.250.98/ ldaps:///" # Any custom options #SLAPD_OPTIONS="-s 128" # Keytab location for GSSAPI Kerberos authentication #KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" /etc/openldap/ldap.conf contains: # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASE dc=deepsoft,dc=com URI ldaps://192.168.250.98/ TLS_CACERT /etc/openldap/certs/ca-cert.pem TLS_CACERTDIR /etc/openldap/certs TLS_REQCERT demand #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on But now when I try to do a ldapsearch I get: [heller@c764guest ~]$ ldapsearch -x ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) even though: [root@c764guest heller]# netstat -a|grep ldap tcp 0 0 0.0.0.0:ldaps 0.0.0.0:* LISTEN tcp 0 0 c764guest.deepsoft:ldap 0.0.0.0:* LISTEN tcp 0 0 localhost:ldap 0.0.0.0:* LISTEN tcp 0 0 c764guest.deepsof:33302 c764guest.deepsoft:ldap ESTABLISHED tcp 0 0 c764guest.deepsoft:ldap c764guest.deepsof:33302 ESTABLISHED tcp6 0 0 [::]:ldaps [::]:* LISTEN Is this correct? I am not sure if I should be using ldaps:/// or not. And I am not sure what the proper "magic" to get TLS working is. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

2 1

Re: Getting ldappasswd and PAM in the same page under CentOS 7
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 10:45 AM -0400 Robert Heller <heller(a)deepsoft.com> wrote: > Operation 11 *seems* to be fetching the uid, using self, which has write > access, which implies read access, which seems to work just fine, using > ldapsearch from the command line: > > [heller@c764guest ~]$ ldapsearch -D > uid=test2user,ou=People,dc=deepsoft,dc=com -W -LLL '(uid=test2user)' uid > Enter LDAP Password: > dn: uid=test2user,ou=People,dc=deepsoft,dc=com > uid: test2user Is PAM actually bound as uid=testuser2, or is it bound as anonymous or some other DN? I can't tell from the little snippet of log that was in this thread. So yes, it works for you using ldapsearch when you bind as uid=test2user, but is that what pam is using? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Getting ldappasswd and PAM in the same page under CentOS 7
by Robert Heller 22 Sep '17

22 Sep '17

I am having a hard time setting a user password using ldap (OpenLDAP 2.4.40-13.el7) on a CentOS 7 system. I have installed OpenLDAP 2.4.40-13.el7 (stock CentOS 7 server and client), nss-pam-ldapd (0.8.13-8.el7) and used authconfig to enable ldap. I have created a user in the ldap database, and getent works just fine -- the uid and gid are seen, etc. But I cannot set the user's password in a way that works for su (and presumably login/slogin, etc.). I am using ldappasswd to set the user's password. I am thinking that PAM and ldappasswd are using *different* oneway encryption methods and I am guessing I need to update a configuration somewhere (either for pam, sssd, or nslcd), but I am not finding it. -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

5 13

Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount 22 Sep '17

22 Sep '17

--On Friday, September 22, 2017 8:38 AM -0400 Frank Swasey <Frank.Swasey(a)uvm.edu> wrote: > My take away from this lengthy discussion is the following: > > 1) cn=config is not ready for "make; make test; make install" level of > upgrade. Until it is, it is not usable in a production environment. I've been doing binary upgrades on deployments using cn=config for years (Since 2011 or so), with servers all across the globe. However, I didn't use ppolicy in my configurations. The real issue with ppolicy is that it shouldn't be shipping with a separate schema, and instead it should have its configuration schema fully internalized. I've already made a note to that that needs to be fixed for OpenLDAP 2.5 so it doesn't occur again. Outside of that, I'm not aware of it being deficient in comparison to slapd.conf, and I'm quite aware of numerous ways in which it is substantially better. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2017