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 <[email protected]> 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 [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. -- 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.
