Re: Dependency issue with libldap2.4_2-2.4.11-1.rhel5.i386.rpm
by Buchan Milne
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
15 years
using OpenLDAP client to change directory schema
by Klaus Heinrich Kiwi
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
15 years
schema replication 2.4
by Daniel Paufler
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
15 years
Re: Upgrading 2.3.x -2.4.x
by FRLinux
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
15 years
Re: Upgrading 2.3.x -2.4.x
by FRLinux
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
15 years
openldap tls problem
by Michael Fischer
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
15 years
Re: Upgrading 2.3.x -2.4.x
by FRLinux
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
15 years
Upgrading 2.3.x -2.4.x
by Peter Clark
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
15 years
Bizarre error while initializing a DIT
by Maykel Moya
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
15 years
Unix socket auth(EXTERNAL) not working in netbsd
by David Markey
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.
15 years
