The missing updates: Exim, Proftp and MySQL

[NextIT]

During a fresh Directadmin installation on a Debian system a few programs such as Proftp, Exim and MySQL are downloaded from files.directadmin.com as a tar.gz file or as a DEB package. These packages are defined in a distro-specific files.sh file, for example: http://files.directadmin.com/services/debian_6.0/files.sh. For other distributions the list of custom packages seems to be even larger.

Those packages are downloaded and installed during the Directadmin installation process, but a predefined method of keeping these packages up-to-date seems to be missing.

The best practices on keeping your system up-to-date and secure (http://help.directadmin.com/item.php?id=247) are only mentioning the distro specific package managers (apt, yum, etc.) and the applicable custombuild commands. If only those two methods are used by a system administrator on a regular basis, they will eventually end up with outdated versions of Exim, Proftp and other services.

Currently, I have two questions about this issue:

1. What would be the best practice of keeping these custom packages up-to-date? Shouldn't the documentation be updated on this to prevent users from running outdated software and exposing them to the resulting security risks?

2. Why do we have these custom packages at all? Most of these programs seem to be present in the distro specific package repositories, or can optionally be build using custombuild. Why not let custombuild install and update these programs, or install them from the vendors repositories.

One urgent advice I would like to give to Directadmin users is to check their versions of at least Exim and Proftpd, as these are normally exposed to the Internet. Proftp had some nasty security issues over the past years. I suspect that there are a lot of sysadmins out there that presume their systems are up-to-date, but in fact are running vulnerable services.

 

[Arieh]

Its a bit of a gray area for me as of how things are at the installation, but at the moment I've got the newest versions of proftpd/exim/mysql (and dovecot, apache php, etc) all installed trough custombuild. As explained on the ?id=247 page I got the cron enabled and I receive an e-mail when theres an update.

The only service I know of not maintained by DA would be bind. It may be a good idea to add it to custombuild. Not sure if there are more users who feel the same. Right now I'm keeping tabs on the bind versions myself and compile it from source when theres an update. I don't like to wait for debian to update their archive, especially when theres a security issue to be fixed.

 

[scsi]

If you use custombuild you should have no problems keeping anything up to date. Learn how to use it.

 

[NextIT]

If you use custombuild you should have no problems keeping anything up to date. Learn how to use it.

I am just wondering, what is the point of providing custom packages if the installer could use the custombuild installer in the first place. That would provide an easy to maintain system straight away.

 

[NoBaloney2]

If I'm understanding you correctly, those are the files custombuild is using.

Jeff

 

[DirectAdmin Support]

Hello,

Custombuild is a newer tool than the older deb method. Since the deb files are already setup and in place with the installer, they're still used for the initial install, as they also setup things like new system accounts, man pages, boot scripts, configs, etc... and will work (avoiding potential compile errors)
However, custombuild is probably your best bet for keeping them updated, eg:

cd /usr/local/directadmin/custombuild
./build exim
./build proftpd

If they need to be turned on:

./build set exim yes
./build set proftpd yes

Once enabled, they'll be part of this:

./build all d

As for enabling them by default, we're currently considering including proftpd as "on" by default, since it rarely, if ever has compile issues. Exim, on the other hand, has many more dependancies and library requirements, and usually takes a few tries to ensure everything it needs is there.. hence we likely won't have it enabled by default in custombuild (unless we add many checks and auto-installer options, which starts to get beyond the scope of custombuild).

Custombuild saves us an immense amount of time for updating services, as we no longer need to create a new package for every single OS we support.. for every single new version, of every service that comes out. Custombuild is OS also independent, so our 1 versions.txt update works for all our supported systems.

John