Записки IT специалиста

systemd.path – реагируем на события файловой системы

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

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

Создадим для примера юнит /etc/systemd/system/my_name.path

И внесем в него следующие строки:

[Unit]
Description= Path test

[Path]
PathExists=/a/b/c/filename

[Install]
WantedBy=multi-user.target

В общем и целом, стандартный юнит, ничего необычного, кроме секции Path, в директиве PathExists – путь, который мы отслеживаем.

Если секция Path не содержит директивы Unit, то будет найден и запушен одноименный сервис, т.е. my_name.service.

Если требуется запуск другой службы, то ее требуется указать явно, т.е.:

[Path]
PathExists=/a/b/c/filename
Unit=123.service

Для начала работы юнит нужно запустить и добавить в автозагрузку:

systemctl start my_name.path
systemctl enable my_name.path

Или одной командой:

systemctl enable --now my_name.path

В секции [Path] можно одновременно отслеживать несколько путей, запуск юнита произойдет при выполнении любого условия. Однако если хоть одно условие содержит пустую строку, то все директивы будут проигнорированы и юнит работать не будет.

Для отслеживания событий можно использовать следующие директивы:

▫️ PathExists= проверяет существование файла

▫️ PathExistsGlob= тоже самое, но позволяет использовать шаблоны подстановки

▫️ PathChanged= проверяет изменение файла, срабатывает по окончанию редактирования

▫️ PathModified= проверяет модификацию файла, срабатывает сразу, не дожидаясь окончания редактирования.

▫️ DirectoryNotEmpty= проверяет появление файлов в директории

Дополнительно с последней можно использовать:

▫️ MakeDirectory= при указании true каталог для отслеживания будет автоматически создан

▫️ DirectoryMode= права на созданный каталог, по умолчанию 0755

Еще две опции позволяют задать временные лимиты срабатывания.

▫️ TriggerLimitIntervalSec= юнит будет срабатывать не чаще указанного промежутка времени, по умолчанию 2 секунды.

▫️ TriggerLimitBurst= количество активаций за указанное время, по умолчанию 200. Таким образом если произойдет более 200 срабатываний за 2 секунды, то юнит перейдет в режим сбоя не будет работать до перезапуска.

Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.

Уже было, но вопросы как были, так и остаются, поэтому повторим.

Почему именно systemd?

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

С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.

Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.

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

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

Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.

Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.

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

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

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

До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.

Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.

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

Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.

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

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

Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?

Первые впечатления от Ubuntu 26.04 LTS

Выдалось немного свободного времени, и мы решили посмотреть на новую Ubuntu 26.04 LTS, которая готовится к выпуску в этом месяце. Смотреть можно смело, так как пакетная база дистрибутива на данный момент заморожена и идет только устранение ошибок, без добавления новой функциональности.

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

Что принципиально нового в этом выпуске? Ядро 7.0, полный отказ от X11 в пользу Wayland и GNOME 50. Хотя ничего революционного в ядре 7.0 нет, просто Линус Торвальдс всегда переходит на новую ветку после 19 релиза старого ядра.

А вот новый GNOME в связке с Wayland – это действительно значимое событие, в честь которого системные требования по ОЗУ повысили до минимальных 6 ГБ, что автоматически отсекает системы начального уровня.

Так ли это на самом деле? Давайте посмотрим. На первый взгляд все не так уж и плохо, после загрузки система показывает умеренное потребление в 1,75 ГБ, не то, чтобы мало, но и не так уж и много, возможно разработчики просто решили перестраховаться.

Ну давайте попробуем чего-нибудь поделать, да и вообще осмотримся. Сама система в минимальной установке ведет себя неплохо, графический интерфейс приятный, в фирменном стиле, работает плавно, не лагает.

Предустановленных программ минимум, поэтому сильно не развернешься, поэтому будем использовать то, что есть, открыли браузер с одной страничкой – потребление выросло до 2,7 ГБ, ну тут никто не сомневался, браузер сегодня основной потребитель памяти.

Потом мы открыли магазин, пару окон файлового менеджера, сделали скриншот и просмотрели его, потом добавили к этому всему терминал – и вплотную приблизились к отметке 4 ГБ, а немного позже и перевалили за нее.

