After each micro-update from Parallels, ProFTPd fails with the following errors produced:
Code: Select all
Fatal: unknown configuration directive 'ClamAV' on line 2 of '/etc/proftp-asl.conf'
Code: Select all
# yum reinstall psa-proftpd
Code: Select all
Fatal: unknown configuration directive 'ClamAV' on line 2 of '/etc/proftp-asl.conf'
Code: Select all
# yum reinstall psa-proftpd
Yes, also see https://www.atomicorp.com/forum/viewtop ... =18&t=5603chrismcb wrote: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.Code: Select all
Fatal: unknown configuration directive 'ClamAV' on line 2 of '/etc/proftp-asl.conf'
I recommend monitoring service availability.chrismcb wrote:This can go on for hours if no-one picks up on it...
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.chrismcb wrote:is there anything that can be done to allow for cross-compatibility with the original ProFTPd and the ART version?
Code: Select all
#cat /etc/proftp-asl.conf
<Global>
ClamAV on
ClamServer 127.0.0.1
ClamPort 3310
</Global>
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.Or is there some other solution that Atomicorp can come up with to ensure Plesk doesn't reinstall its own ProFTPd?
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.mikeshinn wrote: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.
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.mikeshinn wrote: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.
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.mikeshinn wrote: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