DirectAdmin/CustomBuild: Removal of suPHP, mod_ruid2, mod_php, MySQL 5.5/5.6, MariaDB 5.5/10.0/10.1/10.2

smtalk

smtalk

Administrator
Staff member
Joined
Aug 22, 2006
Messages
10,629
Location
LT, EU
DirectAdmin intends to remove support of some outdated software:

* suPHP - (EOL 2013) - DA support will be dropped on 2023-01-01
* mod_ruid2 - (compatible with CentOS 7 only) - DA support will be dropped on 2023-01-01
* mod_php - DA support will be dropped on 2023-01-01
* MySQL 5.5, 5.6 - (EOL 2018-2021) - DA support will be dropped on 2023-04-01
* MariaDB 5.5, 10.0, 10.1, 10.2 (EOL 2020-2022) - DA support will be dropped on 2023-04-01

We anticipate this will affect only a minority of customers. With the next release of DirectAdmin, we will begin to send notifications through the DA Message System if any of these components are used.

We also invite feedback on other software that is not actively developed any more: webalizer and SquirrelMail, for example. Is anyone relying heavily on them? If convenience measures were provided, such as import functionality of SquirrelMail contacts to RoundCube, would this be seen as a good way to drop support for outdated software?

Are there any other components you see as outdated? Would you like to have a replacement for them?
 
Very good idea! While you're at it maybe add Majordomo to the list as well? Created a feature request about a possible Majordomo replacement a while back.

Webalizer and SquirrelMail can be dropped without a problem, it's a bit weird Webalizer is still installed by default nowadays.
 
Last edited:
Very good idea indeed and good that it's announced on various places.
I guess only customers with ancient stuff might have issues with that, so I guess there will be some complaints. :)

We only used mod_php and mod_ruid2 on the Centos 7 servers as backup when php-fpm was doing weird again. That issue is still not solved but happens seldom and seems fixed in php 8.1 anyway so we stopped using the alternative mathod. I don't mind being it removed.
Squirrelmail we used in the very beginning until it had an issue and since then we're running Roundcube. Are there even people using Squirrel still?

As for webalizer, it wonders me a lot that it will be removed as this is still installed by default like @tristan mentioned. Or rather, that defaulting to awstats was not done way earlier.
I surely support removing it in favor of awstats. Even more if there will be an easy method to remove webalizer and leftovers of it in userdirs (if that won't break their stats).

So yes with convenience measures taken where needed, I'm all in favor too. (y)
 
I don't see any problem with abandoning the old MySQL versions. But as for suPHP, I am very disappointed. We have been using suPHP for xx years. It is simple, secure, stable, without any bugs (and also has a fork: https://github.com/lightsey/mod_suphp - John Lightsey from cpanel would have corrected the error if anything came up). Much better than php-fpm in my opinion. What does he bother you with? Will the only option be to disable DA updates and set chown to the custombuild folder?

Generally, I can't imagine fpm migration. Apart from the other php.ini entry of users (let's say that it can be converted), first of all, changes to the PHP version were made through entries in .htaccess. Everything will die. Could you foresee some "native" option to stick with suPHP? Let's say put the "other" PHP option to options.conf and let people choose for themselves whether they want mod_php, suPHP or ruid.
 
Last edited:
smtalk said:
php-fpm isn't the only option, fastcgi is a good replacement for suPHP, isn't it?
Click to expand...
Honestly, I don't know. Once upon a time I tested and the chroot (bubble) didn't work well (mail function didn't work). SuPHP has a built-in chroot and document root checking, everything works perfectly fine. suPHP is a very stable and predictable soft with no vulnerabilities.

It just works as it should. Is it really impossible to leave suphp just by not making it difficult to use? Now we only use the php_expert option to compile / update the PHP version.

Edit: it would be enough to run the command:
./build php_expert 8.1 other
Click to expand...
This would compile version 8.1 and nothing else (no configuration changes). We use cusom templates vhosts anyway, so all changes to e.g. suphp.conf are done manually.
 
webalizer is still useful for ours customer ( simple UI), it easy to use than awstat. but for me awstat is better.
 
erick85 said:
Honestly, I don't know. Once upon a time I tested and the chroot (bubble) didn't work well (mail function didn't work). SuPHP has a built-in chroot and document root checking, everything works perfectly fine. suPHP is a very stable and predictable soft with no vulnerabilities.

It just works as it should. Is it really impossible to leave suphp just by not making it difficult to use? Now we only use the php_expert option to compile / update the PHP version.

Edit: it would be enough to run the command:

This would compile version 8.1 and nothing else (no configuration changes). We use cusom templates vhosts anyway, so all changes to e.g. suphp.conf are done manually.
Click to expand...

PHP-FPM actually has a built in chroot directive

PHP: Configuration - Manual

www.php.net www.php.net

But of course, you have to have a setup chroot setup for each user in order for it to operate correctly.
 
I know it used to be popular, but consider putting suhosin on a watch list too. It was last released over 7 years ago and it looks like snuffleupagus is the next generation anyway.

Some thought is needed for mod security too over the next couple of years. Looks like Comodo WAF is dead:

Is this project dead? - Free Modsecurity rules - Comodo Web Application Firewall

No new rules since Christmas. Should we still rely on this project or not?
forums.comodo.com

And Trustwave is getting out of the business:


Looks like the future lies with OWASP and some alternatives on the horizon:

Talking about ModSecurity and the new Coraza WAF – OWASP ModSecurity Core Rule Set

coreruleset.org coreruleset.org
 
sparek said:
PHP-FPM actually has a built in chroot directive
Click to expand...
Of course I know that. The point is, we have many servers set up, including tens of thousands of vhosts. Users have their PHP versions configured via .htaccess using the AddHandler and php.ini configs. I can't imagine how much time it would take to convert all these entries to a different configuration (and remove them from .htaccess, otherwise there would be a 500 error). In the case of fresh servers, okay, the matter is simple. But for existing solutions it is a nightmare.

I emphasize once again that as far as I understand the decision to remove support from suPHP (it results rather from low popularity, and not that something is wrong with this soft), I only count on not to make life difficult for users and leave them a gate to using anything other than fastcgi and php-fpm. I'm just counting on it.
 
May you clarify - what does "remove support of some outdated software" means -

Can those existing already-installed(s) outdated software(s) run or not?

Or, custombuild will no longer new install those outdated software(s) after the specific date ?

Or, simply no technical support from DA?
 
@ccto
it will no longer possible to install, also of some DA or other package will conflict with installed outdated plugin - they will not patch/fix it.
 
You must log in or register to reply here.
Back
Top