FAQ
after many, many iterations and googling left and right, we've finally
made some progress on our email setup -- but mailman's web interface
keeps generating absolute links off-site!

- debian (testing/unstable)
- exim4-daemon-heavy (4.61-1 via apt-get)
- mailman (2.1.7-2.1.8rc1-1 via apt-get)
- vexim (downloaded & installed 2.0.1)

all's well EXCEPT...

within the web interface for mailman
(http://site.name/cgi-bin/mailman/*) ALL admin links are absolute, and
point to a DIFFERENT virtual host on the same server. it's all written
in python, and from what i can tell the culprit is in ScriptURL inside
Mailman/Utils.py: in particular, when viewing
https://site.name/cgi-bin/mailman/admin/test to administer the TEST
list, all links are absolute, pointing to
http://other.site/cgi-bin/mailman/admin/test/* -- no https, and a
different site.

we added
DEFAULT_HOST_NAME = 'site.name'
DEFAULT_URL = 'https://site.name'
to /etc/mailman/mm_cfg.py (after seeing the comments in
/usr/lib/mailman/Mailman/Default.py and confirming it in MailList.py)
to no effect. [maybe the python files aren't being recompiled?
timestamps indicate .pyc are being recompiled from the .py files.]

we ran 'hostname site.name' to fix it in ram, and then restarted
mailman, exim, and apache. no good.

we reset /etc/hostname and rebooted the computer, no good.

any ideas?

--
will trillich
"Their is five errers in this sentance."

Search Discussions

  • Will at May 8, 2006 at 1:49 pm
    after many, many iterations and googling left and right, we've finally
    made some progress on our email setup -- but mailman's web interface
    keeps generating absolute links off-site! including the form submits...
    not good!

    - debian (testing/unstable)
    - exim4-daemon-heavy (4.61-1 via apt-get)
    - mailman (2.1.7-2.1.8rc1-1 via apt-get)
    - vexim (downloaded & installed 2.0.1)

    all's well EXCEPT...

    within the web interface for mailman
    (http://site.name/cgi-bin/mailman/*) ALL admin links are absolute, and
    point to a DIFFERENT virtual host on the same server. it's all written
    in python, and from what i can tell the culprit is in ScriptURL inside
    Mailman/Utils.py: in particular, when viewing
    https://site.name/cgi-bin/mailman/admin/test to administer the TEST
    list, all links are absolute, pointing to
    http://other.site/cgi-bin/mailman/admin/test/* -- no https, and on to a
    different web server.

    things we tried, to make the URLs link relative to the current host,
    current protocol, and current request-path:

    we added
    DEFAULT_HOST_NAME = 'site.name'
    DEFAULT_URL = 'https://site.name'
    to /etc/mailman/mm_cfg.py (after seeing the comments in
    /usr/lib/mailman/Mailman/Default.py and confirming it in MailList.py)
    to no effect. [maybe the python files aren't being recompiled?
    timestamps indicate .pyc are being recompiled from the .py files.]

    we ran 'hostname site.name' to fix it in ram, and then restarted
    mailman, exim, and apache. no good.

    we reset /etc/hostname and rebooted the computer, no good.

    it's almost as if the other site name is hard-wired into the code,
    but of course that's ludicrous, as it's another virtual host on the
    same machine. how do we get relative links?

    any ideas?
  • Patrick Bogen at May 8, 2006 at 3:43 pm

    On 5/7/06, will trillich wrote:
    any ideas?
    Check your setting in DEFAULT_URL_PATTERN. See FAQ 4.29:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp

    --
    - Patrick Bogen
  • Will trillich at May 9, 2006 at 3:16 am

    On 5/8/06, Patrick Bogen wrote:
    On 5/7/06, will trillich wrote:
    any ideas?
    Check your setting in DEFAULT_URL_PATTERN. See FAQ 4.29:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
    thanks for the pointer. turns out, ours is set exactly right. it's
    perfectly fine.

    even so, check out Mailman/MailList.py, inside InitVars (and mentioned in
    /usr/lib/mailman/Mailman/Defaults.py):

    self.web_page_url = (
    mm_cfg.DEFAULT_URL or
    mm_cfg.DEFAULT_URL_PATTERN % mm_cfg.DEFAULT_URL_HOST)

    since DEFAULT_URL_HOST didn't appear to be used in the final analysis,
    we tried DEFAULT_URL instead (with the short-circuit approach, it
    would override). alas, no luck.

    all links from <site>/cgi-bin/mailman/admin/<list> are absolute links,
    pointing to
    another virtual host we've got on this server. there's GOT to be a way
    to make them
    relative -- we don't want to submit POST forms via insecure http (to
    the wrong site)
    from our secure https page!


    e.g. site for mail is 'mail.myexample.not'. that's where the MX points for smtp,
    and that's where webmail will be hosted for user pick-up (or imaps or pop3s).
    to administer this puppy, we've got 'emailadmin.myexample.not' which has vexim
    and mailman running on it. but ALL links on the admin pages -- including form
    actions -- hop from 'https://emailadmin.myexample.not' to
    'http://mail.myexample.not'.
    it's maddening!

    --
    will trillich
    "Their is five errers in this sentance."
  • Richard Barrett at May 9, 2006 at 7:39 am

    On 9 May 2006, at 04:16, will trillich wrote:
    On 5/8/06, Patrick Bogen wrote:
    On 5/7/06, will trillich wrote:
    any ideas?
    Check your setting in DEFAULT_URL_PATTERN. See FAQ 4.29:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
    thanks for the pointer. turns out, ours is set exactly right. it's
    perfectly fine.

    even so, check out Mailman/MailList.py, inside InitVars (and
    mentioned in
    /usr/lib/mailman/Mailman/Defaults.py):

    self.web_page_url = (
    mm_cfg.DEFAULT_URL or
    mm_cfg.DEFAULT_URL_PATTERN % mm_cfg.DEFAULT_URL_HOST)
    This is a red herring because the value assigned in InitVars is only
    transient while the object is being created. Shortly after this
    assignment it is replaced with the stored value recovered from the
    list's config-stored-on-disk for an existing lists or by assignment
    when a new list is being created, per the comment "Assign default
    values - some will be overriden by stored state" at the head of
    InitVars.
    since DEFAULT_URL_HOST didn't appear to be used in the final analysis,
    we tried DEFAULT_URL instead (with the short-circuit approach, it
    would override). alas, no luck.

    all links from <site>/cgi-bin/mailman/admin/<list> are absolute links,
    pointing to
    another virtual host we've got on this server. there's GOT to be a way
    to make them
    relative -- we don't want to submit POST forms via insecure http (to
    the wrong site)
    from our secure https page!
    Looking back at your original posting, you were setting
    DEFAULT_HOST_NAME and DEFAULT_URL both of which are obsolete, only
    honoured for legacy/update installations, and should have the value
    None (the default in Defaults.py). Stop fooling with them, it is only
    confusing the issue.

    btw: If your are trying to have a mix of http URLs for non-admin GUI
    and and https for admin GUI then you are wasting your time, it is all
    or nothing, one or the other. Same rule applies regarding which host
    is used for a list admin or no-admin web GUI, same one for all.

    If you want https for everything then follow the link from:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp

    to:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.027.htp
    e.g. site for mail is 'mail.myexample.not'. that's where the MX
    points for smtp,
    and that's where webmail will be hosted for user pick-up (or imaps
    or pop3s).
    to administer this puppy, we've got 'emailadmin.myexample.not'
    which has vexim
    and mailman running on it. but ALL links on the admin pages --
    including form
    actions -- hop from 'https://emailadmin.myexample.not' to
    'http://mail.myexample.not'.
    it's maddening!
    If you diligently follow _all_ the instructions in the FAQ entries,
    including the comments regarding virtual hosts, the VIRTUAL_HOSTS
    Python dictionary, restarting mailmanctl and judicious use of
    fix_url for existing lists you will get a consistent set of
    appropriate URLs produced on the MM web GUI. You also need to read
    the bin/newlist usage to understand the way that you can assign new
    lists to web and email hosts when creating them which again links to
    the understanding and setup of VIRTUAL_HOSTS Python dictionary in
    mm_cfg.py. Also, if you find yourself fooling with the list's
    host_name attribute through the admin GUI "Host name this list
    prefers for email" option then it is probably time to stop and review
    you mm_cfg entries etc.
    --
    will trillich
    "Their is five errers in this sentance."
    ------------------------------------------------------
    Mailman-Users mailing list
    Mailman-Users at python.org
    http://mail.python.org/mailman/listinfo/mailman-users
    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-users/
    r.barrett%40openinfo.co.uk

    Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?
    req=show&amp;file=faq01.027.htp
  • Will trillich at May 9, 2006 at 5:12 pm

    On 5/9/06, Richard Barrett wrote:
    btw: If your are trying to have a mix of http URLs for non-admin GUI
    and and https for admin GUI then you are wasting your time, it is all
    or nothing, one or the other. Same rule applies regarding which host
    is used for a list admin or no-admin web GUI, same one for all. ah.
    If you want https for everything then follow the link from:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp

    to:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.027.htp
    e.g. site for mail is 'mail.myexample.not'. that's where the MX
    points for smtp,
    and that's where webmail will be hosted for user pick-up (or imaps
    or pop3s).
    to administer this puppy, we've got 'emailadmin.myexample.not'
    which has vexim
    and mailman running on it. but ALL links on the admin pages --
    including form
    actions -- hop from 'https://emailadmin.myexample.not' to
    'http://mail.myexample.not'.
    it's maddening!
    If you diligently follow _all_ the instructions in the FAQ entries,
    including the comments regarding virtual hosts, the VIRTUAL_HOSTS
    Python dictionary, restarting mailmanctl and judicious use of
    fix_url for existing lists you will get a consistent set of
    appropriate URLs produced on the MM web GUI. You also need to read
    the bin/newlist usage to understand the way that you can assign new
    lists to web and email hosts when creating them which again links to
    the understanding and setup of VIRTUAL_HOSTS Python dictionary in
    mm_cfg.py. Also, if you find yourself fooling with the list's
    host_name attribute through the admin GUI "Host name this list
    prefers for email" option then it is probably time to stop and review
    you mm_cfg entries etc.
    thanks for the pointers. got lots to chew on, thanks!

    --
    will trillich
    "Their is five errers in this sentance."
  • Will trillich at May 10, 2006 at 2:07 pm
    my original missive should've been more thorough. i can see that now. :)
    On 5/9/06, Richard Barrett wrote:
    On 9 May 2006, at 04:16, will trillich wrote:
    On 5/8/06, Patrick Bogen wrote:
    Check your setting in DEFAULT_URL_PATTERN. See FAQ 4.29:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
    thanks for the pointer. turns out, ours is set exactly right. it's
    perfectly fine.
    according to http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
    we can plop 'https://%s/mailman' into DEFAULT_URL_PATTERN and it'll
    determine where the links go when creating those cursed (and
    unnecessarily) absolute urls.

    but it's still not cooperating. it's IGNORING that variable. during
    execution, that variable is parsed, because if we take out the "%s" it
    dies a painful python death. but so long as it has "%s" then the rest
    of the string does not matter, and we get redirected to our
    alternative virtual site no matter what.
    since DEFAULT_URL_HOST didn't appear to be used in the final analysis,
    we tried DEFAULT_URL instead (with the short-circuit approach, it
    would override). alas, no luck.
    DEFAULT_URL_HOST is definitely NOT what determines the links we're
    having trouble with.

    If you want https for everything then follow the link from:

    http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq04.029.htp
    apache is serving up secure https just fine. we've got that part covered.

    okay, just to be sure that DEFAULT_URL_PATTERN is referenced
    SOMEWHERE, we changed it to 'bad-url-pattern' and sure enough, it
    bombs out with a serious python error (no %s in the string for the
    argument passed to the '%' operator).

    so we changed it to 'where%s the beef?' and then everything worked
    just fine. all links STILL pointed to the other (wrong) virtual site,
    without secure https. plus, forms are also sent in the clear, to the
    wrong site. NO absolute links should be working at all in that case,
    right? IF the variable were being used, that is. it's clearly NOT
    being used in generating these links.

    i'm very new to python (coupla hours, now) -- so following library and
    module calls is quite alien to me. any chance i could munge the
    href-generator algorithm to generate relative links? absolute links
    are handy when taking cross-site jumps into account as a possibility
    -- but with cookies and authentication that would be counter
    productive anyway. links should look like

    ../../other/path

    NOT

    http://proper.server.name/on/a/good/day/other/path

    at the very least, if we're going to insist on an absolute website for
    the html doc, it should be placed in the <base> tag, and then all the
    other links should STILL be relative.

    If you diligently follow _all_ the instructions in the FAQ entries,
    including the comments regarding virtual hosts, the VIRTUAL_HOSTS
    Python dictionary, restarting mailmanctl and judicious use of
    is it simple to dump the virtual_hosts dictionary? maybe there's
    something in there that we don't want. better, would be to massage the
    href-generator routine.
    fix_url for existing lists you will get a consistent set of
    appropriate URLs produced on the MM web GUI. You also need to read
    the bin/newlist usage to understand the way that you can assign new
    lists to web and email hosts when creating them which again links to
    the understanding and setup of VIRTUAL_HOSTS Python dictionary in
    mm_cfg.py. Also, if you find yourself fooling with the list's
    host_name attribute through the admin GUI "Host name this list
    prefers for email" option then it is probably time to stop and review
    you mm_cfg entries etc.
    don't mean to sound too grumpy, but i think i've been pretty diligent.
    and we don't have any existing lists yet, as we're still trying to get
    this bad boy to straighten up and fly right.

    if we can have DEFAULT_URL_PATTERN set to "?x:%s:z!" and the site
    still works, then there's something very very wrong under the hood.
    (could be MY hood, sure, but the point stands. :)

    your talking from the perspective that it's working sanely. my debian
    setup is currently not aligned with your paradigm, but i'd love it if
    it were. :)

    --
    will trillich
    "Their is five errers in this sentance."

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedMay 8, '06 at 4:52a
activeMay 10, '06 at 2:07p
posts7
users3
websitelist.org

People

Translate

site design / logo © 2022 Grokbase