On 2014-12-03 22:42, Rob Reynolds wrote:
For the
other items, please create tickets (feel free to point back to this
discussion) and we can get them prioritized. Thanks!
You mean, like https://tickets.puppetlabs.com/browse/PUP-1298 back from
2013. Or
On Fri, Dec 5, 2014 at 7:07 AM, David Schmitt da...@dasz.at wrote:
On 2014-12-03 22:42, Rob Reynolds wrote:
For the
other items, please create tickets (feel free to point back to this
discussion) and we can get them prioritized. Thanks!
You mean, like
On Thu, Nov 27, 2014 at 2:06 AM, David Schmitt da...@dasz.at wrote:
On 2014-11-26 19:02, Rob Reynolds wrote:
Making a switch to non-authoritative would be in the realm of
possibility for Puppet 4 given the short timeline. I think the
group_membership resource type could be something that
On 2014-11-26 19:02, Rob Reynolds wrote:
Making a switch to non-authoritative would be in the realm of
possibility for Puppet 4 given the short timeline. I think the
group_membership resource type could be something that could be done at
any time, and then the other properties deprecated and
There's a patch for that.
https://github.com/onyxpoint/puppet-gpasswd/blob/master/lib/puppet/provider/group/gpasswd.rb
It was not included due to not wanting to increase the code in the core.
Trevor
On Thu, Nov 27, 2014 at 3:06 AM, David Schmitt da...@dasz.at wrote:
On 2014-11-26 19:02,
Awesome, thanks! That would have saved me a quite awkward moment at a
client. :-)
Regards, David
On 2014-11-27 16:08, Trevor Vaughan wrote:
There's a patch for that.
https://github.com/onyxpoint/puppet-gpasswd/blob/master/lib/puppet/provider/group/gpasswd.rb
It was not included due to
If you could make a push to get it into core, that would be great.
I didn't understand the argument for rejecting it, but made the module
anyway.
It's plug and play and works in both 2.7 and 3.X.
Trevor
On Thu, Nov 27, 2014 at 10:20 AM, David Schmitt da...@dasz.at wrote:
Awesome, thanks!
On Tue, Nov 25, 2014 at 6:31 PM, Nigel Kersten ni...@puppetlabs.com wrote:
On Mon, Nov 24, 2014 at 7:37 AM, John Bollinger john.bollin...@stjude.org
wrote:
On Friday, November 21, 2014 3:21:15 PM UTC-6, Rob Reynolds wrote:
When we originally set out to do PUP-2628[1] for Puppet 4, we
On Wednesday, November 26, 2014 12:03:09 PM UTC-6, Rob Reynolds wrote:
Making a switch to non-authoritative would be in the realm of possibility
for Puppet 4 given the short timeline. I think the group_membership
resource type could be something that could be done at any time, and then
On Mon, Nov 24, 2014 at 7:37 AM, John Bollinger john.bollin...@stjude.org
wrote:
On Friday, November 21, 2014 3:21:15 PM UTC-6, Rob Reynolds wrote:
When we originally set out to do PUP-2628[1] for Puppet 4, we were going
to change the group resource default to not authoritative for Windows
On Friday, November 21, 2014 3:21:15 PM UTC-6, Rob Reynolds wrote:
When we originally set out to do PUP-2628[1] for Puppet 4, we were going
to change the group resource default to not authoritative for Windows (e.g.
the specified members would be the minimum), because the thinking is that
On Monday, November 24, 2014 9:37:38 AM UTC-6, John Bollinger wrote:
purging. I think you still end up with a slightly leaky abstraction, in
that only some systems have a concept of users' primary group, but support
for that could and probably should be recast as a provider feature. On
On 11/24/2014 04:37 PM, John Bollinger wrote:
A (say) Group_membership resource type could allow group membership to
be expressed the same way for all systems, and it would dovetail
nicely with the new ideas for client-side queries and resource
purging. I think you still end up with a
13 matches
Mail list logo
