openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Issue upgrading openldap-clients from 2.4.19-15 to 2.4.23-20
by Esther Garcia 24 May '12

24 May '12

Hi all, We have an OpenLDAP server (RHEL6) running version 2.4.23-15, and we have clients in RHEL5 and RHEL6. With clients in RHEL5 works properly but I found some problems with RHEL6 clients in versions newer than 2.4.19-15. In the clients, if I try to upgrade to new versions than 2.4.19-15 then the client stops working: [root@XX ~]# rpm -qa | grep openldap openldap-2.4.19-15.el6.x86_64 openldap-clients-2.4.19-15.el6.x86_64 [root@XX ~]# ldapsearch -x -D 'cn=authenticate, ou=System,dc=test, dc=es' '(objectclass=*)' -W -ZZ Enter LDAP Password: # extended LDIF # # LDAPv3 ...... [root@XX ~]# id esther uid=63004(esther) gid=50041(test) groups=50041(test) [root@XX ~]# yum upgrade openldap* ..... Updating : openldap-2.4.23-20.el6.x86_64 1/4 warning: /etc/openldap/ldap.conf created as /etc/openldap/ldap.conf.rpmnew Updating : openldap-clients-2.4.23-20.el6.x86_64 2/4 Cleanup : openldap-clients-2.4.19-15.el6.x86_64 3/4 Cleanup : openldap-2.4.19-15.el6.x86_64 4/4 Updated: openldap.x86_64 0:2.4.23-20.el6 openldap-clients.x86_64 0:2.4.23-20.el6 Complete! [root@XX ~]# service nslcd restart Stopping nslcd: [ OK ] Starting nslcd: [ OK ] [root@XX ~]# id esther id: esther: No such user [root@XX ~]# ldapsearch -x -D 'cn=authenticate, ou=System,dc=test, dc=es' '(objectclass=*)' -W -ZZ ldap_start_tls: Connect error (-11) I have the same configuration files that used with the older version. I use these configuration files: */etc/pam_ldap.conf:* base dc=test,dc=es binddn cn=authenticate,ou=System,dc=test,dc=es bindpw XXXX timelimit 120 bind_timelimit 120 idle_timelimit 3600 pam_lookup_policy yes pam_password exop nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm ssl start_tls uri ldap://ldap1-test ldap://ldap2-test tls_cacertdir /etc/openldap/cacerts pam_password md5 */etc/nslcd.conf* uid nslcd gid ldap uri ldap://ldap1-test ldap://ldap2-test base dc=test,dc=es binddn cn=authenticate,ou=System,dc=test,dc=es bindpw XXXX ssl start_tls tls_cacertdir /etc/openldap/cacerts timelimit 120 bind_timelimit 120 idle_timelimit 3600 */etc/openldap/ldap.conf:* URI ldap://ldap1-test/ ldap://ldap2-test/ BASE dc=test,dc=es TLS_CACERT /etc/openldap/cacerts/catest.crt *CAcert file:* [root@XX ~]# ls -l /etc/openldap/cacerts/catest.crt -rw-r--r--. 1 root root 1655 May 23 15:23 /etc/openldap/cacerts/catest.crt Any idea on what the issue is? Am I missing anything? Thanks in advance, Esther

2 3

Re: dn.exact vs dn.base
by Turbo Fredriksson 24 May '12

24 May '12

[sorry, should have gone to the list] On Thu, 24 May 2012 14:02:28 +0300, Nick Milas wrote: > access to dn.base="ou=system,dc=example,dc=com" > by dn.exact="uid=userx,ou=people,dc=example,dc=com" write This gives 'uid=userx,...' access to 'ou=system,...' _and everything below it_. > access to dn.exact="ou=system,dc=example,dc=com" > by dn.base="uid=userx,ou=people,dc=example,dc=com" write While this is the opposite - it gives 'uid=userx,...' and any objects below this (not much point in this exact example :) to ONLY the base object 'ou=system,...'. For example: ----- s n i p ----- access to dn.exact="" attrs=supportedSASLMechanisms,namingContexts,subschemaSubentry,objectClass,monitorContext,configContext,entry by domain.subtree="bayour.com" read by peername.ip="127\.0\.0\.1" read by peername.ip="192\.168\.69\.8" read by peername.path="/var/run/slapd/ldapi" read ----- s n i p ----- This gives almost anonymous access to certain attributes to the base DN...

2 1

Re: Migrating from slapd 2.3 to 2.4
by Bobby Krupczak 23 May '12

23 May '12

Hi! > This is an old can of worms, Bobby. > Basically, Quanah & the OpenLDAP developers are not interested in > supporting old versions, because it takes away from the time they have > to work on the current version. We as users should support this, > because the software will stop growing if the devs spend too much time > on older versions. I understand completely. I write software myself and only admin my network enough to support my software development. I have a small number of users but a large number of machines hence why I use ldaps. I dont want to support years old releases of my own software. However, I dont radically change my config file formats either :) > I've followed this policy for the decade or so that I've been using > OpenLDAP and been very successful. I am running a large infrastructure > of Red Hat OL builds right now - dozens of replicas, with no problems > whatsoever. Thanks!! I'm going to tackle the conversion after I get this new system in place. Bobby

5 11

Re: checking replica dbs for consistency
by Nick Milas 23 May '12

23 May '12

