Hi,
sssd shows the following error when a user tries to log on using password. enumerate is false. Using 1.5.1.70 Any idea why this is happening?
Thanks (Mon Aug 11 19:47:39 2014) [sssd] [mt_svc_exit_handler] (2): Child [LDAP] terminated with signal [11] (Mon Aug 11 19:47:39 2014) [sssd] [sbus_dispatch] (3): Connection is not open for dispatching. (Mon Aug 11 19:47:39 2014) [sssd] [mt_svc_restart] (6): Scheduling service LDAP for restart 1 (Mon Aug 11 19:47:39 2014) [sssd] [start_service] (4): Queueing service LDAP for startup (Mon Aug 11 19:47:39 2014) [sssd] [sbus_server_init_new_connection] (5): Entering. (Mon Aug 11 19:47:39 2014) [sssd] [sbus_server_init_new_connection] (5): Adding connection 0x129cea40. (Mon Aug 11 19:47:39 2014) [sssd] [sbus_init_connection] (5): Adding connection 129CEA40 (Mon Aug 11 19:47:39 2014) [sssd] [sbus_server_init_new_connection] (5): Got a connection (Mon Aug 11 19:47:39 2014) [sssd] [monitor_service_init] (3): Initializing D-BUS Service (Mon Aug 11 19:47:39 2014) [sssd] [client_registration] (4): Received ID registration: (%BE_LDAP,1) (Mon Aug 11 19:47:39 2014) [sssd] [mark_service_as_started] (5): Marking LDAP as started.
On (11/08/14 11:08), Daniel Jung wrote:
Hi,
sssd shows the following error when a user tries to log on using password. enumerate is false. Using 1.5.1.70 Any idea why this is happening?
Thanks (Mon Aug 11 19:47:39 2014) [sssd] [mt_svc_exit_handler] (2): Child [LDAP] terminated with signal [11]
^^^^^^ It is a SIGSEGV.
If you want you can try to uses newe version of sssd on CentOS 5 https://copr.fedoraproject.org/coprs/sgallagh/sssd-1.9-rhel5/
LS
Yeah i noticed that, any other options other than upgrading to 1.9? 1.5.1.70 is the latest avail for cento5. By the way, also having issues with 1.5.1.58, when trying to login with passwd. Is 1.5.1 release too buggy to be used in production?
Mon Aug 11 20:57:29 2014) [sssd] [sbus_dispatch] (3): Connection is not open for dispatching. (Mon Aug 11 20:57:30 2014) [sssd] [global_checks_handler] (1): Service [LDAP] did exit (Mon Aug 11 20:57:30 2014) [sssd] [start_service] (4): Queueing service LDAP for startup (Mon Aug 11 20:57:30 2014) [sssd] [sbus_server_init_new_connection] (5): Entering. (Mon Aug 11 20:57:30 2014) [sssd] [sbus_server_init_new_connection] (5): Adding connection 0xd9733e0. (Mon Aug 11 20:57:30 2014) [sssd] [sbus_init_connection] (5): Adding connection D9733E0 (Mon Aug 11 20:57:30 2014) [sssd] [sbus_add_watch] (8): 0xd96ab40/0xd971ac0 (14), -/W (disabled) (Mon Aug 11 20:57:30 2014) [sssd] [sbus_toggle_watch] (8): 0xd96ab40/0xd9723c0 (14), R/- (enabled) (Mon Aug 11 20:57:30 2014) [sssd] [sbus_server_init_new_connection] (5): Got a connection (Mon Aug 11 20:57:30 2014) [sssd] [monitor_service_init] (3): Initializing D-BUS Service (Mon Aug 11 20:57:30 2014) [sssd] [sbus_dispatch] (9): dbus conn: D9733E0 (Mon Aug 11 20:57:30 2014) [sssd] [sbus_toggle_watch] (8): 0xd96ab40/0xd9723c0 (14), R/- (disabled) (Mon Aug 11 20:57:30 2014) [sssd] [sbus_toggle_watch] (8): 0xd96ab40/0xd971ac0 (14), -/W (enabled) (Mon Aug 11 20:57:30 2014) [sssd] [sbus_toggle_watch] (8): 0xd96ab40/0xd9723c0 (14), R/- (enabled) (Mon Aug 11 20:57:30 2014) [sssd] [sbus_toggle_watch] (8): 0xd96ab40/0xd971ac0 (14), -/W (disabled) (Mon Aug 11 20:57:30 2014) [sssd] [sbus_dispatch] (9): dbus conn: D9733E0 (Mon Aug 11 20:57:30 2014) [sssd] [sbus_dispatch] (9): Dispatching.
On Mon, Aug 11, 2014 at 11:16 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (11/08/14 11:08), Daniel Jung wrote:
Hi,
sssd shows the following error when a user tries to log on using password. enumerate is false. Using 1.5.1.70 Any idea why this is happening?
Thanks (Mon Aug 11 19:47:39 2014) [sssd] [mt_svc_exit_handler] (2): Child [LDAP] terminated with signal [11]
^^^^^^ It is a SIGSEGV.
If you want you can try to uses newe version of sssd on CentOS 5 https://copr.fedoraproject.org/coprs/sgallagh/sssd-1.9-rhel5/
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, Aug 11, 2014 at 12:01:28PM -0700, Daniel Jung wrote:
Yeah i noticed that, any other options other than upgrading to 1.9? 1.5.1.70 is the latest avail for cento5. By the way, also having issues with 1.5.1.58, when trying to login with passwd. Is 1.5.1 release too buggy to be used in production?
It's used in production, but we haven't heard about the issue you encountered yet. I'm sorry you're having trouble with SSSD.
Given you're running centos and not RHEL and hence you don't have to worry about breaking a support contract, I agree with Lukas that using the 1.9 branch would be the best move. Please report any problems you have with 1.9 here.
hi just tried out 1.9 by manually installing on a kvm. Seems like i still run into same issue.
lsb_release -r Release: 5.10 sssd --version 1.9.6
/var/log/messages Aug 11 23:46:34 kernel: sssd_be[3300]: segfault at 0000000000000010 rip 000000376a430748 rsp 00007fff1d8acdf0 error 4
sssd.log (Mon Aug 11 23:46:34 2014) [sssd] [sbus_dispatch] (0x0080): Connection is not open for dispatching. (Mon Aug 11 23:46:34 2014) [sssd] [mt_svc_exit_handler] (0x0040): Child [LDAP] terminated with signal [11] (Mon Aug 11 23:46:34 2014) [sssd] [mt_svc_restart] (0x0400): Scheduling service LDAP for restart 1 (Mon Aug 11 23:46:34 2014) [sssd] [get_ping_config] (0x0100): Time between service pings for [LDAP]: [10] (Mon Aug 11 23:46:34 2014) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [LDAP]: [60] (Mon Aug 11 23:46:34 2014) [sssd] [start_service] (0x0100): Queueing service LDAP for startup
sssd_LDAP.log Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x1000): Backend [ldap] already loaded. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No selinux module provided for [LDAP] !! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x0200): no module name found in confdb, using [ldap]. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x1000): Backend [ldap] already loaded. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No host info module provided for [LDAP] !! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x0200): no module name found in confdb, using [ldap]. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x1000): Backend [ldap] already loaded. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): Subdomains are not supported for [LDAP] !! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [main] (0x0400): Backend provider (LDAP) started! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Entering. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x69192a0. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_init_connection] (0x0200): Adding connection 69192A0 (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Got a connection (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x6919dc0] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Entering. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x691a330. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_init_connection] (0x0200): Adding connection 691A330 (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Got a connection (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x691ab50] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Cancel DP ID timeout [0x691ab50] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Added Frontend client [PAM] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Cancel DP ID timeout [0x6919dc0] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Added Frontend client [NSS] (Mon Aug 11 23:46:44 2014) [sssd[be[LDAP]]] [cleanup_groups] (0x0100): Found 2 expired group entries! (Mon Aug 11 23:46:44 2014) [sssd[be[LDAP]]] [ldap_id_cleanup_set_timer] (0x0400): Scheduling next cleanup at 1407804404.252979
On Mon, Aug 11, 2014 at 12:38 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Aug 11, 2014 at 12:01:28PM -0700, Daniel Jung wrote:
Yeah i noticed that, any other options other than upgrading to 1.9? 1.5.1.70 is the latest avail for cento5. By the way, also having issues with 1.5.1.58, when trying to login with passwd. Is 1.5.1 release too buggy to be used in production?
It's used in production, but we haven't heard about the issue you encountered yet. I'm sorry you're having trouble with SSSD.
Given you're running centos and not RHEL and hence you don't have to worry about breaking a support contract, I agree with Lukas that using the 1.9 branch would be the best move. Please report any problems you have with 1.9 here. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Dont see much in the core either.
Core was generated by `/usr/libexec/sssd/sssd_be -d 0 --domain LDAP'. Program terminated with signal 11, Segmentation fault. #0 0x0000003502030748 in ?? () (gdb) bt #0 0x0000003502030748 in ?? () #1 0x00000000ffffe4a0 in ?? () #2 0x0000000000676f20 in ?? () #3 0x00007fffffffe580 in ?? () #4 0x00007fffffffe4f0 in ?? () #5 0x00007fffffffe618 in ?? () #6 0x0000000000000007 in ?? () #7 0x0000000000063358 in ?? () #8 0x0000000c000000d0 in ?? () #9 0x0000000000000000 in ?? ()
On Mon, Aug 11, 2014 at 2:53 PM, Daniel Jung mimianddaniel@gmail.com wrote:
hi just tried out 1.9 by manually installing on a kvm. Seems like i still run into same issue.
lsb_release -r Release: 5.10 sssd --version 1.9.6
/var/log/messages Aug 11 23:46:34 kernel: sssd_be[3300]: segfault at 0000000000000010 rip 000000376a430748 rsp 00007fff1d8acdf0 error 4
sssd.log (Mon Aug 11 23:46:34 2014) [sssd] [sbus_dispatch] (0x0080): Connection is not open for dispatching. (Mon Aug 11 23:46:34 2014) [sssd] [mt_svc_exit_handler] (0x0040): Child [LDAP] terminated with signal [11] (Mon Aug 11 23:46:34 2014) [sssd] [mt_svc_restart] (0x0400): Scheduling service LDAP for restart 1 (Mon Aug 11 23:46:34 2014) [sssd] [get_ping_config] (0x0100): Time between service pings for [LDAP]: [10] (Mon Aug 11 23:46:34 2014) [sssd] [get_ping_config] (0x0100): Time between SIGTERM and SIGKILL for [LDAP]: [60] (Mon Aug 11 23:46:34 2014) [sssd] [start_service] (0x0100): Queueing service LDAP for startup
sssd_LDAP.log Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x1000): Backend [ldap] already loaded. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No selinux module provided for [LDAP] !! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x0200): no module name found in confdb, using [ldap]. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x1000): Backend [ldap] already loaded. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): No host info module provided for [LDAP] !! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x0200): no module name found in confdb, using [ldap]. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [load_backend_module] (0x1000): Backend [ldap] already loaded. (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [be_process_init] (0x0020): Subdomains are not supported for [LDAP] !! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [main] (0x0400): Backend provider (LDAP) started! (Mon Aug 11 23:46:34 2014) [sssd[be[LDAP]]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Entering. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x69192a0. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_init_connection] (0x0200): Adding connection 69192A0 (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Got a connection (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x6919dc0] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Entering. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Adding connection 0x691a330. (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_init_connection] (0x0200): Adding connection 691A330 (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [sbus_server_init_new_connection] (0x0200): Got a connection (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [be_client_init] (0x0100): Set-up Backend ID timeout [0x691ab50] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Cancel DP ID timeout [0x691ab50] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Added Frontend client [PAM] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Cancel DP ID timeout [0x6919dc0] (Mon Aug 11 23:46:35 2014) [sssd[be[LDAP]]] [client_registration] (0x0100): Added Frontend client [NSS] (Mon Aug 11 23:46:44 2014) [sssd[be[LDAP]]] [cleanup_groups] (0x0100): Found 2 expired group entries! (Mon Aug 11 23:46:44 2014) [sssd[be[LDAP]]] [ldap_id_cleanup_set_timer] (0x0400): Scheduling next cleanup at 1407804404.252979
On Mon, Aug 11, 2014 at 12:38 PM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Aug 11, 2014 at 12:01:28PM -0700, Daniel Jung wrote:
Yeah i noticed that, any other options other than upgrading to 1.9? 1.5.1.70 is the latest avail for cento5. By the way, also having issues with 1.5.1.58, when trying to login with passwd. Is 1.5.1 release too buggy to be used in production?
It's used in production, but we haven't heard about the issue you encountered yet. I'm sorry you're having trouble with SSSD.
Given you're running centos and not RHEL and hence you don't have to worry about breaking a support contract, I agree with Lukas that using the 1.9 branch would be the best move. Please report any problems you have with 1.9 here. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, Aug 11, 2014 at 05:12:26PM -0700, Daniel Jung wrote:
Dont see much in the core either.
Core was generated by `/usr/libexec/sssd/sssd_be -d 0 --domain LDAP'. Program terminated with signal 11, Segmentation fault. #0 0x0000003502030748 in ?? () (gdb) bt #0 0x0000003502030748 in ?? () #1 0x00000000ffffe4a0 in ?? () #2 0x0000000000676f20 in ?? () #3 0x00007fffffffe580 in ?? () #4 0x00007fffffffe4f0 in ?? () #5 0x00007fffffffe618 in ?? () #6 0x0000000000000007 in ?? () #7 0x0000000000063358 in ?? () #8 0x0000000c000000d0 in ?? () #9 0x0000000000000000 in ?? ()
Looks like you're missing the debuginfo packages. Can you run:
sudo rpm -ivh http://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epel-...
or just: sudo debuginfo-install sssd
the latter is going to bring in more *-debuginfo packages but also ensure debuginfo symbols for dependencies are available.
No issue with running getent or ldapsearch to query ldap servers
here are the info from the core bt #0 0x00002abcafe5b748 in ldap_int_tls_start () from /usr/lib64/libldap-2.4.so.2 #1 0x00002abcb46b53fc in sdap_connect_done (op=<value optimized out>, reply=<value optimized out>, error=0, pvt=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:395 #2 0x00002abcb4686ded in sdap_process_message (ev=<value optimized out>, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:366 #3 sdap_process_result (ev=<value optimized out>, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:209 #4 0x0000003501c08c26 in ?? () from /usr/lib64/libtevent.so.0 #5 0x0000003501c06e96 in ?? () from /usr/lib64/libtevent.so.0 #6 0x0000003501c0346d in _tevent_loop_once () from /usr/lib64/libtevent.so.0 #7 0x0000003501c034db in tevent_common_loop_wait () from /usr/lib64/libtevent.so.0 #8 0x0000003501c06e06 in ?? () from /usr/lib64/libtevent.so.0 #9 0x0000000000465d83 in server_loop (main_ctx=0xd13be00) at src/util/server.c:601 #10 0x0000000000419f1b in main (argc=<value optimized out>, argv=0x7ffff4995518) at src/providers/data_provider_be.c:2755
(gdb) list 2670 return EOK; 2671 2672 fail: 2673 talloc_free(ctx); 2674 return ret; 2675 } 2676 2677 #ifndef UNIT_TESTING 2678 int main(int argc, const char *argv[]) 2679 {
frame 1 gdb) list 390 tevent_req_done(req); 391 return; 392 } 393 394 /* FIXME: take care that ldap_install_tls might block */ 395 ret = ldap_install_tls(state->sh->ldap); 396 if (ret != LDAP_SUCCESS) { 397 398 optret = sss_ldap_get_diagnostic_msg(state, state->sh->ldap, 399 &tlserr);
rpm -qi openldap24-2.4.19-15.el5.2 | head Name : openldap24 Relocations: (not relocatable) Version : 2.4.19 Vendor: (none) Release : 15.el5.2 Build Date: Tue 29 Oct 2013 11:31:42 PM CET
I found https://lists.fedorahosted.org/pipermail/sssd-devel/2011-July/006625.html which seems to be similar to the problem i am having?
Sadly, for co5, thats the latest avail, I will build latest and see if that fixes the problem with it.
Cheers
On Tue, Aug 12, 2014 at 12:04 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Aug 11, 2014 at 05:12:26PM -0700, Daniel Jung wrote:
Dont see much in the core either.
Core was generated by `/usr/libexec/sssd/sssd_be -d 0 --domain LDAP'. Program terminated with signal 11, Segmentation fault. #0 0x0000003502030748 in ?? () (gdb) bt #0 0x0000003502030748 in ?? () #1 0x00000000ffffe4a0 in ?? () #2 0x0000000000676f20 in ?? () #3 0x00007fffffffe580 in ?? () #4 0x00007fffffffe4f0 in ?? () #5 0x00007fffffffe618 in ?? () #6 0x0000000000000007 in ?? () #7 0x0000000000063358 in ?? () #8 0x0000000c000000d0 in ?? () #9 0x0000000000000000 in ?? ()
Looks like you're missing the debuginfo packages. Can you run:
sudo rpm -ivh
http://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epel-...
or just: sudo debuginfo-install sssd
the latter is going to bring in more *-debuginfo packages but also ensure debuginfo symbols for dependencies are available. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Installed openldap 2.4.23 manually; There are quite a few packages depending on the libldap and liblber which i had to force to reinstall. It doesnt sigsegv now but i am getting Wed Aug 13 03:09:37:761645 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 13 03:09:37:761687 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
And my ldapsearch -ZZ -x doesnt work anymore. Obviously this is bad libldap?
So using 1.5.1, my ldapsearch -ZZ works fine but sssd_be sigsegv when trying to use pam with password. And using 1.9.6 with openldap-2.4 lib, sssd with pam + password doesnt work plus and it doesnt work with ldapsearch ( this probably has to do with compat+ldap ?)
Anyone out there using sssd in centos 5 with PAM + password auth?
On Tue, Aug 12, 2014 at 12:51 PM, Daniel Jung mimianddaniel@gmail.com wrote:
No issue with running getent or ldapsearch to query ldap servers
here are the info from the core bt #0 0x00002abcafe5b748 in ldap_int_tls_start () from /usr/lib64/libldap-2.4.so.2 #1 0x00002abcb46b53fc in sdap_connect_done (op=<value optimized out>, reply=<value optimized out>, error=0, pvt=<value optimized out>) at src/providers/ldap/sdap_async_connection.c:395 #2 0x00002abcb4686ded in sdap_process_message (ev=<value optimized out>, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:366 #3 sdap_process_result (ev=<value optimized out>, pvt=<value optimized out>) at src/providers/ldap/sdap_async.c:209 #4 0x0000003501c08c26 in ?? () from /usr/lib64/libtevent.so.0 #5 0x0000003501c06e96 in ?? () from /usr/lib64/libtevent.so.0 #6 0x0000003501c0346d in _tevent_loop_once () from /usr/lib64/libtevent.so.0 #7 0x0000003501c034db in tevent_common_loop_wait () from /usr/lib64/libtevent.so.0 #8 0x0000003501c06e06 in ?? () from /usr/lib64/libtevent.so.0 #9 0x0000000000465d83 in server_loop (main_ctx=0xd13be00) at src/util/server.c:601 #10 0x0000000000419f1b in main (argc=<value optimized out>, argv=0x7ffff4995518) at src/providers/data_provider_be.c:2755
(gdb) list 2670 return EOK; 2671 2672 fail: 2673 talloc_free(ctx); 2674 return ret; 2675 } 2676 2677 #ifndef UNIT_TESTING 2678 int main(int argc, const char *argv[]) 2679 {
frame 1 gdb) list 390 tevent_req_done(req); 391 return; 392 } 393 394 /* FIXME: take care that ldap_install_tls might block */ 395 ret = ldap_install_tls(state->sh->ldap); 396 if (ret != LDAP_SUCCESS) { 397 398 optret = sss_ldap_get_diagnostic_msg(state, state->sh->ldap, 399 &tlserr);
rpm -qi openldap24-2.4.19-15.el5.2 | head Name : openldap24 Relocations: (not relocatable) Version : 2.4.19 Vendor: (none) Release : 15.el5.2 Build Date: Tue 29 Oct 2013 11:31:42 PM CET
I found https://lists.fedorahosted.org/pipermail/sssd-devel/2011-July/006625.html which seems to be similar to the problem i am having?
Sadly, for co5, thats the latest avail, I will build latest and see if that fixes the problem with it.
Cheers
On Tue, Aug 12, 2014 at 12:04 AM, Jakub Hrozek jhrozek@redhat.com wrote:
On Mon, Aug 11, 2014 at 05:12:26PM -0700, Daniel Jung wrote:
Dont see much in the core either.
Core was generated by `/usr/libexec/sssd/sssd_be -d 0 --domain LDAP'. Program terminated with signal 11, Segmentation fault. #0 0x0000003502030748 in ?? () (gdb) bt #0 0x0000003502030748 in ?? () #1 0x00000000ffffe4a0 in ?? () #2 0x0000000000676f20 in ?? () #3 0x00007fffffffe580 in ?? () #4 0x00007fffffffe4f0 in ?? () #5 0x00007fffffffe618 in ?? () #6 0x0000000000000007 in ?? () #7 0x0000000000063358 in ?? () #8 0x0000000c000000d0 in ?? () #9 0x0000000000000000 in ?? ()
Looks like you're missing the debuginfo packages. Can you run:
sudo rpm -ivh
http://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/epel-...
or just: sudo debuginfo-install sssd
the latter is going to bring in more *-debuginfo packages but also ensure debuginfo symbols for dependencies are available. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Aug 12, 2014 at 06:36:05PM -0700, Daniel Jung wrote:
Installed openldap 2.4.23 manually; There are quite a few packages depending on the libldap and liblber which i had to force to reinstall.
force is usually not a good idea in a production environment, I hope it was a test VM :-)
SSSD already depends on openldap-24 (libldap-2.4.so.2 in particular) in RHEL5 in order to support the async functionality.
It doesnt sigsegv now but i am getting Wed Aug 13 03:09:37:761645 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 13 03:09:37:761687 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
And my ldapsearch -ZZ -x doesnt work anymore. Obviously this is bad libldap?
Before you upgraded to 2.4, did ldapsearch -ZZ work OK?
So using 1.5.1, my ldapsearch -ZZ works fine but sssd_be sigsegv when trying to use pam with password. And using 1.9.6 with openldap-2.4 lib, sssd with pam + password doesnt work plus and it doesnt work with ldapsearch ( this probably has to do with compat+ldap ?)
Anyone out there using sssd in centos 5 with PAM + password auth?
I don't have a RHEL-5 VM around at the moment, but our QE qualifies the LDAP authentication on RHEL-5...
The places in code that did segfault for you was patched upstream: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=7ab7fd0b4e4efd80113aa2... https://git.fedorahosted.org/cgit/sssd.git/commit/?id=5fe6ca5e339fd345119752...
But I wouldn't expect you to hit those issues except for a very busy environment where servers come and go...
On 2014-08-12 11:04 PM, Jakub Hrozek wrote:
On Tue, Aug 12, 2014 at 06:36:05PM -0700, Daniel Jung wrote:
Installed openldap 2.4.23 manually; There are quite a few packages depending on the libldap and liblber which i had to force to reinstall.
force is usually not a good idea in a production environment, I hope it was a test VM :-)
Yep in the VM :)
SSSD already depends on openldap-24 (libldap-2.4.so.2 in particular) in RHEL5 in order to support the async functionality.
It doesnt sigsegv now but i am getting Wed Aug 13 03:09:37:761645 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 13 03:09:37:761687 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
And my ldapsearch -ZZ -x doesnt work anymore. Obviously this is bad libldap?
Before you upgraded to 2.4, did ldapsearch -ZZ work OK?
ldapsearch -ZZ worked before upgrading openldap to 2.4.23 from 19
So using 1.5.1, my ldapsearch -ZZ works fine but sssd_be sigsegv when trying to use pam with password. And using 1.9.6 with openldap-2.4 lib, sssd with pam + password doesnt work plus and it doesnt work with ldapsearch ( this probably has to do with compat+ldap ?)
Anyone out there using sssd in centos 5 with PAM + password auth?
I don't have a RHEL-5 VM around at the moment, but our QE qualifies the LDAP authentication on RHEL-5...
The places in code that did segfault for you was patched upstream: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=7ab7fd0b4e4efd80113aa2... https://git.fedorahosted.org/cgit/sssd.git/commit/?id=5fe6ca5e339fd345119752...
But I wouldn't expect you to hit those issues except for a very busy environment where servers come and go...
We do have LDAP idle timeout as 1 min on the server side as we do have a lot of connections. Curious of those patches made to sssd.1.5.1 latest package avail from the repo?
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (12/08/14 23:41), Daniel Jung wrote:
On 2014-08-12 11:04 PM, Jakub Hrozek wrote:
On Tue, Aug 12, 2014 at 06:36:05PM -0700, Daniel Jung wrote:
Installed openldap 2.4.23 manually; There are quite a few packages depending on the libldap and liblber which i had to force to reinstall.
force is usually not a good idea in a production environment, I hope it was a test VM :-)
Yep in the VM :)
SSSD already depends on openldap-24 (libldap-2.4.so.2 in particular) in RHEL5 in order to support the async functionality.
It doesnt sigsegv now but i am getting Wed Aug 13 03:09:37:761645 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 13 03:09:37:761687 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
And my ldapsearch -ZZ -x doesnt work anymore. Obviously this is bad libldap?
Before you upgraded to 2.4, did ldapsearch -ZZ work OK?
ldapsearch -ZZ worked before upgrading openldap to 2.4.23 from 19
So using 1.5.1, my ldapsearch -ZZ works fine but sssd_be sigsegv when trying to use pam with password. And using 1.9.6 with openldap-2.4 lib, sssd with pam + password doesnt work plus and it doesnt work with ldapsearch ( this probably has to do with compat+ldap ?)
Anyone out there using sssd in centos 5 with PAM + password auth?
I don't have a RHEL-5 VM around at the moment, but our QE qualifies the LDAP authentication on RHEL-5...
The places in code that did segfault for you was patched upstream: https://git.fedorahosted.org/cgit/sssd.git/commit/?id=7ab7fd0b4e4efd80113aa2... https://git.fedorahosted.org/cgit/sssd.git/commit/?id=5fe6ca5e339fd345119752...
But I wouldn't expect you to hit those issues except for a very busy environment where servers come and go...
We do have LDAP idle timeout as 1 min on the server side as we do have a lot of connections. Curious of those patches made to sssd.1.5.1 latest package avail from the repo?
It should not be problem to backport patch to 1-9 branch
LS
Was unable to patch those to 1.9.6 (first one was already patched?) Second one was causing error during compile:
Also, i see these in the log : (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [highestCommittedUSN] (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_server_opts_from_rootdse] (5): No known USN scheme is supported by this server! (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_send] (4): Executing simple bind as: (null) (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_done] (5): Server returned no controls. (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_done] (3): Bind result: Success(0), (null)
http://www.openldap.org/its/index.cgi/Incoming?id=6789
based on the previous url, (null) return meaning, there is an issue with the cert?
Also, i see slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 in the ldap.log on the ldap server which seems to indicate that sssd is trying to use password policy? but i dont see this behaviour on the centos6 1.9. Is the behaviour different on 1.5.1 from other ?
if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -Iinclude -I.. -I./include -I./src/sss_client -I./src -Iinclude -I. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0 /include -I/usr/include/openldap24 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DLIBDIR="/usr/lib64" -DVARDIR="/var" -DSHLIBEXT="" -DSSSD_LIBEXEC_PATH="/usr/libexec/sssd" -DSSSD_INTRO SPECT_PATH="" -DSSSD_CONF_DIR="/etc/sssd" -DSSS_NSS_MCACHE_DIR="/var/lib/sss/mc" -DSSS_NSS_SOCKET_NAME="/var/lib/sss/pipes/nss" -DSSS_PAM_SOCKET_NAME="/var/lib/sss/pipes/pam" -DSSS_PAC_SOCKET_NAME="/ var/lib/sss/pipes/pac" -DSSS_PAM_PRIV_SOCKET_NAME="/var/lib/sss/pipes/private/pam" -DSSS_SUDO_SOCKET_NAME="/var/lib/sss/pipes/sudo" -DSSS_AUTOFS_SOCKET_NAME="/var/lib/sss/pipes/autofs" -DSSS_SSH_SOCKET_N AME="/var/lib/sss/pipes/ssh" -DLOCALEDIR="@localedir@" -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Werror-implicit-function-declaration -fno-strict-aliasin g -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -MT src/prov iders/ldap/sdap_reinit.lo -MD -MP -MF "$depbase.Tpo" -c -o src/providers/ldap/sdap_reinit.lo src/providers/ldap/sdap_reinit.c; \ then mv -f "$depbase.Tpo" "$depbase.Plo"; else rm -f "$depbase.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -Iinclude -I.. -I./include -I./src/sss_client -I./src -Iinclude -I. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/openldap24 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DLIBDIR="/usr/lib64" -DVARDIR="/var" -DSHLIBEXT="" -DSSSD_LIBEXEC_PATH="/usr/libexec/sssd" -DSSSD_INTROSPECT_PATH="" -DSSSD_CONF_DIR="/etc/sssd" -DSSS_NSS_MCACHE_DIR= "/var/lib/sss/mc" -DSSS_NSS_SOCKET_NAME="/var/lib/sss/pipes/nss" -DSSS_PAM_SOCKET_NAME="/var/lib/sss/pipes/pam" -DSSS_PAC_SOCKET_NAME="/var/lib/sss/pipes/pac" -DSSS_PAM_PRIV_SOCKET_NAME="/var/lib/sss/p ipes/private/pam" -DSSS_SUDO_SOCKET_NAME="/var/lib/sss/pipes/sudo" -DSSS_AUTOFS_SOCKET_NAME="/var/lib/sss/pipes/autofs" -DSSS_SSH_SOCKET_NAME="/var/lib/sss/pipes/ssh" -DLOCALEDIR="@localedir@" -Wall -W shadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Werror-implicit-function-declaration -fno-strict-aliasing -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -MT src/providers/ldap/sdap_async_connection.lo -MD -MP -MF src/providers/ldap/.d eps/sdap_async_connection.Tpo -c src/providers/ldap/sdap_async_connection.c -fPIC -DPIC -o src/providers/ldap/.libs/sdap_async_connection.o src/providers/ldap/sdap_async.c:842: error: expected identifier or '(' before 'if' gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -Iinclude -I.. -I./include -I./src/sss_client -I./src -Iinclude -I. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/openldap24 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DLIBDIR="/usr/lib64" -DVARDIR="/var" -DSHLIBEXT="" -DSSSD_LIBEXEC_PATH="/usr/libexec/sssd" -DSSSD_INTROSPECT_PATH="" -DSSSD_CONF_DIR="/etc/sssd" -DSSS_NSS_MCACHE_DIR= "/var/lib/sss/mc" -DSSS_NSS_SOCKET_NAME="/var/lib/sss/pipes/nss" -DSSS_PAM_SOCKET_NAME="/var/lib/sss/pipes/pam" -DSSS_PAC_SOCKET_NAME="/var/lib/sss/pipes/pac" -DSSS_PAM_PRIV_SOCKET_NAME="/var/lib/sss/p ipes/private/pam" -DSSS_SUDO_SOCKET_NAME="/var/lib/sss/pipes/sudo" -DSSS_AUTOFS_SOCKET_NAME="/var/lib/sss/pipes/autofs" -DSSS_SSH_SOCKET_NAME="/var/lib/sss/pipes/ssh" -DLOCALEDIR="@localedir@" -Wall -W shadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Werror-implicit-function-declaration -fno-strict-aliasing -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -MT src/providers/ldap/sdap_async_services.lo -MD -MP -MF src/providers/ldap/.dep s/sdap_async_services.Tpo -c src/providers/ldap/sdap_async_services.c -fPIC -DPIC -o src/providers/ldap/.libs/sdap_async_services.o make[2]: *** [src/providers/ldap/sdap_async.lo] Error 1 make[2]: *** Waiting for unfinished jobs....
gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -Iinclude -I.. -I./include -I./src/sss_client -I./src -Iinclude -I. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/openldap24 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DLIBDIR="/usr/lib64" -DVARDIR="/var" -DSHLIBEXT="" -DSSSD_LIBEXEC_PATH="/usr/libexec/sssd" -DSSSD_INTROSPECT_PATH="" -DSSSD_CONF_DIR="/etc/sssd" -DSSS_NSS_MCACHE_DIR="/var/lib/sss/mc" -DSSS_NSS_SOCKET_NAME="/var/lib/sss/pipes/nss" -DSSS_PAM_SOCKET_NAME="/var/lib/sss/pipes/pam" -DSSS_PAC_SOCKET_NAME="/var/lib/sss/pipes/pac" -DSSS_PAM_PRIV_SOCKET_NAME="/var/lib/sss/pipes/private/pam" -DSSS_SUDO_SOCKET_NAME="/var/lib/sss/pipes/sudo" -DSSS_AUTOFS_SOCKET_NAME="/var/lib/sss/pipes/autofs" -DSSS_SSH_SOCKET_NAME="/var/lib/sss/pipes/ssh" -DLOCALEDIR="@localedir@" -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Werror-implicit-function-declaration -fno-strict-aliasing -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -MT src/providers/ldap/sdap_child_helpers.lo -MD -MP -MF src/providers/ldap/.deps/sdap_child_helpers.Tpo -c src/providers/ldap/sdap_child_helpers.c -fPIC -DPIC -o src/providers/ldap/.libs/sdap_child_helpers.o src/providers/ldap/sdap_async_connection.c: In function 'sasl_bind_send': src/providers/ldap/sdap_async_connection.c:749: warning: statement with no effect src/providers/ldap/sdap_async_connection.c:749: error: expected ';' before string constant src/providers/ldap/sdap_async_connection.c:751: error: 'ERR_NETWORK_IO' undeclared (first use in this function) src/providers/ldap/sdap_async_connection.c:751: error: (Each undeclared identifier is reported only once src/providers/ldap/sdap_async_connection.c:751: error: for each function it appears in.)
gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -Iinclude -I.. -I./include -I./src/sss_client -I./src -Iinclude -I. -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/openldap24 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DLIBDIR="/usr/lib64" -DVARDIR="/var" -DSHLIBEXT="" -DSSSD_LIBEXEC_PATH="/usr/libexec/sssd" -DSSSD_INTROSPECT_PATH="" -DSSSD_CONF_DIR="/etc/sssd" -DSSS_NSS_MCACHE_DIR="/var/lib/sss/mc" -DSSS_NSS_SOCKET_NAME="/var/lib/sss/pipes/nss" -DSSS_PAM_SOCKET_NAME="/var/lib/sss/pipes/pam" -DSSS_PAC_SOCKET_NAME="/var/lib/sss/pipes/pac" -DSSS_PAM_PRIV_SOCKET_NAME="/var/lib/sss/pipes/private/pam" -DSSS_SUDO_SOCKET_NAME="/var/lib/sss/pipes/sudo" -DSSS_AUTOFS_SOCKET_NAME="/var/lib/sss/pipes/autofs" -DSSS_SSH_SOCKET_NAME="/var/lib/sss/pipes/ssh" -DLOCALEDIR="@localedir@" -Wall -Wshadow -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Werror-implicit-function-declaration -fno-strict-aliasing -std=gnu99 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -MT src/providers/ldap/sdap_idmap.lo -MD -MP -MF src/providers/ldap/.deps/sdap_idmap.Tpo -c src/providers/ldap/sdap_idmap.c -fPIC -DPIC -o src/providers/ldap/.libs/sdap_idmap.o src/providers/ldap/sdap_async_connection.c: In function 'sdap_rebind_proc': src/providers/ldap/sdap_async_connection.c:1880: warning: statement with no effect src/providers/ldap/sdap_async_connection.c:1880: error: expected ';' before string constant src/providers/ldap/sdap_async_connection.c:1882: error: 'ERR_NETWORK_IO' undeclared (first use in this function) make[2]: *** [src/providers/ldap/sdap_async_connection.lo] Error 1
On Wed, Aug 13, 2014 at 12:53 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (12/08/14 23:41), Daniel Jung wrote:
On 2014-08-12 11:04 PM, Jakub Hrozek wrote:
On Tue, Aug 12, 2014 at 06:36:05PM -0700, Daniel Jung wrote:
Installed openldap 2.4.23 manually; There are quite a few packages depending on the libldap and liblber which i had to force to reinstall.
force is usually not a good idea in a production environment, I hope it was a test VM :-)
Yep in the VM :)
SSSD already depends on openldap-24 (libldap-2.4.so.2 in particular) in RHEL5 in order to support the async functionality.
It doesnt sigsegv now but i am getting Wed Aug 13 03:09:37:761645 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 13 03:09:37:761687 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
And my ldapsearch -ZZ -x doesnt work anymore. Obviously this is bad libldap?
Before you upgraded to 2.4, did ldapsearch -ZZ work OK?
ldapsearch -ZZ worked before upgrading openldap to 2.4.23 from 19
So using 1.5.1, my ldapsearch -ZZ works fine but sssd_be sigsegv when trying to use pam with password. And using 1.9.6 with openldap-2.4 lib, sssd with pam + password doesnt work plus and it doesnt work with ldapsearch ( this probably has to do with compat+ldap ?)
Anyone out there using sssd in centos 5 with PAM + password auth?
I don't have a RHEL-5 VM around at the moment, but our QE qualifies the LDAP authentication on RHEL-5...
The places in code that did segfault for you was patched upstream:
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=7ab7fd0b4e4efd80113aa2...
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=5fe6ca5e339fd345119752...
But I wouldn't expect you to hit those issues except for a very busy environment where servers come and go...
We do have LDAP idle timeout as 1 min on the server side as we do have a lot of connections. Curious of those patches made to sssd.1.5.1 latest package avail from the repo?
It should not be problem to backport patch to 1-9 branch
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (15/08/14 16:10), Daniel Jung wrote:
Was unable to patch those to 1.9.6 (first one was already patched?) Second one was causing error during compile:
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=5fe6ca5e339fd345119752...
You are right this patch is already in 1-9 branch.
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=7ab7fd0b4e4efd80113aa2...
Version for 1-9 branch is attached.
Could you test it? If you don't know then the easist way will be to build rpms with make (make rpms)
LS
Still seeing sssd[be[LDAP]]: Could not start TLS encryption. unknown error
Wed Aug 20 01:27:53:174091 2014) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Wed Aug 20 01:27:53:174891 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 20 01:27:53:174930 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
As a recap, openldap user land tools works using -ZZ. upgraded sssd to 1.9.6, upgraded openldap lib to 2.4.39. Any other ideas?
By the way, what was the main decision for compiling against openldap 2.4 when other critical package still compiles against 2.3 ldap lib? Making the upgrade path to openldap 2.4 very difficult.
On Sat, Aug 16, 2014 at 3:34 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (15/08/14 16:10), Daniel Jung wrote:
Was unable to patch those to 1.9.6 (first one was already patched?) Second one was causing error during compile:
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=5fe6ca5e339fd345119752... You are right this patch is already in 1-9 branch.
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=7ab7fd0b4e4efd80113aa2... Version for 1-9 branch is attached.
Could you test it? If you don't know then the easist way will be to build rpms with make (make rpms)
LS
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (19/08/14 16:37), Daniel Jung wrote:
Still seeing sssd[be[LDAP]]: Could not start TLS encryption. unknown error
Wed Aug 20 01:27:53:174091 2014) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Wed Aug 20 01:27:53:174891 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 20 01:27:53:174930 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
As a recap, openldap user land tools works using -ZZ. upgraded sssd to 1.9.6, upgraded openldap lib to 2.4.39. Any other ideas?
By the way, what was the main decision for compiling against openldap 2.4 when other critical package still compiles against 2.3 ldap lib? Making the upgrade path to openldap 2.4 very difficult.
Patch from previous mail just fixed crash. SSSD can try to reconnect after few seconds (value of "offline_timeout")
It is not clear from previous log file; It can be problem with long synchronous calls. You can try to modify some timeout options:
ldap_network_timeout (integer) Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.
Default: 6
ldap_opt_timeout (integer) Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also controls the timeout when communicating with the KDC in case of SASL bind.
Default: 6
other options in man sssd-ldap
LS
I did try modifying the above two parameters with longer timeouts 15secs and these didnt make any difference, still seeing sssd[be[LDAP]]: Could not start TLS encryption. unknown error.
I think there is an issue with way sssd calls ldap lib which may be contributing to this problem. Could someone who uses centos > 5.8 confirm sssd is actually working with pam auth?
(Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [highestCommittedUSN] (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_server_opts_from_rootdse] (5): No known USN scheme is supported by this server! (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_send] (4): Executing simple bind as: (null) (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_done] (5): Server returned no controls. (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_done] (3): Bind result: Success(0), (null)
http://www.openldap.org/its/index.cgi/Incoming?id=6789
based on the previous url, (null) return meaning, there was an issue but sssd didnt get the appropriate msg back from LDAP?
Also, i see slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 in the ldap.log on the ldap server which seems to indicate that sssd is trying to use password policy? but i dont see this behaviour on the sssd running on centos6 as welll on <= centos5.6. Has there been change in the way sssd connects to LDAP?
On Wed, Aug 20, 2014 at 12:44 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (19/08/14 16:37), Daniel Jung wrote:
Still seeing sssd[be[LDAP]]: Could not start TLS encryption. unknown error
Wed Aug 20 01:27:53:174091 2014) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Wed Aug 20 01:27:53:174891 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 20 01:27:53:174930 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
As a recap, openldap user land tools works using -ZZ. upgraded sssd to 1.9.6, upgraded openldap lib to 2.4.39. Any other ideas?
By the way, what was the main decision for compiling against openldap 2.4 when other critical package still compiles against 2.3 ldap lib? Making
the
upgrade path to openldap 2.4 very difficult.
Patch from previous mail just fixed crash. SSSD can try to reconnect after few seconds (value of "offline_timeout")
It is not clear from previous log file; It can be problem with long synchronous calls. You can try to modify some timeout options:
ldap_network_timeout (integer) Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity. Default: 6 ldap_opt_timeout (integer) Specifies a timeout (in seconds) after which calls to
synchronous LDAP APIs will abort if no response is received. Also controls the timeout when communicating with the KDC in case of SASL bind.
Default: 6
other options in man sssd-ldap
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Also, i tried other versions, 1.8.6, 1.5.7 etc. but still having issue with TLS. Any ideas guys?
On Wed, Aug 20, 2014 at 1:57 PM, Daniel Jung mimianddaniel@gmail.com wrote:
I did try modifying the above two parameters with longer timeouts 15secs and these didnt make any difference, still seeing sssd[be[LDAP]]: Could not start TLS encryption. unknown error.
I think there is an issue with way sssd calls ldap lib which may be contributing to this problem. Could someone who uses centos > 5.8 confirm sssd is actually working with pam auth?
(Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [highestCommittedUSN] (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [sdap_get_server_opts_from_rootdse] (5): No known USN scheme is supported by this server! (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_send] (4): Executing simple bind as: (null) (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_done] (5): Server returned no controls. (Fri Aug 15 01:25:04 2014) [sssd[be[LDAP]]] [simple_bind_done] (3): Bind result: Success(0), (null)
http://www.openldap.org/its/index.cgi/Incoming?id=6789
based on the previous url, (null) return meaning, there was an issue but sssd didnt get the appropriate msg back from LDAP?
Also, i see slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 in the ldap.log on the ldap server which seems to indicate that sssd is trying to use password policy? but i dont see this behaviour on the sssd running on centos6 as welll on <= centos5.6. Has there been change in the way sssd connects to LDAP?
On Wed, Aug 20, 2014 at 12:44 AM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (19/08/14 16:37), Daniel Jung wrote:
Still seeing sssd[be[LDAP]]: Could not start TLS encryption. unknown
error
Wed Aug 20 01:27:53:174091 2014) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Wed Aug 20 01:27:53:174891 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null) (Wed Aug 20 01:27:53:174930 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): ldap_install_tls failed: [Connect error] [unknown error]
As a recap, openldap user land tools works using -ZZ. upgraded sssd to 1.9.6, upgraded openldap lib to 2.4.39. Any other ideas?
By the way, what was the main decision for compiling against openldap 2.4 when other critical package still compiles against 2.3 ldap lib? Making
the
upgrade path to openldap 2.4 very difficult.
Patch from previous mail just fixed crash. SSSD can try to reconnect after few seconds (value of "offline_timeout")
It is not clear from previous log file; It can be problem with long synchronous calls. You can try to modify some timeout options:
ldap_network_timeout (integer) Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity. Default: 6 ldap_opt_timeout (integer) Specifies a timeout (in seconds) after which calls to
synchronous LDAP APIs will abort if no response is received. Also controls the timeout when communicating with the KDC in case of SASL bind.
Default: 6
other options in man sssd-ldap
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Have already tested on different LDAP servers but running same version, the latest avail from openldap, 2.4.39 and still same failure with TLS.
On Fri, Aug 22, 2014 at 2:04 PM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (22/08/14 13:11), Daniel Jung wrote:
Also, i tried other versions, 1.8.6, 1.5.7 etc. but still having issue
with
TLS. Any ideas guys?
You mentioned you have lot of connections on ldap server. Could you try to test with different LDAP server (testing) ?
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (22/08/14 15:17), Daniel Jung wrote:
Have already tested on different LDAP servers but running same version, the latest avail from openldap, 2.4.39 and still same failure with TLS.
There should not be problem with openldap-server-2.4.39. Do you use the same valid certificate (even self-signed) on server and client? Could you send me log files with debug_level = 10?
LS
Hi Lukas,
By eliminating the link libs to SSSD, i rebuilt nss and noticed that there is no libnsspem.so from the src [0] which seems to be required for reading PEM cert.
After rebuilding nss with nss_pem.git[1] for cento5 and PAM passwd + auth works now. Sat Aug 23 01:15:02:652979 2014) [sssd[be[LDAP]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to with fd [27]. (Sat Aug 23 01:15:02:652999 2014) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Sat Aug 23 01:15:02:653682 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null)
Openldap user land tools and openssh were able to create TLS connections to the ldap server without this rebuilt of NSS with libnsspem, which seems to indicate that when sssd was built it didnt have approprate dependency to read the pem file properly for centos5 > 5.6. I havent heard from anyone on the list to say that PAM + AUTH + SSSD is working on centos 5.6 and up yet. I found this to be very unsettling. Could you please verify?
Thanks
[0] http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_16_4_RTM/...
[1] https://git.fedorahosted.org/cgit/nss-pem.git/
On Fri, Aug 22, 2014 at 3:23 PM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (22/08/14 15:17), Daniel Jung wrote:
Have already tested on different LDAP servers but running same version,
the
latest avail from openldap, 2.4.39 and still same failure with TLS.
There should not be problem with openldap-server-2.4.39. Do you use the same valid certificate (even self-signed) on server and client? Could you send me log files with debug_level = 10?
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
So here is the step i had to get PAM+PASS SSSD working on centos5.10 - Upgrade openldap to 2.4.39 (recent openldap lib other than 2.4.19 otherwise, sssd would segfault) , will need to install nss-tool - Upgrade nss with nss-pem
For those who has tried and didnt have success with working cert with openldap + openssl/openssh
On Fri, Aug 22, 2014 at 4:35 PM, Daniel Jung mimianddaniel@gmail.com wrote:
Hi Lukas,
By eliminating the link libs to SSSD, i rebuilt nss and noticed that there is no libnsspem.so from the src [0] which seems to be required for reading PEM cert.
After rebuilding nss with nss_pem.git[1] for cento5 and PAM passwd + auth works now. Sat Aug 23 01:15:02:652979 2014) [sssd[be[LDAP]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to with fd [27]. (Sat Aug 23 01:15:02:652999 2014) [sssd[be[LDAP]]] [sdap_sys_connect_done] (0x0100): Executing START TLS (Sat Aug 23 01:15:02:653682 2014) [sssd[be[LDAP]]] [sdap_connect_done] (0x0080): START TLS result: Success(0), (null)
Openldap user land tools and openssh were able to create TLS connections to the ldap server without this rebuilt of NSS with libnsspem, which seems to indicate that when sssd was built it didnt have approprate dependency to read the pem file properly for centos5 > 5.6. I havent heard from anyone on the list to say that PAM + AUTH + SSSD is working on centos 5.6 and up yet. I found this to be very unsettling. Could you please verify?
Thanks
[0]
http://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_16_4_RTM/...
[1] https://git.fedorahosted.org/cgit/nss-pem.git/
On Fri, Aug 22, 2014 at 3:23 PM, Lukas Slebodnik lslebodn@redhat.com wrote:
On (22/08/14 15:17), Daniel Jung wrote:
Have already tested on different LDAP servers but running same version,
the
latest avail from openldap, 2.4.39 and still same failure with TLS.
There should not be problem with openldap-server-2.4.39. Do you use the same valid certificate (even self-signed) on server and client? Could you send me log files with debug_level = 10?
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org