Я обновил популярную подборку со своего сайта:

⇨ Топ бесплатных программ для бэкапа

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

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

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

Если считаете, что какой-то полезной программы не хватает, пишите в комментариях здесь или на сайте. Я буду дополнять. В этом обновлении добавил туда ElkarBackup, FBackup. Почему-то их там не было. До этого добавлял ReaR и Restic, но анонса не делал.

#backup #подборка

​​Когда готовил материал по отправке email сообщений через curl, подумал, он же наверное и читать умеет. И не ошибся. Curl реально умеет читать, и не только, почту по imap. Это открывает очень широкие возможности по мониторингу почтовых серверов с помощью утилиты.

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

Но с curl всё получается намного проще. Она много чего умеет. Расскажу по порядку. Сразу важная сноска, которая сильно затормозила меня в этом вопросе. Когда будете пробовать, возьмите свежую версию curl. Более старые некоторые команды для imap не поддерживают. Я сначала наткнулся на это в старом сервере Centos 7. Потом уже перешёл на современный Debian и там всё получилось.

Сразу перенесём логин с паролем в отдельный файл ~/.netrc:

machine mail.server.tld login username password supersecretpw

Проверяем количество сообщений в imap папке INBOX:

# curl "imap:/mail.server.tld" -n -X 'STATUS INBOX (MESSAGES)'
* STATUS INBOX (MESSAGES 405)

Получили число 405. Посмотрим, сколько из них непрочитанных:

# curl "imap://mail.server.tld" -n -X 'STATUS INBOX (UNSEEN)'
* STATUS INBOX (UNSEEN 147)

147 непрочитанных сообщений. Думаю, идею вы поняли. С помощью curl можно напрямую передавать серверу команды imap.

Смотрим список директорий в ящике:

# curl "imap://mail.server.tld" -n -X 'LIST "" "*"'
* LIST (\HasNoChildren \Marked \Trash) "/" Trash
* LIST (\HasNoChildren \UnMarked \Junk) "/" Junk
* LIST (\HasNoChildren \UnMarked \Drafts) "/" Drafts
* LIST (\HasNoChildren \Sent) "/" Sent
* LIST (\HasChildren) "/" INBOX

Или просто:

# curl "imap://mail.server.tld" -n

Ищем в ящике письма с темой test:

# curl "imap://mail.server.tld/INBOX?SUBJECT%20test" -n
* SEARCH 62 404 405 406
или так:
# curl "imap://mail.server.tld/INBOX" -n -X 'SEARCH HEADER Subject test'

Сообщения от определённого адресата:

# curl "imap://mail.server.tld/INBOX" -n -X 'SEARCH From vladimir@zeroxzed.ru'
* SEARCH 292 404 405 406

Получили UIDs писем. Смотрим содержание письма с конкретным UID. Для этого надо добавить ключ -v, так как оно передаётся в отладочной информации, как и все остальные ответы сервера:

# curl -v "imap://mail.server.tld/INBOX" -n -X 'FETCH 406 BODY[TEXT]'
или так:
# curl -v "imap://mail.server.tld/INBOX;UID=406/;BODY=TEXT" -n

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

Команды imap рассмотрены в упоминаемом недавно курсе по сетям от Созыкина Андрея. Вот конкретный урок: ▶️ Протокол IMAP. Вообще, было интересно во всём этом разобраться. Если надо будет настроить мониторинг очередного почтового сервера, попробую что-то применить с помощью curl.

Первое, что приходит в голову в плане мониторинга - отправлять письмо с меткой времени в теле, а потом забирать его и анализировать эту метку. Если метка старая, значит письма не ходят. Это надёжнее, чем просто проверять статус служб и доступность портов. Тут и smtp, и imap сервер проверяются. И реализуется полностью с помощью curl и zabbix.

#curl #terminal

​​Те, кто сталкивался с настройкой VoIP телефонии, наверняка знают, что такое протокол и сервер STUN. Там постоянно приходится с ним взаимодействовать. Не припомню, где он использовался ещё. Но последнее время в связи с развитием протокола WebRTC, а также программных средств для видеоконференций на его основе, тема снова стала актуальной, даже ещё больше, чем с VoIP. Кратенько своими словами расскажу, что такое STUN и TURN.

Протокол STUN и сервера на его основе решают очень простую задачу. Позволяют клиентам за NAT узнать свой внешний IP адрес и порт, с которого ушёл запрос, чтобы организовать соединение к себе для прохождения голосового или видео потока. Клиент делает запрос на внешний сервер STUN, а тот ему отвечает, что запрос был сделан с такого-то IP и порта. Клиент передаёт эту информацию тому, кто хочет с ним соединиться.

