openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7714) Making slapd easier to jail (enhancement?)
by blance3459＠hotmail.com 01 Oct '13

01 Oct '13

Full_Name: Barry Lance Version: 2.4.35 OS: Linux (Debian 7) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.226.37.254) Operating System: Debian 7.1.0 (Wheezy) 64-bit Openldap version: 2.4.35 Configure Options: --prefix=/usr/local --enable-shared --enable-static --enable-debug --enable-dynamic --enable-syslog --enable-local --enable-slapd --enable-spasswd --enable-modules --enable-backends=mod --disable-ndb --disable-passwd --disable-perl --disable-shell --disable-sock --disable-sql --enable-overlays=mod --with-threads --with-cyrus-sasl --with-tls=openssl config: slapd.conf from make install Jail directory: /var/chroot/openldap Files copied into jail: /etc/openldap -> <jaildir>/etc/openldap /etc/nsswitch.cond -> <jaildir>/etc /etc/pam.d -> <jaildir>/etc/pam.d /etc/passwd (or fragment of) -> <jaildir>/etc/passwd /etc/groups (or fragment of) -> <jaildir>/etc/groups /etc/shadow -> <jaildir>/etc/shadow all other libs referenced by ldd slapd into respective <jaildir>/dir /usr/local/libexec/openldap -> <jaildir>//usr/local/libexec/openldap /lib/x86_64-linux-gnu/libnss_* -> <jaildir>/lib/x86_64-linux-gnu commandline: /usr/local/libexec/slapd -d -1 -f /etc/openldap/slapd.conf -h "ldap:/// ldapi:///" -n slapd -r /var/chroot/openldap -u ldap -g ldap The behavior I have experienced is as follows: 1, Launch slapd without user (-u), group (-g), and jail dir (-r) options is successful. Slapd is running under the current user id (root). 2. Launch slapd with user and group parameters, but without a jail directory successful and the root privilege is dropped to the username given Takeaway - slapd is able to read passwd and groups outside jail. This is definitely expected. 3, Launch slapd with user, group and jail dir options, slapd fails with a message that no such user exists in passwd. 4. Launching slapd given a jail directory, but no user or group options succeeds with the daemon jailed in jail dir, butrunning as root (undesirable). Takeaway - chroot code works, but passwd/groups cannot be accessed after it (as seen in (3)). (4) is expected given the code in servers/slapd/main.c attempts to get the real uid/gid and drop root permission only if the -u and -g options are given on the command line. Comparing servers/slapd/main.c to the code for a few other daemons (ntpd, named, isc-dhcp), the jailing process follows the chdir/chroot process as expected. The difference in these other daemon is that, in all cases, the real uid/gid are retrieved before the chroot code. By doing this, nsswitch.conf, passwd, groups, etc are all still available outside the jail. Once the chroot is completed, they then drop root permission to the non privileged user given on the command line. The code in servers/slapd/main.c gets the real uid/gid AFTER the chroot. As such, the authentication infrastructure (nsswitch.conf, passwd, groups, etc) must be duplicated in the jail. In my opinion, this makes jailing slapd more difficult (inconvenient) than the other daemons mentioned. The jailing code in slapd may work, but I was unable to make it go as a non-root user. Didn't find very much useful information available via Google with respect to troubleshooting my chroot issue. To test a few theories, I added some scaffolding code in main.c and user.c to see where the process was going bad for me. As expected after looking at the source, the failure was happening in the slap_init_user function of user.c. More specifically, the call to getpwnam was returning NULL (failure) and causing the corresponding Debug statement to print the error message I am seeing when attempting to jail as a non-privileged user. No surprise there. Not being that familiar with the code in these two files, I am reluctant to modify too much for fear of introducing unintentional side effects. But in testing I found a few ways of working around the issue. Initially, I thought it might be easiest to move the call to slap_init_user before the chroot code. But then I realized that cannot work, because this function drops root permission before returning which will then cause the chroot code to fail. The first, and simplest, workaround I found was that by making an initial call to getpwnam and discarding the result before hitting the chroot code seemed to make the subsequent call in slap_init_user succeed. Wierd. I can only speculate two possibilities for that. The most reasonable is that the getpwnam call before the chroot code loads some shared library(ies) into memory that I'm missing in my jail allowing the later call after the chroot call to succeed. The second, and least reasonable, is that the man page for getpwnam states the returned pointer is to a static passwd struct which when initialized before the chroot code, is returned despite the later failure in slap_init_user. Like I said, least likely. I don't have the knowledge to test either theory and it just works despite the wasteful additional call to getpwnam. This workaround seems to have the least amount of potential side-effects elsewhere in the code. The second workaround involved moving the code blocks for the getpwnam and getgrnam calls out of slap_init_user and into main just prior to the the chroot code. I would also then have to drop the root permission just after the chroot code block based on got_uid/gid variable values. I didn't dig far enough into the code to know if there is anywhere else that the code drops root permission. If so, this may cause one of those unintentional side effects. This also worked, but seemed like bad coding practice. My third, and final, work around I think fits in the best with the spirit of the existing code. In this workaround I split up the slap_init_user code in user.c into four seperate functions: slap_init_user, slap_init_group, slap_set_user, slap_set_group. The slap_init_xxx functions use two variables added to main of type uid_t and gid_t that are passed in by reference. Each function performs the respective passwd/group calls in slap_init_user, store the result, if successful, into the byref parameter(s) and return a got_uid/gid value back as an integer return value indicating if the uid/gid parameters contain useful id's. The slapd_set_xxx functions perform the actual drop of root permission. Back in main, the slap_init_user/group functions get called prior to the chroot code and the corresponding slap_set_xxx calls are added in the relevant code block that follows the chroot call if the "got" variables indicate the uid/gid values are useful. This allows the uid/gid to be looked up prior to chroot eliminating the need for security info in the jail, root permission is still held to chroot, and the dropping of root authority sill occurs immediately after the chroot call. At the end of the day, I think the third workaround allow the chroot code for slapd to perform in the same way as the other daemons I mentioned creating a more predictable user experience. I certainly can't speak for everyone, but to me, a predictable user experience is more definitely more convenient. In the same light, I wonder if moving the creation of the pid and args files before the chroot adds value for the user when dealing with the daemon via an init script. The init script might be a bit more simple without having to worry about prepending a jail path to the pid file detected from the config when the daemon is being run as such. Not a big issue. If you think the code I used in my workarounds add value to the project, I will gladly send them along. But, honestly, it is so rudimentary that I doubt my copy offers you much value since I'm sure you could duplicate it in less than 30 minutes. Thanks, Barry Lance

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by marco.pizzoli＠gmail.com 01 Oct '13

