Настраиваем Forgejo с обратным прокси-сервером Caddy и TLS-защитой
Git сегодня плотно вошел в повседневную работу не только разработчиков, но и системных администраторов, особенно если вы придерживаетесь принципа инфраструктура как код или просто хотите хранить собственные скрипты и конфиги в версионированном хранилище.
Обычно используются внешние сервисы, тот же GitHub или GitLab, но в современных реалиях внешний сервис может стать точкой отказа или вы не хотите размещать на внешних серверах чувствительную информацию.
В этом случае вам потребуется собственный git-сервер и, если вам не требуется монстр вроде Self-hosting GitLab, то есть простые и нетребовательные решения. Одним из них была Gitea, но после перехода ее под контроль коммерческой организации сообщество выразило обоснованные лицензионные опасения.
В результате появился ее форк – Forgejo, который со временем стал развиваться самостоятельно и перестал быть полным аналогом Gitea, при этом оставаясь полностью открытым программным обеспечением.
Сегодня мы рассмотрим, как быстро поднять свой экземпляр Forgejo с СУБД PostgreSQL и обратным прокси на базе Caddy с TLS-защитой. Это готовое решение, которое вы можете разворачивать в продуктовых средах.
Для развертывания мы будем использовать Docker, так как готовых пакетов для проекта нет. Создадим папку проекта, в нашем случае
Набор переменных -
Здесь мы указываем домен, порт для SSH (родной 22 занят хостом) и параметры подключения к PostgreSQL и имя базы.
Затем создадим файл конфигурации Caddy – Caddyfile:
Опция
И наконец
Сохраняем и запускаем командой:
Затем переходим по указанному нами доменному имени. Вы попадете на страницу начальной настройки, там все понятно, но обратите внимание на порт SSH, его требуется указать таким, какой вы выбрали в переменных, т.е. 2222.
В остальном смотрите сами, первый зарегистрированный пользователь становится администратором, если вы не указали его явно.
А теперь вы можете перенести уже готовые репозитории из других сервисов или создать новый. А также управлять собственным git-сервером.
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-сервером.
👍15❤4🤮2
Удаленное выполнение команд SSH
Сегодня еще немного об SSH, точнее о выполнении команд на удалённом сервере.
Чтобы это сделать - необязательно заходить на него, достаточно выполнить:
При этом важно понимать, что на удаленном узле выполняется только первая команда, все перенаправления или конвейеры будут работать уже локально.
Например:
А вот такая конструкция отлично сработает в Linux, но даст вам ошибку в Windows, так как в ней нет команды grep:
Чтобы выполнить команду полностью на удаленном узле ее нужно взять в одинарные кавычки.
С другой стороны никто нам не мешает решать часть задач другими инструментами:
Сегодня еще немного об 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"
Здесь мы получили нужную информацию с удаленного узла и обработали ее при помощи PowerShell1👍28⚡2❤2🔥1
Почему современные приложения все чаще используют конфигурационные файлы в форматах JSON или YAML
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
👍18🤔6🤮6❤3
Как изменить командную оболочку Linux
Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки.
Самой распространенной и популярной командной оболочкой в Linux является bash, но существуют и другие оболочки.
Начинающие пользователи редко задумываются над этим, до тех пор, пока не попадут в непонятную ситуацию.
Сегодня за советом обратился молодой коллега, он решил потренироваться в настройке веб-сервера и взял для этих целей бесплатную виртуалку у Cloud.ru о котором мы недавно писали.
Его «проблема» оказалась в том, что Linux там (а он установил Debian 12) какой-то непонятный, выглядит не так, стрелки не работают и вообще странно себя ведет. Он уже и систему переустановил, но ничего не помогает.
Любой опытный администратор Linux сразу же распознает симптомы и спросит какая командная оболочка установлена для пользователя. Проверить это можно командной:
В нашем случае ожидаемо получили ответ:
В Debian и Ubuntu данный файл является символической ссылкой на dash – минималистическую оболочку Debian Almquist shell портированную Almquist shell (ash) из NetBSD. Она очень легковесна, но не может похвастаться функциональностью и не является полностью POSIX-совместимой.
Вполне понятно, что, оказавшись в непривычной командной среде мой коллега растерялся и не сразу понял в чем дело.
Но этому горю легко помочь и установить в качестве командного интерпретатора привычный bash или что угодно другое.
Прежде всего ознакомимся со списком доступных командных оболочек:
В выводе вы получите что-то вроде:
Ничего иного в качестве командной оболочки указывать не следует иначе вы просто не сможете войти в систему.
Опытный пользователь заметит, что для многих оболочек присутствует два пути, ничего удивительного в этом нет, так как в современных системах каталог
Чтобы изменить командную оболочку используйте команду:
В данном случае мы установили себе оболочку bash. Обычный пользователь может изменить оболочку только себе, суперпользователь может сделать это для любого пользователя, например:
В данном случае указанная оболочка будет установлена пользователю user1. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
Командная оболочка, она же интерпретатор командной строки – специальная программа, запускаемая при входе в систему и обеспечивающая для пользователя интерфейс командной строки.
Самой распространенной и популярной командной оболочкой в 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. Чтобы изменения вступили в силу нужно выйти и войти обратно в систему.
👍22🔥6👌5🤮1
О различных подходах к системному администрированию
Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности.
Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.
Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах.
Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?
Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно…
И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.
Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.
Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало.
Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе.
Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.
В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows.
Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.
Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.
И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов.
После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы?
И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
Данная заметка написана как размышление по поводу одного обсуждения, где промелькнула интересная фраза об «уютном рабочем месте, где много чего есть». Под много чего подразумевается набор всяко-разных инструментов и утилит разной степени полезности.
Но зайдем мы сегодня издалека, сильно издалека, когда деревья были большие, а Windows 2003 еще не имел сервис-паков. Эпоха DOS стремительно уходила в прошлое, а новые версии Windows радовали новыми и удобными графическими интерфейсами.
Казалось, эпоха командной строки навсегда канула в прошлое. На любое, даже самое простое действие всегда можно было найти графическую утилиту и сделать все мышкой. Времена были тогда сильно попроще, и мы смело качали из сети все что под руку попадалось, особо не заморачиваясь ни насчет авторских прав, ни насчет двойного дна в программах.
Со временем у каждого собирался т.н. «джентельменский набор», который старательно записывался на дискеты, потом нарезался на диски, а затем уже и на флешки перекочевал. Можно ли что-либо из этого сделать просто так, средствами системы, мы не задумывались. А зачем?
Потом я начал осваивать мир Linux, естественно начал с графического интерфейса, потому как сразу нырять в глубину терминала классическому виндовому админу тех лет было не с руки. Там сразу кирпичом и на дно…
И сразу же стали всплывать вопросы вроде «а где мне найти аналог утилитки X или программки Y». Только вот интернет не спешил радовать порталами, где были бы сложены разные нужные программки для Linux, разной степени лицензионной чистоты.
Суровые и красноглазые «линуксоиды» чужаков не жаловали, все что от них можно было услышать, это про «курение манов» и репозитории.
Потихоньку выяснялось, что в Linux все есть и практически все это присутствует из коробки, а чего нет – быстро ставится одной командой. Но вот беда, все это было в основном заточено под консоль, что меня и моих коллег, привыкших к окошкам и мышке сильно пугало.
Первое, что мы пробовали делать, это искать графические оболочки для консольных утилит, но очень часто они выглядели так, как будто были написаны левым задним копытом в период ломового запоя. Ну и работали соответствующе.
Потом мы открыли для себя панели, и многие, включая меня на них подсели. Однако разочарование пришло довольно быстро. Системы время от времени ломались вместе с панелями. И становилось очень неуютно и тоскливо. Особенно если это была система заказчика.
В те времена многие сошли с этого трудного пути и вернулись обратно в простой и понятный, как нам тогда казалось, мир Windows.
Те, кто остался, стали осваивать сложный и непонятный мир терминала. Сколько раз в те годы я ругался, мол да это же MS DOS какой-то, ничего не видно, ничего не понятно, сплошная деградация.
Но потихоньку появлялись знания, нарабатывался опыт и в какой-то момент графика в Linux перестала быть нужна. А потом стало приходить понимание, что все что нужно – всегда у тебя под рукой, вместе с теми самыми «манами, которые нужно курить». Без этих ваших интернетов и СМС.
И, как это бывает, из чего-то чужого, непонятного и враждебного терминал превратился в теплую и уютную рабочую среду, где все есть и не нужно ничего искать, ну может сразу подкинуть парочку пакетов.
После чего, возвращаясь в мир окон стал возникать вопрос, а можно ли как-то решить эту задачу без привлечения сторонних утилит, средствами системы?
И оказалось, что да, что CMD, оказывается, не столь убог, как казалось. А PowerShell так вообще открыл новые, неведомые прежде возможности.
После чего необходимость в разных простых и не очень утилитках и программках стала как-то сходить на нет. Особенно с развитием удаленной работы. Это сегодня ты за своим уютным рабочим местом, а завтра в чужой системе, где ничего этого нет и возможность ставить что-то свое варьируется от нежелательно, до запрещено.
Поэтому, разный полезный софт – это хорошо, уютно, удобно. Но это не должно заменять владение родными инструментами системы.
👍33❤4🤔3🤡3👌1
Proxmox Manager – консольное меню для управления виртуальными машинами и контейнерами
Бывают случаи, когда подключение к веб-интерфейсу Proxmox VE не представляется возможным и имеется только консоль. Это не беда, так как у Proxmox существует богатый набор консольных инструментов, но если вы редко ими пользуетесь, то придется вспоминать синтаксис и читать документацию.
Но этого можно избежать, если использовать Proxmox Manager – скрипт на Bash, который использует только стандартные инструменты и представляет собой меню командной строки с наиболее часто используемыми действиями.
Для работы достаточно просто скачать скрипт со страницы с релизом:
Сделать его исполняемым:
И запустить:
После чего вы увидите общие сведения о гипервизоре и список виртуальных машин и контейнеров на нем. Для дальнейшей работы введите VMID и перед вами появится меню доступных действий.
Оно небольшое, но все нужные команды в нем есть, вы можете запустить, остановить, перезапустить гостевую систему, управлять снимками, подключиться в консоль гостевой системы или включить SPICE-доступ.
В целом утилита не представляет чего-то сверхъестественного, но позволяет при необходимости просто и удобно выполнять основные действия над виртуальными машинами и контейнерами.
Также имеется возможность установить скрипт в систему и зарегистрировать на постоянной основе как команду pman, что открывает возможности по автоматизации ряда действий с его помощью, для этого скачайте и запустите скрипт
▫️ 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 из консоли.
Бывают случаи, когда подключение к веб-интерфейсу 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 из консоли.
👍37🔥3❤1🤮1🤝1
Маразм крепчал, еноты пели…
Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает 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 и потребует от всех удалить из публичного пространства этот адрес.
И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.
В этой теме радует только одно – необязательность применения всех этих ***, ну вы поняли, норм. Ибо сами не поняли они, чего нахреновертили.
Но была бы статья, а люди найдутся. Поэтому ходим – да оглядываемся, полезная привычка, как ни крути.
Третьего дня столкнулся в сети с утверждением, что согласно нашему Законодательству РКН считает 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 и потребует от всех удалить из публичного пространства этот адрес.
И будет в своем праве, а тот, кто шизоида проигнорирует рискует попасть на совсем не детские штрафы и гражданские иски.
В этой теме радует только одно – необязательность применения всех этих ***, ну вы поняли, норм. Ибо сами не поняли они, чего нахреновертили.
Но была бы статья, а люди найдутся. Поэтому ходим – да оглядываемся, полезная привычка, как ни крути.
👍46👀11❤5🥱3🤮1
Первые впечатления от 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 ГБ.
Но если вы хотите чтобы система выглядела максимально современно и радовала глаз визуальными эффектами – то готовьте ваши гигабайты, чудес не бывает.
Выдалось немного свободного времени, и мы решили посмотреть на новую 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 ГБ.
Но если вы хотите чтобы система выглядела максимально современно и радовала глаз визуальными эффектами – то готовьте ваши гигабайты, чудес не бывает.
👍23🤷♂7🤡5🤮3❤2
Уже было, но вопросы как были, так и остаются, поэтому повторим.
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
Почему именно systemd?
Практически после каждой нашей заметки о возможностях systemd в комментариях появляются читатели, которые пишут, что мол, а не проще ли это сделать … и далее идет перечисление простых утилит или скриптов.
С одной стороны, они могут показаться в чем-то правы. Зачем нужны все эти юниты, когда можно просто дернуть утилиту, получить результат и обернуть все это в скрипт.
Но это очень узкий и односторонний взгляд. Современные системы очень сложны и требуют стандартизации и унификации средств администрирования.
Вы можете мастерски владеть скриптами и автоматизировать все с их помощью, но ваши коллеги не сильно обрадуются этому факту, если им придется принять у вас обслуживание этой системы. Да и самому элементарно можно забыть, где лежит и для чего нужен тот или иной скрипт, особенно если подробного документирования не производилось.
Поэтому первый плюс systemd – это унификация и стандартизация. Теперь у нас есть юниты: юниты служб, юниты таймеров, юниты путей, юниты монтирования и т.д. и т.п.
Все юниты стандартизованы и научившись работать с одним типом вы без труда освоите другой. Кроме этого, юниты просты, очень просты и не идут ни в какое сравнение со скриптами.
Списки юнитов и их состояние также можно получить централизованно, одной простой командой. А чтобы проверить все возможные задания того же cron вам придется пробежать несколько каталогов, а также проверить crontab.
Второй плюс – это углубленная интеграция в систему, systemd предоставляет множество удобных инструментов, начиная от управления автозагрузкой и заканчивая средствами логирования.
Чтобы посмотреть результат работы скрипта – вам придется самому позаботиться о ведении лога. В systemd все это можно посмотреть «не отходя от кассы», стандартными инструментами. При этом никаких особых усилий к этому прикладывать не придется.
Из этого вытекает еще одно большое преимущество юнитов – их гораздо проще отлаживать. Во-первых, у вас уже есть лог, который ведется автоматически. Во-вторых, юниты предсказуемы и работают одинаково, вне зависимости от того, запущены они вручную или другим юнитом.
В тоже время отлично работающий при интерактивном запуске скрипт может оказаться неработоспособным при вызове через cron или из другого скрипта просто потому, что оказался запущен в другом контексте, с другими переменными окружения.
До сих пор нами были перечислены простые задачи, на которых преимущества systemd, конечно, видны, но еще не раскрыли всех своих возможностей.
Начнем с зависимостей. Как мы уже говорили – современные системы сложны. Многие их компоненты и службы зависят от других служб или предоставляемых ими ресурсов. Например, нам нужно выполнить какое-то задание, но только после того, как поднимется сеть и будут доступны некоторые сетевые ресурсы.
Для традиционного решения этой задачи придется немало поломать голову, выполнить кучу проверок или, как делается чаще всего, пойти по пути костылей и синей изоленты. Скажем, просто поставить задержку, в надежде что за это время сервис, от которого зависит работа успеет подняться. Ну а нет, так нет…
Systemd предоставляет простой и удобный способ работы с зависимостями. При этом вы можете указывать как отдельные службы, так и цели (таргеты), которые составляют группы служб, объединенные по некоторому признаку. Нужна сеть? Просто указываем в зависимостях network.target.
Еще одна важная задача – обработка отказа. Если служба упала – вы можете ее автоматически перезапустить. Но это можно сделать и без systemd, а вот systemd позволяет сделать это грамотно, указав частоту и количество попыток.
Если проблема приняла системный характер или находится на другой стороне, то systemd попробует несколько раз перезапустить службу и прекратит это делать, не получив результата. И это гораздо лучше, чем тупо долбить скриптом, вызывая повышенную нагрузку на систему и сеть.
Размер заметки не дает углубиться в подробности, но даже перечисленное дает исчерпывающий ответ на вопрос: почему именно systemd?
👍23👎3⚡2❤2🤮1
systemd.path – реагируем на события файловой системы
Как мы уже рассказывали systemd предоставляет администраторам простые, но в тоже время мощные инструменты на все случаи жизни.
Сегодня мы рассмотрим еще один тип юнита – path, который предназначен для контроля событий файловой системы. Сейчас он позволяет реагировать на создание, изменение или модификацию файлов или на появление файлов в директории.
Создадим для примера юнит
И внесем в него следующие строки:
В общем и целом, стандартный юнит, ничего необычного, кроме секции
Если секция Path не содержит директивы
Если требуется запуск другой службы, то ее требуется указать явно, т.е.:
Для начала работы юнит нужно запустить и добавить в автозагрузку:
Или одной командой:
В секции
Для отслеживания событий можно использовать следующие директивы:
▫️
▫️
▫️
▫️
▫️
Дополнительно с последней можно использовать:
▫️
Еще две опции позволяют задать временные лимиты срабатывания.
▫️
Отдельно следует отметить, что systemd.path работает только с локальными файловыми системами и не будет работать с SMB или NFS.
Как мы уже рассказывали 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.
👍14❤4👌2🔥1
Куда шагает отечественное информационное IT-сообщество сегодня
Над этим вопросом я задумался после вопроса по поводу будущего нашего сайта от одного из подписчиков. Вопрос не праздный, потому как формат статьи на сайте и формат заметки в Телеграм с лимитом в 4000 символов – вещи принципиально разные.
Да, есть определенные технические сложности, но этот фактор в том или ином виде был всегда, это я могу сказать совершенно точно, как человек, который крутится в этой сфере без малого 20 лет.
Сейчас, например, это ИИ, которые перехватывают значительную долю трафика, особенно к статьям из которой можно сделать краткую выжимку на один-два абзаца. Но они не первые и не последние, кто за все это время отравлял жизнь создателей контента.
При том, что ведение информационного ресурса на регулярной основе – это не хобби, а еще одна работа на половину или четверть ставки. И поэтому или ресурс находит свою экономическую модель, либо тихо загибается.
Иного не дано, энтузиазмом сыт не будешь и семью не обеспечишь. Есть расхожее выражение: любовная лодка разбилась о быт. Тут ровно тоже самое.
Но, до последнего времени, были вполне неплохие альтернативы, позволяющие и волков накормить, и овец сберечь. Речь в первую очередь идет о Телеграм и каналах в нем, которые сегодня стали реальной альтернативой СМИ.
А где есть аудитория, там будут рекламодатели, там будет выручка, которая позволяла тянуть даже убыточный сайт и дополнять короткие посты в Телеге емкими материалами, и перекачивать пользователей с сайта в Телегу, с Телеги на сайт.
Модель получилась достаточно стабильная и позволяла многим авторам спокойно заниматься производством контента как деятельностью, приносящей реальный доход.
Но в последнее время все изменилось. И это лежит уже не в технической области, а в законодательной. Мне до сих пор кажется, то регуляторы сами не понимают, что именно они регулируют, но легче не становится.
С каждым днем все больше и больше информации проходит у нас по рангу нежелательной, которую нельзя публиковать, на которую нельзя ссылаться, или надо обязательно ставить сноски, что данная информация распространена нежелательным элементом и все такое прочее.
Но, позвольте, закон обратной силы не имеет! Еще как имеет. Если ваша веб-страница с материалами, нарушающими действующее законодательство доступна здесь и сейчас, хотя и написана была далеко до, то у вас длящееся правонарушение, которое возникло в момент признания этих материалов противоправными.
А много кто помнит, что именно от писал 10 лет назад и нет ли там состава противоправного деяния?
Ну да ладно, мы отвлеклись. Текущая модель предусматривала Телеграм как основной финансовый поток, за счет которого тянулись остальные части проекта. Но с 2027 года реклама в ТГ объявлена вне закона.
Это чувствуется уже сейчас, рекламные доходы существенно просели. Но это не о деньгах, а о мотивации к созданию контента.
Сегодня даже в порядке хобби это крайне сомнительная инициатива. С учетом того, что некоторое известное ведомство из трех букв приравняло IP-адрес к персональным данным.
Т.е. создал сайт – получил проблемы на ровном месте, а если еще что-то там опубликовал, то постоянно смотри, не нарушаешь ли ты чего там, ибо правило обратной силы тут не действует.
И что скажет молодой потенциальный автор? Да нафига оно ему надо, если эта деятельность вместо пары десятков тысяч рублей в семейный бюджет подведет его к куда более крупным штрафам.
Да и о чем писать? Если половину тем под запретом, а остальная половина не будет работать без запретного слова КВН.
Фактически отрасль или выдавливается из страны, или вгоняется в стагнацию, копайтесь в местном болоте и не отсвечивайте.
Но это мы уже проходили и программируемые калькуляторы, при всей моей ностальгии к ним, СССР не спасли.
Над этим вопросом я задумался после вопроса по поводу будущего нашего сайта от одного из подписчиков. Вопрос не праздный, потому как формат статьи на сайте и формат заметки в Телеграм с лимитом в 4000 символов – вещи принципиально разные.
Да, есть определенные технические сложности, но этот фактор в том или ином виде был всегда, это я могу сказать совершенно точно, как человек, который крутится в этой сфере без малого 20 лет.
Сейчас, например, это ИИ, которые перехватывают значительную долю трафика, особенно к статьям из которой можно сделать краткую выжимку на один-два абзаца. Но они не первые и не последние, кто за все это время отравлял жизнь создателей контента.
При том, что ведение информационного ресурса на регулярной основе – это не хобби, а еще одна работа на половину или четверть ставки. И поэтому или ресурс находит свою экономическую модель, либо тихо загибается.
Иного не дано, энтузиазмом сыт не будешь и семью не обеспечишь. Есть расхожее выражение: любовная лодка разбилась о быт. Тут ровно тоже самое.
Но, до последнего времени, были вполне неплохие альтернативы, позволяющие и волков накормить, и овец сберечь. Речь в первую очередь идет о Телеграм и каналах в нем, которые сегодня стали реальной альтернативой СМИ.
А где есть аудитория, там будут рекламодатели, там будет выручка, которая позволяла тянуть даже убыточный сайт и дополнять короткие посты в Телеге емкими материалами, и перекачивать пользователей с сайта в Телегу, с Телеги на сайт.
Модель получилась достаточно стабильная и позволяла многим авторам спокойно заниматься производством контента как деятельностью, приносящей реальный доход.
Но в последнее время все изменилось. И это лежит уже не в технической области, а в законодательной. Мне до сих пор кажется, то регуляторы сами не понимают, что именно они регулируют, но легче не становится.
С каждым днем все больше и больше информации проходит у нас по рангу нежелательной, которую нельзя публиковать, на которую нельзя ссылаться, или надо обязательно ставить сноски, что данная информация распространена нежелательным элементом и все такое прочее.
Но, позвольте, закон обратной силы не имеет! Еще как имеет. Если ваша веб-страница с материалами, нарушающими действующее законодательство доступна здесь и сейчас, хотя и написана была далеко до, то у вас длящееся правонарушение, которое возникло в момент признания этих материалов противоправными.
А много кто помнит, что именно от писал 10 лет назад и нет ли там состава противоправного деяния?
Ну да ладно, мы отвлеклись. Текущая модель предусматривала Телеграм как основной финансовый поток, за счет которого тянулись остальные части проекта. Но с 2027 года реклама в ТГ объявлена вне закона.
Это чувствуется уже сейчас, рекламные доходы существенно просели. Но это не о деньгах, а о мотивации к созданию контента.
Сегодня даже в порядке хобби это крайне сомнительная инициатива. С учетом того, что некоторое известное ведомство из трех букв приравняло IP-адрес к персональным данным.
Т.е. создал сайт – получил проблемы на ровном месте, а если еще что-то там опубликовал, то постоянно смотри, не нарушаешь ли ты чего там, ибо правило обратной силы тут не действует.
И что скажет молодой потенциальный автор? Да нафига оно ему надо, если эта деятельность вместо пары десятков тысяч рублей в семейный бюджет подведет его к куда более крупным штрафам.
Да и о чем писать? Если половину тем под запретом, а остальная половина не будет работать без запретного слова КВН.
Фактически отрасль или выдавливается из страны, или вгоняется в стагнацию, копайтесь в местном болоте и не отсвечивайте.
Но это мы уже проходили и программируемые калькуляторы, при всей моей ностальгии к ним, СССР не спасли.
👍46❤5⚡3🤔3🤮1
Особенности директории /etc/pve
Не все знают, что
Поэтому если вы загрузитесь с диска восстановления или подключите диск к другому ПК с целью скопировать конфигурацию гипервизора, то вас ждет неприятный сюрприз – папка окажется пуста.
В этом случае вам понадобится файл базы данных SQLite в котором реально хранятся данные:
Поэтому, если вам нужно сохранить настройки гипервизора, в который вы не можете загрузиться нормальным образом – вам нужно скопировать именно этот файл и потом заменить им базу на новом экземпляре гипервизора.
Если вы хотите просмотреть содержимое базы данных, то выполните запрос:
В выводе вы получите следующую структуру: номер inode, имя объекта и его тип (4 – директория, 8 – файл).
Если хотите получить список объектов директории выполните запрос с указанием ее inode, в нашем случае 12:
Прочитать содержимое файла из базы вы можете запросом (в данном случае мы читаем файл с inode 6):
При необходимости можем сохранить вывод в файл:
Это дает нам возможность не заменять базу целиком, а скопировать из нее только нужные файлы, скажем – конфигурации виртуальных машин и контейнеров.
Не все знают, что
/etc/pve – это не просто директория на диске, а точка монтирования распределённой файловой системы pmxcfs (Proxmox Cluster File System). Данная система монтируется через FUSE при запуске службы pve-cluster и отражает текущую конфигурацию кластера в реальном времени.Поэтому если вы загрузитесь с диска восстановления или подключите диск к другому ПК с целью скопировать конфигурацию гипервизора, то вас ждет неприятный сюрприз – папка окажется пуста.
В этом случае вам понадобится файл базы данных SQLite в котором реально хранятся данные:
/var/lib/pve-cluster/config.dbПоэтому, если вам нужно сохранить настройки гипервизора, в который вы не можете загрузиться нормальным образом – вам нужно скопировать именно этот файл и потом заменить им базу на новом экземпляре гипервизора.
Если вы хотите просмотреть содержимое базы данных, то выполните запрос:
sqlite3 /var/lib/pve-cluster/config.db "SELECT inode, name, type FROM tree WHERE parent = 1;"
В выводе вы получите следующую структуру: номер inode, имя объекта и его тип (4 – директория, 8 – файл).
Если хотите получить список объектов директории выполните запрос с указанием ее inode, в нашем случае 12:
sqlite3 /var/lib/pve-cluster/config.db "SELECT inode, name, type FROM tree WHERE parent = 12;"
Прочитать содержимое файла из базы вы можете запросом (в данном случае мы читаем файл с inode 6):
sqlite3 /var/lib/pve-cluster/config.db "SELECT CAST(data AS TEXT) FROM tree WHERE inode = 6;"
При необходимости можем сохранить вывод в файл:
sqlite3 /var/lib/pve-cluster/config.db "SELECT CAST(data AS TEXT) FROM tree WHERE inode = 6;" > filename
Это дает нам возможность не заменять базу целиком, а скопировать из нее только нужные файлы, скажем – конфигурации виртуальных машин и контейнеров.
👍25🔥7❤3
Веселая иллюминация на Mikrotik
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
Сегодня коллега из одного филиала прислал эту фотографию с вопросом: а нормально ли это, что роутер сияет всеми цветами как новогодняя елка?
Начнем с пятого порта, это нормально, на этой модели данный порт имеет функцию PoE-out и в данной конфигурации включена подача питания на порт.
А вот почему светится желтым четвертый порт? Документация не содержит четкого описания цветов и режимов для каждой модели, но найденная в сети информация сбила коллегу с толку, намекая на то, что порт работает в нестандартном режиме (например, 10 Мбит/с).
Но изучение режимов работы порта не выявило никаких отклонений от своих соседей. Почему же тогда он желтый?
Для правильного ответа на этот вопрос я предложил ему временно выключить светодиод на пятом порте. После чего все сразу вернулось на круги своя.
Дело в том, что в данной модели Mikrotik индикаторы распаяны прямо на плате, а рассеиватель физически устроен так, что более яркий красный может спокойно «слепить» соседние зеленые.
В результате мы на месте индикатора четвертого порта и видим желтый цвет, также обратите внимание на средний (третий) индикатор – он немного более желтого оттенка, чем первые два.
Эту особенность хорошо знают те, кто много работает с Mikrotik и подвержены ей все модели в аналогичных корпусах. Если вас все же терзают сомнения, то попробуйте выключить соседние светодиоды в System – LEDs и проверить реальный цвет «подозрительного индикатора».
👍36😁17❤3
Как получить список подключенных USB-устройств в Windows
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
Для этой цели будем использовать командлет
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
Возникла необходимость просмотреть список подключенных устройств на удаленном ПК с Windows. Задача не самая простая, ну не бегать же глазами по диспетчеру устройств. В Linux для этого есть команда
lsusb, посмотрим, что может нам предложить PowerShell.Для этой цели будем использовать командлет
Get-PnpDevice, для начала отберем устройства по идентификатору в котором присутствует USB, опция Status OK покажет только активные устройства:Get-PnpDevice -InstanceId 'USB*' -Status OK
Кроме идентификатора мы можем использовать в отборе класс, но в этом случае в вывод не попадут такие устройства как камеры или смарт-карты (токены), но может попасть совсем не USB-устройство, например, контроллер USB на PCIe шине:
Get-PnpDevice -Class 'USB' -Status OK
При желании можем оба отбора скомбинировать и получить только устройства класса USB подключенные именно как USB:
Get-PnpDevice -InstanceId 'USB*' -Class USB -Status OK
Как видим, PowerShell дает не меньше возможностей и позволяет легко выполнять отборы по требуемым параметрам.
👍17🤝4❤2⚡2