Дополнением протокола STUN стал TURN. Он включает в себя возможности STUN, но и добавляет новые. В зависимости от настроек NAT на конкретном шлюзе, не всегда можно пробиться к клиенту извне. Данные, которые передаст STUN сервер клиенту, будут актуальны только для подключения этого STUN сервера, но не других клиентов. Шлюз просто отбросит от них соединения. Отдельная проблема, когда оба клиента за таким NAT.

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

Наиболее известной бесплатной реализацией TURN сервера является Coturn, который можно развернуть у себя. При этом в сети довольно много и бесплатный серверов, которые реализуют возможности этих протоколов. Например, известный STUN сервер от гугла - stun.l.google.com. Можно использовать для каких-то своих задач. TURN полностью бесплатный вряд ли можно найти. За это уже деньги надо платить, но есть сервисы с ограниченными бесплатными тарифными планами.

Проверить работу STUN и TURN серверов можно с помощью публичного сервиса:
⇨ https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

Указываете адрес сервера в формате stun:stun.l.google.com:19302 и запускаете проверку. Наглядно видно, что возвращает STUN сервер - внешний IP адрес и порт.

▶️ Вот тут на индусском английском рассказано с картинками то, что я описал.

#voip #webrtc

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

⇨ https://iknowwhatyoudownload.com

Указываете свой IP адрес и наблюдаете свои раздачи. У меня дома статика много лет. Сервис видит всё, что я раздаю. Причём информация очень свежая. У меня много раздач. Постоянно что-то детям качаю - фильмы, сказки, мультики и т.д. Обычно оставляю их на раздаче, не удаляю. Так вот, они там все.

Потыкал там случайные айпишники. Чего только нет - фильмы, игры, софт, xxx и т.д. В общем, имейте ввиду, что все ваши торренты на виду.

#разное

​​Я уже делал серию заметок про CIS (Center for Internet Security). Это некоммерческая организация, которая разрабатывает собственные рекомендации по обеспечению безопасности различных систем. Я проработал рекомендации для:

- Nginx
- MySQL 5.7
- Apache 2.4
- Debian 11
- Docker
- Ubuntu 22.04 LTS

Основная проблема этих рекомендаций - они составлены в огромные pdf книги, иногда до 800 страниц и покрывают очень широкий вектор атак. Выбрать из них то, что вам нужно, довольно хлопотно. Я выделяю основные рекомендации, которые стоит учесть при базовом использовании стреднестатиcтической системы. В этот раз разобрал рекомендации для PostgreSQL 16.

🔹Убедитесь, что настроено логирование ошибок. Задаётся параметром log_destination. По умолчанию пишет в системный поток stderr. Считается, что это ненадёжный способ, поэтому рекомендуется отдельно настроить logging_collector и отправлять логи через него. По умолчанию он отключен. Если настроено сохранение логов в файлы, то не забыть закрыть доступ к ним и настроить ротацию средствами postgresql (log_truncate_on_rotation, log_rotation_age и т.д.)

🔹Для повышения возможностей аудита имеет смысл включить логирование подключений и отключений клиентов. Параметры log_connections и log_disconnections. По умолчанию отключено.

🔹Если вам необходимо отслеживать активность в базе данных, то имеет смысл настроить параметр log_statement. Значение ddl позволит собирать информацию о действиях CREATE, ALTER, DROP.

🔹Для расширенного аудита используйте отдельный модуль pgAudit. Обычно ставится в виде отдельного пакета. Для расширенного контроля за действиями superuser используйте расширение set_user.

🔹Если есть необходимость работать с postgresql в консоли, установите и настройте утилиту sudo, чтобы можно было контролировать и отслеживать действия различных пользователей.

🔹Рекомендованным методом аутентификации соединения является scram-sha-256, а не популярный md5, у которого есть уязвимость (it is vulnerable to packet replay attacks). Настраивается в pg_hba.conf.

🔹Настройте работу СУБД на том сетевом интерфейсе, на котором она будет принимать соединения. Параметр listen_addresses, по умолчанию указан только localhost. Если используется внешний сетевой интерфейс, не забудьте ограничить к нему доступ средствами firewall.

🔹Если есть необходимость шифровать TCP трафик от и к серверу, то не забудьте настроить TLS. За это отвечает параметр hostssl в pg_hba.conf и параметры ssl, ssl_cert_file, ssl_key_file в postgresql.conf. Поддерживается работа с self-signed сертификатами.

🔹Для репликации создавайте отдельных пользователей. Не используйте существующих или superuser.

🔹Не забудьте проверить и настроить создание бэкапов. Используйте pg_basebackup для создания полных бэкапов и копии WAL журналов для бэкапа транзакций.

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

Сам файл с рекомендациями живёт тут. Для доступа нужна регистрация.

#cis #postgresql

Посмотрел вчера свежий обзор домашней лаборатории известного англоязычного IT блоггера Techno Tim:

