... to invoke a template from multiple modules? Here is what I mean: I have a module called "postfix" which handles the installation and base configuration of the postfix MTA. I have another module called "spamassassin" which deals with the download and installation of the Mail::SpamAssassin Perl module which incidently adds the init scripts for SpamAssassin and the clamd binary. I''d like that spamassassin module to modify both the master.cf and main.cffile of postfix to enable its own functionality. Rather than make SpamAssassin part of the postfix module I separated it out since not all machines running postfix need to have the overhead of SpamAssassin (eg. mailers behind the firewall that don''t accept outside email) but my border MX machines do. There''s another module that needs to modify postfix''s config files to be enabled as well and that''s the ClamAV module, I won''t go into detail here. The problem I see is if each of them modify the configs, the postfix module is going to remove the changes the other modules made. Is there a slick way of doing this? -- Peter L. Berghold Owner, Shark River Technical Solutions LLC -- 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.
(Take all this with a grain of salt, perhaps I''m inexperiencedly rhubarbing on.) You don''t necessarily need to configure your packages in the same module that you install them in. You can have a generic module for installing packages, which is included by more specific configuration modules. I wouldn''t call it slick, but perhaps something like this module structure if you only use postfix for mx hosts? postfix/ postfix/files postfix/manifests postfix/manifests/init.pp # class postfix installs the postfix software postfix/manifests/edgemx.pp # class postfix::edgemx includes class postfix, installs spamassassin and does its own cf modifications for edge hosts running spamassassin postfix/manifests/coremx.pp # class postfix::coremx includes class postfix, and does its own cf modifications for core hosts running only spamassassin postfix/manifests/clammx.pp # class postfix::clammx includes class postfix, installs clamav, and does its own cf modifications for the clamav-using postfix hosts If you have generic cf configs across all bits, they''d go in the base postfix class. By contrast, something like this if it''s more to your flavour: postfix/manifests/init.pp # installs postfix software (no configuration) clamav/manifests/init.pp # installs clamav (no configuration) # spamassassin/manifests/init.pp (no configuration) coremx/manifests/init.pp # includes spamassassin and postfix classes, does postfix config specific to core hosts edgemx/manifests/init.pp # etc for edge hosts clammx/manifests/init.pp # etc for clamav hosts Or possibly mix up the two, and so forth. On Thu, Dec 01, 2011 at 10:49:00AM -0500, Peter Berghold wrote:> ... to invoke a template from multiple modules?� Here is what I mean: > > I have a module called "postfix" which handles the installation and base > configuration of the postfix MTA.� I have another module called > "spamassassin" which deals with the download and installation of the > Mail::SpamAssassin Perl module which incidently adds the init scripts for > SpamAssassin and the clamd binary. > > I''d like that spamassassin module to modify both the [1]master.cf and > [2]main.cf file of postfix to enable its own functionality. > > Rather than make SpamAssassin part of the postfix module I separated it > out since not all machines running postfix need to have the overhead of > SpamAssassin (eg. mailers behind the firewall that don''t accept outside > email) but my border MX machines do. > > There''s another module that needs to modify postfix''s config files to be > enabled as well and that''s the ClamAV module, I won''t go into detail here. > > The problem I see is if each of them modify the configs, the postfix > module is going to remove the changes the other modules made. > > Is there a slick way of doing this? > > -- > Peter L. Berghold > Owner, Shark River Technical Solutions LLC > > -- > 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. > > References > > Visible links > 1. http://master.cf/ > 2. http://main.cf/-- 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 Dec 1, 2011, at 8:49 AM, Peter Berghold wrote:> ... to invoke a template from multiple modules? Here is what I mean: > > I have a module called "postfix" which handles the installation and base configuration of the postfix MTA. I have another module called "spamassassin" which deals with the download and installation of the Mail::SpamAssassin Perl module which incidently adds the init scripts for SpamAssassin and the clamd binary. > > I''d like that spamassassin module to modify both the master.cf and main.cf file of postfix to enable its own functionality. > > Rather than make SpamAssassin part of the postfix module I separated it out since not all machines running postfix need to have the overhead of SpamAssassin (eg. mailers behind the firewall that don''t accept outside email) but my border MX machines do. > > There''s another module that needs to modify postfix''s config files to be enabled as well and that''s the ClamAV module, I won''t go into detail here. > > The problem I see is if each of them modify the configs, the postfix module is going to remove the changes the other modules made. > > Is there a slick way of doing this?---- I found this solution to be quite useful a few months ago http://groups.google.com/group/puppet-users/browse_thread/thread/ea991b26562db42f/8660340196074a9f?lnk=gst&q=is+class%3F#8660340196074a9f Craig -- 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.
Generally when I run into this problem I make the troublesome configuration file a "Concat" file - there''s a number of implementations around, including a pure Ruby one I''ve been meaning to track down but this is RIP''s original: https://github.com/ripienaar/puppet-concat Make the Postfix module write out the "common" Postfix configuration as a Concat file, and then have a facility to allow other modules to add configuration. You can do this with a define like postfix::extra_config that adds fragments to the main postfix config file (main.cf or master.cf, whatever you need to edit). Other modules can then make additions to the Postfix config. It implies a level of trust between your modules, and there''s nothing stopping one module adding one fragment, and another unrelated module adding a conflicting fragment to the file. This approach works quite well for an snmpd module where your base config is the same but then you allow other modules to add more lines to snmpd.conf, depending on what modules are declared on that node (mysql, disk space checks, etc). On 01/12/11 15:49, Peter Berghold wrote:> ... to invoke a template from multiple modules? Here is what I mean: > > I have a module called "postfix" which handles the installation and > base configuration of the postfix MTA. I have another module called > "spamassassin" which deals with the download and installation of the > Mail::SpamAssassin Perl module which incidently adds the init scripts > for SpamAssassin and the clamd binary. > > I''d like that spamassassin module to modify both the master.cf > <http://master.cf> and main.cf <http://main.cf> file of postfix to > enable its own functionality. > > Rather than make SpamAssassin part of the postfix module I separated > it out since not all machines running postfix need to have the > overhead of SpamAssassin (eg. mailers behind the firewall that don''t > accept outside email) but my border MX machines do. > > There''s another module that needs to modify postfix''s config files to > be enabled as well and that''s the ClamAV module, I won''t go into > detail here. > > The problem I see is if each of them modify the configs, the postfix > module is going to remove the changes the other modules made. > > Is there a slick way of doing this? > > -- > Peter L. Berghold > Owner, Shark River Technical Solutions LLC > -- > 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.-- Luke Bigum Information Systems +44 (0) 20 3192 2520 Luke.Bigum@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- 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.
Phillip Frost
2011-Dec-01 16:15 UTC
Re: [Puppet Users] Is there a way to invoke a template from multiple modules?
On Dec 1, 2011, at 10:49 AM, Peter Berghold wrote:> I have a module called "postfix" which handles the installation and base configuration of the postfix MTA. I have another module called "spamassassin" which deals with the download and installation of the Mail::SpamAssassin Perl module which incidently adds the init scripts for SpamAssassin and the clamd binary. > > I''d like that spamassassin module to modify both the master.cf and main.cf file of postfix to enable its own functionality. > [...]Don''t have the spamassassin module modify postfix configuration. Rather, provide in the postfix module a resource that adds bits to the postfix configuration, and use it from the spamassassin module. This is a common pattern: class sharedsystem { package { ''sharedsystem'': ensure => installed } service { ''sharedsystem'': ensure => running } } define sharedsystem::config ($source) { file { "/etc/sharedsystem/config.d/$name": source => $source, notify => Service[''sharedsystem''] } } class subsystem1 { package { ''subsystem1'': ensure => installed } sharedsystem::config { ''subsystem1'': source => "puppet:///modules/subsystem1/sharedsystem.conf" } } class subsystem2 { package { ''subsystem2'': ensure => installed } sharedsystem::config { ''subsystem1'': source => "puppet:///modules/subsystem2/sharedsystem.conf" } } By defining sharedsystem::config, you expose from the sharedsystem module a way for other modules to configure sharedsystem, without exposing unnecessary details, and avoiding conflicts. The trick, of course, is finding a way to break down bits of configuration into non-conflicting resources. If your sharedsystem supports a configuration directory (/etc/apache/sites-enabled, /etc/apt/sources.list.d, /etc/sudoers.d, etc) then it''s easy. If not, then maybe you use something like puppet-concat to concatenate your configuration bits into one file. -- 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.
I have one pure-ruby implementation here: https://github.com/onyxpoint/pupmod-concat I''m hoping to get some code uploaded in the near future that makes it a bit less chatty. Thanks, Trevor On Thu, Dec 1, 2011 at 11:10 AM, Luke Bigum <Luke.Bigum@lmax.com> wrote:> Generally when I run into this problem I make the troublesome configuration > file a "Concat" file - there''s a number of implementations around, including > a pure Ruby one I''ve been meaning to track down but this is RIP''s original: > https://github.com/ripienaar/puppet-concat > > Make the Postfix module write out the "common" Postfix configuration as a > Concat file, and then have a facility to allow other modules to add > configuration. You can do this with a define like postfix::extra_config that > adds fragments to the main postfix config file (main.cf or master.cf, > whatever you need to edit). Other modules can then make additions to the > Postfix config. It implies a level of trust between your modules, and > there''s nothing stopping one module adding one fragment, and another > unrelated module adding a conflicting fragment to the file. > > This approach works quite well for an snmpd module where your base config is > the same but then you allow other modules to add more lines to snmpd.conf, > depending on what modules are declared on that node (mysql, disk space > checks, etc). > > > On 01/12/11 15:49, Peter Berghold wrote: > > ... to invoke a template from multiple modules? Here is what I mean: > > I have a module called "postfix" which handles the installation and base > configuration of the postfix MTA. I have another module called > "spamassassin" which deals with the download and installation of the > Mail::SpamAssassin Perl module which incidently adds the init scripts for > SpamAssassin and the clamd binary. > > I''d like that spamassassin module to modify both the master.cf and main.cf > file of postfix to enable its own functionality. > > Rather than make SpamAssassin part of the postfix module I separated it out > since not all machines running postfix need to have the overhead of > SpamAssassin (eg. mailers behind the firewall that don''t accept outside > email) but my border MX machines do. > > There''s another module that needs to modify postfix''s config files to be > enabled as well and that''s the ClamAV module, I won''t go into detail here. > > The problem I see is if each of them modify the configs, the postfix module > is going to remove the changes the other modules made. > > Is there a slick way of doing this? > > -- > Peter L. Berghold > Owner, Shark River Technical Solutions LLC > -- > 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. > > > > -- > Luke Bigum > Information Systems > +44 (0) 20 3192 2520 > Luke.Bigum@lmax.com | http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN > > > The information in this e-mail and any attachment is confidential and is > intended only for the named recipient(s). The e-mail may not be disclosed or > used by any person other than the addressee, nor may it be copied in any > way. If you are not a named recipient please notify the sender immediately > and delete any copies of this message. Any unauthorized copying, disclosure > or distribution of the material in this e-mail is strictly forbidden. Any > view or opinions presented are solely those of the author and do not > necessarily represent those of the company. > > -- > 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.-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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.