On Apr 4, 2:52 pm, Forrie <[email protected]> wrote:
> I've been working with a file of virtual users that I want to
> "realize" on certain hosts. For one of these, I need an
> authorized_keys file. After experimenting with the resource
> ssh_authorized_key, I thought I could create a dependency relationship
> like this:
> Ssh_authorized_key <| title == nagios |> -> Group <| title ==
> nagios |> -> User <| title == nagios |>
> which doesn't work. The logic being that there's no sense in
> manifesting the ssh_authorized_key unless the dependencies of the
> group and user are present.
> What am I doing wrong?
First, you're getting the dependency between key and user backwards.
What you have written says that Puppet should manage the
ssh_authorized_key *before* it manages the user to whom the key
belongs. That's conceptually incorrect, and it will fail in practice
at least if the user doesn't yet exist on the target node.
Second, you have set up a dependency between the Ssh_authorized_key
and the user's *group*, which is incorrect, although it might not hurt
you in this particular case. The relationship should be directly
between key and user.
Third, you do not need to explicitly specify the dependency at all,
because (from the docs of Ssh-authorized_key): "If Puppet is managing
the user account in which this SSH key should be installed, the
ssh_authorized_key resource will autorequire that user." In other
words, Puppet sets up the needed dependency automagically. The same
is true of the dependency between a User and its primary Group.
Fourth, resource dependencies are about influencing the order in which
resources are applied, not about determining whether they should be
applied at all. They are the wrong tool for the job you're trying to
do.
> I can realize the ssh_authorized_key separately, but it stands on its
> own and will likely fail if the aforementioned dependencies disappear.
If you want the user in question to have the key in question
everywhere that he has an account, then declare or realize the key
under the same conditions that you realize the user. One option to
simplify that would be to wrap key and user in a (virtual) instance of
a defined type. For example:
define ssh_user($uid, $gid, $key_name, $key, $ensure = "present") {
# Not virtual at this level:
user { $name: uid => $uid, gid => $gid, ensure => $ensure }
ssh_authorized_key { $key_name: user => $name, key => $key, ensure
=> $ensure }
# Assumes that a virtual group is declared for $gid:
Group<| title == $gid |>
# the needed dependencies are automagically generated
}
# ...
@group { "nagios": ... }
@ssh_user { "nagios":
uid => ...
gid => "nagios"
key_name => "nagios",
key => ...
}
# ...
Ssh_user<| title == "nagios" |>
####
Do note that with this approach it is an Ssh_user that is virtual, not
a User, so if you are realizing the user in multiple places then they
must all know to realize an Ssh_user. Note, however, that the synax
needed to activate everything is simpler (last non-comment line
above).
Also, there are several ways to tweak the definition to support
various requirements; what I gave is just a fairly simple example.
> I also noticed that it creates the .ssh directory owned by "username"
> and group "root" -- but I don't see a directive to manage that.
>
> Can someone clarify how to best accomplish this?
You can manage the user's .ssh directory via a File resource. Is it
harmful, though, for the ownership to be set up that way?
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" 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-users?hl=en.