▶️ HomeLab Hardware Tour! (Late 2023)

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

В видео больше всего понравилась идея со стеной. Удобно сделано. Можно крепить туда всё, что угодно. Весь негабарит, который в стойке будет просто валяться на полках. Также понравилась идея с кластером на Intel NUC и его расположение в стойке. Для домашних тестовых лабораторий, как по мне, идеальное решение, которое не шумит и не потребляет лишнее электричество. Подойдут любые неттопы.

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

А у вас есть своя домашняя серверная? Хоть какая. Если есть желание и возможность, то покажите фотки. Интересно посмотреть.

#видео

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

🎓 Базовое администрирование Linux:
▪️ Основы GNU/Linux и подготовка к RHCSA — автор в качестве хобби создаёт хорошие курсы для новичков. Причём как в текстовом виде, так и в виде записанных уроков. Качество материала высокое.
▪️ Базовое администрирование Linux-серверов — бесплатный курс по основам от Слёрм.
▪️ Введение в Linux — большой и масштабный бесплатный курс по Linux на платформе Stepik.
▪️ Администрирование Linux — совместный курс в виде лекций на youtube от команды VK Team на базе МФТИ.
▪️ Администрирование базового уровня (LPIC-1) - курс на youtube от известного Семаева Кирилла, который к сожалению больше не в состоянии записывать курсы.

🎓 Сети:
▪️ Сети для самых маленьких — очень качественный, структурированный материал по сетям от самых основ до более сложных вещей. Написано, как я понимаю, энтузиастами-сетевиками из подкаста Linkmeup.
▪️ Компьютерные сети, Климанов М.М., Компьютерные сети, учебный курс, Созыкин Андрей — база по сетям от преподавателей МФТИ.
▪️ Основы документирования сетей — серия уроков на youtube по документированию сетей.

🎓 GIT:
▪️ Git для начинающих — бесплатный курс по основам от Слёрм.
▪️ Oh My Git! — одна из самых известных и популярных игр на тему изучения Git.

🎓 Базы данных:
▪️ Введение в базы данных - бесплатный курс на Stepik.
▪️ Интерактивный тренажер по SQL - тоже курс на Stepik.

🎓 DevOps:
▪️ 90DaysOfDevOps — сборник из 90 шагов, разбитых на 90 дней для развития в области DevOps. Язык материала - английский.
▪️ Как стать DevOps Инженером с Нуля, что учить и в каком порядке —интересное видео от человека, который вкатился в DevOps в 30+ лет. Рассказывает свой опыт.
▪️ Онлайн тренажёры от RedHat — интерактивные уроки, где воспроизводят полностью рабочую среду разработчика или devops инженера. 

🎓 Docker:
▪️ Основы Docker - хорошее обучающее видео по Docker для новичков.
▪️ Play-with-docker - онлайн тренажер для изучения Docker.

🎓 Kubernetes:
▪️ Полный видеокурс по Kubernetes из 22 обучающих уроков - там вообще всё от нуля до мониторинга и деплоя приложений.
▪️ Play-with-k8s - онлайн платформа для изучения Kubernetes.

Это всё, что нашёл более ли менее целостное и полезное. Если есть чем дополнить, поделитесь в комментариях. Я публикацию буду обновлять и в будущем ссылаться на неё.

#обучение #подборка

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

⇨ https://www.linuxatemyram.com

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

🟢Что вообще происходит?
Linux использует свободную память для кэширования дисковых операций. Это создаёт впечатления, что свободной памяти нет, но это не так.

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

🟢Что произойдёт, если запустить ещё больше программ?
Если вашим программам понадобится память, они просто получат её из занятой под дисковый кэш. Кэш моментально отдаёт занятую память. Реальной нехватки памяти не возникнет.

🟢Нужно ли добавить swap?
Нет, под кэш уходит только та память, что в данный момент свободна. Она не связана со swap. Если приложениям нужна дополнительная память, занятая под кэш, они берут её там, но не уходят в swap.

🟢Как мне отключить дисковый кэш?
Вы не сможете отключить подобное кэширование. Единственная причина, по которой может появиться подобное желание - ошибочное мнение о том, что память расходуется ненадлежащим образом, а приложениям её не хватает. На самом деле этот кэш ускоряет работу приложений, поэтому отключать его нет никаких оснований. Тем не менее, если вы захотите быстро очистить часть оперативной памяти, занятой кэшем для каких-то своих задач, то сможете сделать это командой: echo 3 | sudo tee /proc/sys/vm/drop_caches

🟢Почему top и free показывают, что вся оперативная память используется, если это не так?
Это просто разница в терминологии. И вы, и Linux согласны с тем, что память, занимаемая приложениями, является "используемой", в то время как память, которая ни для чего не используется, является "свободной". Но как вы назовёте память, которая в данный момент используется для чего-то, но все еще может быть доступна приложениям? Вы можете считать эту память "свободной (free)" и/или "доступной (available)". Linux же считает ее "используемой (used)", но также и "доступной (available)".

🟢Как мне узнать, сколько у меня на самом деле свободной оперативной памяти?
Запустите утилиту:
# free -m
total used free shared buff/cache available
Mem: 1504 1491 13 0 855 792
Swap: 2047 6 2041

Если посмотреть на столбец free, то покажется, что свободной памяти не осталось. Но это не так. На самом деле для приложений доступно 792 MiB, а под кэш и буфферы занято 855 MiB, большая часть из которой может быть выделена для приложений. То есть у вас реально занято примерно 50% памяти и столько же доступно/свободно.

На самом деле простое и доступное объяснение. Ссылочку можно сохранить для друга, который не понимает, как Linux использует память. Для него памяти чем больше, тем лучше. То есть лишней она не бывает. За скобками осталась тема того, как определить реальную используемую память приложением или процессом. Для этого тоже можно отдельный сайт открыть. Я попытался объяснить эту тему в заметке про pmap.

◽Уменьшение или увеличение ram на ходу
◽Анализ использования памяти с помощью pmap
◽Кто и как использует swap (скрипт для просмотра)
🔥Использование оперативной памяти программами (скрипт)

#linux

​​Я не раз поднимал на канале тему видеонаблюдения, преимущественно бесплатного и на Linux. При этом всё время обходил стороной старый российский проект Xeoma, у которого давняя история (с 2004 года) и много хороших отзывов. Я просто сам ни разу с ним не сталкивался, нигде не видел и не настраивал. А это один из старых серверов, у которого очень давно есть версия под Linux.

Я лично настраивал программные сервера видеонаблюдения от брендов LTV и Линия, а настроенных видел ещё больше. В целом, не могу сказать что-то плохое про кого-то из них. Всё, что касается базового видеонаблюдения, работает нормально плюс-минус у всех. Конкретно к LTV и Линии у меня претензий нет. Всё это был софт на Windows. Сейчас я знаю, что Линия активно развивает свой сервер на Linux.

У Xeoma есть сервер видеонаблюдения под Linux (в том числе под архитектуру ARM) и Android(❗️). Причём как с графической оболочкой, так и без. Если устанавливать на сервер с графической оболочкой, там же будет установлен и клиент для настройки и управления. Если сервер без графики, то ставится только серверная часть, а клиент в любое другое место, например на систему с ОС Windows или на смартфон. Версии ОС клиента и сервера могут не совпадать.

Сервер распространяется в формате AppImage, то есть одиночный файл с расширением .app. Установка простая и быстрая, описана в документации. Просто запускаем сервер с ключами и подключаемся к нему клиентом для настройки.

У Xeoma есть бесплатная версия с ограниченной функциональностью. Основное ограничение - только 4 камеры для записи в архив и хранение в архиве - 5 дней. Подключать и просматривать в режиме реального времени можно сколько угодно. То есть это вариант для небольшой дачи или квартиры. Для доступа к своему серверу можно использовать сервис Ретранслятор. Подробно возможности бесплатной версии описаны в статье.

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

Думаю, в комментариях найдётся много тех, кто использует данный сервер. Я постоянно видел его упоминание.

#видеонаблюдение #отечественное

​​У меня до сих пор осталось некоторое количество серверов под управлением Centos 7. Совсем уже отвык от этой системы. Последние пару лет все новые сервера только Debian. Соответственно, они уже почти везде. Где-то делал миграцию с Centos на Debian, но Centos всё равно остались. Всё работает, обновления приходят, поэтому нет смысла суетиться и делать лишнюю работу.

Поддержка Centos 7 закончится 30 июня 2024 года. В принципе, ещё есть время подготовиться. Но тут основной вопрос, на какую систему в итоге перейти. Когда конвертировал 8-ю версию, как раз пару лет назад, выбрал Oracle Linux и сконвертировал системы в него. Думаю, что ошибся, надо было на AlmaLinux переходить. В тот момент не был уверенности, что этот форк получит хорошее развитие. К примеру, анонсированный VzLinux от Virtuozzo в итоге быстро стух и больше не развивается. По факту AlmaLinux стал наиболее распространённым форком. А вы что думаете на этот счёт?

Если решите в итоге Centos 7 сконвертировать в AlmaLinux, то у них есть хорошая инструкция, как получить сразу актуальную 9-ю версию. Я проверил, получилось без проблем. Я скорее всего на этом варианте остановлюсь. Только обязательно тестируйте такое обновление, так как 9-я версия требует дополнительный набор процессорных команд, обозначаемых как x86-64-v2 (SSE4.2, SSSE3, POPCNT и возможно что-то ещё). Иногда может потребоваться дополнительная настройка виртуальных машин. Хорошо, если гипервизор свой. А если арендованный, то обновление не установится. Не пройдёт проверку требований к железу. В PVE достаточно тип процессора с kvm64 заменить на host. Это актуально для всех форков RHEL9.

