Re: (ITS#6684) Patch for autogroup overlay
by ryans＠aweber.com
I'm not sure if this is still relevant or useful, but included below is a set of steps that will reliably reproduce the
issue and a backtrace using autogroup from HEAD and ppolicy, which as noted causes segmentation faults in the slaptools
utilities (e.g., slapcat). Note that this backtrace is from a build of 2.4.21, but the issue is present and occurs with
2.4.23 as well, as Norbert has stated.
rgs@ldapmaster3:~# ldapmodify -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la
modifying entry "cn=module{0},cn=config"
rgs@ldapmaster3:~# ldapadd -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret
dn: olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {3}ppolicy
olcPPolicyHashCleartext: FALSE
olcPPolicyForwardUpdates: FALSE
olcPPolicyUseLockout: TRUE
adding new entry "olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config"
rgs@ldapmaster3:~# cat /etc/ldap/slapd.d/cn=config/cn=module{0}.ldif
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}autogroup.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}smbk5pwd.la
olcModuleLoad: {4}ppolicy.la
structuralObjectClass: olcModuleList
creatorsName: cn=config
entryUUID: f83e3413-5ba7-4c85-9bf7-ed8728d9fbce
createTimestamp: 20091018205311Z
entryCSN: 20101129205850.805900Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20101129205850Z
rgs@ldapmaster3:~/ldap/ldifs/ppolicy# gdb --args slapcat -n1
(gdb) run
Starting program: /usr/sbin/slapcat -n1
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
1271 /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c: No such file or directory.
in /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c
(gdb) backtrace
#0 0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
#1 0x00007ffff7f6ed3a in overlay_op_walk (op=0x7fffffffd700, rs=0x7fffffffd660, which=<value optimized out>,
oi=0x7ffff83220c0, on=0x7ffff8341e50)
at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:659
#2 0x00007ffff7f6f8ab in over_op_func (op=0x7fffffffd700, rs=0xfffffffffffffff0, which=4294957760)
at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:721
#3 0x00007ffff2846141 in autogroup_db_open (be=<value optimized out>, cr=<value optimized out>) at autogroup.c:1754
#4 0x00007ffff7f6e994 in over_db_open (be=<value optimized out>, cr=0x7fffffffdfb0) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:155
#5 0x00007ffff7f1388c in backend_startup_one (be=0x7ffff8315f80, cr=0x7fffffffdfb0) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:224
#6 0x00007ffff7f13a83 in backend_startup (be=0x7ffff8315f80) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:278
#7 0x00007ffff7f742cc in slap_tool_init (progname=<value optimized out>, tool=2, argc=2, argv=0x7fffffffe5a8)
at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcommon.c:780
#8 0x00007ffff7f7335a in slapcat (argc=-9536, argv=<value optimized out>) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/slapcat.c:51
#9 0x00007ffff7ee84f5 in main (argc=2, argv=0x7fffffffe5a8) at /usr/src/openldap/openldap-2.4.21/servers/slapd/main.c:657
(gdb) x 0x7fffffffd700
0x7fffffffd700: 0xffffd870
(gdb) x 0x7fffffffd660
0x7fffffffd660: 0x00000000
For reference, line 1271, located within the ppolicy_restrict function, looks like so:
if ( op->o_conn && !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) {
-Ryan
13 years
(ITS#6728) libldap TCP/SASL problems
by quanah＠zimbra.com
Full_Name: Quanah Gibson-Mount
Version: 2.4.23
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.45.108)
As reported at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604122
Hello,
During some tests for nslcd[1], I found that if the SASL_SECPROPS in
/etc/ldap/ldap.conf is incompatible with the SASL_MECH, then the
library:
- open a useless TCP connection to the server
- check the mechanism and fail
- close the TCP connection
===== /etc/ldap/ldap.conf
BASE dc=baby-gnu,dc=org
URI ldap://192.168.122.4
SASL_MECH DIGEST-MD5
SASL_SECPROPS noactive
===== /etc/ldap/ldap.conf
===== Wireshark capture
No. Time Source Destination Protocol Info
3 2.728967 192.168.122.3 192.168.122.4 TCP 51521 > ldap [SYN] Seq=0
[...]
4 2.729699 192.168.122.4 192.168.122.3 TCP ldap > 51521 [SYN, ACK]
Seq=0 [...]
5 2.729714 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=1
[...]
6 2.739576 192.168.122.3 192.168.122.4 TCP 51521 > ldap [FIN, ACK]
Seq=1 [...]
7 2.740686 192.168.122.4 192.168.122.3 TCP ldap > 51521 [FIN, ACK]
Seq=1 [...]
8 2.740702 192.168.122.3 192.168.122.4 TCP 51521 > ldap [ACK] Seq=2
[...]
===== Wireshark capture
===== ldapsearch
ldapsearch -U dad -s base -LLL supportedSASLMechanisms
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
additional info: SASL(-4): no mechanism available: No worthy
mechs found
===== ldapsearch
As the problem is found in a software using the libldap, I conclude the
problem is in the lib and not in ldapsearc.
Regards.
13 years
Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 11/09/2010 03:50 PM, ondrej.kuznik(a)acision.com wrote:
> On 09/07/2010 03:26 PM, andrew.findlay(a)skills-1st.co.uk wrote:
>> It would certainly help to keep the apparent promises made by things
>> like the uniqueness overlay. Alternatively you could take the view
>> that the data will converge eventually and that is all that the LDAP
>> standards promise.
>
> We've hit a similar problem and decided to go this way, i.e. allowing
> the replication to bypass the uniqueness constraints.
>
> [...]
>
> I have put a preliminary version of patches that modify the unique
> overlay here
> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101109-unique_bypass_v1.tgz
>
> [...]
>
> Howard and/or others, do you consider this solution valid for this ITS?
> If yes, could you help me address the things that should be sorted out?
>
Hi,
I am resurrecting this ITS since there has been no comment on the idea
since, nor has it been explicitly rejected by anyone.
Does it seem valid to you? If so, could you spare a pointer or two to
help me resolve some of the issues with the patch I have pointed out so
that I can make it more fit for inclusion?
Regards,
Ondrej Kuznik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkzzx1gACgkQ9GWxeeH+cXuhQACcCQVydbRBhQJqhONrgeqwXLQ8
xwwAnj0NBBBY3xkazS+QfBRKB/GVGFHm
=ZYQI
-----END PGP SIGNATURE-----
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
13 years
Re: RE : (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it
olivier.chirossel(a)sfr.com wrote:
> Thanks for the report. I've reproduced the bug; it appears to be inside=20
> slapo-rwm(5). The core dump is related to a double free, which I'm=20
> trying to track.
Please test the latest commit of overlays/rwm.c (should apply fine to
2.4.23) and report. It fixes the double free.
With respect to your problem description, "lastmod off" means that the
backend will not *generate* modification-related operational attributes;
however they are proxied. Moreover, you can't strip them off with
mapping unless the remapping is part of a replication process (i.e. the
backend contains syncrepl or "updatedn" is set and the operation is
performed with that identity).
p.
13 years
RE: RE : (ITS#6720) back-ldap core dump
by olivier.chirossel＠sfr.com
Thank's for your time,
the write can't be stop, i have to reinstall all the replica , and my plann=
ing, for the second step, take 3 months ...
Regards,
Olivier
-----Message d'origine-----
De=A0: Pierangelo Masarati [mailto:masarati@aero.polimi.it]=20
Envoy=E9=A0: lundi 29 novembre 2010 15:21
=C0=A0: CHIROSSEL, Olivier
Cc=A0: openldap-its(a)openldap.org
Objet=A0: Re: RE : (ITS#6720) back-ldap core dump
olivier.chirossel(a)sfr.com wrote:
> Thank's for you reply,
>=20
> you can get a tar file containing a simple case which reproduce the probl=
em=3D
> here ( i don't put rewriting rules in proxy conf, just strip of operati=
on=3D
> nal attribut )
>=20
> wget http://olivier:its6720@84.103.237.12/its6720.tar
>=20
>=20
> the lance.sh inititialise the tests=3D20
> (the slapd suppose to be in /usr/local/libexec)
>=20
> and you reproduce it with the command :
>=20
> ldapmodify -D "cn=3D3Dmanager,dc=3D3Dneuf,dc=3D3Dfr" -H "ldap://127.0.0.1=
:489" -=3D
> w secret -f mod
>=20
> i try to explain you my need=3D20
>=20
> 1) For the moment i have a master in 2.3.x with many replica in 2.3.x wit=
h =3D
> slurpd replication
>=20
> 2) my goal is to migrate to a mirror mode master infrastructure with sync=
re=3D
> pl replication
>=20
> 3) the first step is to install my mirror mode infrastructure and replica=
te=3D
> with slurpd from my old master.
>=20
> 4) second step re install replica one by one with syncrepl replication to=
m=3D
> y new mirror mode infrastructure
>=20
> 5) third step write directly to my mirror mode infrastructure
>=20
> For the first step i put a proxy ldap between my old master and my mirror=
m=3D
> ode infrastructure to do rewrite rules and strip operationnal attribut (i=
n=3D
> eed, at the end, have a new clean infrastructure with entryCSN contains =
th=3D
> e ServerId of my new master, for checks the replcation status between my =
ma=3D
> ster and between my replica and my mirror mode architcture)
> =3D20
> The ldapmodify command reproduce the replication operations which highlig=
ht=3D
> the problem..
>=20
> PS:=3DA0before strip attribute with rwm-map directives i try to put "last=
mod =3D
> off" in proxy ldap configuration without success ...
Thanks for the report. I've reproduced the bug; it appears to be inside=20
slapo-rwm(5). The core dump is related to a double free, which I'm=20
trying to track.
In any case, since as far as I understand the only reason you need=20
slapo-rwm(5) is to modify data during the migration, you should probably=20
do it offline, after exporting your data and before importing in the new=20
system.
p.
13 years
Re: RE : (ITS#6720) back-ldap core dump
by masarati＠aero.polimi.it
olivier.chirossel(a)sfr.com wrote:
> Thank's for you reply,
>
> you can get a tar file containing a simple case which reproduce the problem=
> here ( i don't put rewriting rules in proxy conf, just strip of operation=
> nal attribut )
>
> wget http://olivier:its6720@84.103.237.12/its6720.tar
>
>
> the lance.sh inititialise the tests=20
> (the slapd suppose to be in /usr/local/libexec)
>
> and you reproduce it with the command :
>
> ldapmodify -D "cn=3Dmanager,dc=3Dneuf,dc=3Dfr" -H "ldap://127.0.0.1:489" -=
> w secret -f mod
>
> i try to explain you my need=20
>
> 1) For the moment i have a master in 2.3.x with many replica in 2.3.x with =
> slurpd replication
>
> 2) my goal is to migrate to a mirror mode master infrastructure with syncre=
> pl replication
>
> 3) the first step is to install my mirror mode infrastructure and replicate=
> with slurpd from my old master.
>
> 4) second step re install replica one by one with syncrepl replication to m=
> y new mirror mode infrastructure
>
> 5) third step write directly to my mirror mode infrastructure
>
> For the first step i put a proxy ldap between my old master and my mirror m=
> ode infrastructure to do rewrite rules and strip operationnal attribut (i n=
> eed, at the end, have a new clean infrastructure with entryCSN contains th=
> e ServerId of my new master, for checks the replcation status between my ma=
> ster and between my replica and my mirror mode architcture)
> =20
> The ldapmodify command reproduce the replication operations which highlight=
> the problem..
>
> PS:=A0before strip attribute with rwm-map directives i try to put "lastmod =
> off" in proxy ldap configuration without success ...
Thanks for the report. I've reproduced the bug; it appears to be inside
slapo-rwm(5). The core dump is related to a double free, which I'm
trying to track.
In any case, since as far as I understand the only reason you need
slapo-rwm(5) is to modify data during the migration, you should probably
do it offline, after exporting your data and before importing in the new
system.
p.
13 years
Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com
Now I got running this test: "WhoAmI failed (34)!"
See gdb output below. I could provide content of testrun/ if necessary.
$ ./run -b bdb -l 30 test047
Cleaning up test run directory leftover from previous run.
Running ./scripts/test047-ldap for bdb...
Running 1 of 30 iterations
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Using ldapadd to populate the database...
Starting slapd on TCP/IP port 9012...
Using ldapsearch to check that slapd is running...
Using ldapadd to populate the database...
Starting slapd on TCP/IP port 9013...
Using ldapsearch to check that slapd is running...
Searching base="o=Example,c=US"...
Searching base="ou=Meta,o=Example,c=US"...
Modifying database "o=Example,c=US"...
Searching base="o=Example,c=US"...
base="o=Example,c=US"...
Searching filter="(seeAlso=cn=all staff,ou=Groups,o=Example,c=US)"
attrs="seeAlso"
base="o=Example,c=US"...
Searching filter="(uid=example)"
attrs="uid"
base="o=Example,c=US"...
Searching filter="(member=cn=Another Added Group,ou=Groups,o=Example,c=US)"
attrs="member"
base="o=Example,c=US"...
Waiting 10 seconds for cached connections to timeout...
Searching with a timed out connection...
Checking server-enforced size limit...
Checking client-requested size limit...
Filtering ldapsearch results...
Filtering original ldif used to create database...
Comparing filter output...
Changing password to database "o=Example,c=US"...
Binding with newly changed password to database "o=Example,c=US"...
Binding as newly added user to database "o=Example,c=US"...
WhoAmI failed (34)!
(gdb) info threads
* 1 Thread 31230 0x00007f9e739109e5 in raise () from /lib64/libc.so.6
(gdb) thread apply all bt
Thread 1 (Thread 31230):
#0 0x00007f9e739109e5 in raise () from /lib64/libc.so.6
#1 0x00007f9e73911ee6 in abort () from /lib64/libc.so.6
#2 0x00007f9e73909235 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000475d13 in at_delete_names () at at.c:242
#4 at_destroy () at at.c:323
#5 0x000000000046fef3 in schema_destroy () at schema_init.c:6768
#6 0x000000000040ad0f in main (argc=<value optimized out>, argv=<value
optimized out>) at main.c:1037
13 years
