[SSSD] Re: Unable to login with SSH
I have opened a new discussion on sssd-users. The current discussion can be deleted. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#93][closed] SSH: Use default_domain_suffix for users' authorized keys
URL: https://github.com/SSSD/sssd/pull/93 Author: jhrozek Title: #93: SSH: Use default_domain_suffix for users' authorized keys Action: closed To pull the PR as Git branch: git remote add ghsssd https://github.com/SSSD/sssd git fetch ghsssd pull/93/head:pr93 git checkout pr93 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#93][+Pushed] SSH: Use default_domain_suffix for users' authorized keys
URL: https://github.com/SSSD/sssd/pull/93 Title: #93: SSH: Use default_domain_suffix for users' authorized keys Label: +Pushed ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#93][-Accepted] SSH: Use default_domain_suffix for users' authorized keys
URL: https://github.com/SSSD/sssd/pull/93 Title: #93: SSH: Use default_domain_suffix for users' authorized keys Label: -Accepted ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#93][comment] SSH: Use default_domain_suffix for users' authorized keys
URL: https://github.com/SSSD/sssd/pull/93 Title: #93: SSH: Use default_domain_suffix for users' authorized keys jhrozek commented: """ master: ed71fba97dfcf5b3f0f1834c06660c481b9ab3ce sssd-1-14: 2949fe58ac344c44d756ca309d4b2b7f3590cee3 """ See the full comment at https://github.com/SSSD/sssd/pull/93#issuecomment-265115833 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#93][comment] SSH: Use default_domain_suffix for users' authorized keys
URL: https://github.com/SSSD/sssd/pull/93 Title: #93: SSH: Use default_domain_suffix for users' authorized keys jhrozek commented: """ On Mon, Nov 28, 2016 at 05:06:54AM -0800, Pavel Březina wrote: > Can you also prepare a patch to handle this inside cache_req? Ideally on > top of nss patches so we can avoid collisions. > Yes, but since this patch had to be pushed for downstream's sake, I filed a ticket in the meantime: https://fedorahosted.org/sssd/ticket/3260 """ See the full comment at https://github.com/SSSD/sssd/pull/93#issuecomment-265116353 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req pbrezina commented: """ On 12/05/2016 04:36 PM, lslebodn wrote: > SSS_SEED user offline authentication failed: > > * block access to the ldap > * sleep a bit (e.g. 4 seconds) > * seed the SSSD cache with a user: sss_seed -D LDAP -n seeduser -u > 10121 -g 10121 -c "Temporary" -h /home/temp-user -s /bin/bash > * type some password twice for finishing sss_seed (e.g. SimplePassword123) > * authenticate as a seeduser with password SimplePassword123 This fails for me even on master: [pam_reply] (0x0200): pam_reply called with result [9]: Authentication service cannot retrieve authentication info. """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-265117220 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] trac cleanup of the 1.14 backlog milestone
Hi, I checked the 1.14 backlog milestone. I think most of the tickets can be just moved to "Future releases" except for a couple where I was quite confident the ticket can be just closed (and I just closed them), except for these: https://fedorahosted.org/sssd/ticket/1400 - [RFE] In memory fast cache should support negative caching https://fedorahosted.org/sssd/ticket/2497 - When machine gets IPA-enrolled to different IPA with the same domain name and the same users, caches prevent correct operation https://fedorahosted.org/sssd/ticket/2967 - Intermittent attribute retrieval failure from AD The three above should IMO be moved to "Patches welcome". Next on my cleanup todo list is 1.14.3 milestone - IMO only bug fixes should be there, the other tickets would just be overlooked since we are not developing new features or new tests for 1.14. Then it's finally time to start drafting the 1.15 milestone.. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Re: trac cleanup of the 1.14 backlog milestone
On 12/06/2016 11:56 AM, Jakub Hrozek wrote: Hi, I checked the 1.14 backlog milestone. I think most of the tickets can be just moved to "Future releases" except for a couple where I was quite confident the ticket can be just closed (and I just closed them), except for these: https://fedorahosted.org/sssd/ticket/1400 - [RFE] In memory fast cache should support negative caching +1 for Patches welcome https://fedorahosted.org/sssd/ticket/2497 - When machine gets IPA-enrolled to different IPA with the same domain name and the same users, caches prevent correct operation This should at least be documented as a known issue before we put it to Patches welcome milestone. Maybe putting it to the troubleshooting wiki page? https://fedorahosted.org/sssd/ticket/2967 - Intermittent attribute retrieval failure from AD Not sure about this. Lukas owns the issue, maybe he will know more. The three above should IMO be moved to "Patches welcome". Next on my cleanup todo list is 1.14.3 milestone - IMO only bug fixes should be there, the other tickets would just be overlooked since we are not developing new features or new tests for 1.14. Then it's finally time to start drafting the 1.15 milestone.. ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] Feedback About probable Fix for sssd/ticket/1149
Hello, _https://fedorahosted.org/sssd/ticket/1149 _Yes replacement of talloc_get_type() with talloc_get_type_abort() is good move, reasons mentioned in description. Current sssd contains 773 occurrences of talloc_get_type. I suppose Fix is: Replacing all 773 occurrences with talloc_get_type_abort(). Sanity Test: 1. # make intgchk 2. Use case: Configuring AD trust using sssd. My Queries: 1. Is Fix correct? 2. Does any other specific/corner test-case is required? Thanks ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ When I was testing crash caused by enumeration I also found different valgrind errors. I double checked that these errors are not in master. ``` ==18958== 1 errors in context 1 of 1: ==18958== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==18958==at 0x32BF20ED62: send (send.c:28) ==18958==by 0x41607E: sss_packet_send (responder_packet.c:238) ==18958==by 0x412B7A: client_fd_handler (responder_common.c:258) ==18958==by 0x32C4E09F05: epoll_event_loop_once (tevent_epoll.c:728) ==18958==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==18958==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==18958==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637) ==18958==by 0x32C4E082A5: std_event_loop_wait (tevent_standard.c:140) ==18958==by 0x32C564AEB2: server_loop (server.c:705) ==18958==by 0x4066F7: main (nsssrv.c:559) ==18958== Address 0x4da3148 is 120 bytes inside a block of size 608 alloc'd ==18958==at 0x4A06A2E: malloc (vg_replace_malloc.c:270) ==18958==by 0x32C0E03422: talloc_named_const (talloc.c:668) ==18958==by 0x41627A: sss_packet_new (responder_packet.c:84) ==18958==by 0x40982A: nss_protocol_reply (nss_protocol.c:84) ==18958==by 0x406B13: nss_getby_done (nss_cmd.c:338) ==18958==by 0x4198F9: cache_req_done (cache_req.c:690) ==18958==by 0x41A595: cache_req_search_done (cache_req_search.c:409) ==18958==by 0x415B6D: sss_dp_internal_get_done (responder_dp.c:813) ==18958==by 0x32C320E619: complete_pending_call_and_unlock (dbus-connection.c:2234) ==18958==by 0x32C321086E: dbus_connection_dispatch (dbus-connection.c:4397) ==18958==by 0x32C5641D7C: sbus_dispatch (sssd_dbus_connection.c:96) ==18958==by 0x32C4E08CC0: tevent_common_loop_timer_delay (tevent_timed.c:341) ``` and similar with realloc `==7607== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==7607==at 0x32BF20ED62: send (send.c:28) ==7607==by 0x41607E: sss_packet_send (responder_packet.c:238) ==7607==by 0x412B7A: client_fd_handler (responder_common.c:258) ==7607==by 0x32C4E09F05: epoll_event_loop_once (tevent_epoll.c:728) ==7607==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==7607==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==7607==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637) ==7607==by 0x32C4E082A5: std_event_loop_wait (tevent_standard.c:140) ==7607==by 0x32C564AEB2: server_loop (server.c:705) ==7607==by 0x4066F7: main (nsssrv.c:559) ==7607== Address 0xe4c228c is 1,068 bytes inside a block of size 1,632 alloc'd ==7607==at 0x4A06C20: realloc (vg_replace_malloc.c:662) ==7607==by 0x32C0E099AA: _talloc_realloc (talloc.c:1880) ==7607==by 0x4163B9: sss_packet_grow (responder_packet.c:127) ==7607==by 0x40AF86: nss_protocol_fill_initgr (nss_protocol_grent.c:346) ==7607==by 0x409873: nss_protocol_reply (nss_protocol.c:91) ==7607==by 0x406B13: nss_getby_done (nss_cmd.c:338) ==7607==by 0x4198F9: cache_req_done (cache_req.c:690) ==7607==by 0x32C4E04867: tevent_common_loop_immediate (tevent_immediate.c:135) ==7607==by 0x32C4E09CF5: epoll_event_loop_once (tevent_epoll.c:906) ==7607==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==7607==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==7607==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637)`` ``` """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-265215397 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ When I was testing crash caused by enumeration I also found different valgrind errors. I double checked that these errors are not in master. ``` ==18958== 1 errors in context 1 of 1: ==18958== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==18958==at 0x32BF20ED62: send (send.c:28) ==18958==by 0x41607E: sss_packet_send (responder_packet.c:238) ==18958==by 0x412B7A: client_fd_handler (responder_common.c:258) ==18958==by 0x32C4E09F05: epoll_event_loop_once (tevent_epoll.c:728) ==18958==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==18958==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==18958==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637) ==18958==by 0x32C4E082A5: std_event_loop_wait (tevent_standard.c:140) ==18958==by 0x32C564AEB2: server_loop (server.c:705) ==18958==by 0x4066F7: main (nsssrv.c:559) ==18958== Address 0x4da3148 is 120 bytes inside a block of size 608 alloc'd ==18958==at 0x4A06A2E: malloc (vg_replace_malloc.c:270) ==18958==by 0x32C0E03422: talloc_named_const (talloc.c:668) ==18958==by 0x41627A: sss_packet_new (responder_packet.c:84) ==18958==by 0x40982A: nss_protocol_reply (nss_protocol.c:84) ==18958==by 0x406B13: nss_getby_done (nss_cmd.c:338) ==18958==by 0x4198F9: cache_req_done (cache_req.c:690) ==18958==by 0x41A595: cache_req_search_done (cache_req_search.c:409) ==18958==by 0x415B6D: sss_dp_internal_get_done (responder_dp.c:813) ==18958==by 0x32C320E619: complete_pending_call_and_unlock (dbus-connection.c:2234) ==18958==by 0x32C321086E: dbus_connection_dispatch (dbus-connection.c:4397) ==18958==by 0x32C5641D7C: sbus_dispatch (sssd_dbus_connection.c:96) ==18958==by 0x32C4E08CC0: tevent_common_loop_timer_delay (tevent_timed.c:341) ``` and similar with realloc ``` ==7607== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==7607==at 0x32BF20ED62: send (send.c:28) ==7607==by 0x41607E: sss_packet_send (responder_packet.c:238) ==7607==by 0x412B7A: client_fd_handler (responder_common.c:258) ==7607==by 0x32C4E09F05: epoll_event_loop_once (tevent_epoll.c:728) ==7607==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==7607==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==7607==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637) ==7607==by 0x32C4E082A5: std_event_loop_wait (tevent_standard.c:140) ==7607==by 0x32C564AEB2: server_loop (server.c:705) ==7607==by 0x4066F7: main (nsssrv.c:559) ==7607== Address 0xe4c228c is 1,068 bytes inside a block of size 1,632 alloc'd ==7607==at 0x4A06C20: realloc (vg_replace_malloc.c:662) ==7607==by 0x32C0E099AA: _talloc_realloc (talloc.c:1880) ==7607==by 0x4163B9: sss_packet_grow (responder_packet.c:127) ==7607==by 0x40AF86: nss_protocol_fill_initgr (nss_protocol_grent.c:346) ==7607==by 0x409873: nss_protocol_reply (nss_protocol.c:91) ==7607==by 0x406B13: nss_getby_done (nss_cmd.c:338) ==7607==by 0x4198F9: cache_req_done (cache_req.c:690) ==7607==by 0x32C4E04867: tevent_common_loop_immediate (tevent_immediate.c:135) ==7607==by 0x32C4E09CF5: epoll_event_loop_once (tevent_epoll.c:906) ==7607==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==7607==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==7607==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637)`` ``` """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-265215397 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][+Changes requested] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req Label: +Changes requested ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ There is also a crash for group enumeration ``` (Wed Nov 30 09:22:36 2016) [sssd[nss]] [cache_req_search_done] (0x0400): CR #0: Returning updated object [Groups enumeration] (Wed Nov 30 09:22:36 2016) [sssd[nss]] [cache_req_create_and_add_result] (0x0400): CR #0: Found 1 entries in domain LDAP (Wed Nov 30 09:22:36 2016) [sssd[nss]] [cache_req_done] (0x0400): CR #0: Finished: Success (Wed Nov 30 09:22:36 2016) [sssd[nss]] [nss_protocol_done] (0x4000): Sending reply: success (Wed Nov 30 09:22:36 2016) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7fc44877b5c0:2:*@LDAP] (Wed Nov 30 09:22:36 2016) [sssd[nss]] [nss_setent_timeout] (0x0400): Enumeration result object has expired. (Wed Nov 30 09:22:36 2016) [sssd[nss]] [talloc_log_fn] (0x0010): Bad talloc magic value - unknown value ``` UPDATE: The crash is cause by `enum_cache_timeout = 0` in nss section ``` [nss] debug_level = 0x memcache_timeout= 0 # FIXME Remove once Bug 996610 is fixed enum_cache_timeout = 0 ``` and valgrind error: ``` ==15177== Process terminating with default action of signal 6 (SIGABRT) ==15177==at 0x32BEE32495: raise (raise.c:64) ==15177==by 0x32BEE33C74: abort (abort.c:92) ==15177==by 0x32C0E0248B: talloc_abort (talloc.c:399) ==15177==by 0x32C0E0A5E7: talloc_check_name (talloc.c:417) ==15177==by 0x408177: nss_setent_timeout (nss_enum.c:199) ==15177==by 0x32C4E08CC0: tevent_common_loop_timer_delay (tevent_timed.c:341) ==15177==by 0x32C4E09D01: epoll_event_loop_once (tevent_epoll.c:911) ==15177==by 0x32C4E08335: std_event_loop_once (tevent_standard.c:114) ==15177==by 0x32C4E03C3C: _tevent_loop_once (tevent.c:533) ==15177==by 0x32C4E03CBA: tevent_common_loop_wait (tevent.c:637) ==15177==by 0x32C4E082A5: std_event_loop_wait (tevent_standard.c:140) ==15177==by 0x32C564AEB2: server_loop (server.c:705) ``` """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-264900328 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
[SSSD] [sssd PR#89][comment] nss: rewrite nss responder so it uses cache_req
URL: https://github.com/SSSD/sssd/pull/89 Title: #89: nss: rewrite nss responder so it uses cache_req lslebodn commented: """ On (06/12/16 02:40), Pavel Březina wrote: >On 12/05/2016 04:36 PM, lslebodn wrote: >> SSS_SEED user offline authentication failed: >> >> * block access to the ldap >> * sleep a bit (e.g. 4 seconds) >> * seed the SSSD cache with a user: sss_seed -D LDAP -n seeduser -u >> 10121 -g 10121 -c "Temporary" -h /home/temp-user -s /bin/bash >> * type some password twice for finishing sss_seed (e.g. SimplePassword123) >> * authenticate as a seeduser with password SimplePassword123 > >This fails for me even on master: >[pam_reply] (0x0200): pam_reply called with result [9]: Authentication >service cannot retrieve authentication info. > It just mean that I didn't provide reliable reproducer because it works on master. FYI: it is caused by valgrind error "Syscall param socketcall.sendto(msg) points to uninitialised byte(s)" LS """ See the full comment at https://github.com/SSSD/sssd/pull/89#issuecomment-265244156 ___ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