#centos #almalinux

​​У меня дома есть NAS и на всех компах и ноутах подключены сетевые папки. Домашние слабо представляют, как всё это работает. На смартфоне использую TotalCommander с плагином для доступа к тем же сетевым папкам. Жена наверное через TG или VK перекидывает файлы. По-другому вряд ли умеет. Детям это пока не надо.

Есть простое и удобное open source решение для этого вопроса - LocalSend. Поддерживает все операционные системы, в том числе на смартфонах. Это небольшое приложение, которое запускается на определённом порту (53317), принимает входящие соединения и с помощью нескольких методов (описание протокола, в основе поиска Multicast UDP, если не помогает, то POST запрос на все адреса локальной сети) осуществляет поиск таких же серверов в локальной сети. Передача данных осуществляется по протоколу HTTP.

На практике всё это работает автоматически. Приложение под Windows можно поставить, к примеру, через wingwet или скачать portable версию. На смартфоне ставим через Google Play, F-Droid или просто качаем apk. Работает всё в локальной сети, без необходимости каких-то внешних сервисов в интернете. Запускаем на обоих устройствах приложение, они сразу же находят друг друга. Можно передавать файлы. При этом можно на том же компе настроить такой режим, чтобы он автоматом принимал файлы со смартфона и складывал в определённую директорию.

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

Мне иногда надо сыну передать со своего смартфона из родительского чата информацию от учителя с пояснениями по домашке. Я для этого делал скриншот чата, клал его на NAS, на компе с NAS копировал сыну. Через приложение передать в разы удобнее. Запустил прогу и перекинул на комп с именем СЫН. Всё. Мессенджеров и соц. сетей у него пока нет.

Это приложение, которое я попробовал и сразу развернул на всех устройствах. Жене очень понравилось.

Отдельно отмечу, что приложение написано на языке программирования Dart. Впервые о нём услышал. Сначала показалось, что это типичное приложение на JavaScript под NodeJS. Но смутил небольшой размер. После этого и пошёл смотреть, на чём написано. Оказалось, что этот язык программирования разрабатывает Google как раз для замены JavaScript, взяв от него всё лучшее, но исправив недостатки. В целом, выглядит всё это неплохо.

⇨ Сайт / Исходники

#fileserver

​​Один из читателей канала давно мне скидывал информацию про скрипт для Zabbix, который отправляет оповещения с графиками в Telegram. Он его сам написал. У меня как-то затерялась эта информация и только сейчас дошли руки посмотреть. Я проверил, всё работает нормально. В целом, таких скриптов немало, я сам пользуюсь и в статье рассказываю про настройку. Тут отличие в том, что он полностью на Bash, в то время как я использую решения, написанные на Python. Вариант с башем лично для мне выглядит более привлекательным.

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

Отмечу несколько моментов, с которыми сам столкнулся.
1️⃣ Скрипт по умолчанию пишет лог файл в директорию /usr/lib/zabbix/alertscripts, владельцем которой является root, соответственно у скрипта нет прав на запись туда. Либо сделайте владельцем пользователя Zabbix, либо вынесите лог куда-то в другое место.

2️⃣ Второй момент - когда будете добавлять новый способ оповещений (media type), не забудьте добавить туда шаблоны. По умолчанию они не создаются. Я забыл об этом и не сразу догадался, почему ошибку при отправке через этот тип сообщений получаю.

3️⃣ Для айтема должен существовать график, чтобы он прилетел в оповещения. Иначе графика не будет. Если что-то не будет получаться, то почитайте комментарии к статье. Там автор подробно объясняет нюансы и показывает, как дебажить отсутствие графиков

#zabbix

​​Заметка для тех кому приходится разбираться на чужих серверах или перенимать полностью управление в свои руки. Для deb дистрибутивов есть инструмент debsums, живёт в базовых репах:

# apt install debsums

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

А вот проверить конкретно изменения в стандартных конфигурационных файлах бывает очень полезно. Например, если кто-то изменял стандартный конфиг /etc/ssh/ssh_config или /etc/default/ssh, то вы это увидите:

# debsums --config --changed
/etc/ssh/ssh_config
/etc/default/ssh

И так для всех стандартных конфигов, которые идут в составе пакетов, в том числе которые устанавливаются с базовой системой. Юниты systemd, конфиги в /etc/pam.d, /etc/grub.d, /etc/defaults и т.д. Всё будет проверяться.

