openldap-software September 2008

openldap-software@openldap.org

60 participants
64 discussions

Re: Dependency issue with libldap2.4_2-2.4.11-1.rhel5.i386.rpm
by Buchan Milne 18 Sep '08

18 Sep '08

On Thursday 18 September 2008 16:12:37 karthikd(a)aol.in wrote: > Hello All, > > I was initially trying to build openldap 2.4.11 source on a RHEL 5.0 > system, where in I ran into dependency issues with BDB 4.2, since RHEL > 5.0 comes only with BDB 4.3. > > While searching the openldap-software mailing lists, I came across a > post from Mr.Buchan Milne saying he has openldap 2.4 binary packages on > his site > > http://staff.telkomsa.net/packages/rhel5/openldap/ > > So, I downloaded the openldap 2.4.11 packages from the site above. > > First, I tried to install openldap2.4-2.4.11-1.rhel5.i386.rpm, which > gave me the following dependency errors : > > rpm -ivh openldap2.4-2.4.11-1.rhel5.i386.rpm > warning: openldap2.4-2.4.11-1.rhel5.i386.rpm: Header V3 DSA signature: > NOKEY, key ID 60d204a7 > error: Failed dependencies: > libldap2.4_2 = 2.4.11-1.rhel5 is needed by > openldap2.4-2.4.11-1.rhel5.i386 > > So, then I downloaded libldap2.4_2-2.4.11-1.rhel5.i386.rpm which gave > me the following dependncy errors during installation: > > rpm -ivh libldap2.4_2-2.4.11-1.rhel5.i386.rpm > warning: libldap2.4_2-2.4.11-1.rhel5.i386.rpm: Header V3 DSA signature: > NOKEY, key ID 60d204a7 > error: Failed dependencies: > openldap2.4 >= 2.1.25-4mdk is needed by > libldap2.4_2-2.4.11-1.rhel5.i386 > > I couldn't understand what this dependency error is. Any pointers would I should probably put this somewhere else than just where it is (http://staff.telkomsa.net/packages/OpenLDAP.repo), but it does contain this information: # 1)Save as /etc/yum.repos.d/OpenLDAP.repo # wget http://staff.telkomsa.net/packages/OpenLDAP.repo -O /etc/yum.repos.d/OpenLDAP.repo # 2) # RHEL5: # yum upgrade openldap-servers # or # yum install openldap2.4-servers # RHEL4 and older: # yum install openldap2.3-servers # or # yum install openldap2.4-servers # Install libhoard or lib64hoard for a better memory allocator If you download the RPMS individually, you need to do something like: rpm -Uvh libldap2.4_2-2.4.11-1.rhel5.i386.rpm openldap2.4-2.4.11-1.rhel5.i386.rpm (these two packages are inter-dependant, so they must be upgraded together). Regards, Buchan

1 0

using OpenLDAP client to change directory schema
by Klaus Heinrich Kiwi 17 Sep '08

17 Sep '08

Hi, My understanding is that OpenLDAP software doesn't support subschema modification over LDAP operations, but I'm willing to use OpenLDAP client to change cn=schema on an LDAP server (different vendor) that supports it. Is that possible? Or is the OpenLDAP checking for cn=schema at the client? The output I'm getting is: [root@pam ~]# ldapmodify -H ldap://host -D cn=root -w passwd -x -ZZ -a -f /usr/share/doc/krb5-server-ldap-1.6.2/kerberos.ldif ldapmodify: invalid format (line 5) entry: "cn=schema" [root@pam ~]# Thanks, -Klaus -- Klaus Heinrich Kiwi <klausk(a)linux.vnet.ibm.com> Linux Security Development, IBM Linux Technology Center

3 4

schema replication 2.4
by Daniel Paufler 17 Sep '08

17 Sep '08