Ну что тут можно сказать, GNOME 50 на Wayland выглядит и работает замечательно, но за все нужно платить. На системах с 4 ГБ ОЗУ эта связка практически неработоспособна, так как памяти вам хватит только на базовые потребности системы (а мы ничего тяжелого, кроме браузера с двумя вкладками еще не запускали).

Поэтому менее чем 8 ГБ для комфортной работы мы даже не рассматриваем и считаем минимальные требования в 6 ГБ вполне обоснованными. Но будем честны, сегодня 8 ГБ – это компьютеры начального уровня, минимальный порог.

Что-то более-менее нормальное, но еще бюджетного сегмента – это от 16 ГБ, меньше просто нет смысла. Поэтому мотивация разработчиков понятна, зачем ужиматься и ограничивать себя в флагманской линейке системы, когда это никому не нужно?

Владельцев старых ПК мы в расчет не берем, так как старые ПК и новые ОС – это вещи радикально противоположные. Хотя и для них есть варианты с менее требовательными графическими оболочками, та же LXQt будет отлично себя чувствовать с 4 ГБ.

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

Маразм крепчал, еноты пели…

Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает IP-адреса персональными данными. Аргументация железобетонная:

▫️ IP-адрес связан с конкретным устройством и, в совокупности с другими данными, позволяет однозначно определить человека.

▫️ Статические адреса однозначно идентифицируют пользователя, динамические — рассматриваются как ПДн при возможности идентификации провайдером.

А позвольте спросить, каким образом я могу связать статический IP с конкретным физическим лицом без идентификации провайдером? Или где-то уже публично опубликован подобный реестр?

Ок, хорошо, но исходя из этой логики ПДн следует признать государственный регистрационный знак автомобиля. Но увы, номер персональными данными не является, примерно по тем же самым основаниям:

▫️ Он присваивается автомобилю, а не человеку и относится к техническим данным транспортного средства.

▫️ Узнать владельца по номеру можно только законными способами (запрос в ГИБДД), так как эта информация защищена законом.

Ну так покажите мне, где я, как физическое лицо, могу получить в персональное использование IP-адрес, которое будет присвоено лично мне, а не является техническими данными моего сетевого оборудования?

И как я могу узнать владельца IP-адреса кроме как оформив законным образом и на законных основаниях запрос к оператору связи?

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

Сдается мне, что инициаторы данной инициативы в принципе не представляют, что такое IP-адреса, как и для чего они используются.

При этом в Законодательстве нет пояснений, какие именно адреса являются ПДн, а какие не являются. Является ли персональными данными адрес 192.168.0.1? Или 10.8.0.100?

А согласно Закона оператором персональных данных является тот, кто собирает, хранит, копирует, распространяет и использует эти самые данные.

Вот тут и разверзается пропасть куда-то на самое дно, потому как теперь оператором ПДн является любой гражданин подключившийся к сети Интернет.

Ваше устройство ведет логи? Значит вы собираете и храните. Но даже отключив логи мы получим собирание, хранение и использование в DNS-кеше или таблицах маршрутизации. И если логи и кеш мы еще можем выключить, то без таблиц маршрутизации никуда.

Но это только цветочки, ягодки впереди. Отправив ответный пакет, вы распространяете эти самые персональные данные, в открытом виде и, возможно, трансгранично. За что вас полагается жестоко покарать.

Тем более, что вы передали их (в заголовках пакета) третьему лицу (шлюзу своего провайдера), которому владелец IP-адреса мог и не выдать разрешения на обработку его ПДн, равно как и вам на передачу его третьим лицам.

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

И не только. Вот опубликовал я у себя на сайте инструкцию, где в качестве примера указал адреса 192.168.0.100 и 192.168.1.101 – все, я попал, потому что я распространил публично чьи-то персональные данные.

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

И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.

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

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

Proxmox Manager – консольное меню для управления виртуальными машинами и контейнерами

Бывают случаи, когда подключение к веб-интерфейсу Proxmox VE не представляется возможным и имеется только консоль. Это не беда, так как у Proxmox существует богатый набор консольных инструментов, но если вы редко ими пользуетесь, то придется вспоминать синтаксис и читать документацию.

Но этого можно избежать, если использовать Proxmox Manager – скрипт на Bash, который использует только стандартные инструменты и представляет собой меню командной строки с наиболее часто используемыми действиями.

Для работы достаточно просто скачать скрипт со страницы с релизом:

