Как установить старую версию php
Как понизить версию php 7.4 до 5.6 в Vesta на Ubuntu
Понижение и повышение версии PHP в Ubuntu вариант 1
В этом руководстве мы покажем вам, как обновить PHP 7.0, который по умолчанию установлен Vesta CP во время установки, до последней версии PHP 7.1.xx, 7.2.xx, 7.3.xx или 7.4.xx на сервере Ubuntu.
Зачем переходить на php 7.1, 7.2, 7.3 или 7.4?
Это даст вам повышение безопасности и производительности + KICK, поскольку WordPress или поддерживаемые скрипты будут загружаться намного быстрее и потреблять меньше ресурсов.
Пакеты, которые понадобится установить:
Вам нужно установить software-properties-common:
Для Apache mod_php:
Для обновления PHP 7.1:
Сначала вам нужно добавить Ondrejs PPA:
Если вы получите: “‘ascii’ codec can’t decode byte”, выполните следующую команду:
затем запустите эти команды:
Теперь установим PHP 7.1:
После установки, отключите модуль php 7.0, чтобы активировать модуль php7.1:
После включения модуля новой версии php, перезапустите службу apach2 командой:
Для обновления до PHP 7.2, 7.3, 7.4, достаточно изменит цифры версии в командах.
Пример для PHP 7.4:
Теперь, если вы установили все нужные Вам версии PHP, вы сможете переключать их, как в сторону повышения, так и понижать версию PHP.
Чтобы повысить php7.1 до php 7.4, просто выполните следующие команды:
Чтобы понизить версию с php7.4 до php 7.0, просто выполните следующие команды:
Если данный способ, не подходит Вам по каким либо причинам, вы может воспользоваться вариантом переключения PHP который описан ниже.
ПЕРЕКЛЮЧЕНИЕ МЕЖДУ ВЕРСИЯМИ PHP вариант 2
Пример: Ubuntu 18.04 как переключить PHP7.4 на php5.6
Этот метод заключается не в удалении каких-либо из версий php и установке другой версии, а в установке PHP как надстройки и в использовании одной из версий PHP по необходимости.
Данный метод не позволяет выбирать нужную версию PHP в панели управления VestaCP.
Ели Вам нужен способ позволяющий выбирать версию PHP для каждого домена, вам подойдет предыдущая инструкция.
Приступим к установке и настройке:
Вы установили версию PHP 5.6.
Проверим версию PHP командой:
Вывод может отображать вашу старую версия PHP.
Для применения изменений, рестарт веб сервер Apache:
Обычно, сначала необходимо установить еще несколько модулей необходимых для правильной работы веб сервера:
Включение необходимых расширений >>> sudo phpenmod mbstring
Обновление PHP 7.2 до версии 7.3 на Ubuntu сервере с NGINX
Введение
В данной статье будет рассмотрен процесс обновления PHP 7.2 до версии 7.3 на Ubuntu сервере с NGINX. Ниже приведенные инструкции также применимы к переходу с более ранних 7.x версий.
Введение
В данной статье будет рассмотрен процесс обновления PHP 7.2 до версии 7.3 на Ubuntu сервере с NGINX. Ниже приведенные инструкции также применимы к переходу с более ранних 7.x версий.
Подготовка
Для начала сделайте бекап PHP конфигов. Для этого выполните в консоли:
Прежде, чем устанавливать новые версии пакетов, нужно узнать какие именно php-пакеты необходимо установить. Чтобы увидеть, какие php-пакеты установлены на данный момент, выполните в консоли:
Можно сразу сохранить вывод в файл:
Если вы устанавливали PHP из репозитория Ubuntu, тогда добавьте PPA репозиторий:
Если данный репозиторий у вас уже добавлен, тогда просто выполняйте:
Установка
Установите новые версии PHP-пакетов:
Настройка
Скопируйте старый php.ini в новую директорию:
или сделайте изменения вручную, затем перезапустите сервис php7.3-fpm
PHP FPM настроен, но NGINX еще использует старую версию PHP.
укажите NGINX использовать сокет для PHP 7.3.
и перезапустите сервис nginx:
Если для каких-то PHP приложений нужна старая версия PHP, то просто не меняйте путь для FPM сокета в конфиге NGINX. Таким образом, можно одновременно использовать обе версии PHP.
Удаление старой версии
Если старая версия по-прежнему будет использоваться – пропустите этот шаг.
Осталось только удалить старые пакеты (вместе с конфигами), относящиеся к PHP 7.2:
Можно не перечислять все пакеты, а указать только один (остальные пакеты удалятся автоматически).
Заключение
На этом все. Новая минорная версия PHP установлена и настроена.
Как установить старую версию php
Иногда бывает нужно установить старую версию какого-либо пакета. Самый простой (хоть и неправильный) путь это скачать нужную версию и установить ее вручную, но тогда придется самостоятельно разбираться с огромным количеством зависимостей. Поэтому самый правильный путь – это прописать дополнительные репозитории и настроить исключения для нужных пакетов.
В данной статье будем понижать версию PHP с 5.4.x до 5.3.x
Для начала нам нужно добавить репозитории, в которых есть нужная версия пакета.
Узнать какая версия пакета в какой ветке дистрибутива можно на сайте https://www.debian.org/distrib/packages
Мы будем ставить пакет PHP из дистрибутива squeeze (в более новых ветках используется PHP 5.4.x)
Чтобы добавить нужные репозитории открываем /etc/apt/sources.list
И добавляем в конец репозитории:
Теперь нам нужно зафиксировать версии пакетов, чтобы не ставились более новые. Для этого мы укажем в файле /etc/apt/preferences.d/preferences из какого репозитория брать нужные нам пакеты.
Package: libapache2-mod-php5
Pin: release a=oldstable
Pin-Priority: 700
Package: *
Pin: release a=stable
Pin-Priority: 600
Для понижения версии PHP нам потребуются все пакеты, которые начинаются с php5, а так же libapache2-mod-php5.
Объяснение строк:
Package: php5* – пакеты, которые попадают под маску php5*
Pin: release a=oldstable – берутся из репозиториев предыдущей версии дистрибьютива (Можно зафиксировать текущую версию и запретить ее изменять. Для этого нужно написать Pin: version 5.3.3-7+squeeze19, где 5.3.3-7+squeeze19 – это версия пакета).
Pin-Priority: 700 – приоритет установки. Чем больше – тем предпочтительней правило.
Таким же образом выдаем указания для пакета (libapache2-mod-php5) и для всех остальных (*). Теперь обновляем информацию в apt:
и устанавливаем наши пакеты:
Теперь остается перезапустить Apache и все готово.
P.S. Полезные команды:
Посмотреть версии всех пакетов, установленных в системе:
Посмотреть доступные версии в репозиториях:
просто установить нужную версию:
где:
php5 – имя пакета
5.3.3-7+squeeze19 – версия.
Удалить пакет вместе с файлами конфигурации:
P.S.
По умолчанию PHP для апача состоит из пакетов:
Если конфигурация более сложная, то нужно проверять зависимости пакетов. Иначе они все могут не установиться. Посмотреть зависимости пакета можно командой:
На этом статья заканчивается. Удачной установки нужных пакетов. Любые другие пакеты ставятся по аналогии.
Как сменить версию PHP на хостинге
Как установить PHP на хостинг
Поддержка PHP присутствует на всех тарифных планах Hosting Linux и Hosting Windows, кроме тарифов Host-Lite и Win-Lite. Если у вас один из этих тарифов, повысьте тарифный план, чтобы включить поддержку PHP.
Как узнать версию PHP на хостинге
На хостинге REG.RU PHP работает в режиме Fast CGI (mod_fcgi). Чтобы узнать настройки PHP вашей услуги хостинга, выполните следующие действия:
Создайте в папке файл info.php со следующим содержимым:
Где находятся настройки версий PHP в ISPmanager
Если на вашей услуге хостинга установлена панель управления ISPmanager, вы можете хранить настройки PHP отдельно для каждого домена, даже если эти домены используют одну и ту же версию PHP. Либо вы можете использовать общую версию PHP и её настройки для всех доменов. Когда вы добавляете домен в панели управления ISPmanager, по умолчанию включается опция php.ini для домена. Если эта опция включена, настройки PHP будут храниться для каждого нового домена отдельно по пути /var/www/php-bin/имя-домена/php.ini.
Обратите внимание! Если внешний вид вашей панели управления отличается от представленного в инструкции, в левом нижнем углу кликните «Старый интерфейс».
Чтобы настройки общей версии PHP действовали сразу для всех доменов, при добавлении домена в панель ISPmanager НЕ отмечайте галочку php.ini для домена. Настройки будут храниться по пути /var/www/php-bin-php(номер-версии-PHP)/php.ini.
Как сменить версию PHP
Чтобы сменить версию PHP, следуйте инструкции для вашей хостинг-панели:
Как установить или обновить php 7 на CentOS 7
Некоторое время назад вышла новая, практически революционная версия php 7. Революционная, потому что обещает существенный прирост производительности, в отличие от предыдущих обновлений. По предварительным данным из описаний и обещаний, якобы в некоторых случаях может быть прирост скорости обработки php в разы. А если не повезет, то на 30-70%. Решил я это проверить на свою голову.
Введение
Я никогда не придавал большого значения версии php, так как не работал с высоконагруженными проектами. Для моих задач мне хватало любой версии, которую поддерживали необходимые мне скрипты. В основном это популярные движки сайтов, админка заббикса и другие прикладные инструменты системного администратора.
Я решил поэкспериментировать и проверить, насколько быстрее будет работать мой блог, если я перейду на php 7. Этот сайт работает на wordpress, до обновления он работал на php54 с включенной системой кэширования apc. Достаточно старая версия, но именно она ставится из стандартных репозиториев centos, которые я использую. Уже не помню точно, откуда он ставится, то ли из базового, то ли из epel. Как оказалось, не зря ставится эта версия. Серия моих экспериментов и проверок подтвердила, что именно на этой версии достигается максимальная производительность в моем конкретном случае.
Но обо всем по порядку. Для того, чтобы отследить изменения и понимать, стало лучше или нет, я решил провести некоторые замеры скорости работы сайта. Начал гуглить эту тему. Вариантов не особо много. Нашел 2 наиболее популярные утилиты, которыми пользуются для тестирования производительности web сервера: ab и siege. Первая входит в стандартные утилиты httpd или apache2, вторая как есть ставится через yum.
Я попробовал обе утилиты и остановился на siege. Она позволяет проводить измерения наиболее приближенные к реальному поведению пользователей на сайте. Не буду в этой статье подробно останавливаться на описании работы утилиты, в интернете информация есть, легко ищется. Если вам нужно, то сами все найдете и протестируете.
Я настроил siege и прогнал серию тестов, создающую разную нагрузку и зафиксировал результаты. После этого стал готовиться к обновлениям. Сразу скажу, что итоговый результат меня не удовлетворил и я вернулся на начальную свою конфигурацию. Обо всем по порядку расскажу.
Обновление php 5.4 до php 7
Сразу расскажу о проблемах, с которыми вы столкнетесь после обновления php70.
Это то, что я заметил сам. Возможно не работает что-то еще. Все это я узнал постфактум, так что обновиться до php70 и прогнать тесты производительности успел.
Теперь информация об обновлении. Существуют как минимум 2 репозитория, которые можно подключить к CentOS 7 и установить обновление php70. Это либо ius с пакетом php70u, либо webtactic с php70w. Чем они отличаются я не знаю, не стал вникать. Я решил воспользоваться репозиторием ius. Подключаем его:
Скрипт подключит нужное репо в соответствии с вашей системой. Теперь можно удалять старую версию php и устанавливать php70.
Дальнейшие действия будут зависеть от того, что вы используете на вашем веб сервере. У меня установлен nginx + php-fpm примерно по приведенной статье. Мне необходимо удалить пакеты:
Удаление этих пакетов тянет за собой удаление всех зависимостей. Запишите их куда-нибудь, чтобы потом установить новые версии этих пакетов. В качестве пакета к удалению будет в том числе и phpmyadmin. Впоследствии его можно будет установить только вручную из исходников. Если вы используете apache, то необходимо удалить mod_php, а затем заново установить mod_php70u.
Устанавливаем php70 вместе с необходимыми пакетами. У меня получился такой список. В нем оказалось не все, что было удалено, пары пакетов я не нашел в новом репо.
Я точно не помню, но скорее всего этот список соответствует требованиям wordpress и phpmyadmin. Больше у меня на сервере ничего не было, поэтому лишних пакетов быть не должно. После установки нужно чуть-чуть отредактировать конфигурацию php-fpm.
Открываем на редактирование /etc/php-fpm.d/www.conf и добавляем туда параметр:
Если в качестве подключения к php-fpm использовали не unix socket, то придется перейти на него. Для этого закомментируйте строку:
Сохраняем конфиг и перезапускаем php-fpm:
Если вы использовали unix socket, то в конфиге nginx ничего менять не надо, если же TCP socket, то нужно заменить строку:
После этого перезапустите nginx:
Обновление php до версии 7.0 окончено. Можно проверять вывод phpinfo();
Подключение модулей кэширования и тестирование производительности web сервера
PHP обновили, сайт запустился, дальше можно погонять тесты. Цифры я приводить не буду, так как в них нет никакого смысла. Они зависят от огромного числа параметров, поэтому в абсолютном значении не представляют ценности. Важны именно изменения значений в рамках одной тестируемой среды. Я буду говорить о примерном результате.
Первым делом я запустил тесты голого php70, без кэширования. Результаты при средней нагрузке, когда сервер успевает обработать все запросы, но работает на пределе своих возможностей, примерно оказались равны php54+apc. Но когда нагрузка сильно возрастает, образуется очередь запросов, php70 начинает в 2-3 раза медленнее обслуживать запросы, время отклика вырастает в 2-3 раза.
Я так прикинул, думаю, вроде неплохой результат. Сейчас включу apc и замерю как с ним будет. Оказалось, что модуль apc давно не поддерживается и поставить его на версию выше php54 нельзя. Вместо него теперь apcu. Думаю ладно, не проблема. Подключаю apcu и тестирую с ним. Результат меня расстроил. На средней нагрузке результат практически не изменился, на высокой нагрузке стал чуть хуже, а на очень высокой вообще в 2 раза просел по сравнению с работой без модуля.
Я понял, что никакого чуда с обновлением php70 не произошло. Прироста производительности я не получил, а получил кучу проблем в виде неработающих плагинов и phpmyadmin. Я принял решение откатываться назад, но не на версию php54, как было, а решил попробовать php56, чтобы проверить, что у него со скоростью.
К сожалению, уже после удаления 7-й версии php, я узнал, что модуль apc и apcu имеют принципиальное отличие и сравнивать только их нельзя. В результате мои тесты оказались недостоверны и с практической точки зрения бесполезны. Дело в том, что apc является opcode cache and data store, а apcu только data store. Таким образом, чтобы корректно протестировать производительность, мне нужно было в php70 включить еще opcache, который является opcode cache. Такая связка показала бы сопоставимый результат.
Мне все же любопытно проверить реальную производительность php70 в рабочей обстановке. Но постоянно пользоваться им пока не представляется возможным из-за проблем совместимости.
Откат обновления php 7.0 до php 5.6
Я решил откатиться на версию php 5.6. Ничего сложного в этом нет. Я уже рассказывал ранее, как в centos обновить php54 до php56. Воспользуемся информацией из этого материала. Сначала удаляем php70:
И устанавливаем все те же пакеты, что мы до этого удалили из версии php54, потом поставили и удалили php70 🙂
Перезапускаем php-fpm. Он может ругнуться на строку:
Если так, то удалите ее. Я не помню, в какой версии она появляется, в 5.6 или в 7.0, в 5.4 ее точно не должно быть.
После отката на php5.6 я подключил модуль apcu и начал гонять тесты. Думаю и так понятно, что они все были хуже, чем php54+apc, так как принципы работы apc и apcu разные. Так что не буду останавливаться на этом. Жаль, что узнал об этом отличии я слишком поздно, когда уже вернулся обратно на php54 и стал спокойно разбираться в ситуации.
Я принял решение откатиться с версии php56 обратно на php54.
Отмена обновления php 5.6 и возврат на php 5.4
Тут все просто. Удаляем php56:
Подключаем и настраиваем apc как описано в моей статье и проводим тесты. Убеждаемся, что производительность вернулась на прежний уровень.
Заключение
Устроил марафон на своем сервере с сайтом. Результат практически нулевой, за исключением полученных знаний. Так как раньше я вообще был не в теме всех нюансов настройки php и веб сервера, получил некоторое представление о том, как все это работает и в какую сторону нужно двигаться для увеличения производительности. Запланировал на тестовом сервере спокойно разобрать этот вопрос и протестировать производительность wordpress.
Подозреваю, что на слабеньких VDS с небольшой памятью и одним процом большого смысла городить дополнительные модули, которые тратят и так маленькие ресурсы сервера, не нужно. Существенного прироста производительности не будет. У меня все всегда упиралось в процессор при высоких нагрузках. Если нужно быстро ускорить wordpress в разы, то достаточно просто включить какой-нибудь кэширующий плагин, который генерирует статические страницы и выдает их пользователям. Прирост сразу же в десятки и сотни раз. Статический контент nginx отдает моментально и даже слабый VDS самого начального уровня способен будет обрабатывать одновременно сотни запросов.
С подобным кэшированием будут вопросы другого рода. Так как людям отдается статика, будут проблемы с комментированием, с интерактивными плагинами. Банальный счетчик просмотров работать не будет. Все эти вопросы можно решить, и некоторые решают, но тут уже нужно подключать специалистов, либо самому разбираться. Это сложные вопросы и решить их просто погуглив не получится. Готовых рецептов нет.
Буду рад комментариям, замечаниям и советам по теме текущей статьи. У меня нет сейчас достаточно времени, чтобы разобраться в нюансах, но есть желание научиться настраивать максимально производительный web сервер для базовых задач размещения популярных движков. Время отклика сайта сейчас влияет на ранжирование сайта в результатах поиска. По крайней мере гугл открыто об этом говорит и призывает всех делать быстрые сайты.