sssd 1.16.1 wont start, Centos 7.4

[Lachlan Musicman]

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<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^(a)\\]+)$))].
(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<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^(a)\\]+)$))].
(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] (0x0200): DB
File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
(Thu Mar 29 09:05:55 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:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register
control with rootdse!
(Thu Mar 29 09:05:55 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)


/var/lib/sss/pipes/private shows

drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
drwxr-xr-x. 3 sssd sssd   71 Mar 29 03:01 ..
srw-------  1 root root    0 Mar 19 09:21 pam
lrwxrwxrwx  1 root root   62 Mar 19 09:20 sbus-dp_unixdev.company.com ->
/var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
srw-------  1 root root    0 Sep 18  2017 sbus-dp_unixdev.company.com.732
srw-------  1 root root    0 Dec 28 09:47 sbus-dp_unixdev.company.com.746


It looks like there's some clean up that's not happening? I don't actually
know what sbus_dp files do, but the top result (pointing to .758) doesn't
exist...

How do I fix this?

Cheers
L.


------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857

[Valentin Fischer]

Permission issue.

Reinstall sssd-common

On Thu 29. Mar 2018 at 00:20, Lachlan Musicman <datakid(a)gmail.com&gt; 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&lt;domain&gt;[^\\]+)\\(?P&lt;name&gt;.+$))|((?P&lt;name&gt;[^@]+)@(?P&lt;domain&gt;.+$))|(^(?P&lt;name&gt;[^(a)\\]+)$))].
>  (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&lt;domain&gt;[^\\]+)\\(?P&lt;name&gt;.+$))|((?P&lt;name&gt;[^@]+)@(?P&lt;domain&gt;.+$))|(^(?P&lt;name&gt;[^(a)\\]+)$))].
>  (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] (0x0200):
>  DB File for unixdev.company.com:
>  /var/lib/sss/db/cache_unixdev.company.com.ldb
>  (Thu Mar 29 09:05:55 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:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register
>  control with rootdse!
>  (Thu Mar 29 09:05:55 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)
>
>
>  /var/lib/sss/pipes/private shows
>
>  drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
>  drwxr-xr-x. 3 sssd sssd   71 Mar 29 03:01 ..
>  srw-------  1 root root    0 Mar 19 09:21 pam
>  lrwxrwxrwx  1 root root   62 Mar 19 09:20 sbus-dp_unixdev.company.com ->
>  /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
>  srw-------  1 root root    0 Sep 18  2017 sbus-dp_unixdev.company.com.732
>  srw-------  1 root root    0 Dec 28 09:47 sbus-dp_unixdev.company.com.746
>
>
>  It looks like there's some clean up that's not happening? I don't actually
>  know what sbus_dp files do, but the top result (pointing to .758) doesn't
>  exist...
>
>  How do I fix this?
>
>  Cheers
>  L.
>
>
>  ------
>  "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic
>  civics is the insistence that we cannot ignore the truth, nor should we
>  panic about it. It is a shared consciousness that our institutions have
>  failed and our ecosystem is collapsing, yet we are still here — and we are
>  creative agents who can shape our destinies. Apocalyptic civics is the
>  conviction that the only way out is through, and the only way through is
>  together. "
>
>  *Greg Bloom* @greggish
>  https://twitter.com/greggish/status/873177525903609857
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>

[Lachlan Musicman]

On 29 March 2018 at 20:23, Valentin Fischer <valentin(a)servergeek.at&gt; wrote:

>  Permission issue.
>
>  Reinstall sssd-common
>
>  
I tried this on two different machines an it didn't work on either. Am
getting identical output.




>  On Thu 29. Mar 2018 at 00:20, Lachlan Musicman
> <datakid(a)gmail.com&gt; 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<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?
> > P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
> > (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<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?
> > P<domain>.+$))|(^(?P<name>[^@\\]+)$))].
> > (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] (0x0200):
> > DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.
> > company.com.ldb
> > (Thu Mar 29 09:05:55 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:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register
> > control with rootdse!
> > (Thu Mar 29 09:05:55 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)
> >
> >
> > /var/lib/sss/pipes/private shows
> >
> > drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
> > drwxr-xr-x. 3 sssd sssd   71 Mar 29 03:01 ..
> > srw-------  1 root root    0 Mar 19 09:21 pam
> > lrwxrwxrwx  1 root root   62 Mar 19 09:20 sbus-dp_unixdev.company.com ->
> > /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
> > srw-------  1 root root    0 Sep 18  2017 sbus-dp_unixdev.company.com.732
> > srw-------  1 root root    0 Dec 28 09:47 sbus-dp_unixdev.company.com.746
> >
> >
> > It looks like there's some clean up that's not happening? I don't
> > actually know what sbus_dp files do, but the top result (pointing to .758)
> > doesn't exist...
> >
> > How do I fix this?
> >
> > Cheers
> > L.
> >
> >
> > ------
> > "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic
> > civics is the insistence that we cannot ignore the truth, nor should we
> > panic about it. It is a shared consciousness that our institutions have
> > failed and our ecosystem is collapsing, yet we are still here — and we are
> > creative agents who can shape our destinies. Apocalyptic civics is the
> > conviction that the only way out is through, and the only way through is
> > together. "
> >
> > *Greg Bloom* @greggish https://twitter.com/greggish/
> > status/873177525903609857
> > _______________________________________________
> > 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
>
>

[Lachlan Musicman]

On 3 April 2018 at 08:23, Lachlan Musicman <datakid(a)gmail.com&gt; wrote:

>  On 29 March 2018 at 20:23, Valentin Fischer
> <valentin(a)servergeek.at&gt;
>  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/[e-mail]...

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.

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 root    0 Apr  3 10:11 nss
srw-rw-rw-   1 root root    0 Apr  3 10:11 pac
srw-rw-rw-   1 root root    0 Apr  3 10:11 pam
drwxr-x---.  2 sssd root 4096 Apr  3 10:11 private
srw-rw-rw-   1 root root    0 Apr  3 10:11 ssh
srw-rw-rw-   1 root root    0 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 root    0 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 root    0 Apr  3 10:11 sbus-dp_mycompany.com.3913
srw-------  1 root root    0 Apr  3 10:11 sbus-monitor


Cheers
L.





> > On Thu 29. Mar 2018 at 00:20, Lachlan Musicman <datakid(a)gmail.com&gt; 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<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<
> >> domain>.+$))|(^(?P<name>[^@\\]+)$))].
> >> (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_uni
> >> xdev.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<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<
> >> domain>.+$))|(^(?P<name>[^@\\]+)$))].
> >> (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] (0x0200):
> >> DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.
> >> company.com.ldb
> >> (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200):
> >> Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_uni
> >> xdev.company.com.ldb
> >> (Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to
> >> register control with rootdse!
> >> (Thu Mar 29 09:05:55 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)
> >>
> >>
> >> /var/lib/sss/pipes/private shows
> >>
> >> drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
> >> drwxr-xr-x. 3 sssd sssd   71 Mar 29 03:01 ..
> >> srw-------  1 root root    0 Mar 19 09:21 pam
> >> lrwxrwxrwx  1 root root   62 Mar 19 09:20 sbus-dp_unixdev.company.com
> >> -> /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
> >> srw-------  1 root root    0 Sep 18  2017 sbus-dp_unixdev.company.com.73
> >> 2
> >> srw-------  1 root root    0 Dec 28 09:47 sbus-dp_unixdev.company.com.74
> >> 6
> >>
> >>
> >> It looks like there's some clean up that's not happening? I don't
> >> actually know what sbus_dp files do, but the top result (pointing to .758)
> >> doesn't exist...
> >>
> >> How do I fix this?
> >>
> >> Cheers
> >> L.
> >>
> >>
> >> ------
> >> "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic
> >> civics is the insistence that we cannot ignore the truth, nor should we
> >> panic about it. It is a shared consciousness that our institutions have
> >> failed and our ecosystem is collapsing, yet we are still here — and we are
> >> creative agents who can shape our destinies. Apocalyptic civics is the
> >> conviction that the only way out is through, and the only way through is
> >> together. "
> >>
> >> *Greg Bloom* @greggish https://twitter.com/greggish/s
> >> tatus/873177525903609857
> >> _______________________________________________
> >> 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
> >
> >
>

[Jakub Hrozek]

>  On 3 Apr 2018, at 02:24, Lachlan Musicman <datakid(a)gmail.com&gt;
> wrote:
>  
>  On 3 April 2018 at 08:23, Lachlan Musicman <datakid(a)gmail.com&gt; wrote:
>  On 29 March 2018 at 20:23, Valentin Fischer <valentin(a)servergeek.at&gt; 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/[e-mail]...
>  
>  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 root    0 Apr  3 10:11 nss
>  srw-rw-rw-   1 root root    0 Apr  3 10:11 pac
>  srw-rw-rw-   1 root root    0 Apr  3 10:11 pam
>  drwxr-x---.  2 sssd root 4096 Apr  3 10:11 private
>  srw-rw-rw-   1 root root    0 Apr  3 10:11 ssh
>  srw-rw-rw-   1 root root    0 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 root    0 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 root    0 Apr  3 10:11 sbus-dp_mycompany.com.3913
>  srw-------  1 root root    0 Apr  3 10:11 sbus-monitor
>  
>  
>  Cheers
>  L.
>  
>  
>  
>   
>   
>  On Thu 29. Mar 2018 at 00:20, Lachlan Musicman <datakid(a)gmail.com&gt; 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&lt;domain&gt;[^\\]+)\\(?P&lt;name&gt;.+$))|((?P&lt;name&gt;[^@]+)@(?P&lt;domain&gt;.+$))|(^(?P&lt;name&gt;[^(a)\\]+)$))].
>  (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&lt;domain&gt;[^\\]+)\\(?P&lt;name&gt;.+$))|((?P&lt;name&gt;[^@]+)@(?P&lt;domain&gt;.+$))|(^(?P&lt;name&gt;[^(a)\\]+)$))].
>  (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] (0x0200): DB File for
> unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb
>  (Thu Mar 29 09:05:55 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:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register control with
> rootdse!
>  (Thu Mar 29 09:05:55 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)
>  
>  
>  /var/lib/sss/pipes/private shows
>  
>  drwxr-x---. 2 sssd root 4096 Mar 29 08:50 .
>  drwxr-xr-x. 3 sssd sssd   71 Mar 29 03:01 ..
>  srw-------  1 root root    0 Mar 19 09:21 pam
>  lrwxrwxrwx  1 root root   62 Mar 19 09:20 sbus-dp_unixdev.company.com ->
> /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758
>  srw-------  1 root root    0 Sep 18  2017 sbus-dp_unixdev.company.com.732
>  srw-------  1 root root    0 Dec 28 09:47 sbus-dp_unixdev.company.com.746
>  
>  
>  It looks like there's some clean up that's not happening? I don't actually
> know what sbus_dp files do, but the top result (pointing to .758) doesn't exist...
>  
>  How do I fix this?
>  
>  Cheers
>  L.
>  
>  
>  ------
>  "The antidote to apocalypticism is apocalyptic civics. Apocalyptic civics is the
> insistence that we cannot ignore the truth, nor should we panic about it. It is a shared
> consciousness that our institutions have failed and  our ecosystem is collapsing, yet we
> are still here — and we are creative agents who can shape our destinies. Apocalyptic
> civics is the conviction that the only way out is through, and the only way through is
> together. "
>  
>  Greg Bloom @greggish https://twitter.com/greggish/status/873177525903609857
>  _______________________________________________
>  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

[Lachlan Musicman]

On 3 April 2018 at 20:15, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:
>  On 29 March 2018 at 20:23, Valentin Fischer
> <valentin(a)servergeek.at&gt; 
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.

[Lachlan Musicman]

On 3 April 2018 at 20:15, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  > On 3 Apr 2018, at 02:24, Lachlan Musicman <datakid(a)gmail.com&gt; wrote:
>  >
>  > On 3 April 2018 at 08:23, Lachlan Musicman <datakid(a)gmail.com&gt; wrote:
>  > On 29 March 2018 at 20:23, Valentin Fischer <valentin(a)servergeek.at&gt;
>  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
<no matches>


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

[Lachlan Musicman]

On 4 April 2018 at 09:46, Lachlan Musicman <datakid(a)gmail.com&gt; wrote:

>  On 3 April 2018 at 20:15, Jakub Hrozek <jhrozek(a)redhat.com&gt;
> 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
>  <no matches>
>  
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.