Проблема conflicting requests centos

Обновлено: 07.07.2024

Теперь проблема в том, что Composer не может установить необходимую версию пакета symfony/cache , возможно, « потому, что она конфликтует с другим require ».

Как правильно решить эти / такие проблемы с Composer? («Чистый» здесь означает: без сброса проекта, без выполнения повсеместного composer update или создания других жестоких вещей с непредсказуемыми побочными эффектами.)

ОБНОВЛЕНИЕ

composer.json
composer.lock
symfony.lock

composer.json

composer.lock

symfony.lock

2 ответа

Вы уже используете несколько версий пакетов Symfony в своем composer.json , например:

Вы должны очистить это, чтобы избежать несовместимых пакетов. Сделайте это либо с помощью Flex, либо вручную установите все версии пакетов.

Использование Flex

Установите для всех зависимостей, связанных с Symfony, значение "*" , настройте версию Symfony следующим образом:

После этого обновите зависимости Symfony через composer update "symfony/*" .

Для любого последующего обновления до следующей версии требуется только одно изменение в этом разделе.

«Ручная» настройка

Установите все зависимости, связанные с Symfony, на "5.2.*" , обновите их через composer update "symfony/*"

Учитывая ваш результат:

Ограничение пакетов, перечисленных в "symfony / symfony", на "5.0. *"

В настоящее время в вашем composer.json есть что-то вроде этого:

Это означает, что вы не можете обновиться до Symfony в пакете более 5.0.* .

Но теперь вы пытаетесь установить пакет framework-bundle на более крупную версию, но не можете обновить отдельные компоненты.

Чтобы сделать это «чисто», нужно делать это шаг за шагом.

Сначала измените требуемую версию Symfony на 5.2. *, Обновите все пакеты Symfony до этой версии (что да, потребует от вас выпуска composer update ), устраните любые проблемы (если таковые имеются) после обновления и затем установите пакет framework-bundle, который вы собирались установить.

вот это интересная статья, а не графомания по поводу того, что текущие данные в УФ - не всегда данные и не всегда текущей строки. Очень странный сервер с графикой от nvidia и графическим окружением. Обычно Linux сервер ставят вообще без графического окружения (2) В данном случае настраивалось рабочее место, файловые базы.

Ещё более странный выбор. Если уж Linux использовать для рабочего места, то это должна быть Ubuntu. А не серверная система

(12) категорически не согласен, что рабочая станция Ред Хат хуже других решений. Вами незаслуженно обижены специалисты Ред Хат, которые свято верят что их решения сокращают время незапланированных простоев по сравнению с другими системами. Ред Хат это ведущая в мире корпоративная платформа Linux не только для серверов, но и для рабочих станций. Считаю что Windows непригодно для работы, когда в работе надо крутить системные настройки. Например вывести из строя "магазин Виндоуз", без которого операционка становится инвалидом - элементарно, потом уже не восстановить. Убунту тоже не стабильна (поначалу конечно все хорошо, но после череды обновлений - через 1,5 года рассыпается, надежность это не её конек, может если копать слишком глубоко починишь, но оно того не стоит). Убунту 20.04 на двухъядерном проце с 4 гб оперативки жестоко умирает, ред хат линукс 8 с интеграционной шиной фьюз на борту чувствует себя прекрасно. 1ска конечно немного притормаживает на ред хат, но памятую что на Убунте это было гораздо гораздо хуже. Виндоуз и Убунту для меня - давным-давно пройденный этап. А Вы мне кажется не имеете представление о том, о чем пытаетесь судить.

Про Windows это зря. У меня на днях полетел SSD. Больше 20 ошибок UNCR в программе Victoria. И при этом Windows 10 умудрялся как-то загружаться. Иногда с процедурой восстановления

Просто Red Hat - это больше про сервера. С десктопами не так удобно работать. Версии программ или старые в репозитория или не стабильные

Все-таки Fedora - это тестовый полигон для основного продукта со всеми глюками и багами

(12) Извините за некропостинг, но: ваше утверждение в корне неверно. Линуксов нет "серверных" и "не серверных". Установите на десктоп серверное приложение, отключите монитор - вот сервер; установите на "сервер" окружение рабочего стола - вот вам и "рабочее место".

