Bug 697644 - change authconfig sssd domain name to ac-configured
change authconfig sssd domain name to ac-configured
Product: Fedora
Classification: Fedora
Component: authconfig (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2011-04-18 16:04 EDT by Andrew McNabb
Modified: 2011-09-08 04:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 697893 (view as bug list)
Last Closed: 2011-09-08 04:33:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andrew McNabb 2011-04-18 16:04:12 EDT
In retrospect, it seems reasonable that authconfig would need to write to sssd.conf.  Unfortunately, sssd.conf does not have a big banner at the top warning that the file will be overwritten.  It would be very helpful if there were such a warning and if it gave a clear description of where and how users are intended to make custom settings if needed.
Comment 1 Tomas Mraz 2011-04-19 02:41:04 EDT
Given authconfig uses the SSSD config API, what would be the best way to add this comment to sssd.conf? I suppose the config API itself does not have calls for adding comments. Perhaps it should be added to the default config file in the sssd package?
Comment 2 Stephen Gallagher 2011-04-19 09:46:07 EDT
Maybe we should rename the "default" domain to "default-ac" or "authconfig" domain. That should make it clear.

The idea is that if a customer wants to create a custom domain, they should do so by changing the domain name.

We thought "default" would be sufficient, but now I'm thinking it would make more sense if we used a less-ambiguous name.

Additionally, I think you're right that we should add a new config option "description" that has no purpose in the SSSD itself, but could be used by authconfig to add a notice that the domain was autoconfigured and could be changed by subsequent executions of authconfig.

This would be better than changing the default config file. I've actually been thinking about renaming the default config file to sssd-example.conf so that SSSD doesn't try to use it (since it intentionally doesn't work out of the box anyway). The SSSDConfig API (and by extension, authconfig) can create an empty file trivially.

Tomas, please use this BZ to track changing the default domain name to something more clear, and then please clone this ticket against the SSSD for me to add the 'description' option and change the example config name.
Comment 3 Andrew McNabb 2011-04-19 12:26:12 EDT
Unfortunately, authconfig can add a default domain that is very similar a pre-existing custom domain.  For example, after running authconfig, I had to remove the "default" domain and restart sssd.  I think there needs to be a warning message so that people know that the file might get modified.
Comment 4 Tomas Mraz 2011-04-20 08:58:44 EDT
But if you do not want to use authconfig for configuring sssd.conf at all, just use 'authconfig --enablesssd --enablesssdauth --update'.
This will make it to enable it explicitly in system-auth and nsswitch.conf but it will not try to configure domains in sssd.conf.

This is described in 'man authconfig'.
Comment 5 Andrew McNabb 2011-04-20 13:21:40 EDT
Unfortunately, to get authconfig to write out the ecryptfs-related pam configuration, the recommended solution is to add "USEECRYPTFS=yes" to /etc/sysconfig/authconfig and run "authconfig-tui --updateall":


There may be other features that require this as well.  I'm not aware of a "--updatepam" option or anything like that.  Of course, it's possible that there is some other combination of settings that would make "--updateall" work without rewriting sssd config files, but if I had known to expect it, I wouldn't have been very bothered.
Comment 6 Tomas Mraz 2011-09-08 04:33:55 EDT
I've decided to not change this as this brings only a very little improvement but it has potential for breaking existing user configurations and expectations. The 'default' name is there for many Fedora releases and also in RHEL-6 so it should be now quite firmly established.

Note You need to log in before you can comment on or make changes to this bug.