Configuring mailman for a future domain name
I am installing Mailman on my production machine. I want it to install with the same name as another machine where my lists are currently running with listproc. In other words I am installing it on www.<domain> but I want the Mailman pages to be known as (and return the name) lists.<domain> which currently exists on a different box. How do I do this? Do I define it when running configure? I do not see that as an option in the INSTALL file but I see "--with-urlhost" and "--with-mailhost" in the "configure" file.
Paul
Paul Kleeberg paul@fpen.org
After installation look at the DEFAULT_EMAIL_HOST section in Mailman/Defaults.py But as the top of the file says, don't make changes there, make them to mm_cfg.py.
So you might want to add this to your mm_cfg.py DEFAULT_EMAIL_HOST = lists.<domain>
But read on in that file and see if there are anymore option of interest to you.
- Paul Kleeberg (paul@fpen.org) wrote:
I am installing Mailman on my production machine. I want it to install with the same name as another machine where my lists are currently running with listproc. In other words I am installing it on www.<domain> but I want the Mailman pages to be known as (and return the name) lists.<domain> which currently exists on a different box. How do I do this? Do I define it when running configure? I do not see that as an option in the INSTALL file but I see "--with-urlhost" and "--with-mailhost" in the "configure" file.
Paul
Paul Kleeberg paul@fpen.org
-- Matthew Davis http://dogpound.vnet.net/
Truck Pulls: for people who cannot understand the WWF
I have a messed up list and I can't figure out how it got messed up, but it is. The symptom is that messages held for moderation are being lost, and the list is sending uncaught bounces with the admin messages in them.
I've been over the permissions, the settings, the contents of config.db, all to no avail. I've posted here, also to no avail.
What I'd like to do is to delete the list and recreate it, then add the users back. I can extract a list of users and re-add them, but I cannot figure out how to save their settings (such as digest and nomail).
Is this possible, or should I just tell them that their options are going to be lost.
</edg>
- Ed Greenberg (edg@greenberg.org) wrote:
What I'd like to do is to delete the list and recreate it, then add the users back. I can extract a list of users and re-add them, but I cannot figure out how to save their settings (such as digest and nomail).
Is this possible, or should I just tell them that their options are going to be lost.
The easy way would be to tell them all options will be lost. But if you want a bit more work, you could save that info. Just will take a few extra steps. You didn't say which mailman you use, which only means the -f option won't be availiable on mailman 2.0.x (which is to preserve the full name), so this information is based on mailman 2.0.13
This gives you all the regular (non-digest) members in a file called regular.members # bin/list_members -rpo regular.members LISTNAME
This will put the digest members in digest.members # bin/list_members -dpo digest.members LISTNAME
If your using mailman 2.1 then you can get the nomail users # bin/list_members -npo nomail.members LISTNAME
Then you can readd them using bin/add_members And I'll give you mailman 2.1.1 examples since now would be a good time to upgrade if your redoing the list. Highly recommended upgrading to 2.1.1
# bin/add_members -r regular.members LISTNAME # bin/add_members -d digest.members LISTNAME
And you can do what you wish with the nomail people.
-- Matthew Davis http://dogpound.vnet.net/
"Freedom defined is freedom denied." -The Illuminatus
This is excellent advice. Thank you. I'm using Mailman 2.1, and plan to u/g to 2.1.1 as well.
You stated, "do what you wish with the nomail people." I suppose I have to add them as mail-recipients and then set nomail by hand. There shouldn't be too many of them :)
Thanks.
</edg>
--On Sunday, February 09, 2003 10:53 PM -0500 Matthew Davis <matthew.davis@dogpound.vnet.net> wrote:
- Ed Greenberg (edg@greenberg.org) wrote:
What I'd like to do is to delete the list and recreate it, then add the users back. I can extract a list of users and re-add them, but I cannot figure out how to save their settings (such as digest and nomail).
Is this possible, or should I just tell them that their options are going to be lost.
The easy way would be to tell them all options will be lost. But if you want a bit more work, you could save that info. Just will take a few extra steps. You didn't say which mailman you use, which only means the -f option won't be availiable on mailman 2.0.x (which is to preserve the full name), so this information is based on mailman 2.0.13
This gives you all the regular (non-digest) members in a file called regular.members # bin/list_members -rpo regular.members LISTNAME
This will put the digest members in digest.members # bin/list_members -dpo digest.members LISTNAME
If your using mailman 2.1 then you can get the nomail users # bin/list_members -npo nomail.members LISTNAME
Then you can readd them using bin/add_members And I'll give you mailman 2.1.1 examples since now would be a good time to upgrade if your redoing the list. Highly recommended upgrading to 2.1.1
# bin/add_members -r regular.members LISTNAME # bin/add_members -d digest.members LISTNAME
And you can do what you wish with the nomail people.
-- Matthew Davis http://dogpound.vnet.net/
"Freedom defined is freedom denied." -The Illuminatus
Mailman-Users mailing list Mailman-Users@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/
This message was sent to: edg@greenberg.org Unsubscribe or change your options at http://mail.python.org/mailman/options/mailman-users/edg%40greenberg.org
What you say is correct but won't that put a "legacy" URL into Default.py whereas if I used the (undocumented?) parameters below, would it build Default.py with the correct URLs and therefore eliminate the necessity to add the entry to mm_cfg.py?
I suppose I should just shut-up and try it and see what happens...
At 9:23 PM -0500 2/9/03, Matthew Davis wrote:
After installation look at the DEFAULT_EMAIL_HOST section in Mailman/Defaults.py But as the top of the file says, don't make changes there, make them to mm_cfg.py.
So you might want to add this to your mm_cfg.py DEFAULT_EMAIL_HOST = lists.<domain>
But read on in that file and see if there are anymore option of interest to you.
- Paul Kleeberg (paul@fpen.org) wrote:
I am installing Mailman on my production machine. I want it to install with the same name as another machine where my lists are currently running with listproc. In other words I am installing it on www.<domain> but I want the Mailman pages to be known as (and return the name) lists.<domain> which currently exists on a different box. How do I do this? Do I define it when running configure? I do not see that as an option in the INSTALL file but I see "--with-urlhost" and "--with-mailhost" in the "configure" file.
-- Matthew Davis http://dogpound.vnet.net/
Truck Pulls: for people who cannot understand the WWF
-- Paul Kleeberg paul@fpen.org
- Paul Kleeberg (paul@fpen.org) wrote:
What you say is correct but won't that put a "legacy" URL into Default.py whereas if I used the (undocumented?) parameters below, would it build Default.py with the correct URLs and therefore eliminate the necessity to add the entry to mm_cfg.py?
I suppose I should just shut-up and try it and see what happens...
That's correct. By not modifing Defaults.py you put a 'legacy' url in there so its posed to confuse the next admin that takes your place (heaven forbid...). But I believe thoes are there for example purporses, and your not lucky enough to have the 'defaults' work.
You can edit Defaults.py, I personally see no harm in it other than it'll break future source patches and maybe you'll forget working syntex's if you mess something up. But that's nothing that can't be solved by refering back to the Defaults.py in the tarball.
Take it for what its worth, it was free...
-- Matthew Davis http://dogpound.vnet.net/
Interstellar Matter is a Gas
At 04:06 11/02/2003, Matthew Davis wrote:
- Paul Kleeberg (paul@fpen.org) wrote:
What you say is correct but won't that put a "legacy" URL into Default.py whereas if I used the (undocumented?) parameters below, would it build Default.py with the correct URLs and therefore eliminate the necessity to add the entry to mm_cfg.py?
I suppose I should just shut-up and try it and see what happens...
That's correct. By not modifing Defaults.py you put a 'legacy' url in there so its posed to confuse the next admin that takes your place (heaven forbid...). But I believe thoes are there for example purporses, and your not lucky enough to have the 'defaults' work.
You can edit Defaults.py, I personally see no harm in it other than it'll break future source patches and maybe you'll forget working syntex's if you mess something up. But that's nothing that can't be solved by refering back to the Defaults.py in the tarball.
The reason for not editing Defaults.py is that it is replaced when you install a new version of MM over an existing version: the normal case when updating an operational installation. Hence you will lose the configuration variable changes you have made to a running system if you made them in Defaults.py
In contrast, mm_cfg.py is _NOT_ replaced when a new version of MM is installed over an existing version and hence your explicit local configuration changes are retained over the update.
Remember that the Mailman source modules only import mm_cfg (never Defaults) which, alone, imports Defaults _before_ doing its own assignments; this means that the config variable assignments in mm_cfg override any assignment of the same variable in Defaults. If it isn't mentioned in mm_cfg, then the assignment in Defaults holds sway.
Admins should follow the same logic, in which case there should be little room for confusion.
Mailman's developers were thinking about site admins when they set things up to work this way.
Take it for what its worth, it was free...
-- Matthew Davis http://dogpound.vnet.net/
Interstellar Matter is a Gas
Well I just decided to try it:
From within the directory where I unpacked the tarball: ./configure --prefix=/var/mailman --with-cgi-gid=apache --with-mail-gid=mail --with-mailhost=fpen.org --with-urlhost=lists.fpen.org
then "make install" and it appears to have worked. Default.py has the future URLs in it. I could not find documentation for --with-mailhost or --with-urlhost in section 2 of the INSTALL file or anywhere else.
I agree with you. I do not think it wise to edit the Defaults.py file but the above process looked like it might be more orthodox. I'll let you know if I encounter problems.
Paul
At 11:06 PM -0500 2/10/03, Matthew Davis wrote:
- Paul Kleeberg (paul@fpen.org) wrote:
What you say is correct but won't that put a "legacy" URL into Default.py whereas if I used the (undocumented?) parameters below, would it build Default.py with the correct URLs and therefore eliminate the necessity to add the entry to mm_cfg.py?
I suppose I should just shut-up and try it and see what happens...
That's correct. By not modifing Defaults.py you put a 'legacy' url in there so its posed to confuse the next admin that takes your place (heaven forbid...). But I believe thoes are there for example purporses, and your not lucky enough to have the 'defaults' work.
You can edit Defaults.py, I personally see no harm in it other than it'll break future source patches and maybe you'll forget working syntex's if you mess something up. But that's nothing that can't be solved by refering back to the Defaults.py in the tarball.
-- Paul Kleeberg paul@fpen.org
participants (4)
-
Ed Greenberg -
Matthew Davis -
Paul Kleeberg -
Richard Barrett