After having put in no small amount of time in to trying to coerce
Puppet into managing some decentralized users, I''m starting to wonder
if it''s even possible. I have a network in which some user attributes
vary from node to node, such as UID, GID, and groups. However, short
of a truckload of inheritance (something that obviously doesn''t
scale), this doesn''t really seem to be something Puppet is capable
of. The inheritance I''m talking about is something like:
class node1users inherits virt_users {
# override UID''s/GID''s/groups/etc. specific to node1
}
class node2users inherits virt_users {
# override UID''s/GID''s/groups/etc. specific to node2
}
As you can see, this gets quite cumbersome as your node count
increases. Certainly, an already centralized directory service like
LDAP is preferred, or at the very least uniform attributes across
nodes. But, when neither is the case, you work with what you''ve got.
Alas, I think I may have found a somewhat elegant workaround - if it
works. But, testing it is a bit tough at the moment, so I''m hoping
some prying eyes might give it the vote of confidence. If this works,
I''m happy to submit it as a Puppet recipe. My idea is essentially to
have a custom fact that returns either the user''s UID/GID on that
particular node, or undef (in which case the next available UID/GID
will be assigned). Consider the following code snippets:
This custom fact will return the user''s current UID and pGID, or a
group''s GID. Or, it will return undef in the case that the user does
not exist, in which case the user will be assigned the next available
UID/GID:
File.open("/etc/passwd").each do |line|
gecos = line.split(/:/)
Facter.add("#{gecos[0]}_uid") do
setcode { gecos[2] }
end
Facter.add("#{gecos[0]}_pgid") do
setcode { gecos[3] }
end
end
File.open("/etc/group").each do |line|
gecos = line.split(/:/)
Facter.add("#{gecos[0]}_gid") do
setcode { gecos[2] }
end
end
I then need a way to look up the custom facts, which take on the form
"jsmith_uid", "jsmith_pgid", and "jsmith_gid".
This yields the
following function:
module Puppet::Parser::Functions
newfunction(:lookupvar, :type => :rvalue) do |args|
return args[0] if args[0]
end
end
Finally, the glue that puts it all together is the user declaration.
The UID and GID are never re-declared in the config; it''s always set
to return the value of the custom fact:
define account ( ensure, groups, shell, comment, provider directoryservice,
unixpw ) {
...snip...
@user { $name:
ensure => $ensure,
uid => lookupvar("${name}_uid"),
gid => lookupvar("${name}_pgid"),
groups => $supp_groups,
comment => $comment,
shell => $user_shell,
provider => $provider,
password => $unixpw;
}
...snip...
}
Is this a viable workaround to inconsistent user attributes in a
cluster? Votes for or against this?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
On Oct 21, 9:47 am, Ryan Steele <Ryan.G.Ste...@gmail.com> wrote:> > ...snip.. > > I then need a way to look up the custom facts, which take on the form > "jsmith_uid", "jsmith_pgid", and "jsmith_gid". This yields the > following function:Actually, this:> module Puppet::Parser::Functions > newfunction(:lookupvar, :type => :rvalue) do |args| > return args[0] if args[0] > end > endShould really read as follows: module Puppet::Parser::Functions newfunction(:lookupvar, :type => :rvalue) do |args| if args[0] return args[0] else return undef end end end The rest should all be correct, though. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
I see what you''re doing, but I question WHY? The amount of time you have spent troubleshooting this could have been better spent bringing up a small LDAP Directory that would both resolve these issues, work well with Puppet, and allow you a lot more flexibility in the future. On Oct 21, 9:55 am, Ryan Steele <Ryan.G.Ste...@gmail.com> wrote:> On Oct 21, 9:47 am, Ryan Steele <Ryan.G.Ste...@gmail.com> wrote: > > > > > ...snip.. > > > I then need a way to look up the custom facts, which take on the form > > "jsmith_uid", "jsmith_pgid", and "jsmith_gid". This yields the > > following function: > > Actually, this: > > > module Puppet::Parser::Functions > > newfunction(:lookupvar, :type => :rvalue) do |args| > > return args[0] if args[0] > > end > > end > > Should really read as follows: > > module Puppet::Parser::Functions > newfunction(:lookupvar, :type => :rvalue) do |args| > if args[0] > return args[0] > else > return undef > end > end > end > > The rest should all be correct, though.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Jeff Leggett wrote:> I see what you''re doing, but I question WHY? The amount of time you > have spent troubleshooting this could have been better spent bringing > up a small LDAP Directory that would both resolve these issues, work > well with Puppet, and allow you a lot more flexibility in the future. >While I agree that LDAP is the ideal solution (as I mentioned in the original post), that''s a separate issue on someone else''s plate and my design cannot assume a directory service that does not currently exist in that environment. Once it is in place, I will obviously modify the configs to accommodate that setup since Puppet, as you mentioned, works well with LDAP. So while I don''t disagree, I don''t want my Puppet rollout being blocked by an LDAP rollout. That being said, I gained a much better understanding of how Puppet works, and learned some Ruby in the process, which I hardly see as a waste of time. But I do appreciate the feedback. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan, While I think there is something to be said for learning some lessons the hard way, trying to model all the nuanced differences of every node with Puppet is not taking advantage of the tool and is arguably more trouble than it is worth. Often, it is better to step back and figure out what you want and need and then build that, than it is to automate whatever is there now. This is an investment. Pay down the principle. My 2 cents, Andrew On Tue, Oct 21, 2008 at 8:46 AM, Ryan Steele <ryan.g.steele@gmail.com>wrote:> > Jeff Leggett wrote: > > I see what you''re doing, but I question WHY? The amount of time you > > have spent troubleshooting this could have been better spent bringing > > up a small LDAP Directory that would both resolve these issues, work > > well with Puppet, and allow you a lot more flexibility in the future. > > > > While I agree that LDAP is the ideal solution (as I mentioned in the > original post), that''s a separate issue on someone else''s plate and my > design cannot assume a directory service that does not currently exist > in that environment. Once it is in place, I will obviously modify the > configs to accommodate that setup since Puppet, as you mentioned, works > well with LDAP. So while I don''t disagree, I don''t want my Puppet > rollout being blocked by an LDAP rollout. That being said, I gained a > much better understanding of how Puppet works, and learned some Ruby in > the process, which I hardly see as a waste of time. But I do appreciate > the feedback. > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Ryan, Looks like you had a good learning experience; I''m afraid you may not have pulled out the best lesson. The lesson here is that consistent uid/gid assignment is necessary to a properly automated infrastructure. That means that instead of trying to work around the broken infrastructure you should take the opportunity to fix it. Now, you''ve mentioned that someone else on your team is tasked with deploying LDAP; this is a good way to approach the problem. However, you don''t want to delay your Puppet rollout while waiting for LDAP; also a valid concern. So, why not take advantage of the fact that Puppet works well incrementally; don''t model the users in your initial rollout. This is quite doable; I took the same approach in my initial rollout. In short, Andrew''s response is most relevant; here''s one way to do what he recommended. --Paul On Tue, Oct 21, 2008 at 6:47 AM, Ryan Steele <Ryan.G.Steele@gmail.com> wrote:> > After having put in no small amount of time in to trying to coerce > Puppet into managing some decentralized users, I''m starting to wonder > if it''s even possible. I have a network in which some user attributes > vary from node to node, such as UID, GID, and groups. However, short > of a truckload of inheritance (something that obviously doesn''t > scale), this doesn''t really seem to be something Puppet is capable > of. The inheritance I''m talking about is something like: > > class node1users inherits virt_users { > # override UID''s/GID''s/groups/etc. specific to node1 > } > > > class node2users inherits virt_users { > # override UID''s/GID''s/groups/etc. specific to node2 > } > > As you can see, this gets quite cumbersome as your node count > increases. Certainly, an already centralized directory service like > LDAP is preferred, or at the very least uniform attributes across > nodes. But, when neither is the case, you work with what you''ve got. > > Alas, I think I may have found a somewhat elegant workaround - if it > works. But, testing it is a bit tough at the moment, so I''m hoping > some prying eyes might give it the vote of confidence. If this works, > I''m happy to submit it as a Puppet recipe. My idea is essentially to > have a custom fact that returns either the user''s UID/GID on that > particular node, or undef (in which case the next available UID/GID > will be assigned). Consider the following code snippets: > > This custom fact will return the user''s current UID and pGID, or a > group''s GID. Or, it will return undef in the case that the user does > not exist, in which case the user will be assigned the next available > UID/GID: > > File.open("/etc/passwd").each do |line| > gecos = line.split(/:/) > > Facter.add("#{gecos[0]}_uid") do > setcode { gecos[2] } > end > Facter.add("#{gecos[0]}_pgid") do > setcode { gecos[3] } > end > end > > File.open("/etc/group").each do |line| > gecos = line.split(/:/) > > Facter.add("#{gecos[0]}_gid") do > setcode { gecos[2] } > end > end > > > I then need a way to look up the custom facts, which take on the form > "jsmith_uid", "jsmith_pgid", and "jsmith_gid". This yields the > following function: > > module Puppet::Parser::Functions > newfunction(:lookupvar, :type => :rvalue) do |args| > return args[0] if args[0] > end > end > > > Finally, the glue that puts it all together is the user declaration. > The UID and GID are never re-declared in the config; it''s always set > to return the value of the custom fact: > > define account ( ensure, groups, shell, comment, provider > directoryservice, unixpw ) { > > ...snip... > > @user { $name: > ensure => $ensure, > uid => lookupvar("${name}_uid"), > gid => lookupvar("${name}_pgid"), > groups => $supp_groups, > comment => $comment, > shell => $user_shell, > provider => $provider, > password => $unixpw; > } > > ...snip... > > } > > > Is this a viable workaround to inconsistent user attributes in a > cluster? Votes for or against this? > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Tue, Oct 21, 2008 at 10:46 AM, Ryan Steele <ryan.g.steele@gmail.com> wrote:> While I agree that LDAP is the ideal solution (as I mentioned in the > original post), that''s a separate issue on someone else''s plate and my > design cannot assume a directory service that does not currently exist > in that environment. Once it is in place, I will obviously modify the > configs to accommodate that setup since Puppet, as you mentioned, works > well with LDAP. So while I don''t disagree, I don''t want my Puppet > rollout being blocked by an LDAP rollout. That being said, I gained a > much better understanding of how Puppet works, and learned some Ruby in > the process, which I hardly see as a waste of time. But I do appreciate > the feedback.Do you have the jurisdiction to change the IDs on the servers to sync them up? That doesn''t need LDAP, just judicious use of ''find'' and some downtime. Syncing up the IDs is really what needs to happen. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 21, 2:15 pm, "Brian Mathis" <brian.mat...@gmail.com> wrote:> > Do you have the jurisdiction to change the IDs on the servers to sync > them up? That doesn''t need LDAP, just judicious use of ''find'' and > some downtime. > > Syncing up the IDs is really what needs to happen.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Bah, copy and paste fail. I agree that uniformity is certainly something to go for, and something that will be addressed no later than the LDAP rollout. But, I think that piece-mealing my configs, as Andrew and Brian suggested, is probably the most prudent approach at the moment. Thanks to everybody who gave their 2 cents. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---