Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it
pitpalme+openldap(a)gmail.com wrote:
> Full_Name: Peter Palmreuther
> Version: 2.4.19
> OS: FreeBSD 7.2 / Solaris 8
> URL:
> Submission from: (NULL) (87.123.91.4)
>
>
> I've set up OpenLDAP to run in "MirrorMode":
>
> # [...]
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 100
> # [...]
> syncrepl rid=001
> provider=ldap://localhost:11389
> type=refreshAndPersist
> searchbase="o=esolution,dc=deutscherv,dc=de"
> schemachecking=on
> bindmethod=simple
> binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de"
> credentials="M1rr0rM3"
> retry="60 +"
>
> serverID 1
> mirrormode on
> # [...]
>
> The second server is set up identically, except "serverID" is 2 and "provider"
> is set to URL of first server. The fact addresses are "localhost" is because I
> replicated my main setup on my private server (FreeBSD) to better inspect and
> debug the problem.
>
> When adding, modifying and deleting an entry it can happend I do get a positive
> return from delete, but a subsequent "add" fails with "code=68: Already
> exists".
Can you check whether the entry actually exist, although in "glue"
state? You can do this by searching (e.g. with ldapsearch) as the
rootdn, to bypass access checking, and using the manageDSAit control (-MM).
p.
12 years, 7 months
(ITS#6247)
by daniel＠pluta.biz
Hi,
I've uploaded a cleaned up version. It's nearly a complete rewrite of
the original contribution.
In addition to the previous version which (intentionally) just supported
the constant MRA "NOW" the updated version also supports now[+/-]offset
calculation and matching. The offset's syntax is
"NYears#Nmonths#Ndays#NHours#NMinutes#NSeconds"
where '#' separates the different time unit fields and N is the amount
of time (offset) for a distinct time unit. N can be a negative or
positive value (all none-digits and blanks are ignored, multiple signs
are simply aggregated to a single (the first from the left) sign).
Thanks to previous normalization before the actual matching the
"timedrift effect" (see followup #4 above) isn't present any more, too.
The two matching rule's (nowOrEarlier/nowOrLaterMatch) are compatible
with any generalizedTime-syntax based attribute. Additionally the module
introduces two specialized syntaxes exclusively dedicated to this
modules matching rules (intentionally not supporting any kind of
generalizedTime[Ordering]Match-ing extensible match).
Please have a look at the README, the sample schema definition, and/or
the source for further details.
The current version can be found here:
ftp://ftp.openldap.org/incoming/daniel-pluta-now-091110-1.tgz
Any kind of feedback is very welcome.
Thanks a lot!
Daniel
12 years, 7 months
(ITS#6369) Get rid of cacertdir_rehash
by FullName＠in-valid.com
Full_Name: Full Name
Version: 2.3.43
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:708:10:10:21c:25ff:fe98:3f0e)
It is inconvenient to have to use cacertdir_rehash command to hash the certs.
IMO it does not service any purpose. It would be nice if cert could be just
dropped to a dir and then openldap sees it.
12 years, 7 months
(ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com
Full_Name: Peter Palmreuther
Version: 2.4.19
OS: FreeBSD 7.2 / Solaris 8
URL:
Submission from: (NULL) (87.123.91.4)
I've set up OpenLDAP to run in "MirrorMode":
# [...]
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# [...]
syncrepl rid=001
provider=ldap://localhost:11389
type=refreshAndPersist
searchbase="o=esolution,dc=deutscherv,dc=de"
schemachecking=on
bindmethod=simple
binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de"
credentials="M1rr0rM3"
retry="60 +"
serverID 1
mirrormode on
# [...]
The second server is set up identically, except "serverID" is 2 and "provider"
is set to URL of first server. The fact addresses are "localhost" is because I
replicated my main setup on my private server (FreeBSD) to better inspect and
debug the problem.
When adding, modifying and deleting an entry it can happend I do get a positive
return from delete, but a subsequent "add" fails with "code=68: Already
exists".
This does not happen all the time, but often enough to name it "reproducible".
This seems not to happen if there's a "sleep" between modify and delete. It also
seems not to happen if secondary server is down.
12 years, 7 months
Bug in deleting entry in MirrorMode?
by Peter Palmreuther
Hello,
I'm writing to this list to clarify if I discovered a bug or just did not
configure OpenLDAP properly.
I've set up OpenLDAP to run in "MirrorMode":
# [...]
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# [...]
syncrepl rid=001
provider=ldap://localhost:11389
type=refreshAndPersist
searchbase="o=esolution,dc=deutscherv,dc=de"
schemachecking=on
bindmethod=simple
binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de"
credentials="M1rr0rM3"
retry="60 +"
serverID 1
mirrormode on
# [...]
The second server is set up identically, except "serverID" is 2 and
"provider" is set to URL of first server. The fact addresses are "localhost"
is because I replicated my main setup on my private server to better inspect
and debug the problem.
When adding, modifying and deleting an entry it can happend I do get a
positive return from delete, but a subsequent "add" fails with "code=68:
Already exists".
This does not happen all the time, but often enough to name it
"reproducible".
This seems not to happen if there's a "sleep" between modify and delete. It
also seems not to happen if secondary server is down. So either I've got a
configuration problem or there's a problem with synchronization.
Anybody here to help, tracking down this problem?
Thanks a lot, and
--
Regards,
Peter
12 years, 7 months
(ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com
Full_Name: olivier chirossel
Version: 2.4.17 and 2.4.19
OS: linux
URL: http://86.64.145.174:8080/
Submission from: (NULL) (62.39.9.251)
in refreshend persist mode, the replication is incorrect for an entry which be
delete/add after master restart and before the reconnection of the slave.
steps to reproduce :
0) two linux server (one for the master, one for the slave)
on the master ip : 10.143.73.9
on the slave ip : 10.143.73.71
1) kernel configuration on the slave
by default tcp_keepalive_time 7200 on linux and tcp_keepalive_probes 9
put in /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_probes = 2
and
sysctl -p
2) master set up
on /etc/openldap tar xvf slapd_master.tar (get on the url )
and
slapd -F /etc/openldap/slapd.d
and
ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f first.ldif (get on
url)
2) slave set up
on /etc/openldap tar xvf slapd_slave.tar (get on the url )
and
slapd -F /etc/openldap/slapd.d
2) on the master : add the entry
ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f test1init.ldif
(get on url)
3) on the master : restart the master and delete/add (with new value)
kill `pidof slapd`
slapd -F /etc/openldap/slapd.d
ldapdelete -h 10.153.73.9 -D "cn=admin, cn=config" -w secret
msisdn=6666666660,suffix=0,dc=sfr.com
ldapadd -h 10.153.73.9 -D "cn=admin, cn=config" -w secret -f testcreate.ldif
(get on url)
verify the entry
ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b "
suffix=0,dc=sfr.com"
4) on the slave : see the slave reconnect
netstat -an | grep 389 for see the connection between the slave and the master
ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b "
suffix=0,dc=sfr.com"
see the logs
5) on the slave after reconnection to the master
ldapsearch -L -L -L -D "cn=admin, cn=config" -w secret -b "
suffix=0,dc=sfr.com"
( "no entry for dn msisdn=6666666660,suffix=0,dc=sfr.com" )
6) on the master after reconnection from the slave to the master
in the logs syncprov ... changed by peer, ignored
12 years, 8 months
Re: (ITS#6366) application GUI crashes when openning file by a user created by LDAP
by michael＠stroeder.com
fuzq(a)anl.gov wrote:
> Full_Name: Albert Fu
> Version: 2.3.27-8.el5_2.4.i386
> OS: Scientific Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (164.54.208.62)
>
>
> I have a Linux application software with a text editor developed with QT
> and C++. Every time when openning a file by a user created by LDAP, the
> software crashes with "floating point exception". However, this doesn't
> happen to users added to the system by command 'useradd' or 'Users and
> Groups' tool of the system.
I really doubt that this has something to do with OpenLDAP itself. Regarding
the LDAP side you should try to track down whether the user data returned via
nss_ldap or similar is complete and correct. Anyway the software should not
crash if the user name for a numeric user id cannot be found.
Ciao, Michael.
12 years, 8 months
Re: (ITS#6366) application GUI crashes when openning file by a user created by LDAP
by quanah＠zimbra.com
--On Friday, November 06, 2009 5:07 PM +0000 fuzq(a)anl.gov wrote:
> Full_Name: Albert Fu
> Version: 2.3.27-8.el5_2.4.i386
> OS: Scientific Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (164.54.208.62)
>
>
> I have a Linux application software with a text editor developed with QT
> and C++. Every time when openning a file by a user created by LDAP, the
> software crashes with "floating point exception". However, this doesn't
> happen to users added to the system by command 'useradd' or 'Users and
> Groups' tool of the system.
Aside from the fact that 2.3 is historic, how is it OpenLDAP's bug that an
application you wrote crashes?
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
12 years, 8 months
(ITS#6366) application GUI crashes when openning file by a user created by LDAP
by fuzq＠anl.gov
Full_Name: Albert Fu
Version: 2.3.27-8.el5_2.4.i386
OS: Scientific Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (164.54.208.62)
I have a Linux application software with a text editor developed with QT
and C++. Every time when openning a file by a user created by LDAP, the
software crashes with "floating point exception". However, this doesn't
happen to users added to the system by command 'useradd' or 'Users and
Groups' tool of the system.
Thanks,
12 years, 8 months
(ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk
Full_Name: Peter Mogensen
Version: 2.4.19
OS: Debian Lenny
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (95.166.36.16)
Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a
mirrormode setup:
* Load the database with slapadd on server-1, start server-1
The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2
Running on Debian Etch. I have no reason to suspect that it is not loaded
correctly into server1
* Start server-2 and monitor the progress of replication with slapcat, for
example:
# for ((I=1;I<=20;I++)); do slapcat > out-$I; done
* Look at the output:
# for ((I=1;I<=20;I++)); do wc -l out-$I; done
I would expect the generated files to be strictly increasing in size.
However, some times there's a file which is smaller than the previous.
In it I see LDIF entries like this:
dn:
objectClass: top
objectClass: NamedObject
objectClass: simpleSecurityObject
uid: rieke
userPassword:: e1NBU0x.....
structuralObjectClass: NamedObject
entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46
creatorsName: dc=admin,dc=example,dc=com
createTimestamp: 20070823185333Z
entryCSN: 20070823185333.000000Z#000002#000#000000
modifiersName: dc=admin,dc=example,dc=com
modifyTimestamp: 20070823185333Z
... with an empty DN line.
My config is as follows. It has been converted to LDIF and the server is running
with a cn=config database:
============================================
#gentlehup on
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel none
tool-threads 4
# Modules
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload syncprov
# Schemas
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
# Limits
disallow bind_anon
#idletimeout 120
sizelimit 2000
# TLS/Auth
TLSCACertificateFile /etc/ldap/ssl/ca.crt
TLSCertificateFile /etc/ldap/ssl/server.crt
TLSCertificateKeyFile /etc/ldap/ssl/server.nopass.key
TLSCipherSuite "NULL-SHA"
# Allow root to configure slapd via ldapi:///
TLSVerifyClient demand
authz-regexp
"gidNumber=0\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
"cn=config"
authz-regexp
"email=root(a)example.com,cn=config,ou=dev,o=example.com,st=Denmark,c=DK"
"cn=config"
##### Mirror mode ####
serverID 2
database config
limits dn.exact="cn=config"
time.soft=unlimited
time.hard=unlimited
size.soft=unlimited
size.hard=unlimited
syncrepl rid=1
provider=ldaps://server1.example.com:636/
searchbase="cn=config"
type=refreshAndPersist
retry="60 +"
scope=sub
schemachecking=on
bindmethod=sasl
binddn="cn=config"
saslmech="EXTERNAL"
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite="NULL-SHA"
syncrepl rid=2
provider=ldaps://server2.example.com:636/
searchbase="cn=config"
type=refreshAndPersist
retry="60 +"
scope=sub
schemachecking=on
bindmethod=sasl
binddn="cn=config"
saslmech="EXTERNAL"
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite="NULL-SHA"
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncprov-reloadhint TRUE
mirrormode on
=================================================
The database which I slapcat and which is being replicated has been loaded with
" ldapadd -YEXTERNAL -H ldapi:/// -f ..." from this LDIF:
dn: olcDatabase={1}hdb,cn=config
objectClass: olcHdbConfig
objectClass: olcDatabaseConfig
olcDatabase: hdb
olcSuffix: cn=data,dc=example,dc=com
olcRootDN: cn=config
olcDbDirectory: /var/lib/ldap/cn=data,dc=example,dc=com
olcDbMode: 0660
olcDbConfig: set_cachesize 2 0 0
olcDbConfig: set_lg_bsize 2097512
olcDbConfig: set_lg_dir /var/lib/ldap/cn=data,dc=example,dc=com-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbConfig: set_lk_max_objects 5000
olcDbConfig: set_lk_max_locks 5000
olcDbConfig: set_lk_max_lockers 5000
olcDbCheckpoint: 1024 10
olcDbCachefree: 16
olcDbCachesize: 100000
olcDbIDLcacheSize: 300000
olcDbLinearIndex: TRUE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: ou eq
olcDbIndex: o eq
olcDbIndex: givenName eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: member eq
olcDbIndex: reader eq
olcDbIndex: writer eq
olcDbIndex: admin eq
olcAccess:
to dn.base="cn=data,dc=example,dc=com" attrs=userPassword
by * auth
olcAccess:
to dn.base="cn=data,dc=example,dc=com"
by dn.base="cn=data,dc=example,dc=com" search
olcAccess:
to dn.children="cn=data,dc=example,dc=com"
by dn.base="cn=data,dc=example,dc=com" write
olcSyncRepl: rid=3
provider=ldaps://server1.example.com:636/
searchbase="cn=data,dc=example,dc=com"
type=refreshAndPersist
retry="60 +"
scope=sub
schemachecking=on
bindmethod=sasl
binddn="cn=config"
saslmech="EXTERNAL"
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite="NULL-SHA"
olcSyncRepl: rid=4
provider=ldaps://server2.example.com:636/
searchbase="cn=data,dc=example,dc=com"
type=refreshAndPersist
retry="60 +"
scope=sub
schemachecking=on
bindmethod=sasl
binddn="cn=config"
saslmech="EXTERNAL"
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite="NULL-SHA"
olcMirrorMode: TRUE
olcLimits: dn.base="cn=config"
size.soft=unlimited
size.hard=unlimited
time.soft=unlimited
time.hard=unlimited
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 100
olcSpReloadHint: TRUE
dn: olcOverlay=refint,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
olcOverlay: refint
olcRefintAttribute: member
12 years, 8 months
