5 and more PHP versions

[sparek]

The issue with in-life PHP versions is a constant argument on the Internet.

But one argument I never see mentioned is to encourage the folks that develop PHP (php.net) to slow the %&#! down with new releases. It's painfully obvious that their release cycle doesn't match what the user base of PHP uses.

The other argument surrounding folks that paid lots of money to have a project developed with PHP 5.6 ... those folks need to learn that ANYTHING developed for the Internet is always a subscription model. Things are going to change. The Internet today is different from the Internet in 2015, which is different from the Internet from 2005, which is different from the Internet in 1995. You can't plaster up a website with a script and then never, ever, ever touch or maintain it and expect it to work through out all perpetuity.

Scripts/Applications for websites and the Internet are different from non-connected single terminal applications. An example, I have family members that are still using Office 97 on their PCs. Yes, this is old software. Does it have security vulnerabilities? I have no clue, probably does. But in order to exploit it... someone's going to have to be sitting at the computer with Office 97. Short of someone breaking into the house, this kind of limits the potential abusers. But for a script/application on a website... can you vet every single visitor to the website? Can you insure every single visitor the website doesn't have some type of malicious intent?

I don't think enough people (especially the people that write the checks that pay gobs of money to have a script/application developed for their website) are aware of this distinction. A lot of people seem to think you can put something up on a website and then just treat it like an Office 97 install. That's just simply not the case. Those people need to be educated and informed of this difference.

 

[BadSuzi]

But one argument I never see mentioned is to encourage the folks that develop PHP (php.net) to slow the %&#! down with new releases

That's true.

And the main discussion in this topic is loosing it's point - no one forces you to install on your servers PHP 5.3, 5.6 etc.
It's just about the choice - many of our customers also wants to have many PHP versions (on our envs without DA we provide PHP 5.6 and further, including 8.1, cuz clients just needs it) to just tests their applications - if customer wants to have i.e PHP 7.1, 7.3, 7.4, 8.0 and test how his apps works on 8.1 (they often doesn't have web developers to test apps localy, they can just copy/paste files, database and test functionality on newer PHP version) he has to lose one of PHP version, what often means that one of his sites won't be working for some time. It's hard to explain to normal, none IT people:

"Hey, you are paying XXX$ monthly for hosting, where you can have only 4 PHP version"

And of couse there is a Docker, but for someone who has no idea how to run i.e XAMP on their machine it's black magic.
If there will be selector for more than 4 version of PHP and you want to use only 4 - go ahead. But sometimes there is a need to have more of them on one server, and have that possibility will be really nice.

 

[Richard G]

But one argument I never see mentioned is to encourage the folks that develop PHP (php.net) to slow the %&#! down with new releases. It's painfully obvious that their release cycle doesn't match what the user base of PHP uses.

I can agree to that. It follows up so fast, that one can indeed question oneselve why this can't be slowed down or more integrated in existing versions which would life a lot easier, not only for hosters but especially also for developpers and customers.

It's just about the choice

Right, but cichy brought it as a must have. And that is not the case. It's only a must have for the happy few. If it's only just a choice, we got the feedback site for that. And there is also no reason as to why not implement this in the pro pack as using EOL stuff is a special request which is not "normal" or default.

what often means that one of his sites won't be working for some time.

No need for that if he keeps his site a little bit up to date. Come on, 5 php versions... if php 7.4 is release, he should already start testing his stuff on at least php 7.0 so php 5.6 can be removed because that is already EOL for years. So to be that late is a lazy choice of the customer. And if he's a developper that's even worse. Especially developpers should keep their stuff more up to date.
Be aware of the fact that even 7.0 is EOL already 3 years now. Also 7.1, 7.2 and 7.3 are now EOL. So if a dev is still using 5.6 (or even 7.0), well... certainly not a dev where I would buy things.

But sometimes there is a need to have more of them on one server, and have that possibility will be really nice.

Agreed, and 5 is coming, so that would be more then enough. If more is requested by the happy very very few, then I don't see any problem putting this in the pro pack as this is far from normal and secure, so extra service of the panel providing it, in this case DA.

 

[sparek]

Additionally... there's nothing really stopping you from compiling your own PHP and setting your accounts to use that PHP version.

Granted, you have no control of it within the DirectAdmin GUI - but it's technically possible.

I'm not sure when FPM became a connector in PHP - not sure if's available in PHP 4 or not, but assuming that it is... you can compile any version of PHP 4.0 with FPM and then manually connect a VirtualHost to feed through that PHP-FPM pool through Apache or whatever webserver you are using.

