[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4

2018-04-03 Thread Lachlan Musicman
On 4 April 2018 at 09:46, Lachlan Musicman  wrote:

> On 3 April 2018 at 20:15, Jakub Hrozek  wrote:
>
>>
>> > fails with the same errors as reported initially. So running manually
>> in interactive mode works, but starting via systemctl doesn’t
>>
>> One difference I can think of between running the deamon on the
>> foreground versus running as a service is SELinux context. Did you check if
>> maybe there are some AVC denials if you run sssd as a service?
>>
>
>
> I'll check the denials - I'm not fully up to speed on AVC denials and
> selinux, but some googling suggested this command
>
> # ausearch -m avc -c sssd
> 
>

I noticed about an hour ago that the SSSD 1.16 COPR had been updated
earlier this AM. I resync'd our repos and have updated to 1.16.1_2 and
everything is working fine now.

Cheers
L.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4

2018-04-03 Thread Lachlan Musicman
On 3 April 2018 at 20:15, Jakub Hrozek  wrote:

>
>
> > On 3 Apr 2018, at 02:24, Lachlan Musicman  wrote:
> >
> > On 3 April 2018 at 08:23, Lachlan Musicman  wrote:
> > On 29 March 2018 at 20:23, Valentin Fischer 
> wrote:
> > Permission issue.
> >
> > Reinstall sssd-common
> > https://lists.fedorahosted.org/archives/list/sssd-users@list
> s.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/
> >
> >
> > fails with the same errors as reported initially. So running manually in
> interactive mode works, but starting via systemctl doesn’t
>
> One difference I can think of between running the deamon on the foreground
> versus running as a service is SELinux context. Did you check if maybe
> there are some AVC denials if you run sssd as a service?
>


I'll check the denials - I'm not fully up to speed on AVC denials and
selinux, but some googling suggested this command

# ausearch -m avc -c sssd



Here's the sssd config

[domain/unixdev.mycompany.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = unixdev.mycompany.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = vmts-linuxclient1.unixdev.mycompany.com
chpass_provider = ipa
ipa_server = _srv_, vmdv-linuxidm1.unixdev.mycompany.com
ldap_tls_cacert = /etc/ipa/ca.crt
selinux_provider = none
krb5_auth_timeout = 15
debug_level = 7

[domain/unixdev.mycompany.com/mycompany.com]
use_fully_qualified_names = False

[sssd]
config_file_version = 2
services = nss, sudo, pam, ssh
domains = unixdev.mycompany.com
debug_level = 7
domain_resolution_order = unix.mycompany.com,mycompany.com
full_name_format = %1$s

[nss]
homedir_substring = /home
memcache_timeout = 800
debug_level = 7
enum_cache_timeout = 240
entry_cache_nowait_percentage = 75

[pam]
pam_id_timeout = 15
debug_level = 7

[ssh]
debug_level = 7
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4

2018-04-03 Thread Lachlan Musicman
On 3 April 2018 at 20:15, Jakub Hrozek  wrote:
> On 29 March 2018 at 20:23, Valentin Fischer 
wrote:

> > Permission issue.
> >
> > Reinstall sssd-common
> >
> > I tried this on two different machines an it didn't work on either. Am
> getting identical output.>
> >
> > I found this old thread
> >
> > https://lists.fedorahosted.org/archives/list/sssd-users@
> lists.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/
> >
> > I tried running
> >
> > sssd -i -d9
> >
> > and it works fine, the /var/lib/sss/pipes have returned (I deleted them,
> reinstalled sssd-common, they weren't replaced), and I can login
> successfully.
> >
> > So it's just running
> >
> > systemctl start sssd
> > or
> > systemctl restart sssd
> >
> > fails with the same errors as reported initially. So running manually in
> interactive mode works, but starting via systemctl doesn’t
>
> One difference I can think of between running the deamon on the foreground
> versus running as a service is SELinux context. Did you check if maybe
> there are some AVC denials if you run sssd as a service?
>
>
I checked that too. SELinux is disabled and has been since installation.

Cheers
L.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org


[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4

2018-04-03 Thread Jakub Hrozek


> On 3 Apr 2018, at 02:24, Lachlan Musicman  wrote:
> 
> On 3 April 2018 at 08:23, Lachlan Musicman  wrote:
> On 29 March 2018 at 20:23, Valentin Fischer  wrote:
> Permission issue.
> 
> Reinstall sssd-common
> 
> 
> 
> I tried this on two different machines an it didn't work on either. Am 
> getting identical output.
> 
> 
> I found this old thread
> 
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/
> 
> I tried running 
> 
> sssd -i -d9 
> 
> and it works fine, the /var/lib/sss/pipes have returned (I deleted them, 
> reinstalled sssd-common, they weren't replaced), and I can login successfully.
> 
> So it's just running 
> 
> systemctl start sssd
> or
> systemctl restart sssd
> 
> fails with the same errors as reported initially. So running manually in 
> interactive mode works, but starting via systemctl doesn’t

One difference I can think of between running the deamon on the foreground 
versus running as a service is SELinux context. Did you check if maybe there 
are some AVC denials if you run sssd as a service?

> .
> 

> I can't apply the update to production in that state, but if you want any 
> more logs or testing done, let me know.
> 
> Here are the permissions on the file system (I've not changed them by hand), 
> but they look the same as a working 1.16.0_4 sssd installation.
> 
> [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/
> total 8
> drwxr-xr-x.  3 sssd sssd   71 Apr  3 10:11 .
> drwxr-xr-x. 10 root root 4096 Mar 29 03:01 ..
> srw-rw-rw-   1 root root0 Apr  3 10:11 nss
> srw-rw-rw-   1 root root0 Apr  3 10:11 pac
> srw-rw-rw-   1 root root0 Apr  3 10:11 pam
> drwxr-x---.  2 sssd root 4096 Apr  3 10:11 private
> srw-rw-rw-   1 root root0 Apr  3 10:11 ssh
> srw-rw-rw-   1 root root0 Apr  3 10:11 sudo
> [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/private/
> total 4
> drwxr-x---. 2 sssd root 4096 Apr  3 10:11 .
> drwxr-xr-x. 3 sssd sssd   71 Apr  3 10:11 ..
> srw---  1 root root0 Apr  3 10:11 pam
> lrwxrwxrwx  1 root root   63 Apr  3 10:11 sbus-dp_mycompany.com -> 
> /var/lib/sss/pipes/private/sbus-dp_mycompany.com.3913
> srw---  1 root root0 Apr  3 10:11 sbus-dp_mycompany.com.3913
> srw---  1 root root0 Apr  3 10:11 sbus-monitor
> 
> 
> Cheers
> L.
> 
> 
> 
>  
>  
> On Thu 29. Mar 2018 at 00:20, Lachlan Musicman  wrote:
> Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't 
> restart.
> 
> ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) 
> 
> The journalctl -xe shows:
> 
> -- Unit sssd.service has begun starting up.
> Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up
> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service: 
> main process exited, code=exited, status=3/NOTIMPLEMENTED
> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to start 
> System Security Services Daemon.
> -- Subject: Unit sssd.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 
> 
> The /var/log/sssd/sssd.log shows
> 
> 
> (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: 
> /var/lib/sss/db/config.ldb
> (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch 
> for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
> function resolv_conf_inotify_cb after delay 1.0
> (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): Using 
> re 
> [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))].
> (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq 
> format [%1$s].
> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB 
> File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): 
> Timestamp file for unixdev.company.com: 
> /var/lib/sss/db/timestamps_unixdev.company.com.ldb
> (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register 
> control with rootdse!
> (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): 
> dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, 
> message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": 
> Permission denied)
> (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: 
> /var/lib/sss/db/config.ldb
> (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch 
> for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using 
> function resolv_conf_inotify_cb after delay 1.0
> (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): Using 
> re 
> [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))].
> (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq 
> format [%1$s].
> (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0