According to the PHP documentation on unsupported branches
using [unsupported branches of PHP] may expose you to security vulnerabilities and bugs that have been fixed in more recent versions of PHP.
Debian 11, the current stable release, comes with PHP 7.4. which according to the PHP documentation on supported versions ceased being actively supported 6 months ago and will only be supported for security for another 5 months. I assume this means that in 5 months time, which seems like a short time in the life of a production web server, PHP 7.4 will be considered as unsupported by the official PHP organization.
What should I do in order to set up a Debian server for a secure production PHP website?
My current best idea is to set up Apache on Debian 11 and import an 'unofficial' repository from Ondřej Surý who seems to have a good reputation for producing reliable PHP packages. Then I should be able to install PHP 8 from his repository.
Another idea would be to use PHP 7.4 with Debian 11 now and upgrade to Debian 12 assuming it ships with PHP 8. That would presumably be the safest approach theoretically but in practice sounds like a lot of admin with scope for a lot of problems.
I have seen quite a lot of advice which strongly urges users not to install software from repositories that do not ship with the distro. This wiki from Debian is an example.
Are there more sensible alternatives? If so what are they? If not which of my ideas should I pursue?
Related
I am developing a Laravel 9.x app in Windows 10. My current version of PHP is PHP 8.1.5 (cli) (built: Apr 12 2022 17:38:57) (ZTS Visual C++ 2019 x64). Is this a thread-safe or not-thread-safe version? How can I tell? When should I prefer a thread-safe over a not-thread-safe version?
I've tried researching this issue here on StackOverflow but the questions/answers I see all seem to be a decade or more old - like this - and I strongly suspect that I might get a different answer if I asked the question today simply because the technology has changed in the intervening years. Is that a reasonable assumption? (At the very least, my current version of PHP evidently uses a newer compiler, VC++ 2019, rather than VC6 or VC9.)
I have no idea yet what my production environment is going to be or even IF the app I'm developing will ever go to a production environment since it's just an app I'm writing to (re-)learn Laravel. I may put it in production as a demonstration of a working Laravel app when the time comes but whether it will be on a hosting service or Netlify or something else, I just don't know at this point.
Just to give you some context, this issue only came up because I am trying to learn how to step through my Laravel source code to debug problems and this apparently requires me to add XDebug to XAMPP. The instructions I found for installing XDebug point me to here and recommend that I download the Windows binaries for my version of PHP. There are no binaries of 8.1.5 so I don't know if one of the binaries for 8.1 would work or if I'd be better to use 8.1 thread-safe or 8.1 not-thread-safe. If it would be better to upgrade my PHP first to 8.2, I still don't know if thread-safe or not-thread-safe is a better choice.
Can someone enlighten me on these matters?
Is this a thread-safe or not-thread-safe version? How can I tell?
You can use the good old phpinfo() function and lookup for the Thread Safety column.
If you have your PHP setup in PATH environment, you can even get it via CLI using a quick command php -i | grep Thread
When should I prefer a thread-safe over a not-thread-safe version?
As per PHP official documentation
If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP.
I have no idea yet what my production environment is going to be ...
Generally, there is no difference on TS or NTS code execution. It's more towards the webserver.
If I am not mistaken, by default, XAMPP uses Apache Handler, so it will likely be a thread safe build. And yes, the Xdebug binary for PHP8.1 will just work fine.
Technically, NTS should be slightly faster because it doesn't need to cater for thread safety.
Personally, I think it doesn't matter, unless you want to spend slightly more time to tinker around the webserver switching to FastCGI or PHP-FPM, since you are still in development phase, I think stick to the default setup and focusing on getting it up is more efficient.
Previously, I used package managers (i.e. YUM) to install and configure PHP. However, I would like to upgrade to PHP 7 and the package manager(s) available do not yet have PHP 7 available natively.
The plan is to use Chef to compile PHP on the server (during Setup) from original source. With that said, this process can take ~15 minutes on our server and will severely impact boot time.
Are there any techniques for increasing the speed at which the PHP
is compiled?
Can I create a tarball of final binaries and simply
download these to my servers?
There are some online resources that suggest adding the "webtatic" repo to YUM to access PHP 7. Is this safe/secure + reliable?
I am looking for freedom to upgrade my PHP version independent of when the package manager supports the version I am interested in
We ended up waiting for Ubuntu 16.04 which brings in PHP 7 via apt-get. Compiling PHP from scratch didn't turn out to be an efficient nor maintainable process
So, RedHat Enterprise Linux doesn't support the MCrpyt module, but you can get it from the Fedora project through the EPL. This would work fine, except the fact that we're using SoftWare Collections (SCL) to get a newer version of PHP (5.4).
So what is the best approach to getting the dependencies for laravell on RHEL 6.6 and keeping PHP 5.4 in the most vendor supported way possible?
About mcrypt, libmcrypt is a dead project, unmaintained for ~8 years, last version 2.5.8 was released in February 2007!... and despite lot of open tickets, no activity. Cryptography is a very important part of security management. Looking at the past, and issue discovered / fixed in various software, and the need to always increase security standards, and to drop old algorithms, how can we imagine using an 8 years old software ?
More, http://blog.remirepo.net/post/2015/07/07/About-libmcrypt-and-php-mcrypt
This explain why php-mcript is not part of RHEL/RHSCL official packages.
Additional packages for php54 collection (including php54-php-mcrypt) are available on https://www.softwarecollections.org/en/scls/remi/php54more/
And FYI, Laravel 5.1 doesn't requires mcrypt anymore.
I'm trying to figure something out:
I am using Ubuntu server 11.10 virtualized on Win7 (I don't think that matters but more info is better than less) to work on a Drupal 6 website I inherited and need to make significant changes to.
I want to set up a development copy of this Drupal website on my Ubuntu server so I can work without worrying about torching the production website.
I successfully got the production files downloaded and onto my machine, I got the production MySQL database exported and imported into the dev MySQL server, and I set up a symbolic link from the directory /home/myname/thewebsite.com to /var/www/thewebsite.com so I can easily access it.
When I got the website they didn't know the admin password so I dug around online and reset it in the dev db using phpmyadmin and finally log in.
When logging in and poking around the site there are lots of errors, which when googled lead me to believe that PHP 5.3 is causing them and that there are some modules in use that only work with PHP 5.2
After looking around a lot online and on stackoverflow there seems to be no easy way to install PHP 5.2 on Ubuntu Server 11.10. With no packages for 5.2 available through apt-get or aptitude what should/can I do?
1) Install 5.2 from source - how do I get it to interface with MySQL and Apache2? Also, I've never installed anything significant from source. Is there a walkthrough?
2) Replace the repositories with old ones? Will this work on 11.10? The newest instructions I found were for 10.04
3) Use already built PHP 5.2 packages for Ubuntu? Couldn't find these
4) Pay someone who knows more to do it for me? (Just kidding, this isn't really an option...)
Cheers and thanks for your help!
PHP dropped support for 5.2 in August 2011; operating system providers such as Ubuntu will not supply a version that is out of support, so you absolutely won't get an official copy of PHP 5.2 on the current version of Ubuntu (or any other OS).
If you're running an older version of Ubuntu (eg 10.04), you might be able to do it; it would still be a downgrade, because PHP 5.3 has been the default version for quite a long time now.
If you're on a newer version of Ubuntu, ie 11.10 as you state, it is going to be a problem for you.
The Drupal developers dropped the ball badly on this one. I guess it was because Drupal 7 tool so long to finish; they were expecting D7 to be out much sooner, and so they never bothered fixing up D6 to work with PHP5.3. As it turned out, this was a big mistake, because in fact D7 still wasn't officially released when PHP dropped support for 5.2.
But even so, they should have fixed it, because they're still officially supporting Drupal 6, so they need it to work with the current version of PHP. This is definitely Drupal's problem, not PHP's, Ubuntu's or yours.
But you still need to deal with it.
I found this question over on AskUbuntu.com, which gives an answer applicable to 11.04. It isn't quite 11.10 you were asking for, but it it a lot more recent than the best you'd found, so it might be helpful.
Alternatively, you could research exactly what it is about Drupal6 and your specific modules that doesn't work in PHP5.3. The language differences between 5.2 and 5.3 that can break things are not big, so I would expect any code changes required to be fairly small. You might find you can fix the code yourself. And maybe even submit the changes to the community -- Drupal is open source, after all.
Another tack you could take is to consider whether this saga represents an opportunity for you to move the site to Drupal 7?
This may or may not be feasible, depending on the modules you're using, etc, but if it is possible, it will solve the problem, because D7 is of course fully compatible with PHP5.3.
And just to cheer you up, I'll close by mentioning that PHP are on the verge of releasing PHP 5.4. Hopefully the Drupal devs will be more on the ball this time.
I've been learning up on PHP, and a lot of the time in the books and tutorials I read, features come up as having been introduced in PHP 5. I don't know anything about PHP history, so I don't know if I can safely use these features on most servers. I know in Python, adoption of new versions is very slow (few apps use 3.x, most desktops have 2.6, many server distros like Red Hat have versions as early as 2.4).
Is there a similar situation in the PHP ecosystem? My server has version 5.2, but are some servers still running PHP 4? What version of PHP can I safely assume a server would run?
PHP 5 was released in 2004, and PHP 4 reached End of Life at the end of 2007. You can safely assume that the server has at least 5.0.
PHP 5.3 was released in 2009, but there are still major pieces of software that have not fully taken into account everything that was changed in it; additionally, there are still distributions within their mainstream support cycles (like fairly recent versions of Ubuntu and Debian) that do not have it by default.
However, assuming PHP 5.2 is definitely safe.
At this point you should expect if not demand PHP 5.2.x. If your host doesnt have that, switch hosts - they dont deserve your money. PHP 5.3 on the other hand is a different story... not all shared hosts offer that yet so youll want to check it before deploying or setting up an account if thats the version youre targeting.
I wouldn't assume minimum versions of any software installed anywhere. I'm sure there are people still running PHP4 in 2010. Having said that, I also wouldn't be developing any new software targeted at PHP4 in 2010. PHP 5.2 is probably a good, practical choice at this point in time.
Distrowatch can be a useful resource for this type of question. Here's an example: It appears that RedHat went to PHP 5 in RHEL 5.5, which came out in March. That's not actually so long ago; it wouldn't surprise me if some enterprise users haven't upgraded (I work at a large university and we have many production servers running RHEL 4).
Nonetheless, if we were going to run a PHP app on one of those servers, it's a safe bet that we would update PHP. I'd use 5.2 and just document the requirement.
So, we've got some current data after all:
http://phpadvent.org/2010/usage-statistics-by-ilia-alshanetsky
PHP version | usage at the end of 2010
---------------+----------------------------
4.4 | 6%
4.4 | 16%
5.1 | 8%
5.2 | 66%
5.3 | 4%
And a more recent analyzation (says June 2011)
http://w3techs.com/technologies/details/pl-php/5.3/all
5.3 | 8.6% (from 6.6%/0.764)
Most web hosting providers are using PHP5. Some of them still provide both use of PHP 4 & 5 on a hosting account. In any case keep on with development in PHP5.