Issue upgrading openldap-clients from 2.4.19-15 to 2.4.23-20
by Esther Garcia
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
11 years, 6 months
Re: dn.exact vs dn.base
by Turbo Fredriksson
[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...
11 years, 6 months
Re: Migrating from slapd 2.3 to 2.4
by Bobby Krupczak
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
11 years, 6 months
Re: checking replica dbs for consistency
by Nick Milas
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
11 years, 6 months
Re: checking replica dbs for consistency
by Nick Milas
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
11 years, 6 months
ppolicy 'Constraint violation' with no additional info
by Jean-Philippe Braun
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
11 years, 6 months
Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
by Michael Ströder
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.
11 years, 6 months
Re: Fwd: Root cause: Strange OpenLdap performace issue
by Michele Mase'
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
>
11 years, 6 months
Compiling on Windows, using VC or Windows SDK
by Tom Schuetz
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
11 years, 6 months
Re: Fwd: Root cause: Strange OpenLdap performace issue
by Michele Mase'
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
>
11 years, 6 months
