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. 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+unsubscribe@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.
Antoine Benkemoun-André
2013-Sep-16 14:08 UTC
Re: [Puppet Users] SSH configuration Question
This is all going to depend on the criteria on which you will decide which ports gets used where. You can make a standard puppet configuration and have code in the template (ERB file) to decide what port to bind sshd on depending on facts from facter. If the default facter you are working with does not provide the facts that you would like to have, it is possible to easily add other facts. Another way you can do this is to make a puppet define with the port number as parameter that you can then use in a template file. You can then specify the configuration you want on a per-host basis. Hope this helps, Antoine Le 2013-09-16 05:00, John.1209 a écrit :> I''m somewhatnew to puppet and I have this issue with SSH.> > Let''s say I have 6different 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 runSSHD with the following ports:> > Port 22 > Port 9999 > Port 1000, andso on.> > How can I write or modify the puppet openssh module toupdate the different configurations?> > Thanks in advance. > > John> > -- > You received this message because you are subscribed to theGoogle Groups "Puppet Users" group.> To unsubscribe from this group andstop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.> To post to this group, sendemail to puppet-users@googlegroups.com.> Visit this group athttp://groups.google.com/group/puppet-users [1].> For more options,visit https://groups.google.com/groups/opt_out [2]. Links: ------ [1] http://groups.google.com/group/puppet-users [2] 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+unsubscribe@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.
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+unsubscribe@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.
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.Bollinger@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+unsubscribe@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+unsubscribe@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.