New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You could do that, there would be nothing stopping you - until the server suddenly gets hit with the unpatched vulnerabilities.
If you MUST run PHP-5.2... then err.. godspeed.
Vulnerabilities happen with all the latest and hardened stuff also. Actually I need to run an old version of Drupal just for 100 or 200 internal users (with no public access) - at present it is running in a high end shared host for the last 10 to 12 years with no vulnerability, no problem BUT shared hosts will not support php 5x for eternity. So I am interested in knowing are there any VPS/Cloud/Ded Managed or semi-managed that will lINSTALL and let me run LAMP stack with php 5x for the eternity? Will be great if any one posts links of such reliable web hosts. Thanks @dahartigan .
what is stopping you from installing php5 on any vps?
I see. Yeah, forget shared hosting then.
Any VPS or Dedi is capable of running what you describe, and it can work indefinitely as long as it's keep maintained.
At this stage, you could virtually pick any VPS or Dedi that you like the look/sound/price of and then just install the stack you need.
If you need management, you could either get a managed VPS/Dedi or an unmanaged one and some third party management.
Good luck!
Is upgrading Drupal out of the question? Those internal users would appreciate the speed of the site with PHP 7.4/8.
Otherwise you will probably want to use CloudLinux HardenedPHP https://www.cloudlinux.com/features/#hardened-php
Thanks @dahartigan - that was really a very helpful information.
@Kassem - yes, its absolutely out of question. Its a Druapl 5 installation with small code-base and runs really fast even on shared host. Many thanks @Kassem
I will be very glad to get a few other webhost names too who does this sort of job (letting run php 5x) which should not be otherwise done![:blush: :blush:](https://lowendtalk.com/resources/emoji/blush.png)
PS : @dahartigan I have noted and seen your list at aff garden, i will dive deeper into it and the site is attractive indeed. @bruh21 - I was not aware actually, because so far the managed vps or cloud I have seen - they let me choose between various OS - like CentOs Ubunu etc but I have not seen choice of any php version dropdown - my inexperience!! I will study more and look into this because if it so it will be really life-saving![:smiley: :smiley:](https://lowendtalk.com/resources/emoji/smiley.png)
You seriously need to look at going up the PHP chain, you do not want this technical debt in the future. There are patches for Drupal 5 that can allow you to go up to 5.3/5.4 (which is a start) - and I imagine the work to make it 5.6+ compatible is substantial but not impossible.
I understand the reluctance to want to do so, especially if everything "just works" and there aren't likely to be any major security holes -- but you will get to a point where it will become closer to impossible to maintain. (I have many years experience in migrating legacy systems and codebases over to maintainable systems, often it is maintained until the person who maintains it leaves and then nobody can be found who has worked with such old technologies)
That being said, on the CloudLinux suggestion, some (many) shared hosts running CloudLinux will likely support it until CloudLinux stop supporting it - so that is unlikely to be a major upgrade by moving off of a shared host if it works well for you.
Instead - if you're really stuck, build PHP 5.2.17 from source (https://prototype.php.net/versions/5.2/install/source) and use it on a secured system on a modern distribution. There aren't any major security flaws in 5.2.17 as far as I know, and should be fine on a modern system for the time being.
Yeah but vulnerabilities stay in the outdated, abandoned versions of software. Nobody commits to patching an old version of an application for eternity. A fine example being the developer of whatever still requires you to run outdated PHP. The amount of outdated things you may end up running alongside this should be the concerning part. I'd recommend running the PHP interpreter in a very isolated container, in an otherwise up to date system. Preventing your scripts from making any file system changes could be helpful as well, kill the shell scripts in their tracks.
My favorite claim has always been "I didn't change anything so nothing should have changed." My response is always "You didn't change anything and that's exactly why everything should have changed." This thought process needs to be killed, things need to be updated and maintained. But if you absolutely can't, wear a condom (process isolation).
On VPS you can run what ever application you are required. Old version of PHP is not secure, if you do use for internal network so it will be not issue but not for external usage.
How do you ensure it's internal?
Say, the web server listens on a private IP and clients must connect to VPN to reach this IP.
An attacker can setup a third party webpage that contains an
<img>
tag that requests your vulnerable private website, then use social engineering to cause your internal user to visit that webpage.As soon as one of the clients clicks that page while connected to your VPN, your internal web server has been attacked.
So if you have to run something like this my suggestions are as follows:
Use docker and produce a docker image that runs PHP 5.2, this way your PHP environment is separate from the main server and if exploited harder to reach the main server. As well you can run an updated OS as the main host system instead of having to run an outdated version of Linux from 4 years ago that will support that version of PHP.
Even with using docker this doesn't exclude exploits for the older PHP versions from being used against you, if you were a pro I would suggest the user of mod_security or a WAF of some type with some advanced security for Drupal. As I would guess that you are most likely a novice, I would instead suggest regardless of the solutions you use now or in the future I would get services from Sucuri and use their protected reverse proxy in front of your site. For the few customers I have been in this situation with, it helps protect the site 900% better than just crossing your fingers and hoping and has been shown to be useful in protecting against many injection attacks as well.
Even if you think your are invulnerable, if you care about your customers, you will hire one of the many affordable pen testing groups which can perform a battery of tests against your site so you actually know what you are vulnerable to and be sure. Unfortunately, I don't have a good suggestion at hand, but maybe others here could suggest some.
Backups. Backups. BACKUPS! As well as a disaster plan for when your customers information eventually does leak out.. because even with all the protections in the world, a determined group of hackers against an ancient version of Drupal is a laughable challenge at best. If you really respect your customers, you will plan to upgrade as soon as you can budget it.
my 2 cents.
Cheers!
you do have a various methods to setup internal access (specific IP address range access only), so one else be able access your internal application.
Running an end-of-life version of PHP isn't necessarily a problem.
The problem is, if you're running a script that only operates on an end-of-life PHP version, then... well... that script has been abandoned for quite some time.
Any reputable script developer is going to be aware of PHP's lifetime. And while I certainly have disdain for PHP's 3 year lifetime per version (they should really quit releasing new "versions" so often and instead focus on maintaining a version for 5 or even 10 years). If a developer is unaware of PHP's end of life schedule, that's certainly a cause for alarm for anything written by that developer. If they refuse to update the script to work with current in-life versions of PHP, then that's also cause for alarm. Or the more likely scenario, they abandoned the project and couldn't care less if it works on current in-life PHP versions.
This is why I'm not a huge fan of CloudLinux's "support every version of PHP since the beginning of time". Because the world needs more Joomla! 1.5 scripts running wild!
It has been an amazingly high value wealth of information for me in this thread and huge amount of thanks to @LordSpock @TheLinuxBug and all others. As all the help and information has been already provided to me and I know I should not ask for more ... still @LordSpock @TheLinuxBug - can I have some ref or links to any reliable **managed ** VPS or Cloud that will do ( in lieu of some fees, of course)
in other words I look for a managed service with the ease of a shared Cpanel environment where they provide a secure php 5.2 to php5.6 and supporting db and I can actually focus on the website users and its design and management? Thanks and best regards.
It's threads like this where the best of LET shines
I'm looking forward to seeing how you get on with this project.