• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Mailman not working after updating to 9.0

U

unco

Guest
Hi -

A customer has let me know that Mailman's not working anymore after I upgraded to Plesk version 9.0. She now gets this error:

preline: fatal: unable to run /var/qmail/bin/mm_wrapper: file does not exist

Relevant info:
Plesk version 9.0.0
Operating system Linux 2.6.18-92.1.10.el5 (CentOS 5.2)

We're using qmail. The only place I find mm_wrapper is in /usr/lib/plesk-9.0/mm_wrapper. Mailman worked fine before the upgrade. Luckily, there's only one customer using it on this server.

I'm not sure where to start! Any clues will be appreciated.

Thanks,
Beth
 
I'm having the same problem on Fedora Core after upgrading to version 9

Here is the uname -a 2.6.9-023stab043.1-smp #1 SMP Mon Mar 5 16:35:19 MSK 2007 i686 i686 i386 GNU/Linux

Anyone who sends messages to any of the mailing lists they get this.

Hi. This is the qmail-send program at ip-xxxxxx.ip.secureserver.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[email protected]>:
preline: fatal: unable to run /var/qmail/bin/mm_wrapper: file does not exist..

I have tons of users on the mailing lists i really need help ASAP..

Thanks..

Tyler.
 
Lord I am tired of cleaning up after Parallels giant messes!

Now I have to wake these brain cells up, but it seems to
me when we were fixing Mailman before in 8.X or 7.5.X that
Plesk was rigged where there was a universal wrapper in one
spot but all the individual domains had their own. Looks like
whatever was there has been totally wiped out, without even
the courtesy of saving it as a backup! Or at least telling us
in advance so we could make copies to help now...

The wrapper was to have qmail call sendmail since Mailman
freaked on that, but now it appears from scoping out that
directory in the error message we're all getting that it's been
re-centralized back into the mail Qmail setup where there's
no hint of a wrapper? So we need to write our own to go
there and form some kind of symlinks in the directories for
the existing stuff since it's gone and Plesk seems to expect
that you'd use the new mail MTA instead?

All stupid to me, but there's the starting clues while we
work on it here. Been swatting flies for a freakin week on
this while fielding calls from really (*#$(* people we shouldn't
have to deal with after a BETA period!

Somehow the wrapper's gotta define the mail calls under
Qmail to pull up the fake Sendmail still in Plesk to send out.
And/or it's related to the no outbound errors in other posts
here in the Forums, not sure about that. But I remember
hand writing the first wrappers till a later verion of Plesk
actually did it itself - now it doesn't again for older stuff
yet they ripped out it's support AND it's file. Nice going!

There's a start, anyone go from here? I think we did this
over at EV1/The Planet's forums at the time too... Have to
go dig there for our old posts.
 
OK, this is going to be a two-part reply but I'll try to edit this same
post if I can get away with it so it makes sense... NOTE: You are
at your own risk and on your own, I'm sick of waiting for no answers
and the crappy Parallels support for all this so what you read is what
I tried, could break again tomorrow or not be 100% accurate. So if
you give it a shot or build off of this, save the flamewar bits if it doesn't
work right! Just tell us how it should be and we'll go from there.

Found fixes from all the way back to 7.5 to replace the mm_wrapper
file and compile it. Guess what? It's asking for gcc to compile it and
it appears the wonderful (#*$() at Plesk left out all the compilers!

[This was done on a Fedora 8, Plesk 9.0.X box w/Xmas Day's updates]

First, start with this:

yum install gcc

No idea if it matters, but I did this as Root from the / root dir
on this server instead of down in the Qmail area to keep this
from getting any worse...

That'll get your compiler installed to be able to take care of the next
step, this fixes the wrapper problem but then you're ending up with
the mail stuck in the Mail Queue, presumably from the OTHER problem
here in the Forums about the fact that nothing can seem to send out
of the box anymore since this lovely upgrade! See if you can think of
what I'd like to type here in Parallel's direction...

Meanwhile, the mm_wrapper fix courtesy of a Google search:

#include <errno.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
int main(int argc, char** argv, char** env)
{
if (setregid(110, 110) != 0) {
}
(void) execve("/var/qmail/bin/mm_wrapper-real", argv, env);
/* Should not get here */
}

This should be saved as mm_wrapper.c in the /var/qmail/bin
directory for you to compile from right there. How do you get
it in there you ask? Well see more of the crud Plesk never has
in it's docs, they replaced PICO/PINE with it's later version,
Nano.

So you start with "nano mm_wrapper.c" and follow nano's
easy commands to write and save it where it belongs.

Now we have the wrapper code written for Plesk, Lord
knows if it works but when I saw a test mail end up in the
queue, it works for me and I'll gladly post corrections up
here if you post'em in this thread.

Time to compile and chmod to lock it in:

# gcc mm_wrapper.c -o /var/qmail/bin/mm_wrapper

File's complied, the original C file will still be there, just
leave that be and get on to koshering up the compiled
version:

# chmod 6755 /var/qmail/bin/mm_wrapper

That should turn your compiled file red, it does have a 6 in
front for those of you thinking it should be 0755 - it ain't.

That's it. No reboot unless you feel like it and that at least
got an existing List semi-functional, below I seriously hope to
find the patched solution for the outbound Qmail so that our
lists make full circle!

[OUTBOUND FIX OR LINK TO FORUMS POST WILL BE HERE]
 
Well so far this and today's update - nothing. The rejections stopped
showing up from the Lists, but the mail now blackholes to nowhere. And
at this point the update didn't fix anything save maybe the spamassassin
but because we stayed with Qmail - didn't bother us one bit.

So for now that update setup previously posted is in limbo, I tried the
file replacement mentioned elsewhere on outbound e-mail and it's not
doing anything to the Mailman lists at all!

Still hunting for clues.
 
I opened a per-incident ticket and have not had a response. As soon as I get one, I'll let you know.
 
LOL, well thanks for the effort! They're notoriously slow since doing
this to us for sure...

Sadly I've just noticed that ALL my e-mail is DOA again! It was working,
I was having a conversation with someone that means it should've been
working fine since he's one of our domains and was using his Horde
account... but I just checked my server mail with Vista's Windows Mail
and even the spammy account is empty. Totally void. Meaning all the
mail processing is dead and that explains the empty queue.

Got this clue from the fact I went to spam training to see how it was
doing on an account and it was again - empty. This is one of my
spam-bait accounts that should draw hundreds of mails a day - nada.
Not one. Meaning it's stopped, even after a reboot and upgrade earlier.

And now I've got it telling me there is more upgrades? This is got me
on the final edge of picking something else and living through the hell
of migration instead of dealing with slop like this.
 
I'm just checking back to see if anyone's been able to resolve this. My CP kept telling me there were updates to do, but it wouldn't complete them. I finally ran updates at the command line. Still though, no mailmain lists are working. There's also been no response at all to my paid ticket.

The paid ticket was a credit from the last time I paid and nobody could fix my problem!
 
Nope, I keep getting that same annoying update bug, do the update - nada.
So I think it's a false trigger and you just gotta check the CP every once in
awhile to see if there's really an update or not - plus keep tabs on the Forums
for discussions about new stuff being released.

All our Mailman's are DOA as well, really whizzin me off and to hear Parallels
did this and then can't even help you resolve it is outrageous! Quality all the
way, sheesh.

First off, I tried a couple of the 'can't send out internal e-mail' workarounds
here on the Forums that allegedly work - they don't. Instead it jammed up
my Qmail for 12 hours til I found out it stopped and wouldn't restart until I
put the original file back into place that the workaround had me replace with
an older 8.6 copy that'd allegedly kick it in the butt and make it work right.
Didn't happen at all. Now I notice some programs in Plesk ARE sending out
mail just fine like Watchdog, etc? But yet others like AtMail, Horde and things
like that can't with this bug? Makes no sense at all!

Far as I can tell it all comes down to the handling and sadly Steve Freegard
the author of Mailman doesn't use Plesk and there's little clues on their group
about it either. They have done some papers on it but they're all based on
Qmail and versions 7 & 8 - not this mess in Plesk 9! And certainly none with
Postfix related to 9 if you went that route instead of keeping it on Qmail.

All seems to come to one point - mail handling. Kinda like the way the
Spamassassin now does stupid things instead of straight drop/rejections
without clogging up your mail system! The posts are coming in, I see them
in the Mail Queue sitting there and waiting with no real clues on them as
to what's dropping out. I'm digging through the logs but can't find where
those post mails are being processed and the resulting errors we could
possibly fix or get a workaround.

I tried the old wrapper stuff - didn't work. No errors, but it's like the
post mail comes in and can't go any further as nothing picks it up to be
processed. The mail accounts aren't really there, so it can't reject them
as undeliverable because the account 'exists', but yet it's not in our CPs
so therefore it's not a real mailbox or forwarding account we can do
anything with either! Maddening!

So we need to locate what was changed from 8.6 to 9.X that used to
pick up mail for that specific mailing list account and process it, a job
formerly done by the 'wrapper' because that's the way Mailman does it.
Steve can't make a link between Plesk and Mailman because he doesn't
use it though I'm about to ask him if he'll go into one of our boxes and
screw it up til it works!

Downside - next freakin blundering Plesk upgrade may wipe out the
very same files we manage to create as a workaround requiring either
reinstallation of them or another workaround modification - all not really
worth it thanks to Plesk.

Wish I had better news but that's where we seem to be at!
 
Ok, I compiled the new mm_wrapper and put it in /usr/lib/plesk9.0 and now i get no error but nothing happens.. I tred a few different premissions and still no joy!!! Not sure where to go from here..

Are their moderatiors from parallells that post on here? Seems kinda weird all that would turn up would be a google search.. come one! I'm not about to pay for support,, i already pay a monthly fee for the damn server and the people at godaddy where NO HELP! and then i treid to submit a ticked to Parallels and they want me to buy a service plan! come one.. Thanks for the help tho..
 
Welcome to hell, ice water's $75/Hour! Yes there's some Parallel's guys
around here but never expect them to post much because they're all
into getting us to pay for the support. Bleed both sides of the fence
seems to be logic.

We're on our own with this, I'm where you are trying to determine what
part's dropping out they didn't properly plan for. Are you running Qmail
or the new Postfix MTA?

The main problem is because Mailman's a 3rd Party software, even though
Parallels did this in their own OS, they'll disown the whole thing and work
on a resolution ultra slowly because there's so much else wrong right now
in 9.X. That's the logic, it ain't ours so you're on your own even though
you didn't install it - we did.

Somehow the wrapper's not totally right or we're hitting a wall on mail
delivery where it's coming into the MTA but not going out properly, like
a mailbox it creates for the account you use on each list doesn't exist.
It doesn't, it's imaginary and not in our CP's to manipulate which means
it's all in the file level and somehow we've gotta determine where the
black hole is. If Parallels screwed with the entire mail system regardless
of MTA to the point the accounts made for the list aren't right - that's
it but it's beyond me how to fix it!

I tried making a new list to see if that was the case, where old imported
lists and their respective e-mails were an issue but the new one doesn't
work either. It's like it hangs in the mail queue showing it's in the system
but never reaching the final destination because it's not erroring out
either.
 
Its qmail... it looks like the /usr/lib/plesk9.0/mm_wrapper is gone.. when i replaced it with the above .c and compiled it now i dont get an error but still don't have any e-mail going to the lists. i think its just a matter of getting the correct wrapper installed, and with the correct premissions.. does someone have a copy of the mm_wrapper from plesk 9.0 i could drop in their? also what are the premissions? i think i have them root:root 6775
 
It looks to me like that version of mm_wrapper mentioned above just adds a function to mm_wrapper and then points it back to the original file.. which is renamed mm_wrapper-real..

Don't think that will help if the file is missing all together, i did a search on the system and couldnt find anything like it.

I downloaded Mail Man and looked at the source and the mail-wrapper.c is much larger then the one in the post, i tried to build it on the system but their are tons of things i need and don't really want to mess with, As i shouldnt have to mess with!! A COMPANY SHOULD SUPPORT ITS UPDATES!! or not offer them... So i guess the next step is to find a system running plesk 9 and look for the file and just copy it into place and see what happens.. can someone help? i need
/usr/lib/plesk9.0/mm_wrapper thanks..

Tyler.
 
You've hit the entire problem - Parallels won't touch this without someone
paying them for support, which is ridiculous because they did this to start
with.

There's no mm_wrapper in 9.X to mess with, that's the whole problem! What
we'd be more likely to need is an 8.6 version of that same file where we could
examine what was working instead. Trying to hunt that down now, I know I
got another fix file from the 8.6 version that didn't work, but the same method
for extracting it and then examining what's up might help.

Simply replacing it with the 8.6 won't work, just like the other workaround for
local mail delivery. Made more of a mess than anything else. One problem may
be that the 9.X version isn't making or even acknowledging the fact there are
list e-mails that don't appear in our CP! If that's the case - we're screwed till
they fix it and if they go postfix and leave us for dead with Qmail - we're hosed
permanently without a patch. Any new patches Parallels makes could easily
wipe out what we fix ourselves, meaning it has to be redone each and every
time after an upgrade AND pray the upgrade doesn't change something important!

The mail's getting into our systems in the queue, then as you mentioned, not
being handled by that wrapper or something else. The version of the wrapper
I got and put back in there as mentioned here seems to be doing what it should
but it's almost like Plesk doesn't have the needed accounts anymore? And the
new version of making a Mailing List doesn't make them either?

Only thoughts I have at the moment beyond the 8.6 version to look at the code
would be that we may have to manually make the accounts in our CP and just
like turn off their mailboxes and all of that? Don't know why they're not in there
to start with so we can use the spam and other options on them!
 
Any update on this? Apparently 9.0.0.2 does not address the issue. I've seen in other threads people have tickets open for the same issue. You'd think with multiple people with paid support tickets open this item would get fixed. I see nothing's changed but the name since Parallels bought out SWSoft.
 
I've had no response. I set up another server just for people who have mailing lists and moved their data over to that machine.

I'm still not at 9.0.0.2 and am frustrated because I can't get this update done. I've downloaded
parallels_installer_v3.4.0_build081115.22_os_CentOS_5_i386

All I get is "The component base is already installed."
 
I have it working

After it broke for me yesterday, I copied the mm_wrapper from a Plesk 8.6 server. It's now working.

Other stuff I had to do to fix mail in general: start the plesk-specific spamassassin and add *all* the local IPs in the IP whitelist for the mailserver (to get around the 553 relay error) especially the ones any VPN software may install (I used 192.168.0.0/16).

I also got procmail running again by changing .qmail to the following:
| true
|preline /usr/bin/procmail -m -o .procmailrc

All in all, a costly upgrade in downtime, but at least it's working now.
 
After it broke for me yesterday, I copied the mm_wrapper from a Plesk 8.6 server. It's now working.

Any chance you could attach a copy of the file or the contents as well as the permissions for mm_wrapper?

I don't have access to a Plesk 8.6 server at the moment.
 
This appears to be fixed by symlinking the new file to the old...

http://forum.swsoft.com/showpost.php?p=221856&postcount=19

Ok, I did manually fix that bug earlier, but it was not my only problem. What I did was to add a symlink to that file in the directory mentioned in the error message. The only place I found that file was in /usr/lib/plesk-9.0, so I did something like:

cd \var\qmail\bin
ln -s /usr/lib/plesk-9.0/mm_wrapper mm_wrapper


That did get rid of that error, but there appeared to be other problems.

Do an updatedb and then locate mm_wrapper and see if you find it the same place I did. If you did, add the symlink.
 
Back
Top