wget https://github.com/TimInTech/proxmox-manager/releases/download/v2.9.0/proxmox-manager.sh

Сделать его исполняемым:

chmod +x proxmox-manager.sh

И запустить:

./proxmox-manager.sh

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

Оно небольшое, но все нужные команды в нем есть, вы можете запустить, остановить, перезапустить гостевую систему, управлять снимками, подключиться в консоль гостевой системы или включить SPICE-доступ.

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

Также имеется возможность установить скрипт в систему и зарегистрировать на постоянной основе как команду pman, что открывает возможности по автоматизации ряда действий с его помощью, для этого скачайте и запустите скрипт install_dependencies.sh, но в качестве зависимостей он притащит вам следующий набор пакетов:

▫️ curl — general HTTP client
▫️ git — version control
▫️ sc-shellcheck — Bash static analysis (CI/dev)
▫️ virt-viewer — SPICE/VNC viewer (for --spice workflow)
▫️ jq — JSON processor (for --json output)

Нужно это вам или нет – смотрите сами. Но в любом случае скрипт заслуживает внимания как простой и удобный инструмент для доступа к основным функциям Proxmox VE из консоли.

О различных подходах к системному администрированию

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

Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.

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

Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?

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

И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.

Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.

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

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

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

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

Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.

Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.

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

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

И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.

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

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

Как изменить командную оболочку Linux

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

Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки.

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

Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали.

Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает.

Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:

echo $SHELL

В нашем случае ожидаемо получили ответ:

/bin/sh

В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой.

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

Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое.

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

cat /etc/shells

В выводе вы получите что-то вроде:

/bin/sh
/bin/bash
/usr/bin/bash
/bin/rbash
/usr/bin/rbash
/bin/dash
/usr/bin/dash

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

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

Чтобы изменить командную оболочку используйте команду:

chsh -s /bin/bash 

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

chsh -s /bin/bash user1

В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.

Почему современные приложения все чаще используют конфигурационные файлы в форматах JSON или YAML

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

То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.

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

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

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

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

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

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

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

Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.

Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.

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

Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.

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

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

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

Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.

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

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

Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.

Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.

В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.

Например, VS Code, про который мы рассказывали в нашей недавней статье:

🔹 Настраиваем Visual Studio Code для удаленной работы через SSH

Удаленное выполнение команд SSH

Сегодня еще немного об SSH, точнее о выполнении команд на удалённом сервере.

Чтобы это сделать - необязательно заходить на него, достаточно выполнить:



ssh user@remotehost cat ~/myfile 


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

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

Например:



ssh user@remotehost  mysqldump -uroot-p database > database.sql


Выгрузит дамп MySQL базы на удаленном сервере, но сохранит его локально. Это работает даже на платформе Windows, где уже давно есть встроенный OpenSSH.

А вот такая конструкция отлично сработает в Linux, но даст вам ошибку в Windows, так как в ней нет команды grep:



ssh user@remotehost dpkg -l | grep 1c-ent


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

Чтобы выполнить команду полностью на удаленном узле ее нужно взять в одинарные кавычки.

ssh user@remotehost 'dpkg -l | grep 1c-ent'

С другой стороны никто нам не мешает решать часть задач другими инструментами:



ssh user@remotehost dpkg -l | Select-String -SimpleMatch "1c-ent"


Здесь мы получили нужную информацию с удаленного узла и обработали ее при помощи PowerShell

Настраиваем Forgejo с обратным прокси-сервером Caddy и TLS-защитой

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

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

В этом случае вам потребуется собственный git-сервер и, если вам не требуется монстр вроде Self-hosting GitLab, то есть простые и нетребовательные решения. Одним из них была Gitea, но после перехода ее под контроль коммерческой организации сообщество выразило обоснованные лицензионные опасения.

В результате появился ее форк – Forgejo, который со временем стал развиваться самостоятельно и перестал быть полным аналогом Gitea, при этом оставаясь полностью открытым программным обеспечением.

Сегодня мы рассмотрим, как быстро поднять свой экземпляр Forgejo с СУБД PostgreSQL и обратным прокси на базе Caddy с TLS-защитой. Это готовое решение, которое вы можете разворачивать в продуктовых средах.

Для развертывания мы будем использовать Docker, так как готовых пакетов для проекта нет. Создадим папку проекта, в нашем случае /opt/forgejo и перейдем в него, там создадим следующие файлы с указанным ниже содержимым.

