fedora server стабильность

Слишком толсто.

Софт поломается, или будет работать?

Как и везде: чем сложнее конфигурация, тем больше гемороя. Тут скорее другое – реальный пример прям этого форума: Максу вот надоело её обновлять и ЛОР перехал на центось.

Что будет

Это зависит от. Обновишься и узнаешь, в общем.
Когда уймёшь зуд обнововлений, переходи на более стабильные дистры.

и я обновлю дистрибутив через пакетный менеджер?

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

Не рекомендую обновляться на проде в пятницу вечером.

ЛОР перехал на центось.

А подлый редхат тут новый RHEL выкатил, значит ли это, что придётся и центось обновлять?

лет через 10-15 обновлять придётся обязательно, т.к. 7я версия перестанет поддерживаться.

По плану CentOS 7 перестанет поддерживаться через 5 лет.

Поддержка центоси не протухает с выходом новой версии, тут вам не там. Так что не обязательно в обозримом будущем.

Понятненько. Лучше будет подождать Centos 8. Сейчас работает ubuntu 18.04. Но хочется Selinux.

поломается, или будет работать?

Именно так.

Fedora - есть, была и будет тестовым полигоном для Red Hat'а. Нужна стабильность? Добро пожаловать на CentOS.

Fedora Server? Звучит как Arch Server. А учитывая её стабильность(даже арчик последние года три или четыре у меня работал более стабильно) - я бы не стал на серьёзном проекте ставить подобное на сервер. Обновляется оно примерно как Ubuntu - в 99% случаев без проблем. Но если уж проблема возникнет, то разруливать её будете долго и с бубном.

Мне любопытно, чем вам Centos(или Debian стабильной версии) не подошли?

Уже понял, что лучше Centos. Selinux не работает в дебиан/убунту из коробки. Дебиан/убунту - хороши.

SELinux хорош, но умеете ли вы его готовить? Как вы его используете, пишите свои политики под свои приложения?

Вопрос не в стабильности системы, а в софте который ты собираешься гонять.

Будешь ли регулярно обновляться до новых версий mariadb,php,.. Если нет, то пока модули с долгосрочной поддержкой старых версий не примутся, имеет смысл сидеть на центоси.

Контекст задаю для файлов друпал, с которыми работает nginx.

Вывод: федора сервер, на сервер не годится. Я обновлюсь, обновится мой php, а друпал не будет его поддерживать. И будет мне горе.

Как-то грустно с модулями. Вроде, вначале так рьяно начали печь модули, а сейчас посмотришь - тишина как на кладбище.

Ага, всем бы такая тишина. Мы ещё после того как майнтейнер всех Java пакетов их в модули отправить решил последствия не разгребли.

Modularity уже готова и взлетела. Модули для основных БД и для языковых тулчейнов сделаны. К примеру у тебя есть выбор какой из постгресов поставить на F30: 9, 10 или 11. Это именно то для чего оно создавалось и оно работает.

Сейчас идет фаза «устаканивания», выработка политик - что модуляризовывать а что нет, как взаимодействовать с майнтейнерами, как отслеживать разноплановые циклы поддержки и т.п. Плюс технический долг по инфровым задачам.

Поэтому кричать уже не надо, надо пользоваться.

Зависит от того какой сервер и в каких сценариях используется.

Если у тебя к примеру контейнеризованные приложения, разработка и и т.д., то тебе может быть интересно обновлять ядро, systemd и container tools чтобы получать все новые фишки которые с ними приходят.

Если же всё нативно и статично, то статичная система конечно удобнее.

У меня без докера. Процессы работают в lxc/lxd контейнерах, но это лишняя прослойка.

Установил на десктоп федора 30, и мне понравилось. Завелся kvm, vaapi, viber. Понравился lvm, firewalld, selinux. Вот и появились мысли о сервере. Но смущает, что она обновляется раз в пол года. Поэтому спросил как оно на сервере.

Теперь понятно, что лучше centos.

ещё после того как майнтейнер всех Java пакетов их в модули отправить решил

Кошмар! Это же такое болото...

Я обновлюсь, обновится мой php, а друпал не будет его поддерживать. И будет мне горе.

А с другой стороны типичная ситуация с CentOS:

Твой Drupal обновился и перестал поддерживать версию php, которая имеется в CentOS.

Коварно то как! =)
И что тогда делать? Ubuntu lts + ppa?

Убунта-то чем поможет. Это опять кейс для модулей, и в centos8 они тоже будут, чуточку более ограниченные чем в ф30.

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

И что тогда делать? Ubuntu lts + ppa?

В данный момент можно CentOS + SCL или всякие там epel, remi.

Но в CentOS’е 8 можно будет заюзать podman для этого дела. Насколько хорошо это будет работать – пока мне неизвестно.

Спасибочки. Надо будет попробовать SCL.

У меня из SCL для Wordpress установлена связка пакетов:

1. rh-php72, rh-php72-php-fpm (PHP 7.2)
2. rh-nginx114 (nginx 1.14)
3. rh-mariadb102 (MariaDB 10.2)

Получилось. Завел дпупал с вашей подсказкой, о пакетах из SCL.
За что и большое спасибо. Да прибудет с вами, на пути вашем, удача большая =).

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

Но если у тебя маленький сервачок на котором ты гоняешь свою домашнюю страничку с котиками - обновляй, заодно узнаешь.

Linux comes with ABSOLUTELY NO WARRANTY

Мне тоже по душе Centos на серверах. И не только из-за того, что он из коробки с Selinux идёт. Но и из-за определённой унификации с RH/Fedora/Oracle Linux и производных(те же наименования пакетов, те же способы настройки серверного ПО, то же наименование юнитов systemd) и т.п. Да даже такая удобная фича как firewalld из коробки есть. Debian и Ubuntu хороши, в некоторых кейсах очень хороши. Но они - другие. Со своей спецификой. Если нет особых требований со стороны соответствующего ПО, я предпочту Centos.

Кстати очень хороший вопрос. SELinux нужно уметь готовить. Если нет опыта в настройки и создании политик под прилоежния - его придётся отключать.

Видно джедая, знающего толк в обновлении ОС на боевых серваках :) Тот, кто сам батхёрта от последствий не удачного обновления на продакш-серваке не ощутил, всё равно ваш совет не примет серьёзно. Тут батхёрт обязателен, так как без своих граблей иногда ничему не учишься. А как огребёшь - делаешь выводы.

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

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

Хороший опыт!

Это не «хороший опыт», это здравый смысл и банальная техника безопасности, по факту - единственный нормальный путь.

Ты спокойно будешь тестить новый сервак (попутно исправив стопицот ошибок миграции и нагородив стопицот костылей), пока твой старый прод тихо-мирно себе функционирует и ничего с ним не случается.

Иногда после таких приседаний админы и вовсе отказываются от миграции на новую платформу :)

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

Я обновлюсь, обновится мой php, а друпал не будет его поддерживать.

Если и php, и drupal ставились из репозитория, то этого не произойдет в норме не должно происходить и является серьезной причиной репортить баг, если произошло. В любом дистрибутиве.