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:
thanks for the pointer. turns out, ours is set exactly right. it's
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.
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
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
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. :)
"Their is five errers in this sentance."