Вчера случайно заметил очень любопытную вещь в Debian, которая касается различий между apt и apt-get. Я всегда был уверен, что различия там в основном организационные в плане названия команд. Apt объединил в себе возможности apt-get и apt-cache, добавился прогресс бар, и что важно apt list --upgradable.

Я обычно использую apt, потому что короче набирать и в целом удобнее. Оказалось, что команды apt upgrade и apt-get upgrade тоже отличаются. Фактически разницы между apt upgrade и apt full-upgrade нет, а она должна быть. Напомню, что команда upgrade обновляет только текущую версию пакета, ничего не удаляя. В то же время full-upgrade может удалить текущую версию пакета и установить новую. Поэтому эта команда используется при обновлении с релиза на релиз. Там без удаления не обойтись.

А заметил я разницу, когда установил на Debian 12 версию php 8.2 и захотел обновить её до 8.3, подключив сторонний репозиторий. Покажу наглядно по шагам, что сделал.

Сначала полностью обновил систему и установил туда php 8.2 из стандартного репозитория:

# apt update && apt upgrade
# apt install php

Далее подключил репозиторий sury, а точнее его зеркало в домене на su, так как автор ограничил к нему доступ из РФ:

# wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.su/php/apt.gpg
# sh -c 'echo "deb https://packages.sury.su/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'

В репозитории есть версия php 8.3. Пробую обновиться через apt:

# apt update && apt upgrade

Предлагает установить php 8.3 и удалить 8.2:

The following packages were automatically installed and are no longer required:
 libapache2-mod-php8.2 php8.2 php8.2-cli php8.2-common php8.2-opcache php8.2-readline
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
 debsuryorg-archive-keyring libapache2-mod-php8.3 php8.3 php8.3-cli php8.3-common php8.3-opcache php8.3-readline

Делаю full-upgrade:

# apt full-upgrade

Вывод один в один как для upgrade. Предлагает удалить 8.2 и поставить 8.3. Я выполнил обе эти команды и убедился, что результат идентичный. Они отработали обе как full-upgrade. Я получил в системе php 8.3.

Делаю то же самое, только с apt-get:

# apt-get upgrade

The following packages will be upgraded:
 libapache2-mod-php8.2 php8.2 php8.2-cli php8.2-common php8.2-opcache php8.2-readline

Предлагает только обновить 8.2, что от него и ожидаешь. Выполняю full-upgrade:

# apt-get full-upgrade

The following packages were automatically installed and are no longer required:
 libapache2-mod-php8.2 php8.2 php8.2-cli php8.2-common php8.2-opcache php8.2-readline
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
 debsuryorg-archive-keyring libapache2-mod-php8.3 php8.3 php8.3-cli php8.3-common php8.3-opcache php8.3-readline

Вывод такой же, как у apt full-upgrade. То есть в apt-get upgrade и full-upgrade работают ожидаемо, как и описано в документации. А вот с apt мне непонятна ситуация. Не так часто приходится в рамках одной системы переходить на другую ветку ПО, поэтому раньше не обращал на это внимание. А теперь буду.

Вот отличия apt upgrade от apt full-upgrade согласно man:

▪️ upgrade - upgrade is used to install available upgrades of all packages currently installed on the system from the sources configured via sources.list(5). New packages will be installed if required to satisfy dependencies, but existing packages will never be removed.

▪️ full-upgrade - full-upgrade performs the function of upgrade but will remove currently installed packages if this is needed to upgrade the system as a whole.

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

#linux

Познакомлю вас с простым и функциональным DNS сервером с управлением через веб интерфейс. Речь пойдёт о бесплатном Nxfilter. Почему-то вообще не нашёл о нём информации в русскоязычном интернете, кроме каких-то коротких упоминаний.

Кратко опишу возможности этого сервера:

◽️обслуживание dns запросов из локальной сети;
◽️аутентификация пользователей на основе ip адресов, паролей, учётных записей из Active Directory (в том числе прозрачная);
◽️использование готовых списков для запрета доступа к каким-то сайтам, а также создание своих списков;
◽️логирование всех dns запросов;
◽️создание гибких политик доступа к сайтам на основе пользователей, групп пользователей, времени суток;
◽️отчёты и оповещения о событиях фильтрации.

Сам продукт бесплатен, монетизируется за счёт подписок на регулярно обновляемые списки сайтов, разбитых на категории. На них, соответственно, можно не подписываться и использовать программу бесплатно без ограничения. Коммерческое использование допускается. Программа написана на Java, поэтому кроссплатформенна. Можно запускать как на Linux, так и на Windows.

Показываю процесс установки на Debian 12. Устанавливаем Java и sudo (нужен установщику):

# apt install openjdk-17-jdk-headless sudo

