FAQ
Hi everyone...

I currently run Mailman (2.1) (which I love.. great job, guys!), and use
it to run a few private lists behind SSL. I have recently been asked to do
some virtual domain hosting for some friends, and would like to provide
them with their own Mailman lists, should they wish.

In mm_cfg.py I have:
DEFAULT_EMAIL_HOST = 'lists.wingfoot.org'
DEFAULT_URL_HOST = 'www.wingfoot.org'
DEFAULT_URL_PATTERN = 'https://%s/mailman/'
DEFAULT_URL = 'https://www.wingfoot.org/mailman/'
PUBLIC_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s'
PRIVATE_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s'

VIRTUAL_HOSTS = {'www.wingfoot.org':'lists.wingfoot.org',
'www.domain2.org':'lists.domain2.org',
'www.domain3.com':'lists.domain3.com',
'www.domain4.org':'lists.domain4.org'}
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)
add_virtualhost('www.domain2.org','lists.domain2.org')
add_virtualhost('www.domain3.com','lists.domain3.com')
add_virtualhost('www.domain4.org','lists.domain4.org')

Now.. when I create a list under Wingfoot, it has all the
https://www.wingfoot.org/mailman/listinfo stuff all correct. Since, that's
how I access my listserver, this is the expected behavior... :)

When I create one, say, from domain2, it *also* gets
https://www.domain2.org/mailman/listinfo stuff... even though the URL to
access that list is in http://www.domain2.org/mailman/listinfo :-/

I have tried commenting out the DEFAULT_URL_PATTERN to no avail. If I
change it to http://%s/etc that works.. but then lists on Wingfoot break.

Is what I'm trying to do possible with one instance of Mailman? Should I
install a 2nd instance? Can I even do that?

Hopefully this is chewy-good-for-thought stuff and not a "You idjit! Read
the archives!" (I checked, but didn't see anything that screamed
"Conclusive".)

Thanks guys.. and again, I appreciate all the help you've been over the
past not-quite-year, and all your hard work and effort into the Mailman
project. :)

Thanks,
Glenn
---
The original portions of this message are the copyright of the author
(c)1998-2002 Glenn E. Sieb. ICQ UIN: 300395 IRC Nick: Rainbear
"All acts of Love and Pleasure are Her rituals"-Charge of the Goddess