Hello List I already searched the archives but did not find a clue. I am using slapd 2.4.9 on Ubuntu Hardy. I set up two servers, one master, one slave. On the master, i have cn=config with samba schema included. On the slave, i do a full clean install via: rm -rf slapd.d/* slaptest -f slapd.conf.old -F slapd.d chown openldap:openldap slapd.d -R This gives me an empty database and standard cn=config with nothing but standard build-in schema. (core, cosine, nis, inetorgperson) Going further, i insert the syncrepl statement on the slave ldapadd -W -x -D "cn=admin,cn=config" -f init_slave_db.ldif ---- dn: olcDatabase={1}hdb,cn=config changetype: modify add: olcSyncRepl olcsyncrepl: {0}rid=001 provider=ldap://masterLDAP binddn="cn=replication,dc=tree" bindmethod=simple credentials=<PW> searchbase="dc=tree" type=refreshAndPersist interval=00:00:00:10 - add: olcUpdateRef olcUpdateRef: ldap://masterLDAP ----- Now, my whole LDAP dc=tree is aviable on the slave. If i now insert syncrepl for cn=schema,cn=config ldapadd -W -x -D "cn=admin,cn=config" -f init_slave_config.ldif ------ dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=002 provider=ldap://masterLDAP binddn="cn=admin,cn=config" bindmethod=simple credentials=<PW> searchbase="cn=schema,cn=config" type=refreshOnly interval=00:00:00:10 --- When i now want to change the slave daemon loglevel by entering olcLoglevel, i get an error 53: no update referral summing up, when i insert schema replication, i can not change anythin in cn=config on my slave - not only in cn=schema,cn=config. Is that default behavior or do i miss something? Any hints appreciated. Daniel

4 7

Re: Upgrading 2.3.x -2.4.x
by FRLinux 16 Sep '08

16 Sep '08

On Tue, Sep 16, 2008 at 11:11 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > There isn't 4.7 support until OpenLDAP 2.4.12 is released. Sleepycat > considers 4.7 stable. Thanks for clarifying, I'll be starting some migration on 2.4 in the next week hence my anxiety :) Cheers, Steph

1 0

Re: Upgrading 2.3.x -2.4.x
by FRLinux 16 Sep '08

16 Sep '08

On Tue, Sep 16, 2008 at 9:00 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Personally I'd go with 4.6 with 2.3, and 4.7 with 2.4. ;) But going from > 2.3 to 2.4 you pretty much want to do a slapcat/slapadd anyway. Hey Quanah, Your smiley at the end of the sentence scares me a bit, does it mean 4.7 wouldn't be quite stabilized just yet? Cheers, Steph

2 1

openldap tls problem
by Michael Fischer 16 Sep '08

16 Sep '08

hi, i hope this is the right list for my problem, if not sorry in advance. i want to configure slapd to use tls. i have a certifikate signed by globalsign and the following lines in my slapd.conf: <snip> TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCertificateFile /etc/postfix/certs/ldap.pem TLSCertificateKeyFile /etc/postfix/certs/ldap.key TLSCACertificateFile /etc/postfix/certs/globalsign-domainssl.pem </snip> but when issuing a ldapsearch on another machine i still get an error: <snip> # ldapsearch -bdc=xxx,dc=at -Dcn=admin,dc=xxx,dc=at -hldap.xxx.at -p389 -x -W -ZZ -d5 objectClass=* ... TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 2, err: 19, subject: /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root, issuer: /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect. ldap_perror ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed </snip> the same globalsign-certificates work well with my apache. any hints? lg, Michael Fischer -- email: michi.fischer(a)gmx.net web: http://www.webfischer.at

4 4

Re: Upgrading 2.3.x -2.4.x
by FRLinux 16 Sep '08

16 Sep '08

On Tue, Sep 16, 2008 at 8:40 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > (although I would make sure to use a BDB later than 4.2, since the next OL > 2.4 release will only support BDB 4.4 and up). So, if we are currently running 4.2 (FreeBSD systems) with 2.3, you'd advise on dumping data via slapcat and just wipe out db4.2 and replace with 4.4? Cheers, Steph

2 1

Upgrading 2.3.x -2.4.x
by Peter Clark 16 Sep '08

16 Sep '08

Hello, We have an OpenLDAP 2.3.43 implementation. Right now the database is rather small but I am looking at populating it fully (soon) and moving it into production to replace an ancient OpenLDAP install. 2.3.43 works, it does what I need it to but I am at a point that if I was going to upgrade now would be the time to make the jump. Is there any clear cut upgrade process? Any help would be appreciated. Peter

3 2

Bizarre error while initializing a DIT
by Maykel Moya 16 Sep '08

16 Sep '08

I'm trying to initialize a DIT. This is the error I get: root@tpro:/var/lib/ldap# slapadd -v -n 2 -l tproca1st.ldif PROXIED attributeDescription "DC" inserted. hdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapadd: dn="DC=tpro,DC=ca" (line=1): (64) naming attribute 'DC' is obsolete root@tpro:/var/lib/ldap# cat tproca1st.ldif dn: dc=tpro,dc=ca objectClass: top objectClass: dcObject objectClass: organization o: My test Orga dc: tpro root@tpro:/var/lib/ldap# slapcat -b cn=config ... dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcSuffix: DC=tpro,DC=ca olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap/tproca olcDbCacheSize: 1000 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 4194304 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbLinearIndex: FALSE olcDbMode: 384 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcHdbConfig entryUUID: 140c5ffc-f953-102c-9659-bb5cef3694ca creatorsName: cn=config createTimestamp: 20080808050326Z olcDbIndex: objectClass eq olcDbIndex: mail eq olcAccess: {0}to dn.subtree="ou=users,dc=tpro,dc=ca" filter="(objectClass=sldM ailRecipient)" attrs=mail,sldMailbox,userPassword by dn="cn=dovecot,dc=tpro,dc=ca" read by * break olcAccess: {1}to attrs=entry,uid,objectClass by dn.base="cn=dn-search,dc=tpro,dc=ca" read by * break olcAccess: {2}to attrs=userPassword,shadowLastChange by dn.base="cn=admin,dc= tpro,dc=ca" write by anonymous auth by self write by * none olcAccess: {3}to dn.base="" by * read olcAccess: {4}to * by dn.base="cn=admin,dc=tpro,dc=ca" write by * read entryCSN: 20080818145521.939111Z#000000#000#000000 modifiersName: cn=admin,DC=tpro,DC=ca modifyTimestamp: 20080820145521Z I'm using Ubuntu package for slapd 2.4.11. Any hints? Regards, maykel

3 4

Unix socket auth(EXTERNAL) not working in netbsd
by David Markey 16 Sep '08

16 Sep '08

netbsd# /usr/pkg/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.11 (Sep 15 2008 00:03:54) $ root(a)netbsd.dmarkey.com: /usr/pkgsrc/databases/openldap-server/work/openldap-2.4.11/servers/slapd netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn: External isnt listed. I assume that the unix socket API is slightly different.: man unix The LOCAL_CREDS option may be enabled on a SOCK_DGRAM or a SOCK_STREAM socket. This option provides a mechanism for the receiver to receive the credentials of the process as a recvmsg(2) control message. The msg_con- trol field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by a variable length sockcred structure, defined in <sys/socket.h> as follows: struct sockcred { uid_t sc_uid; /* real user id */ uid_t sc_euid; /* effective user id */ gid_t sc_gid; /* real group id */ gid_t sc_egid; /* effective group id */ int sc_ngroups; /* number of supplemental groups */ gid_t sc_groups[1]; /* variable length */ }; The LOCAL_PEEREID option may be used with getsockopt(2) to get the PID and effective user and group IDs of a SOCK_STREAM peer when it did connect(2) or bind(2). The returned structure is struct unpcbid { pid_t unp_pid; /* process id */ uid_t unp_euid; /* effective user id */ gid_t unp_egid; /* effective group id */ }; as defined in <sys/un.h>. The SOCKCREDSIZE() macro computes the size of the sockcred structure for a specified number of groups. The cmsghdr fields have the following val- ues: cmsg_len = sizeof(struct cmsghdr) + SOCKCREDSIZE(ngroups) cmsg_level = SOL_SOCKET cmsg_type = SCM_CREDS Any ideas? Howard i assume you would be an authority to answer this one. Thanks.

5 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software September 2008