Postfix does not run against mailman lists!

19 posts / 0 new
Last post
#1 Tue, 03/14/2006 - 02:07
GinoMorilla

Postfix does not run against mailman lists!

Hello...

When trying to send an email to a mailman list, postfix prints out this in logs... (my company politics doesn´t want to publish names :( )

[[root@ns49 log]]# tail -f maillog Mar 14 09:21:52 ns49 postfix/cleanup[[4048]]: 6266CC9CD82: message-id=indentificator... Mar 14 09:21:52 ns49 postfix/qmgr[[3525]]: 6266CC9CD82: from=mailer, size=2302, nrcpt=1 (queue active) Mar 14 09:21:52 ns49 local[[4050]]: fatal: execvp /usr/lib/mailman/bin/mailman: No such file or directory Mar 14 09:21:52 ns49 postfix/smtpd[[3501]]: disconnect from ns14.xxxxxxxxxxx.net Mar 14 09:21:53 ns49 postfix/local[[4049]]: 6266CC9CD82: to=destiny, orig_to=destiny, relay=local, delay=1, status=bounced (Command died with status 1: "/usr/lib/mailman/bin/mailman post testgino") Mar 14 09:21:53 ns49 postfix/qmgr[[3525]]: 6266CC9CD82: removed

Clearly, the most important error is:

Mar 14 09:21:52 ns49 local[[4050]]: fatal: execvp /usr/lib/mailman/bin/mailman: No such file or directory

Ok... I´ve seen that virtualmin manages mailman lists adding the following lines in /etc/aliases:

testgino-yyyyyyyyyy.com: "|/usr/lib/mailman/bin/mailman post testgino" testgino-admin-yyyyyyyyyy.com: "|/usr/lib/mailman/bin/mailman admin testgino" testgino-bounces-yyyyyyyyyy.com: "|/usr/lib/mailman/bin/mailman bounces testgino" testgino-confirm-yyyyyyyyyy.com: "|/usr/lib/mailman/bin/mailman confirm testgino"

Oka... I can see obviously the paths are not correct, since the file "mailman" is in "/usr/lib/mailman/mail/mailman", and not in "/usr/lib/mailman/bin/mailman"

pfffff...

How can I do to fix this? I don´t really know how to manage virtualmin to configure the correct aliases for mailman lists...

If I shell: cp /usr/lib/mailman/mail/mailman /usr/lib/mailman/bin/mailman

Ok...

Mar 14 09:04:47 ns49 postfix/local[[3445]]: E1609C9CD82: to=destiny, orig_to=destiny, relay=local, delay=1, status=sent (delivered to command: /usr/lib/mailman/bin/mailman post testgino) Mar 14 09:04:47 ns49 postfix/qmgr[[3525]]: E1609C9CD82: removed

Oka, there is no error, but emails are not arriving anywhere...

How can I see what is doing "mailman post testgino"???? Emails get losts...

(Ommited mails names because of security reasons of the forum... )

Thank you so much!

Tue, 03/14/2006 - 15:56
Joe
Joe's picture

Hi Gino,

I believe this is either a bug in our virtualmin-mailman module or in the Fedora Core 4 mailman package (what platform are you running on, by the way? That'll help me figure out what's going on, because I thought this was fixed in the last virtualmin-mailman module release). To fix your existing list configurations, you can do this:

cd /etc
sed -i 's/mailman/bin/mailman/mail/g' aliases
newaliases

As soon as I figure out what's going on with Fedora's mailman locations, a new module will roll into the repository which fixes this problem for good (until Fedora moves the files around again).

--

Check out the forum guidelines!

Sun, 06/25/2006 - 14:31
PaulDuffield

Hi Joe,

Any update on this one at all? I can't get mailman to start after a virutalmin install it tells me "site list is missing" running RHE 4 X64 and Virtualmin 3.08

I tried the fix above but it didn't work mailman still will not start.

(Should I think about upgrading to a later virtualmin too btw? if so any suggestions as to how please)

Cheers for now,

P

Sun, 06/25/2006 - 15:18
PaulDuffield

An update...

After some fiddling and viewing some other forums I created a user and group called mailman and that at least seems to have got it started.

However, I am getting the following error when attempting to post to a test list set up for the purpose...

*testlist-boatability.co.uk@its-magic.co.uk* (expanded from
*testlist@boatability.co.uk*): Command died with status 1:
"/usr/lib/mailman/bin/mailman post testlist"

In the plugin module config there is a path that is just /usr/lib/mailman/ but extending it to the above seems to make no difference. (more desperation than a calculated or knowledgeable attempt at a fix...)

(html tags replaced by * above as this forum wont let me post them)

P

Wed, 06/28/2006 - 23:58 (Reply to #4)
Joe
Joe's picture

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

--

Check out the forum guidelines!

Thu, 12/27/2007 - 06:30 (Reply to #5)
fuzzie

I was able to remigrate this account and get the mailman lists successfully set up. I think the issue was the username@domain.com username format. The whole migration was choking.
Once I fixed that, the mailman lists came over smoothly.

However, mail sent to the lists just disappears, never to be seen or delivered.

So I created a brand new test list...and mail to that list is also vanishing.

Beating my head against the wall on this one!

BTW: Excellent product! The cPanel migration worked great!

Thu, 12/27/2007 - 15:34 (Reply to #6)
Joe
Joe's picture

Hey Fuzzie,

What's in the maillog when you send a message to a list?

--

Check out the forum guidelines!

Fri, 12/28/2007 - 05:39 (Reply to #7)
fuzzie

Joe, excellent job!
I figured out how to get mailman to cooperate. Although I am not sure which of the following worked:
1. Created a admin mailing list called mailman
2. Added the aliases created by step 1 into /etc/aliases
3. Restarted /etc/init.d/mailmanctl

Confession time: I am not so sure mailman was running, or if it were, whether skipping to step 3 and restarting it would not have fixed the issue. Bottom line, it is working as it did under cPanel.

Thu, 06/29/2006 - 00:00 (Reply to #8)
Joe
Joe's picture

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?

--

Check out the forum guidelines!

Mon, 07/03/2006 - 02:08
PaulDuffield

Hi Joe,

I initially set up mailman using webmin and not the mailman source package. It appeared in the plugin section.

Initially it would not start so I "fiddled" with it a bit and managed to get it to start. I can also add lists etc even though they do not subsequently work.

When I send though it seems to think I do not have the correct Virtual domain list either configured or the path to it is incorrect.

I am still not "Linux aware" (Linux capable...;-)) enough to get to the bottom of it unfortunately. ( I have been learning fast over the last few months though!)

I also upgraded Virtualmin to the latest version in the hope that may fix it but no joy again.

I am now worried that in all my tinkering I may have completely misconfigured it to the extent that debugging it may be difficult in its own right.

Would it be best to completely remove mailman and try and start again? If so what is the best way to do that?

Sun, 07/09/2006 - 16:43
PaulDuffield

Hi Joe,

Are you still about? Just wanted an opinion on how best to remove mailman (just zap the folder? or does that leave legacy stuff hanging about?)

Paul

Mon, 07/10/2006 - 11:40 (Reply to #11)
Joe
Joe's picture

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.

--

Check out the forum guidelines!

Mon, 07/10/2006 - 11:41 (Reply to #12)
Joe
Joe's picture

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.

--

Check out the forum guidelines!

Thu, 07/13/2006 - 15:40
PaulDuffield

Thanks for the suggestions here Joe. I will dig deeper and try go get my head round this in more detail. Just recovering from dealing with and exchange server crash which lasted all day in terms of a fix though so it will have to wait till morning now :-)

I will feedback with anything I can come up with.

Cheers for now,

Paul

Sun, 08/06/2006 - 14:47
PaulDuffield

Hi Joe,

I have done some digging, reading and reinstalling but not a lot wiser! Some progress now as I can now get virtualmin to display and manage lists etc. and mail distributes to the relevent email addresses.

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)

The problem seems to be that a user and group called mailman needs to be created and used(I have done this) as that is what the default cgi scripts expect.

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 rhel package though uses the data directory separate from the program files though... usr/lib/mailman and var/lib/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"

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

If I were to set up mailman as a webmin user to carry out the installation it becomes very difficult to work out what permissions to give and I am reluctant to do that in case I inadvertantly create a security loophole.

I could follow the mailman instruction manual and install just using the OS in usr/local/mailman and follow their instructions but I suspect that using virtual min will make it easier to manage lists etc and other items down the road.

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

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

Any further thoughts appreciated!

Sun, 08/06/2006 - 17:59 (Reply to #15)
Joe
Joe's picture

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.

--

Check out the forum guidelines!

Sun, 10/22/2006 - 05:29
JohnBransford

Uhh...

So what is it we should do? Can I have the condensed version updated to now?

I didn't know that mailman was broken under Virtualmin. It works fine in Cpanel I think so its not virtualhosting but something less vague maybe.

Sun, 10/22/2006 - 13:42 (Reply to #17)
Joe
Joe's picture

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

--

Check out the forum guidelines!

Sat, 12/22/2007 - 17:18 (Reply to #18)
fuzzie

I'm trying to convert some cPanel accounts to virtualmin servers, and the migration is choking on Mailman.

Failed to create [listname] : List creation command failed :
Is there a way to migrate these lists?

Topic locked