Про "тестовый полигон" тоже искажение фактов. У федоры собственный независимый цикл разработки. Релизы получаются очень стабильными. 8 лет на федоре - ни одного сбоя, хоть ПО по "свежести", о чём вы в (14) говорите, ни разу не старее аналогичной убунты. В той же "свежей" убунту ни одного релиза не было, чтобы не вылазило багов. Что на intel с интегрированным видео или с nvidia, что на amd.

А если учесть, что Ubuntu взяли курс на заворачивание всего десктопа в snap, который в свою очередь намертво прибит к экосистеме Canonial, то использовать Ubuntu - добровольно загонять себя под вендорлок.

Адекватным выбором сейчас будет, как раз, или Debian, или Fedora, или тот, кто придёт на замену ныне покойному CentOS. А учитывая короткий срок жизненного цикла Fedora и туманность будущего наследников CentOS, выбора практически нет.

Старый софт - не старый софт, для работы значение имеет мало. Даже наоборот. Если окружение рабочего стола не будет меняться каждые пол-года\год, пользователи вам спасибо скажут только.

Браузер достаточно свежий, ESR (обычный стабильный выпуск огнелиса использовать тоже так себе идея); документы открываются; рабочее прикладное обеспечение функционирует; обновления безопасности прилетают - что ещё надо?

Как и где появляется ошибка 409?

Выше упоминалось, что природа происхождения ошибки 409 кроется в конфликте запросов. Не всегда эти запросы относятся к пользовательским. Например, такая ошибка может возникнуть при конфликте файлов сайта, если они обращаются к разным данным в одном файле. В результате этого, сервер возвращает ошибку, которая на самом деле не имеет отношения к запросам пользователей.

Основные причины возникновения ошибки 409:

Пользователь обращается к данным, имеющим отличное значение или более новую версию. В итоге, сервер выдает ошибку 409, т.к. существует обновленная версия файла, страницы или скрипта.
Ошибка 409 появилась в результате конфликтующих запросов внутри файлов на сервере. Решить проблему может программист.
Использование прокси, которое конфликтует с определенными адресами или форматами запрашиваемых данных. Не путайте эту ошибку с ошибкой 407.
Более распространенная причина – троян или вирус, который блокирует запросы к определенным сайтам или подгружает файл, который имеет конфликт с конфигурацией браузера.

Ошибка 409 Conflicting Request в большинстве случае решается системным администратором или программистом, если это не касается заражения компьютера вирусом или трояном. Как проверить и какой программой расскажем ниже.

Чистим от вируса или трояна, чтобы убрать ошибку 409

Определить вирус/троян у вас или нет просто – установите программу Cureit от Dr.Web и просканируйте систему этой программой. Она бесплатная и не требует установки. Скачиваем только с официального сайта. В программе отмечаем все пункты для проверки и шагаем спать/на работу, т.к. сама проверка займет длительное время. На скриншоте ниже вы можете рассмотреть, как и что отмечать в программе. Свой антивирус лучше отключить перед проверкой.

Чистим от вируса или трояна, чтобы убрать ошибку 409

Можно также использовать бесплатную утилиту от Касперского, но она довольно сложная и нужно понимать, какие скрипты вводить в консоль. Остальные программы – платные, поэтому не пишу о них. Кстати, не рекомендую скачивать бесплатные ключи, т.к. такие генераторы могут с собой принести тот самый вирус или троян. Не пожалейте 30$ в год за нормальную защиту.

Исправляем ошибку 409 в конкретном браузере

В случае, если ошибка 409 Conflicting Request появляется буквально на каждом сайте, чтобы вы ни нажимали – это точно троян или вирус. Причем это должно происходить в любом браузере. Если нет – можете сразу удалить и заново установить браузер. Возможно произошел сбой конфигурации браузера.

Перед удалением браузера сохраните закладки!

Заранее нужно сохранить закладки, т.к. можно потерять все нажитое непосильным трудом. Делается это просто. На скриншоте выше вы видите пример сохранения настроек в браузере Mozilla. Аналогично делается и в остальных браузерах.