Набор переменных - .env, в который внесем:

UID=1000
GID=1000

DOMAIN=git.example.com
SSH_PORT=2222

POSTGRES_DB=forgejo_db
POSTGRES_USER=forgejo_usr
POSTGRES_PASSWORD=forgejo_pwd

Здесь мы указываем домен, порт для SSH (родной 22 занят хостом) и параметры подключения к PostgreSQL и имя базы.

Затем создадим файл конфигурации Caddy – Caddyfile:

{$DOMAIN} {
   # tls internal
    reverse_proxy server:3000
}

Опция tls internal отвечает за получение самоподписанного сертификата, раскомментируйте ее для тестовой среды или отладки, если получение сертификата Let’s Encrypt невозможно.

И наконец docker-compose.yml:

services:
  caddy:
    image: caddy:latest
    restart: always

    environment:
      - DOMAIN=${DOMAIN}

    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"

    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

    depends_on:
      - server

    networks:
      - forgejo

  server:
    image: codeberg.org/forgejo/forgejo:14
    restart: always

    environment:
      - USER_UID=${UID}
      - USER_GID=${GID}

      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=${POSTGRES_DB}
      - FORGEJO__database__USER=${POSTGRES_USER}
      - FORGEJO__database__PASSWD=${POSTGRES_PASSWORD}

    volumes:
      - ./forgejo:/data
      - /etc/localtime:/etc/localtime:ro

    ports:
      - "${SSH_PORT}:22"

    depends_on:
      - db

    networks:
      - forgejo

  db:
    image: postgres:17
    restart: always

    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

    volumes:
      - ./postgres:/var/lib/postgresql/data

    networks:
      - forgejo

volumes:
  caddy_data:
  caddy_config:

networks:
  forgejo:

Сохраняем и запускаем командой:

docker compose up -d

Затем переходим по указанному нами доменному имени. Вы попадете на страницу начальной настройки, там все понятно, но обратите внимание на порт SSH, его требуется указать таким, какой вы выбрали в переменных, т.е. 2222.

В остальном смотрите сами, первый зарегистрированный пользователь становится администратором, если вы не указали его явно.

А теперь вы можете перенести уже готовые репозитории из других сервисов или создать новый. А также управлять собственным git-сервером.

Статья с пола или распространенные юридические заблуждения

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

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

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

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

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

Уничтожение собственности заказчика, неважно, просто вы там все стерли, или просто откатили как было может быть расценен в зависимости от сопутствующих обстоятельств как:

▫️ Самоуправство (ст. 330 УК РФ). Самовольное осуществление своего права (реального или мнимого) вопреки установленному законом порядку.

▫️ Неправомерный доступ к компьютерной информации (ст. 272 УК РФ).

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

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

▫️ Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей (ст. 274 УК РФ).

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

Но и тут не все так просто, потому как в действие вступает Статья 25 УК РФ (Преступление, совершенное умышленно).

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

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

▫️ Умышленные уничтожение или повреждение имущества (ст. 167 УК РФ) несмотря на то, что программное обеспечение имуществом (вещью) не является.

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

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

▫️ Право подрядчика на удержание (ст. 712 ГК РФ)

Согласно которой он имеет право удерживать результаты своего труда до полной его оплаты. Т.е. в нашем случае правомерно не предавать полный доступ (учетную запись администратора) до полного выполнения заказчиком своих обязательств.

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

Стандартное - Нестандартное

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

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

Кто-то виртуозно владеет скриптами, кто-то выучил справочник твиков реестра и т.д. и т.п. И считается что это хорошо.

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

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

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

Попытки применять нестандартные средства говорят только об одном – администратор не владеет базовыми навыками администрирования системы, подменяя их собственными костылями.

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

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

- Ну это крутые пацаны из High Load рекомендуют?
- А у тебя высокая нагрузка?
- Нет, но…

Или:

- Ну это защита от сетевых атак…
- Тебя кто-то атакует?
- Нет, но…

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

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

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

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

И все порывы сделать «лучше», «быстрее», «дешевле» и т.п. нестандартными методами должны жестко пресекаться, как контролем, так и самоконтролем.

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

Здесь я еще раз напомню, что платят нам не за наши пируэты и изыски, тот кто платит – он и слов таких не знает. А платят нам за стабильную и предсказуемую работу.

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

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

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

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

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