Technically speaking... you don't really need DirectAdmin for anything other than the DirectAdmin control panel (what runs on port 2222 - or port 2222 by default). Custombuild just makes it easier to compile all of these softwares, but it's technically not absolutely necessary.

And since there's no further releases for anything older than PHP 7.4 - once you compile one of these ancient PHP versions you won't have to update it ever again.

 

[DirectAdmin Sales]

This thread has so much enlightened and informative discussion -- thanks very much guys. @sparek, that was a really good point about people spending big bucks to develop something and then wanting to keep it static. You totally nailed it. It takes some wisdom to see both sides of it; that something can be bad practice, but there is a reason behind it.

We're seeing the same thing just when asking people to update their DA version. There seems to be very similar pushback, because they put big effort into a static configuration, and don't want to upgrade from CentOS 3 or Debian 4, or whatever EOL OS it happens to be.

In this context, regarding PHP, @woktron probably gave the best solution for this group of people? Not only does the CloudLinux PHP selector allow a lots of versions, but it also gives some older versions down to 4.4.

 

[BadSuzi]

CloudLinux is an option but we are using Debian on all of ours environemts and unification is more important than PHp selector. And as many providers there always will be as much "but"
Of course that you can build PHP outside DA but every good sysadmin will say that keeping things as simple as possible is a key to not being a good, but stressed sysadmin That's why I think more than 4 options is good feature, and it's awaiting in a line for almost a year now or even longer. From my perspective adding 5 or 6 PHP version is more than welcome and if there are already 4 options then adding next ones can't be hard - but still I'm not an DA developer. And as I said - you don't have to use them if you don't want to.

We can talk all night about technology stack and how it should be done/looks like but saying:

No need for that if he keeps his site a little bit up to date. Come on, 5 php versions... if php 7.4 is release, he should already start testing his stuff on at least php 7.0 so php 5.6 can be removed because that is already EOL for years. So to be that late is a lazy choice of the customer. And if he's a developper that's even worse. Especially developpers should keep their stuff more up to date.

Is a wishfull thinking.
Not every provider takes care daily about HA clients, who brings thousands $ monthly. Some of them have a lot smaller clients, which pays thousand of dolars summarized and if they are lazy but paying - you have to agree to keep older version of PHP, OS, SQL whatever, cuz loosing those clients is a lot more painfull for a business, than dealing with EOL stack. That's the fact.

Everything depends on what market are you working at and what's the target. Things looks diffrent in Netherlands, Germany, Spain, Russia, Poland, UK or any other country you will look at. So I think taking a look from other, less platonic and idealistic perspective is needed as well.

 

[Richard G]

Is a wishfull thinking.

No it's not imho. There is a difference between normal customers and developpers. The example was developpers. If they use 5.6 they are crappy and lazy, end of story.
As for the incomine and normal customers, that's another story indeed. However, daily care is not needed, php does not change daily. But it should be possible, even with lots of customers, to have customers update their stuff too so a newer php version can be implemented, at least over a periode of 3 years time.
Using Cloudlinux is a solution yes, but it takes a lot of work to keep old versions save and patched, that is not a job for DA.

you have to agree to keep older version of PHP, OS, SQL whatever, cuz loosing those clients is a lot more painfull for a business, than dealing with EOL stack. That's the fact.

If everyone wouldn't do that, this issue would be a non issue. I have a little company so loosing clients is much more painfull for me, but still I'm strict. And there was not 1 client which went away because he had to update his/her old stuff.

Oke with a lot more customers, this risk is a lot greater, so yes, to keep an older version of PHP, OS, SQL etc. running, is a reasonable argument, but only partly when dealing with EOL. Otherwise we could all keep running Centos 6 and php 5.6 forever, people do have do upgrade, even with Windows they know that, so their website is not any different.
So it's what I said in my argument, it's a money question, too afraid to loose customers. Yes it's partly ideallistic, but if we all keep the same flat money thought and afraid to loose customers, nothing will ever change. Which is no problem as long as is not expected that others (like panels) will have to comply to those wishes too. That's unrealistic.
And if there are that many clients, then if some clients will run (and have a hard time finding a host using ancient stuff), it will not be that big of a loss.

We got very big company's in the Netherlands too, they run cloudlinux indeed, but their eol support also finishes at some time. And they also changed prices drastically, also loosing customers. So it can be done.

