Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount
--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>
6 years, 2 months
Re: Locker killed to resolve a deadlock
by Quanah Gibson-Mount
--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>
6 years, 2 months
need an example of using "ldap_search_s" function using the "attr" parameter.
by Don jessup
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
6 years, 2 months
Re: slapd: null_callback : error code 0x14
by Quanah Gibson-Mount
--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>
6 years, 2 months
Re: Olc deployment vs slapd.conf based deployment
by Howard Chu
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/
6 years, 2 months
Re: Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Quanah Gibson-Mount
--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>
6 years, 2 months
Openldap 2.4.40-13.el7 on CentOS 7 and SSL/TLS
by Robert Heller
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
6 years, 2 months
Re: Getting ldappasswd and PAM in the same page under CentOS 7
by Quanah Gibson-Mount
--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>
6 years, 2 months
Getting ldappasswd and PAM in the same page under CentOS 7
by Robert Heller
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
6 years, 2 months
Re: Olc deployment vs slapd.conf based deployment
by Quanah Gibson-Mount
--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>
6 years, 2 months
