Issue #7241 has been updated by John Bollinger.
Nigel Kersten wrote:
> It's very difficult right now to express declarative statements like:
>
> * Ensure this user is not in this group, leave it alone otherwise
> * Ensure this user is in this group without defining the user, leave it
> alone otherwise.
>
> I propose that we move group membership to a type of its own. That would also
> allow us to abstract away the differences between different platforms, some
> of which consider membership to be an attribute of the group, some of which
> consider it to be an attribute of the user.
>
> It would allow us to remove all the "authoritative" settings for user/group
> membership, as they would move to this type instead.
I'm not very comfortable with this. I do agree that it would be useful to
abstract away operating system differences, but I don't see why it is necessary
to introduce a new resource type to do so. Why can the User and / or Group
providers not be made smarter instead? Just choose one of those resource types
as the Puppet-level locus for managing group membership. This is more or less
the standard Puppet approach: system differences are accommodated at the
provider level.
As for ensuring group non-membership, that can be accomplished by adding a
parameter to (say) User. For example:
user { "untrusted":
excluded_groups => [ 'extra_privileged' ]
}
Providers must of course do the right thing with that, but that's no harder
than the problem that a Groupmembership provider would face.
And as for managing group membership without managing the users involved:
1. I'm not very keen on the concept in the first place. Moreover, such a
feature would be meaningless if one were able to manage a User's groups as its
only managed attributes (as in the above example).
2. It could nevertheless be accomplished by making Group the Puppet locus for
managing group membership on all systems (but see below).
3. For systems with the concept of a primary group for each user (i.e. most of
those on which Puppet currently runs), membership in a primary group is not
comparable to membership in a secondary group. On such systems, group
membership cannot be managed independently of users in a consistent manner.
For example, what happens if one attempts to ensure a user not a member of his
primary group?
Overall, I think the underlying issue is an old one: whether group membership
is an attribute of users or of groups. In an abstract sense it is both, which
is the root of the problem. Elevating group membership to its own type does
not solve that problem; instead, it complicates it further.
----------------------------------------
Feature #7241: Group membership should be a type of its own.
https://projects.puppetlabs.com/issues/7241
Author: Nigel Kersten
Status: Accepted
Priority: Normal
Assignee:
Category:
Target version: Telly
Affected Puppet version:
Keywords:
Branch:
It's very difficult right now to express declarative statements like:
* Ensure this user is not in this group, leave it alone otherwise
* Ensure this user is in this group without defining the user, leave it alone
otherwise.
I propose that we move group membership to a type of its own. That would also
allow us to abstract away the differences between different platforms, some of
which consider membership to be an attribute of the group, some of which
consider it to be an attribute of the user.
It would allow us to remove all the "authoritative" settings for user/group
membership, as they would move to this type instead.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
