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

• 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

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

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