Description of problem: Happens right after boot finishes - before user logs in - on a Fedora 25 install (from Fedora-Server-dvd-x86_64-25-20160810.n.0.iso ) which was enrolled to a FreeIPA domain during installation via a kickstart. This is an openQA test: https://openqa.stg.fedoraproject.org/tests/31320 . Later on, the test attempts to log in as a FreeIPA user, and the login fails; I believe this crash is why. A system enrolled to the same server post-install does not show the same problem. Version-Release number of selected component: sssd-common-1.14.0-4.fc25 Additional info: reporter: libreport-2.7.2 backtrace_rating: 4 cmdline: /usr/libexec/sssd/sssd_be --domain domain.local --uid 0 --gid 0 --debug-to-files crash_function: ipa_dyndns_update_send executable: /usr/libexec/sssd/sssd_be global_pid: 973 kernel: 4.8.0-0.rc1.git0.1.fc25.x86_64 pkg_vendor: Fedora Project runlevel: N 3 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #0 ipa_dyndns_update_send at src/providers/ipa/ipa_dyndns.c:175 #1 ipa_dyndns_update at src/providers/ipa/ipa_dyndns.c:122 #2 be_run_cb_step at src/providers/data_provider_callbacks.c:96 #3 tevent_common_loop_timer_delay at ../tevent_timed.c:341 #4 epoll_event_loop at ../tevent_epoll.c:659 #5 epoll_event_loop_once at ../tevent_epoll.c:926 #6 std_event_loop_once at ../tevent_standard.c:114 #7 _tevent_loop_once at ../tevent.c:533 #8 tevent_common_loop_wait at ../tevent.c:637 #9 std_event_loop_wait at ../tevent_standard.c:145
Created attachment 1190161 [details] File: backtrace
Created attachment 1190162 [details] File: cgroup
Created attachment 1190163 [details] File: core_backtrace
Created attachment 1190164 [details] File: dso_list
Created attachment 1190165 [details] File: environ
Created attachment 1190166 [details] File: exploitable
Created attachment 1190167 [details] File: limits
Created attachment 1190168 [details] File: maps
Created attachment 1190169 [details] File: mountinfo
Created attachment 1190170 [details] File: namespaces
Created attachment 1190171 [details] File: open_fds
Created attachment 1190172 [details] File: proc_pid_status
Created attachment 1190173 [details] File: var_log_messages
I'm gonna at least propose this as an Alpha blocker. Not absolutely sure if it needs to be, but we should at least consider it. Criterion is "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain." - post-install works fine with updates-testing packages, but this bug affects install time (kickstart) enrolment; the enrolment works, but the crash seems to result in the installed system not "respect[ing] the identity, authentication and access control configuration provided by the domain."
Could you also attach coredump?
It is fixed in upstream by commit b5f61f8963300c9ba011436f234e9e10224aff6d But It was just a band aid because the previous reporter was not able to reproduce the crash. Is there a simple way how to run the openqa test in local environment?
unfortunately not really. The test basically sets up a system - 'ipa001.domain.local' with static IP 10.0.2.100 - as a FreeIPA server using rolectl, adds a couple of users, and sets up a one-time password for enrolment of a client: ipa host-add client001.domain.local --password=monkeys --force the client install part of the test runs an install from the Server DVD with this kickstart: install cdrom bootloader --location=mbr network --device=link --activate --bootproto=static --ip=10.0.2.101 --netmask=255.255.255.0 --gateway=10.0.2.2 --hostname=client001.domain.local --nameserver=10.0.2.100 lang en_US.UTF-8 keyboard us timezone --utc America/New_York clearpart --all autopart %packages @^server-product-environment %end rootpw anaconda reboot realm join --one-time-password=monkeys ipa001.domain.local then boots the installed system. From the logs the crash happens just at the end of client system boot, before any login or other action is done; trying to log into the client as one of the users created on the server fails. I'll add the coredump.
Created attachment 1190442 [details] coredump
Lukas: can we please get a Fedora build with the band-aid applied? Alpha go/no-go is on Thursday so we are working to a tight deadline here. Thanks!
sssd-1.14.0-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-97debec731
Discussed during the 2016-08-15 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made as this appears to violate "It must be possible to join the system to a FreeIPA or Active Directory domain at install time and post-install, and the system must respect the identity, authentication and access control configuration provided by the domain." adamw plans to perform some more testing concerning this bug to ensure it is as reported. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-08-15/f25-blocker-review.2016-08-15-16.00.txt
sssd-1.14.0-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-97debec731
Good news - the update does stop the crash. Bad news - login still doesn't work :( These are the errors from the journal: Aug 16 10:00:31 client001.domain.local login[1228]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty3 ruser= rhost= user=test1 Aug 16 10:00:31 client001.domain.local login[1228]: pam_sss(login:auth): received for user test1: 4 (System error) Aug 16 10:00:31 client001.domain.local login[1228]: FAILED LOGIN 1 FROM tty3 FOR test1, Authentication failure I'll see if I can enable debugging and get relevant logs from server and client...
So I wound up reporting the login issue separately: https://bugzilla.redhat.com/show_bug.cgi?id=1367604 and then, found out it seems to be caused by issues in anaconda dealing with the system time and timezones: https://bugzilla.redhat.com/show_bug.cgi?id=1367647 Given that, I'm gonna remove the accepted blocker status from this bug, as we don't know that the crash actually has significant consequences. I will try if I can in the next day or two to test and see what happens if we fix the time issue but do *not* fix the crash. I'm also gonna nominate it for a freeze exception, because it probably makes sense to fix this crash even if it doesn't *seem* to cause immediately obvious terrible consequences (and thus doesn't count as a blocker).
Discussed at 2016-08-18 go/no-go meeting, functioning as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting/2016-08-18/f25-alpha-go_no_go-meeting.2016-08-18-17.00.html . We agreed to delay the decision on blocker status as we are not sure what the practical consequences of the crash are yet, but we agreed a crash in sssd like this is at least serious enough to warrant a freeze exception (especially given the fix is pretty demonstrably safe). If necessary I will test and see what happens when the other bug is fixed, but this one is not.
Fixed version should be already in stable. https://bodhi.fedoraproject.org/updates/FEDORA-2016-97debec731
No it isn't, because we're frozen. All pushes during freezes are manual and have to be co-ordinated between QA and releng. I'm taking care of it.
sssd-1.14.0-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Adam Williamson from comment #27) > No it isn't, because we're frozen. All pushes during freezes are manual and > have to be co-ordinated between QA and releng. I'm taking care of it. Thank you for info