01 Oct '13

--047d7bdc109e14c94f04e7b17008 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael, yes I was, but I'm quite sure I didn't have any memberOf-operation running in the meantime. Marco On Tue, Oct 1, 2013 at 7:36 PM, Michael Str=F6der <michael(a)stroeder.com>wro= te: > Marco Pizzoli wrote: > > Hi, this *could* be also the root cause of a problem I found some times > ago > > joking with a particular OL cluster scenario in which I failed to obtai= n > > all entries correctly populated. Please tell me if this could be relate= d. > > [..] > > All the members of the cluster were using the contrib/slapo-lastbind > > overlay. > > We're also using slapo-lastbind but deactivating does not make a differen= ce > when modifying group entries (tested today). > > Are you using slapo-memberof at all? > > Ciao, Michael. > --047d7bdc109e14c94f04e7b17008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div>Hi Michael,<br></div>yes I was, but I'm quit= e sure I didn't have any memberOf-operation running in the meantime.<br= ><br></div>Marco<br></div><div class=3D"gmail_extra"><br><br><div class=3D"= gmail_quote"> On Tue, Oct 1, 2013 at 7:36 PM, Michael Str=F6der <span dir=3D"ltr"><<a = href=3D"mailto:michael@stroeder.com" target=3D"_blank">michael(a)stroeder.com= </a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">Marco Pizzoli wrote:<br> > Hi, this *could* be also the root cause of a problem I found some time= s ago<br> > joking with a particular OL cluster scenario in which I failed to obta= in<br> > all entries correctly populated. Please tell me if this could be relat= ed.<br> </div>> [..]<br> <div class=3D"im">> All the members of the cluster were using the contri= b/slapo-lastbind<br> > overlay.<br> <br> </div>We're also using slapo-lastbind but deactivating does not make a = difference<br> when modifying group entries (tested today).<br> <br> Are you using slapo-memberof at all?<br> <br> Ciao, Michael.<br> </blockquote></div><br></div> --047d7bdc109e14c94f04e7b17008--

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 01 Oct '13

01 Oct '13

Marco Pizzoli wrote: > Hi, this *could* be also the root cause of a problem I found some times ago > joking with a particular OL cluster scenario in which I failed to obtain > all entries correctly populated. Please tell me if this could be related. > [..] > All the members of the cluster were using the contrib/slapo-lastbind > overlay. We're also using slapo-lastbind but deactivating does not make a difference when modifying group entries (tested today). Are you using slapo-memberof at all? Ciao, Michael.

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by marco.pizzoli＠gmail.com 01 Oct '13

01 Oct '13