Простой и удобный инструмент для того, чтобы быстро оценить, что на сервере менялось и настраивалось. Увидите в том числе изменённые конфиги установленного софта, типа nginx или mariadb. То есть сразу будет видно, что сюда ставили и настраивали.

#debian

​​Я по привычке всегда создаю ключи для SSH с использованием протокола RSA. Просто добавляю параметр для длины ключа 4096. Когда-то увидел информацию, что меньшая длина теоретически может быть небезопасной.

# ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)_$(date -I)"

OpenSSH сервер в очередном обновлении отказался от коротких RSA ключей: "Refuse RSA keys <1024 bits in length and improve reporting for keys that do not meet this requirement.". А не так давно от него было предупреждение: "use RSA/SHA256 when testing usability of private keys as some systems are starting to disable RSA/SHA1 in libcrypto." Это всё информация из releasenotes.

Криптография не стоит на месте и постоянно развивается. Появился протокол Ed25519, который сейчас многие сервисы рекомендую использовать для SSH ключей, а если видят RSA, то выводят предупреждение. Не вижу причин его не использовать. Надо менять привычки.

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

# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -C "$(whoami)@$(hostname)_$(date -I)"

# cat id_ed25519
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZWQyNTUxOQAAACAhQeOKKXennY4AxzG27R5F+8uiQiuBPDil8RNUaisnjwAAAKCDHZihgx2YoQAAAAtzc2gtZWQyNTUxOQAAACAhQeOKKXennY4AxzG27R5F+8uiQiuBPDil8RNUaisxjwAAAECp2CJm9zWAsi9TQ/T92h6maR7CkeZyXlR1EOC9IecDvCFB44opd6edjgDHMbbtHkX7y6JCK4E8OKXxE1RqKzGPAAAAGHJvb3RAZGViaWFuMTFfMjAyMy0xMi0yMAECAwQF
-----END OPENSSH PRIVATE KEY-----

# cat id_ed25519.pub 
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICFB44opv6edjgDHMbbtHkX7y6JCK4E8OKXxE1RqKzGP root@debian11_2023-12-20

Публичные ключи Ed заметно короче RSA, что банально практичнее. Они содержат всего 68 символов, в отличие от RSA 3072 с их длиной 544 символа.

Кто-то уже перешёл на Ed25519? Там нет каких-то подводных камней, в виде отсутствия поддержки в каком-то софте? По идее, такого уже не должно быть, так как алгоритм появился довольно давно. Хотя какой тут софт может быть? Подавляющее число подключений по SSH, это подключения к openssh серверу, который с 15-го года поддерживает Ed25519. Наиболее вероятно, что проблемы могут возникнуть на каком-то старом сетевом оборудовании, где версия openssh очень старая.

#ssh

​​Zabbix последнее время не сильно радует новостями или какими-то событиями. Как-будто у компании проблемы. Раньше регулярно были рассылки с множеством событий: обновления, статьи в блоге, ролики в ютубе, новые шаблоны, вебинары и т.д.

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

✔️ Рассказывают, что реализовали возможность передавать параметры к скриптам прямо из веб интерфейса. Если я правильно понял, то можно добавить какой-то скрипт, к примеру, для перезапуска службы. В случае необходимости, можно через веб интерфейс к нему обратиться и передать что-то в качестве параметра. Например, адрес сервера и/или имя службы. И скрипт выполнит перезапуск на целевом сервере. Подробного описания нет. Свою интерпретацию сделал на основе вот этих строк: "The latest alpha release introduces the ability to pass custom input to frontend scripts, enabling many new host administration scenarios directly from the Zabbix frontend." и картинки, что будет в конце публикации.

✔️ Посмотрел список остальных нововведений. Понравился новый тип проверки net.dns.perf. С его помощью можно проверять DNS записи. Это полезная штука, так как зачастую изменение записей может обрушить всю систему. За этим важно следить.

✔️ Ещё из полезного - добавили возможность пушить метрики через Zabbix API. Раньше для этого можно было только zabbix_sender использовать. Теперь можно без него обойтись. Это позволит быстро и просто передавать метрики из других систем через их вебхуки. В будущем обещают виджет на дашборд для ввода метрик вручную. Это, кстати, было бы полезно. Сейчас нет простых способов передать вручную в айтем значение.
▶️ Zabbix 7.0 - History Push API Feature
В видео в том числе можно увидеть новый интерфейс в Zabbix 7.0. Всё левое меню существенно изменилось.

✅ Также вышла новая версия Zabbix Server 6.0.25, в которой наконец-то исправили баг, когда не работали веб проверки сайтов в кодировке, отличной от utf8. В комментариях кто-то писал, что тоже заметил эту проблему. Так вот теперь её исправили. У меня наконец-то заработали проверки старых сайтов в кодировке Windows-1251. Раньше Битрикс по умолчанию в ней устанавливался и до сих пор успешно работает и обновляется с этой кодировкой.

У Zabbix изменились сроки поддержки не LTS версий, то есть версий X.2 и X.4. Теперь это будет 6 месяцев полной поддержки и 6 месяцев исправлений критичных багов и проблем с безопасностью. То есть поддержка будет 1 год со времени выхода нового релиза. Напомню, что у LTS версии поддержка 5 лет. Я обычно на LTS версиях сижу. Редко обновляю на промежуточные релизы. Только если интересно потестить какие-то нововведения.
⇨ Zabbix Life Cycle and Release Policy.

Ждём версию 7.0. Пока что только alpha, потом ещё несколько месяцев будут beta выходить. К весне, наверное, зарелизятся.

#zabbix

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

Установить сервер очень просто. Для DEB дистрибутивов есть репозитории. На Debian ставим так:

# curl -L https://www.ikus-soft.com/archive/minarca/public.key | gpg --dearmor > /usr/share/keyrings/minarca-keyring.gpg
# echo "deb [arch=amd64 signed-by=/usr/share/keyrings/minarca-keyring.gpg] https://nexus.ikus-soft.com/repository/apt-release-$(lsb_release -sc)/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/minarca.list
# apt update
# apt install minarca-server

И всё, можно идти в веб интерфейс на порт 8080. Учётка по умолчанию: admin / admin123.

Для того, чтобы что-то забэкапить, надо скачать и установить агента. Есть версия под Windows, Linux, MacOS. Можно всех бэкапить под одной учёткой, либо под разными. Дальше будет понятно, в чём отличие. Устанавливаем клиента, указываем адрес сервера, логин, пароль.

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

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

Каких-то особенных возможностей нет, но в базе по бэкапам есть всё необходимое. При желании, можно настроить 2FA и спрятать сервис за прокси. Отмечу ещё раз, что под капотом там rdiff-backup, соответственно, все возможности по хранению там те же: бэкап только на уровне файлов, дедупликации, бэкапа дисков и всей системы нет. Хранятся инкрементные бэкапы в экономичном формате с помощью линуксовых hard links. Репозитроий для хранения - обычная директория Linux на сервере. По умолчанию - /backups.

Мне система понравилась. Не знаю, что там по надёжности и удобству использования. Это надо попользоваться, чтобы понять. Больше всего понравилось то, что можно легко дать пользователям доступ к бэкапам. А также ежедневные или еженедельные отчёты по бэкапам, которые можно настроить в уведомлениях.

⇨ Сайт / Исходники / Demo / Видеообзор

#backup

Бодрое видео на тему того, почему Linux лучше Windows:

▶️ Why I use Linux

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

А вот прикол с touch CON и ls CON не понял. Кто-то может пояснить, к чему это было?

#юмор

Я уже не раз делал заметки про Gitea - легковесную open source систему для управления git репозиториями. Изначально это был просто веб интерфейс для git, который можно было сделать с помощью соответствующей темы очень похожей на github. Написана Gitea на Go и по своей сути это просто бинарник, поэтому с установкой и настройкой никаких проблем. Бонусом гошечки идёт очень быстрая работа и отзывчивость веб интерфейса.

Как я уже сказал, Gitea была создана просто для работы с кодом, без какой-либо автоматизации. Для построения конвейера для сборки, деплоя и хранения образов я предлагал связку: Gitea + Drone CI + Docker Registry.

С недавних пор в Gitea завезли Gitea Actions, которые полностью совместимы с GitHub Actions. То есть она превратилась в полноценную CI/CD систему с собственным Package Registry и Gitea Runner. Получился аналог gitlab на минималках.

Подробно посмотреть обзор всех этих возможностей, а также инструкцию по настройке, можно в серии из двух видеороликов:
▶️ Gitea-01: домашний github (+ actions)
▶️ Gitea-02: домашний github (+ actions)

#git #devops #cicd

​​Я делал несколько заметок на тему systemd, где встроенные возможности этой системы управления службами заменяют функциональность других линуксовых программ и утилит:

◽Systemd timers как замена Cron
◽Journald как замена Syslog
◽Systemd-journal-remote - централизованное хранение логов
◽Systemd-journal-gatewayd - просмотр логов через браузер
◽Systemd-mount для монтирования дисков
◽Есть ещё timesyncd как замена ntp или chrony.

Сегодня расскажу про ещё одну такую службу, которая заменяет локальный кэширующий DNS сервер - systemd-resolved. Изначально я научился настраивать DNS сервер Bind ещё в те времена, когда было привычным делом держать свою зону на своих серверах. Везде использовал его, даже в простых случаях, где нужно простое кэширование без поддержки своих зон. Потом познакомился с Dnsmasq и для обычного кэширования стал использовать его, так как настроить быстрее и проще. На пути к упрощению решил попробовать systemd-resolved. Он выступает в роли локального кэширующего сервера, то есть обрабатывает только запросы сервера, где он установлен, и его приложений.

