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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
