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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
