Re: Help with SASL generic GSSAPI error
Am Mon, 12 May 2014 20:52:14 -0600 schrieb Joshua Schaeffer jschaeffer0...@gmail.com: I'm looking for a little help concerning the below error I get when I do an ldapsearch: root@mytest:~# ldapsearch -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () That error is pretty generic to me and the searching I've done to find a solution has not yielded anything successful. I have MIT Kerberos and SASL setup and I'm able to successfully get a TGT from any machine that can see my KDC. I also can successfully search my ldap directory using simple authentication. I've run the sasl-sample-client and server between several machines including: ldap server to krb server, test server to krb server, test server to ldap server, etc. I can complete the sasl test on every one. Running slapd in debug mode doesn't provide me with any additional information: root@baneling:~# slapd -h ldap:/// ldapi:/// -d 256 5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $ root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd 5371865c slapd starting 53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839 (IP=0.0.0.0:389) 53718672 conn=1000 op=0 BIND dn= method=163 53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () 53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () 53718672 conn=1000 op=1 UNBIND 53718672 conn=1000 fd=13 closed 53718672 connection_read(13): no connection! I do have the keytab in a non-standard location on the ldap server (/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and restarted slapd. I'm not really sure what I can provide from my cn=config that would help diagnose this issue let me know and I can respond with the details. Here is my ldap.conf from the server I'm running the ldapsearch from (my test server): root@mytest:~# cat /etc/ldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASEdc=harmonywave,dc=com URIldap://baneling.harmonywave.com #SIZELIMIT12 #TIMELIMIT15 #DEREFnever # TLS certificates (needed for GnuTLS) TLS_CACERT/etc/ssl/certs/ca.harmonywave.com.pem TLS_REQCERTdemand TLS_CHECKPEERyes TLS_CIPHER_SUITESECURE256 # LDAP sudo settings sudoers_baseou=SUDOers,dc=harmonywave,dc=com # SASL Kerberos settings SASL_MECHGSSAPI SASL_REALMHARMONYWAVE.COM Does klist show a ldap service principal? -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95N 10°08'02,42E
Re: problems in memberof overlay
Quoting goal jeff e...@hotmail.com:
hi.
I configured the function of 'memberof overlay' these days.
At first I used the methods on the webpage of
http://www.openldap.org/doc/admin24/overlays.html, I add the codes
of overlay
memeberof in the file of slapd.conf,then I started the slapd service, the
system give me an error overlay memberof not found .
second,I googled the internet and found an article on this
webpage:http://www.redmine.org/projects/redmine/wiki/RedmineLDAP,so
I create two
LDIF files as follow:
the first file :
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib/ldap
olcModuleLoad: memberof
the second file:
dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
after I entered the command ldapadd -x -D
'cn=Manager,dc=example,dc=com' -W
-f 1.ldif,the system give an error:ldap_add: Insufficient access (50)
please help me ,thanks.
First of all, memberof is an overlay and is not a module. You don't
need the first file at all.
Second, are you running slapd with a configuration file or with
cn=config? You can't modify cn=config if you are running with
slapd.conf.
Third, how is your openldap compiled? There is a configure switch
--enable-memberof.
-mike
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
On 02/06/2014 03:28 PM, Paul B. Henson wrote: From: Michael Ströder Sent: Saturday, February 01, 2014 2:45 AM As Howard confirmed on this mailing list static configuration will still be available in OpenLDAP 2.5.x. Really? I didn't see that; my last understanding was that it was deprecated in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off dealing with the conversion for much longer :). Just FWIW, we also have the configs for our different OpenLDAP databases on various servers under git version control. This provides us with a critical, time-stamped audit trail and documentation for all changes along with a fast, reliable method for reverting to earlier configs should it become necessary. We would very much hate to lose that audit-trail documentation and control. ;-) -- Andy Dorman Ironic Design, Inc. AnteSpam.com, ComeHome.net CONFIDENTIALITY NOTICE: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any erroneous transmission. If you receive this message in error, please immediately destroy it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, or copy any part of this message if you are not the intended recipient.
Moving From Debian 2.4.31/hdb to LTB 2.4.39/mdb
Hi. We have been using OpenLDAP for about 11 years now and have an MMR set up with 2 masters and 18 delta-syncrepl clients/slaves, all but 3 slaves are currently using back_hdb. Our beta test server and two load balancers are using back_mdb. The db is not too big with about 50,000 entries, 9 indexes (7 eq 2 sub) and the slapdump ldif is about 41 MB. All our servers are Debian testing with a few packages from unstable and even experimental so we have the latest security and feature fixes for the work we do (email security filtering). Unfortunately, even the bleeding edge debian releases are wy behind in OpenLDAP. Last year we lost our system admin that set all this up, and I have been on a very steep learning curve since then. At this time I believe we need to move to a current version of OpenLDAP via ltb-project and switch to mdb, but I have run into a couple of questions we need to resolve first. FWIW, I would dearly like to help out the Debian community and compile maintain an up-to-date version of OpenLDAP for them, but I need at least a couple more years of experience before it is even marginally safe to have other companies depending on my expertise with debian packaging. Anyway, after reading the OpenLDAP ltb-project docs I have a couple of questions for anyone already using the ltb-project debian release, slapd.d mdb. I hope the answers will help make our and others' transition go more smoothly. So here we go Question #1. I see that slapd.conf is deprecated and we should move to a slapd.d config db. However, the slapd.conf file (with git cfengine) meets 3 key requirements for our service's configuration management: (1) audit trail, (2) peer review staff notification, (3) automatic, staggered release to all servers so our users experience 0 downtime. I do not yet see an easy way to meet the first two requirements using slapd.d. To satisfy #3 I hope we can just update our master server slapd.d and config changes will be replicated to the slaves. Someone please correct me if I am wrong about that. To meet the requirement for an audit trail staff review notification, in the absence of someone's experience and/or knowledge from this group, we currently plan to use our ticket-tracking system (Request Tracker). Within an RT queue dedicated to our db systems we will document, review manage slapd.d changes prior to actually making a change in the master which will then (I hope) propagate through delta-syncrepl. How does anyone else that is using slapd.d with an MMR setup with multiple client/slaves take care of their needs for an audit trail, peer review/staff notification, and release to all those servers? Question #2. This may be a simple oneWhen reading the latest OpenLDAP docs at http://www.openldap.org/doc/admin24/slapdconf2.html I noticed that there are no references to back_mdb in the configuration documentation...Specifically, Table 5.2: Database Backends and Table 6.2: Database Backends do not show an mdb option. Is this an oversight or is mdb going away already or am I completely confused? I suspect the answer is #3 ;-) Basically I need to know what to use in the backend database directives (slapd.conf) or olcBackend attribute (slapd.d) if we want the mdb backend? Thank you for your insights and any information you can share. -- Andy Dorman Ironic Design, Inc. AnteSpam.com, ComeHome.net CONFIDENTIALITY NOTICE: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any erroneous transmission. If you receive this message in error, please immediately destroy it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, or copy any part of this message if you are not the intended recipient.
Re: openldap search filter attribut equal to another
On 03/05/2014 02:52 AM, Lanfeust troy wrote: hi list, is it possible to write a filter like: ((objectClass=inetOrgPerson)(mail=cn)) to retrieve all entry that attribute mail equal to attribute cn. thanks I have never tried it, but I bet not. For starters I don't see how the interpreter would be able to tell that your value on the right side of the = is an attribute name and not a value to compare to. -- Andy Dorman
Re: Debian OpenLDAP is Not Dead Yet
On 03/17/2014 05:54 PM, Joshua Schaeffer wrote: Not to beat a dead horse and not to bash on Debian (personally Debian is the only distro I use), but to further help other people make a decision as to which version they should/may want to install: the slapd package included with Debian or the latest version from source: The Debian community is fully aware of the numerous issues with their OpenLDAP package and acknowledges that it needs work, they have also been asking for help with OpenLDAP for some time (1878 days according to their work-needing packages list): openldap (#512360), requested 1878 days ago Description: OpenLDAP server, libraries, and utilities Reverse Depends: 389-admin 389-ds-base 389-ds-base-dev 389-ds-base-libs 389-dsgw adcli alpine am-utils aolserver4-nsldap apache2-bin (200 more omitted) Installations reported by Popcon: 163954 As the entry specifies bug #512360 in the BTS gives additional information about what work is needed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512360 Thanks, Josh On Mon, Mar 17, 2014 at 11:32 AM, Quanah Gibson-Mount qua...@zimbra.comwrote: --On Monday, March 17, 2014 9:00 AM +0100 Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: Dieter Klünterdie...@dkluenter.de schrieb am 14.03.2014 um 21:50 in Nachricht 20140314215009.33f39...@pink.avci.de: Am Fri, 14 Mar 2014 09:27:10 +0100 schrieb Ulrich Windl ulrich.wi...@rz.uni-regensburg.de: Quanah Gibson-Mount qua...@zimbra.com schrieb am 13.03.2014 um 19:03 in Nachricht 34E9E18C6D0A7C6D92162635@[192.168.1.46]: --On Thursday, March 13, 2014 1:56 PM -0500 espe...@oreillyauto.com wrote: Version 2.4.31-1+nmu2 Plain syncrepl. As I said I hope to be upgrading to the latest version in the next couple of months. Right now I need to get through this problem the best I can. Known issue with 2.4.31. Solution is to upgrade and stop using the crap shipped by Debian. The LTB project now has a deb repository for their builds, I'd advise investigating switching to using it. A: One could also file a bug report for Debian, I guess. B: Rubbish, have you ever seen a Debian or Ubuntu maintainer posting to this mailing list? C: Actually there is no qualified Debian or Ubuntu maintainer. What has A to do with B, and how can you conclude C from A or B? B obviously has to do with A. A qualified maintainer would maintain some presence with the upstream project. C you can conclude from years of interacting with the Debian project, like I have. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration Looks like we should not give up on Debian quite yet...I just saw this for the unstable release... Date: Mon, 17 Mar 2014 15:27:31 -0700 Source: openldap Binary: slapd slapd-smbk5pwd ldap-utils libldap-2.4-2 libldap-2.4-2-dbg libldap2-dev slapd-dbg Architecture: source amd64 Version: 2.4.39-1 Distribution: unstable Urgency: low Maintainer: Debian OpenLDAP Maintainers pkg-openldap-de...@lists.alioth.debian.org Changed-By: Steve Langasek vor...@debian.org Description: ldap-utils - OpenLDAP utilities libldap-2.4-2 - OpenLDAP libraries libldap-2.4-2-dbg - Debugging information for OpenLDAP libraries libldap2-dev - OpenLDAP development libraries slapd - OpenLDAP server (slapd) slapd-dbg - Debugging information for the OpenLDAP server (slapd) slapd-smbk5pwd - Keeps Samba and Kerberos passwords in sync within slapd. Closes: 725824 738641 Changes: openldap (2.4.39-1) unstable; urgency=low ... -- Andy Dorman Ironic Design, Inc. AnteSpam.com, ComeHome.net CONFIDENTIALITY NOTICE: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any erroneous transmission. If you receive this message in error, please immediately destroy it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, or copy any part of this message if you are not the intended recipient.
LDAP_OPT_X_TLS_CACERTDIR not working.
Hi, I would like to open a discussion with OpenLDAP team. I hope this is the right email address. If not please let me know the correct to which this mail should be directed to. Issue: We are currently using OpenLdap 2.4.16 version on Win 64 .We are using RSA and MES Shareadapter internally to build the openldap libs. I am getting the below error when I use Sha-256 (2048 key length) certificates: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I am using the option LDAP_OPT_X_TLS_CACERTDIR and pass the cert directory which has the certificates. This fails. But the same passes when I use LDAP_OPT_X_TLS_CACERTFILE and point to the certicate which is of .pem format. Can you please let me know I am missing something here or is this a bug? Any help on this is appreciated. Thanks Anitha
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Hi, On Thu, 6 Feb 2014, Andy Dorman wrote: On 02/06/2014 03:28 PM, Paul B. Henson wrote: From: Michael Ströder Sent: Saturday, February 01, 2014 2:45 AM As Howard confirmed on this mailing list static configuration will still be available in OpenLDAP 2.5.x. Really? I didn't see that; my last understanding was that it was deprecated in 2.4 and was going to be removed in 2.5. Sweet, that means I can push off dealing with the conversion for much longer :). Just FWIW, we also have the configs for our different OpenLDAP databases on various servers under git version control. This provides us with a critical, time-stamped audit trail and documentation for all changes along with a fast, reliable method for reverting to earlier configs should it become necessary. We would very much hate to lose that audit-trail documentation and control. ;-) as has been said before several times. There is no reason to lose your ability to put your configs into version control when you move to cn=config. - You can check the output from slapcat -n0 into your vcs. - You can revert to an older configuration from your version control by using slapadd -n0. - You can use ldapdiff between old and new versions and generate deltas that you could apply with ldapmodify. - etc ... Greetings Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Quoting Christian Kratzer ck-li...@cksoft.de: as has been said before several times. There is no reason to lose your ability to put your configs into version control when you move to cn=config. - You can check the output from slapcat -n0 into your vcs. You in my message referring to the OP, not you Christian. Or you can ldapsearch it from a backup script running on a cron job. Or you can cd into the config directory and do a git init. In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. It enables you to perform critical adjustments to your service without interrupting your service (more or less depending on the implementation). I have built multilevel LDAP clusters where there were over 15000 simultaneous persistent connections from mobile network elements checking RBAC against management actions and believe me, static configuration would have been a showstopper if I needed to restart LDAP services just to expand my capacity (adding new replicas, etc). If you don't see why dynamic configuration is a good idea, then you probably shouldn't be using LDAP for anything too important, anyway. I personally believe that support for static configuration should be removed already because having two different configuration systems in place serves to confuse a lot of people, especially learners. -mike
Re: LDAP_OPT_X_TLS_CACERTDIR not working.
Am Tue, 25 Mar 2014 11:04:50 -0400 schrieb Seshadri, Anitha anitha.sesha...@emc.com: Hi, I would like to open a discussion with OpenLDAP team. I hope this is the right email address. If not please let me know the correct to which this mail should be directed to. Issue: We are currently using OpenLdap 2.4.16 version on Win 64 .We are using RSA and MES Shareadapter internally to build the openldap libs. I am getting the below error when I use Sha-256 (2048 key length) certificates: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I am using the option LDAP_OPT_X_TLS_CACERTDIR and pass the cert directory which has the certificates. This fails. But the same passes when I use LDAP_OPT_X_TLS_CACERTFILE and point to the certicate which is of .pem format. Can you please let me know I am missing something here or is this a bug? Any help on this is appreciated. Excerpt from openssl documentation: if CApath is not NULL, it points to a directory containing CA certificates in PEM format. The files each contain one CA certificate. The files are looked up by the CA subject name hash value, which must hence be available. I presume, your directory does not provide c_hashed subject names. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95N 10°08'02,42E
autoreconf failing with automake errors
Hi, I am trying to build the openldap package from the source following the release tarball from ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz. I am building this package in a new architecture ppc64le ( IBM PowerPC Little endian ). As the config.guess and libtool did not have the required patches to identify this new architecture, I did autoreconf -f -i in my build system whose latest automake and libtool has the patches of ppc64le. but the autoreconf failed with the following error automake: error: no 'Makefile.am' found for any configure output autoreconf: automake failed with exit status: 1 As the config.guess and configure scripts were updated with the ppc64le patches, i went ahead building the package. IT subsequently failed during 'make' with the following errors make[2]: Entering directory `/home/rajesh/openldap/openldap/libraries/liblber' rm -f version.c ../../build/mkversion -v 2.X liblber.la version.c /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLBER_LIBRARY -c assert.c ../../libtool: 1: eval: base_compile+= cc: not found ../../libtool: 1: eval: base_compile+= -g: not found ../../libtool: 1: eval: base_compile+= -O2: not found ../../libtool: 1: eval: base_compile+= -I../../include: not found ../../libtool: 1: eval: base_compile+= -I../../include: not found ../../libtool: 1: eval: base_compile+= -DLBER_LIBRARY: not found ../../libtool: 1: eval: base_compile+= -c: not found libtool: compile: you must specify a compilation command libtool: compile: Try `libtool --help --mode=compile' for more information. make[2]: *** [assert.lo] Error 1 FYI, I also tried verified building the package in x86 ( Intel Box ) to get some clues if it is specific to ppc64le architecture. Without doing a autoreconf (which I dont require in my x86 laptop), the package building was sucessful. When I did autoreconf in my x86 laptop, I was struck with the similar errors as I had mentioned above. So, can anyone provide any clues how to progress or redirect this mail to the right person if this is not the right place to discuss this issue? Thanks and Regards Rajeshkumar S Linux Technology Center, IBM
Re: Help with SASL generic GSSAPI error
Yes, it does on the server I'm testing from: root@mytest:~# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: jschaef...@harmonywave.com Valid startingExpires Service principal 12/05/2014 20:32 13/05/2014 06:32 krbtgt/harmonywave@harmonywave.com renew until 13/05/2014 20:32 12/05/2014 20:32 13/05/2014 06:32 ldap/baneling.harmonywave@harmonywave.com renew until 13/05/2014 20:32 On 05/13/2014 12:26 AM, Dieter Klünter wrote: Am Mon, 12 May 2014 20:52:14 -0600 schrieb Joshua Schaeffer jschaeffer0...@gmail.com: I'm looking for a little help concerning the below error I get when I do an ldapsearch: root@mytest:~# ldapsearch -Y GSSAPI SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () That error is pretty generic to me and the searching I've done to find a solution has not yielded anything successful. I have MIT Kerberos and SASL setup and I'm able to successfully get a TGT from any machine that can see my KDC. I also can successfully search my ldap directory using simple authentication. I've run the sasl-sample-client and server between several machines including: ldap server to krb server, test server to krb server, test server to ldap server, etc. I can complete the sasl test on every one. Running slapd in debug mode doesn't provide me with any additional information: root@baneling:~# slapd -h ldap:/// ldapi:/// -d 256 5371865b @(#) $OpenLDAP: slapd (Apr 23 2013 12:16:04) $ root@lupin:/tmp/buildd/openldap-2.4.31/debian/build/servers/slapd 5371865c slapd starting 53718672 conn=1000 fd=13 ACCEPT from IP=10.1.10.10:53839 (IP=0.0.0.0:389) 53718672 conn=1000 op=0 BIND dn= method=163 53718672 SASL [conn=1000] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () 53718672 conn=1000 op=0 RESULT tag=97 err=80 text=SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information () 53718672 conn=1000 op=1 UNBIND 53718672 conn=1000 fd=13 closed 53718672 connection_read(13): no connection! I do have the keytab in a non-standard location on the ldap server (/etc/ldap/ldap.keytab), so I modified /etc/default/slapd and restarted slapd. I'm not really sure what I can provide from my cn=config that would help diagnose this issue let me know and I can respond with the details. Here is my ldap.conf from the server I'm running the ldapsearch from (my test server): root@mytest:~# cat /etc/ldap/ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. BASEdc=harmonywave,dc=com URIldap://baneling.harmonywave.com #SIZELIMIT12 #TIMELIMIT15 #DEREFnever # TLS certificates (needed for GnuTLS) TLS_CACERT/etc/ssl/certs/ca.harmonywave.com.pem TLS_REQCERTdemand TLS_CHECKPEERyes TLS_CIPHER_SUITESECURE256 # LDAP sudo settings sudoers_baseou=SUDOers,dc=harmonywave,dc=com # SASL Kerberos settings SASL_MECHGSSAPI SASL_REALMHARMONYWAVE.COM Does klist show a ldap service principal? -Dieter
Re: Help with SASL generic GSSAPI error
On Tue, 2014-05-13 at 08:12 -0500, Dan White wrote:
On 05/13/14 07:32 -0400, Brendan Kearney wrote:
On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote:
Am Mon, 12 May 2014 20:52:14 -0600
schrieb Joshua Schaeffer jschaeffer0...@gmail.com:
root@mytest:~# ldapsearch -Y GSSAPI
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information ()
Check your syslog - auth facility, and check your kdc logs.
a couple of things that may need attention. you need to map the
kerberos-established identities to ldap user objects. adjust the below
to match your environment (these need to be in cn=config):
olcSaslRealm: BPK2.COM
This may be necessary.
olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
This is not necessary, for GSSAPI authentication. That is, the error
message above is a SASL error message. olcAuthzRegexp would be needed to
map the user after authentication has been completed.
good point, why map an identity if it has not been authenticated yet.
you might also need to tell sasl to use the kerberos auth mechanism, and
where to find the ldap servers. again, adjust to your environment
(saslauthd.conf):
ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
ldap_use_sasl: yes
ldap_mech: kerberos5
ldap_auth_method: fastbind
keytab: /etc/ldap.keytab
This is also not necessary, as GSSAPI authentication does not depend on or
use saslauthd. It would be needed if performing pass-through or PLAIN/LOGIN
authentication.
interesting. when i found the articles that i worked off of for my
environment, those distinctions were not made. only recently did i
discover that the pass-through auth works. i have set olcSaslSecProps
to noanonymous,noplain so it seems to only works in limited cases.
Re: Help with SASL generic GSSAPI error
I do have olcSaslRealm and olcAuthzregexp setup in my cn=config. I do
not have saslauthd.conf setup. I ran kinit from my ldap server then
tried to do an ldapsearch and it looks like syslog is providing the same
information.
root@baneling:~# kdestroy
root@baneling:~# kinit -p jschaeffer
Password for jschaef...@harmonywave.com:
root@baneling:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: jschaef...@harmonywave.com
Valid startingExpires Service principal
13/05/2014 07:44 13/05/2014 17:44 krbtgt/harmonywave@harmonywave.com
renew until 14/05/2014 07:43
root@baneling:~# ldapsearch -Y GSSAPI
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information ()
root@baneling:~# cat /var/log/syslog | tail -n 2
May 13 07:44:37 baneling kernel: 7[275.456 palsdne(NU) Neh
U=MCf:ff:ff:f0:eb:c2:40:0SCDT25252525LN38TS01 RC00 T=2 D0POOUPST6
P=7LN38
May 13 07:44:48 baneling slapd[20118]: SASL [conn=1012] Failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more information ()
In my kdc log I don't see anything related to the ldapsearch I'm trying
to perform. It did mention that it there was no host service ticket for
my test server so I added one, but the test I just ran was directly on
my ldap server. I do see this, I'm not sure if it is related to this
problem:
May 13 07:43:58 immortal.harmonywave.com krb5kdc[15804](info): AS_REQ (4
etypes {18 17 16 23}) 10.1.10.9: NEEDED_PREAUTH:
jschaef...@harmonywave.com for krbtgt/harmonywave@harmonywave.com,
Additional pre-authentication required.
Thanks,
Josh
On 05/13/2014 07:12 AM, Dan White wrote:
On 05/13/14 07:32 -0400, Brendan Kearney wrote:
On Tue, 2014-05-13 at 08:26 +0200, Dieter Klünter wrote:
Am Mon, 12 May 2014 20:52:14 -0600
schrieb Joshua Schaeffer jschaeffer0...@gmail.com:
root@mytest:~# ldapsearch -Y GSSAPI
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Other (e.g., implementation specific)
error (80)
additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information ()
Check your syslog - auth facility, and check your kdc logs.
a couple of things that may need attention. you need to map the
kerberos-established identities to ldap user objects. adjust the below
to match your environment (these need to be in cn=config):
olcSaslRealm: BPK2.COM
This may be necessary.
olcAuthzRegexp: {0}uid=([^,]*),cn=bpk2.com,cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
olcAuthzRegexp: {1}uid=([^,]*),cn=gssapi,cn=auth uid=
$1,ou=Users,dc=bpk2,dc=com
This is not necessary, for GSSAPI authentication. That is, the error
message above is a SASL error message. olcAuthzRegexp would be needed to
map the user after authentication has been completed.
you might also need to tell sasl to use the kerberos auth mechanism, and
where to find the ldap servers. again, adjust to your environment
(saslauthd.conf):
ldap_servers: ldap://ldap1.bpk2.com/ ldap://ldap2.bpk2.com
ldap_use_sasl: yes
ldap_mech: kerberos5
ldap_auth_method: fastbind
keytab: /etc/ldap.keytab
This is also not necessary, as GSSAPI authentication does not depend
on or
use saslauthd. It would be needed if performing pass-through or
PLAIN/LOGIN
authentication.
Re: problems in memberof overlay
--On May 13, 2014 at 9:30:08 AM +0300 Mike Jackson m...@netauth.com wrote: First of all, memberof is an overlay and is not a module. You don't need the first file at all. Overlays can definitely be modules, and it is entirely possible one may need to load them, depending on how OpenLDAP was compiled. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Moving From Debian 2.4.31/hdb to LTB 2.4.39/mdb
--On March 4, 2014 at 10:46:23 AM -0600 Andy Dorman ador...@ironicdesign.com wrote: Question #2. This may be a simple oneWhen reading the latest OpenLDAP docs at http://www.openldap.org/doc/admin24/slapdconf2.html I noticed that there are no references to back_mdb in the configuration documentation...Specifically, Table 5.2: Database Backends and Table 6.2: Database Backends do not show an mdb option. Is this an oversight or is mdb going away already or am I completely confused? I suspect the answer is #3 ;-) back-mdb was introduced well into the 2.4 release, and much of the documentation has yet to be updated to reflect its presence. If you check out current git-master, I've been steadily updating the documentation there to include back-mdb. There's still plenty more to update however. ;) I do advise reading the back-mdb manpage as well. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: LDAP_OPT_X_TLS_CACERTDIR not working.
Seshadri, Anitha wrote: I would like to open a discussion with OpenLDAP team. Please don't spam all these e-mail adresses. openldap-technical@openldap.org is sufficient for asking OpenLDAP usage questions. We are currently using OpenLdap 2.4.16 version on Win 64 .We are using RSA and MES Shareadapter internally to build the openldap libs. I am getting the below error when I use Sha-256 (2048 key length) certificates: ldap_sasl_bind_s: Can't contact LDAP server (-1) error:14090086:SSL routines: SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I am using the option LDAP_OPT_X_TLS_CACERTDIR and pass the cert directory which has the certificates. This fails. But the same passes when I use LDAP_OPT_X_TLS_CACERTFILE and point to the certicate which is of .pem format. I assume you're using the OpenLDAP client libs on Windows. Furthermore I assume that you've linked OpenLDAP to the OpenSSL libs. If yes, then using LDAP_OPT_X_TLS_CACERTDIR might fail since you did not put the CA certs with hash-based file names into there. Normally on Unixoid systems like Linux one creates symbolic links with the cert hash as name. So this seems rather to be a question on how to correctly use OpenSSL on Windows. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Mike Jackson wrote: Quoting Christian Kratzer ck-li...@cksoft.de: as has been said before several times. There is no reason to lose your ability to put your configs into version control when you move to cn=config. - You can check the output from slapcat -n0 into your vcs. You in my message referring to the OP, not you Christian. Or you can ldapsearch it from a backup script running on a cron job. Or you can cd into the config directory and do a git init. We've discussed that here many times: IMO it's a big difference to export a running configuration in your VCS just for the records or to control the configuration in VCS before rollout. For me doing the VCS actions *before* rolling out the configuration to all the slapd instances gives much more control especially if you have to roll *back* something. And think of staging. And slapd-config does not handle deletion = rollback can be very hard. Also orchestrated rollout of changes might spread across other systems as well. E.g. when I'm deploying schema changes in slapd I have to change the web-based admin UI as well etc. In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. It enables you to perform critical adjustments to your service without interrupting your service (more or less depending on the implementation). I have built multilevel LDAP clusters where there were over 15000 simultaneous persistent connections from mobile network elements checking RBAC against management actions and believe me, static configuration would have been a showstopper if I needed to restart LDAP services just to expand my capacity (adding new replicas, etc). Nonsense. If HA is important you must have decent load-balancers in front of your servers and know how to operate them. If you don't see why dynamic configuration is a good idea, then you probably shouldn't be using LDAP for anything too important, anyway. Ah, and you are the one and only *real* expert. Strange enough my customers are running mission-critical OpenLDAP deployments with static configuration - since years. I personally believe that support for static configuration should be removed already because having two different configuration systems in place serves to confuse a lot of people, especially learners. Complete nonsense. Ciao, Michael. smime.p7s Description: S/MIME Cryptographic Signature
Re: autoreconf failing with automake errors
--On May 13, 2014 at 8:39:07 AM -0400 raj...@linux.vnet.ibm.com wrote: Hi, I am trying to build the openldap package from the source following the release tarball from ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.4.39.tgz. I am building this package in a new architecture ppc64le ( IBM PowerPC Little endian ). As the config.guess and libtool did not have the required patches to identify this new architecture, I did autoreconf -f -i in my build system whose latest automake and libtool has the patches of ppc64le. but the autoreconf failed with the following error I would advise filing an ITS at http://www.openldap.org/its/ requesting an update to the build tools so that newer architectures are supported. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
[LMDB] Choosing right environment flags
I need to better understand the best way to configure the various environment flags related to sync and map. When we converted from BDB to LMDB, we instinctively kept #MDB_NOSYNC true. This proved to make the database subject to corruption if it was killed or stopped too harshly. It also had the effect on Windows at least to make Windows gradually use up all available RAM for the memory mapped file and to bring the server to its knees. After carefully reading the documentation about leaving the system with no hint for when to write transactions to disk when MDB_NOSYNC was turned on, we completely went without setting any options. The results were that we can't corrupt the database, but the speed degradation makes this approach unusable, as we are very heavily write focused (at least in this part of our process, where we perform analysis and load the database with 100's millions of records). In looking at the documentation I'm tempted to try MDB_WRITEMAP with MDB_MAPASYNC but do I then need to also issue some manual mdb_env_sync and if so at what frequency and what should trigger this? What are best practices combinations of those flags here. We absolutely can't afford database corruption, but we can deal with one (or maybe more with some re-design) transactions that are lost. Please guide us. Thanks Alain
[LMDB] Single writer question
If my memory serves me well, at some point Howard mentioned that LMDB was looking at moving from a single environment writer to a single writer per database. Am I just dreaming or did I see that? And if I'm not dreaming then what is the status of this, as my experiment seem to show that there is no performance gain to be have by splitting your data in more than one db. Thanks Alain
RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
From: Mike Jackson Sent: Tuesday, May 13, 2014 2:02 AM In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. It enables you to perform critical adjustments to your service without interrupting your service (more or less depending on the implementation). You seem to be confusing the concept of dynamic configuration, the ability to change the configuration of a running service without having to stop said service or disrupt providing the service, with the concept of where the configuration is stored, in a flat text file or in a database. There is absolutely no reason why openldap could not support dynamic configuration when the configuration is stored in a flat text file. There are numerous examples of services which store their configuration in a flat text file, and are capable of rereading that file and dynamically changing the running configuration based on the changes found. Yes, the current implementation of openldap only supports dynamic configuration when the configuration is stored in an LDAP database, but that is not an inherent limitation of storing configuration in a flat text file, but simply the preference of the openldap developers. If they chose to do so, they could absolutely implement a similar dynamic configuration for flat text file configuration. The merits of flat text versus LDAP database configuration have been debated to no end, and I don't intend to reopen that discussion, but rather simply to point out it was a choice and not a restriction. If you don't see why dynamic configuration is a good idea, then you probably shouldn't be using LDAP for anything too important, anyway. I guess if we're going to play at being haughty, perhaps people that cannot differentiate between where the configuration is stored and how it is processed shouldn't be using LDAP for anything too important, anyway… I personally believe that support for static configuration should be removed already because having two different configuration systems in place serves to confuse a lot of people, especially learners. That statement is true; but if you had to pick which configuration system confused more people, especially learners, it wouldn't be the flat text file implementation…
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
On 13/05/2014 11:01, Mike Jackson wrote: In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. I don't need anything of this. I just need a simple LDAP server for a small business, where the complexity of dynamic configuration is just a cost with no benefit. And anyway a lot of services (bind, apache, posfix just to name a few) implemented dynamic configuration by the means of a kill -HUP. Simone
RE: password policy module memory leaks / excessive replication?
From: Quanah Gibson-Mount Sent: Thursday, May 08, 2014 3:43 PM Nope... I think I have moderator privs even, but I don't recall where I have to log into to do it. :/ There's a couple of people I can bug about it though. The list administrative interface is at: http://www.openldap.org/lists/mm/admin/openldap-devel But you probably also don't recall the password to get into it ;).
RE: password policy module memory leaks / excessive replication?
--On May 13, 2014 at 1:51:30 PM -0700 Paul B. Henson hen...@acm.org wrote: From: Quanah Gibson-Mount Sent: Thursday, May 08, 2014 3:43 PM Nope... I think I have moderator privs even, but I don't recall where I have to log into to do it. :/ There's a couple of people I can bug about it though. The list administrative interface is at: http://www.openldap.org/lists/mm/admin/openldap-devel But you probably also don't recall the password to get into it ;). Very true. ;) --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
RE: password policy module memory leaks / excessive replication?
From: Quanah Gibson-Mount Sent: Monday, May 12, 2014 7:00 PM I haven't had any luck in reproducing it in my lab. I'd be curious to know if you could share your cn=config setup (minus rootdn passwords), and describe how you are triggering the ppolicy updates in the lab. I'll send you my config off list. The first time this happened, I had enabled the password policy module and configured two policies, one as default, and one explicitly configured on about a dozen service accounts. I played with that for about an hour until I realized the authentication failure granularity was insufficient to meet our account lockout needs. Then it just sat basically idle, and maybe 6-8 hours later it started ramping up memory use and blew up. The second time, I reloaded our dev environment with a snapshot of production data, and started it up with the password policy module loaded, but no actual password policies defined. Once again, within a few hours it started spinning. I'll see if I can get some minimal configuration that reliably reproduces this failure, I don't think our ISO would be on board with shipping you a copy of our production data :). If you're up to gdb debugging, then the first step is to gdb slapd, and set a watchpoint on the serverID, so you can see at which point it gets set to '0' instead of the the correct sid value. My current binaries don't have debugging symbols, but I will build a binary with debugging enabled and give it a try if I get the time. So you mean the slap_serverID variable defined in servers/slapd/ctxcsn.c?
RE: password policy module memory leaks / excessive replication?
--On May 13, 2014 at 2:08:30 PM -0700 Paul B. Henson hen...@acm.org wrote: From: Quanah Gibson-Mount Sent: Monday, May 12, 2014 7:00 PM I haven't had any luck in reproducing it in my lab. I'd be curious to know if you could share your cn=config setup (minus rootdn passwords), and describe how you are triggering the ppolicy updates in the lab. I'll send you my config off list. The first time this happened, I had enabled the password policy module and configured two policies, one as default, and one explicitly configured on about a dozen service accounts. I played with that for about an hour until I realized the authentication failure granularity was insufficient to meet our account lockout needs. Then it just sat basically idle, and maybe 6-8 hours later it started ramping up memory use and blew up. The second time, I reloaded our dev environment with a snapshot of production data, and started it up with the password policy module loaded, but no actual password policies defined. Once again, within a few hours it started spinning. I'll see if I can get some minimal configuration that reliably reproduces this failure, I don't think our ISO would be on board with shipping you a copy of our production data :). That's interesting... it was totally idle (doing nothing at all?). If you're up to gdb debugging, then the first step is to gdb slapd, and set a watchpoint on the serverID, so you can see at which point it gets set to '0' instead of the the correct sid value. My current binaries don't have debugging symbols, but I will build a binary with debugging enabled and give it a try if I get the time. So you mean the slap_serverID variable defined in servers/slapd/ctxcsn.c? No, s_sid in the syncops struct in syncprov.c. That is what was flipping from [1|2|3] - 0 on my systems. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
RE: password policy module memory leaks / excessive replication?
--On May 13, 2014 at 2:21:03 PM -0700 Quanah Gibson-Mount
qua...@zimbra.com wrote:
My current binaries don't have debugging symbols, but I will build a
binary with debugging enabled and give it a try if I get the time. So you
mean the slap_serverID variable defined in servers/slapd/ctxcsn.c?
No, s_sid in the syncops struct in syncprov.c. That is what was flipping
from [1|2|3] - 0 on my systems.
For example, here's what I saw on a problematic master:
(gdb) print *so
$1 = {s_next = 0x0, s_base = {bv_len = 12, bv_val = 0xa857d70
cn=accesslog}, s_eid = 1, s_op = 0xc13a300, s_rid = 0, s_sid = 0,
s_filterstr = {bv_len = 46, bv_val = 0x42ca1f8 }, s_flags = 34, s_inuse =
2, s_res = 0x0, s_restail = 0x0, s_mutex = {__data = {__lock = 0, __count =
0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev =
0x0, __next = 0x0}}, __size = '\000' repeats 39 times,
We can see here that s_sid = 0 instead of 2 (The server ID of this master)
The other issue here is that it has also lots the rid (s_rid=0). We use
rids of 100 and up in my configurations. So you can watch on both of those,
and see what triggers first.
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Well, I can say that I operate OpenLDAP at an enterprise level and the configuration do not change very often here. The dynamic configuration is something that could be useful but definetly is not required for me. I also think the term enterprise-grade is misleading. There is a lot of junk software out there which call themselves enterprise solution but in fact are just garbage. I can give a list of LDAP servers which have dynamic configuration but can't scale, can't keep data sync between the servers, fail frequently and etc. At the end of the day the most important thing for me and business people is stability/performance and if one can't configure OpenLDAP with all man pages and documentation that it have, maybe it's in the wrong role. Em 13-05-2014 16:47, Simone Piccardi escreveu: On 13/05/2014 11:01, Mike Jackson wrote: In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. I don't need anything of this. I just need a simple LDAP server for a small business, where the complexity of dynamic configuration is just a cost with no benefit. And anyway a lot of services (bind, apache, posfix just to name a few) implemented dynamic configuration by the means of a kill -HUP. Simone Esta mensagem é somente para uso do destinatário informado e pode conter informações privilegiadas, proprietárias, ou privadas. Se você recebeu esta mensagem por engano, por favor notifique o remetente imediatamente e apague a original. Qualquer uso deste email é proibido. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- Matheus Morais Plataforma e Aplicações de TI Confederação SICREDI - Porto Alegre 51 3358-7143 http://www.sicredi.com.br www.sicredi.com.br Esta mensagem é somente para uso do destinatário informado e pode conter informações privilegiadas, proprietárias, ou privadas. Se você recebeu esta mensagem por engano, por favor notifique o remetente imediatamente e apague a original. Qualquer uso deste email é proibido. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. signature.asc Description: OpenPGP digital signature
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Paul B. Henson wrote: From: Mike Jackson Sent: Tuesday, May 13, 2014 2:02 AM In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. It enables you to perform critical adjustments to your service without interrupting your service (more or less depending on the implementation). You seem to be confusing the concept of dynamic configuration, the ability to change the configuration of a running service without having to stop said service or disrupt providing the service, with the concept of where the configuration is stored, in a flat text file or in a database. There is absolutely no reason why openldap could not support dynamic configuration when the configuration is stored in a flat text file. There are numerous examples of services which store their configuration in a flat text file, and are capable of rereading that file and dynamically changing the running configuration based on the changes found. Yes, the current implementation of openldap only supports dynamic configuration when the configuration is stored in an LDAP database, but that is not an inherent limitation of storing configuration in a flat text file, but simply the preference of the openldap developers. If they chose to do so, they could absolutely implement a similar dynamic configuration for flat text file configuration. The merits of flat text versus LDAP database configuration have been debated to no end, and I don't intend to reopen that discussion, but rather simply to point out it was a choice and not a restriction. It was the only sane choice, and as you are not a developer and were not participating in the design discussions back in 2002-2003 you're not in any position to comment or critique on it. And judging from your commentary, you're not qualified to offer an opinion. It's all well and fine for you to say sure they could have kept the flat text file but we would have had to invent a remote administration protocol and all of its required security mechanisms. Reinventing those wheels would have been stupid, when we already have highly evolved protocol, data model, and security mechanisms in place. Keep in mind that none of puppet/chef/cfengine/what-have-you existed or were in common use in that timeframe. You cannot sanely rewrite a slapd.conf file from machine-generated code and expect it to resemble the original input. Since sysadmins tended to be sloppy and put config directives where they didn't belong, it was guaranteed that any dynamically modified file would still be reorganized relative to the input. Nor can you sanely reload an entire slapd.conf file without doing a bunch of redundant parsing, to skip over the parts that didn't change. It's a lot of work simply to find the parts that didn't change, unless you invent a network protocol that lets you send deltas. But oh wait, we already have a protocol with that - we can use the LDAPModify operation. Only a moron would have chosen any other design path than the one we took. Any other path would have been tons of redundant code, redundant processing, and still caused complaints from clueless ungrateful users because it transformed their sloppily constructed config files into something else. If you don't see why dynamic configuration is a good idea, then you probably shouldn't be using LDAP for anything too important, anyway. I guess if we're going to play at being haughty, perhaps people that cannot differentiate between where the configuration is stored and how it is processed shouldn't be using LDAP for anything too important, anyway… I personally believe that support for static configuration should be removed already because having two different configuration systems in place serves to confuse a lot of people, especially learners. That statement is true; but if you had to pick which configuration system confused more people, especially learners, it wouldn't be the flat text file implementation… You're entirely mistaken. LDAP administrators have to know how LDIF works anyway. LDAP administrators have to know about ldapsearch/add/modify slapadd/slapcat anyway. LDAP administrators have to know how to read schema anyway. This is, in fact, shortening the learning curve for brand new admins. You're just too stuck in your flatland ways to recognize that fact. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Simone Piccardi wrote: On 13/05/2014 11:01, Mike Jackson wrote: In any case, dynamic configuration IS an enterprise-grade/carrier-grade feature as opposed to static configuration. I don't need anything of this. I just need a simple LDAP server for a small business, where the complexity of dynamic configuration is just a cost with no benefit. And anyway a lot of services (bind, apache, posfix just to name a few) implemented dynamic configuration by the means of a kill -HUP. That's not really dynamic configuration. Anything that requires you to physically login to a server to issue a change is not scalable. With cn=config you can delegate configuration privileges across an arbitrarily large network, without requiring any host/OS privileges. Most people didn't need electricity when they still had oil lamps... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
On 14/05/2014 00:58, Howard Chu wrote: Most people didn't need electricity when they still had oil lamps... If I'm going in a cave almost everytime I still need an oil lamp. Bringing there electricity can be far more costly. Yes for a solution for arbitrarily large networks cn=config could be more scalable and cheaper. But that's not true for a small server for a small organization that doesn't need the extra complexity. I don't want to understate the pros of cn=config, I just state my opinion about the cons. If you tell me the maintaining slapd.conf is too costly in terms of developers energies I've nothing to say. But I don't agree that cn=config is always better. Simone
RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
From: Howard Chu Sent: Tuesday, May 13, 2014 3:56 PM It was the only sane choice, and as you are not a developer and were not participating in the design discussions back in 2002-2003 you're not in any position to comment or critique on it. And judging from your commentary, you're not qualified to offer an opinion. I see, you're going to go with the your opinion differs from mine; therefore, you are clearly not qualified to have an opinion argument? As a systems administrator who has been managing large-scale distributed systems since the mid-90s, I think I do actually have the qualifications to have an opinion on configuration management. It's all well and fine for you to say sure they could have kept the flat text file but we would have had to invent a remote administration protocol and all of its required security mechanisms. Really? It's amazing then how other enterprise scale software packages such as Apache httpd managed to survive using flat text file configuration models without inventing secure remote administration protocols for deploying that configuration. Again, you're mixing up two things – how configuration is processed, and how configuration is delivered. You are tightly coupling two things that do not need to be coupled, basically decreeing by fiat that only that configuration which arrives over the LDAP protocol may be dynamically placed into effect. If someone already has a secure way of delivering flat text file configuration updates, too bad, they don't get to be dynamically applied. Not because it's impossible to reload a configuration file and apply the changes, but because you don't want to do it. stupid, when we already have highly evolved protocol, data model, and security mechanisms in place. Keep in mind that none of puppet/chef/cfengine/what-have-you existed or were in common use in that timeframe. Perhaps, but in the late 90s, before this design discussion that I didn't participate in even took place, I already had secure mechanisms for delivering configuration files to large distributed networks of systems. You cannot sanely rewrite a slapd.conf file from machine-generated code and expect it to resemble the original input. I have no expectation that you will rewrite my slapd.conf. My expectation is that *I* will rewrite my slapd.conf, and then slapd will reread it and apply the change configuration. Nor can you sanely reload an entire slapd.conf file without doing a bunch of redundant parsing, to skip over the parts that didn't change. It's a lot of work simply to find the parts that didn't change, unless you invent a network protocol that lets you send deltas. But oh wait, we already have a protocol with that - we can use the LDAPModify operation. I don't think I ever claimed it wouldn't involve some additional code, some additional work, to allow dynamic reconfiguration from rereading a flat text configuration; I simply claimed it is possible. And redundant or not, parsing a configuration file into a configuration structure is hardly intractable, nor is running through the existing in-place configuration and comparing it to the new configuration just loaded in determining the differences. Only a moron would have chosen any other design path than the one we took. All those morons that would really really really like the ability to have slapd dynamically reload its configuration from a changed flat text file, please raise your hands? Based on the mailing list archives, there seem to be quite a few of us. And I guess now we have degenerated to the if you wouldn't have done it the way I did, you're a moron argument. Any other path would have been tons of redundant code, redundant processing, and still caused complaints from clueless ungrateful users because it transformed their sloppily constructed config files into something else. Assuming the implementation of what I would actually want, not the implementation you are currently imagining I would want, that is blatantly false, as nothing would ever touch the configuration file other than the user or their agent. The whole point is I don't want something *else* touching my configuration files, I want my *configuration management system* generating them. You're entirely mistaken. LDAP administrators have to know how LDIF works anyway. LDAP administrators have to know about ldapsearch/add/modify slapadd/slapcat anyway. LDAP administrators have to know how to read schema anyway. This is, in fact, shortening the learning curve for brand new admins. By that argument, apache administrators need to know how http works, so it would only make sense to manage an apache server configuration via HTTP PUT. And bind administrators clearly do need to know the details of the DNS protocol, so it only makes sense to manage named configuration via secure dns updates. Anybody running samba should surely know the details of the CIFS protocol, so obviously samba
RE: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
From: Howard Chu Sent: Tuesday, May 13, 2014 3:59 PM That's not really dynamic configuration. Anything that requires you to physically login to a server to issue a change is not scalable. With cn=config you can delegate configuration privileges across an arbitrarily large network, without requiring any host/OS privileges. Ah, yes, the I'm going to redefine terminology so your argument is no longer valid approach. I never said I had to or planned to physically login to a server to make a change. I simply said that reloading a flat text configuration file and applying any configuration changes in it is a valid and reasonable approach. Perhaps in a scenario where the person managing the LDAP server configuration does not have any operating system privileges, your feature would be invaluable. But in an environment where the person managing the operating system configuration itself is also managing the LDAP server configuration, it is meaningless. What next, you're going to offer the feature for slapd to proxy changes to the operating system configuration files via the LDAP interface? You just don't seem to understand or accept that deployment scenarios other than the one you envision exist, are useful, or should be supported, and that the ability to manage openldap via existing infrastructure that is already managing other systems and applications is a valuable feature. Most people didn't need electricity when they still had oil lamps... Many people still drive a manual transmission vehicle even after the widespread availability of the automatic transmission. See, I can spew irrelevant platitudes too… You can reply to this if you like, but I'm done with the debate, as clearly you will never accept an alternative viewpoint and banging my head against a concrete wall is not my favorite hobby. While I have great respect for your skills and knowledge, and great appreciation for your work with openldap, I think your opinion on this particular topic is a bit too artificially ingrained.
RE: password policy module memory leaks / excessive replication?
From: Quanah Gibson-Mount Sent: Tuesday, May 13, 2014 2:21 PM That's interesting... it was totally idle (doing nothing at all?). Yes, the absolute only activity after slappadd'ing the data and starting the server were the automated accesses to the monitoring backend by a service account. No, s_sid in the syncops struct in syncprov.c. That is what was flipping from [1|2|3] - 0 on my systems. Ah, ok.
RE: password policy module memory leaks / excessive replication?
--On May 13, 2014 at 5:46:38 PM -0700 Paul B. Henson hen...@acm.org wrote: From: Quanah Gibson-Mount Sent: Tuesday, May 13, 2014 2:21 PM That's interesting... it was totally idle (doing nothing at all?). Yes, the absolute only activity after slappadd'ing the data and starting the server were the automated accesses to the monitoring backend by a service account. Ok. Hm, I was wondering if it was related to the accesslog purge, but your purge only happens once a day for things 1 week old, so that wouldn't have hit in such a short term. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Have you seen this FUD - IT pros suffer OpenLDAP configuration headaches ?
Paul B. Henson wrote: You can reply to this if you like, but I'm done with the debate, as clearly you will never accept an alternative viewpoint and banging my head against a concrete wall is not my favorite hobby. While I have great respect for your skills and knowledge, and great appreciation for your work with openldap, I think your opinion on this particular topic is a bit too artificially ingrained. You really think what you're suggesting wasn't suggested already, 12 years ago? You really think we didn't already *try* it and see that it didn't work? This is why advice and opinions from people like you is utterly worthless. If you didn't participate in the work leading up to the current implementation, and didn't walk through the code and previous designs, and don't understand the coding implications of a particular approach, then you've got nothing valid to contribute to the topic. If you didn't read the debates from the openldap-devel mailing list back when this was first covered, you've got no business rehashing the conversation now. If you didn't actually spend any of your own time writing code to test an approach, failing, and trying another approach, you've got no right to demand any particular implementation from anyone else. http://www.openldap.org/conf/odd-wien-2003/proceedings.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
