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