Ошибка 409 в результате правок на сайте

Если вы являетесь администратором сайта или программистом… Вы знаете, что такое бэкап и как им пользоваться. Если не знаете – спросите в комментариях. Что с ним делать? Думаю, ответ знаете сами.

Последнее слово про ошибку

Если уж сильно хочется – установите программу CCleaner и пройдитесь по реестру с помощью этой программы. Во всяком случае это безопаснее, чем делать что-то лично ручками. Манипуляции с компьютером в случае с ошибкой 409 делать не стоит.

В связи с выходом нового релиза популярной операционной системы пришло время актуализировать некоторые статьи. Сегодня я настрою производительный веб сервер CentOS 8 на свежих версиях nginx, php-fpm, где сам php версии 7.2. Сейчас пока нет необходимости использовать сторонние репозитории для php, так как в стандартных присутствует свежая и актуальная версия.

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти .

Цели статьи

Описать общий принцип настройки web сервера на базе nginx.
Показать, как установить актуальные версии nginx, php-fpm и mariadb.
Привести примеры своих конфигов для перечисленных сервисов.
Настроить бесплатные ssl сертификаты let's encrypt для сайтов.
Показать, как настроить selinux для web сервера nginx.
Записать и показать видео настройки веб сервера.

Данная статья является частью единого цикла статьей про сервер Centos.

Введение

В этой статье я расскажу, как настроить производительный web сервер на базе популярного стека технологий - nginx и php-fpm. В связи с выходом нового релиза Centos 8, многие статьи на эту тему стали не актуальны, так как версии софта в базовых репозиториях обновились и тот же php нет смысла ставить из стороннего репозитория.

Работать будем на сервере под управлением CentOS 8. Если у вас его еще нет, то читайте мои статьи на тему установки и базовой настройки centos. Не забудьте уделить внимание теме настройки iptables. В данной статье я ее не буду касаться, хотя тема важная для web сервера.

В самом конце я покажу, как настроить SELinux применительно к данному веб серверу. Приведу список правил, которые нужно будет применить конкретно к моей статье. Правила не универсальные. В зависимости от настройки web сервера, они будут отличаться. Если вам не хочется тратить на это свое время, или вам он не нужен, то просто отключите selinux. Если же нужен, то пока только добавляйте конфиги, но ничего не запускайте, пока не дойдете до самого конца. С включенным и не настроенным SELinux все равно ничего не заработает.

В своей тестовой среде я буду использовать следующие сущности.

Подопытным сервером будет выступать виртуальная машина от ihor, характеристики следующие:

Процессор	4 ядра
Память	4 Gb
Диск	80 Gb SSD

Это кастомная настройка параметров. Они не оптимальны по цене, но мне были нужны именно такие.

Установка nginx на CentOS 8

Для установки самой свежей стабильной версии nginx на centos подключим официальный репозиторий. Я использую именно родной репозиторий по следующей причине. Мне больше нравится начальное расположение и формат конфигурационных файлов. Устанавливая софт из официальных репозиториев ты помимо того, что имеешь самую свежую и актуальную версию nginx, так и расположение и формат конфигурационных файлов будет одинаковый во всех системах.

Банальный пример. Если ставить nginx из официального репозитория centos 8, настройка дефолтного виртуального хоста будет прямо в основном конфиге nginx.conf . Мне лично это не удобно, так как в этом файле я храню набор настроек без привязки к виртуальным хостам. Если установить nginx из официального репозитория, конфигурация дефолтного хоста будет в отдельном конфиге default.conf .

Подключаем репозиторий nginx в centos 8. Я обычно использую mainline версию. Она имеет все нововведения на борту и достаточно стабильна. По крайней мере у меня никогда проблем с ней не было. Если вы хотите стабильную версию, то используйте репозиторий stable. Рисуем конфиг репозитория /etc/yum.repos.d/nginx.repo.

Устанавливаем nginx на сервер.

Запускаем nginx и добавляем в автозагрузку.