On 23/5/2012 5:51 μμ, Charles T. Brooks wrote: > > <Mail content is a bit scrambled (text with spaces between chars), but I managed to read !!> > Charles, Thank you for your thoughts. I agree with you. There can/should be a number of consumers fully replicating the DIT so that they can be promoted to masters whenever needed. However, we do have and want some consumers with limited data replication. For example, our mail server runs a consumer replicating only the user accounts needed and only the ldap-hosted aliases. I don't want to replicate more ldap data there, there is no need to expose more data there and to load the server with unneeded replication operations. We are replicating on the mail server so that we can do *local* ldap lookups and achieve better mail server performance. Additionally, our DNS masters, replicate only the DNS resource records (also ldap-hosted). They don't need any info about users and aliases. We are also replicating there so that we can do local ldap lookups and achieve better DNS server performance. But I want to be able to check whether all partially replicated data are replicating as they should! One solution would be to define some non-root DN which *will be able to* replicate the whole DIT and use it in consumer configuration, then limit replication *using filters*. But this limits options and affects DIT architecture in the first place (not necessarily bad, but we would need to re-evaluate some things and it's not easy when in production). Thank you again for your time and thoughts, Nick

1 0

Re: checking replica dbs for consistency
by Nick Milas 23 May '12

23 May '12

On 23/5/2012 4:39 μμ, Charles T. Brooks wrote: > I u s e s l a p c a t t o d u m p t h e d a t a b a s e s t o L D I F f i l e s , s o r t t o n o r m a l i z e t h e o r d e r i n g , a n d d i f f t o c h e c k f o r d i f f e r e n c e s . Thank you, As I said, this actually would work only when replicating *the whole* DIT. By the way, what happens with the operational attributes - are they (supposed to be) identical on both ends? I am expecting any hints on comparing partial replicated data (based on consumer bind DN) ! Nick

2 1

ppolicy 'Constraint violation' with no additional info
by Jean-Philippe Braun 23 May '12

23 May '12

Hi all, I'm using ppolicy for some time now but sometimes when a user changes its password we get a 'Constraint violation' error without any additional info like 'Password is too young to change' or 'Password is in history of old passwords'. So I'm not sure where it fails. Does anybody have some idea on which case(s) this could happen ? (still using 2.4.23 on debian stable) Thanks

2 1

Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
by Michael Ströder 22 May '12

22 May '12

harry.jede(a)arcor.de wrote: > Michael Ströder wrote: >> The goal was to make the ACLs more readable for the admin. > This is my intend. Now the question is: Where to make them more readable. >> The GUI >> just makes it possible for the admin to add the LFs and display the >> ACL as multiple lines. And now this has the effect that the >> attributes values in LDIF are base64-encoded. The admin decides >> whether to add LFs or not. > Right, but are you sure all admins, can handle base64 encoded strings > properly. Tools, especially GUI-Tools should make life easier, not more > complex. Again: Did you read the whole thread in the mailing list archive? >> Please add it via LDAP and display it in a LDAP client. It will be a >> single line which was considered to be less readable. > Yes, and it should be a single line. It's entirely up to you whether you want to add LFs or not. There's no GUI tool forcing you to do so. Not my web2ldap nor Apache Directory Studio mentioned in this thread. Ciao, Michael.

2 2

Re: Fwd: Root cause: Strange OpenLdap performace issue
by Michele Mase' 22 May '12

22 May '12

Sorry, I'didn't understand. Which should be better compile/build options? Michele MAsè On Tue, May 22, 2012 at 12:40 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Tuesday, May 22, 2012 12:06 AM +0200 Michele Mase' < > michele.mase(a)gmail.com> wrote: > > > This is how redhat builds openldap; which are the bad libs? Are they the >> lib crypt (--enable-crypt); what should I use instead? >> Michele Masè >> > > Not crypt. crypto. as in using NSS instead of OpenSSL. > > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 3

Compiling on Windows, using VC or Windows SDK
by Tom Schuetz 22 May '12

22 May '12

Has anyone successfully compiled openldap using Visual Studio, or Windows SDK? If so, could you share your process with me, what you used for a makefile (or vcproj), approach to dependencies, etc? I have VC 2010 Express on a 64-bit Windows 7 box, and then I also have Windows SDK 7.1. I am comfortable with POSIX OSs and have MinGW installed, but for this I would prefer not to use it to actually compile. Am open to using MinGW to make a useable / translatable makefile, though. Thanks very much, Tom S

3 3

Re: Fwd: Root cause: Strange OpenLdap performace issue
by Michele Mase' 22 May '12

22 May '12

configure \ --with-threads=posix \ --enable-local \ --enable-rlookups \ --with-tls=no \ --with-cyrus-sasl \ --enable-wrappers \ --enable-passwd \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --disable-lmpasswd \ --enable-modules \ --disable-sql \ --libexecdir=%{_libdir} build \ --enable-plugins \ --enable-slapd \ --enable-multimaster \ --enable-bdb \ --enable-hdb \ --enable-ldap \ --enable-ldbm \ --with-ldbm-api=%{ldbm_backend} \ --enable-meta \ --enable-monitor \ --enable-null \ --enable-shell \ --enable-sql=mod \ --disable-ndb \ --enable-passwd \ --enable-sock \ --disable-perl \ --enable-relay \ --disable-shared \ --disable-dynamic \ --with-kerberos=k5only \ --enable-overlays=mod This is how redhat builds openldap; which are the bad libs? Are they the lib crypt (--enable-crypt); what should I use instead? Michele Masè On Mon, May 21, 2012 at 11:47 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, May 21, 2012 11:40 PM +0200 Michele Mase' < > michele.mase(a)gmail.com> wrote: > > Is it really bad? Is it buggy? Since redhat has its own ldap 389 dir. >> server, I suppose they don't care of openldap. isn't it? >> Michele Masè >> > > There are known issues with the release they use, and the crypto libraries > it is linked to. > > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical