Так конфигураций разных бывает много. Та, которую описываете Вы мне вот ни разу не пригождалась. Между двумя аппаратными портами может быть разница в том, что к одному порту влан должен быть подцеплен с тэгом, а к другому -- без, опять же, обычно речь идёт не про работу с одним портом, а про работу с разными... Короче, я описываю то, как можно начать понимать логику работы вланов, а не реализацию отдельно взятого случая.
Это всё отлично применимо ко всему, где есть Router OS, даже к тем свичам, которые перешиваются из Switch OS в Router OS, вне зависимости от аппаратной платформы.
fail2ban штука конечно хорошая, но вот случай, где он реально был нужен лично у меня был один за всю жизнь. :) Работал на государя и обслуживал сервис, аудитория которого была несколько миллионов человек, сервис был кривой «шо пипец», встроенных защит никаких… При этом он был веб естественно. И вот защищать систему от перебора паролей китайскими хакерами не было вообще никаких других вариантов. При чем благодаря fail2ban'у удалось реально снизить трафик через интерфейс. Прям чуть ли не в 2 раза. При этом интересно было то, что логи для анализа брались с другого сервера, находящегося в DMZ по SMB.
Во всех остальных случаях анализ пост-фактум показывал, что никакой полезной функции fail2ban не несёт. Ибо атака захлебывается еще на этапе подбора логина (root-то не имеет права доступа по ssh вообще), до подбора пароля ни разу не доходило.
Поэтому хотя я его по привычке обычно и ставлю, могу сказать, что на мой взгляд он не нужен 99% пользователей.
Да, отменно. Как скажем и ext4, что также проверено неоднократно. :)
Вы путаете изменение размера раздела и изменение размера файловой системы. Если на разделе есть LVM, то файловой системы там просто нет. Никакой. Только сам lvm.
А так, можно скажем виртуальный увеличить диск, который на машине имеет обозначение xvdc, после этого можно увеличить например раздел xvdc1, после этого можно увеличить файловую систему на разделе.
Геометрия устройства, раздела и файловой системы это 3 разные вещи.
И я пишу про то, что при работе с LVM удобнее избегать последних двух сущностей. Потому что несмотря на то, что изменять область диска, занятую файловой системой, удобно, не удобно перед этим расширять размер раздела.
А конкретно про сравнение lvm и xfs могу сказать, что на одном устройстве может быть скажем 10 разделов. И если понадобилось расширить скажем третий по счёту, то делать это с помощью расширения файловой системы не выйдет просто потому, что после конца раздела с этой файловой системой находится следующая область с данными и расширять раздел некуда. А с помощью lvm — легко и непринужденно, так что lvm всё-таки мощнее. Не зря же у гипервизоров внутри именно lvm.
Если есть отдельная СХД, то можно положить и туда. Но во-первых не у всех она есть: скажем, все облачные сервисы предоставляют устройство целиком, т.е. сервер с дисками без отдельной хранилки. А во-вторых, даже если СХД есть, во многих случаях это оптика и FC либо iSCSI, прикрепленный как раздел к гипервизору, куски которого уже потом раздаются виртуальным машинам как обычные диски.
Но даже если это будет именно nfs-шара, она будет не на том же разделе, где система. Да, она будет не в LVM'е на сервере, но я говорил что данные обязательно отделять. Если кому-то удобнее делать это по NFS, то пускай так, лишь бы рядом не лежали. :)
Вообще-то веб-сервер должен работать под отдельным непривелегированным пользователем, у которого даже shell в свойствах пользователя не прописан. И естественно доступ к файловой системе у него очень ограничен даже на чтение.
Конфиг апача (в котором указано всё, что апач реально может) взломщик сможет увидеть как при выключенном SELinux, так и при включенном.
Дернуть интерпретатор php — тоже. Получить доступ к телу сайта — опять же. Найти там логин-пароль от базы данных и получить к ней доступ через php — снова.
В итоге, что с SeLinux, что без него, злоумышленник скомпрометировав веб-сервер сможет поломать кусок базы данных (не всю, потому что сайт ходит к базе не под рутом естественно и права сильно урезаны) и всё.
Да, еще он сможет увидеть список сервисов, запущенных на сервере так, как будто фаерволла нет. Что при правильной настройке безопасности внутри самих сервисов (т.е. без использования безопасности через запутывание) ничем ему не поможет.
Удивительно. У меня вот более 60 линуксовых серверов в парке, потери данных на XFS были раза 2, раза 2 было, что при разбивке в XFS система просто отказывается ставиться через кикстарт (CentOS7)… Вручную-то переразбивал в ext4 и всё ставилось, а кикстарт просто обламывался. Пару раз было, что попадал на необходимость восстановления системы с первого попавшегося LiveCD, а он просто не умел xfs (флешка с живой системой, лежащая под рукой "внезапно" оказывалась старой), поэтому приходилось увозить с объекта диск в офис и разбираться там, а потом везти обратно… А проблем с ext4 лично у меня не было ни разу. Но спасибо за комментарии, учту, что такая статистика тоже есть.
P.S. С ext2 в лохматые годы такое было, да. И с ext3 тоже, но её тогда только выпустили и официально еще не рекомендовали в продакшн.
Родные пакеты ставить приятнее. Со сторонними репозиториями всегда возможны конфликты, чего не хочется допускать на боевом сервере. Конкретно установка php7 из репозиторий remi у меня вызвала проблемы с обновлением Zabbix, которые я потом решил путём доустановки какого-то метапакета, но эти танцы с бубном не для продакшена на мой взгляд.
При текстовом режиме установке с кикстарта по сети при 1 ГБ памяти у меня система падала при установке, ссылаясь на то, что не может что-то распаковать.
/тут должен быть смайлик, разводящий руками/
Во-первых, наоборот без размонтирования. Во-вторых, я не сказал, что нельзя, в моем примере это просто не требуется.
В-третьих, если вначале увеличить виртуальный диск, а потом захотеть увеличить раздел на нём, это рекомендуют делать путём удаления раздела и создания нового бОльшего размера поверх, указывая при создании те же данные, которые использовались ранее. Мне такое на работающем сервере с примонтированным разделом, с которым идёт работа делать страшно. Возможно это и удастся, поскольку таблица разделов в памяти обновляется после partprobe… Но блин, я на своих серверах так экспериментировать не хочу.
Если же увеличивать группу, расположенную на утройстве без раздела, то эта операция вообще не требуется. Что гораздо приятнее.
Ничего «продвинутого» в этой виртуалке нет. Это стандартная конфигурация. Конкретно эта для разработки, запускать на машине с постоянно меняющейся конфигурацией — увольте.
Про swap могу сказать, что лично у меня раздел всегда создан и стоит система мониторинга. Если в какой-то момент раздел начинает заполняться, я получаю сообщение на телефон и иду разбираться что сломалось, очень удобно. Для того и используется. Параметр swapiness в данном случае принципиального значения не играет.
Смотря как ездить. Если штурмовать танковые полигоны (как я на своей Ниве), ездить каждый день по разбитым в хлам, ямы и ухабы грунтовкам под 80 (как я с дачи на работу и обратно) и тюнинговать под «хочу добавить эту, эту и вооооон эту опцию к той комплектации, в которой купил», то выходит тысяч 100 в год. :) С учетом ремонта кузова, который при таком раскладе живёт не очень долго.
P.S. Правда даже при таком раскладе это ремонт в основном плановый в духе «ой, я пробил в машине дырку сваей, весной заварю». Я вот на эвакуатере за 3 года не ездил ни разу.
Только вот аффтар пошел по тому же пути, по которому все разработчики до него. Вот я не понимаю, почему меня должны ограничивать по максимальной длине пароля? И зачем ограничивать подряд идущие последовательности? И адрес пользователя? Вот хочется мне в качестве пароля каждый раз набрать весь русский, а потом и весь английский алфавит подряд кроме обеих «а», а потом еще и емейл. Да, символы идут подряд, зато эти 56 символов не подбираются ни перебором, ни словарём просто потому, что никому в голову не придёт что я реально их столько указываю. Ничего надежнее вы все равно не придумаете. А запоминать — легче легкого. И кстати в наш век утилит для хранения паролей 95% времени этот пароль может автоматически вводиться откуда-нибудь с е-токена.
Резюме: нужно считать сложность и взломостойкость пароля на этапе регистрации в баллах. За определенную узнаваемую последовательность добавлять определенное же количество баллов. Одна буква или цифра — тоже определенное количество баллов. И разрешать к регистрации пароли, набравшие нужное количество баллов. Алгоритм конечно же будет сложнее, зато эффекта больше.
Только вот совет не работает. Вообще, когда я собирал загрузочную флэшку в прошлый раз, удалось сделать ее только с 5 CentOS'ом. С 6 не вышло. По этим советам тоже не выходит. То есть флэшка-то получается, но вот в середине загрузки появляется kernel panic. В тот раз выкрутился тем, что заменил ISOшник на 5.8 NetInstall, а в процессе установки указал путь к репозиторию 6-ки. Поставилось. Есть мнение, что дело в EFI, но я пока в этом не уверен. Так или иначе, но 6-ка с флэшки у мну не ставится даже NetInstall'ом. Что печально, потому что в 5-ке ядро не поддерживает сетевухи Atheros, популярные во всяких тонких и не очень клиентах.
Пара мелких косяков:
Надо в /etc/dovecot/conf.d/10-auth.conf раскомментировать строку: !include auth-sql.conf.ext
И в /etc/dovecot/dovecot-sql.conf.ext стоит разрыв строки перед буквой «E», в слове «WHERE» должно быть вот так:
driver = mysql
connect = host=localhost dbname=postfix user=postfix password=mypassword
default_pass_scheme = MD5-CRYPT
user_query = SELECT '/var/vmail/%d/%n' as home, 'maildir:/var/vmail/%d/%n'as mail, 1000 AS uid, 1000 AS gid, concat('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
password_query = SELECT username as user, password, '/var/vmail/%d/%n' as userdb_home, 'maildir:/var/vmail/%d/%n' as userdb_mail, 1000 as userdb_uid, 1000 as userdb_gid, concat('*:bytes=', quota) AS userdb_quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
Так конфигураций разных бывает много. Та, которую описываете Вы мне вот ни разу не пригождалась. Между двумя аппаратными портами может быть разница в том, что к одному порту влан должен быть подцеплен с тэгом, а к другому -- без, опять же, обычно речь идёт не про работу с одним портом, а про работу с разными... Короче, я описываю то, как можно начать понимать логику работы вланов, а не реализацию отдельно взятого случая.
Это всё отлично применимо ко всему, где есть Router OS, даже к тем свичам, которые перешиваются из Switch OS в Router OS, вне зависимости от аппаратной платформы.
Во всех остальных случаях анализ пост-фактум показывал, что никакой полезной функции fail2ban не несёт. Ибо атака захлебывается еще на этапе подбора логина (root-то не имеет права доступа по ssh вообще), до подбора пароля ни разу не доходило.
Поэтому хотя я его по привычке обычно и ставлю, могу сказать, что на мой взгляд он не нужен 99% пользователей.
Вы путаете изменение размера раздела и изменение размера файловой системы. Если на разделе есть LVM, то файловой системы там просто нет. Никакой. Только сам lvm.
А так, можно скажем виртуальный увеличить диск, который на машине имеет обозначение xvdc, после этого можно увеличить например раздел xvdc1, после этого можно увеличить файловую систему на разделе.
Геометрия устройства, раздела и файловой системы это 3 разные вещи.
И я пишу про то, что при работе с LVM удобнее избегать последних двух сущностей. Потому что несмотря на то, что изменять область диска, занятую файловой системой, удобно, не удобно перед этим расширять размер раздела.
А конкретно про сравнение lvm и xfs могу сказать, что на одном устройстве может быть скажем 10 разделов. И если понадобилось расширить скажем третий по счёту, то делать это с помощью расширения файловой системы не выйдет просто потому, что после конца раздела с этой файловой системой находится следующая область с данными и расширять раздел некуда. А с помощью lvm — легко и непринужденно, так что lvm всё-таки мощнее. Не зря же у гипервизоров внутри именно lvm.
Если есть отдельная СХД, то можно положить и туда. Но во-первых не у всех она есть: скажем, все облачные сервисы предоставляют устройство целиком, т.е. сервер с дисками без отдельной хранилки. А во-вторых, даже если СХД есть, во многих случаях это оптика и FC либо iSCSI, прикрепленный как раздел к гипервизору, куски которого уже потом раздаются виртуальным машинам как обычные диски.
Но даже если это будет именно nfs-шара, она будет не на том же разделе, где система. Да, она будет не в LVM'е на сервере, но я говорил что данные обязательно отделять. Если кому-то удобнее делать это по NFS, то пускай так, лишь бы рядом не лежали. :)
Вообще-то веб-сервер должен работать под отдельным непривелегированным пользователем, у которого даже shell в свойствах пользователя не прописан. И естественно доступ к файловой системе у него очень ограничен даже на чтение.
Конфиг апача (в котором указано всё, что апач реально может) взломщик сможет увидеть как при выключенном SELinux, так и при включенном.
Дернуть интерпретатор php — тоже. Получить доступ к телу сайта — опять же. Найти там логин-пароль от базы данных и получить к ней доступ через php — снова.
В итоге, что с SeLinux, что без него, злоумышленник скомпрометировав веб-сервер сможет поломать кусок базы данных (не всю, потому что сайт ходит к базе не под рутом естественно и права сильно урезаны) и всё.
Да, еще он сможет увидеть список сервисов, запущенных на сервере так, как будто фаерволла нет. Что при правильной настройке безопасности внутри самих сервисов (т.е. без использования безопасности через запутывание) ничем ему не поможет.
Удивительно. У меня вот более 60 линуксовых серверов в парке, потери данных на XFS были раза 2, раза 2 было, что при разбивке в XFS система просто отказывается ставиться через кикстарт (CentOS7)… Вручную-то переразбивал в ext4 и всё ставилось, а кикстарт просто обламывался. Пару раз было, что попадал на необходимость восстановления системы с первого попавшегося LiveCD, а он просто не умел xfs (флешка с живой системой, лежащая под рукой "внезапно" оказывалась старой), поэтому приходилось увозить с объекта диск в офис и разбираться там, а потом везти обратно… А проблем с ext4 лично у меня не было ни разу. Но спасибо за комментарии, учту, что такая статистика тоже есть.
P.S. С ext2 в лохматые годы такое было, да. И с ext3 тоже, но её тогда только выпустили и официально еще не рекомендовали в продакшн.
/тут должен быть смайлик, разводящий руками/
В-третьих, если вначале увеличить виртуальный диск, а потом захотеть увеличить раздел на нём, это рекомендуют делать путём удаления раздела и создания нового бОльшего размера поверх, указывая при создании те же данные, которые использовались ранее. Мне такое на работающем сервере с примонтированным разделом, с которым идёт работа делать страшно. Возможно это и удастся, поскольку таблица разделов в памяти обновляется после partprobe… Но блин, я на своих серверах так экспериментировать не хочу.
Если же увеличивать группу, расположенную на утройстве без раздела, то эта операция вообще не требуется. Что гораздо приятнее.
Ничего «продвинутого» в этой виртуалке нет. Это стандартная конфигурация. Конкретно эта для разработки, запускать на машине с постоянно меняющейся конфигурацией — увольте.
Про swap могу сказать, что лично у меня раздел всегда создан и стоит система мониторинга. Если в какой-то момент раздел начинает заполняться, я получаю сообщение на телефон и иду разбираться что сломалось, очень удобно. Для того и используется. Параметр swapiness в данном случае принципиального значения не играет.
P.S. Правда даже при таком раскладе это ремонт в основном плановый в духе «ой, я пробил в машине дырку сваей, весной заварю». Я вот на эвакуатере за 3 года не ездил ни разу.
Резюме: нужно считать сложность и взломостойкость пароля на этапе регистрации в баллах. За определенную узнаваемую последовательность добавлять определенное же количество баллов. Одна буква или цифра — тоже определенное количество баллов. И разрешать к регистрации пароли, набравшие нужное количество баллов. Алгоритм конечно же будет сложнее, зато эффекта больше.
Надо в
/etc/dovecot/conf.d/10-auth.confраскомментировать строку:!include auth-sql.conf.extИ в
/etc/dovecot/dovecot-sql.conf.extстоит разрыв строки перед буквой «E», в слове «WHERE» должно быть вот так: