On Oct 10, 11:15 am, Guy Matz <gm...@matz.org>
wrote:> Hi! I''ve got a requirement that a few users need to have the same
username,
> but different passwords on qa & prod server. The users are currently
> defined as
> @users which gets realized in an appropriate module, and I''ve been
thinking
> about splitting out the users I need to have realized in different
> environments and putting them in @qausers & @produsers, hoping that I
could
> say something like @users = @users + @{$env}users which would then contain
> my "main" group of user definitions, plus my environment-specific
ones.
>
> Does anyone know of a good way of doing this? Am I going about this the
> wrong way?
You are confusing me with your notation. When you write "@users" are
you talking collectively about multiple virtual User resources, or
about a single virtual instance of some "Users" defined type? Or are
you maybe just talking about an array of User resources (note that
Puppet DSL does not use the ''@'' sigil for arrays)?
There are at least two ways to go about this, both relatively
straightforward.
1) Instead of maintaining separate prod and qa user lists, with never
the twain to meet, you can configure each affected user just once,
setting its password appropriately for the node whose catalog is being
compiled. Whatever logic you are using to select prod vs. qa can be
applied at that level, or unique to that level you could use
extlookup() or hiera to select the correct password from an external
source.
2) You can carefully maintain separate user lists for qa and prod, and
maybe also a common user list, presumably in separate classes, and use
some kind of a conditional at a higher level to select which to
include on each node.
In neither case does it matter whether the User declarations are
virtual.
Option (2) is similar to what you asked about, so I will discuss it
first even though I find it the inferior option. It would look
something like this:
class usersmod::common {
@user { "common1":
# ...
}
@user { "common2":
# ...
}
}
class usersmod::prod {
@user { "special1":
# ...
}
}
class usersmod::qa {
@user { "special1":
# ...
}
}
class usersmod::users {
# this is the composition
include "usersmod::common"
if [I am prod] {
include "usersmod::prod"
} else if [I am QA] {
include "users::qa"
}
# Maybe realize the desired users ...
}
That''s usable, but slightly brittle: switching users between
"common"
and special requires moving their declarations to different classes,
and the qa and prod user classes need to be kept synchronized. Those
problems can all go away if you load your data from an external
source. Here''s a simple way you can do that via extlookup(), which is
included in the base distribution:
(Two variable definitions in site.pp not shown.)
class usersmod::virtual {
@user { "common1":
password => ''...''
# ...
}
@user { "common2":
password => ''...''
# ...
}
# Note: only one declaration of this user:
@user { "special1":
password => extlookup(''password_special1'',
''!!'', "passwords_$
{env}")
# ...
}
}
# Wherever you realize users:
class anymod::anyclass {
include "usersmod::virtual"
# realize desired users ...
}
It would be possible to extlookup() the common users'' passwords, too,
and in that case to use lookup priority to prefer a password from the
environment-specific file to one in the common file. The overall
result is easier to maintain because it''s DRYer and less complex.
John
--
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.