Если ее не видите, скорее всего у вас включен и не настроен firewalld. В начале статьи я приводил ссылку на статью с настройкой сервера и настройкой iptables. Если вы с ними познакомились, значит либо уже открыли нужные порты, либо сейчас это сделаете. Для тех, кто не хочет со всем этим разбираться, я просто покажу, как открыть порты 80 и 443 на firewalld, который используется в centos 8 по-умолчанию.

Проверить, открылись ли порты можно командой.

Теперь выполним небольшую начальную настройку. Очень подробно вопрос настройки nginx я разбирал отдельно, рекомендую познакомиться со статьей. Там описано все то, что используется далее в конфигах. Здесь же я их просто привожу, без комментариев и объяснений. Начнем с основного конфига /etc/nginx/nginx.conf.

Сохраните конфиг и проверьте его корректность командой:

Если ошибок нет, то можно применить.

Теперь создадим структуру каталогов для сайтов. Я обычно все сайты размещаю отдельно, например в /web/sites. Создадим там два сайта - основной и панель phpmyadmin для него. Привожу просто для примера, вешать на отдельный виртуальный хост phpmyadmin не обязательно, хотя в некоторых случаях это бывает удобно.

Создаем файл с логином и паролем для доступа.

В данном случае pma - имя пользователя, а пароль будет задан в консоли при выполнении второй команды.

Сохраняем конфиги хостов и движемся дальше. Пока nginx перезапускать не надо. Некоторые сущности, которые упоминются в конфиге, еще не настроены. Одну из них сразу добавим, чтобы не забыть. Нам надо сформировать файл dhparam.pem . Процесс длится долго, до получаса на слабых виртуалках. Этот файл нужен для повышения безопасности и получения максимального рейтинга ssl. Насколько этот параметр критичен в реальности, не берусь судить. Если тороплюсь, то настраиваю без него.

Установка php-fpm

Установка php-fpm в Centos 8 сильно упростилась по сравнению с предыдущей версией, потому что в базовом репозитории хранится актуальная версия php 7.2 , которой можно пользоваться. Пока нет необходимости подключать сторонние репозитории, так как версия 7.2 вполне свежа и актуальна. Если у вас нет необходимости использовать что-то новее, то можно остановиться на этой версии.

Устанавливаем php и php-fpm в CentOS 8, а так же некоторые популярные модули.

Перезапускаем php-fpm и проверяем, запущен ли сокет.

Все в порядке, php-fpm запущен и готов к работе. Cделаем еще одну важную настройку. Назначим nginx владельцем директории для хранения сессий php.

Более безопасно было бы для каждого сайта делать отдельную директорию для сессий и определять ее в настройках php. Но это уже частный случай. В общем случае, можно оставить так.

Возможно, вам захочется поставить более свежу версию php. Как это сделать, читайте в отдельной статье - обновление php-7.2 до 7.4 в CentOS 8.

Для того, чтобы проверить работу нашего веб сервера, нужно установить ssl сертификаты. Без них nginx с текущим конфигом не запустится. Исправляем это.

Настройка бесплатного ssl сертификата Lets Encrypt

Устанавливаем пакет certbot для получения бесплатного ssl сертификата от let’s encrypt. Он находится в репозитории epel, поэтому подключаем его, если еще этого не сделали ранее.

Наша следующая задача - получить бесплатные сертификаты. Для этого временно остановим nginx, если он вдруг оказался запущен и подтвердим владение доменами с помощью temporary webserver, который certbot поднимет сам на время верификации доменов.

После того, как получили сертификаты, можно проверить конфиг nginx и запустить его. Ошибок быть не должно. Если они есть, то разбирайтесь с ними, возможно где-то ошиблись.

Настройка nginx на этом завершена. Он должен корректно запуститься и работать в рабочем режиме.

Приводим его к следующему виду:

По аналогии делаете с остальными виртуальными хостами, для которых используете бесплатные сертификаты let’s encrypt. Осталось дело за малым — настроить автоматический выпуск новых ssl сертификатов, взамен просроченным. Для этого добавляем в /etc/crontab следующую строку:

Все, с сертификатами закончили. Двигаемся дальше в настройке web сервера.

Установка mariadb на CentOS 8

