Greylisting at Plesk 9.2.1 fails!
Hi there,
we've upgraded a server to Plesk 9.2.1 yesterday and it look pretty good.
When I tried the new greylisting feature, a error is upcoming whcih tells me, that there is a file missing:
I checked and it's really not there:
/opt/psa/admin/bin/glmng
The file is not there, can anybody confirm this?
ys
Manuel
Nope. It's there for me and it seems to work too.
What OS and Plesk version before upgrade?
Same here, the binary glmgr was not installed. Upgraded from 9.1 to 9.2.1 on CentOS 5.2.
I ran autoinstaller again and now its here.
But some other crazy problems: mailserver crashes totally... serious authpsa processes and relaylock`s.
they drive the machine to 100% usage; i changed configuration and set a maxmimum of 4 processes in /etc/courier-imap / /etc/xinetd/psa_smtp
but login is not working and I can't find why
clients getting angry
I just had the exact same problem. After a few restarts of qmail and courier-imap and killall relaylock and authpsa processes, it now seems to be holding.. but I'm guessing it will just happen again.
I noticed the problem is related with the poplock database, those stale processes are spinning around /var/lib/plesk/mail/poplock/poplock.db and /var/lib/plesk/mail/poplock/poplock-journal.db.
no sig. just sigh.
migrate to postfix (and then back to qmail)
but postfix is stable in this version. love it and will upgrade all servers this night!
ys
manuel
Solution: upgrade with '--force' option the package psa-mail-(qc|pc)-driver or upgrade Plesk via autoinstaller.
Excuse me for my english
Can i do migrate to postfix is i use imap with qmail ?
I don't lost my email ?
Run the autoinstaller from shell and select postfix
Postfix does not support account logins with short name, so it's not an option when clients already use short names. Installing postfix and then qmail again, via auto-installer, did not fix the problem.
no sig. just sigh.
Same problems here! I've updates Plesk last night from 9.0.1 to 9.2.1
Today the server reached high loads. I've even seen a load from 166! the highest load the server normally has, is somewhere between 2 and 4.
I'm now trying to install postfix through the installer, and than switching back to qmail.
Every time the loads get high, I have to "killall authpsa relaylock" and than it gets quiet for a while.
I hadn't had this problem in version 9.0.1
Installing postfix and then switching back to qmail did not work for me. I have purchased a support ticket with Parallels yesterday, but so far they seem to be clueless. Lousy software, lousy support. I thought that after paying I'd have this fixed in no time, but not even in that case. Just sad.
no sig. just sigh.
I've installed postfix, and keep on using that. My server is even less loaded than when i used qmail.
I've informed all customers to use full emailaddres as username.
Hi there,
we use postfix now on all our machines and are very satisfied. Load is much lower than ever before; we asked ourself a couple of days ago, if we should upgrade our hardware.
with postfix now, I think we can use the hardware for another 1,5 years.
But we still have trobules with mailbounces (see http://forum.parallels.com/showthrea...t=85508&page=4)
ys
manuel
Manuel,
Why don't you just use a drop-in graylisting system for qmail??
Something like SpamDyke. . .that's what I use, and it works like a charm!
- Eric Gillette, GSolutions Online LLC
Getting the same issue here - I've seen CPU usage up to 600% (!!!) When I manage to get in to run a ps, there are dozens, perhaps hundreds, of authpsa relaylock processes. Unfortunately, I couldn't even kill them - four times I had to do a hard reset. This would happen every few hours, randomly, usually after I have gotten comfortable for the evening.
Temporarily disabling relaying via POP AUTH has stopped the errors, but this isn't exactly a solution since I don't feel like calling a few hundred people and telling them that they now have to login to relay mail. Another week, another great opportunity of getting bitten by a Plesk upgrade. (which mind you, I was installing to get rid of an issue from the *last* upgrade)
Remind me why I pay for this privilege again?
SpamDyke. . .
Like I said before. . .SpamDyke will solve that problem. SpamDyke is a drop-in that interfaces with Qmail, and can even take care of POPAUTH for you. I've been using it now for the past 2 years. Trust me it works. There's a very good chance the reason why POPAUTH is staying open is because the connection isn't being closed. SpamDyke prevents that by forcibly closing the connection if the sending server doesn't "talk" after a couple seconds.Originally Posted by twwheeler
Here's a snapshot from my server's /var/usr/local/psa/var/log/maillog:
May 5 04:12:16 [hostname_removed] spamdyke[20335]: DENIED_GRAYLISTED from: 8mh3v6-32vof-6vwu1-95cjjo-keo15x-h-m...ounce.ed10.net to: rwoo$
May 5 04:12:59 [hostname_removed] spamdyke[20441]: DENIED_RDNS_MISSING from: krystyna.viola_kk@jax.sysco.com to: egillette@[hostname_removed].com origin_ip: 124.59.43.30 origin_$
May 5 04:13:26 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 80.86.159.130:19269 (not defined)
May 5 04:13:28 [hostname_removed] spamdyke[20449]: DENIED_RDNS_MISSING from: bsbyb@boylesports.com to: egillette@[hostname_removed].net origin_ip: 80.86.159.130 origin_rdns: (un$
May 5 04:13:35 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 77.35.38.180:22534 (not defined)
May 5 04:13:37 [hostname_removed] spamdyke[20437]: TIMEOUT from: (unknown) to: (unknown) origin_ip: 85.137.88.184 origin_rdns: 85.137.88.184.dyn.user.ono.com auth: (unknown) r$
May 5 04:13:37 [hostname_removed] spamdyke[20452]: DENIED_RDNS_MISSING from: tempo.libero@quadrifor.it to: egillette@[hostname_removed].net origin_ip: 77.35.38.180 origin_rdns: $
May 5 04:13:44 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 193.200.32.33:5871 (not defined)
May 5 04:13:45 [hostname_removed] spamdyke[20455]: DENIED_RDNS_MISSING from: rtbpijocya@bmssin.com.sg to: egillette@[hostname_removed].net origin_ip: 193.200.32.33 origin_rdns: $
May 5 04:14:06 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 193.200.32.33:1659 (not defined)
May 5 04:14:06 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 67.219.103.18:3641 (ymail01.bwpbrands.com)
May 5 04:14:07 [hostname_removed] spamdyke[20467]: DENIED_GRAYLISTED from: simplyautos@ymail01.bwpbrands.com to: egillette@[hostname_removed].net origin_ip: 67.219.103.18 origin$
May 5 04:14:08 [hostname_removed] spamdyke[20468]: DENIED_RDNS_MISSING from: jyffd@bradley-homes.com to: egillette@[hostname_removed].net origin_ip: 193.200.32.33 origin_rdns: ($
May 5 04:14:13 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 67.219.103.18:4901 (ymail01.bwpbrands.com)
May 5 04:14:14 [hostname_removed] spamdyke[20473]: DENIED_GRAYLISTED from: simplyautos@ymail01.bwpbrands.com to: egillette@[hostname_removed].net origin_ip: 67.219.103.18 origin$
May 5 04:14:21 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 67.219.103.18:2169 (ymail01.bwpbrands.com)
May 5 04:14:21 [hostname_removed] spamdyke[20476]: DENIED_GRAYLISTED from: simplyautos@ymail01.bwpbrands.com to: egillette@[hostname_removed].net origin_ip: 67.219.103.18 origin$
May 5 04:14:26 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 193.200.32.33:1035 (not defined)
May 5 04:14:28 [hostname_removed] spamdyke[20479]: DENIED_RDNS_MISSING from: ipydeo@bluecom.fi to: egillette@[hostname_removed].net origin_ip: 193.200.32.33 origin_rdns: (unknow$
May 5 04:14:28 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 67.219.103.18:3347 (ymail01.bwpbrands.com)
May 5 04:14:29 [hostname_removed] spamdyke[20482]: DENIED_GRAYLISTED from: simplyautos@ymail01.bwpbrands.com to: egillette@[hostname_removed].net origin_ip: 67.219.103.18 origin$
May 5 04:14:38 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 77.35.38.180:23155 (not defined)
May 5 04:14:43 [hostname_removed] spamdyke[20485]: DENIED_RDNS_MISSING from: dgotejxvp@bobyoungprints.com to: egillette@[hostname_removed].net origin_ip: 77.35.38.180 origin_rdn$
May 5 04:15:35 [hostname_removed] relaylock: /var/qmail/bin/relaylock: mail from 77.35.38.180:23728 (not defined)
May 5 04:15:37 [hostname_removed] spamdyke[20630]: DENIED_RDNS_MISSING from: moho@boylesmoak.com to: egillette@[hostname_removed].net origin_ip: 77.35.38.180 origin_rdns: (unkno$
May 5 04:15:42 [hostname_removed] spamdyke[20849]: ALLOWED from: support@endicia.com to: egillette@[hostname_removed].net origin_ip: 65.203.54.5 origin_rdns: smtp.envmgr.com aut$
Yup, that's ALL GREYLISTING done by SpamDyke, which functions a bit better than Plesk's built-in graylisting, and gives you far more control over the things you can do -- best part is. . .it's FREE, and a piece of cake to install.
I wouldn't tout it so hard here, but it completely solved my problems. . .! =0)
Eric:
While I agree that your solution sounds great, I just want the product that we pay (a fair amount of money for) to work as it was designed. I installed Plesk so I wouldn't have to mess with keeping things running, adding my own patches, etc. If I wanted to go that route I could build the system myself and save a good deal of cash.
What would be nice is a vendor that would test their damn updates. Obviously this authpsa/relaylock issue is a defect, and the forums are lit with people with the issue. Where's Parallels? Raking in paid support calls, I'm sure.
I understand what you mean twwheeler. . .
Yeah, I can understand what you're saying, and it makes perfect sense.
I agree that Parallels should take more of an active approach in testing (and testing some more) before releasing their updates. I mean, there will still be problems naturally, just by the nature of the fact that everyone's setup is different, and what not, but they would sure save most people a lot of trouble by testing ahead of time.
I've basically consigned myself to the fact that no release of Plesk is ever completely error-free upon upgrade.
So now, what I do is. . .I first apply upgrades to a non-production machine, so that when things go for a loop, and get all jacked up. . .clients don't suffer, and neither do our own sites.
I usually wait 4-6 weeks after an upgrade has been released for them to work out all the bugs, and patches, before I upgrade any production machines that contain our sites, or client websites.
It has saved me a whole lot of headaches, because now, I don't have to spend days creating work-arounds for things that Parallels should have addressed before releasing the upgrade.
I remember upgrading Plesk 7.5 to Plesk 8.1, and the e-mail system stopped working (qmail wouldn't even run manually).
You know who my clients called?? Us. Not Parallels. It was a support nightmare.
Instead of spending time developing websites for new clients (our main business), we spent the whole day creating work-arounds for Plesk e-mail problems.
From that day forward, I made a personal vow to myself, that we would NEVER do that again, and we would always first apply upgrades to a non-production machine first, and even then, 4-6 weeks after the initial upgrade's distribution period, to ensure that most bugs are caught/figured out already by other Plesk users.
I can't fault Parallels entirely, since the reality is that they create a software that brings a GUI to things that Server Admins would have to otherwise do manually from within an SSH console. That's a BIG project to get right EVERY time, and for EVERY single upgrade.
But I do believe it is possible for them to produce an upgrade that works on 95% of systems flawlessly; for the most part anyway. I mean if the issues were small issues, like say the issue I had recently where the firewall app wasn't working, and I had to manually adjust the firewall settings from a shell console. . .I wouldn't mind so much. But the problem is that most of the upgrades they produce do NOT work with 95% of systems, and to make matters worse, the upgrades tend to "break" major operating components like e-mail, webmail, or otherwise.
Hopefully, at some point, they'll get it right. . .but until then, my non-production machine testing system seems to have been working, as it allows me to test the upgrades, and see what works / what doesn't work. It also saves me the trouble of having to deal with client support issues for a full day (we have about 80 websites hosted with us), while I could be working on other projects or tasks.
Anyway. . .just my 2 cents buddy! But I do feel your pain!
- Eric Gillette
Posting Permissions
Reply With Quote