Hi,
I am writing a simple app to let users change their own ldap password in go, using gopkg.in/ldap.v2
binding and searching works great. But when I try to change a password as a user, 389ds just crashes.
This happens on both 389-Directory/1.3.2.16 B2014.098.2147 on Ubuntu 14.04 and 389-Directory/1.2.11.15 B2016.132.835 on CentOS 6.
The only things I can see is the error log stating:
[21/Aug/2016:12:12:44 +0000] - 389-Directory/1.3.2.16 B2014.098.2147 starting up [21/Aug/2016:12:12:44 +0000] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [21/Aug/2016:12:12:45 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [21/Aug/2016:12:12:45 +0000] - Listening on All Interfaces port 636 for LDAPS requests
Frank
Hello,
Could you share the stacktraces from the core file?
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes
Thanks, --noriko
On 08/21/2016 05:13 AM, Frank Rosquin wrote:
Hi,
I am writing a simple app to let users change their own ldap password in go, using gopkg.in/ldap.v2
binding and searching works great. But when I try to change a password as a user, 389ds just crashes.
This happens on both 389-Directory/1.3.2.16 B2014.098.2147 on Ubuntu 14.04 and 389-Directory/1.2.11.15 B2016.132.835 on CentOS 6.
The only things I can see is the error log stating:
[21/Aug/2016:12:12:44 +0000] - 389-Directory/1.3.2.16 B2014.098.2147 starting up [21/Aug/2016:12:12:44 +0000] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [21/Aug/2016:12:12:45 +0000] - slapd started. Listening on All Interfaces port 389 for LDAP requests [21/Aug/2016:12:12:45 +0000] - Listening on All Interfaces port 636 for LDAPS requests
Frank
389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
On Sun, 2016-08-21 at 22:47 +0000, Frank Rosquin wrote:
Hi,
https://gist.github.com/cnf/47f76fc895ac67eed73277b17b2ac23e
I hope this helps
https://gist.github.com/cnf/47f76fc895ac67eed73277b17b2ac23e#file-stacktrace...
This is the segfault here.
You are missing a lot of symbols, so that makes it harder. We can't see where in libslapd the crash is really happening. Is there a 389-ds-base-debug package you are missing?
I'm pretty sure we don't really support 1.3.2 anymore, 1.2.11 on EL6 is "old stable", you really want 1.3.4 or 1.3.5 from a newer ubuntu. 14.04 is looks like an LTS ubuntu, so we probably need to talk to their team about how we can update this package version.
If you can reproduce this on the CentOS machine, that would be better as that's where our teams expertise is. As well, gdb will tell you what devel packages you are missing in gdb, IE:
0x00007fa1c38ce02d in poll () at ../sysdeps/unix/syscall-template.S:84 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) Missing separate debuginfos, use: dnf debuginfo-install audit-libs-2.6.6-1.fc26.x86_64 ....
Finally, you said you are using the golang ldap api. Do you mind checking if this happens from ldappasswd or python-ldap?
ldappasswd -ZZ -H ldap://serverip -x -D "user_to_change_DN" -W -A -S
same, causes 389ds to crash.
The rest of your questions are really non-trivial for me to set up :(
On 08/22/2016 12:03 PM, Frank Rosquin wrote:
ldappasswd -ZZ -H ldap://serverip -x -D "user_to_change_DN" -W -A -S
same, causes 389ds to crash.
The rest of your questions are really non-trivial for me to set up :(
389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
Looking at your stacktraces, passwd_extop.c has the right symbols but not the others.
Could you run this command line?
rpm -qa | grep 389-ds-base
If there are some mismatches between the debuginfo and the others, we cannot get the right stacktraces.
Thanks, --noriko
it's not an RPM based distro.
root@daf470eb4d76:/# dpkg -p 389-ds-base-dbg Package: 389-ds-base-dbg Priority: extra Section: debug Installed-Size: 5146 Maintainer: Ubuntu 389ds ubuntu-389-directory-server@lists.launchpad.net Architecture: amd64 Source: 389-ds-base Version: 1.3.2.16-0ubuntu1 Depends: 389-ds-base (= 1.3.2.16-0ubuntu1) Size: 4362346 Description: 389 Directory Server suite - server debugging symbols Based on the Lightweight Directory Access Protocol (LDAP), the 389 Directory Server is designed to manage large directories of users and resources robustly and scalably. . This package provides detached debugging information for the 389 Directory Server. It is useful primarily to permit better backtraces and crash dump analysis after problems with the libraries. GDB will find this debug information automatically. Homepage: http://directory.fedoraproject.org Original-Maintainer: Debian 389ds Team pkg-fedora-ds-maintainers@lists.alioth.debian.org root@daf470eb4d76:/# dpkg -p 389-ds-base Package: 389-ds-base Priority: optional Section: net Installed-Size: 5444 Maintainer: Ubuntu 389ds ubuntu-389-directory-server@lists.launchpad.net Architecture: amd64 Version: 1.3.2.16-0ubuntu1 Replaces: dirsrv, libdirsrv-dev, libdirsrv0 Depends: 389-ds-base-libs (= 1.3.2.16-0ubuntu1), libc6 (>= 2.14), libdb5.3, libicu52 (>= 52~m1-1~), libldap-2.4-2 (>= 2.4.7), libnspr4 (>= 2:4.9-2~) | libnspr4-0d (>= 1.8.0.10), libnss3 (>= 2:3.13.4-2~) | libnss3-1d (>= 3.12.0~1.9b1), libpam0g (>= 0.99.7.1), libsasl2-2 (>= 2.1.24), libsnmp30 (>= 5.7.2~dfsg), adduser, ldap-utils, libmozilla-ldap-perl, libnetaddr-ip-perl, libsasl2-modules-gssapi-mit, libperl4-corelibs-perl | perl (<< 5.12.3-7), libsocket-getaddrinfo-perl, python Pre-Depends: debconf (>= 0.5) | debconf-2.0 Breaks: dirsrv, libdirsrv-dev, libdirsrv0 Conflicts: slapd Size: 1386648 Description: 389 Directory Server suite - server Based on the Lightweight Directory Access Protocol (LDAP), the 389 Directory Server is designed to manage large directories of users and resources robustly and scalably. . Its key features include: * four-way multi-master replication; * great scalability; * extensive documentation; * Active Directory user and group synchronization; * secure authentication and transport; * support for LDAPv3; * graphical management console; * on-line, zero downtime update of schema, configuration, and in-tree Access Control Information. Homepage: http://directory.fedoraproject.org Original-Maintainer: Debian 389ds Team pkg-fedora-ds-maintainers@lists.alioth.debian.org root@daf470eb4d76:/#
On 08/22/2016 03:03 PM, Frank Rosquin wrote:
ldappasswd -ZZ -H ldap://serverip -x -D "user_to_change_DN" -W -A -S
same, causes 389ds to crash.
The rest of your questions are really non-trivial for me to set up :(
I can not reproduce the crash on 1.3.2.
Are you using any special characters in the passwords you are using? Do you have the terminal output from when ldapasswd crash the server? The DN of the user you are changing the password for, are there any special characters in the DN?
I'm trying to figure what could be different between our tests. This is what I see:
# ldappasswd -ZZ -H ldap://localhost:389 -D "uid=mark,dc=example,dc=com" -W -S -A Old password: <password> Re-enter old password: <password> New password: <PASSWORD> Re-enter new password: <PASSWORD> Enter LDAP Password: <password>
Going back to the stacktrace you provided... As William mentioned the stack traces are missing some symbols (the important ones). Can you please get the output of:
# rpm -qa | grep 389
I want to verify the right packages are installed, and get the exact version of the 389-ds-base package you have.
Thanks, Mark
-- 389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
Hi,
Mark Reynolds told me on IRC about a bug in 389ds where changing a user pass with CLEAR password plugin disabled crashes the ds.
This is what was affecting me. I enabled CLEAR scheme again, and it stopped crashing.
FYI, thanks Mark
Frank
On 09/01/2016 01:38 PM, Frank Rosquin wrote:
Hi,
Mark Reynolds told me on IRC about a bug in 389ds where changing a user pass with CLEAR password plugin disabled crashes the ds.
This is what was affecting me. I enabled CLEAR scheme again, and it stopped crashing.
FYI, thanks Mark
No problem, and for tracking purposes here is the ticket:
https://fedorahosted.org/389/ticket/48975
Regards, Mark
Frank
389-users mailing list 389-users@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.or...
389-users@lists.fedoraproject.org