On Mon, 5 Oct 2009, Mark Sapiro wrote:
I just applied the mailman-2.1.7-20060114-to-vhost.patch to the 2.1.12
base and it applied with only two rejects, both of which are easy to
fix. Whether the patched code will actually work and meet your
requirements, I can't say.
I probably can't afford the luxury of testing it, at least not now.
I thought I saw a branch up in the Launchpad project that deals with this.
Is that a better place to start than these patches?
Maybe, but I don't see one at
<https://code.launchpad.net/mailman?field.lifecycle=ALL>.
Well it was something like 3 in the morning when I was looking. Let me
see...
Ok, scrub that. Was something else.
Are these patches
still the recommended way to achieve what I'm looking for?
I don't recommend any of these patches. Multiple Mailman instances is
the recommended way for Mailman 2.1
ah. This is what I need to hear.
My concerns right now are:
1. I need to implement this on a production system, so it has to implement
the ability to have the same list names on multiple domains and
domain-specific site passwords. And it needs to be stable (i.e. it needs
to work as advertised).
I don't see that these patches implement a domain specific site
password.
hmmm...I see it's listed as an outstanding issue.
My recommendation would be to create separate Mailman instances per
domain. I know you said originally
3. Multiple installs. I'd rather not do this if I can help it. Not
only do I have to make sure that all of them play nice with the mail
system (postfix), but I can see the day when we'll want to upgrade, and
that's going to mean upgrading something like 7 installations. ergh.
This may be a pain if you use a package that isn't designed for it, but
I wouldn't do this with a package, I can't see how I could get it to
install into different places without a *lot* of gymnastics like chroots.
if you install from source and you have Mailman generating aliases and
virtual maps for Postfix, all this means is you need to add 7 entries
to alias_maps and virtual_alias_maps instead of just one.
Ok...This is tarting to sound doable. It also means I can get the most
important domains up quickly. Is there any documentation for doing this?
I need to have 7 lots of everything, right?
And as long as you keep track of your configure commands, upgrading a
source install is very easy and straightforward. Upgrading 7 unpatched
installations is probably easier than upgrading 1 patched one.
Yeah I guess it would be.
We know this works, and there will be a migration path to MM 3.
That was my other concern about this approach - how to integrate into a
unified install once it is officially supported. But if you will be
providing an upgrade path from multiple installs then this makes me more
comfortable with the idea.
Geoff.
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
