I wrote an ssh_config defined type, unpublished, to manage every sshd
config value. This allowed me to set custom options like $port,
$allowgroups, create $match and $match_conditions, etc, on a server by
servers basis.
--
Later,
Darin
On Mon, Sep 16, 2013 at 12:02 PM, jcbollinger <john.bollin...@stjude.org> wrote:
>
>
> 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 puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
--
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 puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
