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

It's all webmail. Those are just application names.
Like Outlook, Thunderbird, Eudora... it's all e-mail clients, just different applications to use with e-mail.
Roundcube is also webmail just different application to use it with. ;)
Yes good catch 🤓 just forgot how fast all changes :)))
 
With regards to squirrelmail: it is the most used for many of my customers. There are no issues with it, so why remove? How much updates has it had in the recent past? I vote to keep it.

Many of my customers are still using mod_php. On a dedicated server this is a fine choice I think. I am not aware of 'many updates' in mod_php, how often does that get or need updates? In other words: if support is denied as of 1-1-2023, how bad would it be? To continue using it?
Of course I am aware of the small changes in not using it anymore, so we (as in we='customers') can disable mod_php somewhere next year (per dedicated server) as it will run just fine for a long time after 1-1-2023.
With regards to MySql / MariaDB. On some servers with many GB's of data, updating MariaDB takes more than 6 hours. And, in the event there is an error, restoring is a pain in the _ _ . Plus, new rules in higher versions of MariaDB possibly will break website(s). All I am saying is that it would be nice to have these support issued noticed a year up ahead or so, not just months, it takes a lot of research and testing to upgrade for some of my customers with very big websites/databases.

Why is it discussed here on the forum? I mean: is Direct Admin going to change its course if many users complain about one of the choices?
 
What will happen with servers running any of them after DA drops support of them?
Good question. I would also like to know if this will break a server. Or does DA simply stop releasing updates for it.

What webalizer concerns, I think this is a handy tool for quickly scanning the some basic statistics. I never used Awstats so I cannot comment on that as an alternative. Can I run both on the same server for testing purposes?

[edit]
I got a warning that mod_ruid2 is enabled on one of my servers. I don't think i'm using it because PHP uses PHP-FPM. I disabling mod_ruid2 in the options enough to "stop using it"? Or do I have to rebuild something?
 
Last edited:
Many of my customers are still using mod_php. On a dedicated server this is a fine choice I think.
The only OS supporting mod_ruid2 is CentOS7. Without mod_ruid2 it runs under apache user, and is not recommended to run it like this. We'd recommend switching to another mode of PHP.

On some servers with many GB's of data, updating MariaDB takes more than 6 hours.
It shouldn't, unless you mean a backup :)

Plus, new rules in higher versions of MariaDB possibly will break website(s).
It's controlled by a single
Code:
sql_mode
configurable parameter, if any of the websites have problems - you'd just adjust that parameter, or just leave it blank.

All I am saying is that it would be nice to have these support issued noticed a year up ahead or so, not just months
We're talking about end-of-life versions of MySQL/MariaDB, they are end of life not for "just months".
 
Since 2 days I am getting three messages on one of my servers (CentOS 7 of course):
1) New Message: Your MySQL/MariaDB version 10.2 is EOL
2) New Message: Removal of mod_ruid2
3) New Message: Removal of mod_php

Are we going to get these mails on every server every day?
 
Since 2 days I am getting three messages on one of my servers (CentOS 7 of course):
1) New Message: Your MySQL/MariaDB version 10.2 is EOL
2) New Message: Removal of mod_ruid2
3) New Message: Removal of mod_php

Are we going to get these mails on every server every day?
With every hot-fix or update.
 
I had an even more unpleasant experience. In the early morning, around 3 am, I received for the first time the "Removal of mod_ruid2" and "Removal of mod_php" messages. Three hours later, our webserver (httpd) went down. Maybe that was not directly related to this announcement, but must have been related to the first update/hotfix that introduced those messages.

A simple restart did not help, but rewriting the configs did (this post helped me). Just posting this in case someone else encounters the same issue.
 
With every hot-fix or update.
Can you relate to what happens to servers running unsupported PHP methods and webalizer?
Similarly, I am interested in the question of whether the DA provides native support for other PHP methods. The point is to leave this option at all, and not to force migration.
 
Can you relate to what happens to servers running unsupported PHP methods and webalizer?
It was just a question about webalizer/squirrelmail :) There is no final decision on them and no removal dates.

Regarding PHP - CustomBuild/DirectAdmin won't support configuration of it, if you have custom configuration set there it'd work, but it'd stop working with default configs.
 
Regarding PHP - CustomBuild/DirectAdmin won't support configuration of it, if you have custom configuration set there it'd work, but it'd stop working with default configs.
Ok, I'm using custom templates so it shouldn't be a problem. But is there any chance of an option "other" to ./build php_expert... ? The point is that CB will not overwrite any configurations outside of compiling a specific PHP version.
 
Ok, I'm using custom templates so it shouldn't be a problem.
Please make sure there are no if clauses for mod_php, as they wouldn't work anymore :) It'd need to be hardcoded to be mod_php. Also, keep in mind that no other systems, but CentOS7, support it. CB won't have any native ways to install mod_php anymore. I'd like to note that after 2024, when CentOS7 becomes EOL, it'll have no use cases at all :)
 
Please make sure there are no if clauses for mod_php, as they wouldn't work anymore :)
I'm only thinking about suPHP. For me, it's the best solution, super simple (and therefore stable) and safe. It has a built-in chroot (not via bubblewrap like in fast cgi), we also extended it with additional things like user limiting (CPU, number of processes). We can have dozens of different PHP versions (if we want, of course) that we enable/disable/replace in one configuration file (suphp.conf) and the user selects the version via one .htaccess line (also for subdirectories). Really many advantages. I know that there is also php-fpm and they also have their advantages (like lower CPU usage, although imo suPHP's poor performance is a bit of a myth). But migrating multiple servers (tens of thousands of vhosts) to another method of running PHP is a big problem.
 
We are using Webalizer.
If changing from Webalizer to AWStat , can previous Webalizer reports keep ?

We also are using suPHP for some servers.
 
How can we stop DirectAdmin auto-update itself ?
Recently Direct Admin checked its license and updated itself, while I dit not want any updates, since it is CentOS 6.
Now they updated, some things stopped working, and I need to do things manually (Let's Encrypt for instance).
They should have not updated. CentOS 6 is End Of Life and I am not able to install (any) required modules (Go for Let's Encrypt).
My request to DA would be: if you check the license, don't do an update on DA binaries. Not without asking.
 
Now they updated, some things stopped working, and I need to do things manually (Let's Encrypt for instance).
Are you sure ? this will be an big problem for use, but when i check the list of removed software I dont see LE ?
@fln @DirectAdmin Support is this true , will this removed (or stopped on Centos 6 ?)
 
Are you sure ? this will be an big problem for use, but when i check the list of removed software I dont see LE ?
@fln @DirectAdmin Support is this true , will this removed (or stopped on Centos 6 ?)
Sure! I had disabled updating directadmin on CentOS 6 servers, because there was a message like 'future updates may not work' etcetera, so I stopped updating DA for over a year. But out of the blue, it updated itself recently, and the letsencrypt script was as well updated, breaking the functionality. I have switched to paid certificates now. And downgrading DA? I am not sure if I want to ever try that on CentOS 6.
 
Back
Top