Search Discussions

  • Richard Barrett at Jul 26, 2003 at 8:46 am

    On Saturday, July 26, 2003, at 01:45 AM, Glenn Sieb wrote:

    Hi everyone...

    I currently run Mailman (2.1) (which I love.. great job, guys!), and
    use
    it to run a few private lists behind SSL. I have recently been asked
    to do
    some virtual domain hosting for some friends, and would like to provide
    them with their own Mailman lists, should they wish.
    Before commenting on the detail of what you do I make the observation
    that using Secure HTTP and private mail archives are not the same topic.

    Mailman's private archive feature is based on a cookie based
    authentication scheme and the delivery of private archive pages via one
    of Mailman's CGI scripts (while public archive pages are delivered by
    the web server without the use of a MM VGI script).

    Secure HTTP is a means of:

    a. preventing snooping of HTTP request/response content in
    communication between the client and server.

    b. authenticating the server to the client via the server-side
    certificates.

    c. much less frequently used: authenticating the client to the server
    (and potentially the user) via client-side certificates.

    Using HTTPS can prevent user credentials being snooped when using low
    security authentication schemes such as HTTP's Basic Authentication or
    cookie based authentication.

    But MM's list archive privacy does not require HTTPS; use of HTTPS
    merely 'hardens' the protection the list privacy scheme offers.

    The converse is also true; using HTTPS is not a constraint on reaching
    public archive pages.
    In mm_cfg.py I have:
    Commenting on this mm_cfg.py:

    You should read the comments in $prefix/Mailman/Defaults.py.
    DEFAULT_EMAIL_HOST = 'lists.wingfoot.org'
    DEFAULT_URL_HOST = 'www.wingfoot.org'
    DEFAULT_URL_PATTERN = 'https://%s/mailman/'
    DEFAULT_URL is obsolete and only for compatibility reasons, is defined
    as None in Defaults.py and should not be defined in mm_cfg.py.
    DEFAULT_URL = 'https://www.wingfoot.org/mailman/'
    PUBLIC_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s'
    There is not such animal as PRIVATE_ARCHIVE_URL in the MM lexicon. This
    variable is being completely ignored.

    Private archives are served by a Mailman CGI script in file
    $prefix/Mailman/Cgi/private.py which is invoked (assuming a default
    install) by the URI /mailman/private

    The URL for private archive access is formed from the virtual hostname
    (the url host that is) using the DEFAULT_URL_PATTERN. The ScriptAlias
    you put in your httpd.conf file associates that URL with the Mailman
    CGI program.
    PRIVATE_ARCHIVE_URL = 'https://%(hostname)s/pipermail/%(listname)s'

    VIRTUAL_HOSTS = {'www.wingfoot.org':'lists.wingfoot.org',
    'www.domain2.org':'lists.domain2.org',
    'www.domain3.com':'lists.domain3.com',
    'www.domain4.org':'lists.domain4.org'}
    add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)
    add_virtualhost('www.domain2.org','lists.domain2.org')
    add_virtualhost('www.domain3.com','lists.domain3.com')
    add_virtualhost('www.domain4.org','lists.domain4.org')

    Now.. when I create a list under Wingfoot, it has all the
    https://www.wingfoot.org/mailman/listinfo stuff all correct. Since,
    that's
    how I access my listserver, this is the expected behavior... :)

    When I create one, say, from domain2, it *also* gets
    https://www.domain2.org/mailman/listinfo stuff... even though the URL
    to
    access that list is in http://www.domain2.org/mailman/listinfo :-/
    This is no surprise as URLs for all Mailman CGI programs are formed
    from DEFAULT_URL_PATTERN
    I have tried commenting out the DEFAULT_URL_PATTERN to no avail. If I
    change it to http://%s/etc that works.. but then lists on Wingfoot
    break.
    Which is a pretty good hint that you do not want to do this. Again read
    the comments in Defaults.py before you mess with this stuff.

    btw: I assume you are restarting mailmanctl running fix_url.py after
    fixing your mm_cfg.py.
    Is what I'm trying to do possible with one instance of Mailman? Should
    I
    install a 2nd instance? Can I even do that?
    If you want to use HTTPS for private archives and HTTP for public
    archives, the simplest approach is to say:

    DEFAULT_URL = None
    PUBLIC_ARCHIVE_URL = 'http://%(hostname)s/pipermail/%(listname)s'
    DEFAULT_URL_PATTERN = 'https://%s/mailman/'

    With this, all access to Mailman CGI scripts, not just
    /mailman/private, will go via HTTPS but the links to public list
    archives will go via HTTP.

    You could do some cute stuff with httpd.conf RewriteRules but it isn't
    really necessary to have a working solution.

    As a matter of interest, what do you have in your httpd.conf for
    handling Mailman related access, thatis what Alias, ScriptAlias and
    such did you add to httpd.conf for MM.
    Hopefully this is chewy-good-for-thought stuff and not a "You idjit!
    Read
    the archives!" (I checked, but didn't see anything that screamed
    "Conclusive".)

    Thanks guys.. and again, I appreciate all the help you've been over the
    past not-quite-year, and all your hard work and effort into the
    Mailman
    project. :)

    Thanks,
    Glenn
    ---
    The original portions of this message are the copyright of the author
    (c)1998-2002 Glenn E. Sieb. ICQ UIN: 300395 IRC Nick: Rainbear
    "All acts of Love and Pleasure are Her rituals"-Charge of the Goddess
  • Glenn Sieb at Jul 26, 2003 at 5:30 pm
    Heya Richard :)

    Richard Barrett said:
    Before commenting on the detail of what you do I make the observation
    that using Secure HTTP and private mail archives are not the same topic.
    This is correct, and a nice summary of SSL versus private archives, but it
    has nothing to do with my question, unfortunately :-/
    You should read the comments in $prefix/Mailman/Defaults.py.
    I will do so again, but Defaults.py can just read like Beetlejuice style
    stereo instructions at times :-/
    DEFAULT_URL is obsolete and only for compatibility reasons, is defined
    as None in Defaults.py and should not be defined in mm_cfg.py. <snip>
    There is not such animal as PRIVATE_ARCHIVE_URL in the MM lexicon. This
    variable is being completely ignored.
    Ok, fair 'nuff. Things to note: I probably got most of these settings
    either A) from reading this list or B) reading HOWTOs on the web... my
    Mailman server has been up for a number of months now, and I don't exactly
    recall where I got most of the settings I used.
    Private archives are served by a Mailman CGI script in file
    $prefix/Mailman/Cgi/private.py which is invoked (assuming a default
    install) by the URI /mailman/private
    Correct--please note my question had to do with having one hostname behind
    SSL, and others (virtual hostnames) not behind SSL. The installation as it
    stands has been running for a while now and I have no complaints with it's
    performance.
    This is no surprise as URLs for all Mailman CGI programs are formed
    from DEFAULT_URL_PATTERN
    I still put the reference in, so you could see that I had taken the basic
    logical steps in figuring this out. :)
    Which is a pretty good hint that you do not want to do this. Again read
    the comments in Defaults.py before you mess with this stuff.
    Maybe what I can/should do, is, go through Defaults.py and see if I can
    clean up the wording to make it easier to understand in those spots that
    are clearly written by programmers for programmers? :)
    btw: I assume you are restarting mailmanctl running fix_url.py after
    fixing your mm_cfg.py. Yup.
    If you want to use HTTPS for private archives and HTTP for public
    archives, the simplest approach is to say:
    This was not my question. My question was: Virtual Hosts. I have a primary
    host (wingfoot), and others (domain2.org, etc). I apologize, but I thought
    I had been pretty clear in that my whole question was that I wish
    Wingfoot's Mailman to be behind SSL and the other domains Mailmans *not*
    to be behind SSL.

    So, is it possible to do what I need to in one instance of Mailman, or do
    I need two instances of Mailman? And, if I do need two instances of
    Mailman, is that even possible to do so on one box without them clobbering
    each other?

    Thank you!
    Glenn
    ---
    The original portions of this message are the copyright of the author
    (c)1998-2002 Glenn E. Sieb. ICQ UIN: 300395 IRC Nick: Rainbear
    "All acts of Love and Pleasure are Her rituals"-Charge of the Goddess
  • Richard Barrett at Jul 26, 2003 at 10:03 pm
    On Saturday, July 26, 2003, at 06:30 PM, Glenn Sieb wrote:

    <snip>
    My question was: Virtual Hosts. I have a primary
    host (wingfoot), and others (domain2.org, etc). I apologize, but I
    thought
    I had been pretty clear in that my whole question was that I wish
    Wingfoot's Mailman to be behind SSL and the other domains Mailmans
    *not*
    to be behind SSL.
    Must have missed that the first time around or at least failed to grasp
    why it was of concern. If I am honest fail to see why you have a
    problem with all the virtual hosts using the same scheme but what the
    heck, its your system.
    So, is it possible to do what I need to in one instance of Mailman,
    It would appear not. There is only one DEFAULT_URL_PATTERN and one
    PUBLIC_ARCHIVE_URL per mm_cfg.py file. The value of those variables
    define the scheme to be used in URL's generated by the MM software that
    accesses that file. I think it is safe to assume that all the virtual
    hosts being supported by that MM installation will those values and
    hence use the same scheme.
    or do
    I need two instances of Mailman? And, if I do need two instances of
    Mailman, is that even possible to do so on one box without them
    clobbering
    each other?
    I would think that running ./configure with two different values of
    --with-prefix, followed by make install for each, would be the simplest
    approach and work just fine. I am sure you can work out the additional
    entries in your httpd.conf for the 'https server' and the 'http server'
    to coexist. And you have the to ensure that mail aliases supported by
    the two MM installs do not collide as far as your MTA is concerned.
    Thank you!
    Glenn
    ---
    The original portions of this message are the copyright of the author
    (c)1998-2002 Glenn E. Sieb. ICQ UIN: 300395 IRC Nick: Rainbear
    "All acts of Love and Pleasure are Her rituals"-Charge of the Goddess
  • Glenn Sieb at Jul 26, 2003 at 10:34 pm

    Richard Barrett said:
    Must have missed that the first time around or at least failed to grasp
    why it was of concern. If I am honest fail to see why you have a
    problem with all the virtual hosts using the same scheme but what the
    heck, its your system.
    Easy--because SSL isn't very friendly for virtual domains unless you
    specify a separate IP address for *every* domain. (Remember--SSL works on
    the *IP* level, not on the HTTP server level--so right now having the
    other domains reply to https: means they're using my (Wingfoot's)
    certificate, which causes all kinds of screaming by browsers, and just
    Looks Ugly(tm).) For any of us who've ever been hosted at places like
    phpwebhosting.com, you know exactly what I'm talking about.. :)

    So, since IPs cost $, plus the time and hassle to have to go through a
    network renumber... I'm all about avoiding that. :)
    It would appear not. There is only one DEFAULT_URL_PATTERN and one
    PUBLIC_ARCHIVE_URL per mm_cfg.py file. The value of those variables
    define the scheme to be used in URL's generated by the MM software that
    accesses that file. I think it is safe to assume that all the virtual
    hosts being supported by that MM installation will those values and
    hence use the same scheme.
    *nod* Ok...
    I would think that running ./configure with two different values of
    --with-prefix, followed by make install for each, would be the simplest
    approach and work just fine. I am sure you can work out the additional
    entries in your httpd.conf for the 'https server' and the 'http server'
    to coexist. And you have the to ensure that mail aliases supported by
    the two MM installs do not collide as far as your MTA is concerned.
    Ok fair enough.. I'll give this a shot... I'll let you know how it turns
    out...

    Thanks, Richard!
    Glenn
    ---
    The original portions of this message are the copyright of the author
    (c)1998-2002 Glenn E. Sieb. ICQ UIN: 300395 IRC Nick: Rainbear
    "All acts of Love and Pleasure are Her rituals"-Charge of the Goddess

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJul 26, '03 at 12:45a
activeJul 26, '03 at 10:34p
posts5
users3
websitelist.org

People

Translate

site design / logo © 2022 Grokbase