--20cf303ea4b89c8b7504e7abe440 Content-Type: text/plain; charset=ISO-8859-1 Hi, this *could* be also the root cause of a problem I found some times ago joking with a particular OL cluster scenario in which I failed to obtain all entries correctly populated. Please tell me if this could be related. Long story short: 4-way multimaster cluster --> cluster A 3-way multimaster cluster --> cluster B one of the members of cluster A has also configured, as provider, one of the member of cluster B. By modifying data on any of the members of cluster A I should be able to see the modification also on any member of cluster B. Correct? Well, this was failing sometimes on 1 or 2 members. I had load balancer health-checks continuously polling all of members from both A and B: - bind - search - unbind All the members of the cluster were using the contrib/slapo-lastbind overlay. So the internal authTimestamp attribute populated by an internal operation. Could it be that the contextCSN of one node of the cluster were newer than the one of the providers? I'm not too expert, just trying to be of help by sharing experiences. Thanks for reading Marco --20cf303ea4b89c8b7504e7abe440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi, this *could* be also the root cause of a problem I fou= nd some times ago joking with a particular OL cluster scenario in which I f= ailed to obtain all entries correctly populated. Please tell me if this cou= ld be related.<div> <br></div><div>Long story short:</div><div>4-way multimaster cluster -->= cluster A</div><div>3-way multimaster cluster --> cluster B</div><div><= br></div><div>one of the members of cluster A has=A0also=A0configured, as p= rovider, one of the member of cluster B.</div> <div><br></div><div>By modifying data on any of the members of cluster A I = should be able to see the modification also on any member of cluster B. Cor= rect?</div><div>Well, this was failing sometimes on 1 or 2 members.<br> </div><div><br></div><div>I had load balancer health-checks continuously po= lling all of members from both A and B:</div><div>- bind</div><div>- search= </div><div>- unbind</div><div><br></div><div>All the members of the cluster= were using the contrib/slapo-lastbind overlay. So the internal authTimesta= mp attribute populated by an internal operation.</div> <div>Could it be that the contextCSN of one node of the cluster were newer = than the one of the providers?</div><div><br></div><div>I'm not too exp= ert, just trying to be of help by sharing experiences.</div><div>Thanks for= reading</div> <div>Marco</div></div> --20cf303ea4b89c8b7504e7abe440--

1 0

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by sumantk2＠linux.vnet.ibm.com 01 Oct '13

01 Oct '13

