options to change URL structure?
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
URL architecture is a concern to me because the URL should be a permanent address and it should not be overly complex or "ugly".
In a standard Mailman implementation, we see URLs similar to this:
http://server.example.com/cgi-bin/mailman/options/ourlist/
In a cpanel installation we see URLs similar to this:
http://server.example.com/mailman/options/ourlist_server.example.com/
I'm on a cpanel implementation. We are the only domain on the VPS. It is not a shared server. Is it possible to achieve a URL structure like this (with simple list name and no cgi-bin segment)?
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 4/26/2012 1:39 PM, David wrote:
URL architecture is a concern to me because the URL should be a permanent address and it should not be overly complex or "ugly".
In a standard Mailman implementation, we see URLs similar to this:
Actually, in a standad source install of Mailman, you won't have the cgi-bin/ directory in the path. That's from a 3rd party package or someone who went out of the way to do that.
In a cpanel installation we see URLs similar to this:
http://server.example.com/mailman/options/ourlist_server.example.com/
I'm on a cpanel implementation. We are the only domain on the VPS. It is not a shared server. Is it possible to achieve a URL structure like this (with simple list name and no cgi-bin segment)?
Not if you use cPanel's Mailman and cPanel's list creation. It might be possible if you create lists with bin/newlist. You'd have to experiment.
As far as the cgi-bin/ segment is concerned, you don't need it. You don't even need the mailman/ segment if it wouldn't create conflicts to drop it. This is all controlled by the list's web_page_url attribute set at list creation time from the lists web host and DEFAULT_URL_PATTERN and Mailman's ScriptAlias or equivalent in the web server.
See FAQs at <http://wiki.list.org/x/mIA9> and <http://wiki.list.org/x/lYA9>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Thu, Apr 26, 2012 at 5:06 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 4/26/2012 1:39 PM, David wrote:
In a standard Mailman implementation, we see URLs similar to this: http://server.example.com/cgi-bin/mailman/options/ourlist/
Actually, in a standad source install of Mailman, you won't have the cgi-bin/ directory in the path. That's from a 3rd party package or someone who went out of the way to do that.
The mailman package in Ubuntu does it this way by default.
Is it possible to achieve a URL structure like this (with simple list name and no cgi-bin segment)?
It might be possible if you create lists with bin/newlist. You'd have to experiment.
OK, this will work...
don't even need the mailman/ segment if it wouldn't create conflicts to drop it.
It will not be a conflict. I'd like to drop it.
This is all controlled by the list's web_page_url attribute set at list creation time from the lists web host and DEFAULT_URL_PATTERN and Mailman's ScriptAlias or equivalent in the web server.
See FAQs at <http://wiki.list.org/x/mIA9> and <http://wiki.list.org/x/lYA9
.
I read the FAQs. I could use a bit more help. Here are my settings now.
# cat Defaults.py | grep _URL_ DEFAULT_URL_HOST = 'cloud.example.com' DEFAULT_URL_PATTERN = 'http://%s/mailman/' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
# cat Defaults.py | grep _EMAIL_ DEFAULT_EMAIL_HOST = 'cloud.example.com' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
mm_cfg.py is empty except for the personalization options I set: OWNERS_CAN_ENABLE_PERSONALIZATION=1 VERP_PERSONALIZED_DELIVERIES=1
Based on this, my guess is that I will revise this line as so:
DEFAULT_URL_PATTERN = 'http://%s/'
Is there anything else I need to change?
I'm a little confused by not seeing the expected URL subdomain.example.com. Our list is list@subdomain.example.com; we don't use cloud.example.com(there's no MX record for it).
# grep subdomain * returns no matches in the folder where the config files reside (/usr/local/cpanel/3rdparty/mailman/Mailman)
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Thu, Apr 26, 2012 at 6:41 PM, David <dave@fiteyes.com> wrote:
Based on this, my guess is that I will revise this line as so:
Is there anything else I need to change?
I'm a little confused by not seeing the expected URL subdomain.example.com. Our list is list@subdomain.example.com; we don't use cloud.example.com(there's no MX record for it).
I tried it and it didn't work as expected. I get a 404 error when clicking on the new list from the mailman/admin page. (The new list is listed on that admin page.)
Also, I'm used to having to edit /etc/aliases and run postalias /etc/aliases. It seems that the cpanel/exim installation does things differently. I haven't found the docs on that yet.
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Thu, Apr 26, 2012 at 7:11 PM, David <dave@fiteyes.com> wrote:
On Thu, Apr 26, 2012 at 6:41 PM, David <dave@fiteyes.com> wrote:
Based on this, my guess is that I will revise this line as so:
Is there anything else I need to change?
I'm a little confused by not seeing the expected URL subdomain.example.com. Our list is list@subdomain.example.com; we don't use cloud.example.com (there's no MX record for it).
I tried it and it didn't work as expected. I get a 404 error when clicking on the new list from the mailman/admin page. (The new list is listed on that admin page.)
The problem is the "mailman" segment in the url. I changed this value:
DEFAULT_URL_PATTERN = 'http://%s/'
But the admin pages for my new list are still found at subdomain.example.com/mailman/admin/listname
The link to the new list that is shown on the /mailman/admin page points to subdomain.example.com/admin/listname and this gives a 404.
Apparently I need to change another setting. BTW, to avoid having to run fix_url.py (since I don't know that script well), I just deleted my list and ran newlist again.
My other lists are still accessible at subdomain.example.com/mailman/admin/listname. Once I get all the options changed, I assume I'll have to fix those lists with fix_url.py. I'll cross that bridge once I get there.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
David wrote:
But the admin pages for my new list are still found at subdomain.example.com/mailman/admin/listname
See <http://mail.python.org/pipermail/mailman-users/2012-April/073249.html>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
David wrote:
I tried it and it didn't work as expected. I get a 404 error when clicking on the new list from the mailman/admin page. (The new list is listed on that admin page.)
See my prior reply.
Also, I'm used to having to edit /etc/aliases and run postalias /etc/aliases. It seems that the cpanel/exim installation does things differently. I haven't found the docs on that yet.
Exim does not use aliases to deliver to Mailman. See <http://www.exim.org/howto/mailman21.html>, although cPanel's Mailman router and transport are different because of remapping list@example.com to the list_example.com list name.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
On 4/26/2012 3:41 PM, David wrote:
On Thu, Apr 26, 2012 at 5:06 PM, Mark Sapiro <mark@msapiro.net> wrote:
On 4/26/2012 1:39 PM, David wrote: > > In a standard Mailman implementation, we see URLs similar to this: > http://server.example.com/cgi-bin/mailman/options/ourlist/ Actually, in a standad source install of Mailman, you won't have the cgi-bin/ directory in the path. That's from a 3rd party package or someone who went out of the way to do that.
The mailman package in Ubuntu does it this way by default.
As I said, a 3rd party package - "the Debian way".
# cat Defaults.py | grep _URL_ DEFAULT_URL_HOST = 'cloud.example.com' DEFAULT_URL_PATTERN = 'http://%s/mailman/' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
# cat Defaults.py | grep _EMAIL_ DEFAULT_EMAIL_HOST = 'cloud.example.com' add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
mm_cfg.py is empty except for the personalization options I set: OWNERS_CAN_ENABLE_PERSONALIZATION=1 VERP_PERSONALIZED_DELIVERIES=1
Based on this, my guess is that I will revise this line as so:
DEFAULT_URL_PATTERN = 'http://%s/'
Is there anything else I need to change?
Yes. You Probably have in the apache config
ScriptAlias /mailman/ "/usr/local/cpanel/3rdparty/mailman/cgi-bin/"
You could change that to
ScriptAlias / "/usr/local/cpanel/3rdparty/mailman/cgi-bin/"
But that would probably preclude anything but Mailman CGIs being accessed on your server. I'm not sure of this and I'm not an apache expert.
I would probably add several lines of the form
ScriptAlias /xxx "/usr/local/cpanel/3rdparty/mailman/cgi-bin/xxx"
where xxcx is
admin confirm edithtml listinfo options rmlist subscribe admindb create private roster
I'm a little confused by not seeing the expected URL subdomain.example.com. Our list is list@subdomain.example.com; we don't use cloud.example.com (there's no MX record for it).
That's a cPanel thing. If you're going to use bin/newlist to create lists, I would replace 'cloud' by 'subdomain' in DEFAULT_URL_HOST (assuming that's tyhe web domain too) and DEFAULT_EMAIL_HOST.
# grep subdomain * returns no matches in the folder where the config files reside (/usr/local/cpanel/3rdparty/mailman/Mailman)
strings /usr/local/cpanel/3rdparty/mailman/lists/*/config.pck |
grep subdomain
will probably find a few.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Thu, Apr 26, 2012 at 7:31 PM, Mark Sapiro <mark@msapiro.net> wrote:
Is there anything else I need to change?
Yes. You Probably have in the apache config
ScriptAlias /mailman/ "/usr/local/cpanel/3rdparty/mailman/cgi-bin/"
You could change that to
ScriptAlias / "/usr/local/cpanel/3rdparty/mailman/cgi-bin/"
I made the following changes in /usr/local/cpanel/APACHE_CONFIG:
#ScriptAlias /mailman /usr/local/cpanel/3rdparty/mailman/cgi-bin/ ScriptAlias / /usr/local/cpanel/3rdparty/mailman/cgi-bin/ ScriptAlias /admin /usr/local/cpanel/3rdparty/mailman/cgi-bin/admin ScriptAlias /confirm /usr/local/cpanel/3rdparty/mailman/cgi-bin/confirm ScriptAlias /edithtml /usr/local/cpanel/3rdparty/mailman/cgi-bin/edithtml ScriptAlias /listinfo /usr/local/cpanel/3rdparty/mailman/cgi-bin/listinfo ScriptAlias /options /usr/local/cpanel/3rdparty/mailman/cgi-bin/options ScriptAlias /rmlist /usr/local/cpanel/3rdparty/mailman/cgi-bin/rmlist ScriptAlias /subscribe /usr/local/cpanel/3rdparty/mailman/cgi-bin/subscribe ScriptAlias /admindb /usr/local/cpanel/3rdparty/mailman/cgi-bin/admindb ScriptAlias /create /usr/local/cpanel/3rdparty/mailman/cgi-bin/create ScriptAlias /private /usr/local/cpanel/3rdparty/mailman/cgi-bin/private ScriptAlias /roster /usr/local/cpanel/3rdparty/mailman/cgi-bin/roster *REMOVE* ScriptAlias / /usr/local/cpanel/3rdparty/mailman/cgi-bin/
I did not know what to do with these lines so I left them alone:
Alias /mailman/archives /usr/local/cpanel/3rdparty/mailman/archives/public/ *REMOVE* Alias /mailman/archives/ /usr/local/cpanel/3rdparty/mailman/archives/public/ Alias /pipermail /usr/local/cpanel/3rdparty/mailman/archives/public/ *REMOVE* Alias /pipermail/ /usr/local/cpanel/3rdparty/mailman/archives/public/
I restarted apache: /usr/local/apache/bin/apachectl restart
I collected all my changes in /usr/local/cpanel/3rdparty/mailman/Mailman/mm_cfg.py as shown below:
from Defaults import * OWNERS_CAN_ENABLE_PERSONALIZATION=1 VERP_PERSONALIZED_DELIVERIES=1 DEFAULT_EMAIL_HOST = 'subdomain.example.com' DEFAULT_URL_HOST = 'subdomain.example.com' DEFAULT_URL_PATTERN = 'http://%s/'
I restarted mailman: /usr/local/cpanel/3rdparty/mailman/bin/mailmanctl restart
...and there was no change in behavior. It's like I didn't make any changes.
so I reviewed the FAQs (including http://wiki.list.org/pages/viewpage.action?pageId=4030616)
I also did: $ ./bin/rmlist -a cleanurl $ ./bin/newlist --urlhost=subdomain.example.com cleanurl
I still get a 404 on subdomain.example.com/admin/cleanurl
As before, the URL subdomain.example.com/mailman/admin/cleanurl still works.
Apparently, I have missed some settings or not restarted a service that should be restarted. To check, I did : /usr/local/apache/bin/apachectl stop /usr/local/apache/bin/apachectl start
It made no difference.
Thanks so much for your help!
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Thu, Apr 26, 2012 at 10:10 PM, David <dave@fiteyes.com> wrote:
On Thu, Apr 26, 2012 at 7:31 PM, Mark Sapiro <mark@msapiro.net> wrote:
Is there anything else I need to change?
Apparently, I have missed some settings or not restarted a service that should be restarted. To check, I did : /usr/local/apache/bin/apachectl stop /usr/local/apache/bin/apachectl start
It made no difference.
Interesting info: your get_bounce_info script, Mark, runs fine on the new list, but it fails with "list not found" on the prior lists. I plan to fix the urls on those. But the funny thing is that the webserver is still serving those old lists fine and the new list gives a 404 at the expected URL.
I tried one more thing:
http://docs.cpanel.net/twiki/bin/view/11_30/WHMDocs/RestartServices # /usr/local/cpanel/scripts/restartsrv httpd Waiting for httpd to restart....finished. httpd (/bin/sh /etc/init.d/httpd start) running as root with PID 24827 (process table check method) Apache successfully restarted.
It didn't make a difference. I still get a 404 at the expected URL and things still work at the old URLs.
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Thu, Apr 26, 2012 at 10:36 PM, David <dave@fiteyes.com> wrote:
On Thu, Apr 26, 2012 at 10:10 PM, David <dave@fiteyes.com> wrote:
It didn't make a difference. I still get a 404 at the expected URL and things still work at the old URLs.
I went through the steps on a non-cpanel installation and I encountered exactly the same problem.
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Fri, Apr 27, 2012 at 12:33 AM, David <dave@fiteyes.com> wrote:
On Thu, Apr 26, 2012 at 10:36 PM, David <dave@fiteyes.com> wrote:
On Thu, Apr 26, 2012 at 10:10 PM, David <dave@fiteyes.com> wrote:
It didn't make a difference. I still get a 404 at the expected URL and things still work at the old URLs.
I went through the steps on a non-cpanel installation and I encountered exactly the same problem.
Just so people don't waste time replying, I got this resolved on the non-cpanel installation. (I just had to get the apache config files right.) It works perfectly and we have short and sweet URLs now. I have not gotten it to work on cpanel mailman yet. I'm going to ask our host to help resolve it. Thanks.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
David wrote:
Just so people don't waste time replying, I got this resolved on the non-cpanel installation. (I just had to get the apache config files right.) It works perfectly and we have short and sweet URLs now. I have not gotten it to work on cpanel mailman yet. I'm going to ask our host to help resolve it. Thanks.
If you have a non-cPanel Mailman install working on your VPS now, why are you even considering doing anything with the cPanel Mailman? I strongly suggest you just stick with your non-cPanel install and forget about the cPanel Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
David wrote:
I did not know what to do with these lines so I left them alone:
Alias /mailman/archives /usr/local/cpanel/3rdparty/mailman/archives/public/ *REMOVE* Alias /mailman/archives/ /usr/local/cpanel/3rdparty/mailman/archives/public/ Alias /pipermail /usr/local/cpanel/3rdparty/mailman/archives/public/ *REMOVE* Alias /pipermail/ /usr/local/cpanel/3rdparty/mailman/archives/public/
The above lines represent two ways of accessing public archives. With your non-cPanel Mailman, you probably want
Alias /pipermail/ /usr/local/mailman/archives/public/
(or whatever the path is).
I restarted apache: /usr/local/apache/bin/apachectl restart
I collected all my changes in /usr/local/cpanel/3rdparty/mailman/Mailman/mm_cfg.py as shown below:
from Defaults import * OWNERS_CAN_ENABLE_PERSONALIZATION=1 VERP_PERSONALIZED_DELIVERIES=1 DEFAULT_EMAIL_HOST = 'subdomain.example.com' DEFAULT_URL_HOST = 'subdomain.example.com'
I don't know how you ordered things, but the above two lines need to precede the add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST) line.
DEFAULT_URL_PATTERN = 'http://%s/'
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
The last URL I want to change is for the public archives.
I want to use "archive" instead of "pipermail" in the URL.
I made the changes to apache2/sites-enabled/000-default and /etc/mailman/apache.conf
Even though it was probably not needed, I ran: /var/lib/mailman/bin/withlist -l -a -r fix_url -- -v
...and the new archive URL appears to work. For example, I can navigate to the list's public archives with
http://server.example.com/archive/ourlist/
However, on the following admin page: Example mailing list administration, General Options Section... the link: *Go to list archives* still points to http://server.example.com/pipermail/ourlist/
I restarted mailman: sudo /etc/init.d/mailman restart
But the admin page still shows the old link.
What should I check next?
Thanks!
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
David wrote:
Even though it was probably not needed, I ran: /var/lib/mailman/bin/withlist -l -a -r fix_url -- -v
Yes, it wasn't needed.
...and the new archive URL appears to work. For example, I can navigate to the list's public archives with
http://server.example.com/archive/ourlist/
However, on the following admin page: Example mailing list administration, General Options Section... the link: *Go to list archives* still points to http://server.example.com/pipermail/ourlist/
I restarted mailman: sudo /etc/init.d/mailman restart
But the admin page still shows the old link.
What should I check next?
Read the documentation and default setting for PUBLIC_ARCHIVE_URL in Defaults.py and that should tell you what you need to put in mm_cfg.py.
It should be effective without restarting Mailman.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/59095c9cb86c22f50431abef1b166ba4.jpg?s=120&d=mm&r=g)
On Mon, Apr 30, 2012 at 10:38 PM, Mark Sapiro <mark@msapiro.net> wrote:
David wrote:
What should I check next?
Read the documentation and default setting for PUBLIC_ARCHIVE_URL in Defaults.py and that should tell you what you need to put in mm_cfg.py.
I simply added this to mm_cfg.py PUBLIC_ARCHIVE_URL = 'http://%(hostname)s/archive/%(listname)s/'
It should be effective without restarting Mailman.
Yes, it was. Thank you!
participants (2)
-
David
-
Mark Sapiro