(ITS#6475) SASL OTP and syncrepl
by manu＠netbsd.org
Full_Name: Emmanuel Dreyfus
Version: any
OS: any
URL: ftp://ftp.openldap.org/incoming/ldapotp.tgz
Submission from: (NULL) (213.41.141.172)
When binding using SASL OTP to a replica, the bind works, but the
cmusaslsecretOTP attribute is modified on the replica and fail to be propagated
to the master. On the next modification, the master will overwrite the replica's
updated cmusaslsecretOTP value.
Here is a script that exhibit the behaviour:
ftp://ftp.openldap.org/incoming/ldapotp.tgz
That require SASL enabled OpenLDAP, with the OTP plugin installed. The PATH in
run.sh must probably be adjusted.
12 years, 5 months
(ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org
Full_Name: Ralf Haferkamp
Version: HEAD, RE24
OS: linux (gcc 4.5)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (89.166.207.32)
Submitted by: ralf
gcc 4.5 will do some stricter checks for buffer overflows when compiling with
-D_FORTIFY_SOURCE=2. Current HEAD aborts in test004-modify with:
*** buffer overflow detected ***:
/usr/src/packages/BUILD/openldap-2.4.21/servers/slapd/.libs/slapd terminated
======= Backtrace: =========
#0 0x00007f207dc6b9c5 in raise () from /lib64/libc.so.6
#1 0x00007f207dc6ced6 in abort () from /lib64/libc.so.6
#2 0x00007f207dca6ba9 in __libc_message () from /lib64/libc.so.6
#3 0x00007f207dd20537 in __fortify_fail () from /lib64/libc.so.6
#4 0x00007f207dd1e2e0 in __chk_fail () from /lib64/libc.so.6
#5 0x00007f207fa89769 in strcpy () at dn2id.c:679
There is no real buffer overflow here AFAICS but the real problem is, that the
destination of the strcpy() is defined as char[1] in this case (it's the nrdn
member of a struct diskNode). The additional runtime check when compiling with
-D_FORTIFY_SOURCE=2 sees that the destination data will not fit in there and
aborts.
The easiest fix here (apart from not building with -D_FORTIFY_SOURCE=2) is to
use memcpy instead of strcpy here. I'll submit that later today.
12 years, 5 months
Re: (ITS#6322) slapd suddenly stops working, and starts using 100% CPU
by helge＠monsternett.no
Hello again.
We randomly tried to switch to LDAP without SSL last Friday (we used ldaps://..:636/ before), and the server hasn't crashed since!
This is a good enough workaround for us, but I hope this information can help with fixing this bug, or help others with the same problem.
On Wed, Dec 30, 2009 at 02:08:00PM +0100, Helge Milde wrote:
>On Wed, Dec 30, 2009 at 09:04:12AM +0100, Helge Milde wrote:
>>I just enabled trace loglevel, perhaps that might give us a clue on what's going on.
>
>Slapd just stopped working again. Here's the (annotated) log for viewing and/or downloading:
>http://www.pastie.org/761198.txt
>
>Does this give you any clues?
>
>Tell me if I can do anything else to help.
>
>--
>Helge Milde, 69701808
>www.monsternett.no
--
Helge Milde, 69701808
www.monsternett.no
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
If nothing else, if this is in fact some strange 'elusive' bug, someone =
else experiencing it may find this thread useful or enlightening in some =
way (or perhaps it may help them further identify the particulars of =
this intermittent phenomenon). I too must avoid spending further time =
on this issue, as my team considers it suitably fixed; thus not =
requiring further invested resources on my part.
Thanks for your time on this issue, I must move on now.
J=
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it
> Interesting. I can't seem to imagine why this behaved the way it did =
> (looking over my config again) I am just happy that moving it fixed =
> the issue.
Well, unless you can come up with a configuration AND a test case that is
fully reproducible, I'd rather avoid spending further time on this issue.
If the problem is related to intermixing configuration statements, then it
is a bug, but it might only surface when something really odd happens
(like one module mucking with some pointer somewhere and not restoring
things as they should be). Then the only thing we can do is exactly track
what caused this.
However, in your case, you're not actually intermixing statements, but
rather sort overlays differently: all dynlist related statements exactly
follow the "overlay dynlist" statement, but different overlays are ordered
differently. This calls for unexpected interaction between overlays stack
execution that results in the odd behavior you observed. This should be a
bug as well, unless there is a good reason for having different behavior
when overlays are stacked differently (e.g. an overlay legally mucks with
data that is later handled by another). Again, unless you can present a
clearly reproducible case, it's quite hard to track, and likely impossible
if it's data dependent.
So I'm happy you solved your specific issue by rearranging the order of
the overlays.
p.
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
Interesting. I can't seem to imagine why this behaved the way it did =
(looking over my config again) I am just happy that moving it fixed =
the issue.
On Feb 14, 2010, at 00:55 , masarati(a)aero.polimi.it wrote:
>> First of all, I am paraphrasing. No one is hiding anything from you =
=3D
>> Pierre. You need only ask.=3D20
>>=20
>>> It is supposed to be a bug. It's also the reason I asked from the
>>> beginning to see the real configuration, real data and real =
operation
>>> causing the issue. If you keep hiding essential details, and only =3D=
>> provide
>>> bits of information each time, it'll take ages to just discover =
where =3D
>> the
>>> issue is.
>>=20
>>=20
>>> So now the only way to keep this ITS open is to see your ENTIRE =3D
>> slapd.conf
>>> (except passwords, of course). An even better alternative would be =
to
>>> receive a sanitized slapd.conf, a LDIF and a search operation based =
on
>>> ldapsearch that clearly illustrates the issue, like what I posted a =
=3D
>> couple
>>> of postings ago.
>>=20
>> Here, the entire sanitized config. I left out the ACL file (the =
include =3D
>> statement at the very end), but the behavior in question was =
happening =3D
>> to the rootdn user as well, meaning ACLs weren't the culprit. I also =
=3D
>> removed 14 of 15 of the syncrepl stanzas for brevity, as they were =
all =3D
>> the same aside from hostname/IP.
>>=20
>> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote =
the =3D
>> original (dysfunctional) position vs the current (functional) =
position.
>=20
> I can't see any difference in behavior with the configuration in
> <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and =
the
> ldapsearch command described in my previous posting (the only =
difference
> is that now, after "./run -b hdb test003" you need to manually create
> directory "testrun/db.2.a" for the log database, and bind as the =
rootdn to
> perform the search). I tried both HEAD and current re24 code, which
> should not differ much from 2.4.21. The only modifications to
> configuration are related to: statically built backends/overlays, no =
ACLs,
> no TLS. Also, valgrind does not show anything strange (like dangling
> pointers or so) which could be symptoms of doing nasty things with =
memory
> that make my setup work "by chance".
>=20
> p.
>=20
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it
> First of all, I am paraphrasing. No one is hiding anything from you =
> Pierre. You need only ask.=20
>
>> It is supposed to be a bug. It's also the reason I asked from the
>> beginning to see the real configuration, real data and real operation
>> causing the issue. If you keep hiding essential details, and only =
> provide
>> bits of information each time, it'll take ages to just discover where =
> the
>> issue is.
>
>
>> So now the only way to keep this ITS open is to see your ENTIRE =
> slapd.conf
>> (except passwords, of course). An even better alternative would be to
>> receive a sanitized slapd.conf, a LDIF and a search operation based on
>> ldapsearch that clearly illustrates the issue, like what I posted a =
> couple
>> of postings ago.
>
> Here, the entire sanitized config. I left out the ACL file (the include =
> statement at the very end), but the behavior in question was happening =
> to the rootdn user as well, meaning ACLs weren't the culprit. I also =
> removed 14 of 15 of the syncrepl stanzas for brevity, as they were all =
> the same aside from hostname/IP.
>
> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the =
> original (dysfunctional) position vs the current (functional) position.
I can't see any difference in behavior with the configuration in
<ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and the
ldapsearch command described in my previous posting (the only difference
is that now, after "./run -b hdb test003" you need to manually create
directory "testrun/db.2.a" for the log database, and bind as the rootdn to
perform the search). I tried both HEAD and current re24 code, which
should not differ much from 2.4.21. The only modifications to
configuration are related to: statically built backends/overlays, no ACLs,
no TLS. Also, valgrind does not show anything strange (like dangling
pointers or so) which could be symptoms of doing nasty things with memory
that make my setup work "by chance".
p.
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
First of all, I am paraphrasing. No one is hiding anything from you =
Pierre. You need only ask.=20
> It is supposed to be a bug. It's also the reason I asked from the
> beginning to see the real configuration, real data and real operation
> causing the issue. If you keep hiding essential details, and only =
provide
> bits of information each time, it'll take ages to just discover where =
the
> issue is.
> So now the only way to keep this ITS open is to see your ENTIRE =
slapd.conf
> (except passwords, of course). An even better alternative would be to
> receive a sanitized slapd.conf, a LDIF and a search operation based on
> ldapsearch that clearly illustrates the issue, like what I posted a =
couple
> of postings ago.
Here, the entire sanitized config. I left out the ACL file (the include =
statement at the very end), but the behavior in question was happening =
to the rootdn user as well, meaning ACLs weren't the culprit. I also =
removed 14 of 15 of the syncrepl stanzas for brevity, as they were all =
the same aside from hostname/IP.
NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the =
original (dysfunctional) position vs the current (functional) position.
######
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/sudo.schema
include /etc/ldap/schema/dhcp.schema
include /etc/ldap/schema/samba.schema
include /usr/share/doc/libpam-ldap/ldapns.schema
include /etc/ldap/schema/hdb.schema
include /etc/ldap/schema/uber.schema
include /etc/ldap/schema/nisdomainobject.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
tool-threads 4
loglevel stats stats2 sync
## Modules/Overlays
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload back_monitor.la
moduleload syncprov
moduleload accesslog
moduleload dynlist.la
serverID 100 ldap://10.94.100.100:3890/
TLSCertificateFile /etc/ldap/ssl/wildcard.example.com.crt
TLSCertificateKeyFile /etc/ldap/ssl/wildcard.example.com.key
TLSCACertificateFile /etc/ssl/certs/ca-example.cert
TLSVerifyClient never
## Limits, Mandates & Allowances
disallow bind_anon
sizelimit unlimited
timelimit unlimited
security tls=3D0
access to dn.subtree=3D"cn=3DSubschema"
by users read
access to dn.base=3D""
by users read
defaultSearchBase dc=3Dexample,dc=3Dcom
sasl-realm EXAMPLE.COM
sasl-host ds.example.com
authz-regexp "uid=3D\(.*\),cn=3DEXAMPLE.COM,cn=3Dgssapi,cn=3Dauth"
"uid=3D$1,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom"
backend hdb
########### Monitoring Database - For slapd/hdb performance data
database monitor
rootdn uid=3Dmonitor,cn=3Dmonitor
rootpw {SSHA}....
access to dn.subtree=3D"cn=3Dmonitor"
by =
group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro=
ups,dc=3Dexample,dc=3Dcom" read
########### Example Log
database hdb
suffix cn=3Dexamplelog
rootdn "uid=3Dlog,cn=3Dexamplelog"
rootpw {SSHA}....
directory /var/lib/ldap/examplelog
index reqStart,objectClass,entryCSN,reqResult eq
dbconfig set_cachesize 0 4097152 0
dbconfig set_lg_regionmax 1048576
dbconfig set_lg_max 1048576
dbconfig set_lg_dir /var/lib/ldap/examplelog
dbconfig set_tmp_dir /tmp
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
access to dn.subtree=3D"cn=3Dexamplelog"
by =
group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro=
ups,dc=3Dexample,dc=3Dcom" read
########### Example.Com
database hdb
idlcachesize 4000
suffix "dc=3Dexample,dc=3Dcom"
checksum
checkpoint 10 1
cachefree 20
rootdn "uid=3Drootdn,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=
=3Dcom"
rootpw {SSHA}....
monitoring on
lastmod on
directory "/var/lib/ldap/example"
dncachesize 1000
dbconfig set_cachesize 1 0 2
dbconfig set_lg_max 10485760
dbconfig set_lg_regionmax 40485760
dbconfig set_flags db_log_autoremove
dbconfig set_lg_bsize 20971520
dbconfig set_lk_max_objects 5500
dbconfig set_lk_max_locks 5500
dbconfig set_lk_max_lockers 5500
index objectClass eq =20
index entryCSN,entryUUID eq =20
index cn,uid,memberUid eq
index uidNumber,gidNumber eq
###############
### WORKS HERE
overlay dynlist
dynlist-attrset groupOfURLs memberURL memberUid
dynlist-attrset posixGroup memberURL memberUid:uid
## There were 15 of these, removed 14 for brevity.
syncrepl rid=3D001
provider=3Dldap://10.94.100.100:3890/
starttls=3Dyes
bindmethod=3Dsimple
binddn=3D"uid=3Dsyncrepl,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom"
credentials=3Dpassword
scope=3Dsub
filter=3D"(objectClass=3D*)"
schemachecking=3Doff
searchbase=3D"dc=3Dexample,dc=3Dcom"
attrs=3D"*,+"
retry=3D"12 +"
sizelimit=3Dunlimited
timeout=3D20
type=3DrefreshAndPersist
mirrormode true
overlay syncprov
syncprov-sessionlog 10
syncprov-checkpoint 1 5
overlay accesslog
logdb cn=3Dexamplelog
logops writes
logold (objectclass=3D*)
logpurge 7+00:00 2+00:00
logsuccess TRUE
##################
### IS BROKEN HERE
overlay dynlist
dynlist-attrset groupOfURLs memberURL memberUid
dynlist-attrset posixGroup memberURL memberUid:uid
include /etc/ldap/acls
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it
> Actually, maybe I wasn't totally wrong. There MAY be a bug at work, =
> just not the one I initially thought ....
>
> 1.) Implemented your exact working example on my dev server. Worked.
> 2.) Implemented same example on my QA server. Worked.
> 3.) Implemented on a production server. Failed.
>
> I then realized the dynlist-attrset was listed as follows:
>
> syncrepl params
> accesslog params
> dynlist-attrset params
>
> I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl =
> lines (below my indexes for this DB).
>
> Example then worked in production.
>
> Is THAT a bug? That its behavior changes depending on where it is placed =
> inside of a given 'database' section?
>
> Thanks, sorry to keep bugging you with this ....
GUESSING what you meant above is something like this (as you keep writing
things like "accesslog parameters" instead of the real thing)
<slapd.conf excerpt>
database bdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
#null#bind on
directory testrun/db.1.a
index objectClass eq
index cn,sn,uid pres,eq,sub
overlay dynlist
dynlist-attrset groupOfURLs memberURL memberUid
overlay syncprov
overlay accesslog
logdb cn=log
logops writes reads
logold (objectclass=person)
dynlist-attrset posixGroup memberURL memberUid:uid
</slapd.conf excerpt>
or any permutation of the dynlist-attrset statement, like both before
overlay syncprov, or both at the end, or anywhere between "overlay
syncrepl" and the last "log*" statement, I get the expected result.
So now the only way to keep this ITS open is to see your ENTIRE slapd.conf
(except passwords, of course). An even better alternative would be to
receive a sanitized slapd.conf, a LDIF and a search operation based on
ldapsearch that clearly illustrates the issue, like what I posted a couple
of postings ago.
p.
12 years, 5 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it
> Actually, maybe I wasn't totally wrong. There MAY be a bug at work, =
> just not the one I initially thought ....
>
> 1.) Implemented your exact working example on my dev server. Worked.
> 2.) Implemented same example on my QA server. Worked.
> 3.) Implemented on a production server. Failed.
>
> I then realized the dynlist-attrset was listed as follows:
>
> syncrepl params
> accesslog params
> dynlist-attrset params
>
> I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl =
> lines (below my indexes for this DB).
>
> Example then worked in production.
>
> Is THAT a bug? That its behavior changes depending on where it is placed =
> inside of a given 'database' section?
It is supposed to be a bug. It's also the reason I asked from the
beginning to see the real configuration, real data and real operation
causing the issue. If you keep hiding essential details, and only provide
bits of information each time, it'll take ages to just discover where the
issue is.
p.
12 years, 5 months
