Русские Блоги
Сервер CentOS7 yum, установка и удаление Apache
Недавно я узнал о соответствующем содержимом сервера CentOS7. Недавно я реализовал оптимизированный метод настройки для нескольких доменных имен Apache (httpd). Запишите его, чтобы не забыть.
Системная среда: Tencent Cloud CentOS 7.2 x64
apache запускает связанные команды
| команда | Особенности |
|---|---|
| sudo systemctl stop httpd | Остановите службу Apache: |
| sudo systemctl start httpd | запускать |
| sudo systemctl restart httpd | Перезапустите службу Apache: |
| sudo systemctl reload httpd | После внесения некоторых изменений конфигурации перезагрузите службу Apache: |
| sudo systemctl disable httpd | Отключите службу Apache для запуска во время загрузки: |
| sudo systemctl enable httpd | И снова включите его: |
Удалить
Во-первых, установка Apache (httpd)
Тест доступа
Затем мы используем curl для доступа к локальному:
Два, конфигурация программного обеспечения
Достаточно отредактировать httpd.conf, httpd.conf находится в / etc / httpd / conf
1. Используйте #, чтобы закомментировать следующие две строки (на самом деле, если вы не комментируете, это не повлияет на вас).
2. Открыть разрешения на использование каталога.
3. Запишите информацию о виртуальном хосте.
② Запишите информацию об одном виртуальном хосте
В-третьих, полный процесс
Пример приведен только для справки, если у вас есть другие потребности, измените его в соответствии с ситуацией.
1. Консольные команды
2. Измените httpd.conf (опустите части, которые не нужно изменять)
(DocumentRoot) и (Directory) должны быть согласованы. Просто уйди из группы. Другая конфигурация по запросу
Затем вам нужно создать файл записи index.html в этом каталоге.
Затем вы можете получить доступ
команда curl 127.0.0.1
Удалить
Прежде всего, чтобы подтвердить, установлен ли он или в системе есть служба httpd, с помощью следующей команды:
Я установил его один раз, поэтому он будет выглядеть следующим образом:
Затем я сначала удаляю свой httpd, сначала останавливаю службу httpd, команда выглядит следующим образом:
В середине вас спросят, хотите ли вы подтвердить, y в порядке, до тех пор, пока не появится надпись Complete!, Означающая, что удаление завершено.
установка
Если вы хотите убедиться, что удаление является чистым, вы можете использовать команду list для вывода списка установленных (первый шаг удаления). Мы не будем делать этого здесь, мы просто используем для вывода списка httpd-элементов на складе yum, команда выглядит следующим образом:
Затем, увидев доступные элементы, мы вводим следующую команду для установки:
Введите «y» в середине, и установка будет завершена.
Затем мы проверяем текущий статус httpd с помощью следующей команды:
Если фактический httpd не запущен, мы можем запустить службу с помощью следующей команды:
Каталог www по умолчанию находится в / var / www / html /, поэтому мы пишем файл html, чтобы увидеть, что происходит, введите команду для создания файла, содержащего строку hello world:
Тест доступа
Затем мы используем curl для доступа к локальному:
PHP 7 обновление в CentOS 7
Рассмотрим обновление на PHP 7-ой версии в системе CentOS 7 работающей с Nginx. Произведем настройку после обновления необходимых конфигурационных файлов для работы ресурсов использующих php. Процесс обновления сложный требующий внимания и ответственности.
Введение
Рано или поздно приходит время обновить старую версию PHP на новую. Как правило это обусловлено требование при обновлении ресурсов которые не смогут работать со старой версией. Редко обновление приходит без ручного вмешательства в редактирование конфигурационных файлов.
Обязательно перед обновление сделайте резервную копию системы и после обновления максимально проверьте все ресурсы использующие PHP!
В моем случае я обновляю версию которую устанавливал в статье Установка и настройка PHP.
В другой статье вы узнаете как работать с PHP используя репозиторий Remi для CentOS 7.
Удаление старой версии PHP
Перед тем как установить новую версию нам надо определить какая стоит версия, какие пакеты и с какого репазитория.
Подготовка перед удалением
Проверим установленную версию:
Выведем весь список установленных пакетов:
Исходя из вывода удалим все эти пакеты. Новую версию php мы будем устанавливать с другого репазитория. Репозиторий remi нам больше не нужен и мы его удалим.
Удаление PHP 5.6
Удалим одной командой:
Внимательно смотрим лог обновления на предмет ошибок и предупреждений! Сохраните все ошибки и предупреждения. Уверяю в последствии это сильно сократит время в настройке после обновления!
Удаление репозитория Remi-safe
Не вижу смысла держать репозитории которые больше не используются и всегда их удаляю.
Выведем список всех используемых репозиториев:
В выводе видим точное имя которое мы используем при удалении:
После всех действий обновим систему чтобы окончательно всё подготовить к установке новой версии:
Установка новой версии PHP
Выбор репозитория и версии PHP 7
Вероятно есть разные варианты установки PHP 7 версии, но мне нравится репозиторий WebtaticEL про него и расскажу.
Перейдя по ссылке вы увидите все варианты версий возможных для установки а так же способы их установки в необходимую вам систему. Мой выбор пал на версию PHP 7.1 так как на данный момент это самая стабильная новая версия.
Добавление репозитория Webtatic
Добавим репозиторий в систему:
После добавления любого репазитория необходимо обновить список пакетов. В CentOS это можно сделать командой вывода всех репозиториев которая заодно и обновит весь список пакетов:
Установка PHP 7.1
Установим все нужные мне пакеты исходя из тех что удалял:
Сознательно не стал ставить параметр с которым всё установится без вопросов. Лучше всегда быть на контроле таких сложных и ответственных обновлений.
Можем уставим все что есть, но решать вам самим что для вас лучше:
После обновления я предпочитая перезагрузить систему чтобы окончательно избавится от сомнений что что то работает по старой схеме и после перезагрузки перестанет работать.
Проверка после обновления PHP
После обновления первым делом проверим какая версия php в системе:
Видим что установилась новая версия, но почти со 100% уверенностью могу сказать что при попытке открыть свой интернет ресурс вы обнаружите что он не работает. Вот тут то и пригодятся все наши сохранённые предупреждения при удалении, обновлении и установке новых пакетов.
Ошибки в логах установки/удаления
В моем случае было несколько предупреждений:
Как видите система сказала что в двух случаях она создала новые файлы а старые сохранила с пометкой rpmsave. В случае когда система не смогла создать новый файл она создала его с пометкой rpmnew.
Любыми удобными вам способами сохраните копии созданных новых рабочих файлов. Необходимый вам код из старых сохраненных обновлением файлов перенесите в новые рабочие файлы. Мне было необходимо отредактировать два файла /etc/php-fpm.d/www.conf и /etc/php.ini.
На моих системах, с которыми я работаю, мне не доставляет это большого труда, так как весь код что я правлю документируется. Всегда комментирую старый код и пишу новый с пометками. При таком подходе мне проще понять код и тому кто будет работать с системой после меня будет проще разобраться при возникновении проблем.
Настройка PHP-FPM после обновления
Так как у нас работает Nginx и для связки с php используется php-fpm мы проверим необходимую службу:
Из вывода мы видим что служба остановлена и отсутствует в автозагрузке. Добавим в автозагрузку, запустим и посмотрим статус:
Из вывода команды мы видим ошибку во второй строке файла /etc/php-fpm.d/www.conf. Откроем и посмотрим код:
Видим что вторая строке и отключена знаком #. Посмотрев в сохранном созданном установщиком новом файле увидим что все отключения идут знаком ;. Заменив все знаки # на ; сохраним и перезапустим службу и посмотрим статус:
Видим что служба находится в автозагрузке и работает.
Вывод всех параметров PHP 7
Последнее что нам осталось сделать для полного понимания проделанной работы это посмотреть вывод всей информации о версии php. Создадим на работающем ресурсе в корневой директории сайта файл info.php и поместим туда код:
Достаточно набрать в строке браузера http://IP или ИМЯ/info.php и вы увидите страницу примерно с таким содержанием:
PHP Version 7.1.8
Вывод
Судя по статье может показаться что обновление версии PHP не такое уж и сложное дело но уверяю что эта простота придет только с опытом. Многое зависит от того как долго не обновляли систему, какие ресурсы там работают и какие у каждого в отдельности требования к версии php. В случае если вам досталась система с которой работали разные люди и мало чего комментировали в коде сложностей может возникнуть очень много и единственное что вас спасет от головной боли в случае неправильной работы важных ресурсов это резервное копирование перед выполнением обновления. Лучшим вариантом при обновлении таких систем это сделать клон системы и производить все действия на нем. Конечно при работе с клоном может возникнуть дополнительные сложности но это уже другая тема.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Как установить или обновить 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 сервер для базовых задач размещения популярных движков. Время отклика сайта сейчас влияет на ранжирование сайта в результатах поиска. По крайней мере гугл открыто об этом говорит и призывает всех делать быстрые сайты.
Жонглируем версиями PHP в системе
Проблема “ хочу новую версию %software% на моем стареньк … стабильном Debian/CentOS…” так же стара, как *nix-мир. Способов добиться желаемого хватает. Есть масса решений как притащить в систему несколько версий одного и того же софта. Но дальше хочется не просто иметь ещё одну версию, но и управлять тем, какая из версий доступна в системе по умолчанию, для конкретных приложений или пользователей.
Что делать, если хочется сменить системную версию PHP на одну из кастомных сборок? Давайте отталкиваться от того, что у вас на сервере уже установлено несколько версий PHP и вы хотите, чтобы в консоли команда php была конкретной версии, отличающаяся от той, что шла с системой. В этой статье я расскажу, как правильно это настроить, чтобы не было проблем с будущими пакетными обновлениями.
В качестве примера возьмём сервер на CentOS 7, где установлен родной PHP:
Также на сервере установлен наш Plesk с парой своих сборок PHP:
Допустим, мы хотим переключить систему на использование PHP 5.6 по умолчанию (переключать глобально PHP с версии 5.4 на 7 как-то сс… страшно — чему-то в системе может поплохеть от такого). Бинарь PHP 5.6 лежит у нас тут:
Как же сделать так, чтобы система использовала эту, нужную нам, версию PHP?
Сначала посмотрим на системную переменную PATH
В ней перечислен список директорий, в которых ищутся программы по имени. Главный нюанс — поиск в директориях происходит последовательно и используется первый найденный результат. Текущий путь до текущего бинарника PHP мы можем увидеть с помощью команды:
Теперь, давайте зарегистрируем все доступные версии PHP с помощью этой команды:
Цифры 10, 20 и 30 — это приоритет. Он работает для автоматического выбора, если администратор сам не выбрал конкретную версию. Самое большое число определяет выбор «по умолчанию».
Проверим, что php теперь указывает на созданную командой симлинку:
Давайте разберемся, что же update-alternatives сделала для нас:
Как видно, она создала цепочку симлинок и теперь по требованию просто меняет промежуточную симлинку на нужный нам бинарь.
Давайте переключимся на PHP версии 5.6, которая идет в поставке с Plesk’ом:
Проверяем, что переключение произошло:
Все отлично работает. Теперь в системе используется нужная нам версия PHP и я не опасаюсь, что эта настройка слетит при следующих пакетных обновлениях.
С помощью update-alternatives можно выбирать не только версию PHP, но и многие другие вещи, например разные версии phpunit или редактор по умолчанию в системе. Подход этот универсален для различных систем. Не изобретая своего велосипеда, используя существующие инструменты, вы можете быть уверенным, что не устроили для ваших коллег квеста “Ну почему оно так работает?!”. Настраивайте свою систему правильно.
Полное удаление и повторная установка PHP на Centos 7
Мне нужно было попробовать PHP 5.6 и 5.5 на Centos 7. Итак, я установил их поверх идеальной рабочей установки PHP 7.1. Я следовал инструкциям здесь: https:/ / www.mojowill.com / geek/howto-install-php-5-4-5-5-or-5-6-on-centos-6-and-centos-7/
В принципе, я отредактировал конфигурационный файл remi repo, чтобы включить PHP 5.6 и 5.5, и установил PHP 5.6. Я проверил то, что хотел проверить, и попытался переключиться обратно, отключив репозитории и удалив все php, а затем переустановив снова. Теперь у меня проблемы.
Вот симптомы и то,что я пробовал.
Я получаю сообщение об установке WordPress » Your PHP installation appears to be missing the MySQL extension which is required by WordPress. «
Я попытался проверить, установлен ли еще php-mysql:
Есть ли какое-то простое решение этого беспорядка, или я должен просто заново установить всю машину разработки.
1 ответ
Я экспериментирую с Hadoop и Spark, поскольку компания, в которой я работаю, готовится начать раскручивать Hadoop и хочет использовать Spark и другие ресурсы для большого машинного обучения наших данных. Большая часть этого ложится на меня, поэтому я готовлюсь, учась самостоятельно. У меня есть.
Я строю двоичный файл FOO на Centos 7 (использует glibc 2.14 ) и хочу, чтобы он работал на Centos 6 (имеет только glibc 2.12 ) Если я установлю glibc 2.14 параллельно в системе Centos 6: https://unix.stackexchange.com/вопросы/176489/how-to-update-glibc-to-2-14-in-centos-6-5#299665 тогда что мне.
Сначала удалите все, что касается старой версии php (потребуется некоторое время. )
затем установите более новую версию (это займет еще больше времени)
не забудьте сделать перезагрузку и проверить sudo apachectl перезапуск systemctl статус httpd
Если вы используете fpm с NGinX, то используйте следующую деинсталляцию (это сохранит конфигурацию только для удаления пакетов / зависимостей)
(используйте [72] вместо [7], если вам нужно)
сохранение, выход и перезапуск
пожалуйста, подумайте о переходе на версию 7.1, так как это может быть немного менее болезненным подключением модулей, чем последняя версия, особенно на всегда проблемном centOS
(спасибо @fyrye за опции по удалению)
Похожие вопросы:
Я пытаюсь установить среду выполнения MATLAB (см. www.mathworks.com/products/compiler/mcr) на Cent0S 7. Я думаю, что установил MCR правильно, потому что установка завершается тем, что она завершена.
когда я пытаюсь установить SteamCMD на CentOS 7, я получаю ошибку: Login Failure: No Connection, я могу подтвердить, что selinux отключен, и что брандмауэр выключен, я могу заставить его нормально.
Я экспериментирую с Hadoop и Spark, поскольку компания, в которой я работаю, готовится начать раскручивать Hadoop и хочет использовать Spark и другие ресурсы для большого машинного обучения наших.
Я строю двоичный файл FOO на Centos 7 (использует glibc 2.14 ) и хочу, чтобы он работал на Centos 6 (имеет только glibc 2.12 ) Если я установлю glibc 2.14 параллельно в системе Centos 6.
Я пытаюсь установить Magento 2.1 с помощью PHP composer. http://idroot.net/tutorials/how-to-install-php-composer-on-centos-7 / Я нашел url выше, чтобы установить PHP composer для Centos 7. на шаге 2.
Мое приложение основано на фреймворке Laravel, и мне нужно построить контейнер Docker с этими спецификациями: CentOS / RHEL 7.x PHP 7.x PHP расширения: OpenSSL PDO Работы mbstring Токенизатор XML Но.
как установить Haxe на centos 7 из этого учебника нет платформы Centos, есть ли какая-либо установка тела на Centos успешной?
У меня ВПС centos 7 и вам нужно понизить версию php 7 до 5.6 понижение версии php 7 до 5.6 на VPS centos 7 ошибка : нет пакетов, помеченных для удаления