Тонкие настройки LXC. Память
Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.
Еще одной, часто используемой тонкой настройкой LXC являются лимиты использования памяти. Но перед тем, как переходить непосредственно к настройкам разберем некоторые особенности использования памяти контейнерами.
В отличие от виртуальных машин, которые имеют выделенные ресурсы, контейнеры работают с общей памятью хоста и их аппетиты регулируются лимитами. Для системы контейнер ничем не отличается от любого другого приложения и точно также конкурирует за память на общих основаниях.
Т.е. если мы «выделили» контейнеру 16 ГБ памяти, но просит он только 4 ГБ, то он получит только запрашиваемое, а остальные 12 ГБ будут доступны другим процессам. Это позволяет гибко настраивать выделение памяти, когда суммарно лимиты могут превышать доступный объем.
Это нормально, допустим мы знаем, что наше рабочее приложение в среднем потребляет 2 ГБ памяти, но при пиковых нагрузках может попросить 3 - 3,5 ГБ, поэтому смело ставим лимит на 4 ГБ и, если в системе есть свободная память – контейнер ее получит.
А вот тут начинается самое интересное – лимиты. Их четыре. Они отвечают за верхние и нижние значения. Начнем с верхних. В конфигурационных файлах Proxmox
/etc/pve/lxc/nnn.conf (где nnn – ID контейнера) указывается просто выделенный объем памяти, а вот если мы заглянем в настоящий конфиг LXC в /var/lib/lxc/nnn/config, то увидим там две директивы (для контейнера с 4 ГБ памяти):lxc.cgroup2.memory.max = 4294967296
lxc.cgroup2.memory.high = 4261412864
▫️ lxc.cgroup2.memory.max – это жесткое верхнее ограничение по памяти в байтах, ничего сверх указанного значения контейнер не получит.
▫️ lxc.cgroup2.memory.high – мягкий верхний лимит, Proxmox устанавливает его на уровне 99% жесткого лимита. При его достижении система начинает агрессивно вытеснять память, сбрасывать кеш и, если ничего не поможет, задействует OOM Killer.
Данный зазор – в 1% - это есть защитный промежуток, чтобы контейнер вдруг внезапно не уперся в жесткий лимит, что будет означать, что память для него закончилась. Но стандартные Linux механизмы ему не помогут, так как он считает доступной всю память хоста.
Таким образом memory.high как раз включает защитные механизмы и начинает активно освобождать память.
Чем нам может помочь этот лимит? Для второстепенных контейнеров мы можем его понизить. Для нашего примера, когда для пиковой нагрузки в 3,5 ГБ мы поставили жесткий лимит 4 ГБ, то мягкий можем сделать как раз 3,5 ГБ.
Если контейнер превысит это значение, то он начнет сначала свопить, потом сбрасывать кеш. Т.е. просядет в производительности, но конкурировать за память с более важными соседями не будет.
Теперь перейдем к нижним лимитам, это:
lxc.cgroup2.memory.low
lxc.cgroup2.memory.min
▫️ lxc.cgroup2.memory.min – это нижний жесткий лимит гарантированной памяти контейнера. Фактически мы забираем объем, указанный в этой директиве из общего пула, и закрепляем за контейнером, даже если он ее всю не утилизирует.
Скажем вы выделили 1 ГБ, а контейнер использует всего 256 МБ, но оставшийся резерв не будет доступен никакому другому процессу, так как закреплен за определенным контейнером. Поэтому использовать эту опцию надо осторожно, так как можно серьезно повлиять на стабильность и производительность всей системы.
▫️ lxc.cgroup2.memory.low – это мягкий нижний предел, который система выделяет контейнеру в приоритетном порядке, но, при необходимости, эта память может быть использована или вытеснена другими процессами.
В данном случае система не жестко фиксирует, а защищает выделенный объем памяти от вытеснения.
Если у нас есть несколько контейнеров с различными значениями memory.low и свободной памяти недостаточно на удовлетворение всех лимитов, то она будет распределена пропорционально значениям memory.low.
Основное отличие от memory.min здесь в том, что если памяти не хватает, то ее не хватает всем, но некоторым ее не хватает чуть меньше, чем остальным. Это позволяет поддерживать систему стабильной, пусть и ценой некоторой потери производительности.
👍40👀1
Сколько месяцев ты ещё будешь сидеть без работы, пока другие получают офферы в IT?
Дарим полный роадмап по вкатыванию в DevOps:
✅ Программа для обучения
✅ Бесплатные ресурсы с теорией
✅ Лайфхаки от Senior DevOps
Бонус внутри: скидка 5000₽ на менторскую программу в GigaDevOps!
Скачать файл → [Тык сюда]
Кстати, заглядывай в канал GigaDevOps, там тоже много полезной бесплатной инфы.
Дарим полный роадмап по вкатыванию в DevOps:
✅ Программа для обучения
✅ Бесплатные ресурсы с теорией
✅ Лайфхаки от Senior DevOps
Бонус внутри: скидка 5000₽ на менторскую программу в GigaDevOps!
Скачать файл → [Тык сюда]
Кстати, заглядывай в канал GigaDevOps, там тоже много полезной бесплатной инфы.
Как узнать все смонтированные файловые системы?
Раньше можно было сказать: загляните в
Можно использовать команду
Но есть способ лучше -
А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
Раньше можно было сказать: загляните в
/etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС.Можно использовать команду
mount, но ее вывод недостаточно удобочитаем.Но есть способ лучше -
findmnt, данная команда выведет все смонтированные файловые системы в удобном древообразном виде.А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом
--real. Чтобы получить больше информации воспользуйтесь ключом --help.
👍68
Секта свидетелей чего-то там
Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.
Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.
Давайте рассмотрим подробнее.
🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.
Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .
Вместе с этим обычно употребляются принижающие уровень оппонентов выражения и эпитеты: виндузятники, красноглазики, не осилили, отстали от прогресса, неумехи и т.д. и т.п.
🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.
Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.
Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.
Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.
🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.
Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.
🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.
После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?
Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.
Вам сразу пояснят, что вы не догнали, не поняли и вообще, разговаривать об этом можно только на равных, а вам они лекции читать не собираются. Не доросли и, вообще, время – деньги.
Ну и также вам никто не пояснит простым и понятным языком какие именно преимущества вы получите от внедрения данного продукта.
🔆 Атмосфера тайны – это плавно вытекает из элитарности. Адепты любят рассказывать, насколько идеален их продукт, как он сильно помог многим известным компаниям и т.д. и т.п. А когда просишь подробностей, то тут же ссылаются на невозможность выдать такую информацию по многим причинам.
В результате появляется некая параллельная вселенная, где тайные города и тайные корпорации успешно используют объект проповедования и никому об этом не рассказывают. Ну чтобы не повторили успешный успех, наверное. Тогда зачем вообще об этом говорить?
Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.
👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…
Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.
Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.
Давайте рассмотрим подробнее.
🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.
Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .
Вместе с этим обычно употребляются принижающие уровень оппонентов выражения и эпитеты: виндузятники, красноглазики, не осилили, отстали от прогресса, неумехи и т.д. и т.п.
🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.
Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.
Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.
Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.
🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.
Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.
🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.
После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?
Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.
Вам сразу пояснят, что вы не догнали, не поняли и вообще, разговаривать об этом можно только на равных, а вам они лекции читать не собираются. Не доросли и, вообще, время – деньги.
Ну и также вам никто не пояснит простым и понятным языком какие именно преимущества вы получите от внедрения данного продукта.
🔆 Атмосфера тайны – это плавно вытекает из элитарности. Адепты любят рассказывать, насколько идеален их продукт, как он сильно помог многим известным компаниям и т.д. и т.п. А когда просишь подробностей, то тут же ссылаются на невозможность выдать такую информацию по многим причинам.
В результате появляется некая параллельная вселенная, где тайные города и тайные корпорации успешно используют объект проповедования и никому об этом не рассказывают. Ну чтобы не повторили успешный успех, наверное. Тогда зачем вообще об этом говорить?
Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.
👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…
💯49👍22🤣14🤡9⚡3
Девушки в IT
Вас немного – но вы есть и с каждым годом вас становиться больше. Поэтому в этот день позвольте поздравить вас и пожелать всего самого светлого.
В первую очередь любви, любите и будьте любимыми и не забывайте радовать нас цветами любви – детьми. Это высший дар и награда для нас, суровых админов и прочих специалистов который кроме вас никто не сможет преподнести.
Затем – здоровья (его не купишь), цветите и будьте всегда бодрыми и радостными, вдохновляя нас на свершения для вас.
Ну и мирного нам всем неба над головой, этого тоже не купить, но это тоже очень важно. Жители приграничья меня поймут.
В общем милые дамы, с вами трудно, без вас совсем никуда. С праздником Вас, будьте любимы и счастливы. А мы для этого постараемся.
Вас немного – но вы есть и с каждым годом вас становиться больше. Поэтому в этот день позвольте поздравить вас и пожелать всего самого светлого.
В первую очередь любви, любите и будьте любимыми и не забывайте радовать нас цветами любви – детьми. Это высший дар и награда для нас, суровых админов и прочих специалистов который кроме вас никто не сможет преподнести.
Затем – здоровья (его не купишь), цветите и будьте всегда бодрыми и радостными, вдохновляя нас на свершения для вас.
Ну и мирного нам всем неба над головой, этого тоже не купить, но это тоже очень важно. Жители приграничья меня поймут.
В общем милые дамы, с вами трудно, без вас совсем никуда. С праздником Вас, будьте любимы и счастливы. А мы для этого постараемся.
👍25👏3⚡2🫡1
Больше никаких долгих внедрений и дорогих разработок. 12 марта в 11:00 мы покажем, как платформа Low-code/No-code помогает компаниям ускорить цифровую трансформацию.
🔥 Вы узнаете:
✅ Как мы прошли путь от идеи до запуска на примере кейса «Элемент Лизинг».
✅ Как выбрать LCNC-платформу, которая идеально подойдет вашему бизнесу.
✅ Какие практические шаги мешают цифровой трансформации — и как их устранить.
✅ Как инструменты ELMA365 позволяют запускать процессы в 5 раз быстрее.
📅 Дата и время: 12 марта, 11:00 (МСК)
💰 Стоимость участия: Бесплатно
📢 Этот вебинар для вас, если вы:
✔️ Хотите масштабировать бизнес без лишних затрат.
✔️ Директор по стратегии или ИТ, который ищет эффективные решения.
✔️ Просто устали от долгих и дорогих разработок.
Не откладывайте цифровую трансформацию!
👉 Регистрируйтесь
🔥 Вы узнаете:
✅ Как мы прошли путь от идеи до запуска на примере кейса «Элемент Лизинг».
✅ Как выбрать LCNC-платформу, которая идеально подойдет вашему бизнесу.
✅ Какие практические шаги мешают цифровой трансформации — и как их устранить.
✅ Как инструменты ELMA365 позволяют запускать процессы в 5 раз быстрее.
📅 Дата и время: 12 марта, 11:00 (МСК)
💰 Стоимость участия: Бесплатно
📢 Этот вебинар для вас, если вы:
✔️ Хотите масштабировать бизнес без лишних затрат.
✔️ Директор по стратегии или ИТ, который ищет эффективные решения.
✔️ Просто устали от долгих и дорогих разработок.
Не откладывайте цифровую трансформацию!
👉 Регистрируйтесь
Мы думали, что РОСА уже все и новостей не было от них очень давно. А оказывается еще не все, в конце февраля без лишнего шума и пыли выкатили новый релиз.
Свежий Фреш на новой платформе:
🔹 Теперь по-русски, не ROSA FRESH а РОСА Фреш.
🔹Упрощенная нумерация, мажорный номер версии фреша совпадает с номером платформы.
🔹Новейшие версии библиотек и пользовательских программ.
ядро 6.12 LTS для поддержки новой аппаратуры.
🔹glibc 2.20 для совместимости с переносимыми приложениями.
🔹systemd 256 — современная система управления службами.
🔹Обновленный дизайн в традиционной цветовой гамме.
🔹Базовая поддержка китайского и арабского языков.
Свежий Фреш на новой платформе:
🔹 Теперь по-русски, не ROSA FRESH а РОСА Фреш.
🔹Упрощенная нумерация, мажорный номер версии фреша совпадает с номером платформы.
🔹Новейшие версии библиотек и пользовательских программ.
ядро 6.12 LTS для поддержки новой аппаратуры.
🔹glibc 2.20 для совместимости с переносимыми приложениями.
🔹systemd 256 — современная система управления службами.
🔹Обновленный дизайн в традиционной цветовой гамме.
🔹Базовая поддержка китайского и арабского языков.
👍37🤣9🤔2❤1👎1
Новая РОСА Фреш при ближайшем рассмотрении вызывает только недоумение. Постоянно терзает мысль – а для кого это и зачем?
Изначально Роса получила отличный задел в виде наследства Mandriva, со всеми вытекающими. Но практически все это было бесполезно растрачено. Если Mandrake, а затем и Mandriva были дистрибутивами самобытными, то РОСА практически потеряла какую-либо уникальность, став просто еще одним дистрибутивом.
Родных для экосистемы утилит и программ drake для управления системой почти не осталось, а те, что остались давно устарели. Свой пакетный менеджер заменен на DNF. Чего-то своего тоже не появилось.
Сам Фреш позиционируется как домашний дистрибутив, об этом говорит как схема разбивки диска, так и набор поставляемого софта. Но вменяемые инструменты управления софтом в графическом режиме отсутствуют, магазин так и не завезли. Интеграции со Snap и Flatpak нет.
Кому это нужно домой? Зачем? В офис, посмотреть? Но тоже зачем? Документация куцая, распространенность слабая.
Изначально Роса получила отличный задел в виде наследства Mandriva, со всеми вытекающими. Но практически все это было бесполезно растрачено. Если Mandrake, а затем и Mandriva были дистрибутивами самобытными, то РОСА практически потеряла какую-либо уникальность, став просто еще одним дистрибутивом.
Родных для экосистемы утилит и программ drake для управления системой почти не осталось, а те, что остались давно устарели. Свой пакетный менеджер заменен на DNF. Чего-то своего тоже не появилось.
Сам Фреш позиционируется как домашний дистрибутив, об этом говорит как схема разбивки диска, так и набор поставляемого софта. Но вменяемые инструменты управления софтом в графическом режиме отсутствуют, магазин так и не завезли. Интеграции со Snap и Flatpak нет.
Кому это нужно домой? Зачем? В офис, посмотреть? Но тоже зачем? Документация куцая, распространенность слабая.
👀11🤔10🔥4🤣3🥱1
Устали от ограничений и долгой настройки серверов? High-speed VDS поможет в работе!
Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.
А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:
✅ Управление репозиториями кода для Git
✅ Система отслеживания задач
✅ Удобная Wiki для документации
✅ Мощный CI/CD пайплайн
✅ И многое другое для продуктивной работы всей команды!
🎁 Подготовили приятный бонус для тебя: +10% к пополнению баланса
Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.
А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:
✅ Управление репозиториями кода для Git
✅ Система отслеживания задач
✅ Удобная Wiki для документации
✅ Мощный CI/CD пайплайн
✅ И многое другое для продуктивной работы всей команды!
🎁 Подготовили приятный бонус для тебя: +10% к пополнению баланса
👍3❤1👀1
Блеск и нищета FreeBSD
Разработчики FreeBSD опубликовали отчёт о развитии за четвёртый квартал 2024 года, в котором упомянут проект bsd-user-4-linux, развивающий инструментарий для запуска в Linux приложений, собранных для FreeBSD.
Целью проекта заявлена возможность собирать пакеты для FreeBSD в Linux, используя родной сборочный инструментарий FreeBSD.
Для запуска исполняемых файлов FreeBSD задействован форк эмулятора QEMU. В данном режиме QEMU выполняет трансляцию системных вызовов и обработку сигналов.
Для запуска приложений требуется развёртывание в локальном каталоге библиотек и настроек из базовой системы FreeBSD. Проект можно рассматривать как обратный аналог Linuxulator.
На текущем этапе разработки работает запуск основных системных утилит (sh, bash, find, grep, git, clang и т.п.), поддерживается динамическое связывание и разделяемые библиотеки, доступны сетевые функции.
Например, уже можно пересобрать FreeBSD находясь в Linux. Из отсутствующей функциональности отмечается невозможность запуска отладчика GDB, недоступность IPC, и ряда системных вызовов.
А теперь переведем это на обычный язык – дела у FreeBSD идут настолько неважно, что сами разработчики BSD не пользуются своей системой и вместо того, чтобы хоть как-то развивать ее тратят и без того скудное финансирование на разработку подобных костылей.
При этом жизнь, похоже, ничему не учит «строителей величественного собора», которые в начале десятых уступили Linux серверный рынок, причем уступили по вполне объективным причинам, проспав технологический прогресс.
Далее бездарно проспали наследство Sun в виде ZFS, которая могла бы стать киллер-фичей и снова сделать систему конкурентной. Но увы, в настоящий момент развитием этой файловой системы занимается OpenZFS, которая разрабатывает ее в первую очередь в интересах Linux.
В целом перспективы у FreeBSD более чем туманные, что еще держит проект на плаву и привлекает финансирование – так это то, что этот код можно просто взять и закрыть, ничего не возвращая назад.
Этим активно пользуются многие, от Apple до Juniper и слышать от адептов FreeBSD отсылки к этим системам смешно. Так как никто не знает, что именно там взяли от BSD и как изменили. Плюс самому сообществу и системе от этого ни холодно, ни жарко. Взамен они не получили ничего.
Разработчики FreeBSD опубликовали отчёт о развитии за четвёртый квартал 2024 года, в котором упомянут проект bsd-user-4-linux, развивающий инструментарий для запуска в Linux приложений, собранных для FreeBSD.
Целью проекта заявлена возможность собирать пакеты для FreeBSD в Linux, используя родной сборочный инструментарий FreeBSD.
Для запуска исполняемых файлов FreeBSD задействован форк эмулятора QEMU. В данном режиме QEMU выполняет трансляцию системных вызовов и обработку сигналов.
Для запуска приложений требуется развёртывание в локальном каталоге библиотек и настроек из базовой системы FreeBSD. Проект можно рассматривать как обратный аналог Linuxulator.
На текущем этапе разработки работает запуск основных системных утилит (sh, bash, find, grep, git, clang и т.п.), поддерживается динамическое связывание и разделяемые библиотеки, доступны сетевые функции.
Например, уже можно пересобрать FreeBSD находясь в Linux. Из отсутствующей функциональности отмечается невозможность запуска отладчика GDB, недоступность IPC, и ряда системных вызовов.
А теперь переведем это на обычный язык – дела у FreeBSD идут настолько неважно, что сами разработчики BSD не пользуются своей системой и вместо того, чтобы хоть как-то развивать ее тратят и без того скудное финансирование на разработку подобных костылей.
При этом жизнь, похоже, ничему не учит «строителей величественного собора», которые в начале десятых уступили Linux серверный рынок, причем уступили по вполне объективным причинам, проспав технологический прогресс.
Далее бездарно проспали наследство Sun в виде ZFS, которая могла бы стать киллер-фичей и снова сделать систему конкурентной. Но увы, в настоящий момент развитием этой файловой системы занимается OpenZFS, которая разрабатывает ее в первую очередь в интересах Linux.
В целом перспективы у FreeBSD более чем туманные, что еще держит проект на плаву и привлекает финансирование – так это то, что этот код можно просто взять и закрыть, ничего не возвращая назад.
Этим активно пользуются многие, от Apple до Juniper и слышать от адептов FreeBSD отсылки к этим системам смешно. Так как никто не знает, что именно там взяли от BSD и как изменили. Плюс самому сообществу и системе от этого ни холодно, ни жарко. Взамен они не получили ничего.
😢19👍10🫡9🤔2👀2
Культура работы с сертификатами
А точнее ее полное отсутствие. Причем наблюдать это можно сплошь и рядом. Про наплевательское отношение с доступом к ним промолчим, это тема отдельной беседы, сегодня именно про культуру работы.
Пригласили нас тут третьего дня помочь настроить работу Честного знака и маркировки. Да не вопрос, точнее самый первый вопрос – это сертификаты, а там такое… В общем бардак полный, который вы можете увидеть на рисунке ниже.
И во всем этом безобразии только три живых сертификата, остальные просроченные, причем сильно просроченные. И ладно бы там не было собственного админа, так он там есть.
На наш вопрос – а что это за бардак он только вяло махнул рукой, мол ну его нафиг, сейчас тронь, а потом там что-то поломается, утомишься чинить. Причем чему там ломаться он так и не пояснил.
Это все говорит о крайне низкой культуре работы с сертификатами и понимания как это все устроено, что местами приводит практически к мистической боязни всего что с ними связано.
Поэтому давайте разберемся, что это за зверь такой «сертификат», мы не просто взяли это слово в кавычки. Но оно стало общеупотребимым, а из песни слов не выкинешь. Но любой технический специалист должен понимать, что, говоря «сертификат» мы понимаем ключевую пару.
Ключевая пара состоит из секретного закрытого ключа и общедоступного открытого, который дополненный дополнительной информацией о владельце, выпустившей стороне, назначениях использования и т.д. и т.п. и представляет тот самый сертификат.
Подробнее о том, как это все работает и почему открытый ключ можно передавать, а закрытый нужно хранить в секрете можно прочитать в нашей статье:
🔹 Введение в криптографию. Общие вопросы, проблемы и решения
Что нужно знать в нашем случае? Что единственно допустимым хранилищем ключевой пары является токен, ну это если официально. Если проявить некоторую смекалку, то при должном знании и умении из токенов Рутокен (кроме Рутокен ЭЦП 2.0/3.0) ключевая пара извлекается и может быть записан на флешку или в реестр.
Физически ключевая пара – это два файла бинарного или текстового формата, в последнем случае используется Base64 кодирование бинарного файла.
Для того, чтобы мы могли работать с этой ключевой парой нам нужно установить сертификат в системное хранилище сертификатов. При этом вместе с сертификатом будет прописано расположение закрытого ключа.
Если вы после этого смените его хранилище, скажем с токена на флешку, то сертификат надо будет переустановить.
Хранилища ключевой пары зовутся контейнерами и в том же Крипто-Про доступны в отдельном разделе. А раздел Сертификаты отражает установленные в системное хранилище сертификаты, т.е. те, которые непосредственно доступны для работы.
Удаляя сертификат из системы, мы только делаем его недоступным для прикладного ПО, физически он как был в своем контейнере, так и остается, при необходимости мы всегда можем установить его снова.
Что касается удаления контейнера, то для этого нужно постараться отдельно: отформатировать токен, удалить файлы с флешки или раздел реестра. Но это надо сделать отдельно и осознанно. Штатные инструменты работы с сертификатами или Крипто-Про (равно как и другие криптопровайдеры) таким не занимаются.
После того, как срок действия сертификата закончился – он превратился в тыкву, в прямом смысле этого слова. Также в тыкву он может превратиться и ранее этого срока, если вы перевыпустили сертификат, не дожидаясь его окончания.
Держать их установленными нет никакого смысла, это не дает никаких плюсов, а только запутывает и делает работу крайне неудобной, в любом личном кабинете, куда вы входите по сертификату вместо трех вариантов входа, будет в нашем случае 13.
Аналогичная картина будет и при подписании, где вместо одного сертификата на организацию будет всплывать целая стопка.
Поэтому просроченный сертификат из системы нужно сразу удалять. Никаких негативных последствий это не несет и нести не может.
Зато сразу повысится удобство работы и значительно улучшится диагностика возможных проблем работы с сертификатами.
А точнее ее полное отсутствие. Причем наблюдать это можно сплошь и рядом. Про наплевательское отношение с доступом к ним промолчим, это тема отдельной беседы, сегодня именно про культуру работы.
Пригласили нас тут третьего дня помочь настроить работу Честного знака и маркировки. Да не вопрос, точнее самый первый вопрос – это сертификаты, а там такое… В общем бардак полный, который вы можете увидеть на рисунке ниже.
И во всем этом безобразии только три живых сертификата, остальные просроченные, причем сильно просроченные. И ладно бы там не было собственного админа, так он там есть.
На наш вопрос – а что это за бардак он только вяло махнул рукой, мол ну его нафиг, сейчас тронь, а потом там что-то поломается, утомишься чинить. Причем чему там ломаться он так и не пояснил.
Это все говорит о крайне низкой культуре работы с сертификатами и понимания как это все устроено, что местами приводит практически к мистической боязни всего что с ними связано.
Поэтому давайте разберемся, что это за зверь такой «сертификат», мы не просто взяли это слово в кавычки. Но оно стало общеупотребимым, а из песни слов не выкинешь. Но любой технический специалист должен понимать, что, говоря «сертификат» мы понимаем ключевую пару.
Ключевая пара состоит из секретного закрытого ключа и общедоступного открытого, который дополненный дополнительной информацией о владельце, выпустившей стороне, назначениях использования и т.д. и т.п. и представляет тот самый сертификат.
Подробнее о том, как это все работает и почему открытый ключ можно передавать, а закрытый нужно хранить в секрете можно прочитать в нашей статье:
🔹 Введение в криптографию. Общие вопросы, проблемы и решения
Что нужно знать в нашем случае? Что единственно допустимым хранилищем ключевой пары является токен, ну это если официально. Если проявить некоторую смекалку, то при должном знании и умении из токенов Рутокен (кроме Рутокен ЭЦП 2.0/3.0) ключевая пара извлекается и может быть записан на флешку или в реестр.
Физически ключевая пара – это два файла бинарного или текстового формата, в последнем случае используется Base64 кодирование бинарного файла.
Для того, чтобы мы могли работать с этой ключевой парой нам нужно установить сертификат в системное хранилище сертификатов. При этом вместе с сертификатом будет прописано расположение закрытого ключа.
Если вы после этого смените его хранилище, скажем с токена на флешку, то сертификат надо будет переустановить.
Хранилища ключевой пары зовутся контейнерами и в том же Крипто-Про доступны в отдельном разделе. А раздел Сертификаты отражает установленные в системное хранилище сертификаты, т.е. те, которые непосредственно доступны для работы.
Удаляя сертификат из системы, мы только делаем его недоступным для прикладного ПО, физически он как был в своем контейнере, так и остается, при необходимости мы всегда можем установить его снова.
Что касается удаления контейнера, то для этого нужно постараться отдельно: отформатировать токен, удалить файлы с флешки или раздел реестра. Но это надо сделать отдельно и осознанно. Штатные инструменты работы с сертификатами или Крипто-Про (равно как и другие криптопровайдеры) таким не занимаются.
После того, как срок действия сертификата закончился – он превратился в тыкву, в прямом смысле этого слова. Также в тыкву он может превратиться и ранее этого срока, если вы перевыпустили сертификат, не дожидаясь его окончания.
Держать их установленными нет никакого смысла, это не дает никаких плюсов, а только запутывает и делает работу крайне неудобной, в любом личном кабинете, куда вы входите по сертификату вместо трех вариантов входа, будет в нашем случае 13.
Аналогичная картина будет и при подписании, где вместо одного сертификата на организацию будет всплывать целая стопка.
Поэтому просроченный сертификат из системы нужно сразу удалять. Никаких негативных последствий это не несет и нести не может.
Зато сразу повысится удобство работы и значительно улучшится диагностика возможных проблем работы с сертификатами.
👍52❤3🤔3🤡2👎1
👍7🤣3
Режимы запуска bash
Для того, чтобы правильно ответить на вопрос «что не так сделал Вася» следует понимать контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
Кроме того,
Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной BASH_ENV среды окружения (если задан).
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
Для того, чтобы правильно ответить на вопрос «что не так сделал Вася» следует понимать контекст выполнения команд bash в каждом конкретном случае.
1️⃣ Начнем с режима входа в систему, в этом случае bash является оболочкой входа и при завершении процесса сеанс прекратится. Такой режим используется при интерактивном входе в систему или при подключении через SSH.
При запуске в качестве оболочки входа bash создает новую базовую среду и считывает файлы инициализации
/etc/profile и один из файлов: ~/.bash_profile, ~/.bash_login или ~/.profile который будет найден первым при поиске в указанном порядке.Кроме того,
/etc/profile считывает файлы /etc/profile.d/*.sh и /etc/bash.bashrc, а : ~/.bash_profile содержит указание на исполнение файла ~/.bashrc.Таким образом в режиме входа в систему bash создает базовую среду на основе как системных настроек, так и персональных для выполнившего вход пользователя.
2️⃣ Следующий режим – интерактивный, он запускается, когда стандартные потоки ввода-вывода подключены к эмулятору терминала. Например, если вы запустили терминал в графической среде. Или явно запустили bash внутри оболочки входа (а это может быть не обязательно bash).
В этом случае новая базовая среда не создается, а наследуется контекст окружения текущей оболочки, в дополнение к этому считываются персональные настройки из
~/.bash_profile и общие из /etc/bash.bashrc. Если сравнивать интерактивный режим и режим оболочки входа, то основной разницей является то, что интерактивный режим наследует текущее окружение и только лишь дополняет его персональными настройками.
3️⃣ Третий режим – неинтерактивный. Он используется при запуске
bash -с или bash имя_скрипта, а также при вызове команд и скриптов системными процессами, тем же cron.Этот режим существенно отличается как от режима оболочки входа, так и интерактивного. Основное его отличие в том, что при запуске создается новая минимальная базовая среда, но при этом не считываются никакие файлы инициализации, кроме файла указанного в переменной BASH_ENV среды окружения (если задан).
Таким образом большинство привычных настроек, включая пути исполнения, в неинтерактивном режиме окажутся недоступны. И если скрипт у вас прекрасно работал интерактивно, то в неинтерактивном режиме вас может поджидать неприятная неожиданность.
Как избежать данной проблемы? Не запускать скрипты интерактивно. Т.е. вместо
./my_script.sh используйте bash my_script.sh.В чем разница? В первом случае скрипт будет исполнен интерактивно, в режиме оболочки входа или интерактивной оболочки. Во втором bash будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.
👍54🤮2❤1
День рождения Arch Linux
Сегодня, 12 марта Arch Linux исполняется, кто бы мог подумать, 23 года. А ведь казалось это было только вчера.
За это время Arch успел плотно занять свою нишу, а также стать причиной появления многих бессмертных поговорок, вроде «не было печали – апдейтов накачали».
Но при этом Arch как был, так и остался дистрибутивом не для всех, а все потому, что установка у него происходит в «ручном» режиме и требует от пользователя определенной квалификации и понимания работы системы.
Но это не страшно, существует бесчисленное количество дистрибутивов на базе Arch, которые позволят приобщиться к этому миру с наименьшими сложностями.
Самый известный и дружелюбный – это Manjaro – своего рода Ubuntu в мире Arch, где новичка буквально проведут за руку, а чтобы вы случайно ничего не сломали апгрейдами у Manjaro есть свой репозиторий, в который пакеты попадают после дополнительной проверки.
Да, это уже не экстремально свежий софт, зато надежно, стабильно и предсказуемо (насколько это вообще применимо к миру Arch).
✅ Manjaro Linux - самый простой способ окунуться в мир Arch
Хотите что-то более суровое, дабы прочувствовать все особенности этого семейства? Возьмите EndeavourOS, тут вас водить за ручку никто не будет. А консоль станет основным вашим другом и товарищем.
✅ EndeavourOS - и снится нам не рокот космодрома
А может быть чего-то необычного? И этого хватает, тот же Garuda – яркий, стильный с буйством красок и возможностей, вплоть до игровых. Но в тоже время это Arch со всеми своими особенностями и хотя он менее суров чем EndeavourOS, но под капот заглядывать все равно придется.
✅ Garuda KDE Dr460nized - яркий и стильный и это тоже Arch
И это только несколько примеров, которые мы рассматривали и писали обзоры. А сколько еще осталось за кадром? Причем найти можно абсолютно что угодно, на любой вкус и цвет.
Поэтому если вам хочется смелых экспериментов и постоянно находиться на острие прогресса – то выбрать для этого что-нибудь из семейства Arch будет неплохой идеей.
Сегодня, 12 марта Arch Linux исполняется, кто бы мог подумать, 23 года. А ведь казалось это было только вчера.
За это время Arch успел плотно занять свою нишу, а также стать причиной появления многих бессмертных поговорок, вроде «не было печали – апдейтов накачали».
Но при этом Arch как был, так и остался дистрибутивом не для всех, а все потому, что установка у него происходит в «ручном» режиме и требует от пользователя определенной квалификации и понимания работы системы.
Но это не страшно, существует бесчисленное количество дистрибутивов на базе Arch, которые позволят приобщиться к этому миру с наименьшими сложностями.
Самый известный и дружелюбный – это Manjaro – своего рода Ubuntu в мире Arch, где новичка буквально проведут за руку, а чтобы вы случайно ничего не сломали апгрейдами у Manjaro есть свой репозиторий, в который пакеты попадают после дополнительной проверки.
Да, это уже не экстремально свежий софт, зато надежно, стабильно и предсказуемо (насколько это вообще применимо к миру Arch).
✅ Manjaro Linux - самый простой способ окунуться в мир Arch
Хотите что-то более суровое, дабы прочувствовать все особенности этого семейства? Возьмите EndeavourOS, тут вас водить за ручку никто не будет. А консоль станет основным вашим другом и товарищем.
✅ EndeavourOS - и снится нам не рокот космодрома
А может быть чего-то необычного? И этого хватает, тот же Garuda – яркий, стильный с буйством красок и возможностей, вплоть до игровых. Но в тоже время это Arch со всеми своими особенностями и хотя он менее суров чем EndeavourOS, но под капот заглядывать все равно придется.
✅ Garuda KDE Dr460nized - яркий и стильный и это тоже Arch
И это только несколько примеров, которые мы рассматривали и писали обзоры. А сколько еще осталось за кадром? Причем найти можно абсолютно что угодно, на любой вкус и цвет.
Поэтому если вам хочется смелых экспериментов и постоянно находиться на острие прогресса – то выбрать для этого что-нибудь из семейства Arch будет неплохой идеей.
Записки IT специалиста
Manjaro Linux - самый простой способ окунуться в мир Arch
О семействе дистрибутивов Arch следует поговорить особо, так как это полностью отдельная экосистема со своими особенностями и правилами. Arch Linux не претендует на скучное корпоративное применение, а, наоборот, стремиться быть на переднем крае прогресса…
👍18🥱1
Настраиваем политику паролей в Linux
Во многих дистрибутивах Linux (а более подробно мы будем говорить о Debian / Ubuntu) политика паролей по умолчанию не установлена, и никто не помешает нам установить слабый пароль, даже «123».
Это неправильно, поэтому мы сейчас займемся более гибкой настройкой политики паролей. Для этого сначала установим в систему необходимые пакеты:
После чего откроем файл /etc/security/pwquality.conf, который отвечает за политику паролей. Опции будут перечислены в порядке их перечисления в файле со значениями по умолчанию:
Количество символов, на которые новый пароль должен отличаться от старого.
Минимальная длина пароля
При составлении пароля учитываются классы символов, их четыре: прописные буквы, строчные буквы, цифры и специальные символы.
Мы можем поощрить использование определенных классов символов за счет более короткой длины пароля, для этого используется система кредитов. По умолчанию один любой символ – один кредит. Количество кредитов должно быть равно или превышать минимальную длину пароля.
Следующие опции позволяют начислять дополнительные кредиты за каждый класс символов:
Таким образом, если мы установим dcredit = 1, то пароль pass123 получит 10 кредитов, что будет эквивалентно его длине в 10 символов.
Если же мы установим количество кредитов меньше нуля, то это будет требованием минимального количества символов данного класса, например, ocredit = -2 – не менее двух специальных символов в пароле.
Для того, чтобы сочетать в пароле разные классы символов мы можем задать необходимое количество классов:
Так если мы установим его значение равным трем, то это будет значить, что в пароле требуется использовать не менее трех классов символов. Не забываем, что классов у нас всего четыре.
Для повышения сложности пароля можем задать максимально допустимое количество повторений одного символа:
Рядом есть другая опция, которая задает максимальное количество повторения символов одного класса:
Чтобы понять разницу между ними разберем простой пример, допустим, что оба параметра имеют значение, установленное в три.
В первом случае пароль АААА не пройдет, а пароль ABCD пройдет, так как символы разные. Во втором не пройдут оба, так как и там и там символы одного класса.
Учетная запись пользователя в Linux имеет специальное поле GECOS, которое может содержать его реальное имя, телефон, адрес почты и т.д. Мы можем проверить пароль на наличие в нем общедоступной информации:
При установке значения в единицу при нахождении в пароле данных GECOS он не будет пропущен.
Также мы можем осуществлять проверку по словарям cracklib (ставятся по зависимостям):
Следующая проверка исключает использование имени пользователя в пароле:
Но это грубая проверка, которая проверяет имя пользователя целиком, например, сочетание логина и пароля ivanov:ivan123 будет разрешено. Но мы можем ужесточить эту проверку, указав предельно допустимую длины подстроки имени пользователя:
Если установить его равным трем, то сочетание ivanov:ivan123 будет запрещено, равно как vano456, а iva123 будет пропущен.
Следующая опция устанавливает количество попыток ввода пароля:
Но есть одна тонкость, все эти правила не распространяются на пользователя root, чтобы изменить это поведение просто раскомментируйте опцию:
Как видим, настроить политику паролей в Linux не сложно, но это позволит значительно повысить безопасность системы и не допустить использования слабых или словарных паролей.
Во многих дистрибутивах Linux (а более подробно мы будем говорить о Debian / Ubuntu) политика паролей по умолчанию не установлена, и никто не помешает нам установить слабый пароль, даже «123».
Это неправильно, поэтому мы сейчас займемся более гибкой настройкой политики паролей. Для этого сначала установим в систему необходимые пакеты:
apt install libpam-pwquality
После чего откроем файл /etc/security/pwquality.conf, который отвечает за политику паролей. Опции будут перечислены в порядке их перечисления в файле со значениями по умолчанию:
Количество символов, на которые новый пароль должен отличаться от старого.
difok = 1
Минимальная длина пароля
minlen = 8
При составлении пароля учитываются классы символов, их четыре: прописные буквы, строчные буквы, цифры и специальные символы.
Мы можем поощрить использование определенных классов символов за счет более короткой длины пароля, для этого используется система кредитов. По умолчанию один любой символ – один кредит. Количество кредитов должно быть равно или превышать минимальную длину пароля.
Следующие опции позволяют начислять дополнительные кредиты за каждый класс символов:
dcredit = 0 – цифры
ucredit = 0 – прописные буквы
lcredit = 0 – строчные буквы
ocredit = 0 – специальные символы
Таким образом, если мы установим dcredit = 1, то пароль pass123 получит 10 кредитов, что будет эквивалентно его длине в 10 символов.
Если же мы установим количество кредитов меньше нуля, то это будет требованием минимального количества символов данного класса, например, ocredit = -2 – не менее двух специальных символов в пароле.
Для того, чтобы сочетать в пароле разные классы символов мы можем задать необходимое количество классов:
minclass = 0
Так если мы установим его значение равным трем, то это будет значить, что в пароле требуется использовать не менее трех классов символов. Не забываем, что классов у нас всего четыре.
Для повышения сложности пароля можем задать максимально допустимое количество повторений одного символа:
maxrepeat = 0
Рядом есть другая опция, которая задает максимальное количество повторения символов одного класса:
maxclassrepeat = 0
Чтобы понять разницу между ними разберем простой пример, допустим, что оба параметра имеют значение, установленное в три.
В первом случае пароль АААА не пройдет, а пароль ABCD пройдет, так как символы разные. Во втором не пройдут оба, так как и там и там символы одного класса.
Учетная запись пользователя в Linux имеет специальное поле GECOS, которое может содержать его реальное имя, телефон, адрес почты и т.д. Мы можем проверить пароль на наличие в нем общедоступной информации:
gecoscheck = 0
При установке значения в единицу при нахождении в пароле данных GECOS он не будет пропущен.
Также мы можем осуществлять проверку по словарям cracklib (ставятся по зависимостям):
dictcheck = 1
Следующая проверка исключает использование имени пользователя в пароле:
usercheck = 1
Но это грубая проверка, которая проверяет имя пользователя целиком, например, сочетание логина и пароля ivanov:ivan123 будет разрешено. Но мы можем ужесточить эту проверку, указав предельно допустимую длины подстроки имени пользователя:
usersubstr = 0
Если установить его равным трем, то сочетание ivanov:ivan123 будет запрещено, равно как vano456, а iva123 будет пропущен.
Следующая опция устанавливает количество попыток ввода пароля:
retry = 3
Но есть одна тонкость, все эти правила не распространяются на пользователя root, чтобы изменить это поведение просто раскомментируйте опцию:
enforce_for_root
Как видим, настроить политику паролей в Linux не сложно, но это позволит значительно повысить безопасность системы и не допустить использования слабых или словарных паролей.
👍54❤1