On 10/01/2013 12:46 PM, Howard Chu wrote: > sumantk2(a)linux.vnet.ibm.com wrote: >> Full_Name: sumanth k >> Version: 2.4.35 to any recent version with mdb support >> OS: Linux - ppc64 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (122.248.161.59) >> >> >> The pagesize of Linux for x86 and s390x architecture is 4096. Whereas >> in Powerpc >> <ppc64> , the pagesize is by default 65536. So when the pagesize is >> not equal to >> 4096, the segmentation fault occurs. So tried to compile the >> powerpc64 kernel >> with page size of 4096 and the problem disappears and runs smoothly. >> But by >> default the powerpc64 architecture runs with 65536 pagesize . So >> there is some >> problem in mdb_env_open2() function in mdb.c when the pagesize is not >> equal to >> 4096. > > Thanks for the report. I believe you should be able to instead change > the definition of MDB_PAGESIZE to 65536, instead of forcing your > machine to use 4096 byte pages. > Yes i have tried changing MDB_PAGESIZE to 65536 before reporting this and the segmentation fault still occured. > There are other problems though; we use an unsigned short for page > offsets. I'm not sure the assert that you tripped will succeed in this > case. > Will try changing datatype and see ..But not sure whether it affects some other part of the code. >> >> These are my observations : >> >> >> Compiled the source with -O0 optimization . >> /home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f >> /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h >> ldap://localhost:9011/ -d >> 0x4105 >> >> ./scripts/test000-rootdse: line 31: 19059 Aborted >> (core dumped) >> $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 >> >> Core file : >> bash-4.2# cat .gdbinit >> b mdb_db_open >> b mdb_env_open >> b mdb_env_open2 >> b mdb_txn_begin >> b mdb_txn_renew0 >> b mdb_dbi_open >> b mdb_cursor_init >> b mdb_cursor_set >> b mdb_page_search >> b mdb_page_get >> b mdb_page_search_root >> r -s0 -f /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h >> ldap://localhost:9011/ -d 0x4105 >> >> >> # Core was generated by >> `/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 >> -f /home/openldap-2.4.36'. >> Program terminated with signal 6, Aborted. >> #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 >> Missing separate debuginfos, use: debuginfo-install >> cyrus-sasl-lib-2.1.26-8.mcp8_0.2.ppc64 >> cyrus-sasl-md5-2.1.26-8.mcp8_0.2.ppc64 >> glibc-2.17-4.mcp8_0.6.ppc64 keyutils-libs-1.5.5-4.mcp8_0.2.ppc64 >> krb5-libs-1.11.3-1.mcp8_0.2.ppc64 libcom_err-1.42.7-2.mcp8_0.1.ppc64 >> libdb-5.3.21-8.mcp8_0.4.ppc64 libselinux-2.1.13-15.mcp8_0.3.ppc64 >> nss-softokn-freebl-3.14.3-1.mcp8_0.2.ppc64 >> openssl-libs-1.0.1e-4.mcp8_0.1.ppc64 >> pcre-8.32-7.mcp8_0.2.ppc64 zlib-1.2.7-10.mcp8_0.1.ppc64 >> (gdb) where >> #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 >> #1 0x00001fffff7afb64 in .abort () from /lib64/libc.so.6 >> #2 0x00001fffff7a455c in .__assert_fail_base () from /lib64/libc.so.6 >> #3 0x00001fffff7a464c in .__assert_fail () from /lib64/libc.so.6 >> #4 0x00000000101498cc in mdb_node_add (mc=0x3fffe89a7d40, indx=0, >> key=0x3fffe89a7d20, data=0x3fffe89a7d30, pgno=0, flags=2) at >> ./../../../libraries/liblmdb/mdb.c:6160 >> #5 0x000000001014882c in mdb_cursor_put (mc=0x3fffe89a7d40, >> key=0x3fffe89a7d20, >> data=0x3fffe89a7d30, flags=2) at ./../../../libraries/liblmdb/mdb.c:5877 >> #6 0x00000000101516a8 in mdb_dbi_open (txn=0x1000f675980, >> name=0x1027b9c8 >> "ad2i", flags=262152, dbi=0x1fffff0800a0) at >> ./../../../libraries/liblmdb/mdb.c:7902 >> #7 0x0000000010139cd4 in mdb_db_open (be=0x1000f4f83a0, >> cr=0x3fffe89a81c0) at >> init.c:207 >> #8 0x0000000010050e34 in backend_startup_one (be=0x1000f4f83a0, >> cr=0x3fffe89a81c0) at backend.c:224 >> #9 0x0000000010051588 in backend_startup (be=0x1000f4f83a0) at >> backend.c:325 >> #10 0x0000000010089a7c in slap_startup (be=0x0) at init.c:219 >> #11 0x000000001000a9c8 in main (argc=8, argv=0x3fffe89a8958) at >> main.c:991 >> >> >> >> Here is the error message : >> >> #/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f >> /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h >> ldap://localhost:9011/ -d >> 0x4105 >> (...some messages...) >> 524a2fe1 mdb_db_open: database "o=OpenLDAP Project,l=Internet": >> dbenv_open(/home/openldap-2.4.36/tests/testrun/db.1.a). >> slapd: ./../../../libraries/liblmdb/mdb.c:6160: mdb_node_add: Assertion >> `mp->mp_pb.pb.pb_upper >= mp->mp_pb.pb.pb_lower' failed. < === fails >> in assert() >> ; >> Aborted (core dumped) >> >> >> >> Some of my observation : >> >> in this file libraries/liblmdb/mdb.c >> in X86 : rc = mdb_cursor_set(&mc, &key, &data, MDB_SET, &exact); the >> value of >> rc = MD_SUCCESS, but for ppc64 it is MDB_NOTFOUND. This is due to the >> fact that >> md_root != 2 >> >> The value of md_root=2 for env->me_metas[1]->mm_dbs in X86 , but some >> huge value >> in ppc64. The value of md_pad = 4096 in x86 and 65536 in ppc64 . >> >> in x86: >> >> Breakpoint 2, mdb_txn_begin (env=0x9c5050, parent=0x0, flags=0, >> ret=0x7fffffffdf98) at ./../../../libraries/liblmdb/mdb.c:2219 >> 2219 int rc, size, tsize = sizeof(MDB_txn); >> (gdb) p env->me_metas[1]->mm_dbs >> $1 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, >> md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = >> 18446744073709551615}, {md_pad = 0, md_flags = 0, >> md_depth = 1, md_branch_pages = 0, md_leaf_pages = 1, >> md_overflow_pages = 0, >> md_entries = 4, md_root = 2}} >> (gdb) p env->me_metas[0]->mm_dbs >> $2 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, >> md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = >> 18446744073709551615}, {md_pad = 0, md_flags = 0, >> md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, >> md_overflow_pages = 0, >> md_entries = 0, md_root = 18446744073709551615}} >> >> >> in ppc64: >> >> Breakpoint 2, mdb_txn_begin (env=0x10493ef0, parent=0x0, flags=0, >> ret=0x3fffffffe590) at ./../../../libraries/liblmdb/mdb.c:2219 >> 2219 int rc, size, tsize = sizeof(MDB_txn); >> (gdb) p env->me_metas[0]->mm_dbs >> $1 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, >> md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = >> 18446744073709551615}, {md_pad = 0, md_flags = 0, >> md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, >> md_overflow_pages = 0, >> md_entries = 0, md_root = 18446744073709551615}} >> (gdb) p env->me_metas[1]->mm_dbs >> $2 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, >> md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = >> 18446744073709551615}, {md_pad = 0, md_flags = 0, >> md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, >> md_overflow_pages = 0, >> md_entries = 0, md_root = 18446744073709551615}} >> >> >> >> >> # From further investigation , the value of env->me_metas[1] is >> initialized in >> mdb_env_open2() at : >> >> p = (MDB_page *)env->me_map; >> env->me_metas[0] = METADATA(p); >> env->me_metas[1] = (MDB_meta *)((char *)env->me_metas[0] + >> meta.mm_psize); >> >> Here the meta.mm_psize in ppc64 is 65536 , hence there is some >> problem.. If the >> value of meta.mm_psize is 4096 , then everything works fine. >> >> >> As i dont have deep knowledge in openldap ,some help is needed. >> >> Thank you, >> Sumanth K >> >> > >

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 01 Oct '13

