Комментарии 42
Надо же — наконец-то можно будет ставить нормальный свежий PHP без всяких сторонних репозиториев, а то я уже посматривал в сторону debian.
А за перевод selinux в disable — низачёт, не так уж и много нужно поднастроить-то.
Несколько вопросов. Почему нельзя увеличить размер раздела без монтирования? Очень даже можно. CentOS 7 это позволяет, проверено множество раз на ext3-4 и на чем-то типа BTRFS, не помню точно. Где-то читал что должно стоять в системе чтоб без размонтирования увеличить раздел, не запоминал — просто по факту CentOS это делает сразу из коробки, SuSE — нет.
Зачем вы отключаете selinux? Вы для тестов такую продвинутую виртуалку делаете или для работы?
Про swap пожалуй можно добавить — есть параметр swapiness, что-то вроде предпочтения при использовании swap. В последнем CentOS он не поддерживается? Я не в курсе.
А вместо репозитория Яндекса попробуйте что-нибудь из соседних регионов, Беларусь например, Казахстан вроде есть, и т.д.
В-третьих, если вначале увеличить виртуальный диск, а потом захотеть увеличить раздел на нём, это рекомендуют делать путём удаления раздела и создания нового бОльшего размера поверх, указывая при создании те же данные, которые использовались ранее. Мне такое на работающем сервере с примонтированным разделом, с которым идёт работа делать страшно. Возможно это и удастся, поскольку таблица разделов в памяти обновляется после partprobe… Но блин, я на своих серверах так экспериментировать не хочу.
Если же увеличивать группу, расположенную на утройстве без раздела, то эта операция вообще не требуется. Что гораздо приятнее.
Ничего «продвинутого» в этой виртуалке нет. Это стандартная конфигурация. Конкретно эта для разработки, запускать на машине с постоянно меняющейся конфигурацией — увольте.
Про swap могу сказать, что лично у меня раздел всегда создан и стоит система мониторинга. Если в какой-то момент раздел начинает заполняться, я получаю сообщение на телефон и иду разбираться что сломалось, очень удобно. Для того и используется. Параметр swapiness в данном случае принципиального значения не играет.
Во-первых, наоборот без РАЗмонтирования
Согласен, на телефоне просто набирал текст и не заметил смысловую ошибку. В приложении (ужасном, кстати!) нет функционала редактирования комментария.
Сам лично проверял, правда на xfs, а не ext4. Думаю, с ext4 так же будет.
Вы путаете изменение размера раздела и изменение размера файловой системы. Если на разделе есть LVM, то файловой системы там просто нет. Никакой. Только сам lvm.
А так, можно скажем виртуальный увеличить диск, который на машине имеет обозначение xvdc, после этого можно увеличить например раздел xvdc1, после этого можно увеличить файловую систему на разделе.
Геометрия устройства, раздела и файловой системы это 3 разные вещи.
И я пишу про то, что при работе с LVM удобнее избегать последних двух сущностей. Потому что несмотря на то, что изменять область диска, занятую файловой системой, удобно, не удобно перед этим расширять размер раздела.
А конкретно про сравнение lvm и xfs могу сказать, что на одном устройстве может быть скажем 10 разделов. И если понадобилось расширить скажем третий по счёту, то делать это с помощью расширения файловой системы не выйдет просто потому, что после конца раздела с этой файловой системой находится следующая область с данными и расширять раздел некуда. А с помощью lvm — легко и непринужденно, так что lvm всё-таки мощнее. Не зря же у гипервизоров внутри именно lvm.
отключать SELinux нельзя. просто нельзя и всё.
использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам (ну ext4 — это экскременты (простите за французский)) а в storage продуктах даже не поддерживает(!). SUSE тоже не рекомендует. только XFS.
зачем нужны Development tools (make, strace, gdb вот это всё) на боевом сервере (чтобы проще было руткиты и бэкдоры конпелять?) не оч понятно
Поэтому одна volume group используется для системы и обязательно другая исползуется для данных! Это логическое разделение сильно помогает в жизни!
можно пожалуйста поподробнее, кому помогает, как? бэкап PV — одна простая команда, аналогично и с восстановлением бэкапа, вы всю VG бэкапите? как если не секрет? много лет одной VG обходился…
отключать SELinux нельзя. просто нельзя и всё.
Очень аргументированно.
использовать ext4 нельзя. RH не рекомендует этого по очевидным причинам
А мне вот причины не очевидны, не поделитесь? Попытавшись загуглить, я нашёл эту статью, а в ней ext4 наоборот рекомендуется для некоторых ситуаций.
/тут должен быть смайлик, разводящий руками/
P.S. Это не ирония.
EXT4: многочасовые fsck, с которыми непонятно что делать, многократные поломки самой ФС, которые не лечатся fsck вообще (иногда второе следовало за первым т.е. я сидел, ждал, а в итоге ОС не может даже загрузиться)
XFS: любая проверка меньше 15 секунд, нулевое количество разрушений ОС за примерно аналогичный период (2 года против 2.5)
справедливости ради несохраненные данные лучше «выживали» на ext4 (если сама ФС не дохла), но кого это волнует? — у нормального админа все важные данные забэкаплены в любом случае
BTRFS хороша для системного раздела (если использовали атомарные обновления, понимаете), но не для данных (производительность может быть ниже в разы)
А на счёт RH подобных дистрибах с их «Нажмите CTRl-D чтобы упасть в рутовую консоль» когда fsck не смог проверить раздел с EXT(2/3/4), а ты находишься на лесах с дрелью чуть ли не в зубах помогая другу со строительством его загородного дома, и по телефону, прижатому к уху плечом, диктуешь манагерше, которая перед сервером сама дрожжит ещё хлеще чем ты на этих лесах, рутовый двадцатизначный пароль полный шифтов и спецсимволов — это бесценный опыт. Чтобы НИКОГДА не использовать такие решения как RH и Ext(3/4).
Удивительно. У меня вот более 60 линуксовых серверов в парке, потери данных на XFS были раза 2, раза 2 было, что при разбивке в XFS система просто отказывается ставиться через кикстарт (CentOS7)… Вручную-то переразбивал в ext4 и всё ставилось, а кикстарт просто обламывался. Пару раз было, что попадал на необходимость восстановления системы с первого попавшегося LiveCD, а он просто не умел xfs (флешка с живой системой, лежащая под рукой "внезапно" оказывалась старой), поэтому приходилось увозить с объекта диск в офис и разбираться там, а потом везти обратно… А проблем с ext4 лично у меня не было ни разу. Но спасибо за комментарии, учту, что такая статистика тоже есть.
P.S. С ext2 в лохматые годы такое было, да. И с ext3 тоже, но её тогда только выпустили и официально еще не рекомендовали в продакшн.
P.S. «LiveCD, а он просто не умел xfs» — SytemRescueCD наше всё :)
stopdisablingselinux.com
Но в Centos его хоть можно поменять без перезагрузки через профиль tuned.
имхо: о всем и толком ни о чем…
И спасибо за инфу что CentOS 8 вышел ;)
Поднимите мой личный уровень, пожалуйста: зачем нужен SELinux? Как меня взломают злые хацкеры, если я его отключу? Какие есть ситуации, когда без SELinux прям вообще никак нельзя? Информация из гугла не смогла убедить меня, что SELinux мне действительно необходим — все найденные мной примеры работы SELinux какие-то жутко синтетические и лишь сильнее побуждают бежать отключать его.
Когда может быть нужен или полезен SELinux? Дополнительная безопасность, порядок, контроль. Это все SELinux. Кому-то это ненужные возможности, а кому-то помощь.
Из своего опыта:
Например, когда вы его настраиваете, то для того же веб-сервера указываются конкретные директории, где лежат конфиг, логи и пр. И из папки логов .conf не заработает. Т.е. как минимум, структура выполнения будет выдерживаться строже. Левые файлы к процессу доступ иметь не смогут. Если на сервере работают разные люди, то это может так же спасти от неверных действий (запуск не из той директории и пр.).
Плюс пока все это порой выстроишь, самому потом проще документировать, что и где.
Если это хост KVM, то iso-шники, файлы vm и другое должны быть именно там, где они и должны быть. А если вам нужно что-то добавить — не вопрос, semanage fcontext --add -t virt_image_t '/vms(/.*)?'. К примеру.
Возня с SELinux неоднократно приводила лично меня к чистке мусора в конфигах, логах, отлаживанию всяких mysqld, запущенных когда-то кем-то и как-то работающих на стареньком и всеми забытом сервере. На кривых конфигах SELinux может мозг вынести. И это сразу видно, где все четко, а где — бардачокс. Не всегда (даже очень часто) это возможно сделать и нужно делать, особенно на уже запущенном сервере.
Запрет запуска веб-сервера/ssh/чего-угодно-еще на порту, отличном от заданного. Это разве пустяк? Совем нет.
Ну и такая штука, как выполнение левого кода через веб-шелл или еще какие приколы этого плана становятся сложнее для злоумышленника. Это может быть и не спасет, но время оттянет. А может и вовсе отбить охоту ломать такой сервис.
И, заметьте, я не призываю всегда использовать SELinux. Я предлагаю (и сам этому следую) стараться не отключать его. Как-то так.
И из папки логов .conf не заработает.
Не могу представить ситуации, когда тот же условный httpd внезапно возьмёт и начнёт читать конфиги из каталога с логами. Разве что вопиющая некомпетентность настраивающего админа, но это не SELinux'ом решать надо
Ну или ещё можно предположить RCE-уязвимость, но тогда через то же RCE можно перенастраивать всё что надо на лету без чтения файлов, не?
Левые файлы к процессу доступ иметь не смогут.
Для этого есть chown/chmod/setfacl, которыми я активно пользуюсь, для особых параноиков даже контейнеры и systemd-nspawn придумали, а к чему тут SELinux — непонятно
это может так же спасти от неверных действий (запуск не из той директории и пр.)
Тоже непонятно о чём речь
Если это хост KVM, то iso-шники, файлы vm и другое должны быть именно там, где они и должны быть.
Поэтому не нужно пускать кого попало к редактированию конфигов, в которых прописаны соответствующие пути. А при чём тут SELinux?
Запрет запуска веб-сервера/ssh/чего-угодно-еще на порту, отличном от заданного.
Вот это уже действительно напоминает что-то полезное. Только вот вовсе не для веб-сервера или ssh (их всё равно может слушать только root и защищать там нечего), а для XMPP на порту 5222, например
выполнение левого кода через веб-шелл
А вот это интересно, как именно SELinux способен запретить подобное? Я могу представить запрет исполнения левых исполняемых файлов, но ведь интерпретацию байткода из памяти процесса всё равно никто не отменял, а как SELinux отличит нормальный байткод от вредоносного — что-то пока не понимаю.
Даже если веб-сайт написан криво и взломщик сможет написать кучу всяких гадостей в конфиг самого httpd, то на этом раздолье закончится — служба httpd ни как не сможет добраться до других каталогов, процессов, интерфейсов. Это же очевидно — резко снижается масштаб катастрофы при взломе. Вот для чего нужен seLinux.
Это же очевидно
Вот ни разу не очевидно. Это всё имеет смысл только при условии, что злоумышленник найдёт в службе RCE-уязвимость, которая позволяет получить root, что уже само по себе событие маловероятное — приходится покопаться в CVE и прикинуть реальность такой ситуации. Но если это маловероятное событие наступает, тогда да, описанные в вашем комменатрии ситуации имеют смысл. Если же у злоумышленника рута нет — тогда остаётся только порты защищать.
Вообще-то веб-сервер должен работать под отдельным непривелегированным пользователем, у которого даже shell в свойствах пользователя не прописан. И естественно доступ к файловой системе у него очень ограничен даже на чтение.
Конфиг апача (в котором указано всё, что апач реально может) взломщик сможет увидеть как при выключенном SELinux, так и при включенном.
Дернуть интерпретатор php — тоже. Получить доступ к телу сайта — опять же. Найти там логин-пароль от базы данных и получить к ней доступ через php — снова.
В итоге, что с SeLinux, что без него, злоумышленник скомпрометировав веб-сервер сможет поломать кусок базы данных (не всю, потому что сайт ходит к базе не под рутом естественно и права сильно урезаны) и всё.
Да, еще он сможет увидеть список сервисов, запущенных на сервере так, как будто фаерволла нет. Что при правильной настройке безопасности внутри самих сервисов (т.е. без использования безопасности через запутывание) ничем ему не поможет.
На мой взгляд, дальнейшие за/против SELinux бесполезны. Мне всегда претят рекомендации "для начала отключим доп. слой защиты". Уж в случае с веб-сервером разобраться можно было бы. Это один из самых уязвимых сервисов, здесь доп защита не мешает никогда. Да, правильно сконфигурированный любой сервис достаточно надёжен. Но если добавить правильно сконфигурированный SELinux, правильно сконфигурированный firewall/fail2ban, хуже не будет ведь? Или с "правильно настроенным" веб-сервисом и fail2ban не нужен? Не обязателен. Но если бы он шел "в коробке" с CentOS, то мануалы бы выглядели так: "для начала вырубаем fail2ban, отключаем SELinux"...
Во всех остальных случаях анализ пост-фактум показывал, что никакой полезной функции fail2ban не несёт. Ибо атака захлебывается еще на этапе подбора логина (root-то не имеет права доступа по ssh вообще), до подбора пароля ни разу не доходило.
Поэтому хотя я его по привычке обычно и ставлю, могу сказать, что на мой взгляд он не нужен 99% пользователей.
SELinux не решает всех проблем, как не решает их ничто и никто. Но рекомендовать его отключить походя, потому что так быстрее…
Лично я использую fail2ban просто для уменьшения размеров логов, а то многочисленные китайские authentication failure в жирных бинарных логах journald весят ощутимо (до 90% от общего размера логов по примерным прикидкам)
Если есть отдельная СХД, то можно положить и туда. Но во-первых не у всех она есть: скажем, все облачные сервисы предоставляют устройство целиком, т.е. сервер с дисками без отдельной хранилки. А во-вторых, даже если СХД есть, во многих случаях это оптика и FC либо iSCSI, прикрепленный как раздел к гипервизору, куски которого уже потом раздаются виртуальным машинам как обычные диски.
Но даже если это будет именно nfs-шара, она будет не на том же разделе, где система. Да, она будет не в LVM'е на сервере, но я говорил что данные обязательно отделять. Если кому-то удобнее делать это по NFS, то пускай так, лишь бы рядом не лежали. :)
PS: Первые впечатления от Centos 8 довольно положительные.
Веб сервер на CentOS 8 с php7, node.js и redis