Hi, I''m slowly building Puppet into our infrastructure, and it''s quite fun. I have a question about best practices though. If I want to configure a file, say /etc/network interfaces, on all of my Debian boxes, should I put the resource definition in: a) manifests/classes/debian.pp b) modules/debian/manifests/init.pp I guess I''m asking whether people here have configured modules for classes of servers or not. As a followup if you choose a), where do you put that in your files repository? files/debian/etc/network/interfaces? I know neither of these questions have right/wrong answers, but I''m done for the day and it''s what I want to start with tomorrow, so I thought I''d seek some advice before I do. Cheers, -- Eric Gerlach, Network Administrator Federation of Students University of Waterloo p: (519) 888-4567 x36329 e: egerlach@feds.uwaterloo.ca --~--~---------~--~----~------------~-------~--~----~ 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 2/9/2009 5:34 PM, Eric Gerlach wrote:> If I want to configure a file, say /etc/network interfaces, on all of > my Debian boxes, should I put the resource definition in: > > a) manifests/classes/debian.pp > b) modules/debian/manifests/init.pp > > I guess I''m asking whether people here have configured modules for > classes of servers or not.(b). I can''t think of any reason not to make a module for a OS. Not sure what you mean by modules for classes of servers. I have modules for operating systems, that include classes for everything that is specific to that OS. I could include that module''s classes from an overall class that covers all my systems (include $operatingsystem, for example). And if I have a server or group of servers that should provide a particular set of services, both my OS-specific and OS-neutral classes get included via either inheritance, explicitly in a service-specific class, or in the node definition itself. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological 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 -~----------~----~----~----~------~----~------~--~---
Hi Eric,
I tend to think of modules as a method to encapsulate a package or
even larger service. If you needed to develop for a specific OS you
could break down into seperate classes.
If you created a module named "network" it could be more generic and
apply to other OSes.
ie:
class network {
case $lsbdistid: {
"centos": { include network::centos }
"debian": { include network::debian }
}
Hope this helps.
-L
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Sorry $operatingsystem not $lsbdistid for the variable. -L On Feb 9, 6:54 pm, Larry Ludwig <larry...@gmail.com> wrote:> Hi Eric, > > I tend to think of modules as a method to encapsulate a package or > even larger service. If you needed to develop for a specific OS you > could break down into seperate classes. > > If you created a module named "network" it could be more generic and > apply to other OSes. > > ie: > > class network { > case $lsbdistid: { > "centos": { include network::centos } > "debian": { include network::debian } > > } > > Hope this helps. > > -L--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hello, Am 10.02.2009 um 00:34 schrieb Eric Gerlach:> If I want to configure a file, say /etc/network interfaces, on all > of my Debian boxes, should I put the resource definition in: > > a) manifests/classes/debian.pp > b) modules/debian/manifests/init.pp > > I guess I''m asking whether people here have configured modules for > classes of > servers or not. > > As a followup if you choose a), where do you put that in your files > repository? > files/debian/etc/network/interfaces? > > I know neither of these questions have right/wrong answers, but I''m > done for > the day and it''s what I want to start with tomorrow, so I thought > I''d seek some > advice before I do.I use modules, but I differentiate "programs" or "tasks" rather than OSes. I think you''ll find abstracting the OS away makes thins much easier. What I ended up with were modules for apache, bash settings, cadaver, ntp, informix, whatever. In your case, maybe a module called network would make the most sense. Then, we have a common part in the manifests, and some specialisation blurbs depending on the OS. As you can supercede stuff in puppet, you can make the common part anything you like, and change everything in the OS specific part. E.g.: Say you have a file that always goes in /some/path/some_file, except in debian where it would go in /some/other/path/some_file, and that the file should be owned by root:root on every system, except on SLES where you want john:john to have the file. That would go somewhat like: """ ## example/manifests/manifest.pp: Example class class example { # Here, we put some class defaults through the first-letter-uppercase mechanism Exec { user => john, # all commands in this class will get executed as john unless specified otherwise } include "example::${operatingsystem}" } class example::base { # the default config, OS specific adjustment go into the "OS-classes" file { "/some/path/some_file": source => "puppet:///example/some_file", owner => root, group => root; } } class example::debian inherits example::base { # some_file has to be somewhere else on debian File["/some/path/some_file"] { path => "/some/other/path/some_file", } } class example::sles inherits example::base { # some_file gets another owner on SLES File["/some/path/some_file"] { owner => john, group => john, } } class example::suse inherits example::base { # nothing to change for suse } class example::solaris inherits example::base { # nothing to change for solaris } """ It makes for a bit more typing, but I''ve found my classes to be much more flexible this way. Hope this helps, if anything is unclear, feel free to ask again :-) Felix --~--~---------~--~----~------------~-------~--~----~ 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 Mon, Feb 09, 2009 at 03:54:18PM -0800, Larry Ludwig wrote:> > Hi Eric, > > I tend to think of modules as a method to encapsulate a package or > even larger service. If you needed to develop for a specific OS you > could break down into seperate classes. > > If you created a module named "network" it could be more generic and > apply to other OSes. > > ie: > > class network { > case $lsbdistid: { > "centos": { include network::centos } > "debian": { include network::debian } > } > > Hope this helps.Thanks for the quick responses, Larry and Felix. Now that I think about it, haivng "network" as a module makes a lot of sense. I do want to ask the question: "Is the network up?" Cheers, -- Eric Gerlach, Network Administrator Federation of Students University of Waterloo p: (519) 888-4567 x36329 e: egerlach@feds.uwaterloo.ca --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---