01 Oct '13

Michael Ströder wrote: > hyc(a)symas.com wrote: >>> Configuration: >>> - MMR with 3 nodes and normal syncrepl. >>> - slapo-memberof used to populate/update attribute 'memberOf' in user entries. >>> >>> If a group entry is modified and slapo-memberof updates the attribute 'memberOf' >>> in the member's entry the contextCSN value of the server where the LDAP request >>> was sent to is not updated on the other MMR replicas. >> >> I don't understand this sentence, can you rephrase? > > I looked into this a bit more: > > We have three MMR nodes, let's simply enumerate them as 1, 2 and 3. > > When modifying a group entry on 1 'memberOf' gets *locally* updated and the > contextCSN value for server 1 gets also updated. So far so good. > > Now the group modification are pulled by 2 and 3 and slapo-memberof installed > there *locally* updates attr memberOf and the *local* contextCSN value for 2 > and 3 are updated with new timestamp. But the updated contextCSN values of 2 > and 3 never get replicated to the other instances! So my monitoring check > shows a long-lasting replication gap. After next server restart all contextCSN > values get updated. > >> Also see ITS#6915. > > Sorry, glancing over ITS#6915 I don't understand what it means in this context. The point of #6915 is that internal ops are not supposed to affect the contextCSN. If you're seeing new contextCSNs on 2 and 3 solely due to slapo-memberof then some part of #6915 is still broken. We'll need a duplicate setup to reproduce this... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com 01 Oct '13

01 Oct '13

hyc(a)symas.com wrote: >> Configuration: >> - MMR with 3 nodes and normal syncrepl. >> - slapo-memberof used to populate/update attribute 'memberOf' in user entries. >> >> If a group entry is modified and slapo-memberof updates the attribute 'memberOf' >> in the member's entry the contextCSN value of the server where the LDAP request >> was sent to is not updated on the other MMR replicas. > > I don't understand this sentence, can you rephrase? I looked into this a bit more: We have three MMR nodes, let's simply enumerate them as 1, 2 and 3. When modifying a group entry on 1 'memberOf' gets *locally* updated and the contextCSN value for server 1 gets also updated. So far so good. Now the group modification are pulled by 2 and 3 and slapo-memberof installed there *locally* updates attr memberOf and the *local* contextCSN value for 2 and 3 are updated with new timestamp. But the updated contextCSN values of 2 and 3 never get replicated to the other instances! So my monitoring check shows a long-lasting replication gap. After next server restart all contextCSN values get updated. > Also see ITS#6915. Sorry, glancing over ITS#6915 I don't understand what it means in this context. Ciao, Michael.

1 0

