I'll try that. I have narrowed it down to the ppm.so from slapd-modules/ppm. I removed ppm.so from /usr/local/libexec/openldap, restarted slapd, ran the command that killed it prior and it didn't die, stopped slapd, recompiled ppm and installed the new ppm.so in libexec/openldap, restarted slapd and reran the password change and boom, down went Frazier!
---
Regards,
Kevin Martin
On Fri, Aug 27, 2021 at 11:30 AM Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, August 27, 2021 11:44 AM -0500 kevin martin ktmdms@gmail.com
wrote:
41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: entry uid=kmart,ou=people,dc=lecpq,dc=com", 87, MSG_NOSIGNAL, NULL, 0) = 87 41720 getpid() = 41718 41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: Reading pwdCheckModuleArg attribute", 75, MSG_NOSIGNAL, NULL, 0) = 75 41720 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8}
41718 <... futex resumed>) = ? 41720 +++ killed by SIGSEGV +++ 41719 <... epoll_wait resumed> <unfinished ...>) = ? 41719 +++ killed by SIGSEGV +++ 41718 +++ killed by SIGSEGV +++
still now coredump file. I'll try changing the kernel.core_pattern and see if we get something somewhere.
Coredumps are often useless because they lose key information. You want to get a trace under gdb while the process is executing.
Start slapd
gdb /path/to/slapd PID (gdb) cont
execute the command that crashes slapd
at the gdb prompt:
gdb thr apply all bt full
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Ok, so I've done the GDB and the "thr apply... " stuff...I find one error that says:
cracklibExt = {0x7f33fe7b03a0 "\205\003", 0x7f33b9c5c700 "K", 0x4b <error: Cannot access memory at address 0x4b>}
and then there's more stuff dumped. gdb reports alot of missing debuginfo's and I can try and find those and get them installed if that will help ultimately. what more of the dump might you want to look at, understanding of course that there might be passwords embedded in the output since this *is crashing on a password change.
---
Regards,
Kevin Martin
On Fri, Aug 27, 2021 at 12:05 PM kevin martin ktmdms@gmail.com wrote:
I'll try that. I have narrowed it down to the ppm.so from slapd-modules/ppm. I removed ppm.so from /usr/local/libexec/openldap, restarted slapd, ran the command that killed it prior and it didn't die, stopped slapd, recompiled ppm and installed the new ppm.so in libexec/openldap, restarted slapd and reran the password change and boom, down went Frazier!
Regards,
Kevin Martin
On Fri, Aug 27, 2021 at 11:30 AM Quanah Gibson-Mount quanah@symas.com wrote:
--On Friday, August 27, 2021 11:44 AM -0500 kevin martin < ktmdms@gmail.com> wrote:
41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: entry uid=kmart,ou=people,dc=lecpq,dc=com", 87, MSG_NOSIGNAL, NULL, 0) = 87 41720 getpid() = 41718 41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: Reading pwdCheckModuleArg attribute", 75, MSG_NOSIGNAL, NULL, 0) = 75 41720 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8}
41718 <... futex resumed>) = ? 41720 +++ killed by SIGSEGV +++ 41719 <... epoll_wait resumed> <unfinished ...>) = ? 41719 +++ killed by SIGSEGV +++ 41718 +++ killed by SIGSEGV +++
still now coredump file. I'll try changing the kernel.core_pattern and see if we get something somewhere.
Coredumps are often useless because they lose key information. You want to get a trace under gdb while the process is executing.
Start slapd
gdb /path/to/slapd PID (gdb) cont
execute the command that crashes slapd
at the gdb prompt:
gdb thr apply all bt full
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
--On Friday, August 27, 2021 1:20 PM -0500 kevin martin ktmdms@gmail.com wrote:
Ok, so I've done the GDB and the "thr apply... " stuff...I find one error that says:
cracklibExt = {0x7f33fe7b03a0 "\205\003", 0x7f33b9c5c700 "K", 0x4b <error: Cannot access memory at address 0x4b>}
You need to provide the entire backtrace and not try and cherry pick what you provide. If your build is missing debug information, you need to build it correctly and ensure it's not stripped at installation time.
Alternatively, if you're using an OS that Symas OpenLDAP supports, you could install our build and the related debuginfo packages.
https://repo.symas.com/soldap/
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
kevin martin wrote:
I'll try that. I have narrowed it down to the ppm.so from slapd-modules/ppm. I removed ppm.so from /usr/local/libexec/openldap, restarted slapd, ran the command that killed it prior and it didn't die, stopped slapd, recompiled ppm and installed the new ppm.so in libexec/openldap, restarted slapd and reran the password change and boom, down went Frazier!
If this module was built for and working with OpenLDAP 2.4, then it needs to be modified to work with 2.5. If you compiled it against a 2.5 source tree, without any other modifications, you should have gotten a compile error.
Regards,
Kevin Martin
On Fri, Aug 27, 2021 at 11:30 AM Quanah Gibson-Mount <quanah@symas.com mailto:quanah@symas.com> wrote:
--On Friday, August 27, 2021 11:44 AM -0500 kevin martin <ktmdms@gmail.com <mailto:ktmdms@gmail.com>> wrote: > > > 41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: entry > uid=kmart,ou=people,dc=lecpq,dc=com", 87, MSG_NOSIGNAL, NULL, 0) = 87 > 41720 getpid() = 41718 > 41720 sendto(3, "<165>Aug 27 15:36:40 slapd[41718]: ppm: Reading > pwdCheckModuleArg attribute", 75, MSG_NOSIGNAL, NULL, 0) = 75 > 41720 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} --- > 41718 <... futex resumed>) = ? > 41720 +++ killed by SIGSEGV +++ > 41719 <... epoll_wait resumed> <unfinished ...>) = ? > 41719 +++ killed by SIGSEGV +++ > 41718 +++ killed by SIGSEGV +++ > > > > > still now coredump file. I'll try changing the kernel.core_pattern and > see if we get something somewhere. Coredumps are often useless because they lose key information. You want to get a trace under gdb while the process is executing. Start slapd gdb /path/to/slapd PID (gdb) cont execute the command that crashes slapd at the gdb prompt: gdb thr apply all bt full --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
--On Friday, August 27, 2021 7:51 PM +0100 Howard Chu hyc@symas.com wrote:
kevin martin wrote:
I'll try that. I have narrowed it down to the ppm.so from slapd-modules/ppm. I removed ppm.so from /usr/local/libexec/openldap, restarted slapd, ran the command that killed it prior and it didn't die, stopped slapd, recompiled ppm and installed the new ppm.so in libexec/openldap, restarted slapd and reran the password change and boom, down went Frazier!
If this module was built for and working with OpenLDAP 2.4, then it needs to be modified to work with 2.5. If you compiled it against a 2.5 source tree, without any other modifications, you should have gotten a compile error.
It didn't exist in the contrib directory in OpenLDAP 2.4, and he specifically noted he built it out of contrib with 2.5.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org
-
Howard Chu -
kevin martin -
Quanah Gibson-Mount