Предисловие
Вот уже 2 дня как вышла новая версия операционной системы CentOS, а именно, CentOS 8. И пока что в Интернете довольно мало статей на тему того, как в ней что-то делается, поэтому я решил восполнить этот пробел. При чем расскажу я не только о том, как поставить эту пару программ, но и о том, как я вообще вижу установку Линукс в виртуальную среду в современном мире для типовых задач, включая разбиение дисков и прочее.
Но в начале я хочу кратенько рассказать о том, почему стоит переходить на эту версию со всех предыдущих, а тому есть аж две причины:
- php7! В прошлой версии CentOS ставился «православный» php5.4…
Ладно, если чуть серьезнее, то очень много пакетов перепрыгнули через несколько версий скопом. Мы (поклонники redhat-ообразных ОС) наконец-то вошли если не в будущее, то хотя бы в настоящее. И сторонники Ubuntu больше не будут над нами смеяться и тыкать в нас пальцами, ну… хотя бы некоторое время ;). - Переход с yum на dnf. Основная разница в том, что теперь официально поддерживается работа сразу с несколькими версиями пакетов. Вот прямо в восьмерке мне это еще ни разу не пригодилось, но звучит многообещающе.
Создание виртуальной машины
Гипервизоры бывают разные и у меня нет цели затачивать читателя под конкретный, расскажу об общих принципах.
Память
Первое… Для установки системы CentOS начиная с 7 точно, а по-моему и в 6 тоже так было («но это не точно»), необходимо минимум 2 ГБ оперативной памяти. Поэтому советую для начала столько и выдать.
Но если что, после установки объем памяти можно и уменьшить. На 1 ГБ голая система работает вполне нормально, я проверял.
Диск
Для нормальной установки следует создать виртуальный диск объемом 20-30 ГБ. Для системы этого хватит. И второй диск для данных. Его можно добавить как на этапе создания виртуальной машины, так и после. Я обычно добавляю потом.
Процессор
На одном ядре голая система не тормозит. А поскольку ресурсы свободно масштабируются, давать больше на этапе установки я смысла не вижу (разве что вы идеально знаете требования и лень лишний раз лезть в конфигуратор)
Остальное обычно можно оставить по-умолчанию.
Собственно установка
Итак… Запускаем установщик… Лично я давно ставлю подобные сервисы только в виде виртуальных машин, поэтому всякие там записи дистрибутива на флешку описывать не буду — просто монтирую ISO в качестве CD-диска в любимом гипервизоре, загрузка и погнали.
Базовая установка проходит довольно типично, остановлюсь только на нескольких моментах.
Выбор источника
С момента выхода восьмой версии зеркало от Яндекса лежит уже который день. Ну, то есть оно периодически поднимается, а потом опять начинает показывать ошибку. Уверен, что дело в чрезмерной нагрузке на сервис. Поэтому для указания источника лично мне пришлось вместо того, чтобы ввести привычный адрес, идти сюда, выбирать там зеркало которое мне нравится и вручную вводить адрес в окне установщика. Тут важно помнить, что указывать надо путь к той папке, где лежит каталог repodata. Например, mirror.corbina.net/pub/Linux/centos/8/BaseOS/x86_64/os.
Разбивка диска
Этот вопрос скорее религиозный на мой взгляд. У каждого админа есть своя позиция на этот счёт. Но я всё-таки поделюсь своей точкой зрения на вопрос.
Да, в принципе, можно всё место выделить под корень и работать будет, чаще всего даже вполне неплохо. Зачем же тогда городить огород с разными разделами? — Основных причины тому на мой взгляд 2: квоты и переносимость.
Например, если что-то пошло не так и на основном разделе с данными возникли ошибки, хочется иметь возможность всё равно загрузить систему и провести реанимационные мероприятия. Поэтому лично я выделяю отдельный раздел под /boot. Там лежит ядро и загрузчик. Обычно хватает мегабайт 500, но в редких случаях может потребоваться больше, а учитывая, что мы уже привыкли измерять место терабайтами, я выделяю под этот раздел 2ГБ. И тут важно то, что его нельзя делать lvm.
Дальше идёт корень системы. Для нормальной установки мне ни разу не требовалось больше 4 ГБ именно на систему, но во время плановых мероприятий я часто использую каталог /tmp для распаковки дистрибутивов, а выделять его под отдельный раздел смысла не вижу — в современных системах он чистится автоматически, поэтому не заполняется. Так что под корень я выделяю 8ГБ.
Swap… По большому счету практической пользы от него мало. Если у вас на сервере стал использоваться свап, сегодня в реальном мире это означает лишь то, что серверу надо добавить больше оперативной памяти. Иначе проблемы с быстродействием гарантированы (либо у какой-то программы «течёт» память). Поэтому этот раздел нужен только для диагностики. Поэтому 2 ГБ это отличная цифра. Да, вне зависимости от того, сколько на сервере памяти. Да, я читал все те статьи, где написано про отношение объема памяти к объему свопа… ИМХО, они устарели. За 10 лет практики мне это ни разу не пригодилось. 15 лет назад я их применял, да.
Выделять ли /home в отдельный раздел ИМХО каждый может решать сам. Если кто-то этим каталогом на сервере будет пользоваться активно, лучше выделить. Если никто — незачем.
Далее, /var. Его на мой взгляд выделять надо обязательно. Для начала можно ограничиться цифрой в 4 ГБ, а там как пойдёт. И да, под «как пойдет» я имею ввиду, что
- Во-первых, всегда можно примонтировать другой диск в подкаталог /var (что я дальше покажу на примере)
- Во-вторых, у нас же lvm — всегда можно добавить. А добавлять обычно приходится тогда, когда слишком много логов начинает туда сыпаться. Но мне заранее предсказать эту цифру никогда не удавалось, поэтому начинаю я с 2 ГБ, а потом смотрю.
Не распределенное место останется свободным в группе томов, его потом всегда можно использовать.
LVM
Все разделы, кроме /boot имеет смысл сделать в LVM. Да, включая swap. Да, swap по всем советам должен быть в начале диска, а в случае с LVM его местоположение определить нельзя в принципе. Но как я уже писал выше, ваша система не должна использовать swap вообще. А потому не имеет никакого значения, где он находится. Ну не в 95 году мы живём, вот честно!
Далее, в LVM есть несколько базовых сущностей, с которыми надо уметь жить:
- физический том
- группа томов
- логический том
Физические тома объединяются в группы, при этом каждый физический том может быть только в одной группе, а группа может находиться сразу на нескольких физических томах.
А логические тома находятся каждый в одной группе.
Но… У нас, блин, опять же 21 век на дворе. И сервера виртуальные. Не имеет смысла к ним применять те же механизмы, которые применялись к физическим. И вот для виртуальных важно иметь данные отдельно от системы! Это очень важно в частности для возможности быстрого переключения данных к другой виртуалке (например при переходе на новую ОС) и вообще всяких полезных плюшек (раздельных бэкапов разделами средствами гипервизора например). Поэтому одна volume group используется для системы и обязательно другая используется для данных! Это логическое разделение сильно помогает в жизни!
Если вы при создании виртуальной машины создали только один виртуальный жесткий диск, на этом конфигурация и заканчивается. А если два, то просто не размечайте пока второй.
Запускаем установку.
Постустановка
Так, наконец-то загрузилась свежеустановленная система. Первое, что надо проверить — интернетик.
ping ya.ruОтвет есть? — Отлично, жмём Ctrl-C.
Если нет — идите настраивать сеть, без этого жизни нет, но моя статья не об этом.
Теперь если мы еще не под рутом, заходим под рута, ибо набирать такое количество команд с sudo лично мне влом (и да простят меня админы-параноики):
sudo -iТеперь первым делом набираем
dnf -y updateИ если вы читаете эту статью в 2019 году, скорее всего ничего не произойдет, но попробовать стоило.
Теперь сконфигурируем оставшийся диск
Допустим, раздел с системой у нас был xvda, тогда диск с данными будет xvdb. ОК.
Большинство советов будут начинаться со слов «Запустите fdisk и создайте раздел...»
Так вот, это неверно!
Я блин еще раз повторю, потому как это важно! В данном случае для работы с LVM, занимающим один целый пусть и виртуальный диск создавать на нем разделы вредно! В этой фразе важно каждое слово. Если мы работаем без LVM — надо. Если у нас на диске скажем система и данные — надо. Если нам почему-то надо оставить половину диска пустой — тоже надо. Но обычно все эти допущения сугубо теоретические. Потому что если мы решим добавить места к имеющемуся разделу, то проще всего это будет делать именно при такой конфигурации. И удобство в администрировании настолько перевешивает много всякого, что мы целенаправленно идём к этой конфигурации.
А удобство заключается в том, что если вы захотите расширить раздел с данными, вы просто добавите места в виртуальный раздел, после чего расширите группу с помощью vgextend и всё! В редких случаях может потребоваться что-то еще, но как минимум не придёться расширять в начале логический том, что уже приятно. А то для расширения этого самого тома рекомендуют в начале удалить имеющийся, а потом создать новый поверх… Что и выглядит не очень приятно и нельзя сделать на живую, а расширение по указанному мною сценарию можно проводить «на лету» даже не размонтируя раздел.
Итого, создаём физический том, потом группу томов, его включающую и потом раздел для нашего сервера:
pvcreate /dev/xvdb
vgcreate data /dev/xvdb
lvcreate -n www -L40G data
mke2fs -t ext4 /dev/mapper/data-www
Тут можно вместо большой буквы «L» (и размера в ГБ) указать маленькую и тогда вместо абсолютного размера указать относительный, например, чтобы использовать половину свободного на данный момент в группе томов места, надо указать "-l +50%FREE"
А последняя команда форматирует раздел в файловой системе ext4 (которая пока что по моей практике показывает наибольшую стабильность в случае если всё сломалось, поэтому я предпочитаю её).
Теперь монтируем раздел в нужное место. Для этого добавляем правильную строку в /etc/fstab:
/dev/mapper/data-www /var/www ext4 defaults 1 2И набираем
mount /var/wwwЕсли выскочила ошибка — бьем тревогу! Потому что это означает, что у нас ошибка в /etc/fstab. И что при следующей перезагрузке у нас будут очень большие проблемы. Система может и вообще не загрузиться, что для облачных сервисов часто весьма печально. А потому надо либо срочно исправлять последнюю дописанную строку, либо удалять её вовсе! Именно поэтому мы не стали прописывать команду монтирования вручную — тогда мы не получили бы такой прекрасной возможности провести проверку конфига вотпрямщаз.
Теперь собственно ставим всё, что хотели и открываем порты под веб:
dnf groupinstall "Development Tools"
dnf -y install httpd @nodejs @redis php
firewall-cmd --add-service http --permanent
firewall-cmd --add-service https --permanent
По желанию можно еще и БД сюда поставить, но лично я стараюсь держать её отдельно от веб-сервера. Хотя держать её рядом быстрее, да. Скорость виртуальных сетевых адаптеров обычно в районе гигабита, а при работе на той же машине обращения происходят почти мгновенно. Но зато менее безопасно. Тут кому что важнее.
Теперь добавляем параметр в конфигурационный файл (создаём новый, современная идеология CentOS'а такая)
echo "vm.overcommit_memory = 1"> /etc/sysctl.d/98-sysctl.confПерезагружаем сервер.
В комментариях меня заругали за совет выключать SeLinux, поэтому я исправлюсь и напишу про то, что после этого надо не забыть настроить SeLinux.
Собственно, профит! :)
Комментарии (36)
danemon
27.09.2019 01:06занятно.
Несколько вопросов. Почему нельзя увеличить размер раздела без монтирования? Очень даже можно. CentOS 7 это позволяет, проверено множество раз на ext3-4 и на чем-то типа BTRFS, не помню точно. Где-то читал что должно стоять в системе чтоб без размонтирования увеличить раздел, не запоминал — просто по факту CentOS это делает сразу из коробки, SuSE — нет.
Зачем вы отключаете selinux? Вы для тестов такую продвинутую виртуалку делаете или для работы?
Про swap пожалуй можно добавить — есть параметр swapiness, что-то вроде предпочтения при использовании swap. В последнем CentOS он не поддерживается? Я не в курсе.
А вместо репозитория Яндекса попробуйте что-нибудь из соседних регионов, Беларусь например, Казахстан вроде есть, и т.д.nioliz Автор
27.09.2019 13:05Во-первых, наоборот без размонтирования. Во-вторых, я не сказал, что нельзя, в моем примере это просто не требуется.
В-третьих, если вначале увеличить виртуальный диск, а потом захотеть увеличить раздел на нём, это рекомендуют делать путём удаления раздела и создания нового бОльшего размера поверх, указывая при создании те же данные, которые использовались ранее. Мне такое на работающем сервере с примонтированным разделом, с которым идёт работа делать страшно. Возможно это и удастся, поскольку таблица разделов в памяти обновляется после partprobe… Но блин, я на своих серверах так экспериментировать не хочу.
Если же увеличивать группу, расположенную на утройстве без раздела, то эта операция вообще не требуется. Что гораздо приятнее.
Ничего «продвинутого» в этой виртуалке нет. Это стандартная конфигурация. Конкретно эта для разработки, запускать на машине с постоянно меняющейся конфигурацией — увольте.
Про swap могу сказать, что лично у меня раздел всегда создан и стоит система мониторинга. Если в какой-то момент раздел начинает заполняться, я получаю сообщение на телефон и иду разбираться что сломалось, очень удобно. Для того и используется. Параметр swapiness в данном случае принципиального значения не играет.linko22
27.09.2019 13:24Есть отличный набор утилит в пакете cloud-utils-growpart (например growpart /dev/vda 2 увеличивает место на сервере на диске vda на разделе 2), очень сильно облегчает увеличение места на диске без использования LVM, мы от него уже везде отказываемся, т.к. вся инфраструктура либо на собственных ВМ, либо в облаках. Все операции по работе с дисками как с LVM так и без давно уже делаются без перезагрузки ВМ. Надо когда-нибудь разродиться статьёй по работам по увеличению дискового размера в разных ситуациях.
danemon
27.09.2019 21:05Во-первых, наоборот без РАЗмонтирования
Согласен, на телефоне просто набирал текст и не заметил смысловую ошибку. В приложении (ужасном, кстати!) нет функционала редактирования комментария.
Zeroxzed
28.09.2019 21:23xfs разделы, в том числе корневые, в centos можно расширять так же удобно, как и lvm прямо на лету, без перезагрузки. Пример — serveradmin.ru/rasshirenie-uvelichenie-xfs-kornevogo-razdela-bez-ostanovki
Сам лично проверял, правда на xfs, а не ext4. Думаю, с ext4 так же будет.danemon
28.09.2019 22:04Да, там то же самое — на лету прямо, в обеих ФС. Из личного опыта — раздел с базой MySQL, активно используемой Zabbix, расширял с полтычка — ни перезагрузки, ни даже остановки службы не нужно, просто делаем свою работу.
Кстати учился по статьям на serveradmin.ru ))
mrobespierre
27.09.2019 03:56для установки CentOS 7 нужно минимум 1 GB памяти (я ставил и на 750 MB), просто нужно освоить kickstart и текстовую установку
отключать SELinux нельзя. просто нельзя и всё.
использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам (ну ext4 — это экскременты (простите за французский)) а в storage продуктах даже не поддерживает(!). SUSE тоже не рекомендует. только XFS.
зачем нужны Development tools (make, strace, gdb вот это всё) на боевом сервере (чтобы проще было руткиты и бэкдоры конпелять?) не оч понятно
Поэтому одна volume group используется для системы и обязательно другая исползуется для данных! Это логическое разделение сильно помогает в жизни!
можно пожалуйста поподробнее, кому помогает, как? бэкап PV — одна простая команда, аналогично и с восстановлением бэкапа, вы всю VG бэкапите? как если не секрет? много лет одной VG обходился…
andreymal
27.09.2019 12:14отключать SELinux нельзя. просто нельзя и всё.
Очень аргументированно.
использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам
А мне вот причины не очевидны, не поделитесь? Попытавшись загуглить, я нашёл эту статью, а в ней ext4 наоборот рекомендуется для некоторых ситуаций.
nioliz Автор
27.09.2019 13:08При текстовом режиме установке с кикстарта по сети при 1 ГБ памяти у меня система падала при установке, ссылаясь на то, что не может что-то распаковать.
/тут должен быть смайлик, разводящий руками/
Arris
27.09.2019 14:03Расскажите пожалуйста о своем негативном опыте работы с EXT4. Почему от него следует отказаться везде и перейти на XFS. Почему не BTRFS?
P.S. Это не ирония.mrobespierre
27.09.2019 16:13негативный опыт: старое здание с протекающей крышей, частые отключения света при дожде (обычное дело — отключение на 6+ часов ночью и на выходных, бесперебойники столько не держали), бывали отключения подряд (т.е. ФС восстанавливается после отключения и в этот самый момент происходит следующее отключение).
EXT4: многочасовые fsck, с которыми непонятно что делать, многократные поломки самой ФС, которые не лечатся fsck вообще (иногда второе следовало за первым т.е. я сидел, ждал, а в итоге ОС не может даже загрузиться)
XFS: любая проверка меньше 15 секунд, нулевое количество разрушений ОС за примерно аналогичный период (2 года против 2.5)
справедливости ради несохраненные данные лучше «выживали» на ext4 (если сама ФС не дохла), но кого это волнует? — у нормального админа все важные данные забэкаплены в любом случае
BTRFS хороша для системного раздела (если использовали атомарные обновления, понимаете), но не для данных (производительность может быть ниже в разы)
crlam0
27.09.2019 21:04Ловил такие проблемы с EXT3/4 на проблемных по питанию серверах, после чего перешёл на ReiserFS и проблем не знаю. Вот с XFS наслышан о случаях с полной потерей данных.
А на счёт RH подобных дистрибах с их «Нажмите CTRl-D чтобы упасть в рутовую консоль» когда fsck не смог проверить раздел с EXT(2/3/4), а ты находишься на лесах с дрелью чуть ли не в зубах помогая другу со строительством его загородного дома, и по телефону, прижатому к уху плечом, диктуешь манагерше, которая перед сервером сама дрожжит ещё хлеще чем ты на этих лесах, рутовый двадцатизначный пароль полный шифтов и спецсимволов — это бесценный опыт. Чтобы НИКОГДА не использовать такие решения как RH и Ext(3/4).nioliz Автор
28.09.2019 21:48Удивительно. У меня вот более 60 линуксовых серверов в парке, потери данных на XFS были раза 2, раза 2 было, что при разбивке в XFS система просто отказывается ставиться через кикстарт (CentOS7)… Вручную-то переразбивал в ext4 и всё ставилось, а кикстарт просто обламывался. Пару раз было, что попадал на необходимость восстановления системы с первого попавшегося LiveCD, а он просто не умел xfs (флешка с живой системой, лежащая под рукой "внезапно" оказывалась старой), поэтому приходилось увозить с объекта диск в офис и разбираться там, а потом везти обратно… А проблем с ext4 лично у меня не было ни разу. Но спасибо за комментарии, учту, что такая статистика тоже есть.
P.S. С ext2 в лохматые годы такое было, да. И с ext3 тоже, но её тогда только выпустили и официально еще не рекомендовали в продакшн.crlam0
29.09.2019 13:27Да и с EXT3 были проблемы когда она уже была рекомендована к использованию. Например если по пресловутому Ctrl-D начать проверять файловую систему и тупо зажать «y» то все файлы оказывались в Lost+Found. Тут вопрос к fsck.ext3 конечно же, но с fsck.reiserfs такого не было. На моей практике один раз пришлось btree пересобрать, и то обошлось с нулём потерянной информации.
P.S. «LiveCD, а он просто не умел xfs» — SytemRescueCD наше всё :)
DoctorMoriarty
27.09.2019 04:23>Отключаем SeLinux, путем перевода параметра «SELINUX» в значение «disabled» в файле /etc/selinux/config и перезагружаем сервер
stopdisablingselinux.com
avlag
27.09.2019 08:08Грусть. Теперь параметрами ядра при загрузке нельзя задать планировщик ввода/вывода. Впрочем как и на свежей Ubuntu.
Но в Centos его хоть можно поменять без перезагрузки через профиль tuned.
mammuthus
27.09.2019 10:28наконец-то вошли если не в будущее, то хотя бы в настоящее.
Ну это про Centos Stream скорее.
MarvinD
27.09.2019 13:09Старайтесь никогда не отключать SELinux. Это на первый взгляд проблемная вещь. Всегда в таких ситуациях считайте, что не отключая SELinux: 1) вы понимаете свой личный уровень, 2) защищаете дополнительно сервер.
И спасибо за инфу что CentOS 8 вышел ;)andreymal
27.09.2019 13:30Поднимите мой личный уровень, пожалуйста: зачем нужен SELinux? Как меня взломают злые хацкеры, если я его отключу? Какие есть ситуации, когда без SELinux прям вообще никак нельзя? Информация из гугла не смогла убедить меня, что SELinux мне действительно необходим — все найденные мной примеры работы SELinux какие-то жутко синтетические и лишь сильнее побуждают бежать отключать его.
MarvinD
27.09.2019 16:54Вообще-то, гугл вас убеждать ни в чем не должен. Если уж так. Это вы должны искать решение своей задачи в гугле. И если вам что-то не нужно или напрягает, это уж точно не проблема гугла.
Когда может быть нужен или полезен SELinux? Дополнительная безопасность, порядок, контроль. Это все SELinux. Кому-то это ненужные возможности, а кому-то помощь.
Из своего опыта:
Например, когда вы его настраиваете, то для того же веб-сервера указываются конкретные директории, где лежат конфиг, логи и пр. И из папки логов .conf не заработает. Т.е. как минимум, структура выполнения будет выдерживаться строже. Левые файлы к процессу доступ иметь не смогут. Если на сервере работают разные люди, то это может так же спасти от неверных действий (запуск не из той директории и пр.).
Плюс пока все это порой выстроишь, самому потом проще документировать, что и где.
Если это хост KVM, то iso-шники, файлы vm и другое должны быть именно там, где они и должны быть. А если вам нужно что-то добавить — не вопрос, semanage fcontext --add -t virt_image_t '/vms(/.*)?'. К примеру.
Возня с SELinux неоднократно приводила лично меня к чистке мусора в конфигах, логах, отлаживанию всяких mysqld, запущенных когда-то кем-то и как-то работающих на стареньком и всеми забытом сервере. На кривых конфигах SELinux может мозг вынести. И это сразу видно, где все четко, а где — бардачокс. Не всегда (даже очень часто) это возможно сделать и нужно делать, особенно на уже запущенном сервере.
Запрет запуска веб-сервера/ssh/чего-угодно-еще на порту, отличном от заданного. Это разве пустяк? Совем нет.
Ну и такая штука, как выполнение левого кода через веб-шелл или еще какие приколы этого плана становятся сложнее для злоумышленника. Это может быть и не спасет, но время оттянет. А может и вовсе отбить охоту ломать такой сервис.
И, заметьте, я не призываю всегда использовать SELinux. Я предлагаю (и сам этому следую) стараться не отключать его. Как-то так.andreymal
27.09.2019 17:37И из папки логов .conf не заработает.
Не могу представить ситуации, когда тот же условный httpd внезапно возьмёт и начнёт читать конфиги из каталога с логами. Разве что вопиющая некомпетентность настраивающего админа, но это не SELinux'ом решать надо
Ну или ещё можно предположить RCE-уязвимость, но тогда через то же RCE можно перенастраивать всё что надо на лету без чтения файлов, не?
Левые файлы к процессу доступ иметь не смогут.
Для этого есть chown/chmod/setfacl, которыми я активно пользуюсь, для особых параноиков даже контейнеры и systemd-nspawn придумали, а к чему тут SELinux — непонятно
это может так же спасти от неверных действий (запуск не из той директории и пр.)
Тоже непонятно о чём речь
Если это хост KVM, то iso-шники, файлы vm и другое должны быть именно там, где они и должны быть.
Поэтому не нужно пускать кого попало к редактированию конфигов, в которых прописаны соответствующие пути. А при чём тут SELinux?
Запрет запуска веб-сервера/ssh/чего-угодно-еще на порту, отличном от заданного.
Вот это уже действительно напоминает что-то полезное. Только вот вовсе не для веб-сервера или ssh (их всё равно может слушать только root и защищать там нечего), а для XMPP на порту 5222, например
выполнение левого кода через веб-шелл
А вот это интересно, как именно SELinux способен запретить подобное? Я могу представить запрет исполнения левых исполняемых файлов, но ведь интерпретацию байткода из памяти процесса всё равно никто не отменял, а как SELinux отличит нормальный байткод от вредоносного — что-то пока не понимаю.
danemon
27.09.2019 21:01При взломе даже самым тотальным образом веб-сервиса (службы httpd, которая доступна через интернет) взломщик не сможет походить по всей файловой системе, позапускать процессы. У службы httpd нет нужных разрешений на это, только работа с каталогами своих собственных конфигов и библиотек, с каталогами веб-сайтов и возможно с сетевыми интерфейсами, по которым доступна БД. Причем httpd сможет добраться только до порта 3306 например, но не сможет вот так запросто отправить поток данных на 389-й порт для попытки взлома другого сервера (контроллера домена, например). seLinux это контролирует.
Даже если веб-сайт написан криво и взломщик сможет написать кучу всяких гадостей в конфиг самого httpd, то на этом раздолье закончится — служба httpd ни как не сможет добраться до других каталогов, процессов, интерфейсов. Это же очевидно — резко снижается масштаб катастрофы при взломе. Вот для чего нужен seLinux.andreymal
27.09.2019 21:33Это же очевидно
Вот ни разу не очевидно. Это всё имеет смысл только при условии, что злоумышленник найдёт в службе RCE-уязвимость, которая позволяет получить root, что уже само по себе событие маловероятное — приходится покопаться в CVE и прикинуть реальность такой ситуации. Но если это маловероятное событие наступает, тогда да, описанные в вашем комменатрии ситуации имеют смысл. Если же у злоумышленника рута нет — тогда остаётся только порты защищать.
nioliz Автор
28.09.2019 22:04Вообще-то веб-сервер должен работать под отдельным непривелегированным пользователем, у которого даже shell в свойствах пользователя не прописан. И естественно доступ к файловой системе у него очень ограничен даже на чтение.
Конфиг апача (в котором указано всё, что апач реально может) взломщик сможет увидеть как при выключенном SELinux, так и при включенном.
Дернуть интерпретатор php — тоже. Получить доступ к телу сайта — опять же. Найти там логин-пароль от базы данных и получить к ней доступ через php — снова.
В итоге, что с SeLinux, что без него, злоумышленник скомпрометировав веб-сервер сможет поломать кусок базы данных (не всю, потому что сайт ходит к базе не под рутом естественно и права сильно урезаны) и всё.
Да, еще он сможет увидеть список сервисов, запущенных на сервере так, как будто фаерволла нет. Что при правильной настройке безопасности внутри самих сервисов (т.е. без использования безопасности через запутывание) ничем ему не поможет.MarvinD
28.09.2019 23:08На мой взгляд, дальнейшие за/против SELinux бесполезны. Мне всегда претят рекомендации "для начала отключим доп. слой защиты". Уж в случае с веб-сервером разобраться можно было бы. Это один из самых уязвимых сервисов, здесь доп защита не мешает никогда. Да, правильно сконфигурированный любой сервис достаточно надёжен. Но если добавить правильно сконфигурированный SELinux, правильно сконфигурированный firewall/fail2ban, хуже не будет ведь? Или с "правильно настроенным" веб-сервисом и fail2ban не нужен? Не обязателен. Но если бы он шел "в коробке" с CentOS, то мануалы бы выглядели так: "для начала вырубаем fail2ban, отключаем SELinux"...
dvglab
27.09.2019 21:16Тот случай когда 10 лет сидишь на zfs и забываешь о fdisk и о разбивке на разделы как о страшном сне. Но все же, есть ли большой смысл в отдельном вирт. диске для данных? Данные можно положить на схд на nfs и монтировать к операционке, там же в схд и встроенный бэкап со снапшотами, вот и данные отделены и операционка отделена.
nioliz Автор
28.09.2019 22:10Если есть отдельная СХД, то можно положить и туда. Но во-первых не у всех она есть: скажем, все облачные сервисы предоставляют устройство целиком, т.е. сервер с дисками без отдельной хранилки. А во-вторых, даже если СХД есть, во многих случаях это оптика и FC либо iSCSI, прикрепленный как раздел к гипервизору, куски которого уже потом раздаются виртуальным машинам как обычные диски.
Но даже если это будет именно nfs-шара, она будет не на том же разделе, где система. Да, она будет не в LVM'е на сервере, но я говорил что данные обязательно отделять. Если кому-то удобнее делать это по NFS, то пускай так, лишь бы рядом не лежали. :)
dvglab
28.09.2019 23:01Я просто на себя примеряю, у меня нетапп который умеет все протоколы, вебсайт и 40гиг картинок, и вот я подумал почему бы не укатить картинки на nfs, а в дев и стэйдж маунтить в fstab, нежели ждать пока вирт.диск склонируется… картинки фактически статическая нагрузка и меняются редко но должны быть везде одинаковы. Кажется nfs тут лучшее что можно придумать.
PS: Первые впечатления от Centos 8 довольно положительные.
questor
Надо же — наконец-то можно будет ставить нормальный свежий PHP без всяких сторонних репозиториев, а то я уже посматривал в сторону debian.
А за перевод selinux в disable — низачёт, не так уж и много нужно поднастроить-то.
linko22
Всего то подключить два репо — remi и remi-7.x на выбор, потом yum update и у вас нужный вам пхп, свежий, с обновлениями.
nioliz Автор
Родные пакеты ставить приятнее. Со сторонними репозиториями всегда возможны конфликты, чего не хочется допускать на боевом сервере. Конкретно установка php7 из репозиторий remi у меня вызвала проблемы с обновлением Zabbix, которые я потом решил путём доустановки какого-то метапакета, но эти танцы с бубном не для продакшена на мой взгляд.