Hi all, I''ve spent a bit of time today investigating whether or not I can use the Puppet Labs Apache module - https://forge.puppetlabs.com/puppetlabs/apache I''ve noted this helpful blog post - http://blog.akquinet.de/2011/11/23/managing-an-apache-server-with-puppet/ However after examining the Apache configuration I''ve inherited it seems to me that the publicly available module exposes only a fraction of the Apache options in the manifests. E.g. I have inherited several hundred RewriteRules along with RewriteConds, and all that ugliness, non standards paths to files, non standard values passed to prefork and and worker MPM, and so on. In general, looking in templates/httpd.conf.erb file, though, it appears to me that the vast majority of Apache''s configuration options can''t be controlled by puppet if you use the Apache module. Rather they''re hardcoded in this file. This leads me to suspect that most sites must be using Apache modules that were entirely developed in house? Or have most sites just decided that most of Apache''s options shouldn''t ever be changed from these default settings? Or is there a better Apache module I should look at? Or should I take the initiative and feedback lots and lots of changes to the module? Thanks in advance for feedback. Kind regards, Alex Harvey -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Hi, On Mon, Jan 28, 2013 at 10:05:21PM -0800, Alex Harvey wrote:> Hi all, > > I''ve spent a bit of time today investigating whether or not I can use the > Puppet Labs Apache module - > https://forge.puppetlabs.com/puppetlabs/apache > > I''ve noted this helpful blog post - > http://blog.akquinet.de/2011/11/23/managing-an-apache-server-with-puppet/ > > However after examining the Apache configuration I''ve inherited it seems to > me that the publicly available module exposes only a fraction of the Apache > options in the manifests. > > E.g. I have inherited several hundred RewriteRules along with RewriteConds, > and all that ugliness, non standards paths to files, non standard values > passed to prefork and and worker MPM, and so on. > > In general, looking in templates/httpd.conf.erb file, though, it appears to > me that the vast majority of Apache''s configuration options can''t be > controlled by puppet if you use the Apache module. Rather they''re > hardcoded in this file. > > This leads me to suspect that most sites must be using Apache modules that > were entirely developed in house? Or have most sites just decided that > most of Apache''s options shouldn''t ever be changed from these default > settings? Or is there a better Apache module I should look at? Or should > I take the initiative and feedback lots and lots of changes to the module?I suspect you are correct about in house apache modules. I also found the various apache modules on forge or elsewhere did not accomodate our site''s needs. It is a tough problem. We ended up building 2 apache modules. the first handles our messy "inherited" web site configs. I opted to keep the httpd.conf static and place all the messy stuff into vhost.conf files. These get managed either by template or static file depending on complexity. This is less than ideal and very site dependant. We are up to 90+ vhost templates, one per url. In the second version I tried to be more general. I wanted a way for any given application which needs web frontend to generate a vhost config within it''s own module without having to directly include an apache class. In the node def I can then include many such webapp classes in any combination. I then include my apache class which serves any vhosts configs it finds in /etc/apache/vhost.d or whatever. I am using exported resourses for the vhost configs, but I probably don''t need to. In both versions I keep the httpd.conf static, and put the apache config complexity into the vhost configs.> > Thanks in advance for feedback. > > Kind regards, > Alex Harvey > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. > To post to this group, send email to puppet-users@googlegroups.com. > Visit this group at http://groups.google.com/group/puppet-users?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > >-- -ashley Did you try poking at it with a stick? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On Wednesday, January 30, 2013 7:16:32 AM UTC+11, ashely wrote: I suspect you are correct about in house apache modules. I also found> the various apache modules on forge or elsewhere did not accomodate our > site''s needs. It is a tough problem. > > We ended up building 2 apache modules. the first handles our messy > "inherited" web site configs. I opted to keep the httpd.conf static and > place all the messy stuff into vhost.conf files. These get managed > either by template or static file depending on complexity. This is less > than ideal and very site dependant. We are up to 90+ vhost templates, > one per url. > > In the second version I tried to be more general. I wanted a way for > any given application which needs web frontend to generate a vhost > config within it''s own module without having to directly include an > apache class. In the node def I can then include many such webapp > classes in any combination. I then include my apache class which > serves any vhosts configs it finds in /etc/apache/vhost.d or whatever. > I am using exported resourses for the vhost configs, but I probably > don''t need to. > > In both versions I keep the httpd.conf static, and put the apache config > complexity into the vhost configs. >Thanks Ashley for your thoughts. I suspect this is what I''ll do too. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 01/29/2013 07:05 AM, Alex Harvey wrote:> This leads me to suspect that most sites must be using Apache modules > that were entirely developed in house? Or have most sites just decided > that most of Apache''s options shouldn''t ever be changed from these > default settings? Or is there a better Apache module I should look at? > Or should I take the initiative and feedback lots and lots of changes to > the module?I''ve modified apache module from puppetlabs to accommodate our needs, and hope I will push some changes back to community. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.