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

so I stopped updating DA for over a year
AAgh maybe that is the reason, the only Centos 6 we have is doing on DA 1643 now, aybe your DA version was just too old
Can you share from which version DA it was upgraded ?
I had disabled updating directadmin on CentOS 6 servers,
How did you do that ? I don't see any option to do that, perhaps with "custom version" option ?
 
Hmm, I take it back. It looks like DA has been updating itself, I just had not paid attention to it. In my memory, DA did not update itself automatically in the past. But since version X (don't know which) it just updates.
DA Last Updated: Sat Nov 5 14:51:09 2022 (1.643)
It is 1.643 which broke LetsEncrypt.
And I checked history for this server, and I can see it was continuously upgraded by me, and also automatically, so I can't say when it switched to automatic updating (all I can see is which date I have which version).
I do say that my customer knows CentOS6 is not updatable, but they are in sort of 'take over' situation, where the mother company keeps saying they will build the same functionality, however it never gets done. It is not really my problem, but I do my best to support them as long as I can.

Let's drop this post about CentOS 6, it is only partly related to this thread. You do can pm me for more brainstorming.
 
I have a question with regards to 'support'. DA will drop 'support'.
Here is my 'what if' scenario.

What happens, if DA updates itself after 1-1-2023? Suppose we get a new binary.
And now suppose I am on a server with mod_php still working (I have many CentOS 7 servers). Can I still add/edit websites which are running with mod_php? Or will the DA binary no longer support it (and thus deny adding/editing sites)?

PS: scrolling back to other comments several people have asked for more clarification.
I also see some texts which are not clear to me.
smtalk writes: "Regarding PHP - CustomBuild/DirectAdmin won't support configuration of it, if you have custom configuration set there it would work, but it would stop working with default configs.
Please make sure there are no if clauses for mod_php, as they wouldn't work anymore :) It would need to be hardcoded to be mod_php"

This makes me understand that the intention of Direct Admin is to completely stop supporting mod_php. We are forced to take some action (not clear which or what, if we do not upgrade I mean). All of my servers (many many of them) need to be upgraded in December. Just one month up ahead notion. Wow. I cannot live with this. I am having trouble sleeping at night since this message has arrived to me. Can we please get more clarity? I would feel a lot better knowing I can still continue to use mod_php, since it is only for CentOS 7 and that ends 2024, so why not let it work (support it) one more year? I never anticipated something like this could be forced upon me, just like this. I just ''happen' to be 'the minority'? I t is a huge impact from what I understand right now.
 
Our clients use and like better webalizer we vote to keep it

We use SquirrelMail as our failsafe backup webmail client and our low bandwidth webmail alternative, we also vote to keep it.
 
Our clients use and like better webalizer we vote to keep it

We use SquirrelMail as our failsafe backup webmail client and our low bandwidth webmail alternative, we also vote to keep it.
I agree 100%.
Squirrelmail is mostly used. Never had problems.
Most people don't use stats anymore, they all rely on stats from third parties.
 
I’m a bit suprised to read that SquirrelMail is still used since the latest update was 11 years agoo_O not worried about security issues?
 
Well in fact not 11 but it was almost 10 years ago in 2013. At least for the stable version. There was a nightly build in October 2021 for php 8 compatibililty. But in fact... al those years no active development anymore, same for Webalizer. Also last stable version 2013 against Awstats in 2020.
I liked Squirrelmail in the past, had a couple of issues in the past, changed to Roundcube and end of problems, never had one again.

Just because of "we use it" (mostly used is probably only on your own server) is not a valid reason to keep unsupported software active in a panel which is not only used by professionals. One would expect that safety is thought of. Which is a valid argument to get rid of both.

Mostly used is Roundcube. Squirrel is less used for a more then a decade and Horde just a little bit more than Squirrel.
You can see it from the table in this post (click).
 
Our clients use and like better webalizer we vote to keep it

We use SquirrelMail as our failsafe backup webmail client and our low bandwidth webmail alternative, we also vote to keep it.
Ooof, your clients are in the wrong decade. Both webalizer and squirrelmail are dead projects. By the time DA removes them it will be over ten years since their last release.
 
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?

We are still using MySQL 5.5. When we installed one of the higher versions before, many of the sites had problems and we had to switch back to MySQL 5.5.
 
@Didyma try to move database to another server with fresh mysql 5.7 or 8, you can add to my.cnf for test at this server
sql_mode = "NO_ENGINE_SUBSTITUTION" and check will it help or not.
 
The number of emails is getting annoying. And we have to receive and check emails, for in case there is a real problem. With the many accounts I have it really adds up.
Do note I am trying to find out how to upgrade, but this means having to check and debug every website of every customer (often some code needs to be tweaked, or it must be flagged as it can not bu upgraded at all).
This will take at least until February. Most likely I am coding and working at Christmas. Not what I had in mind. Just 1 month notice is really unpleasant (using acceptable words).
I do hope Direct Admin is also going to respond to some of the open questions in this thread, I do am waiting for answers. Stress level is rising every day. Why don't we get an answer? ? ?
 
Does this mean that every server that uses mod_php is going to have this mode removed from the server? There are some older applications/servers that cannot do without this mode. What will this mean for all these servers? How do we move away from this mode?
 
Last edited:
Does this mean that every server that uses mod_php is going to have this mode removed from the server? There are some older applications/servers that cannot do without this mode. What will this mean for all these servers? How do we move away from this mode?
Hi Patrick,

I wil try and tell you what I know and do, so far. It may be a guide for you to get started.

Did you install php-fpm yet on your server? Also, check htscanner, it is a module to help you migrate, it can be left out if you are willing to manually remove php_* settings from .htaccess and place them in .user.ini.

Move any PHP settings to .user.ini​

If you’re currently changing any PHP settings in Apache configuration files, move these to a .user.ini file which is picked up by PHP-FPM. So e.g., if you have .htaccess file with:

php_value include_path ".:/php_lib"
php_value auto_prepend_file "autoload.php"
Change it to this equivalent .user.ini file (note the syntax is different):

include_path = '.:/php_lib'
auto_prepend_file = 'autoload.php'


A way how to find these occurrences:
Code:
cd /home
find */domains/*/*html/ -type f -name .htaccess -exec grep -HirE "php.*(flag|value)" {} \;
More on php.net.

You also need to scan your scripts, check if they use Apache specific calls.
* apache_*(
* getallheaders(
* virtual(
A way how to find these occurrences:
Code:
cd /home
find */domains/*/*html/ -type f -name "*.php" -exec grep -H "apache_" {} \;
find */domains/*/*html/ -type f -name "*.php" -exec grep -H "getallheaders" {} \;
find */domains/*/*html/ -type f -name "*.php" -exec grep -H "virtual" {} \;

Suppose your one and only php version is 5.6 with mod_php? I recommend to add a second php version, either 5.5 or 7.0. If you would do so, you then have the option to change (per domain) the php version and test the website. With some clever tweaking you can use a dummy domain, use 'ln -s' to link to an existing 5.6 site and thus test the newer version locally. (you will need unix and scripting experience to do this, it won't work out of the box).

I would not recommend to 'just replace php with mod_php to php with php-fpm'.

One drawback is DA does not support 2 times the same php version, you can not have 5.6 mod_php active as well as 5.6 php-fpm. That is why I would recommend to use 5.5 with php-fpm for testing.

With all of this info you should be able to start migrating. I am doing MANY servers currently, and having the time of my life, since DA only gave 1 month up ahead. And they don't say what will happen 1-1-2023 if you continue using mod_php. Having said that, I am 100% sure not much will change or happen. It is just that you can not change TO mod_php anymore. Or use (switch on) mod_ruid2 (on CentOS 7) via custombuild anymore. But what was working will continue working. But as soon as you make changes in the php version, things MAY go wrong,
./build rewrite_confs may no longer support it (DA: please step in and tell us how you will implement this, what can we expect?).

There is one more script very useful, however it needs to be changed since it only contains maximal 2 php versions.
I upgraded the script to support 3 versions, and it can be modified further to support all 4 of them.
And maybe this script can be of use (but it has no mod_php or php-fpm setting in it).

One more note. You do can switch php versions. Suppose php version one is 5.6 mod_php and version 2 is 7.4 php-fpm. As long as both are upgraded to the latest version, you can use custombuild to swap their places. It will not do any compiling. Do not forget to do ./build rewrite_confs. A reason for doing this is that al of your webapps are using php version 1. (phpmyadmin, roundcube and such). You can't do updates on the webapps, they do check the php version. * after the swap you need to use the change_domain_phpver.sh to change all domains. I found out the best way is to temporarily make a remark of the 2 lines at the end of the script:
#/usr/local/directadmin/dataskq
Doing this enables you to update all domains (use a script, clever copy and pasting may do the job already). And only when done, you would call
/usr/local/directadmin/dataskq twice yourself. DA is running and MAY already see your changes, but that would be no more than a hickup I guess, I recommend to run the script(s) just 1 second after the whole minute has passed, I suspect datatask runds every whole minute (this needs verification).

NOTE: I may have missed documenting details for sure. Those must be minor details I think. You may have custom templates and other changes that will make your situation different from mine.
 
Last edited:
You do can switch php versions. Suppose php version one is 5.6 mod_php and version 2 is 7.4 php-fpm. As long as both are upgraded to the latest version, you can use custombuild to swap their places.
That would be a security issue however, since you can't use mod_ruid2 with a combination of a mod_php and php-fpm version we were told in the past.
 
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?
Hi, thanks for the heads up, presumably, when you say remove support, they will continue to work but can't be managed from custom build?
 
I have not used Squirrelmail in years, can’t remember any clients that did. If it is clunky and/or causes compatibility or security issues then I’d scrap it but otherwise it seems like a lot of other people and their clients are still using it after so many years.
 
Hey Direct Admin. Happy new year!

So what happens now? We still have no answer and my customers don't like surprises. How about some feedback?
I did notice in December I could no longer use php_mod on php version 2 or up. Which was a pain in the youknowwhat, because it disabled me to switch phpversion1 and phpversion2, so I cound set phpversion1 to be php-fpm and version 2 php_mod. WebApps need to run a higher php version, as you know. You have disabled this? And why? (I am talking about the plugin in the admin, it no longer shows php_mod at phpversion >1).
In short: Many of the servers I maintain still use mod_php. There were just too many to convert!
 
Last edited:
Hey folks, I am having my nephew type for me because can't see right now. My propane fireplace blew up in my face on Christmas Eve. I spent the holidays in the hospital/burn center with 3rd degree burns. The nephew read me the message about the update. I had him reboot server which did not help anything and actually named won't start now as well as php. I hate to ask but hoping someone can help with this. If I could see I could do it myself.
Thanks, Paul
 
Back
Top