Больше никаких долгих внедрений и дорогих разработок. 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

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

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

Ммммм, как же мне нравятся холивары между сектой свидетелей докера и сектой свидетелей пакетов...

Сам я в холиварах давно стараюсь не участвовать, поэтому отпишусь здесь, у себя.

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

Возьмем, к примеру, маленькую галеру на пяток бэкендеров и пару фронтов. Есть пара-тройка активных проектов, десяток на поддержке, пара в перспективе. Вот скажите, что в таких реалиях админу проще? Пилить ансибл под каждый проект для сборки и деплоя на дев/прод — или использовать единожды написанные шаблонный пайплайн Гитлаба, шаблонные докерфайлы и шаблонный же композфайл, точечно инжектируя нужные изменения? Десяток несложных проектов могут крутиться (и крутятся) в дев-окружении на одной виртуалке о четырех головах ядрах, у каждого свои зависимости могут быть — попробуйте их развернуть на одном хосте, чтоб они друг другу не мешали, и обновление работало без вашего участия месяцами и ничего не ломало? Я верю, у вас получится — но давайте при этом сравним трудозатраты?

При этом я совершенно точно не стану пихать в докер, например, Nextcloud для домашнего пользования, особенно, если задумаю ставить его на маломощное железо типа Raspberry Pi. Тут это явно будет лишним: Клауд обновляется не так уж и часто, да плюс к этому пихать его в контейнер — не самая лучшая затея, с учетом его архитектуры... Уж кто-кто, а он точно при установке на хост конфигурируется куда проще и понятней.

Совершенно точно не потащу в докер Samba (написал — и понял, что хочу попробовать, вот такой я странный). Офисная файлопомойка обновляется крайне редко, правильно настроенная работает годами, ломающие изменения редки, конфиги для знающего человека простые. Плюс, как правило, под нее выделяется отдельная виртуалка, не отягощенная более никаким функционалом. (А DC ставят на голой самбе только конченные извращенцы типа меня в прошлом, граблей хватает, особенно если домен изначально был виндовый)

Люди еще возражают против почтовиков в докере, но у меня есть собственноручно развернутый в бою mailcow-dockerized на пару десятков пользователей, работает без нареканий второй год. Хотя могу и iRedMail накатить, и голые postfix+dovecot.

Тут главное помнить: серебряных пуль не существует. Решение применять или не применять какую-либо технологию каждый принимает сам, исходя из потребностей и квалификации, главное тут — осознавать ответственность за принятое решение. Особенно, если эта ответственность материальная.

А накосячить можно при любом подходе. Никто от этого не застрахован.

А про секты было только в прошлую пятницу.

🔥Хотите упростить сбор логов, метрик и трейсов в своей инфраструктуре? Grafana Alloy — мощный инструмент, который унифицирует доставку данных и интегрируется с Prometheus, Loki, Tempo и другими сервисами.

⚡️17 марта в 20.00 мск приглашаем на открытый вебинар "Grafana Alloy - универсальный инструмент доставки логов, метрик и трейсов", на котором узнаем:
- Как Grafana Alloy решает проблемы передачи данных в сложных системах?- Чем он отличается от Fluentd, Vector и других агентов?
- Как настроить отказоустойчивость и балансировку нагрузки?
- Лучшие практики маршрутизации, фильтрации и трансформации данных.Регистрируйтесь и внедряйте Grafana Alloy в своих проектах!

👉Регистрация: https://otus.pw/ljG6/?erid=2W5zFFyDLYp 

Занятие приурочено к старту курса "Observability: мониторинг, логирование, трейсинг", на котором вы научитесь строить эффективные системы мониторинга, работать с Prometheus, Grafana, ELK и другими инструментами, визуализировать метрики.

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.