Hide Forgot
Description of problem: authconfig fails to update /etc/sssd/sssd.conf if no domains are currently listed. End result is sssd fails to start with a 'no domains' error. Version-Release number of selected component (if applicable): RHEL6.0 with authconfig-gtk-6.1.4-6.el6.x86_64 installed. How reproducible: RHEL6.0 desktop at Baker Street RH300 course had it reproducable every time. Steps to Reproduce: 1. Clean RHEL6 install with no config outside of files in place. 2. Run authconfig with the appropriate arguments eg: authconfig --updateall --enablesssd --enablesssdauth --enablecachecreds --enableldap --ldapserver=instructor.example.com --enableldaptls --ldaploadcacert=ftp://instructor.example.com/pub/EXAMPLE-CA-CERT --enablekrb5 --krb5kdc=instructor.example.com --krb5adminserver=instructor.example.com 3. Note SSSD service fails to start with no domains error. 4. add domains = default to /etc/sssd/sssd.conf 5. Re-run the authconfig command and watch it all work. Actual results: SSSD fails to start with no domains in config error. Expected results: SSSD starts and authentication using it is possible. Additional info: With no domains = line a [domain/default] block does not even get created. This problem does not appear to occur when using the GUI tool. --update rather than --updateall also appears to work fine.
The --enablesssd and --enablesssdauth must not be used if you want authconfig to set up the SSSD domain. It will enable it implicitly if the configuration is supportable (--enableldap + --enablekrb5 is).
Ah I see.... On the course it was thought it should work and was advised to raise a ticket for it... Reading the man page I can see that it says that... but it feels 'wrong' that telling the tool "yes I definately want to use SSSD" skips updating the SSSD config and that --update verses --updateall showed different behaviour in that perspective. Thanks for the quick response Tomas - will have to remember not to use the --*sssd* options on the test day ;)