> On 14 Mar 2018, at 20:14, Jim Richard <jrich...@placeiq.com> wrote:
> 
> Thanks.
> 
> 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 (System error)][placeiq.net]
> 

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.
> 
> 
> 
> 
> <sssd-logs.tar>
> 
> 
> 
>       Jim Richard                     
> SYSTEM ADMINISTRATOR III
> (646) 338-8905  
> 
> 
> 
>> On Mar 13, 2018, at 6:41 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>> 
>> 
>> 
>>> On 13 Mar 2018, at 04:44, Jim Richard <jrich...@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:
>>> https://access.redhat.com/solutions/1477473
>>> 
>>> 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@lists.fedorahosted.org
>>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
>> _______________________________________________
>> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> 
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

Reply via email to