Скачиваем пакет и устанавливаем:

# wget https://pub.nxfilter.org/nxfilter-4.7.0.5.deb
# dpkg -i nxfilter-4.7.0.5.deb

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

# systemctl enable --now nxfilter

Служба какое-то время будет создавать свою базу данных и индексы. Наблюдать за процессом можно в логе:

# tail -f /nxfilter/log/nxfilter.log

Как только процесс завершится, можно идти в веб интерфейс по адресу сервера: https://10.20.1.36/admin/ Учётка: admin / admin. Мне почему-то после логина показывалась страница с блокировкой, хотя аутентификация проходила нормально. Я просто открыл страницу https://10.20.1.36/dashboard.jsp и оказался в панели управления. После этого всегда успешно заходил в админку.

Кратко покажу, как тут всё устроено. Для примера добавим пользователя, который будет проходить аутентификацию на основе своего IP адреса, то есть автоматом. Создадим политику, которая будет блокировать доступ к доменам vk.com и ok.com и назначим эту политику этому пользователю.

1️⃣ Идём в раздел DNS ⇨ Setup и указываем DNS серверы, на которые будем перенаправлять запросы. В разделе DNS ⇨ ACCESS CONTROL указываем подсети, для которых будет разрешен доступ к dns серверу. У меня это подсеть 10.20.1.0/24.

2️⃣ Идём в раздел CATEGORY ⇨ CUSTOM и добавляем новую категорию. Я назвал её VK_OK. После создания нажимаем на редактирование и добавляем в список домены для блокировки.

3️⃣ Идём в раздел POLICY ⇨ POLICY и создаём новую политику. Нажимаем на редактирование, переходим на вкладку BLOCKED CATEGORIES и выбираем там созданную ранее категорию.

4️⃣ Идём в раздел USER ⇨ USER и создаём там новый список, открываем на редактирование. В параметре Work-time Policy выбираем созданную ранее политику. Во вкладке ADD IP указываем IP адреса или подсети, которые будут входить в создаваемый список.

5️⃣ Идём в раздел SYSTEM ⇨ SETUP и включаем там параметр Enable User Authentication. Я про него забыл и в итоге ничего не работало.

Вот и всё. Я довольно быстро разобрался, просто потыкав веб интерфейс. Там всё интуитивно понятно, плюс многие параметры описаны. Теперь пользователь из списка при открытии заблокированных сайтов будет перенаправлен на внутреннюю страницу. Она может быть настроена. Он увидит предупреждение о недоверенном TLS сертификате, так как по умолчанию используется самподписанный. На самой странице с редиректом будет указано, что данный сайт заблокирован, так как входит в соответствующий список.

Такой вот относительно простой и эффективный способ блокировки доступа к сайтам на основе фильтрации DNS запросов. Помимо этого nxfilter всё логирует, собирает статистику, выводит её на дашборд, формирует отчёты. В общем, функциональная и удобная программа.

⇨ Сайт

#dns

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

Покажу сразу очень наглядный пример:

# echo --version
--version

# /usr/bin/echo --version
echo (GNU coreutils) 9.1

В первом случае ключ не сработал, а во втором сработал, хотя запускал вроде бы одно и то же. А на самом деле нет. В первом примере я запустил echo из состава оболочки bash, а во втором случае - это бинарник в файловой системе. Это по факту разные программы. У них даже ключи разные.

Узнать, что конкретно мы запускаем, проще всего через type:

# type echo
echo is a shell builtin

# type /usr/bin/echo
/usr/bin/echo is /usr/bin/echo

В первом случае прямо указано, что echo - встроена в оболочку.

И ещё один очень характерный пример:

# type ls
ls is aliased to `ls --color=auto'

Очень часто ls это не утилита ls, а алиас с дополнительными параметрами.

Когда вы вводите команду в терминал, происходит следующее:

1️⃣ Проверяются алиасы. Если команда будет там найдена, то поиск остановится и она исполнится.

2️⃣ Далее команда проверяется, встроена в ли она в оболочку, или нет. Если встроена, то выполнится именно она.

3️⃣ Только теперь идёт поиск бинарника в директориях, определённых в $PATH.

У последнего варианта тоже есть свои нюансы. У вас может быть несколько исполняемых файлов в разных директориях с одинаковым именем. Ситуация нередкая. Можно столкнуться при наличии разных версий python или php в системе. Поиск бинарника ведётся по порядку следования этих директорий в переменной слева направо.

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Что раньше будет найдено в директориях, определённых в этой строке, то и будет исполнено.

И ещё важный нюанс по этой теме. Есть привычные команды из оболочки, которых нет в бинарниках. Например, cd.

# type cd
cd is a shell builtin

# which cd

В выводе последней команды пусто, то есть бинарника cd нет. Если вы будете использовать cd в скриптах, то проблем у вас не будет, так как там обычно в шебанге указан интерпретатор. Обычно это bash или sh, и там cd присутствует.

А вот если вы cd используете в юните systemd, то ничего не заработает:

ExecStart=cd /var/www/ ....... && .........

Вот так работать не будет. Systemd не будет запускать автоматом оболочку. Надо это явно указать:

ExecStart=/usr/bin/bash -с "cd /var/www/ ......."

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

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

#bash #terminal

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

Radmin VPN — приложение только под Windows. После установки оно создаёт новое сетевое соединение, подключается к своему серверу, назначает компьютеру серый IP адрес с маской 255.0.0.0. Далее вы можете создать локальную сеть, закрытую отдельным паролем и собирать в эту сеть подключенные компьютеры.

Я проверил, как это работает. Установил Radmin VPN на 3 машины: Win10, Win11, WinSRV2019. Добавил их в единую сеть. Они сразу же увидели друг друга: стали пинговаться по своим серым адресам, заработал доступ к файлам через \\26.210.121.198\c$, подключение по RDP. Никаких настроек делать не пришлось, кроме подключения к созданной сети через клиента Radmin VPN. Сам софт доступен без регистрации и каких-то дополнительных действий.

Не знаю, насколько это безопасный способ подключения. Я так понял, что все клиенты этой сети сидят в общем адресном пространстве 26.0.0.0 с маской 255.0.0.0. Вы можете создавать публичные сети для совместной онлайн игры. Посмотрел на доступный список подобных сетей. Их очень много на разных языках. То есть продуктом реально пользуются по всему миру. Зашёл в одну такую публичную сеть - стал видеть все компы из этой сети по их серым IP адресам. Они видны, так как все участники сети отображаются в общем списке. Как только из общей сети выходишь, доступ к её членам по IP пропадает.

В целом, не вижу тут каких-то серьёзных сетевых проблем, если настроить файрвол и разрешить доступ только со своих серых IP адресов. Они статичны. Можно разрешить только те протоколы, что вам нужны. Например, RDP. У него своё шифрование, так что можно спокойно пользоваться поверх любых сетей.

А так в целом продукт очень простой для использования. Будет удобно для тех, кто не хочет или не может, не умеет, настраивать свои VPN серверы. Можно детей научить пользоваться, чтобы играли с приятелями в онлайн игры. Тот же Minecraft.

⇨ Сайт

Помимо Radmin VPN у этой компании есть ещё два неплохих бесплатных продукта для сисадминов, работающих с локальными сетями и пользователями:

▪️ Advanced IP Scanner
▪️ Advanced Port Scanner

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

#vpn

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

Порядок настройки следующий:

1️⃣ Сохраняю список правил в файл /etc/iptables.sh. Адаптирую под текущие условия гипервизора: меняю имена сетевых интерфейсов, IP адреса. Делаю его исполняемым. Обычно сразу же проверяю, просто запустив его.

# mcedit /etc/iptables.sh
# chmod +x /etc/iptables.sh
# bash /etc/iptables.sh
# iptables -L -v -n

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

2️⃣ Убеждаюсь, что после выполнения скрипта появился файл-экспорт с набором правил /etc/iptables.rules. Добавляю применение правил в файл /etc/network/interfaces:

iface enp5s0 inet manual
post-up iptables-restore < /etc/iptables.rules

Вешаю загрузку правил iptables на поднятие wan интерфейса.

3️⃣ Перезагружаю сервер и убеждаюсь, что всё нормально поднимается, правила применяются, доступ к серверу у меня есть.

4️⃣ Если нужно добавить или изменить какое-то правило, то правлю файл iptables.sh, а когда закончу, запускаю его. Он обновляет набор правил в iptables.rules, так что после перезагрузки хоста изменённые правила сохранятся.

Если у вас хост Proxmox выполняет роль шлюза, то не забудьте проверить, что параметр net.ipv4.ip_forward=1 активен в /etc/sysctl.conf. Без него NAT для виртуалок не заработает. Точнее не сам нат, а передача пакетов между локальным и wan интерфейсом. Если в качестве шлюза для VM выступает отдельная VM, то как минимум из набора правил исчезает NAT и всё, что касается локалки и проброса портов. А на шлюз уезжает этот же шаблон с правилами и там правится по месту.

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

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

#proxmox #iptables

Git - довольно замороченная система контроля версий. Не очень понятно, за что она завоевала такую популярность. Разобраться с ней - пуд соли съесть. Какие-то самые простые вещи делать не сложно. А вот если чуть копнуть, то там тёмный лес.

Об этом тёмном лесе даже сайт замутили с говорящим названием - ohshitgit.com. В англоязычном интернете он довольно популярен. Не раз видел на него ссылки. У нас особо не встречал. Есть две русские версии этого сайта.

⇨ Одна матерная - https://ohshitgit.com/ru
⇨ Вторая без мата - https://dangitgit.com/ru

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

📌 Журнал всех действий в репозитории:
# git reflog
Откатится на какое-то событие из этого списка:
# git reset HEAD@{index}

📌 Добавить что-то в уже созданный коммит:
# git add .
# git commit --amend --no-edit

📌 Изменить сообщение последнего коммита:
# git commit --amend

📌 Перенести последний коммит из мастер ветки в новую ветку:
# git branch какое-то-имя-новой-ветки
# git reset HEAD~ --hard
# git checkout какое-то-имя-новой-ветки

📌 Отменить коммит, который был 5 коммитов назад:
# git log
# git revert [сохранённый хеш]

📌 Отменить изменения в файле:
# git log
# git checkout [сохранённый хеш] -- путь/к/файлу
# git commit -m "Ого, теперь не придётся копипастить, чтобы отменить изменения!"

Для тех, кто не видел, оставлю ссылку на публикацию с подбором хороших обучающих материалов по git:

🎓 Подборка бесплатных материалов по GIT

#обучение #git

В выходные прочитал интересную статью:

⇨ Как настроить веб-приложение под высокие нагрузки

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

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

Изначально это был небольшой проект на PHP и его фреймворке Symfony, который писали 3-5 проектировщиков. СУБД была PostgreSQL, под кэш Redis, написана API и очередь для неё на RabbitMQ. Такое типовое классическое веб приложение. Проект располагался на 16 физических серверах, фронтенды и бэкенды — по 24 ядра и 128 ОЗУ каждый, ноды СУБД имели 56 ядер и 512 ГБ ОЗУ.

Огромную помощью в решении возникающих проблем оказывал мониторинг. Он был реализован на базе Zabbix, Symfony Profiler, Cockpit, DBeaver, Nginx Amplify.

🔹Одним из узких мест оказались логи Nginx. Была включена буферизация логов. В момент скидывания буферов на диск, они тормозили. Временно перенесли логи в RAM-диски (tmpfs). Потом перенастроили систему хранения логов.

🔹Другим узким местом была главная страница. Её целиком закешировали и поместили в Redis. Далее весь код перетряхнули и по возможности настроили использование кэша в Redis. После этого Redis вынесли в отдельный кластер. Это привело к тому, что даже в границах одной серверной и максимально быстрой сети, кэш стал работать медленнее, а на саму локалку сильно выросла сетевая нагрузка. Пришлось разбить кэш на 2 уровня. Первый хранить в локальных инстансах Redis, а второй в отдельном кластере с доступом по сети.

🔹Для разгрузки СУБД установили PgBouncer для управления пулом соединений, постановки их в очередь, если всё занято. Один огромный сервер под СУБД распили на кластер из 5-ти серверов. Запросы к кластеру стали распределять с помощью PGPool. INSERT, UPDATE, DELETE отправляли на Master, всё остальное распределяли между остальными серверами.

🔹В какой-то момент все серверные мощности были нагружены на 70-80%. Это стало приводить к проблемам, когда что-то из железа выходило из строя. Пришлось добавить серверов, чтобы нагрузка стала 40-50%.

🔹Далее упёрлись в ёмкость входного канала. Пришлось переходить на использование геораспределённой CDN.

#perfomance

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

⇨ Топ 10 программ для инвентаризации оборудования

В ней перечислены следующие программы:

◽GLPI
◽Snipe-IT
◽Tactical RMM
◽Ralph
◽ITop
◽NetBox
◽I-doit
◽Lansweeper
◽Algorius
◽Spiceworks
◽DataGerry

Насколько я знаю, самым популярным и функциональным является GLPI. Несмотря на то, что это очень старый продукт, написанный на PHP, он продолжает развиваться: большая активность на github, регулярно выходят новые релизы. Есть свой агент для сбора данных с управляемых систем. Дополнительно можно развернуть HelpDesk систему. Причём она там не для галочки, а вполне функциональна. Есть встроенная база знаний, учёт финансов, серверных стоек и много что ещё.

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

Я сходу не нашёл чего-то интересного, чем можно было бы дополнить список из того, о чём ещё не писал. Может кто-то из вас успешно использует что-то другое? Или просто хочет поделиться известной программой на эту тему. Напишите о них в комментариях. Я посмотрю, напишу заметки и дополню подборку как тут в Telegram, так и на сайте.

#управление #ITSM #подборка

🦖 Selectel — дешёвые и не очень дедики с аукционом!