Re: (ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by hyc＠symas.com 01 Oct '13

01 Oct '13

sumantk2(a)linux.vnet.ibm.com wrote: > Full_Name: sumanth k > Version: 2.4.35 to any recent version with mdb support > OS: Linux - ppc64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.248.161.59) > > > The pagesize of Linux for x86 and s390x architecture is 4096. Whereas in Powerpc > <ppc64> , the pagesize is by default 65536. So when the pagesize is not equal to > 4096, the segmentation fault occurs. So tried to compile the powerpc64 kernel > with page size of 4096 and the problem disappears and runs smoothly. But by > default the powerpc64 architecture runs with 65536 pagesize . So there is some > problem in mdb_env_open2() function in mdb.c when the pagesize is not equal to > 4096. Thanks for the report. I believe you should be able to instead change the definition of MDB_PAGESIZE to 65536, instead of forcing your machine to use 4096 byte pages. There are other problems though; we use an unsigned short for page offsets. I'm not sure the assert that you tripped will succeed in this case. > > These are my observations : > > > Compiled the source with -O0 optimization . > /home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f > /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d > 0x4105 > > ./scripts/test000-rootdse: line 31: 19059 Aborted (core dumped) > $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 > > Core file : > bash-4.2# cat .gdbinit > b mdb_db_open > b mdb_env_open > b mdb_env_open2 > b mdb_txn_begin > b mdb_txn_renew0 > b mdb_dbi_open > b mdb_cursor_init > b mdb_cursor_set > b mdb_page_search > b mdb_page_get > b mdb_page_search_root > r -s0 -f /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h > ldap://localhost:9011/ -d 0x4105 > > > # Core was generated by `/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 > -f /home/openldap-2.4.36'. > Program terminated with signal 6, Aborted. > #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 > Missing separate debuginfos, use: debuginfo-install > cyrus-sasl-lib-2.1.26-8.mcp8_0.2.ppc64 cyrus-sasl-md5-2.1.26-8.mcp8_0.2.ppc64 > glibc-2.17-4.mcp8_0.6.ppc64 keyutils-libs-1.5.5-4.mcp8_0.2.ppc64 > krb5-libs-1.11.3-1.mcp8_0.2.ppc64 libcom_err-1.42.7-2.mcp8_0.1.ppc64 > libdb-5.3.21-8.mcp8_0.4.ppc64 libselinux-2.1.13-15.mcp8_0.3.ppc64 > nss-softokn-freebl-3.14.3-1.mcp8_0.2.ppc64 openssl-libs-1.0.1e-4.mcp8_0.1.ppc64 > pcre-8.32-7.mcp8_0.2.ppc64 zlib-1.2.7-10.mcp8_0.1.ppc64 > (gdb) where > #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 > #1 0x00001fffff7afb64 in .abort () from /lib64/libc.so.6 > #2 0x00001fffff7a455c in .__assert_fail_base () from /lib64/libc.so.6 > #3 0x00001fffff7a464c in .__assert_fail () from /lib64/libc.so.6 > #4 0x00000000101498cc in mdb_node_add (mc=0x3fffe89a7d40, indx=0, > key=0x3fffe89a7d20, data=0x3fffe89a7d30, pgno=0, flags=2) at > ./../../../libraries/liblmdb/mdb.c:6160 > #5 0x000000001014882c in mdb_cursor_put (mc=0x3fffe89a7d40, key=0x3fffe89a7d20, > data=0x3fffe89a7d30, flags=2) at ./../../../libraries/liblmdb/mdb.c:5877 > #6 0x00000000101516a8 in mdb_dbi_open (txn=0x1000f675980, name=0x1027b9c8 > "ad2i", flags=262152, dbi=0x1fffff0800a0) at > ./../../../libraries/liblmdb/mdb.c:7902 > #7 0x0000000010139cd4 in mdb_db_open (be=0x1000f4f83a0, cr=0x3fffe89a81c0) at > init.c:207 > #8 0x0000000010050e34 in backend_startup_one (be=0x1000f4f83a0, > cr=0x3fffe89a81c0) at backend.c:224 > #9 0x0000000010051588 in backend_startup (be=0x1000f4f83a0) at backend.c:325 > #10 0x0000000010089a7c in slap_startup (be=0x0) at init.c:219 > #11 0x000000001000a9c8 in main (argc=8, argv=0x3fffe89a8958) at main.c:991 > > > > Here is the error message : > > #/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f > /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d > 0x4105 > (...some messages...) > 524a2fe1 mdb_db_open: database "o=OpenLDAP Project,l=Internet": > dbenv_open(/home/openldap-2.4.36/tests/testrun/db.1.a). > slapd: ./../../../libraries/liblmdb/mdb.c:6160: mdb_node_add: Assertion > `mp->mp_pb.pb.pb_upper >= mp->mp_pb.pb.pb_lower' failed. < === fails in assert() > ; > Aborted (core dumped) > > > > Some of my observation : > > in this file libraries/liblmdb/mdb.c > in X86 : rc = mdb_cursor_set(&mc, &key, &data, MDB_SET, &exact); the value of > rc = MD_SUCCESS, but for ppc64 it is MDB_NOTFOUND. This is due to the fact that > md_root != 2 > > The value of md_root=2 for env->me_metas[1]->mm_dbs in X86 , but some huge value > in ppc64. The value of md_pad = 4096 in x86 and 65536 in ppc64 . > > in x86: > > Breakpoint 2, mdb_txn_begin (env=0x9c5050, parent=0x0, flags=0, > ret=0x7fffffffdf98) at ./../../../libraries/liblmdb/mdb.c:2219 > 2219 int rc, size, tsize = sizeof(MDB_txn); > (gdb) p env->me_metas[1]->mm_dbs > $1 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 1, md_branch_pages = 0, md_leaf_pages = 1, md_overflow_pages = 0, > md_entries = 4, md_root = 2}} > (gdb) p env->me_metas[0]->mm_dbs > $2 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, > md_entries = 0, md_root = 18446744073709551615}} > > > in ppc64: > > Breakpoint 2, mdb_txn_begin (env=0x10493ef0, parent=0x0, flags=0, > ret=0x3fffffffe590) at ./../../../libraries/liblmdb/mdb.c:2219 > 2219 int rc, size, tsize = sizeof(MDB_txn); > (gdb) p env->me_metas[0]->mm_dbs > $1 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, > md_entries = 0, md_root = 18446744073709551615}} > (gdb) p env->me_metas[1]->mm_dbs > $2 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, > md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = > 18446744073709551615}, {md_pad = 0, md_flags = 0, > md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, > md_entries = 0, md_root = 18446744073709551615}} > > > > > # From further investigation , the value of env->me_metas[1] is initialized in > mdb_env_open2() at : > > p = (MDB_page *)env->me_map; > env->me_metas[0] = METADATA(p); > env->me_metas[1] = (MDB_meta *)((char *)env->me_metas[0] + meta.mm_psize); > > Here the meta.mm_psize in ppc64 is 65536 , hence there is some problem.. If the > value of meta.mm_psize is 4096 , then everything works fine. > > > As i dont have deep knowledge in openldap ,some help is needed. > > Thank you, > Sumanth K > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7713) Segmentation fault if the pagesize of the Operating system is not equal to 4096.
by sumantk2＠linux.vnet.ibm.com 30 Sep '13

