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

[Richard G]

@Amoled I've been anxious to change too, also because of .htaccess and other stuff. I change a couple of years back and never was sorry and wouldn't go back anymore.

I don't agree with Sparek that .htaccess files to end user control can be a recipe for disaster as users always had control over .htaccess also with mod_php. And one can set limits as to the max amount of for example php memory_limit a user can configure in a .htaccess file.

There is a documentation about how to easily switch to php-fpm and don't forget any commands, you can find it here.

General | Directadmin Docs

DirectAdmin Knowledge Base

docs.directadmin.com

 

[sparek]

I don't agree with Sparek that .htaccess files to end user control can be a recipe for disaster as users always had control over .htaccess also with mod_php. And one can set limits as to the max amount of for example php memory_limit a user can configure in a .htaccess file.

Interesting. Where is the documentation at limiting PHP directive values in .htaccess files?

 

[Richard G]

Where is the documentation

I don't know if there is any documentation about it on DA.
If you limit it to a max in the global php.ini then a .htaccess file can not override that value to my knowledge.
However if it would be possible some way, then this issue would be present using mod_php also, unless one forbids the use of .htaccess so I don't see any difference with php-fpm anyway.
When changing to php-fpm not using the .htscanner one can use a personal .ini file for such changes.

I thought I've read somewhere here that it was also possible via vhost or some other way to limit this for users, but don't know where that topic was.
Maybe @smtalk of @Zhenyapan has some idea on how to restrict that in another way besides the global limit.

 

[sparek]

That's what I mean. I don't think there was ever a way to restrict PHP directive values in the .htaccess file when using mod_php.

Now, maybe htscanner does something - I won't dispute that.

The same is also true of .user.ini files, but you can disable .user.ini files in the global php.ini file.

My point is that ever allowing end users to customize PHP directives with their own values with no restrictions, was always a bad idea. Removing mod_php and therefore taking this ability away from end users doesn't really mask the fact that it was never a good idea to begin with. Forethought.

 

[Zhenyapan]

I don't remember exact case, it was long time ago, but maybe with php_admin_value memory limit was upper than one from htaccess, but it's not a case - if you want to limit memory you can use cloudlinux or propack (cgroups). In my experience - htaccess must work at least for rewrite rules, expire and additional headers etc.

 

[Richard G]

Now, maybe htscanner does something - I won't dispute that.

I wouldn't know about that, the htscanner only takes care that you can use all values in .htaccess again like with mod_php.
What I ment was that if htscanner is not used, then users can't use .htaccess to raise values but they can create a user.ini to do exactly the same.

I was talking about the global limit in the global php.ini file, as far as I know this restricts using higher values using both mod-php or php-fpm.
Which is why I'm wondering as to how a user would be able to override the global memory_limit setting. Because they can't do it in .htaccess.

I can understand that it's not a good idea to have end customers use no restrictions at all. So I really wonder how somebody would be able to set the value to 50G, unless there is no limit set in the global php.ini.

 

[sparek]

Well, it's been a long time since I used mod_php and .htaccess PHP directive values.

But why would the global php.ini only define the upper limit? That would mean that .htaccess PHP controls could only set a value LESS than the value in the global php.ini. Because if no .htaccess file exists or no PHP directive control in the .htaccess exists, then PHP would use the value defined in the global php.ini.

If you set the global php.ini value to 1024M - then any account that doesn't have a .htaccess file or doesn't have a php_value memory_limit in their .htaccess file is going to have a 1024M memory_limit. If this acts as an upper limit, then the only way to raise this for a specific account would be to raise it globally for all accounts.

 

[Richard G]

But why would the global php.ini only define the upper limit?

Because the title is "max" memory limit, not minimal. But I was wrong, seems it doesn't strictly keeps that limit always.

then PHP would use the value defined in the global php.ini.

Yes, that was what I was doubting about. So before I posted my previous reply and tested this. My global php.ini has 512M and I tried to set it to 1024M via .htaccess and the phpinfo.php still said it was 512M.

then the only way to raise this for a specific account would be to raise it globally for all accounts.

No there are other ways, I don't know them all, but you can check this posts and thread:

Changing PHP memory limit

Hi How i can change php memory limit for "each user separately" on Control panel?

forum.directadmin.com

and

Increase PHP memory limit for just one account

Hi all, I wonder if it is possible to increase the php memory limit for just one single account, NOT for the whole server. I have read that this is sometimes possible through a php.ini in the root of the website or trough a modification in the .htaccess site. Is this also possible on DA servers?

forum.directadmin.com

But now I got confused. Via .htaccess this would not work. It kept saying 512M. But the default was set to 256M in the global php.ini file.

Just I found out some odd thing (and editted my text now). It kept being 512M no matter what I changed in .htaccess so that is not good.
When checking I found a file called /usr/local/directadmin/data/users/foobar/domains/domain.com.php.ini and in that file, the memory limit was set to 512M.
Now I went into the DA GUI with the php settings and there it was possible to set a max of 1024 M and that worked, so overriding the global 256M default.

However, so this would mean the limit is 1024 M, but this limit can be changed (higher or lower), I just don't remember where that was.

 

[Amoled]

Listen, even though it is possible to implement support htaccess in php-fpm, I want to decide for myself which one to use for me. It is unacceptable for the software manufacturer to give instructions to the hosting owners what to use and what not to use.

At school, my children are told which gender to choose and which god to believe in. At work, they tell me which software to use. For my own money. What kind of nonsense is this? I just want to use mod_php, stop messing with my head =(

 

[itcms]

Hi,

You confirm all outdated software yes will be removed, no supported BUT remains active and doesn't affect the current installation.
Example Mysql

 

[Amoled]

It will be funny if MySQL is simply deleted with all the data at the next update because it is "outdated".

 

[dyna]

is it me, or did something automatically change regarding php_fm instead of php_mod, because all of our websites went down with 503 due to httpdconf errors after someone adding a new domain.

 

[timtim1234]

I read every post in this thread, but still I don't know what I have to do or have not to do to keep mod_php working.
Could you please tell how I can use mod_php even after 2024?
Thank you

 

[smtalk]

I read every post in this thread, but still I don't know what I have to do or have not to do to keep mod_php working.
Could you please tell how I can use mod_php even after 2024?
Thank you

As you're going to run EOL system/server, you'd get no updates for any of the software components running there (including OS updates, DA updates etc.) - I don't think there is anything to worry about Your webserver should still be working fine without any updates.

 

[zEitEr]

What will happen with servers running any of them after DA drops support of them?

The day has come, and now we have:

[root@~ custombuild]# ./build update
[root@~ custombuild]# ./build versions
PHP mode 'suphp' is not supported, please set php1_release=php-fpm|fastcgi|lsphp in CustomBuild 'options.conf'.
[root@~ custombuild]#

All the other services are still running. A server is still online. No updates are available, that's the only thing.

 

[Magistar]

Hello I am still runnign MySQL 5.6 combined with Cloudlinux and php-fpm. Which alternative do you recommend I upgrade to?

 

[Zhenyapan]

@Magistar you can keep same but new Mysql 8, Cloudlinux 8.7, php-fpm (or lsphp)

 

[IT_Architect]

Distros support versions past the date that the date software authors maintain it and customer choices are driven by such. Are we saying that DirectAdmin has decided to be driven by the date software authors decide to maintain it and not fully support the distros?

 

[pvmierlo]

The day has come, and now we have:

[root@~ custombuild]# ./build update
[root@~ custombuild]# ./build versions
PHP mode 'suphp' is not supported, please set php1_release=php-fpm|fastcgi|lsphp in CustomBuild 'options.conf'.
[root@~ custombuild]#

All the other services are still running. A server is still online. No updates are available, that's the only thing.

They are running but might be vulnerable as we speak since the other services cannot be updated in the current environment that was created with this change. We have customers who have a hard time finding the time and effort needed to making their web application ready for newer versions of MySQL or MariaDB. We can't force them to take these steps since the database software is not vulnerable or causing problems. Currently the servers running older MariaDB/MySQL versions with Custombuild won't update any packages related/maintained by DirectAdmin. I wonder how this can be the desired outcome of this change.

Is there any alternative available to make sure that internet facing services (which MySQL is not) receive their (security) updates besides the now defunct CustomBuild?

 

[quanghuy985]

When i change mod_php to php-fpm, i have an error that i can not start php72-fpm during ./build php. journalctl -xe, i see the log like in the image.

I did that :

cd /usr/local/directadmin/custombuild
./build update
./build set php1_release 7.2
./build set php1_mod php-fpm
./build set php2_release 5.6
./build set php2_mod php-fpm
./build set php3_release 7.4
./build set php3_mod php-fpm
./build set php4_release 8.1
./build set php4_mod php-fpm
./build set mod_ruid2 no
./build set_php htscanner yes
./build mod_htscanner2
./build php
./build rewrite_confs

Now my server can not run website with php7.2. Php 8.1 run normally. All of website run php 7.2 have error "You don't have permission to access this resource.Server unable to read htaccess file, denying access to be safe".

Please help me to fix it. Thanks you