Hi,

After each micro-update from Parallels, ProFTPd fails with the following errors produced:



Each time, the only thing I can do is to reinstall psa-proftpd.



This can go on for hours if no-one picks up on it... is there anything that can be done to allow for cross-compatibility with the original ProFTPd and the ART version?

Yes, also see viewtopic.php?f=18&t=5603



I recommend monitoring service availability.



Plesk micro updates don't use RPM (boo!), so that sadly rules out a solution via RPM triggers. But it sure is annoying to have to remember to reinstall proftpd after every micro update.

Yeah, there are monitoring tools set up, but there aren't always people poised to reinstall a package at every hour of the day.

Can the line in question that it breaks on (with the subsequent lines the same if it got a chance to parse them, I'm sure) be moved elsewhere to at least ensure FTP services stay up - then a reinstall can be done manually after the update to get the ART release?



Or is there some other solution that Atomicorp can come up with to ensure Plesk doesn't reinstall its own ProFTPd?

The problem is that Plesk doesnt honor package management when you use their microupdates (if you use yum you're good). So we are in fact doing it correctly, they just blindly ignore the systems configuration and clobber things. We recommend you open a case with them to not do this, when they use rpm these things are taken care of automatically, but the microupdate system from PArallels doesnt. They've been scolded many many times, including back when Scott and I still owned Plesk that not do this. But some developers just don't care, so keep hounding them to drop this backwards system. They have a great package management system, they just dont use it for microupdates.

Anyway, this FAQ is the simple procedure to fix their poor package management:

https://www.atomicorp.com/wiki/index.ph ... sl.conf.27

Which is just to run this command as root:

yum reinstall psa-proftpd psa-proftpd-xinetd

While of course you are correct that it's bad that they're bypassing the package manager with their micro updates it's the users of the Atomic repository that suffer, because now they need to know about incompatibility between installing micro updates and a package in the Atomic repository.



While I agree that Parallels switching to using the package manager again for their micro updates (they used to ship RPM's back when micro updates were still called hotfixes!) would be the ultimate solution and of course Plesk users should bug Parallels about this, it would be nice if it was possible to do something in the psa-proftpd package to prevent proftpd from breaking. I'm sure Atomic users and ASL customers would like that.

After all Atomic is upgrading one of the Plesk packages here with a modified version and I can very well understand that maybe Parallels won't support people who do that. Or is it really just impossible to prevent micro updates from breaking the Atomic version of psa-proftpd?



Sadly you'll have to run that after every subsequent micro update, as all previous micro updates get reapplied when upgrading to a new micro update.

Possibly, with something we can do in the kernel. It would make it look like the micro-updates were being applied but would silently (exit 0) fail.

Would this kernel-level tweak stop ALL micro updates? or just the ProFTPd one?

The updates are good and useful - they do allow us to turn them off anyway, so a selective option would be best.

Lets just say I call it the "Nuclear" option

So we've added in new self-healing rules, which amongst other things, can analyze logs and take corrective action on the system to repair things, fix things, etc. We've added in SH rules for the psa-proftp Parallels bug, and some others.

If there are events you want us to analyze and for ASL to take action please let us know. As we discover things we think ASL should self-heal on the system, we'll add them in.

A self-healing rule for qmail-scanner breaking would be cool: https://www.atomicorp.com/forum/viewtop ... f=4&t=5560