30 Sep '13

Full_Name: sumanth k Version: 2.4.35 to any recent version with mdb support OS: Linux - ppc64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.248.161.59) The pagesize of Linux for x86 and s390x architecture is 4096. Whereas in Powerpc <ppc64> , the pagesize is by default 65536. So when the pagesize is not equal to 4096, the segmentation fault occurs. So tried to compile the powerpc64 kernel with page size of 4096 and the problem disappears and runs smoothly. But by default the powerpc64 architecture runs with 65536 pagesize . So there is some problem in mdb_env_open2() function in mdb.c when the pagesize is not equal to 4096. These are my observations : Compiled the source with -O0 optimization . /home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d 0x4105 ./scripts/test000-rootdse: line 31: 19059 Aborted (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 Core file : bash-4.2# cat .gdbinit b mdb_db_open b mdb_env_open b mdb_env_open2 b mdb_txn_begin b mdb_txn_renew0 b mdb_dbi_open b mdb_cursor_init b mdb_cursor_set b mdb_page_search b mdb_page_get b mdb_page_search_root r -s0 -f /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d 0x4105 # Core was generated by `/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f /home/openldap-2.4.36'. Program terminated with signal 6, Aborted. #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.26-8.mcp8_0.2.ppc64 cyrus-sasl-md5-2.1.26-8.mcp8_0.2.ppc64 glibc-2.17-4.mcp8_0.6.ppc64 keyutils-libs-1.5.5-4.mcp8_0.2.ppc64 krb5-libs-1.11.3-1.mcp8_0.2.ppc64 libcom_err-1.42.7-2.mcp8_0.1.ppc64 libdb-5.3.21-8.mcp8_0.4.ppc64 libselinux-2.1.13-15.mcp8_0.3.ppc64 nss-softokn-freebl-3.14.3-1.mcp8_0.2.ppc64 openssl-libs-1.0.1e-4.mcp8_0.1.ppc64 pcre-8.32-7.mcp8_0.2.ppc64 zlib-1.2.7-10.mcp8_0.1.ppc64 (gdb) where #0 0x00001fffff7adb70 in .raise () from /lib64/libc.so.6 #1 0x00001fffff7afb64 in .abort () from /lib64/libc.so.6 #2 0x00001fffff7a455c in .__assert_fail_base () from /lib64/libc.so.6 #3 0x00001fffff7a464c in .__assert_fail () from /lib64/libc.so.6 #4 0x00000000101498cc in mdb_node_add (mc=0x3fffe89a7d40, indx=0, key=0x3fffe89a7d20, data=0x3fffe89a7d30, pgno=0, flags=2) at ./../../../libraries/liblmdb/mdb.c:6160 #5 0x000000001014882c in mdb_cursor_put (mc=0x3fffe89a7d40, key=0x3fffe89a7d20, data=0x3fffe89a7d30, flags=2) at ./../../../libraries/liblmdb/mdb.c:5877 #6 0x00000000101516a8 in mdb_dbi_open (txn=0x1000f675980, name=0x1027b9c8 "ad2i", flags=262152, dbi=0x1fffff0800a0) at ./../../../libraries/liblmdb/mdb.c:7902 #7 0x0000000010139cd4 in mdb_db_open (be=0x1000f4f83a0, cr=0x3fffe89a81c0) at init.c:207 #8 0x0000000010050e34 in backend_startup_one (be=0x1000f4f83a0, cr=0x3fffe89a81c0) at backend.c:224 #9 0x0000000010051588 in backend_startup (be=0x1000f4f83a0) at backend.c:325 #10 0x0000000010089a7c in slap_startup (be=0x0) at init.c:219 #11 0x000000001000a9c8 in main (argc=8, argv=0x3fffe89a8958) at main.c:991 Here is the error message : #/home/openldap-2.4.36/tests/../servers/slapd/slapd -s0 -f /home/openldap-2.4.36/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d 0x4105 (...some messages...) 524a2fe1 mdb_db_open: database "o=OpenLDAP Project,l=Internet": dbenv_open(/home/openldap-2.4.36/tests/testrun/db.1.a). slapd: ./../../../libraries/liblmdb/mdb.c:6160: mdb_node_add: Assertion `mp->mp_pb.pb.pb_upper >= mp->mp_pb.pb.pb_lower' failed. < === fails in assert() ; Aborted (core dumped) Some of my observation : in this file libraries/liblmdb/mdb.c in X86 : rc = mdb_cursor_set(&mc, &key, &data, MDB_SET, &exact); the value of rc = MD_SUCCESS, but for ppc64 it is MDB_NOTFOUND. This is due to the fact that md_root != 2 The value of md_root=2 for env->me_metas[1]->mm_dbs in X86 , but some huge value in ppc64. The value of md_pad = 4096 in x86 and 65536 in ppc64 . in x86: Breakpoint 2, mdb_txn_begin (env=0x9c5050, parent=0x0, flags=0, ret=0x7fffffffdf98) at ./../../../libraries/liblmdb/mdb.c:2219 2219 int rc, size, tsize = sizeof(MDB_txn); (gdb) p env->me_metas[1]->mm_dbs $1 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}, {md_pad = 0, md_flags = 0, md_depth = 1, md_branch_pages = 0, md_leaf_pages = 1, md_overflow_pages = 0, md_entries = 4, md_root = 2}} (gdb) p env->me_metas[0]->mm_dbs $2 = {{md_pad = 4096, md_flags = 8, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}, {md_pad = 0, md_flags = 0, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}} in ppc64: Breakpoint 2, mdb_txn_begin (env=0x10493ef0, parent=0x0, flags=0, ret=0x3fffffffe590) at ./../../../libraries/liblmdb/mdb.c:2219 2219 int rc, size, tsize = sizeof(MDB_txn); (gdb) p env->me_metas[0]->mm_dbs $1 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}, {md_pad = 0, md_flags = 0, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}} (gdb) p env->me_metas[1]->mm_dbs $2 = {{md_pad = 65536, md_flags = 8, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}, {md_pad = 0, md_flags = 0, md_depth = 0, md_branch_pages = 0, md_leaf_pages = 0, md_overflow_pages = 0, md_entries = 0, md_root = 18446744073709551615}} # From further investigation , the value of env->me_metas[1] is initialized in mdb_env_open2() at : p = (MDB_page *)env->me_map; env->me_metas[0] = METADATA(p); env->me_metas[1] = (MDB_meta *)((char *)env->me_metas[0] + meta.mm_psize); Here the meta.mm_psize in ppc64 is 65536 , hence there is some problem.. If the value of meta.mm_psize is 4096 , then everything works fine. As i dont have deep knowledge in openldap ,some help is needed. Thank you, Sumanth K

1 0

Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by hyc＠symas.com 30 Sep '13

30 Sep '13

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.36 > OS: > URL: > Submission from: (NULL) (2001:8d8:1fe:7:d6be:d9ff:fe09:1b7c) > > > Configuration: > - MMR with 3 nodes and normal syncrepl. > - slapo-memberof used to populate/update attribute 'memberOf' in user entries. > > If a group entry is modified and slapo-memberof updates the attribute 'memberOf' > in the member's entry the contextCSN value of the server where the LDAP request > was sent to is not updated on the other MMR replicas. I don't understand this sentence, can you rephrase? Also see ITS#6915. > > All changes are correctly done though. > > After restart contextCSN values are all the same on all MMR replicas. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs