Puppet users - Sep 2008 - Puppet Common Modules: SSH Proposal

Hi there,

I''d like to collect some feedback on a conceptual simple Puppet Common 
Module I want to propose;

http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH

I''m thinking about things like;

- the way virtual resources are used,
- the way operating system specific sub-classes are used,
- use-cases I haven''t met (although secondary),
- simple errors I''ve made (I whipped this up from the top of my head), 
although the best thing is maybe to jump on the Wiki and correct my error,
- further enhancements in making this a really viable PCM.

I guess what is not needed (yet) includes (I''m sorry if this sound
harsh);

- discussions about the indentation I used

I can live with any form of indentation, and I guess so can you. I *just 
so happen* to use 4 spaces to a tab.

- the way I aggregate types into resources

It to me is a habit / matter of convenience, while I''d like to focus
the
discussion on technical arguments instead.

- namespacing of modules or classes

again I can live with *any* namespacing, and it''s not about setting the
defacto standard for all Puppet Common Modules, it''s about making a 
*start* in "code".

- module or class extensions that everyone uses

because these often-used extensions should go *in* the module (upstream, 
upstream, upstream is my motto), and such can only be done when there is 
an upstream module to begin with.

Thanks in advance for review/comments,

Kind regards,

Jeroen van Meeuwen
-kanarip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

There is a lot to digest here but a quick correction on:

# Red Hat / CentOS has puppet-0.24.4 and does not do the import magic. It could
do the imports, but it requires import statements per file (not exactly making
the module any more portable).

I''m not sure what you mean by this as import magic is most certainly in
place (we use it all the time and we actually don''t use the word import
anywhere).


----- "Jeroen van Meeuwen" <kanarip@kanarip.com> wrote:
> Hi there,
> 
> I''d like to collect some feedback on a conceptual simple Puppet
Common
> 
> Module I want to propose;
> 
> http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH
> 
> I''m thinking about things like;
> 
> - the way virtual resources are used,
> - the way operating system specific sub-classes are used,
> - use-cases I haven''t met (although secondary),
> - simple errors I''ve made (I whipped this up from the top of my
head),
> 
> although the best thing is maybe to jump on the Wiki and correct my
> error,
> - further enhancements in making this a really viable PCM.
> 
> I guess what is not needed (yet) includes (I''m sorry if this sound
> harsh);
> 
> - discussions about the indentation I used
> 
> I can live with any form of indentation, and I guess so can you. I
> *just 
> so happen* to use 4 spaces to a tab.
> 
> - the way I aggregate types into resources
> 
> It to me is a habit / matter of convenience, while I''d like to
focus
> the 
> discussion on technical arguments instead.
> 
> - namespacing of modules or classes
> 
> again I can live with *any* namespacing, and it''s not about
setting
> the 
> defacto standard for all Puppet Common Modules, it''s about making
a
> *start* in "code".
> 
> - module or class extensions that everyone uses
> 
> because these often-used extensions should go *in* the module
> (upstream, 
> upstream, upstream is my motto), and such can only be done when there
> is 
> an upstream module to begin with.
> 
> Thanks in advance for review/comments,
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> -kanarip
> 
> 
> 
-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Digant C Kasundra wrote:
> There is a lot to digest here but a quick correction on:
> 
> # Red Hat / CentOS has puppet-0.24.4 and does not do the import magic. It
could do the imports, but it requires import statements per file (not exactly
making the module any more portable).
> 
> I''m not sure what you mean by this as import magic is most
certainly in place (we use it all the time and we actually don''t use
the word import anywhere).
> 
Well, it''s in the commentary of the actual module... And not as 
significant to the proposal as the actual module itself...

Besides the wiki page can just describe the module as a one file source, 
I find the automagic module imports work, but the subclasses and defined 
types in modules (and/or it''s subbclasses) are not automatically
imported.

Jeroen van Meeuwen
-kanarip

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

This is an interesting approach and certainly valid and should work. 
I''m not sure I would use the virtual resources since one could just as
easily define those things in the classes they are used in.  Virtual resources
are better when you wnat to declare something in one place but it could be
realized in any number of places (making it impossible to be declared in all of
those places b/c if two such classes were included, you''d have an
error)

I think having the OS specific subclasses override the package name instead of a
large case statement in the initial package declaration is spiffy.  I can
actually seeing both ways being useful.  Sometimes, I like to see all the
various ways a package (or  service) might look in one place, so I sometimes
like to see the case statement approach.  Other times, I like to see specific
changes that are related to an OS or similar logical grouping to be made in an
appropriate subclass with the use of overrides.

To answer about use-cases, we have in our ssh module some subclasses that are
relevent to a particular configuration of ssh server.  For instance, ssh::global
allows ssh connections from off campus while our regular ssh doesn''t. 
I prefer these as subclasses b/c I like to look at my list of classes to glean
what kinds of things my server is setup to do (and when I build an external node
tool, rather than messing with variables and blah blah blah, I''ll just
be adding or dropping classes).


----- "Jeroen van Meeuwen" <kanarip@kanarip.com> wrote:
> Hi there,
> 
> I''d like to collect some feedback on a conceptual simple Puppet
Common
> 
> Module I want to propose;
> 
> http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH
> 
> I''m thinking about things like;
> 
> - the way virtual resources are used,
> - the way operating system specific sub-classes are used,
> - use-cases I haven''t met (although secondary),
> - simple errors I''ve made (I whipped this up from the top of my
head),
> 
> although the best thing is maybe to jump on the Wiki and correct my
> error,
> - further enhancements in making this a really viable PCM.
> 
> I guess what is not needed (yet) includes (I''m sorry if this sound
> harsh);
> 
> - discussions about the indentation I used
> 
> I can live with any form of indentation, and I guess so can you. I
> *just 
> so happen* to use 4 spaces to a tab.
> 
> - the way I aggregate types into resources
> 
> It to me is a habit / matter of convenience, while I''d like to
focus
> the 
> discussion on technical arguments instead.
> 
> - namespacing of modules or classes
> 
> again I can live with *any* namespacing, and it''s not about
setting
> the 
> defacto standard for all Puppet Common Modules, it''s about making
a
> *start* in "code".
> 
> - module or class extensions that everyone uses
> 
> because these often-used extensions should go *in* the module
> (upstream, 
> upstream, upstream is my motto), and such can only be done when there
> is 
> an upstream module to begin with.
> 
> Thanks in advance for review/comments,
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> -kanarip
> 
> 
> 
-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

----- "Jeroen van Meeuwen" <kanarip@kanarip.com> wrote:
> Digant C Kasundra wrote:
> > There is a lot to digest here but a quick correction on:
> > 
> > # Red Hat / CentOS has puppet-0.24.4 and does not do the import
> magic. It could do the imports, but it requires import statements per
> file (not exactly making the module any more portable). 
> > 
> > I''m not sure what you mean by this as import magic is most
certainly
> in place (we use it all the time and we actually don''t use the
word
> import anywhere).
> > 
> 
> Well, it''s in the commentary of the actual module... And not as 
> significant to the proposal as the actual module itself...
> 
> Besides the wiki page can just describe the module as a one file
> source, 
> I find the automagic module imports work, but the subclasses and
> defined 
> types in modules (and/or it''s subbclasses) are not automatically
> imported.
> 
> Jeroen van Meeuwen
> -kanarip
That''s odd b/c that seems to work for me just fine.  Perhaps it is b/c
of namespacing?  I.e. when I define a subclass of ssh called foo, I would
actually declare it as ssh::foo.  If I include ssh::foo, puppet looks for foo.pp
in the ssh/manifests and if it doesn''t find that, it then looks in
init.pp in ssh/manifests.  Perhaps I''m not understanding what you
aren''t able to get work.


-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Digant C Kasundra wrote:
> That''s odd b/c that seems to work for me just fine.  Perhaps it is
b/c of namespacing?  I.e. when I define a subclass of ssh called foo, I would
actually declare it as ssh::foo.  If I include ssh::foo, puppet looks for foo.pp
in the ssh/manifests and if it doesn''t find that, it then looks in
init.pp in ssh/manifests.  Perhaps I''m not understanding what you
aren''t able to get work.
> 
It''s no big deal it''s just something I wasn''t able to
get to work when I
looked at it, I''ll figure it out some time.

-Jeroen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sun, 2008-09-28 at 15:54 +0200, Jeroen van Meeuwen
wrote:
> Hi there,
> 
> I''d like to collect some feedback on a conceptual simple Puppet
Common
> Module I want to propose;
> 
> http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH
Nice. The one thing that leaves a bad taste in my mouth is the way the
file statements try to let you control which exact ssh{,d}_config file
is used on a client: won''t that in practice go back pretty quickly to a
situation of one file per host on the server ? Even worse, when an
update to the package wants to change the default for some setting (or
add a new one), you''ll have to spend lots of time merging that change
into all the copies of ssh{,d}_config.

Not surprisingly, I''d advocate to only manage the places where the
ssh{,d}_config needs to deviate from the default that''s shipped in the
package, and to do that with Augeas. So, instead of blowing out the
entire file to a client, just say something like

        augeas { "sshd-config-mods":
          context => "/files/etc/ssh/sshd_config"
          changes => [
            "set UsePam no",
            "set PermitRootLogin yes"
          ]
        }

with appropriate Puppet-specific logic to adjust for differing file
locations etc.

David



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

David Lutterkort wrote:
> On Sun, 2008-09-28 at 15:54 +0200, Jeroen van Meeuwen wrote:
>> Hi there,
>>
>> I''d like to collect some feedback on a conceptual simple
Puppet Common
>> Module I want to propose;
>>
>> http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH
> 
> Nice. The one thing that leaves a bad taste in my mouth is the way the
> file statements try to let you control which exact ssh{,d}_config file
> is used on a client: won''t that in practice go back pretty quickly
to a
> situation of one file per host on the server ? Even worse, when an
> update to the package wants to change the default for some setting (or
> add a new one), you''ll have to spend lots of time merging that
change
> into all the copies of ssh{,d}_config.
> 
No. Package defaults do not concern you unless the package default comes 
with a major operating system version upgrade, and the package defaults 
are moot as soon as you start managing the SSHd service (in grant 
total). If the package defaults are really of interest, then all you 
need to do is:

service { sshd: ensure => running, enable => true }

rather then:

include ssh::server

meaning that you won''t need a module to begin with, or the module is of
no interest to anyone.
> Not surprisingly, I''d advocate to only manage the places where the
> ssh{,d}_config needs to deviate from the default that''s shipped in
the
> package, and to do that with Augeas. So, instead of blowing out the
> entire file to a client, just say something like
> 
>         augeas { "sshd-config-mods":
>           context => "/files/etc/ssh/sshd_config"
>           changes => [
>             "set UsePam no",
>             "set PermitRootLogin yes"
>           ]
>         }
> 
> with appropriate Puppet-specific logic to adjust for differing file
> locations etc.
> 
Although I understand your point, I''m not sure how ready anyone is
right
now to "migrate" to auguas, especially seeing how it is only a few 
months old. Then again, I''m not familiar with augeas and I could ask a 
random large number of questions about it right now but it''s besides
the
point.

Even when using augeas, the settings provided in a module like you 
describe will differ in over a dozen ways even if just one or two 
organizations are using the module.

Besides, the file sshd_config *will* need to be managed as soon as you 
attempt to manage the sshd server/service, regardless of the file 
remaining to be the package default, or a default being shipped with the 
module.

In addition, if you end up with a file per host in the puppet 
configuration tree, the question becomes how you implement configuration 
management in the bigger picture to begin with, not how difficult it is 
to change a bunch of settings spread over all these files. I for one 
once started out with a sshd_config.wheel-only, to which I symlinked 
sshd_config.$hostname and ended up having too many symbolic links to 
that one file, as I moved hosts from being publicly accessible to 
privately accessible. Right about then is the time you make 
sshd_config.wheel-only to be the default, and make the exemptions for 
the other hosts (and create symbolic links sshd_config.$hostname => 
sshd_config.public).

On another note, if you do the augeas changes you forget to manage the 
other aspects that may be important to you. Suppose I manage symbolic 
links between foo and bar... My manifest would look like:

file { "/tmp/foo":
     ensure => "/tmp/bar"
}

But what I forget is that if the default for "links => manage"
changes
to "links => follow", I''m screwed. The point being, even
within a
manifest, if you do not manage the defaults that are important to you, 
you will most probably find out just how important they are when it is 
too late.

Kind regards,

Jeroen van Meeuwen
-kanarip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, 2008-10-03 at 22:47 +0200, Jeroen van Meeuwen
wrote:
> David Lutterkort wrote:
> > On Sun, 2008-09-28 at 15:54 +0200, Jeroen van Meeuwen wrote:
> >> Hi there,
> >>
> >> I''d like to collect some feedback on a conceptual simple
Puppet Common
> >> Module I want to propose;
> >>
> >> http://reductivelabs.com/trac/puppet/wiki/PuppetCommonModules/SSH
> > 
> > Nice. The one thing that leaves a bad taste in my mouth is the way the
> > file statements try to let you control which exact ssh{,d}_config file
> > is used on a client: won''t that in practice go back pretty
quickly to a
> > situation of one file per host on the server ? Even worse, when an
> > update to the package wants to change the default for some setting (or
> > add a new one), you''ll have to spend lots of time merging
that change
> > into all the copies of ssh{,d}_config.
> > 
> 
> No. Package defaults do not concern you unless the package default comes 
> with a major operating system version upgrade, and the package defaults 
> are moot as soon as you start managing the SSHd service (in grant 
> total). If the package defaults are really of interest, then all you 
> need to do is:
> 
> service { sshd: ensure => running, enable => true }
> 
> rather then:
> 
> include ssh::server
> 
> meaning that you won''t need a module to begin with, or the module
is of
> no interest to anyone.
I didn''t say that the default config file should be used verbatim, but
that it is a reasonable starting point; needing to modify ssh config is
very common.

Seeing all those sources for the reminded me a lot of home-grown config
mgmt systems where you simply store all the modified config files in
some sort of SCM, organized by some simple principle, like hostname or
similar and then just copy files around.

The problem with that organization is that there isn''t one scheme that
fits a wide variety of uses; puppet''s solution to that is to make it
easy to split a machine''s configuration into small independent parts
that can be composed in a variety of ways (mostly inheritance and
inclusion of classes) to enable a DRY description of the configuration
of the whole site.

With the ssh config files, you have to stop decomposing at the
granularity of files; for other files, you can do that at a more
fine-grained level (e.g., the host type) My point was that if you can
describe the parts of the config file that need changing at a more
granular level, you don''t need such an extensive categorization of ssh
config files.
> Although I understand your point, I''m not sure how ready anyone is
right
> now to "migrate" to auguas, especially seeing how it is only a
few
> months old. Then again, I''m not familiar with augeas and I could
ask a
> random large number of questions about it right now but it''s
besides the
> point.
Point well taken - feel free to ask in private mail or on the augeas
list.
> Even when using augeas, the settings provided in a module like you 
> describe will differ in over a dozen ways even if just one or two 
> organizations are using the module.
My point was that if you have a very granular way to change individual
config settings, you don''t need to worry as much about the different
ways in which to organize where the whole file comes from; users of the
module can simply compose the file using puppet''s standard mechanisms.
> Besides, the file sshd_config *will* need to be managed as soon as you 
> attempt to manage the sshd server/service, regardless of the file 
> remaining to be the package default, or a default being shipped with the 
> module.
Yes, I think my point about whether to start from the package default or
sth else is a bit of a red herring. Basically what I am saying is the
large number of file sources is a side-effect of managing at the wrong
level of granularity. Imagine there wasn''t a /etc/htpd/conf.d, and you
could only have one /etc/httpd/conf/httpd.conf - you would wind up with
similar headaches since there wouldn''t be a convenient way to compose
the entire Apache config from disparate parts.

David



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

David Lutterkort wrote:
> Seeing all those sources for the reminded me a lot of home-grown config
> mgmt systems where you simply store all the modified config files in
> some sort of SCM, organized by some simple principle, like hostname or
> similar and then just copy files around.
> 
> The problem with that organization is that there isn''t one scheme
that
> fits a wide variety of uses; puppet''s solution to that is to make
it
> easy to split a machine''s configuration into small independent
parts
> that can be composed in a variety of ways (mostly inheritance and
> inclusion of classes) to enable a DRY description of the configuration
> of the whole site.
> 
> With the ssh config files, you have to stop decomposing at the
> granularity of files; for other files, you can do that at a more
> fine-grained level (e.g., the host type) My point was that if you can
> describe the parts of the config file that need changing at a more
> granular level, you don''t need such an extensive categorization of
ssh
> config files.
> 
Point taken, but the number of configuration options available in any 
given application does rise another problem for me;

How can I use and re-use the same /var/lib/puppet/modules/ssh/ directory 
to multiple organizations if I know each of those organizations is going 
to mess with every possible setting available in sshd_config?

In my opinion, you can go three ways:

1) Have files put in the right location and puppet will pick up the 
first hit. This does not mean however you need to put files in 
RedHat/3/, RedHat/4/ and RedHat/5/, because 4 and 5 will be similar, 
just like CentOS/4/ and CentOS/5/, and Fedora (Core) 5 through 10, and 
only RedHat/3/ will have the exemption. Only the exemptions go where 
puppet will pick them up sooner then the more general config file.

2) Do templating, which will provide a good default but requires 
templating the entire array of available configuration settings, which 
in the case of sshd might be doable, but when configuring httpd that way 
certainly doesn''t make it more feasible, and since we would abstract
the
configuration settings, we would need to check whether a supplied value 
is even correct for a given setting. In addition, it requires setting 
the variables in a puppet manifest making the manifest more complex, 
less long-term sustainable because of changing configuration options 
across application versions, and is not relocatable.

3) Minimize the management or differentiation in the module and require 
the user of the module to define either an augeas type for use with the 
specific model or override file location settings using subclasses 
(which can be done right now as well BTW, so reducing the number of file 
sources is not a problem).

Which one of these three is the best solution, I don''t know. Maybe
given
one situation I''d choose 2) whereas in another situation I might choose
1).

In the end this makes me wonder whether there is such a thing as "one 
SSH module, to rule them all", or whether even modules as simple as an 
SSH module may need to be adjusted for each of the three situations 
mentioned and provided in three-fold.

Any ideas on that?

Kind regards,

Jeroen van Meeuwen
-kanarip

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Digant C Kasundra wrote:
> This is an interesting approach and certainly valid and should work. 
I''m not sure I would use the virtual resources since one could just as
easily define those things in the classes they are used in.  Virtual resources
are better when you wnat to declare something in one place but it could be
realized in any number of places (making it impossible to be declared in all of
those places b/c if two such classes were included, you''d have an
error)
> 
These resources are virtual to facilitate subclassing the classes 
available with the module.
> I think having the OS specific subclasses override the package name instead
of a large case statement in the initial package declaration is spiffy.  I can
actually seeing both ways being useful.  Sometimes, I like to see all the
various ways a package (or  service) might look in one place, so I sometimes
like to see the case statement approach.  Other times, I like to see specific
changes that are related to an OS or similar logical grouping to be made in an
appropriate subclass with the use of overrides.
> 
I choose operating system specific subclasses because of how these can 
override resource parameters, and do not have to be all-inclusive like 
some case statements would need to be. I think also inheritance between 
the sub-classes is relevant.
> To answer about use-cases, we have in our ssh module some subclasses that
are relevent to a particular configuration of ssh server.  For instance,
ssh::global allows ssh connections from off campus while our regular ssh
doesn''t.  I prefer these as subclasses b/c I like to look at my list of
classes to glean what kinds of things my server is setup to do (and when I build
an external node tool, rather than messing with variables and blah blah blah,
I''ll just be adding or dropping classes).
> 
This of course is perfectly doable:

// import module ssh

class ssh::server::global {
     include ssh::server
}

or in case of needing to override the source;

class ssh::server::global inherits ssh::server {
     File["/etc/ssh/sshd_config"] {
         source => "puppet:///ssh/something/different"
     }
}

I hope this makes sense.

Kind regards,

Jeroen van Meeuwen
-kanarip

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

David Lutterkort wrote:
> On Fri, 2008-10-03 at 22:47 +0200, Jeroen van Meeuwen wrote:
>> Even when using augeas, the settings provided in a module like you 
>> describe will differ in over a dozen ways even if just one or two 
>> organizations are using the module.
> 
> My point was that if you have a very granular way to change individual
> config settings, you don''t need to worry as much about the
different
> ways in which to organize where the whole file comes from; users of the
> module can simply compose the file using puppet''s standard
mechanisms.
> 
On another note, diverging the thread wrt. my previous reply a little, 
one of the things I try to avoid is using variables in manifests to 
provide/tweak settings from within a manifest, most primarily because 
there''s just too many configuration settings and writing routines to 
check settings for valid values, for or while loops and nesting isn''t 
something I would like to see in a module''s manifest that is supposed
to
just work.

That being said, if settings were to be provided in or through the 
manifest, including the ssh::server class might start looking something 
like this (don''t ask about the actual settings provided in this example
:P):

$ssh_port = [ "22", "443" ]
$ssh_protocol = [ "1", "2" ]
$ssh_access_groups = [ "sysadmin", "wheel",
"webadmin" ]
$ssh_use_pam = $operatingsystem ? {
     "RedHat" => $lsbdistrelease ? {
         "3" => false,
         default => true
     },
     "CentOS" => $lsbdistrelease ? {
         "3" => false,
         default => true
     },
     "Debian" => $operatingsystemversion ? {
         "2" => false
	(...etc...)
     },
     default => true
}

include ssh::server

and then in the ssh::server class:

$real_ssh_port = $ssh_port ? { '''' => 22, default =>
$ssh_port }
$real_ssh_protocol = $ssh_protocol ? { '''' => 2, default
=> $ssh_protocol }
(...etc...)

and then in the template... well you get the idea, I guess.

This -providing all settings one might want to tweak- IMHO, should not 
happen in a manifest. If someone needs to do such with puppet, I''d say 
use augeas instead. Maybe create a subclass to the appropriate class 
from the SSH Puppet Common Module and make it do what works for you, or 
maybe not use the SSH Puppet Common Module at all, or maybe (better yet) 
contribute a SSH module to Puppet Common Modules entirely based on and 
wrapped around augeas usage.

Kind regards,

Jeroen van Meeuwen
-kanarip

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Jeroen van Meeuwen schrieb:
> Point taken, but the number of configuration options available in any 
> given application does rise another problem for me;
> 
> How can I use and re-use the same /var/lib/puppet/modules/ssh/ directory 
> to multiple organizations if I know each of those organizations is going 
> to mess with every possible setting available in sshd_config?
> 
> In my opinion, you can go three ways:
> 
> 1) Have files put in the right location 
> 2) Do templating
> 3) Minimize the management or differentiation in the module and require 
> the user of the module to define either an augeas type for use with the 
> specific model or override file location settings using subclasses 
> (which can be done right now as well BTW, so reducing the number of file 
> sources is not a problem).

Or 4) provide a ssh::config type that can manage setting values in the 
sshd_config.

This is the most flexible approach, enabling fun stuff like purging, 
virtual resources, export/collect and a variety of other scenarios. This 
also avoids having to use a big set of variables as you outline in your 
other mail.

Of course using augeas in the guts of such a ssh::config type is 
probably a very good idea in the long-term.



Regards, DavidS

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

David Schmitt wrote:
> Or 4) provide a ssh::config type that can manage setting values in the 
> sshd_config.
> 
Good point. This however is mutually exclusive with managing the file 
resource.
> This is the most flexible approach, enabling fun stuff like purging, 
> virtual resources, export/collect and a variety of other scenarios. This 
> also avoids having to use a big set of variables as you outline in your 
> other mail.
> 
Exporting and collecting resources requires storeconfig capabilities 
from the puppetmaster, doesn''t it?

Kind regards,

Jeroen van Meeuwen
-kanarip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Jeroen van Meeuwen schrieb:
> David Schmitt wrote:
>> Or 4) provide a ssh::config type that can manage setting values in the 
>> sshd_config.
>>
> 
> Good point. This however is mutually exclusive with managing the file 
> resource.
Yes. Still, I don''t care much about the file-resource-distribution
part,
since -- through purging -- this can be totally emulated by per-setting 
resources. e.g. by stuffing all relevant settings into a class.
>> This is the most flexible approach, enabling fun stuff like purging, 
>> virtual resources, export/collect and a variety of other scenarios.
This
>> also avoids having to use a big set of variables as you outline in your
>> other mail.
>>
> 
> Exporting and collecting resources requires storeconfig capabilities 
> from the puppetmaster, doesn''t it?
Yes. And that''s still experimental. And sshd_config is probably not the
best example for use-cases of export/collect. The global ssh_config is 
probably a much better one in this case. Think each server distributing 
its own ssh_config "snippet".




Regards, DavidS

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---