On 14 Mar 2018, at 20:14, Jim Richard <jrichard(a)placeiq.com>
I deployed a clean/new Fedora 27 minimal, installed ipa-client/sssd, we have sssd version
1.16.0-6.fc27 on that virtual machine now, and then enrolled the host in our FreeIPA.
Then I did a:
service sssd stop ; rm -rvf /var/lib/sss/db/* ; rm -rvf /var/lib/sss/mc/* ; rm -rvf
/var/log/sssd/* ; service sssd start
added log level 9 to all sections of the sssd config file
Ran my test and then tar'd up the sssd log files and attached them here.
I did look them over beforehand but I'm not seeing anything interesting that I would
recognize other than:
(Wed Mar 14 14:50:06 2018) [sssd[pam]] [pam_dp_process_reply] (0x0200): received: [4
There was a segfault coming from the selinux_child. We recently had a bug (fixed upstream
already) where the selinux_child would segfault on a system where SELinux was completely
disabled and also the selinux policy was not installed. Could it be your case?
If you don’t use the SELinux user context mapping feature, you can safely disable the
selinux provider by setting selinux_provider=none.
A little more background.
Of course we don't run Fedora in production, it's all CentOS, mostly 7 and some
6. And we use FreeIPA.
We use Rundeck (http://rundeck.org/
) for job scheduling and we have a few jobs that can,
if not properly scheduled, trigger multiple logins to the same host, by the same FreeIPA
user, at the same time.
This did not used to cause problems but unfortunately Puppet pushed out an update to sssd
to all of our CentOS nodes last Friday, March 9 and with this updated sssd version we
started seeing failures.
SYSTEM ADMINISTRATOR III
> On Mar 13, 2018, at 6:41 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
>> On 13 Mar 2018, at 04:44, Jim Richard <jrichard(a)placeiq.com> wrote:
>> result in:
>> pam_sss(sshd:account): Access denied for user rundeck: 4 (System error)
>> I know this has been an issue in the past per some info I see in places like:
>> any chance there's been a regression bringing this issue back?
> System Error is the default catch-all if SSSD can’t map some internal error onto a
more specific error code. A bit like an unhandled exception. You need to enable the debug
logs as per https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
and look into the
logs what’s going on.
>> Jim Richard
>> SYSTEM ADMINISTRATOR III
>> (646) 338-8905
>> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org