-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Recently there has been a lot of activity in Trac surrounding our support for invoking the legacy shadow-utils tools for managing legacy files-based domains. This has raised some questions over the utility of this feature.
First of all, there is an unreasonable amount of code implemented to handle the logic of determining into which domain we're attempting to add a user.
Secondly, the legacy local users (provider=files) is the only non-native backend that we're providing any special handling for. I'm not sure I see the utility in exerting so much effort supporting a configuration we hope to be phasing out.
So my proposal is to have the sss_* tools support only the native local domain in the SSSD (provider=local). By extension, I also propose that we mandate that a valid config must have exactly one provider=local domain (it can hold whatever name the administrator desires, but it should always be there). There should never be more than one, as that doesn't really make sense and would similarly introduce the complexity of adding users to the domains.
In summary, I feel that the sssd commandline user and group tools should manipulate only the SSSD native local users and groups, and all configurations of the SSSD need to ensure that a native local domain is present.
Please raise questions and comments in reply to this message.
- -- Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Recently there has been a lot of activity in Trac surrounding our support for invoking the legacy shadow-utils tools for managing legacy files-based domains. This has raised some questions over the utility of this feature.
First of all, there is an unreasonable amount of code implemented to handle the logic of determining into which domain we're attempting to add a user.
Secondly, the legacy local users (provider=files) is the only non-native backend that we're providing any special handling for. I'm not sure I see the utility in exerting so much effort supporting a configuration we hope to be phasing out.
So my proposal is to have the sss_* tools support only the native local domain in the SSSD (provider=local). By extension, I also propose that we mandate that a valid config must have exactly one provider=local domain (it can hold whatever name the administrator desires, but it should always be there). There should never be more than one, as that doesn't really make sense and would similarly introduce the complexity of adding users to the domains.
In summary, I feel that the sssd commandline user and group tools should manipulate only the SSSD native local users and groups, and all configurations of the SSSD need to ensure that a native local domain is present.
Please raise questions and comments in reply to this message.
+1 And provide a tool to migrate legacy local users and groups to the local domain.
Stephen Gallagher RHCE 804006346421761
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkqJpmEACgkQeiVVYja6o6OvHwCgpc6NLUlgj+jFHWTWbpMOj4e4 ilwAn3xDugbXQv71sH14WcSK0PwCUEh2 =6L5u -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/17/2009 08:50 PM, Stephen Gallagher wrote:
Recently there has been a lot of activity in Trac surrounding our support for invoking the legacy shadow-utils tools for managing legacy files-based domains. This has raised some questions over the utility of this feature.
First of all, there is an unreasonable amount of code implemented to handle the logic of determining into which domain we're attempting to add a user.
Secondly, the legacy local users (provider=files) is the only non-native backend that we're providing any special handling for. I'm not sure I see the utility in exerting so much effort supporting a configuration we hope to be phasing out.
So my proposal is to have the sss_* tools support only the native local domain in the SSSD (provider=local).
As the one who implemented most of this feature, I mostly agree..as could be seen from Jenny's testing, there's many corner cases to cover, and therefore many bugs and many headaches and quite a lot of time spent on this feature, compared to its usefulness.
But I kinda see the value in providing "one tool to rule them all", even after we set sssd as default, some people will probably let their existing accounts live in /etc/passwd and not having to think about which tool to use to manage Joe Schmoe's account might be a plus..
By extension, I also propose that we mandate that a valid config must have exactly one provider=local domain (it can hold whatever name the administrator desires, but it should always be there). There should never be more than one, as that doesn't really make sense and would similarly introduce the complexity of adding users to the domains.
What about LDAP-only systems? For example, I only want to allow logins from LDAP and local root for maintenance..local wouldn't be needed in this case since we won't handle root in local anyway, right?
I agree that there shouldn't be more than one.
Jakub
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Jenny Galipeau -
Stephen Gallagher