Hi,
not sure if a bug or not but a quick warning that hopefully may save someone some time! We use puppet to install sssd based on a condition. we: - yum install -y sssd - authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldapauth --enablemkhomedir --enablecachecreds --update ( to setup PAM and nsswitch - not sure if ALL of these are necessary? ) - copy over our private config ( as you can't do all of the config with authconfig that i can see? )
This didn't work - intermittently sssd was using a 'stale' config. After much headbutting issue was twofold: - sssd is started and activated by the authconfig command, this creates config.ldb and cache_default.ldb - puppet writes the config file immediately and sssd restarted - sssd compares modification time of /etc/sssd/sssd.conf with /var/lib/sss/db/config.ldb and, because the times are the same ( written in the same minute ), IT IGNORES the new config file
Solution: - add a '--nostart' to the authconfig to stop the initial start, this will prevent creation of the cache. Copy over the config and then start/enable ( which will create the cache ).
Not sure if related but there is a TODO in the code around this area (src/confdb/confdb_setup.c) ret = sss_ini_get_mtime(init_data, sizeof(timestr), timestr); if (ret <= 0 || ret >= (int)sizeof(timestr)) { DEBUG(SSSDBG_FATAL_FAILURE, "Failed to convert time_t to string ??\n"); ret = errno ? errno : EFAULT; }
/* FIXME: Determine if the conf file or any snippet has changed * since we last updated the confdb or if some snippet was * added or removed. */
Puppet then
On (27/10/16 05:04), Daniel Hermans wrote:
Hi,
not sure if a bug or not but a quick warning that hopefully may save someone some time! We use puppet to install sssd based on a condition. we:
- yum install -y sssd
- authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldapauth --enablemkhomedir --enablecachecreds --update ( to setup PAM and nsswitch - not sure if ALL of these are necessary? )
- copy over our private config ( as you can't do all of the config with authconfig that i can see? )
This didn't work - intermittently sssd was using a 'stale' config. After much headbutting issue was twofold:
- sssd is started and activated by the authconfig command, this creates config.ldb and cache_default.ldb
- puppet writes the config file immediately and sssd restarted
- sssd compares modification time of /etc/sssd/sssd.conf with /var/lib/sss/db/config.ldb and, because the times are the same ( written in the same minute ), IT IGNORES the new config file
It is not about the same minute but about the same second.
If puppet creates sssd.config then I think it will be the best to change authconfig options. Because it does not make a sense to generate sssd.conf by authconfig in your case.
IIRC sssd config is generated with reduced combination of options It isn't required to use ldap related options together with sssd --enablesssd --enablesssdauth --enableldap --enableldapauth
You can also remove --enablecachecreds because you can configure it ssd.conf itself which is created by puppet.
Could you try to run following comman on new machine? authconfig --enablesssd --enablesssdauth \ --enablelocauthorize --enablemkhomedir \ --update
LS
On Thu, Oct 27, 2016 at 09:31:42AM +0200, Lukas Slebodnik wrote:
On (27/10/16 05:04), Daniel Hermans wrote:
Hi,
not sure if a bug or not but a quick warning that hopefully may save someone some time! We use puppet to install sssd based on a condition. we:
- yum install -y sssd
- authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldapauth --enablemkhomedir --enablecachecreds --update ( to setup PAM and nsswitch - not sure if ALL of these are necessary? )
- copy over our private config ( as you can't do all of the config with authconfig that i can see? )
This didn't work - intermittently sssd was using a 'stale' config. After much headbutting issue was twofold:
- sssd is started and activated by the authconfig command, this creates config.ldb and cache_default.ldb
- puppet writes the config file immediately and sssd restarted
- sssd compares modification time of /etc/sssd/sssd.conf with /var/lib/sss/db/config.ldb and, because the times are the same ( written in the same minute ), IT IGNORES the new config file
It is not about the same minute but about the same second.
Didn't we have a bug about this?
If puppet creates sssd.config then I think it will be the best to change authconfig options. Because it does not make a sense to generate sssd.conf by authconfig in your case.
IIRC sssd config is generated with reduced combination of options It isn't required to use ldap related options together with sssd --enablesssd --enablesssdauth --enableldap --enableldapauth
IIRC you don't need --enableldap and --enableldapauth since this would put the LDAP NSS and PAM modules to the respective stacks...
You can also remove --enablecachecreds because you can configure it ssd.conf itself which is created by puppet.
Could you try to run following comman on new machine? authconfig --enablesssd --enablesssdauth \ --enablelocauthorize --enablemkhomedir \ --update
LS _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Hi, Thanks for the response.
Yes as you predicted it also works perfectly if i: authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update --nostart [copy over full config] service sssd start ; chkconfig sssd on
Thankyou!!
I now have full LDAP auth against a domain that has no/inconsistent posix attributes ( using ldap_id_mapping = true )
only thing I had to do was use a GID override: override_gid = 10000
and add a manual group to /etc/group to stop this warning: id: cannot find name for group ID 200513
Any thoughts on this topic?
as I guess the
On Tue, Nov 08, 2016 at 12:17:59AM -0000, Daniel Hermans wrote:
Hi, Thanks for the response.
Yes as you predicted it also works perfectly if i: authconfig --enablesssd --enablesssdauth --enablelocauthorize --enablemkhomedir --update --nostart [copy over full config] service sssd start ; chkconfig sssd on
Thankyou!!
I now have full LDAP auth against a domain that has no/inconsistent posix attributes ( using ldap_id_mapping = true )
only thing I had to do was use a GID override: override_gid = 10000
and add a manual group to /etc/group to stop this warning: id: cannot find name for group ID 200513
Judging by the GID value ending with 513, your server is Active Directory. I wonder if your setup uses id_provider=ad with the (default) tokengroups settings? If yes, can you try if setting that to false makes a difference: ldap_use_tokengroups = false ?
Nonetheless, I think this is a bug, but I think trying the non-optimized LDAP path might work.
i'm using id_provider=ldap ( in fact everything id/auth/access are all ldap )
as 513 was obviously 'Domain Users' ( not sure where the '200' gets prefixed? ) I ended up adding local group 'domainusers' with gid = 200513
i suspect my group search base was too specific to pickup domain users ( trying to speed up 'id -a' i have a tighter group_search_base ) - it's a large domain and login can take 3-5 seconds to complete auth even with a more specific base
On Wed, Nov 09, 2016 at 06:44:25AM -0000, Daniel Hermans wrote:
i'm using id_provider=ldap ( in fact everything id/auth/access are all ldap )
Ah, then you alrady default to no token groups (unless you explicitly chose tokengroups to be enabled) and I suspect you hit a bug. You can file one on https://fedorahosted.org/sssd/newticket
as 513 was obviously 'Domain Users' ( not sure where the '200' gets prefixed? ) I ended up adding local group 'domainusers' with gid = 200513
I think this is the SSSD ID mapping picking up a range based on the domain SID.
i suspect my group search base was too specific to pickup domain users ( trying to speed up 'id -a' i have a tighter group_search_base ) - it's a large domain and login can take 3-5 seconds to complete auth even with a more specific base
You can also experiment with upgrading to 1.14.x which contains some performance enhancements, ignore_group_members or mounting the cache to tmpfs.
sssd-users@lists.fedorahosted.org
-
Daniel Hermans -
Jakub Hrozek -
Lukas Slebodnik