В каких-то дистрибутивах systemd-resolved может быть в составе systemd. В Debian 12 это не так, поэтому придётся поставить отдельно:

# apt install systemd-resolved

Далее открываем конфиг /etc/systemd/resolved.conf и приводим его примерно к такому виду:

[Resolve]
DNS=77.88.8.1 1.1.1.1 8.8.8.8
FallbackDNS=77.88.8.8 8.8.4.4
Cache=yes

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

Перезапускаем службу:

# systemctl restart systemd-resolved

После установки systemd-resolved удаляет /etc/resolv.conf и заменяет ссылкой на /run/systemd/resolve/stub-resolv.conf. Проверить работу службы можно разными способами. Например так:

# resolvectl query ya.ru

или так:

# dig @127.0.0.54 ya.ru

То есть локальный DNS сервис имеет адрес 127.0.0.54. Он же и указан в виде nameserver 127.0.0.53 в resolv.conf.

Посмотреть статус службы можно так:

# resolvectl status

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

# systemctl edit systemd-resolved

Добавляем параметр:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Перезапускаем службу и смотрим логи:

# systemctl restart systemd-resolved
# journalctl -f -u systemd-resolved

Если ответа нет в кэше, то вы увидите информацию о том, что был запрос к публичному DNS серверу. Если в кэше есть запись об этом домене, то увидите строку:

Positive cache hit for example.com IN A

Посмотреть статистику по запросам:

# resolvectl statistics

Очистить локальный кэш:

# resolvectl flush-caches

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

#systemd #dns

Один читатель рассказал про свой репозиторий на github:

⇨ https://github.com/Lifailon

Там очень много всего написано за много лет продуктивной деятельности. Автор захотел поделиться с аудиторией. Может кому-то будет полезно. Человек занимался в основном администрированием на Windows, поэтому большая часть работ на PowerShell, но не только.

Я посмотрел репу и сразу честно сказал, что это лютые костыли, которые решали конкретные задачи на конкретном рабочем месте, поэтому слабо применимы для широкой аудитории. Тем не менее, некоторые полезные вещи я увидел и для себя:

▪ Windows-User-Sessions - шаблон и скрипты к Zabbix для мониторинга за терминальными сессиями на сервере.

▪ ACL-Backup - небольшой скрипт с формой ввода, который позволяет сделать полный backup списка прав доступа (ACL) файловой системы NTFS в txt-файл с возможностью восстановления из этого списка. Я тоже писал и использовал скрипты для решения этой же задачи. Когда бэкаплю виндовые шары, записываю на них же списки прав доступа, чтобы можно было восстановить, если что-то пойдёт не так.

▪ PS-Commands - описание с примерами PowerShell cmdlets на русском языке.

▪ Remote Shadow Administrator - практически полноценная программа на PowerShell для управления терминальными серверами и подключения к текущим RDP-сессиям с помощью Shadow-подключения. Написана только с помощью PowerShell и Windows Forms. Если управляете терминальниками, то может быть очень полезным.

В репозитории ещё много всего необычного. Посмотрите, может найдёте что-то полезное для себя.

#windows

Много раз писал про различные возможности SSH на сервере, в том числе для использования в роли jumphost. Да и сам нередко использовал эту возможность. При этом либо в 2 этапа подключался к требуемому хосту, то есть вручную - сначала на jumphost, потом уже на целевой. Либо запускал команду на подключение к целевому хосту внутри команды на подключение к jumphost:

# ssh -t user@jumphost "ssh user@server01"

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

Мимо моего внимания прошла возможность ssh напрямую подключаться со своего хоста на server01 через jumphost. То есть это выглядит вот так:

# ssh -J user@jumphost:22 user@server01

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

Оба эти подхода имеют право на жизнь, в зависимости от ваших потребностей. Например, при первом подходе на jumphost можно более гибко раздать права, настроить логирование или запись сессий, уведомления о подключениях. В случае второго подхода всё это придётся делать на целевом сервере, но при этом будет более простое и стабильное соединение, так как ssh сессия будет одна, а не вложение одной в другую.

📌 Ссылки по теме:
▪ Логирование ssh активности с помощью: Tlog, snoopy, log-user-session, PROMPT_COMMAND
▪ Уведомления в Telegram о ssh сессиях
▪ Переадресация портов через ssh
▪ VPN туннели с помощью ssh
▪ Ограничение на выполнение команд по ssh
▪ Псевдографическое меню для jumphost
▪ Поддержание постоянного ssh соединения с помощью Autossh

#ssh