[Mailman-Developers] Virtual Domains Redux (w proposal)
Rich Johnson
rjohnson at dogstar-interactive.com
Mon Mar 6 18:27:44 CET 2006
On Mar 6, 2006, at 12:44 AM, Msquared wrote:
> On Fri, Mar 03, 2006 at 01:39:18PM -0800, Mark Sapiro wrote:
>
>> I.e, for the initial cut, split the lists/<listname> structure into
>> lists/<hostname>/<listname> and similarly for archives/private and
>> archives/public.
>
> Just a thought on this: might it be better to mangle the directories
> like so:
>
> <hostname>/lists/<listname>
> <hostname>/archives/<listmame>
> etc
>
> so as to group things on a per-host basis? One reason for doing so is
> that it (to me) makes more sense especially if you are hosting many
> domains that are not related or are different clients, etc. It
> simplifies
> the view of things from a per-host perspective.
>
> Perhaps even this:
>
> <hostname>/<listname>/list
> <hostname>/<listname>/archive
> etc
>
> Even better, perhaps make it configurable. :o)
>
> Regards, Msquared...
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
> Searchable Archives: http://www.mail-archive.com/mailman-users%
> 40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-
> developers/rjohnson%40dogstar-interactive.com
>
> Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?
> req=show&file=faq01.027.htp
I'll second this!
In general I object to co-mingling domain specific data. it was the
main motivation for my initial post. I'm glad it triggered a bit
more discussion that I expected. :-)
I'd encourage all to consider also:
- domains are likely to have different requirements and/or be
separately administered.
- The storage format is not necessarily a file-system. (as other
discussions have indicated)
- There's even an argument that storage format may vary between
lists in a single domain.
In any case we have:
archives <= f(domain,list,fmt)
list <= f(domain,list, fmt)
How about a macro capability with $hosthame and $listname (ala Exim's
$local_part, $domain) for filesystem storage?
One could specify:
LIST_DATA_DIR = /var/lib/mailman/%hostname/lists
or
LIST_DATA_DIR = /var/vdomains/%hostname/mailman/lists
in the config file according to your system/site conventions.
Another, more configurable, mechanism would be implementing
''repository'' objects (initially implemented for filesystem
storage): These ''repositories'' would be indexed by ''hostname''.
Their specification could be modeled after Apache's <VirtualHost>.
To wit (assuming a way to interpret this snippit):
<VirtualHost low-volume.tld>
ArchivesRepository filesystem
ListsRepository filesystem
FilesystemRoot /var/vdomains/low_volume/mailman
</VirtualHost>
<VirtualHost high-volume.tld>
ArchivesRepository filesystem
ListsRepository database
DatabaseType Postgres
FilesystemRoot /var/vdomains/high_volume/mailman
DB_info mailman_db/mailman_usr/mailman_dbpwd
</VirtualHost>
-----------------
Or even (tying these two together):
FilesystemRoot /var/vdomains/%hostname/mailman
DatabaseType postgres
DB_info mailman-db/db-user/db-pwd
<VirtualHost low-volume.tld>
ArchivesRepository filesystem
ListsRepository filesystem
</VirtualHost>
<VirtualHost high-volume.tld>
ArchivesRepository filesystem
ListsRepository database
</VirtualHost>
--rich
More information about the Mailman-Developers
mailing list