Дошла очередь до установки сервера баз данных mysql для web сервера на CentOS 8 — MariaDB. Я буду устанавливать последнюю стабильную версию на момент написания статьи — 10.5 из официального репозитория с сайта mariadb.

Для того, чтобы подключить репозиторий MariaDB, можно воспользоваться специальной страницей на официальном сайте, где можно задать параметры системы и получить конфиг репозитория.

В моем случае конфиг получился следующий.

Устанавливаем последнюю версию mariadb на centos.

Запускаем mariadb и добавляем в автозагрузку.

Запускаем скрипт начальной конфигурации mysql и задаем пароль для root. Все остальное можно оставить по умолчанию. Авторизацию через сокет отключаем.

Сервер баз данных mysql для нашего web сервера готов. Продолжаем настройку. Установим панель управления mysql — phpmyadmin.

Установка phpmyadmin

Для того, чтобы установить phpmyadmin на наш web сервер, достаточно просто распаковать в директроию с виртуальным хостом исходники панели. Все остальные настройки у нас уже готовы, в том числе виртуальный хост с tls сертификатом.

Архив упакован в zip. Если у вас нет на сервере пакета unzip, установите его.

Распаковываем исходники в директорию виртуального хоста.

Более подробно вопрос установки и настройки phpmyadmin я рассматривал отдельно. Можете зайти в панель и создать базу mysql для тестового сайта, например, wordpress. Затем через консоль загрузить исходники cms и распаковать их.

На этом основная настройка web сервера завершена. Он уже полностью работоспособен. Если вам достаочно этого функционала, то можете сразу переходить к настройке ротации логов.

Доступ к сайту по sftp

Если вы администратор и единственный пользователь, то больше можно ничего не делать. Вы и так сможете загрузить на сервер все что нужно тем или иным способом. Если же вы будете передавать управление сайтами другим людям, им нужен доступ к директории с исходниками сайта. Раньше для этих целей повсеместно использовали ftp. Если вы хотите так сделать, у меня есть статья по настройке ftp сервера vsftpd.

Я же предлагаю использовать sftp по нескольким причинам:

Он безопаснее.
Его быстрее настроить.
Не надо отдельно настраивать firewall.

Статью по настройке sftp доступа я уже тоже писал, все подробности там. Здесь без комментариев выполним необходимые действия.

Создаем пользователя для подключения к сайту и добавляем его в группу sftp. Я обычно использую имя пользователя пересекающееся с названием сайта. Так удобнее управлять.

Открываем конфиг ssh по пути /etc/ssh/sshd_config и комментируем там одну строку, добавляя далее несколько новых.

Перезапускаем службу sshd.

Работа с сайтами разных пользователей на одном веб сервере

Самый простой способ решить проблему с правами доступа, это сделать владельцем папки с сайтом пользователя, который подключается по sftp. Тогда он сможет нормально работать с файлами, загружать и удалять их. Если доступ в качестве группы установить для nginx, то в целом все будет работать. Для каких-то сайтов такой вариант может оказаться подходящим. То есть сделать надо вот так:

И не забываем обратно вернуть владельца на наш chroot каталог, иначе не подключимся по sftp.

А теперь сделаем все красиво. Назначаем владельцем содержимого нашего сайта только отдельного пользователя.

Еще раз обращаю внимание на важный нюанс. Chroot доступ для sftp не будет работать, если владельцем директории, куда чрутимся, будет не root. Будете получать ошибку.

Возвращаем обратно рута владельцем корня chroot.

Перезапускаем nginx и php-fpm и проверяем работу сайта от отдельного пользователя.

Я рекомендую подключиться по sftp, закинуть еще раз исходники wordpress уже по sftp, установить его и добавить новую тему, чтобы проверить, что все корректно работает. По аналогии проделанные выше действия повторяются для всех остальных сайтов.

Настройка SELinux для web сервера

Раздел для тех, кто хочет настроить SELinux на своем web сервере. Сначала ставим пакет policycoreutils-python-utils если он еще не установлен. Он нам нужен для утилиты semanage.

Дальше нам нужно подготовить набор правил для selinux при нашей текущей конфигурации web сервера. Общий смысл их следующий:

У нас нестандартная директория для сайтов - /web/sites, по-умолчанию запросы будут блокироваться.
Надо разрешить nginx взаимодействовать с сокетом.
Позволить nginx управлять параметром rlimit_nofile.
И еще некоторое количество запретов, которые сможете сами проверить.

Суть описываемой дальше настройки selinux сводится к тому, чтобы следить за ограничениями, которые он накладывает на работу сервиса и добавлять исключения в правила, если вы с ними согласны. Методом нескольких итераций готовится набор правил selinux.

Я для этого пользуюсь следующими командами. Просмотр сработавших блокировок selinux для nginx.

Сформировать список правил для selinux.

Этот файл можно потом вручную дополнять или изменять. После того, как все правила будут собраны в один файл, готовлю модуль для selinux.

В конце загружаю этот модуль в selinx.

Можно не собирать правила самому, а сразу получить готовый модуль для загрузки и установить его.

Потом повторите все то же самое для php-fpm и можно проверять работу web сервера. Если в процессе проверки окажется, что что-то еще не работает, опять смотрите audit.log и добавляйте новые правила, пересобирайте и загружайте модуль. Так, через несколько итераций, получится рабочий набор правил для selinux.

Убедиться, что модуль загружен, можно командой.

В целом, по selinux все. Мы просто разрешили все, что веб сервер просил. По идее, надо вдумчиво во всех правилах разбираться и разрешать только то, что считаешь нужным. Я честно скажу, что selinux знаю не очень хорошо. Дальше загрузки готовых модулей и автоматического создания модулей с помощью audit2allow я не двигался. Руками модули никогда не писал. Если есть какой-то более осмысленный и правильный способ настройки selinux на кастомной конфигурации веб сервера, буду рад полезной информации.

Ротация логов веб сервера nginx

Последний штрих в настройке web сервера — ротация логов виртуальных хостов. Если этого не сделать, то через какое-то, обычно продолжительное, время возникает проблема в связи с огромным размером лог файла.

У нас уже будет файл конфигурации logrotate для nginx, который был создан во время установки — /etc/logrotate.d/nginx. Приведем его к следующему виду:

Я предлагаю ротировать файлы логов по достижению ими размера в 10Мб, сжимать после ротации и хранить 10 архивов с логом. Для виртуальных хостов, работающих от отдельного пользователя, новые логи создаются сразу с соответствующими правами, чтобы у пользователя был доступ к ним. Для всех остальных хостов можно использовать самое первое правило, просто добавляя туда новые пути для логов.

Обращаю внимание на важный нюанс при ротации логов по размеру. Скорее всего в общем случае она будет работать не так, как вы ожидаете. Подробности читайте по ссылке. Я привел пример простой конфигурации. Все параметры вы можете поменять по своему усмотрению. Примеров конфигурации logrotate в интернете много.

На этом все. Я рассмотрел все основные моменты, которые необходимы для установки и настройки производительного web сервера на основе nginx и php-fpm последних версий. При этом рассказал о некоторых вещах, которые повышают удобство и гибкость эксплуатации сервера.

Видео

В завершении полное видео настройки web сервера на основе приведенной статьи. Если у кого-то что-то не получается, посмотрите, как это сделал я.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Тема настройки веб сервера обширна. Рассмотреть все варианты в одной статье невозможно, так как функционал будет разниться, в зависимости от назначения сервера. Тем не менее приведу еще несколько ссылок на материалы, которые имеют отношение к настройке web сервера:

Если у вас будут проблемы с ботами, то пригодится статья по блокировке доступа к сайту по странам или защита сайта от ddos.

Если еще что-то полезное вспомню, добавлю ссылки. Пока вроде все. Статья получилось большой и насыщенной. Было не просто все собрать воедино, проверить, связать между собой и оформить в последовательное повестование. Мог где-то ошибиться. Жду комментариев и отзывов. Написал все по своему опыту, как я обычно настраиваю веб сервера. Предполагаю что-то можно сделать более удобно и правильно. Буду рад научиться.

Напоминаю, что данная статья является частью единого цикла статьей про сервер Centos.

Читайте также: