On Sunday, September 15, 2013 10:00:16 PM UTC-5, John.1209 wrote:
>
> I'm somewhat new to puppet and I have this issue with SSH.
>
> Let's say I have 6 different SSH configurations. How do I get puppet to
> install or upgrade SSH based on the configurations? Assume the O/S and
> SSHD versions are all the same.
>
> So let's say I have different configurations that run SSHD with the
> following ports:
>
> Port 22
> Port 9999
> Port 1000, and so on.
>
> How can I write or modify the puppet openssh module to update the
> different configurations?
>
> Thanks in advance.
>
There are two separate issues here: how to provide for variation in
machine-to-machine configuration details within a single module, and how to
make Puppet choose the correct configuration for each machine. These are
not completely separate. But I will start by focusing on the former.
Basically, the problem you are asking about is that of site-specific module
data. You need to be able to feed data about your site and the machine
being configured into your module in order for the managed resources to be
configured correctly. This is where Puppet variables come in. You can
rely on variables defined by any declared class (including the one wherein
you are declaring the needed resources), by the relevant node block (if
any), or at top scope. You can use these variables directly as or in
resource parameter values, or you can use them in ERB templates evaluated
via the template() or inline_template() functions. Templates are often
used for the content of configuration files.
The next question, then, is how variables get their values. There are
several ways:
- node facts are exposed as global variables; their values are provided
by the client as part of the catalog request
- node-scope variables are defined by node blocks, typically based on
the target node's identity
- variables at any level can be set to the results of Puppet functions.
This is particularly powerful, as functions can compute their results by
any means. Some, such as hiera() and its siblings, are specifically
designed to look up values in external files.
- variables that happen to be class or definition parameters can receive
their values from explicit class or resource declarations or from default
values; class parameters can also receive their values from an external
node classifier (ENC) or from automated data binding via the "hiera"
external data subsystem.
As far as the module design goes, the best approach would probably be to
rely on external data, with sensible default values declared where there
are any. For example,
class ssh_server::config {
# ...
$port = hiera('ssh_server::config::port', 22)
# ...
file { '/etc/ssh/sshd_config':
ensure => file,
uid => 0,
gid => 0,
mode => 0600,
content => template('sshd_config.tmpl')
}
}
Then, somewhere in the template you have
#...
Port <%= @port %>
#...
Note that it is quite popular these days to make class parameters out of
the characteristic data of your classes. The practice is more popular than
I think is warranted its technical merits, but if you wanted to go that
route then the beginning of the above class might look something like this:
class ssh_server::config (
# ... maybe other parameters ...
$port = 22
) {
# ...
file { '/etc/ssh/sshd_config':
#...
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
