accessing relay mailman server from its own network
Hello,
My mailing lists run on a relay server installed as per FAQ 4.88
Accessing the web interface across the internet works fine but accessing while on the host network is not so fine.
Instead of the DSL (dyndns) address I use the server name or IP address and all goes fine unless I query the mailing list addresses. Then i am returned to login again and so on ad infinitum. Same if I try to list them.
I note that when I mouse-over the menu options the browser bottom line shows the server name (or IP) address that I have used. When I mouse-over the 0-9A-Z membership listing then the DSL forwarding address shows.
FAQ 4.29 would indicate that I could change the DEFAULT_URL_HOST setting for existing lists using fix_url.py - in this case perhaps to the IP address?
I suppose that would foul up admin access from across the internet but as that is only me we could live with that.
Before fools rush in where angels fear to tread - is this the way to go? Maybe there is a route to have the best of both worlds (easy access from the internet and the local network)
many thanks in advance anotheranne
Anne Wainwright wrote:
Instead of the DSL (dyndns) address I use the server name or IP address and all goes fine unless I query the mailing list addresses. Then i am returned to login again and so on ad infinitum. Same if I try to list them.
I note that when I mouse-over the menu options the browser bottom line shows the server name (or IP) address that I have used. When I mouse-over the 0-9A-Z membership listing then the DSL forwarding address shows.
That's because the menu links are relative but the action link for the search button and the 'letter' links are absolute.
FAQ 4.29 would indicate that I could change the DEFAULT_URL_HOST setting for existing lists using fix_url.py - in this case perhaps to the IP address?
What you would need to change is the host in the list's web_page_url attribute. This is what fix_url.py does, but it also changes the list's host_name (email domain) attribute, so if you changed web_page_url with fix_url.py, you'd have to change host_name back on the list's General Options page.
It would probably be easier to change just web_page_url with interactive withlist or config_list.
But, this will change every non-relative url for this list including those in List-*: message headers and the bodies of notices and digest boilerplate and message and digest footers, so you don't want to do it.
I suppose that would foul up admin access from across the internet but as that is only me we could live with that.
Amd more than that as I note above.
Before fools rush in where angels fear to tread - is this the way to go? Maybe there is a route to have the best of both worlds (easy access from the internet and the local network)
What we need to do is figure out why those few URLs on the Membership List page are absolute. It may be a bug. I'll look at that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
What we need to do is figure out why those few URLs on the Membership List page are absolute. It may be a bug. I'll look at that.
There are two places in Mailman/Cgi/admin.py where it requests absolute URLs. The relevant code bits are
def membership_options(mlist, subcat, cgidata, doc, form): # Show the main stuff adminurl = mlist.GetScriptURL('admin', absolute=1) ...
and
def password_inputs(mlist): adminurl = mlist.GetScriptURL('admin', absolute=1)
The first of these affects the 'letter/digit' links on the membership ant the action for the Search, Submit Your Changes and Set buttons, and the second affects (I think) only the link to the general options section on the Passwords page.
I see no reason why these need to be absolute URLs. You could just change the two mlist.GetScriptURL lines to
adminurl = mlist.GetScriptURL('admin')and I think that would fix it. If you wouldn't mind trying this and reporting, I'd appreciate it and if it seems OK, I'll file a bug and change it for 2.1.16.
There may be some http/https issue around this, but offhand, I can't think why.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello, Mark,
This action solved the stated problem but now I note that the same situation pertains in "Tend to pending moderator requests" where held messages cannot be read or actioned.
Also "Go to list archives". (we do not have this running). The other two links are fine.
I see three more 'absolute=1' entries in admindb.py - shall I change all three?
regards Anne
On Wed, Apr 10, 2013 at 03:00:50PM -0700, Mark Sapiro wrote:
Mark Sapiro wrote:
What we need to do is figure out why those few URLs on the Membership List page are absolute. It may be a bug. I'll look at that.
There are two places in Mailman/Cgi/admin.py where it requests absolute URLs. The relevant code bits are
def membership_options(mlist, subcat, cgidata, doc, form): # Show the main stuff adminurl = mlist.GetScriptURL('admin', absolute=1) ...
and
def password_inputs(mlist): adminurl = mlist.GetScriptURL('admin', absolute=1)
The first of these affects the 'letter/digit' links on the membership ant the action for the Search, Submit Your Changes and Set buttons, and the second affects (I think) only the link to the general options section on the Passwords page.
I see no reason why these need to be absolute URLs. You could just change the two mlist.GetScriptURL lines to
adminurl = mlist.GetScriptURL('admin')and I think that would fix it. If you wouldn't mind trying this and reporting, I'd appreciate it and if it seems OK, I'll file a bug and change it for 2.1.16.
There may be some http/https issue around this, but offhand, I can't think why.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark, hello,
Actually there were 5 'absolute=1' entries in admindb.py and changing them all has resolved the issue of pending moderator request, but the list archives remains absolute.
Awaiting your official confirmation on which entries to change.
Anne
On Thu, Apr 11, 2013 at 02:25:10PM +0200, Anne Wainwright wrote:
Hello, Mark,
This action solved the stated problem but now I note that the same situation pertains in "Tend to pending moderator requests" where held messages cannot be read or actioned.
Also "Go to list archives". (we do not have this running). The other two links are fine.
I see three more 'absolute=1' entries in admindb.py - shall I change all three?
regards Anne
On Wed, Apr 10, 2013 at 03:00:50PM -0700, Mark Sapiro wrote:
Mark Sapiro wrote:
What we need to do is figure out why those few URLs on the Membership List page are absolute. It may be a bug. I'll look at that.
There are two places in Mailman/Cgi/admin.py where it requests absolute URLs. The relevant code bits are
def membership_options(mlist, subcat, cgidata, doc, form): # Show the main stuff adminurl = mlist.GetScriptURL('admin', absolute=1) ...
and
def password_inputs(mlist): adminurl = mlist.GetScriptURL('admin', absolute=1)
The first of these affects the 'letter/digit' links on the membership ant the action for the Search, Submit Your Changes and Set buttons, and the second affects (I think) only the link to the general options section on the Passwords page.
I see no reason why these need to be absolute URLs. You could just change the two mlist.GetScriptURL lines to
adminurl = mlist.GetScriptURL('admin')and I think that would fix it. If you wouldn't mind trying this and reporting, I'd appreciate it and if it seems OK, I'll file a bug and change it for 2.1.16.
There may be some http/https issue around this, but offhand, I can't think why.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/anotheranne%40fables.co...
Anne Wainwright wrote:
Actually there were 5 'absolute=1' entries in admindb.py and changing them all has resolved the issue of pending moderator request, but the list archives remains absolute.
Current Mailman has only 4. The change between 2.1.14 and 2.1.15 to add the logout button inserted this one
# Now print the results and we're done. Short circuit for whenthere # are no pending requests, but be sure to save the results! admindburl = mlist.GetScriptURL('admindb', absolute=1) if not mlist.NumRequestsPending():
and removed these two
doc.AddItem(_('There are no pending requests.'))
doc.AddItem(' ')
doc.AddItem(Link(mlist.GetScriptURL('admindb', absolute=1),
_('Click here to reload this page.')))
doc.AddItem(mlist.GetMailmanFooter())
print doc.Format()
mlist.Save()
return
admindburl = mlist.GetScriptURL('admindb', absolute=1)
form = Form(admindburl)
# Add the instructions templateIn any case, you want to remove ', absolute=1' from the two or its one replacement.
That leaves these three:
in main()
# Add a link back to the overview, if we're not viewing theoverview! adminurl = mlist.GetScriptURL('admin', absolute=1)
in handle_no_list()
url = Utils.ScriptURL('admin', absolute=1)
link = Link(url, _('list of available mailing lists.')).Format()
doc.AddItem(_('You must specify a list name. Here is the%(link)s'))
and in show_helds_overview)_
# Add the by-sender overview tables
admindburl = mlist.GetScriptURL('admindb', absolute=1)The last of these should definitely be changed. The other two are actually links back to the admin (not admindb) overview page. The one in main() is a link to the admin overview for the host of the list that we're currently processing in the admindb page, but the one in handle_no_list() is different because there is no list. Depending of site configuration, the host in this URL if absolute may be the web host of the current page, or it may be DEFAULT_URL_HOST. This could cause problems with a relative URL if the absolute one should go to DEFAULT_URL_HOST.
So I would say in your case, you can probably safely remove them all, but in terms of what I might do for a bug and fix, I may not do the one in handle_no_list().
As far as the archive URL is concerned, this is generated differently as it has to take into account whether the archives are public or private and the setting for PUBLIC_ARCHIVE_URL and it's always absolute.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
So I would say in your case, you can probably safely remove them all, but in terms of what I might do for a bug and fix, I may not do the one in handle_no_list().
I was going to file a bug and 'fix' this, but I have instead asked a question on mailman-developers. See <http://mail.python.org/pipermail/mailman-developers/2013-April/022761.html> for that post and what I'm concerned about.
In the mean time, it occurred to me that possibly you could fix this without changing Mailman simply by putting an appropriate entry in /etc/hosts on your 'inside the lan' work station.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello, Mark.
I have tried that with partial success, but there is another odd unmentioned behaviour that I have/had to cope with.
When I click on a 0-9A-Z link I am dumped outside back at the login window. When I log in a second time I am presented with the list of members that I wanted in the first place, subsequent queries work first time. Similarly when I need to moderate a message.
I am not sure under what exact conditions this happens, even if it is consistent across the 3 machines that could be used. So will try and determine a consistent set of circumstances under which this occurs.
At the moment removing the 'absolute=1' entries does the job 100%.
Anne
On Fri, Apr 12, 2013 at 01:35:34PM -0700, Mark Sapiro wrote:
Mark Sapiro wrote:
So I would say in your case, you can probably safely remove them all, but in terms of what I might do for a bug and fix, I may not do the one in handle_no_list().
I was going to file a bug and 'fix' this, but I have instead asked a question on mailman-developers. See <http://mail.python.org/pipermail/mailman-developers/2013-April/022761.html> for that post and what I'm concerned about.
In the mean time, it occurred to me that possibly you could fix this without changing Mailman simply by putting an appropriate entry in /etc/hosts on your 'inside the lan' work station.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 4/14/2013 10:13 AM, Anne Wainwright wrote:
I have tried that with partial success, but there is another odd unmentioned behaviour that I have/had to cope with.
When I click on a 0-9A-Z link I am dumped outside back at the login window. When I log in a second time I am presented with the list of members that I wanted in the first place, subsequent queries work first time. Similarly when I need to moderate a message.
If I understand correctly, this is what's happening in those cases. You have a /etc/hosts or whatever to direct the 'outside' host to the 'inside' host. You go to the admin or admindb page via an 'inside' URL (probably a bookmark) and log in. Once there, relative links work fine. You go to a link with an absolute URL. This points to the 'outside' host which as far as your browser is concerned is not the host that set the authentication cookie so it is not returned to the 'outside' host and you have to log in again. Once you have logged in once for each host, you are authenticated for the rest of the browser session.
The answer is if you have /etc/hosts or whatever routing the 'outside' host to the 'inside' host, never go to the 'inside' host (fix your bookmarks to point to the 'outside' host name).
At the moment removing the 'absolute=1' entries does the job 100%.
If you do notice any issues related to this, please let me know.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hi, Mark,
read below.
On Sun, Apr 14, 2013 at 04:14:32PM -0700, Mark Sapiro wrote:
On 4/14/2013 10:13 AM, Anne Wainwright wrote:
I have tried that with partial success, but there is another odd unmentioned behaviour that I have/had to cope with.
When I click on a 0-9A-Z link I am dumped outside back at the login window. When I log in a second time I am presented with the list of members that I wanted in the first place, subsequent queries work first time. Similarly when I need to moderate a message.
If I understand correctly, this is what's happening in those cases. You have a /etc/hosts or whatever to direct the 'outside' host to the 'inside' host. You go to the admin or admindb page via an 'inside' URL (probably a bookmark) and log in. Once there, relative links work fine. You go to a link with an absolute URL. This points to the 'outside' host which as far as your browser is concerned is not the host that set the authentication cookie so it is not returned to the 'outside' host and you have to log in again. Once you have logged in once for each host, you are authenticated for the rest of the browser session.
The answer is if you have /etc/hosts or whatever routing the 'outside' host to the 'inside' host, never go to the 'inside' host (fix your bookmarks to point to the 'outside' host name).
I had attacked this by a circuitous route, putting the ip address in the bookmark because I did not have an entry in /etc/hosts. When I got to putting an entry in /etc/hosts I did not change the bookmark. So ...
Yes, that is totally correct. I am leaving it like that for the moment to ensure there are no issues, and I can modify my FAQ 4.88 to reflect this. Whatever else, for any one implementing a relay server it seems the best way rather than have them editing away at key coding files.
At the moment removing the 'absolute=1' entries does the job 100%.
If you do notice any issues related to this, please let me know.
I will return to this configuration in a short while and will report on any issues or lack thereof.
thanks for all the time taken
Anne
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Hello, Mark,
A year has gone by and the system has run well. This was with the ip address set for users on the network in the 'hosts' file and with the 'absolute=1' setting in admindb.py
Recently I changed my dns provider (from dyndns to activedns) and was back reviewing what had happened here because I was again having the same issues. obviously I had not handled it correctly
In the end I changed the code in admindb.py from absolute to relative (deleted all instances of 'absolute=1', changed 'hosts' file to show the activedns address .... but
I still have dyndns addresses showing on the numeric/alpha address listing both locally and from outside
I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the browser caches. Where can this be dyndns be hiding, or is it time to run the fix_url script?
regards Anne
On Sun, Apr 14, 2013 at 04:14:32PM -0700, Mark Sapiro wrote:
On 4/14/2013 10:13 AM, Anne Wainwright wrote:
I have tried that with partial success, but there is another odd unmentioned behaviour that I have/had to cope with.
When I click on a 0-9A-Z link I am dumped outside back at the login window. When I log in a second time I am presented with the list of members that I wanted in the first place, subsequent queries work first time. Similarly when I need to moderate a message.
If I understand correctly, this is what's happening in those cases. You have a /etc/hosts or whatever to direct the 'outside' host to the 'inside' host. You go to the admin or admindb page via an 'inside' URL (probably a bookmark) and log in. Once there, relative links work fine. You go to a link with an absolute URL. This points to the 'outside' host which as far as your browser is concerned is not the host that set the authentication cookie so it is not returned to the 'outside' host and you have to log in again. Once you have logged in once for each host, you are authenticated for the rest of the browser session.
The answer is if you have /etc/hosts or whatever routing the 'outside' host to the 'inside' host, never go to the 'inside' host (fix your bookmarks to point to the 'outside' host name).
At the moment removing the 'absolute=1' entries does the job 100%.
If you do notice any issues related to this, please let me know.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 05/01/2014 11:31 AM, Anne Wainwright wrote:
I still have dyndns addresses showing on the numeric/alpha address listing both locally and from outside
I do not understand "the numeric/alpha address listing"
Where specifically do you see these?
I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the browser caches. Where can this be dyndns be hiding, or is it time to run the fix_url script?
Probably. See the FAQ at <http://wiki.list.org/x/mIA9>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Thu, May 01, 2014 at 05:19:35PM -0700, Mark Sapiro wrote:
On 05/01/2014 11:31 AM, Anne Wainwright wrote:
I still have dyndns addresses showing on the numeric/alpha address listing both locally and from outside
I do not understand "the numeric/alpha address listing"
I was not clear there, I meant the 0-9, A-Z tabular listing of members under Membership Management / Membership List.
Where specifically do you see these?
I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the browser caches. Where can this be dyndns be hiding, or is it time to run the fix_url script?
Probably. See the FAQ at <http://wiki.list.org/x/mIA9>.
That is a clear exposition of the issue, I will go that route.
many thanks Anne
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/anotheranne%40fables.c...
if this is a duplicate, my error, don't see my post anywhere. see below
On Thu, May 01, 2014 at 05:19:35PM -0700, Mark Sapiro wrote:
On 05/01/2014 11:31 AM, Anne Wainwright wrote:
I still have dyndns addresses showing on the numeric/alpha address listing both locally and from outside
I do not understand "the numeric/alpha address listing" The 0-9A-Z table of members under Membership Management - sorry if unclear.
Where specifically do you see these?
I have changed DEFAULT_URL_HOST in mm_cfg.py appropriately, cleared the browser caches. Where can this be dyndns be hiding, or is it time to run the fix_url script?
Probably. See the FAQ at <http://wiki.list.org/x/mIA9>.
This did however resolve the issue
with thanks Anne
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/anotheranne%40fables.c...
účastníci (2)
-
Anne Wainwright -
Mark Sapiro