Concluding, I don't mind if somebody wants to run ancient stuff, for my part forever, or wants to run 100 php versions on his server. One should decide that for themselve. But problems or issues arising with that, is also ones own issue or problem then, don't project those to others.
Only thing I was arguing about, was the fact that it's those peoples own problem and one can wish or request more, but not expect a panel like DA to support EOL stuff, because somebody (very very few) wants this for their customers.

As said 5 pieces is coming (could be faster, agreed) which should be sufficient.
And 6 or 7? I don't mind, but I don't understand what's against the argument to put that in the pro pack. And I have not seen any argument against putting it in there.

 

[woktron]

Oke with a lot more customers, this risk is a lot greater, so yes, to keep an older version of PHP, OS, SQL etc. running, is a reasonable argument, but only partly when dealing with EOL.

Both CloudLinux and RedHat backport security fixes into EOL versions of PHP.

Security Backporting Practice - Red Hat Customer Portal

Access Red Hat’s knowledge, guidance, and support through your subscription.

access.redhat.com

https://www.cloudlinux.com/features/ (hardened php)

We have quite a bunch of users on outdated php versions and I would not describe these as edge cases.

 

[sparek]

If everyone wouldn't do that, this issue would be a non issue. I have a little company so loosing clients is much more painfull for me, but still I'm strict. And there was not 1 client which went away because he had to update his/her old stuff.

Agree!

One of the issues I have with CloudLinux is their proliferation of continuing to release PHP versions that are well out of date. To the point that common web hosting users expect these to be available and don't understand what's wrong with that concept.

Now... maybe it really is true that you have a script/application that you spent money on, keep a developer on retainer, that only operates on PHP 5.6. While I don't necessarily agree with the fact that the script/application couldn't be upgraded to support more modern PHP versions by now, but this can certainly describe a niche market. But in this scenario the owner of the website needs to have a developer on hand that they can reach out to 24/7 to resolve issues within the script/application. I'm thinking a BIGGER, Enterprise-like customer - probably someone that can afford to have their website hosted on an isolated "their account only" dedicated server.

A ten year old WordPress website with a theme written by some 12 year old kid 23 years ago and upgrading PHP breaks the website, is not a valid reason for still needing PHP 5.6.

If you can't afford an isolated "my account only" dedicated server to host your outdated PHP dependent script/application... then you probably need to revisit what you are doing with your website and what script/application you are running on your website. If you want to pay cheap hosting pricing of shared hosting, then you have to recognize that shared hosting can't always bend over backwards to serve your specific need. There's more at stake than just your account.

PHP version updates serve the purpose of cleansing a server of many of these outdated and abandoned websites. If your website, plugins, and themes doesn't work with PHP 7.4 by now... you're not keeping your script/plugin/theme up to date... or the developer of the script/plugin/theme has abandoned the project (this is a lot more common than you might think).

Also worth mentioning - if your website uses a script that depends on Ioncube (i.e. WHMCS) then PHP 8 is not an option for you. But this is more of a product of Ioncube dragging their feet on this. But also points out the staggering pace that PHP is releasing versions. PHP 9 will be out before Ioncube has PHP 8 support.

 

[BBM]

Another thing should indeed be "responsibility".
Who will be held responsible if damages occur because a user-account, or more likely, an entire server gets compromised / hacked / dumped online because of some outdated unsupported software still running on it?
I'm pretty sure it's not that particular end-customer who desperately needed that old php-version on his webhosting.

 

[Richard G]

Both CloudLinux and RedHat backport security fixes into EOL versions of PHP.

You might have missed it, but that is the reason why I stated that Cloudlinux is a solution.
But you can't expect that DA must keep support because cloudlinux does and DA supports Cloudlinux.

To the point that common web hosting users expect these to be available and don't understand what's wrong with that concept.

Exactly!
And I agree with the rest too.

 

[sparek]

Another thing should indeed be "responsibility".
Who will be held responsible if damages occur because a user-account, or more likely, an entire server gets compromised / hacked / dumped online because of some outdated unsupported software still running on it?
I'm pretty sure it's not that particular end-customer who desperately needed that old php-version on his webhosting.

A whole server being compromised is probably unlikely. But even if that ticks up half of a percent because one account is using an outdated script, that's still an increase.

The more likely culprit, what I see most often, is these outdated scripts/plugins/themes (that require EOL versions of PHP ... regardless if that PHP version is CloudLinux/RedHat and has backport security fixes) being compromised and malicious users install spam software or phishing content that adversely affects the well-being of the entire server.

Again, the issue isn't so much the EOL PHP version ... it's the fact that the EOL PHP version is necessary to continue running an EOL/outdated/abandoned script/plugin/theme.

 

[woktron]

But you can't expect that DA must keep support because cloudlinux does and DA supports Cloudlinux.

Security fixes are backported natively by Red Hat (CentOS, Alma, Rocky etc.) and also Debian as long as the OS is not EOL. Besides scripting in an additional PHP version in the DA GUI, they won't have to maintain these EOL versions at all. I'm no developer but this should be fairly trivial to do and maintain.

In an ideal world everyone is running the latest version of PHP, no argument there. However, there is a fairly large userbase who are unwilling or unable to. You can either choose to service these clients or let them find a different host. IMO, You can't expect a hairdresser who has most likely been closed most of the year due to COVID to shell out money for a new website.

In our experience compromises are mostly the result of vulnerable plugins, themes or outdated WP installs, regardless of thePHP version they are using.

 

[Richard G]

as long as the OS is not EOL.

That is normal. But we were talking about OS and PHP versions which are EOL. Because you almost never have 5 or more php versions which are not EOL at the same time.

I know there is a fairly large userbase not doing this, but I think mostly that is not unwilling but rather that they are not teached or a bit pushed to upgrade, so unknown of it or a bit lazy.
The ones really which do not want to or really are unable to, is imho rather small compared to the rest.

Oke at this moment, with Covid, you have a valid point (or rather a social one) if you want to help that hairdresser, but that's more a personal choice, not a commercial one. I support the thought to give them some more time if possible. Otherwise I would offer them a seperate VPS for a small fee to keep things running for them. So there are alternatives for these situations.

I don't say you need everybody always to run the newest php version. But my argument is 5 php versions are enough. And in spite of the fact that you have a social reason for maybe more php versions, this still is no argument to put an option providing more than 5 in the Pro pack.

 

[woktron]

That is normal. But we were talking about OS and PHP versions which are EOL. Because you almost never have 5 or more php versions which are not EOL at the same time.

There is a difference between what php.net and entities such as Red Hat support via backporting. PHP.net drops support far quicker. On php.net there are currently 3 versions that are not EOL. CloudLinux on the other hand currently support 10+ php versions. CentOS7 backports from version 5.4 onward. These releases still receive security fixes and are as such not EOL.

Each case is a matter of circumstances and should be judged individually. I fully agree, there are plenty of invalid reasons not to update such as laziness. But there are also custom applications that took lots of manhours to build that are difficult to update (we have a client interfacing with a third party API, however this API only works with the php 5 branch - he wants to update, but he can't), there may be financial concerns or a lack of qualified developers, the original developer has disappeared etc. Ironically, we find that especially larger firms have a tendency to run outdated software. In the end of the day though it is not up to us as a hosting provider to decide where a company/client should spend their resources on. We only have an advisory role.

In my opinion providing these additional (outdated) php versions is not an additional security concern, at least not beyond the issues that we'd normally encounter, the demand is there (25% of php based websites are still on the php 5 branch, this is a sizeable chunk), and implementing additional php versions should not be too much work.

 

[warg]

I think to be fair regardless of what some of us think about this "feature" (it's more like an enhancement) this should be implemented for two reasons if I'm not wrong/misunderstanding the scenario here:

1. This has been already announced by DA staff and is just delayed; so it's not much of an open decision anymore.
2. It sounds a bit weird to me that there is a limitation in the numbers of PHP releases you can run. Of course we talk about legacy versions here but maybe someone wants to run multiple supported versions and some alpha/development releases for test purposes. Then you would need additional selections possible as well.

 

[itscoffetime]

A lost opportunity for you guys would be that there is no way for internal lifetime/datacenter license holders to purchase the pro-pack. We are now using CloudLinux but would be more than happy to make the switch.

This is so true, they should with a extra charge

 

[netswitch]

I did not find it in the arguments but another potential reason to need more than 4 php options is that one might want to run the same (uptodate and supported) version of PHP but with different compilation options/modules/extensions.

 

[marson]

Could anyone point me how to compile additional PHP manually, or to be more clear, how to connect that manually compiled PHP version to a particular domain? Is there any trick in .htaccess or what? I know how to compile PHP, I can prepare php-fpm pools myself, I can prepare php-fpm start script myself but how to use that PHP version in the application?

 

[Zhenyapan]

how to use that PHP version in the application?

check your webserver virtual host (/usr/local/directadmin/data/users/USERNAME/httpd_or_nginx.conf)