You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SSSD should be enhanced so that it's capable of managing local users.
Architecturally, the UNIX files would be treated as the authoritative data store, much like we treat LDAP normally, with the local cache augmenting the files with extra data.
The database that stores the augmented data must not be called 'cache' and should reside in a different directory.
One question that is left a bit undecided at this time is which accounts should be marked as system accounts. The current proposal was that all accounts that were created directly with the files (and not utilities like libuser) would be system accounts. The utilities could create both account types.
milestone: NEEDS_TRIAGE => SSSD 1.13 beta
rhbz: => todo
summary: RFE: Manage local users => [RFE] Manage local users from /etc/passwd and account service
While the design page explicitly talks about synchronization, JanP suggested to add an option where sssd database would be the one and sole owner of the data and /etc/passwd would only contain:
# do not edit this file, see man sssd-passwd(1)
This won't be the default, but should be included as an alternative.
This is out of scope for 1.14, unfortunately. Moving to 1.15.
The good news is that we had another face-to-face meeting during the devconf.cz conference and now we now exactly what to do. This is a target for the Fedora-25 distro release.
Please note that the files provider that mirrors the contents of /etc/passwd and /etc/group is already developed and shipped since Fedora-26. This ticket now tracks implementing the writable interface and implementing the accountsService interface so we can obsolete accountsService.
(On a tangent, this was expressed with the blocked/blocking tickets, but pagure handles them in a strange way, so I just removed all the blocks..)
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/2228
The SSSD should be enhanced so that it's capable of managing local users.
Architecturally, the UNIX files would be treated as the authoritative data store, much like we treat LDAP normally, with the local cache augmenting the files with extra data.
The database that stores the augmented data must not be called 'cache' and should reside in a different directory.
One question that is left a bit undecided at this time is which accounts should be marked as system accounts. The current proposal was that all accounts that were created directly with the files (and not utilities like libuser) would be system accounts. The utilities could create both account types.
Comments
Comment from jhrozek at 2014-02-06 17:26:13
See https://fedorahosted.org/sssd/wiki/DesignDocs/AccountsService for more details.
blockedby: => 2229
Comment from jhrozek at 2014-02-13 10:30:20
Fields changed
blockedby: 2229 => 2229,2244
Comment from jhrozek at 2014-02-13 10:30:42
Fields changed
blockedby: 2229,2244 => 2229,2244,2227
Comment from jhrozek at 2014-02-13 10:31:11
Fields changed
blockedby: 2229,2244,2227 => 2229,2244,2227,843,1126
Comment from dpal at 2014-02-13 15:38:03
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.13 beta
rhbz: => todo
summary: RFE: Manage local users => [RFE] Manage local users from /etc/passwd and account service
Comment from jhrozek at 2014-09-23 13:44:33
While the design page explicitly talks about synchronization, JanP suggested to add an option where sssd database would be the one and sole owner of the data and /etc/passwd would only contain:
This won't be the default, but should be included as an alternative.
Comment from adelton at 2014-09-23 14:01:50
Fields changed
cc: => jpazdziora@redhat.com
Comment from dpal at 2014-09-26 18:27:44
Fields changed
mark: => 1
Comment from jhrozek at 2015-02-10 15:23:47
We need to start on this effort already..
priority: major => critical
Comment from jhrozek at 2015-02-10 17:28:35
Fields changed
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
Comment from jhrozek at 2015-02-12 20:17:42
We should start working on individual pieces after downstream requirements for 1.13 are met, but won't make 1.13, sorry.
milestone: SSSD 1.13 backlog => SSSD 1.14 beta
priority: critical => blocker
Comment from jhrozek at 2016-02-16 11:40:21
This is out of scope for 1.14, unfortunately. Moving to 1.15.
The good news is that we had another face-to-face meeting during the devconf.cz conference and now we now exactly what to do. This is a target for the Fedora-25 distro release.
milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0
Comment from jhrozek at 2016-06-23 16:56:34
Fields changed
milestone: SSSD 1.16 beta => SSSD 1.15 Beta
Comment from jhrozek at 2016-11-21 15:54:32
Fields changed
blockedby: 2229,2244,2227,843,1126 => 2229,2244,2227,843,1126,3242
Comment from jhrozek at 2016-12-08 10:08:32
Fields changed
blockedby: 2229,2244,2227,843,1126,3242 => 2229,2244,2227,843,1126,3242,3262
Comment from jhrozek at 2017-02-24 14:50:21
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-03-31 18:10:39
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-03-31 18:14:53
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-03-31 18:17:04
Please note that the files provider that mirrors the contents of /etc/passwd and /etc/group is already developed and shipped since Fedora-26. This ticket now tracks implementing the writable interface and implementing the accountsService interface so we can obsolete accountsService.
(On a tangent, this was expressed with the blocked/blocking tickets, but pagure handles them in a strange way, so I just removed all the blocks..)
Comment from jhrozek at 2017-03-31 18:17:08
Metadata Update from @jhrozek:
Comment from lslebodn at 2017-03-31 18:21:33
Could you elaborate? Because bug with dependencies should be fixed.
Comment from lslebodn at 2017-03-31 18:21:40
Metadata Update from @lslebodn:
Comment from jhrozek at 2017-04-21 09:33:42
Metadata Update from @jhrozek:
Comment from jhrozek at 2017-09-05 11:52:16
Metadata Update from @jhrozek:
Comment from jhrozek at 2018-03-19 21:35:31
Metadata Update from @jhrozek:
Comment from jhrozek at 2018-03-20 13:51:49
Metadata Update from @jhrozek:
Comment from jhrozek at 2018-08-13 11:11:53
Metadata Update from @jhrozek:
Comment from jhrozek at 2019-02-22 15:53:43
Metadata Update from @jhrozek:
Comment from jhrozek at 2019-06-13 23:26:23
Metadata Update from @jhrozek:
Comment from thalman at 2020-03-11 11:49:41
Metadata Update from @thalman:
Comment from pbrezina at 2020-03-24 14:11:10
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Comment from pbrezina at 2020-03-24 14:11:12
Metadata Update from @pbrezina:
The text was updated successfully, but these errors were encountered: