Paul Lathrop <paul.lath...@gmail.com> writes:
> On Tue, May 11, 2010 at 7:33 PM, Daniel Pittman <dan...@rimspace.net> wrote:
>> Paul Lathrop <p...@tertiusfamily.net> writes:
>>
>>> I've open-sources Digg's apache module:
>>> http://github.com/plathrop/puppet-module-apache
>>>
>>> I know this isn't much more advanced than what I've seen a lot of people
>>> using.
>>
>> It looks very much like our internal, not-able-to-release version. The two
>> features we have that you don't are:
>
> Is it "not able to release yet" or "not ever gonna release"?
I would have to ask my boss; it could be the former, but we have not looked at
the plans. Honestly, until relatively recently enough of this stuff was
limited to "what we need and absolutely no more" that it wouldn't be much help
to most people.
Apache is about the exception, because it is used enough that it is reasonably
flexible.
>> * the module enable/disable feature also ships appropriate configuration and
>> installs the appropriate packages for the platform.
>
> Nice, I'd love to add that.
We did it the nasty way:
define apache::module (...) {
case $name {
"fastcgi": {
package { libapache2-mod-fastcgi: ensure => latest }
# ...and if you need config, use apache::conf here.
}
}
}
Obviously that is going to be doing more for other platforms than Debian.
[...]
>> * apache::listen{,::port80,::port443}, which configures the system to listen
>> on a custom port, and then wraps that in a class for the standard ports.
>
> I don't do it quite the same way, but there is a tunable for the
> ports: $apache_listen_ports
*nod* We ended up with various services needing to deploy to different ports,
and that worked out the best way for them to coordinate that without a single
point that set it up.
>>> Here's my proposition, though. Let's get all the disparate "apache" modules
>>> out there merged together into One Awesome Module. What do you think?
>>
>> Sounds like a great idea to me, but it is a heck of a lot of work.
>
> Yeah, but I'm going to try anyway.
Well, while releasing internal config might be hard, contributing back to an
upstream project we use is easy to approve, so I will see how far we would
need to change to use your module as the base for what we do.
If we can get that I (and my staff) can contribute back enhancements to y'all
easily, and I do want to do that — the less code I maintain the cheaper this
is for my boss.[1]
>> The most likely "next" feature for us, incidentally, will be to try and
>> extract the parts of a VirtualHost tag that are custom, and the parts that
>> are
>> standard like the header, auth, logging, etc, so that we don't duplicate
>> those
>> in dozens of different files we install...
>
> I love this idea. Will have to see if I can add something to this module.
*nod* My goal was to get the "80 percent" bit right: make it easy to turn on
features like injecting a configuration fragment for authentication.
My rough thought was to make it dynamic: supply a string name for "auth", and
it includes some boilerplate in the right location, and then interpolates a
template I supplied with the right name, or something...
Not really a finished thought though.
Daniel
Footnotes:
[1] ...and the less it sucks when I got to the next company, since I don't
have to rebuild all that nice infrastructure from scratch.
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
