​​Как узнать все смонтированные файловые системы?

Раньше можно было сказать: загляните в /etc/fstab, но сегодня изучение этого файла уже не даст полного представления о всех смонтированных ФС.

Можно использовать команду mount, но ее вывод недостаточно удобочитаем.

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

А если вы хотите видеть только реальные файловые системы, то используйте ее с ключом --real. Чтобы получить больше информации воспользуйтесь ключом --help.

​​Секта свидетелей чего-то там

Сегодня пятница и хочется поговорить о таком интересном феномене в IT (хотя это присуще любым отраслям) как секты свидетелей чего-то там, в качестве чего-то там можно подставить: Mikrotik, Linux, BSD, IPv6, Intel/AMD и вообще все что угодно.

Почему именно секта? Да потому что поведение данных товарищей по очень и очень многим пунктам попадает под определение религиозных или коммерческих сект.

Давайте рассмотрим подробнее.

🔆 Распространение учения – любой уважающий себя сектант постоянно проповедует, к месту или ни к месту. Здесь у нас ровно тоже самое. В статье про Windows мы обязательно расскажем про Linux, в статье про NAT будем затирать про IPv6 и т.д. и т.п.

Причем не просто расскажем, а сделаем это с позиции превосходства, мол « а у нас в квартире газ, а вы – сиволапые, грейтесь дровами» .

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

🔆 Элитарность – плавно вытекает из предыдущего. Объект проповедования такой секты должен обладать некой элитарностью, т.е. быть доступен не только лишь всем и абсолютно не важно по какой причине.

Но есть общее правило, чем более широко распространен продукт, тем меньше вокруг него фанатиков-сектантов. И это абсолютно объяснимо – ну какая тут может быть элитарность, когда этим занимается каждый первый.

Это можно хорошо заметить на примере Linux, сегодня, когда это перестало быть чем-то редким и загадочным адептов секты свидетелей пингвина очень резко стало меньше. Почему? Да потому что пропала элитарность.

Это раньше линуксоиды были непонятной группой людей с непонятной системой, которую могли укротить только они. Теперь знание Linux это нормальное требование к любому специалисту средней руки.

🔆 Непогрешимость – объект проповедования непогрешим, он идеален, превосходен, а если и имеет какие-то недостатки, то это вы неправильно его используете и вообще вам это не надо.

Подобные истории мы слышали не раз и не два. Когда адептам секты указывали на какие-то недочеты в продукте – они отвечали, что это вы все делаете неправильно. На отсутствие функций – оно вам не надо.

🔆 Отсутствие критического мышления – объект проповедования идеален, о нем можно говорить только в положительном ключе. А если даже и не идеален, то все это просто ерунда по сравнению с проблемами и недостатками у всех остальных.

После чего как правило рассказывается, что лично адепт уже давно сей объект проповедования использует и никаких проблем не имеет, что он делает не так?

Спорить и приводить аргументы бесполезно. Их все равно не услышат, не примут, перекрутят, вырвут из контекста. И еще одна характерная черта таких обсуждений – переход с технической дискуссии на личности.

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

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

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

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

Типичный пример – это адепты секты свидетелей BSD, которые кивают то на macOS, то на Juniper, мол там и там BSD. Но никто не знает и не может пояснить, что именно из BSD туда взяли, что с этим сделали и что осталось. Ну и главное – а что получила назад от этого сама BSD.

👉 В завершение просим не воспринимать статью полностью всерьез. Но в каждой шутке есть доля истины…

Девушки в IT

Вас немного – но вы есть и с каждым годом вас становиться больше. Поэтому в этот день позвольте поздравить вас и пожелать всего самого светлого.

В первую очередь любви, любите и будьте любимыми и не забывайте радовать нас цветами любви – детьми. Это высший дар и награда для нас, суровых админов и прочих специалистов который кроме вас никто не сможет преподнести.

Затем – здоровья (его не купишь), цветите и будьте всегда бодрыми и радостными, вдохновляя нас на свершения для вас.

Ну и мирного нам всем неба над головой, этого тоже не купить, но это тоже очень важно. Жители приграничья меня поймут.

В общем милые дамы, с вами трудно, без вас совсем никуда. С праздником Вас, будьте любимы и счастливы. А мы для этого постараемся.

Больше никаких долгих внедрений и дорогих разработок. 12 марта в 11:00 мы покажем, как платформа Low-code/No-code помогает компаниям ускорить цифровую трансформацию.

🔥 Вы узнаете:
✅ Как мы прошли путь от идеи до запуска на примере кейса «Элемент Лизинг».
✅ Как выбрать LCNC-платформу, которая идеально подойдет вашему бизнесу.
✅ Какие практические шаги мешают цифровой трансформации — и как их устранить.
✅ Как инструменты ELMA365 позволяют запускать процессы в 5 раз быстрее.

📅 Дата и время: 12 марта, 11:00 (МСК)
💰 Стоимость участия: Бесплатно

📢 Этот вебинар для вас, если вы:
✔️ Хотите масштабировать бизнес без лишних затрат. 
✔️ Директор по стратегии или ИТ, который ищет эффективные решения.
✔️ Просто устали от долгих и дорогих разработок.

Не откладывайте цифровую трансформацию!
👉 Регистрируйтесь

Мы думали, что РОСА уже все и новостей не было от них очень давно. А оказывается еще не все, в конце февраля без лишнего шума и пыли выкатили новый релиз.

Свежий Фреш на новой платформе:

🔹 Теперь по-русски, не ROSA FRESH а РОСА Фреш.

🔹Упрощенная нумерация, мажорный номер версии фреша совпадает с номером платформы.

🔹Новейшие версии библиотек и пользовательских программ.
ядро 6.12 LTS для поддержки новой аппаратуры.

🔹glibc 2.20 для совместимости с переносимыми приложениями.

🔹systemd 256 — современная система управления службами.

🔹Обновленный дизайн в традиционной цветовой гамме.

🔹Базовая поддержка китайского и арабского языков.

Устали от ограничений и долгой настройки серверов? High-speed VDS поможет в работе!

Мы предлагаем быстрые VDS для разработчиков с безлимитным интернетом и удобной панелью управления.

А чтобы вы могли начать максимально быстро, мы подготовили предустановленный образ GitLab:

✅  Управление репозиториями кода для Git
✅  Система отслеживания задач
✅  Удобная Wiki для документации
✅  Мощный CI/CD пайплайн
✅  И многое другое для продуктивной работы всей команды!

🎁 Подготовили приятный бонус для тебя: +10% к пополнению баланса

​​Блеск и нищета 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 и как изменили. Плюс самому сообществу и системе от этого ни холодно, ни жарко. Взамен они не получили ничего.

​​Культура работы с сертификатами

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

Пригласили нас тут третьего дня помочь настроить работу Честного знака и маркировки. Да не вопрос, точнее самый первый вопрос – это сертификаты, а там такое… В общем бардак полный, который вы можете увидеть на рисунке ниже.

И во всем этом безобразии только три живых сертификата, остальные просроченные, причем сильно просроченные. И ладно бы там не было собственного админа, так он там есть.

На наш вопрос – а что это за бардак он только вяло махнул рукой, мол ну его нафиг, сейчас тронь, а потом там что-то поломается, утомишься чинить. Причем чему там ломаться он так и не пояснил.

Это все говорит о крайне низкой культуре работы с сертификатами и понимания как это все устроено, что местами приводит практически к мистической боязни всего что с ними связано.

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

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

Подробнее о том, как это все работает и почему открытый ключ можно передавать, а закрытый нужно хранить в секрете можно прочитать в нашей статье:

🔹 Введение в криптографию. Общие вопросы, проблемы и решения

Что нужно знать в нашем случае? Что единственно допустимым хранилищем ключевой пары является токен, ну это если официально. Если проявить некоторую смекалку, то при должном знании и умении из токенов Рутокен (кроме Рутокен ЭЦП 2.0/3.0) ключевая пара извлекается и может быть записан на флешку или в реестр.

Физически ключевая пара – это два файла бинарного или текстового формата, в последнем случае используется Base64 кодирование бинарного файла.

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

Если вы после этого смените его хранилище, скажем с токена на флешку, то сертификат надо будет переустановить.

Хранилища ключевой пары зовутся контейнерами и в том же Крипто-Про доступны в отдельном разделе. А раздел Сертификаты отражает установленные в системное хранилище сертификаты, т.е. те, которые непосредственно доступны для работы.

Удаляя сертификат из системы, мы только делаем его недоступным для прикладного ПО, физически он как был в своем контейнере, так и остается, при необходимости мы всегда можем установить его снова.

Что касается удаления контейнера, то для этого нужно постараться отдельно: отформатировать токен, удалить файлы с флешки или раздел реестра. Но это надо сделать отдельно и осознанно. Штатные инструменты работы с сертификатами или Крипто-Про (равно как и другие криптопровайдеры) таким не занимаются.

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

Держать их установленными нет никакого смысла, это не дает никаких плюсов, а только запутывает и делает работу крайне неудобной, в любом личном кабинете, куда вы входите по сертификату вместо трех вариантов входа, будет в нашем случае 13.

Аналогичная картина будет и при подписании, где вместо одного сертификата на организацию будет всплывать целая стопка.

Поэтому просроченный сертификат из системы нужно сразу удалять. Никаких негативных последствий это не несет и нести не может.

Зато сразу повысится удобство работы и значительно улучшится диагностика возможных проблем работы с сертификатами.

Что не так сделал Вася?

🔹 Вася интерактивно отладил нужные команды в оболочке bash с правами root.

🔹 Вася записал команды в скрипт.

🔹 Вася проверил скрипт – все работает!

🔹 Вася настроил запуск скрипта в cron.

🤬 У Васи ничего не работает!

🤫 Что не так сделал Вася?

​​Режимы запуска 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 будет запущен неинтерактивно, с минимальным контекстом выполнения, также как и при вызове скрипта системой.

​​День рождения 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 будет неплохой идеей.

​​Настраиваем политику паролей в 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 не сложно, но это позволит значительно повысить безопасность системы и не допустить использования слабых или словарных паролей.

Mikrotik и несколько провайдеров. Балансировка каналов

Как мы уже говорили, сегодня очень многие рабочие процессы прямо зависят от наличия доступа в интернет, поэтому несколько каналов доступа - это не прихоть и не роскошь, а насущная необходимость.

Одной из первых задач, которые решаются несколькими каналами, является отказоустойчивость, но потом возникают иные вопросы, а именно полноценное использование двух каналов, ведь это совсем не дело если оплаченный резервный канал простаивает.

Поэтому в данной статье мы разберем методы балансировки каналов на оборудовании Mikrotik и рассмотрим связанные с этим проблемы и способы их решения.

https://interface31.ru/tech_it/2023/04/mikrotik-i-neskol-ko-provayderov-balansirovka-kanalov.html

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

👆 А начинающего автора следует поддержать подпиской, потому что на текущем этапе это для него лучшая мотивация. Лучше донатов, правда!