-
-
Notifications
You must be signed in to change notification settings - Fork 27
Frequently Asked Questions
- @deb@sury.org on Mastodon
- Ondřej Surý on Patreon
Generally, I do respond on both channels, but if you have anything more complicated than 140 characters (I know 280...), please open an issue in the issue tracker here.
Generally, a Contributor Covenant Code of Conduct applies here. Remember, I do this entirely on my free time and without any expectations from the users except of being polite to me and each other. This is the only warning you will get and if you are rude towards me I will block you and most probably send you to fiery hell. I don't owe you anything. That said, I must also say that most of the users and community around DEB.SURY.ORG are amazing people and I love you, but I don't need you :).
When you are reporting an issue, please make sure that:
- You first try to resolve the issue yourself
- You use an appropriate issue template (Bug or Feature Request)
- You fill-out the required details, the issue templates contains all the hints
Please note that I can't possibly do any user support - I can't teach you the basics of system administration, configure your system or solve unrelated problems. There are more appropriate forums for that like Ask Ubuntu, Server Fault or Debian User Forum.
- Ondřej Surý on Patreon
- Donate on PayPal
- Contact me for special requests (invoices, etc.)
sudo LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
sudo apt update
curl -sSL https://packages.sury.org/php/README.txt | sudo bash -x
sudo apt update
It's longer, thus the instructions live in a separate wiki article: How to remove DEB.SURY.ORG
Security warning: if you remove references to deb.sury.org packages from sources.list, make sure that the original Debian packages such as libraries and encryption tools are reinstalled. If this is not done, those packages will not get (security) updates.
Generally, the packages for releases that reach End-Of-Life are removed very shortly, usually with the next package update. Development releases are not supported, the packages are usually built shortly after the distribution first stable release.
All LTS releases during Standard Support. Interim (non-LTS) releases like Ubuntu Lunar (23.04) or releases like Ubuntu Trusty (14.04) that are covered only by Extended Security Maintenance are specifically not supported.
Debian LTS, oldstable and stable releases are supported.
Debian 8 Jessie, Debian 9 Stretch, Debian 10 Buster, Ubuntu 16.04 Xenial LTS and Ubuntu 18.04 Bionic LTS are available as paid option from PHP LTS by Freexian as a collaboration between DEB.SURY.ORG and Freexian.
Anything not listed here is not supported. It might or might not work. Ubuntu 14.04 Trusty, Ubuntu 16.04 Xenial, Ubuntu 18.04 Bionic, Debian 8 Jessie, Debian 9 Stretch and Debian 10 Buster are not supported in this repository.
Don't ask about the packages for unsupported distributions, they are gone. I don't backup the old packages, I can't dig them up from some "archive".
No, it's never "just a file". It's a security risk. Security issues are regularly found in PHP releases and any "just a file" might accumulate a wealth of them. That's OK, every software has bugs, and henceforth needs to be update on regular basis.
It would be irresponsible to provide unmaintained packages just for "convenience". It would also create additional burden on the maintainer of this repository because instead of "why the packages are not available" this would just generate questions like "why the package are not updated".
It's not "just a file".
Bummer, the date of end-of-life is well known several years ahead. The end-of-life doesn't come as a surprise, you need to plan ahead. If your business depends on it, you can get the packages for limited set of distributions from PHP LTS by Freexian.
The Debian APT repository is protected by CDN that significantly reduces the traffic received by the origin server (93% out of 4TB data served). While I do flush cache using the API on all relevant files, the operation isn't atomic, and there's short time window where the files might be out of the sync, but usually this is quickly resolved. Please don't fill a new issue unless you observe the error for more than 1 hour.
The systemd package is only required for the systemd-tmpfiles binary. Installing the systemd package on a system has no effect as it does not replace /sbin/init -- it merely makes the tools from systemd suite available to packages. This does not switch your /sbin/init to systemd (that's systemd-sysv job) nor it does start any extra services.
I don’t believe the extra 14MB makes a difference for systems with web server, PHP and usually a database.
Be aware that using apt --install-recommends (default) might pull systemd-sysv package by default. You can either install systemd with apt install --no-install-recommends systemd or use APT Pinning to prevent systemd-sysv from installing.
If you want to go extra length because of your beliefs that systemd is source of all evil, it should be you who does the extra work. Feel free to experiment with equivs package and providing systemd-tmpfiles shim via symlink to opentmpfiles-tmpfiles from opentmpfiles package.
The Debian repository is cached by CDN, it saves me quite a lot of money. Please don't mangle with No-Cache headers. If you want to mirror the repository, please properly use rsync (<-- really read this) to minimize the traffic. Using debmirror that use rsync as backend protocol and it can minimize the architectures mirrored is strongly recommended. Mirorring armhf, arm64 or i386 packages when all you need is amd64 package is waste of money, electricity and bandwidth.
There are currently 3 packages:
Example:
-
phpX.Y: Include apache2 package (includes cli) -
phpX.Y-fpm: PHP FPM only (includes cli) -
phpX.Y-cli: PHP CLI only
So if you want to install PHP version without requirement installing apache2 install phpX.Y-cli or phpX.Y-fpm.
See also Why does installing php7.x also install libapache2-mod-php7.x?
This is even more straightforward, just install phpX.Y-fpm and change the socket path in your webserver configuration to /run/php/php-fpm.sock and copy the old configuration, f.e. for PHP 7.4:
sudo apt-get install php7.4-fpm
# now change the socket path in your nginx/apache2 configuration
# from /run/php/php7.3-fpm.sock to /run/php/php7.4-fpm.sock
# or (optionally) use generic /run/php/php-fpm.sock that is symlink to highest PHP FPM version available
# and restart the server
(Optional) If you have defined more FPM pools, you need to copy the old configuration to the new path.
# stop old PHP 7.3 FPM
sudo service php7.3-fpm stop
# copy the old configuration from /etc/php/7.3/fpm/pool.d/ to /etc/php/7.4/fpm/pool.d/
# except www.conf
sudo mv /etc/php/7.3/fpm/pool.d/www.conf /etc/php7.3/fpm/pool.d/www.conf.bak
sudo cp /etc/php/7.3/fpm/pool.d/* /etc/php/7.4/fpm/pool.d/
# disable old PHP 7.3 FPM
sudo update-rc.d php7.3-fpm disable
# restart PHP 7.4 FPM to read the new configuration
sudo service php7.4-fpm restart
(Optional) And uninstall old PHP 7.3 packages
# uninstall old php7.3 packages
sudo apt-get --purge remove php7.3-common
php-pear and pkg-php-tools must depend on PHP CLI for default PHP version and that's PHP 8.2. Installing php-cli pulls php8.2-cli that will install /usr/bin/php8.2 and registers it as alternative with highest (82) priority to provide /usr/bin/php.
Installing PHP CLI binary is mostly harmless unless you need to run PHP scripts locally using command line. I could recommend two approaches:
- Rewriting those scripts to specify required version, e.g. changing
php <script>tophp5.6 <script>, or - Use
update-alternativesto switch/usr/bin/phpto your desired PHP version:- switch to specific version
update-alternatives --set php /usr/bin/php5.6, or -
update-alternatives --config phpconfigure the version by hand
- switch to specific version
To install php-pear on older, non-default versions you must also install the corresponding php-xml package, for example:
sudo apt install php7.3 php7.3-xml php-pear
for PHP 7.3. This is because php-pear depends upon php-xml which corresponds to the default PHP version package (php8.1-xml) but the php-pear package cannot know which PHP version you intend to run.
There are two possible causes:
- The default APT settings also installs recommended packages. As
php-pearrecommendsphp-cliit gets pulled by default even if you are installing PHP 5.6 packages. Use--no-install-recommendsto prevent this. - The real packages has always precedence over virtual. Thus although
php5.6-jsonProvidesphp-json, the realphp-jsonpackage is pulled by default. This might happen when installingphp-memcachedpackage that Depends (has to depend) onphp-json. The workaround is to explicitly list the package providing virtualphp-json, e.g. for PHP 5.6 you need to type:apt-get install php5.6-json php-memcached.
TL;DR: apt-get install php7.x php7.x-fpm or apt-get install php php-fpm.
The php7.x package depends on one of the available web SAPIs (libapache2-mod-php7.x | php7.x-fpm | php7.x-cgi). The APT dependency resolver installs the first listed package if the dependency is not satisfied by different package. Therefore if you required different web SAPI (f.e. FPM), you must explicitly list it as a package to be installed, e.g. instead of apt-get install php you need to run apt-get install php php-fpm. If you require specific PHP version you need to use versioned package names, e.g. apt-get install php5.6 php5.6-fpm. Or just install the specific web SAPI without the dummy dependency package, e.g. to install PHP 7.3 FPM SAPI you need to run apt-get install php7.3-fpm.
PHP extensions that are native (e.g. they come with the PHP sources) are built from the PHP X.Y sources and named phpX.Y-, f.e. php7.4-sqlite3:
Package: php7.4-sqlite3
Source: php7.4
Version: 7.4.3-1+0~20200220.11+debian10~1.gbpe23899
Architecture: amd64
Maintainer: Debian PHP Maintainers <team+pkg-php@tracker.debian.org>
Installed-Size: 124
Depends: php-common (>= 1:35), ucf, php7.4-common (= 7.4.3-1+0~20200220.11+debian10~1.gbpe23899), libc6 (>= 2.14), libsqlite3-0 (>= 3.14.0)
Provides: php-pdo-sqlite, php-sqlite3, php7.4-pdo-sqlite
Homepage: http://www.php.net/
Priority: optional
Section: php
Filename: pool/main/p/php7.4/php7.4-sqlite3_7.4.3-1+0~20200220.11+debian10~1.gbpe23899_amd64.deb
Size: 26888
SHA256: 2d7e6e421995846d43fb6386a4a43a95804408294ffc6d49644c3910eff83022
SHA1: 271d97a799ea179fec329c9d8a9534c74468a5ad
MD5sum: 7119865f9cdb5f74efa96a4dc7e598c5
Description: SQLite3 module for PHP
This package provides the SQLite3 module(s) for PHP.
.
PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used
open source general-purpose scripting language that is especially suited
for web development and can be embedded into HTML.
Description-md5: 0f31b34a4e9ca17b4007ed38c7c98f2c
PHP extensions that come from PECL, e.g. are built externally, are named php- and they contain shared modules for all supported PHP versions and they properly declare Provides: field for every supported PHP version, f.e. php-memcached:
Package: php-memcached
Version: 3.1.3+2.2.0-2+0~20191128.16+debian10~1.gbp5d60d1
Architecture: amd64
Maintainer: Debian PHP PECL Maintainers <team+php-pecl@tracker.debian.org>
Installed-Size: 751
Pre-Depends: php-common (>= 2:69~)
Depends: php-igbinary, php-msgpack, ucf, phpapi-20190902 | phpapi-20180731 | phpapi-20170718 | phpapi-20160303 | phpapi-20151012 | phpapi-20131226, libc6 (>= 2.14), libmemcached11, libmemcachedutil2, libsasl2-2 (>= 2.1.27+dfsg), zlib1g (>= 1:1.1.4)
Provides: php5.6-memcached, php7.0-memcached, php7.1-memcached, php7.2-memcached, php7.3-memcached, php7.4-memcached
Homepage: http://pecl.php.net/package/memcached
Priority: optional
Section: php
Filename: pool/main/p/php-memcached/php-memcached_3.1.3+2.2.0-2+0~20191128.16+debian10~1.gbp5d60d1_amd64.deb
Size: 116960
SHA256: c63552e63cf472faf90cce4754259ea6501c636886c8af4b79e250a5be7fc4a3
SHA1: 4b58d8072f6504c649b2746e8bce33ebf020ce86
MD5sum: 9c19f79d61df10ceeeda45b25b24f9ff
Description-en: memcached extension module for PHP, uses libmemcached
Memcached is a caching daemon designed especially for dynamic web
applications to decrease database load by storing objects in memory.
.
This extension uses libmemcached library to provide API for
communicating with memcached servers.
Description-md5: 8dd75c15765c7e1abc72767ad4d0eaba
Your system may have the "DST Root X3" Root certificate still enabled in it's ca-certificates, this certificate should be disabled as it is expired, @akaPipo provided these instructions
- run sudo dpkg-reconfigure ca-certificates
- uncheck mozilla/DST_Root_CA_X3.crt
- OK
If problems persist you may also be missing the "ISRG Root X1" root certificate, in which case you should add that certificate
you may need to add it manually to /etc/ca-certificates.conf and then run update-ca-certificates
If you require a specific PHP version and want it kept up to date, but not just receive the current release that gets updated when PHP new releases occur (for example the release of PHP 8.2 occurs when you want to stay on PHP 8.1) it is required that when you install PHP and any modules you only install version specific packages and not the generic packages. For example, most packages starting php- (e.g. php itself, and php-mbstring) are generic and will always default to the latest release, whereas selecting php8.1-cli, php8.1-fpm, php8.1-mbstring will install (and update) the specific 8.1 release (and in the case of PHP itself, the specific CLI, FPM, etc version of same - note the entry [in this FAQ] concerning why some packages will pull in others automatically).
Using this method will ensure that critical installs, e.g. to servers, are not suddenly replaced with a new version of PHP that may contain breaking changes or cause unexpected failures (e.g. a package not being available for your new release or an independent package that needs recompiling e.g. through PECL).
Also, this means that you do not need to try pinning PHP and that you are well set up to support multiple PHP versions on your system (e.g. to allow website installs to point to specific php-fpm versions).
Use your package manager to search for php-* packages - you will need to remove these for any you have installed outside of the PHP base. This includes PHP itself - install the version specific (apt install php8.1-cli, apt-install php8.1-fpm, don't forget to install the apache module if you need it also version specific).
For each library that you identify, use your package manager to remove it (but don't purge - you want to keep your settings), and immediately add back the version-specific library, e.g.
apt remove php-mbstring
apt install php8.1-mbstring
Another way to check if you have libraries remaining that need to be version fixed is to do an update and upgrade (but don't actually permit it to install yet) or list upgraded packages and see which are going to be version pushed to a later release (i.e. a 7.4 or 8.1 package now being pushed to an 8.2 - that will be from the meta package install).
Caveat: php-common appears to be installed and updated no matter what and has not been seen to be an issue.
To double-check that you've covered everything, do a php[version] -m to list the modules installed before you start the removal, and compare with the php[version] -m list when you are finished - e.g. php8.1 -m. This is also a good technique to compare during upgrading, e.g. php7.4 -m compared to php8.1 -m - make sure you've got everything installed for the new release.