Hey Paul,
Sorry for the troubles with Mailman. We’re still trying to figure out a good solution ourselves (but see below for the way to make things work immediately, though it’s probably not exactly what you want). Mailman has serious issues with virtual hosting, and as far as I can tell there simply is no way to support multiple domains from a single mailman installation. In other words, mailman is broken by design for virtual hosting under multiple domains.
However, I can see no web based admin pages as sent out in the welcome to the list email. The reason for this (according to the redhat install information in the documentation of the package) is that apparently the "wrong user" is trying to run the cgi scripts. (apache - but it expects mailman)
This might actually not be the case, as it may be running as the user that owns the domain. Note that Virtualmin sets up all domains to use SuExec…and so, anything that you run under the domain will run as that user. Mailman simply can’t run as the user–this is a problem that we’ve yet to come up with a good solution to. Mailman simply sucks for virtual hosting, and there isn’t really anything to be done about it other than either exempt it from SuExec per-domain (which has a problem with the links on the admin pages) or run it under the primary domain, which is the only “good” solution, and it aint very good, as far as many of our customers are concerned.
In short, if you’re hitting the mailman directory like this:
http://www.customerdomain.com/mailman
Then it’s running as the domain user, and it’ll never work right. Jamie and I have been fighting with this for some time, and there are a couple of bugs in the bug tracker about the problem. I don’t think this is ever going to be possible with Mailman.
However, if you’re hitting it as:
http://www.hostingserver.com/mailman
And this is configured as a non-SuExec domain, it’ll work. You will have to explicitly make this a non-SuExec domain however. You could also call it something like:
http://lists.hostingserver.com/
Which will also work, as long as it is non-SuExec.
This all assumes you aren’t running a package from some other source–you need your OS-provided mailman package, which can run as the Apache user.
Also note that the way to be sure about anything is to look at the logs. The Apache error_log will tell you exactly what user is trying to run the script, and if you send it over, it’ll give us some more clues about what we need to do to get you spinning.
The mailman instruction manual suggests that one default location is used usr/local/mailman and that is what virtual min also seems to look for as a default. Changing the paths in webmin to the data and program directories for redhat seems to solve at least part of the problem though.
The manual is wrong for Mailman installed from RPM. If Virtualmin is expecting this path, then Virtualmin is also wrong (but I’m pretty sure it is correct for all supported platforms). /usr/local is not the right path for any mailman installed from RPM. It’ll probably be /usr/lib mailman and/or /var/lib/mailman, I think. You can check where Mailman puts things with:
rpm -ql mailman
Using virtualmin to install the packages (even the fedora version)seems to set incorrect permissions when logged on to virtual min as root. As the cgi scrips require the user and group to be "mailman"
I thought this was a RHEL 4 system? You should install the mailman package provided by your OS. No others. Not the one from the Mailman site, and not any other OS version.
In short, if on RHEL:
up2date mailman
Or if on Fedora:
yum install mailman
Any other installation source is asking for huge swaths of pain and suffering, and you’ll be fighting with Virtualmin to get it to do the right thing (even moreso than you already are–I know there are complexities in the current system, but using odd packages isn’t going to solve them…the problems are just endemic in the way Mailman works, or fails to work, in this case).
The mailman instruction manual suggests that one should NOT be logged on as root to install the packages.
You must be logged in as root to install RPMs. Ignore the Mailman docs with regard to installation–the packages provided by your OS should be sane (and I know that they are sane on RHEL 4 and Fedora Core 4, because I’ve successfully configured both). The installation process docs on the mailman site can, and should, be ignored completely.
So let’s assume I use the latest RHEL 4 rpm from their site (it has a security update in it too) and install it from the where I downloaded it to on the server desktop using Virtualmin (logged on as root?) …
I assume you mean the mailman site by “from their site”? If so, let’s not assume this. This is a terrible idea. 
Please use your OS-provided package. It also has the security updates, and it has things in sane locations and with sane permissions for your OS.
What would be the next steps to get the cgi scripts to recongise the correct mailman user for those scripts?
First step is to revert back to packages provided by your OS. We’ll fix whatever problems occur with those, rather than signing on for a whole new set of problems (plus the previous ones) of a new package from an odd source that has different ideas about what permissions and locations ought to be.
I believe the key here is simply that you must run Mailman scripts without SuExec, and they must run under a single domain (so you can’t point to arbitrary domains /mailman dir–it will just confuse Mailman and your users).
Unfortunately, Jamie added some code to setup Mailman to run under every domain (almost certainly at my suggestion, before I realized how stubborn mailman is), and I think that code is still present as we’ve been trying to figure out a way to make it work. But I’ve just about given up hope that Mailman will ever work right in this type of deployment. So, now, we’re just giving people the illusion that Mailman will ever work that way…and they’re being frustrated when it refuses to. It’s irritating to us, too, if that makes you feel even a little better.
If you’d like, you can contact me via email with details for your server, and I’ll login and setup an example of how this can work…because it can work. It’s not even all that complicated. But unfortunately, I don’t think Virtualmin is doing the right thing at the moment. As soon as we figure out what the right thing is, exactly, we’ll fix it so it does.
)