Postfix does not run against mailman lists!

Hey Paul,

This is a different problem than the one mentioned above, by Gino. That problem has long been resolved in the wbm-virtualmin-mailman package. It sounds like your mailman installation is broken in some odd ways.

Did you install the system standard Mailman package, or did you install from source? I strongly recommend the former, as Mailman is a bitch to install correctly (and a bitch to configure correctly even after you get it installed correctly--let your OS vendor do as much as possible).

Hey Paul,

In re-reading my reply, I see that I probably wasn't emphatic enough: This is not a misconfiguration of the Webmin module. It is a broken Mailman. Fix the mailman instance, and then we can worry over the Webmin module.

What OS is this happening on?

Hey Paul,

I think you're confusing "Mailman" with the "Mailman module".

Mailman is the actual software that runs the mailing lists, and it should have been installed from an RPM--deleting directories manually is a bad idea in this case. You would want to use rpm to remove the package and yum or urpmi or yast (depending on your OS) to reinstall it. It can be misconfigured, though I think it wouldn't be possible to do so using only the Virtualmin Mailman module GUI. It sounds like, however, that your mailman installation is broken in some way. I can't determine exactly why from the information available.

The Mailman module is the Virtualmin interface you see when you create mailing lists. It can be misconfigured, but probably not in any way that would exhibit the problems you're seeing.

Again, the problem you're seeing is definitely unrelated to the one Gino was seeing at the start of this thread, and following the advice mentioned in that message can almost certainly only have negative effects on your situation. Your issue appears to be something wrong at the Mailman level, and not the Webmin/Virtualmin Mailman module configuration layer. We need to fix that underlying problem with Mailman, which cannot be done with changes in the Webmin module.

If you have modified the mailman configuration manually (not using the Webmin/Virtualmin Mailman module), then removing the package with "rpm -e mailman" and then reinstalling it using "yum install mailman" (if you're on a Red Hat based OS--use "urpmi mailman" on Mandriva or "yast -i mailman" on SUSE) might resolve the issue by returning you to sane defaults. But it sounds like you haven't dug deep enough to have broken it in this way. Again, I'm not sure exactly what is going wrong. The OS-provided mailman package should not act this way out-of-the-box.

We should probably open up a customer issue, and exchange some logs and debugging details--I can't see what to do about it from the information available. We'd want to start with what you see in /var/log/maillog during a "service mailman restart" command, and then the log entries that occur when you send a message to a mailing list address. These details will probably give us hints about what troubleshooting steps come next.

By the way, "just zap the folder" is never the right answer with any packages we provide. They're all packaged up as proper RPMs and can be managed cleanly with RPM commands.

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.

<i>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 &quot;wrong user&quot; is trying to run the cgi scripts. (apache - but it expects mailman)</i>

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 &quot;good&quot; 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.

<i>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.</i>

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

<i>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 &quot;mailman&quot;</i>

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).

<i>The mailman instruction manual suggests that one should NOT be logged on as root to install the packages.</i>

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.

<i>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>

I assume you mean the mailman site by &quot;from their site&quot;? 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.

<i>What would be the next steps to get the cgi scripts to recongise the correct mailman user for those scripts?</i>

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.

Hey John,

It's not really broken under Virtualmin (I don't think), it's just that you have to visit the default hostname/mailman to use it (e.g. http://www.hostingdomain.tld/mailman, rather than http://www.customerdomain.tld/mailman). So, it's broken if you need a customerdomain-list to be the only list shown when you hit http://www.customerdomain.tld/mailman...but that's a mailman thing.

But I've just done some digging into the Mailman configuration, and it appears that in newer versions (looks like 2.1+), there is some kind of support for different hostnames (maybe, though I could be misinterpretting things). So this is probably a non-issue now--we just need to get the default configuration directives in Mailman right.

I'll try to get this one figured out today and a fix in our module soon after.

In the meantime, I'd be surprised if you aren't currently able to use Mailman by hitting the default location for it. Domain owners should also be able to reach it via the Webmin interface on their own domain.

But, obviously all of this needs work, as no one (even me) really understands all of the interactions and what ought to be happening where. I have used the Virtualmin Mailman module for managing lists on SciPy.org, but all lists were setup on the same domain, and it wasn't a problem for all lists to be displayed when the user clicked on &quot;show all lists&quot;. These are the things that cause problems (though this thread started because of an alias issue that prevented list mails from being delivered, but that has long since been resolved--we're on to a new set of unrelated web interface problems).