ServerAdmin.ru
26.5K subscribers
182 photos
24 videos
7 files
2.45K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
​​Расскажу про простой и быстрый способ увидеть лог smtp сессии при обращении к какому-то почтовому серверу. Как вы уже знаете из прошлой заметки про curl, она умеет работать с различными протоколами. В том числе и с smtp.

В общем случае самый эффективный способ поговорить с smtp сервером, это обратиться к нему на 25 порт телнетом. И надавать ему туда своих команд. Примеров в сети много. Но это долго и не всегда нужно. Можно воспользоваться curl:

# curl smtp://mail.site.ru:25 -v \
--mail-from sysadmin@site.ru \
--mail-rcpt sysadmin@site.ru \
--user 'sysadmin@site.ru:password' \
--upload-file ~/email.txt

Содержимое email.txt примерно такое:

From: sysadmin@site.ru
To: sysadmin@site.ru
Subject: test email
Date: Mon, 17 Apr 2023 00:17:16

Dear Sysadmin,
Welcome to this test email. What a lovely day.

В консоли будете наблюдать лог smtp сессии. Если что-то не так, увидите ошибку.

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

Мне захотелось разобраться в проблеме, поэтому погрузился в тематику. Выяснил, что Zabbix отправляет почту через curl. Со стороны почтового сервера было не очень понятно, в чём конкретно проблема, он просто ругался на неправильную аутентификацию. Немного поигрался в консоли с curl и понял, в чём проблема.

Curl почему-то по умолчанию предлагает аутентификацию DIGEST-MD5 и она по какой-то причине происходит с ошибкой. По идее, клиент дальше должен пробовать другие методы, но конкретно в этой ситуации curl получал ошибку аутентификации и больше никаких попыток не делал. Дело было на сервере Centos 7, где curl очень старой версии. В сети нашёл информацию, что на нём реально могут быть проблемы с аутентификацией. Обновил утилиту до последней версии, но мне это не помогло.

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

Вот эта же проблема, описанная на форуме Zabbix, а вот предложенное решение по обновлению curl на centos 7, которое мне не помогло.

#linux #curl #zabbix
​​Долгое время у меня в закладках была масштабная система по анализу работы сайтов или веб приложений под названием PostHog. Несколько раз заходил на сайт, мельком всё просматривал и закрывал, так как не видел, где мне она может пригодиться даже теоретически. В итоге всё же изучил продукт и решил поделиться с вами. Хоть он и будет полезен очень малой части пользователей, тем не менее на русском языке я почти не нашёл информации о нём. Возможно, она окажется полезной. Продублирую её на сайте.

PostHog — open source аналог Google Analytics или Яндекс.Метрики. Причём не на уровне просмотра количества посетителей и времени, проведённом на сайте. Там функционал по отслеживанию и аналитике сопоставим, а где-то превосходит публичные сервисы. Особенно, если вы сами пишите свой сайт и можете интегрировать на уровне кода взаимодействие с PostHog.

Чтобы полностью оценить функционал этой системы, можно посмотреть записанную демонстрацию — https://www.youtube.com/watch?v=BPDmpepEwSY
Основные возможности:
сбор и анализ статистики сайтов и мобильных приложений
схемы взаимодействия пользователей с сайтом и приложением, визуализация навигации
запись сессий пользователей, отслеживание конверсий
возможность проведения и оценки A/B тестирования
сбор данных с внешних источников

И весь этот функционал можно развернуть у себя. Причём очень просто и быстро. Весь функционал реализован на базе Docker контейнеров и разворачивается автоматически с помощью bash скрипта. Подробности в руководстве. Для успешной установки надо предварительно установить пакеты curl, gnupg, sudo. Также необходим внешний IP и A запись, чтобы можно было получить бесплатный сертификат от Let's Encrypt. Без этого хозяйство не заведётся. Под капотом там веб сервер caddy, clickhouse, kafka, zookeeper, postgres, redis, minio. Не продукт, а мечта девопса.

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

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

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

#сайт
​​Маленькая, простая и удобная утилита для быстрой проверки работы дисковой подсистемы — ioping. Есть в базовых репозиториях популярных систем на базе Linux. Ставим в Debian 11:
# apt install ioping

Проверяем отклик диска (I/O latency), наподобие сетевого отклика:
# ioping .
4 KiB <<< . (ext4 /dev/sda2 19.0 GiB): request=3 time=3.54 ms
4 KiB <<< . (ext4 /dev/sda2 19.0 GiB): request=4 time=3.68 ms

Измеряем среднее количество иопсов (iops):
# ioping -R /dev/sda
21.6 k requests completed in 2.93 s, 84.5 MiB read, 7.38 k iops, 28.8 MiB/s
generated 21.6 k requests in 3.00 s, 84.5 MiB, 7.21 k iops, 28.2 MiB/s
min/avg/max/mdev = 42.4 us / 135.5 us / 1.13 ms / 71.1 us

Последовательное чтение:
# ioping -RL /dev/sda
8.63 k requests completed in 2.79 s, 2.11 GiB read, 3.10 k iops, 774.3 MiB/s
generated 8.63 k requests in 3.00 s, 2.11 GiB, 2.88 k iops, 719.2 MiB/s
min/avg/max/mdev = 98.2 us / 322.9 us / 4.45 ms / 160.4 us

Классная программа. У неё много возможностей. Чтобы их посмотреть, достаточно запустить ioping без аргументов. Там можно режимы выбирать, ограничения ставить, число запросов назначать, размер запроса указывать и т.д.

Не знал раньше про эту программу. Думаю, её можно добавить в список софта для стандартной установки наравне с mc, htop, screen и т.д.

#linux #terminal
​​Не все системные администраторы знают, что есть отдельный класс программ под названием IPAM (IP Address Management). Они служат для управления пространствами IP адресов. Причём бывают как отдельные программы, где реализована только эта функциональность, так и программы для инвентаризации и учёта IT инфраструктуры, куда включают и IP адреса.

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

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

NetBox — это не только учёт IP адресов, но я всё равно отнёс эту программу сюда, потому что она заточена под учёт сетевой инфраструктуры и является в первую очередь рабочим инструментом сетевых инженеров. Функционал IPAM там сделан не для галочки, а реализован в полной мере.

TeemIP — это как самостоятельный продукт, так и дополнительный модуль для iTop. Думаю, что актуально только для тех, кто использует iTop. Как отдельный продукт он не так хорош, как некоторые другие.

phpIPAM — по удобству, функционалу и внешнему виду, мне кажется, что этот продукт наиболее привлекателен для использования, если нужен конкретно IPAM для больших сетей.

GestioIP — помимо функционала IPAM реализован простенький мониторинг средствами icmp и snmp, поэтому он умеет выполнять автообнаружение узлов в сети. Из приятных особенностей — возможность интеграции с OCS Inventory NG (бесплатное ПО для инвентаризации сети).

Перечисленные выше программы являются наиболее известными, бесплатными, с открытым исходным кодом. Помимо них есть ещё IPplan, openDCIM, HaCi, NIPAP. Коммерческих решений для IPAM существует очень много, так что не буду их перечислять. Отдельно отмечу только одно.

Служба в Windows Server. Возможно не все знают, но начиная с Windows Server 2012 там есть отдельная служба IP Address Management (IPAM) Server. Можно развернуть и пользоваться, не привлекая сторонние программы для этого. Причём там это работает в связке с DNS сервером.

#ipam #подборка
Много лет назад (8), когда я активно занимался поддержкой офисов, не раз сталкивался с вирусами-шифровальщиками. Причём с одним из них я столкнулся, когда они прям только начали появляться и были в новинку. Никто толком не понимал, что это такое и как восстанавливать данные.

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

Самое интересное, что у этих людей были зашифрованные флешки (пин код прям с устройства вводился) с секретной информацией, которая никуда не копировалась и не бэкапилась. Флешки не должны были быть воткнутыми постоянно. Понятное дело, что они были воткнуты постоянно в течении рабочего дня. Все данные там были потеряны. Директор тогда отнёсся философски ко всему этому. Ругаться не стал, сказал, что сами виноваты, пусть выкручиваются, как хотят. В принципе, сами и выкрутились.

Когда я воочию увидел, как легко безвозвратно потерять все данные, стал по-другому относиться к бэкапам. Я сам тогда ещё ни разу не сталкивался с тем, что данные могут быть вот так утеряны безвозвратно и шансов на восстановление нет. Сам за бэкапами всегда следил. Потом и тут всё настроил и забэкапил. Позже они ещё раз словили шифровальщика. Данные им из бэкапа восстановил. Причём всё это было с работающим платным антивирусом Eset. Тогда антивирусы очень слабо реагировали на шифровальщиков.

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

Написать на эту тему решил, чтобы рассказать про сервис https://www.nomoreransom.org/ru/index.html Зашёл его проверить и с удивлением обнаружил, что сайт всё ещё функционирует. Во время разгула шифровальщиков, не все в полной мере шифровали файлы. Были и те, кто косил под популярных шифровальщиков, и те, кто реально ничего не шифровал. Для некоторых случаев антивирусные компании создавали дешифраторы и они реально помогали. Я знал такие случаи.

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

#вирус #сервис
Простой и быстрый способ забэкапить свои репозитории из github или gitlab. Я не стал тут изобретать велосипед, а просто поискал информацию. Нашёл много всяких программ и утилит на различных языках программирования. Всё это отмёл, пока не нашёл простые bash скрипты. Для меня было очевидно, что для решения этой задачи достаточно bash и api указанных сервисов.

В итоге воспользовался вот этим репозиторием:
https://github.com/alexadam/repo-backup
Очень простое и рабочее решение.

Я всё своё храню в Gitlab. Сходил в настройки, выдал токен с разрешениями на чтение api и репозиториев. И использовал его в скрипте:

#!/bin/sh

dirname=gitlab-backup-$(date "+%Y-%m-%d-%H-%M-%S")
mkdir "$dirname"
cd $dirname

privateToken=YOUR_ACCESS_TOKEN
userName=YOUR_GITLAB_USERNAME

curl --header "Private-Token: $privateToken" \
"https://gitlab.com/api/v4/users/$userName/projects" \
| jq -r '.[] | .id, .name' \
| while IFS= read projectId; read projectName; do
curl --header "Private-Token: $privateToken" \
"https://gitlab.com/api/v4/projects/$projectId/repository/archive.zip" \
--output $projectName.zip
done

echo Done! All files downloaded here: $(pwd)

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

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

#backup #git #devops
​​Мне посоветовали посмотреть на почтовый сервер Axigen Mail Server, про который я вообще ни разу не слышал. С интересом изучил его, но быстро разочаровался. Это коммерческий продукт с очень ограниченной бесплатной версией: 5 доменов, 5 пользователей, 5 групп. С такими ограничениями этот сервер подходит только для личного использования.

Тем не менее, сервер мне понравился. Разворачивается он очень просто и быстро. Для запуска есть всё, что только можно: deb и rpm пакеты, docker образ, образ VM для VMWare и VirtualBox, Helm чарт для k8s, установщик для Windows.

Я выбрал Docker для запуска. В лучших традициях монолита всё, что нужно для работы, упаковано в один образ. Это просто праздник. Вместо дюжины контейнеров тут только один. Запускаем:

# docker run --name=axigen -dt -v ~/axigen_var:/axigen/var \
-p 443:443 -p 9443:9443 \
-p 993:993 -p 995:995 \
-p 25:25 -p 465:465 \
-p 9000:9000 -p 7000:7000 axigen/axigen

Функционал типичный для личного органайзера:
почта
календарь
адресная книга
планировщик дел
заметки

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

Решил сделать заметку про этот почтовый сервер, потому что понравился веб интерфейс. Может кому-то тоже приглянется, и он выберет себе этот инструмент для личного использования в качестве персональной почты и всех остальных сервисов. Удобно, когда всё это интегрировано в единую систему. Из письма сразу же можно сделать заметку или задачу. У меня заметки, календарь, почта, задачи — разные сервисы. И это неудобно. А тут всё в одном месте.

Сайт / Demo

#mailserver #заметки
​​Вы знаете, как узнать, кто и насколько активно использует swap в Linux? Можно использовать для этого top, там можно вывести отдельную колонку со swap. Для этого запустите top, нажмите f и выберите колонку со swap, которой по умолчанию нет в отображении. Насколько я слышал, это не совсем корректный способ, поэтому, к примеру, в htop эту колонку вообще убрали, чтобы не вводить людей в заблуждение.

Самый надёжный способ узнать, сколько процесс занимает места в swap, проверить /proc/$PID/smaps или /proc/$PID/status. Первая метрика будет самая точная, но там нужно будет вручную вычислить суммарный объём по отдельным кусочкам используемой памяти. Вторая метрика сразу идёт суммой.

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

#!/bin/bash
SUM=0
OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"`
do
PID=`echo $DIR | cut -d / -f 3`
PROGNAME=`ps -p $PID -o comm --no-headers`
for SWAP in `grep VmSwap $DIR/status 2>/dev/null | awk '{ print $2 }'`
do
let SUM=$SUM+$SWAP
done
if (( $SUM > 0 )); then
echo "PID=$PID swapped $SUM KB ($PROGNAME)"
fi
let OVERALL=$OVERALL+$SUM
SUM=0
done
echo "Overall swap used: $OVERALL KB"

Здесь просто выводятся значения метрики VmSwap из /proc/$PID/status. А тут пример скрипта, где суммируются значения для swap из /proc/$PID/smaps и далее сортируются от самого большого потребителя к наименьшему. Не стал показывать его, потому что он значительно длиннее. Главное, что идею вы поняли. Наколхозить скрипт можно и самому так, как тебе больше нравится.

Можно по-быстрому в консоли посмотреть:
# for file in /proc/*/status ; \
do awk '/VmSwap|Name/{printf $2 " " $3} END { print ""}' \
$file; done | sort -k 2 -n -r | less

#linux #script #perfomance
Немного юмора в пятницу. Диалоги клиентов и заказчиков.

- На каком языке лучше делать сайт интернет-магазина? Ruby, PHP, Python?
- А вы сделайте так, что бы можно было выбрать язык.
===
- Как вы можете рассуждать о невозможности, если даже не пробовали.
===
- Вы профессионал, вот вам деньги, покажите как правильно.
- Вот так правильно.
- Я не согласен.
===
- Вы делаете сайты?
- Да. 
- Сделайте тогда нам сайт с зеркальным фоном, чтобы клиент видел своё отражение.
===
Работаю в сфере дизайна уже 23 года. Мой начальник однажды сказал:
- Смешай два цвета пигмента, чтобы получить жёлтый.*
- Какие два цвета мне использовать?
- Ты эксперт, а не я, вот и думай.
*жёлтый — базовый цвет, как красный и синий, их нельзя получить смешиванием.

Если кто не знает, это комментарии к видео:
The Expert (Русский дубляж)
Оригинал на английском:
The Expert (Short Comedy Sketch)
Рекомендую посмотреть, если ещё не видели. Это пародия на современный корпоративный рабочий процесс.

После просмотра роликов, вы поймёте и вот это:

- Что нам мешает скинуть вниз стекло с 10 этажа при этом не разбив его?
- Физика.
- Просто игнорируйте её.

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

Oh My Git! — одна из самых известных и популярных игр на тему изучения Git. Для этой технологии, на мой взгляд, сделано больше всего игр.

Vim Adventures — научит выходить из Vim. Играть можно в браузере. Игра платная, бесплатно доступны первые несколько уровней.

Elevator Saga — залипательная игра для изучения JavaScript. Нужно программировать эффективную работу лифта по перевозке людей. Играл в неё сам, мне понравилось.

Bandit — хакерская тематика со взломом через использование консоли в Linux. Проходится на реальном сервере в интернете, к которому надо подключаться. Советую обратить внимание, игра интересная и сложная.

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

while True: learn() - головоломка-симулятор на тему машинного обучения, нейронных сетей, ИИ и BigData. В игре вы выступаете в роли тыжпрограммиста, у которого есть кот, который лучше разбирается в it, чем вы.

KodeKloud Engineer - вы регистрируетесь и начинаете путь обычного сисадмина. Вас знакомят с проектом, рассказывают, что там к чему. Для него есть подробная схема, wiki, таблица с ip адресами и доступами. Примерно раз в день вам будут давать какое-то задание по этой инфраструктуре. Всё выполняется в виртуальной консоли в браузере, которая эмулирует консоль Linux. Задания максимально приближены к реальным задачам админа или devops.

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

Если знаете ещё что-то полезное и интересное по данной тематике, поделитесь, пожалуйста, в комментариях.

#игра #обучение #подборка
​​▶️ Понравилось ещё одно выступление с DevOpsConf, которое могу порекомендовать к просмотру:

⇨ DevOps спит, Gitlab CI работает

Выступление будет интересно тем, кто хочет на примерах посмотреть, что такое CI/CD на практике. Не абстрактные интеграции и доставки, а по шагам, что конкретно делаем.

Автор доклада рассказала, как они жили до CI/CD и вручную выполняли все операции по заявкам разработчиков. И как в итоге всё автоматизировали с помощью Gitlab, чтобы вручную не делать ничего. Каждый шаг своего конвейера она описывает. Собственно, об этом весь доклад.

Обратил внимание, что крупная компания использует Rocket.Chat для внутреннего общения. Мне предстоит уже на днях внедрение в небольшую компанию на 50 человек. Расскажу потом, как всё прошло. Самому интересно в работе посмотреть на этот продукт. Дальше тестов никогда дело не заходило. Был опыт внедрения и использования Mattermost и Zulip.

Отдельно хочется отметить, что Виктория начала свой путь с первой линии поддержки в 2018 году. А уже в 2020 стала DevOps инженером. В 2022 выступает на конференции для специалистов. Хорошая мотивирующая история. Дорогу осилит идущий.

#видео #devops #cicd
​​В одном выступлении вскользь увидел упоминание программы Grafana dashboard builder. С её помощью можно автоматически создавать дашборды графаны на основе файлов конфигураций в формате yaml. Идея интересная, поэтому решил посмотреть, как это на практике выглядит.

На то, чтобы установить, запустить и понять, как это работает, ушло довольно много времени. Программа есть в pip, но в Debian 11 просто так не ставится. Не получалось установить все зависимости. В итоге нашёл решение. Нужно было предварительно установить один пакет. В итоге установил вот так:
# apt install python3-pip
# apt install heimdal-dev
# pip3 install grafana-dashboard-builder

Далее склонировал репозиторий, чтобы взять оттуда примеры настроек и проектов:
# git clone https://github.com/jakubplichta/grafana-dashboard-builder
Примеры лежат в директории samples.

Для того, чтобы сгенерировать шаблоны на основе тестового проекта, необходимо в config.yaml указать корректную output_folder. После этого можно запустить генерацию, находять в директории samples:
# grafana-dashboard-builder -p project.yaml \
--exporter file --config config.yaml
В папке Example project будут сгенерированные дашборды в формате json.

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

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

Исходники

#grafana #devops
Хочу порассуждать с вами на тему, которая интересна лично мне. И по которой у меня нет однозначного мнения, что лучше делать вот так, а не иначе. Речь пойдёт про интеграцию аутентификации с единым LDAP каталогом.

Удобно, когда для аутентификации используется единый каталог. Когда все сервисы в закрытом периметре, никаких проблем не вижу. А если речь идёт, например, о почте, или о VPN подключениях? Эти сервисы люди используют, получая к ним доступ через интернет. Я много раз сталкивался, что учётные данные от почты утекают куда-то на сторону и через сервер начинают рассылать спам.

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

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

А вы что думаете на этот счёт? Как обычно настраиваете? В первую очередь почта и VPN интересуют.

#разное
​​Необходимо внедрить в небольшой компании примерно на 50 человек Rocket.Chat. Не хочу долго описывать, почему выбор пал именно на него. Если кратко, то основная причина — большая функциональность платной версии. Менее значимые причины — активная разработка продукта и популярность.

Мне так или иначе знакомы все популярные чат-сервера, которые можно установить у себя. Я лично внедрял и использовал Mattermost и Zulip. Первый понравился больше всего, но бесплатная версия сильно ограничена в функциональности. Zulip понравился по возможностям и внешнему виду, но через полгода-год история так жутко тормозила, что невозможно было что-то найти в старой переписке. А вместе с ней и весь клиент тупил, что пользоваться стало некомфортно. В итоге со временем все забросили этот чат и просто перестали пользоваться.

Rocket.Chat обновляется часто, поэтому решил запускать в Docker. Инструкция есть, запускается буквально за 5-10 минут. Обязательно в compose измените версию с latest на последний релиз!!! Сразу же настроил обратный прокси на Nginx и работу по HTTPS и доменному имени.

По умолчанию сервер хранит все загруженные файлы в своей базе Mongodb. Это удобно для масштабирования установки на несколько серверов, что мне совершенно не нужно. Так что я сразу немного изменил compose файл, добавил новый volume к контейнеру с rocketchat и настроил хранение файлов в отдельной директории.

Далее сразу же настроил бэкап. В этом деле я люблю подстраховываться, поэтому сразу настроил три типа:
Бэкап на уровне виртуальной машины.
Воспользовался Docker-volume-backup для бэкапа volumes.
Бэкап дампа базы mongodb.

Rocket.Chat всё своё состояние хранит в mongodb. Если вы не переносили хранение файлов в директорию файловой системы, то бэкапа mongodb вам будет достаточно. Я не очень люблю большие дампы баз данных, в том числе поэтому вынес хранение файлов в директорию, которая вместе с дампом базы и бэкапом volume от монги уезжает на бэкап сервер.

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

К сожалению, русский перевод не очень. В целом понятный, но корявенький. Себе сразу поставил английский, иначе настраивать неудобно. Пользователям оставил русский. Посмотрим, как проявит себя этот чат. Я им ещё не пользовался и не внедрял. Только для тестов ставил. Из неприятного заметил, что страница логина не грузится в Яндекс.Бразуре. Во всех других, что я проверял, загружается (Chrome, Edge, Firefox). В первом же бесконечно крутится загрузка стартовой страницы.

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

#chat
​​▶️ Информация для тех, кто учится или уже использует Ansible, но возможно не так, как следует:

Ansible плох? Нет, просто готовьте его правильно!

Интересное выступление от специалиста в своей области знаний. Я после доклада захотел купить у него курс, но, как оказалось, как такового курса нет, а когда-то проводилось групповое обучение.

В выступлении разобраны популярные по мнению автора ошибки при использовании Ansible. Основные:
использование шаблонизации yaml, как текстов, а не как структурированных данных
использование группы хостов all, а потом методом исключения добавляются условия
использование модулей python с зависимостями, которые непонятно что вам принесут в систему
использование Ansible для управления учётками и доступами на машинах
хранение инвентаря в формате ini
подмена тэгов условиями
и т.д.

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

Ещё полезные материалы по Ansible от этого автора:
Ansible это вам не bash (текст, видео)
Блеск и нищета Ansible
Ansible-vault decrypt: обходимся без Ansible
Ускоряем Ansible

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

#видео #ansible
​​Напоминаю про очень функциональное и удобное решение для бэкапов — Restic. Часто вижу его упоминание в различных выступлениях и интервью. Я уже делал про него заметку, хочу дополнить информацию. Кратко перечислю плюсы :

🔹простая установка, так как это всего лишь один бинарник, написанный на GO, есть в репозитории Debian
🔹очень хорошая производительность
🔹поддержка дедупликации, снепшотов на уровне данных
🔹разные бэкенды для хранения: локальная директория, sftp, S3, rclone и т.д.
🔹проверка целостности, шифрование

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

Для Prometheus есть готовый экспортёр метрик — restic-exporter. Указываете репозиторий, пароль к нему и получаете на выходе полезные метрики: статус проверок, количество снэпшотов, время последнего бэкапа, кол-во файлов в бэкапе, их размер и т.д. А бонусом идёт дашборд для Grafana.

Zabbix тоже имеет готовый шаблон для мониторинга за бэкапами, сделанными Restic. Его написали не разработчики, так как он в отдельном репозитории community-templates, но, тем не менее, они за ним следят и актуализируют к свежим версиям. Мониторинг работает через прокладку resticprofile, которая формирует конфигурационные файлы для бэкапов и умеет сохранять результаты работы в json файл.

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

Вообще, решение с Prometheus выглядит более целостным, простым и удобным. Если бы мне сейчас нужно было мониторить бэкапы Restic, я бы взял именно его. А если всё же нужен Zabbix, то распарсил бы промовский экспортер. Там буквально, запускаем контейнер с restic-exporter и смотрим метрики:

# docker run -d \
 --name=restic-exporter \
 -v /mnt/backup:/data
 -e TZ=Europe/Moscow \
 -e RESTIC_REPO_URL=/data \
 -e RESTIC_REPO_PASSWORD=123 \
 -e REFRESH_INTERVAL=60 \
 -p 8001:8001 \
 --restart unless-stopped \
 ngosang/restic-exporter

# curl http://localhost:8001

Очень просто и удобно.

#backup
​​Одной из наиболее известных, если не самой известной, бесплатной платформой с открытым исходным кодом для организации онлайн конференций является BigBlueButton. Условно её можно назвать бесплатной заменой Zoom, которую можно поднять на своих серверах.

📌 Базовый функционал BigBlueButton:

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

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

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

С установкой и запуском базовой конфигурации особых проблем не будет. Продукт известный, в сети много руководств. Есть готовый bash скрипт для Ubuntu, который надо запустить, передав ему некоторые базовые параметры в виде домена и почтового ящика для учётной записи Let's Encrypt. Процесс подробно описан в документации. Установка будет выполнена с помощью deb пакетов из подключенного репозитория и кое-что будет запущено в Docker (greenlight — веб панель для управления).

Альтернативным вариантом установки может стать Ansible, с использованием которого написаны различные варианты разворачивания полной инфраструктуры. Например, вариант HA кластера, с PeerTube для стриминга, ELK для логов, Prometheus + Grafana для мониторинга — Ansible roles deploying BigBlueButton.

Сайт / Исходники / Документация / Demo

#видеоконференции
​​Для просмотра истории консольных команд в Linux есть соответствующая утилита history. Помимо неё есть ещё одна — fc. Я не знаю, кто и зачем её придумал. Функционал у неё довольно скромный и нет ничего такого, чего бы не умела history. Например, смотрим 5 последних команд:

# fc -l -5
# history 5

На самой fc я не буду подробно останавливаться, так как цель этой заметки не в ней. Я увидел эту команду и думаю, что это вообще такое. Захожу в Debian, пробую:

# man fc
No manual entry for fc

Пусто, нет информации. Ищу бинарник:

# which fc

Опять пусто. Думаю, наверное это алиас в виде обёртки над history.

# alias | grep fc

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

# type fc
fc is a shell builtin

Всё встало на свои места. Утилита fc входит в состав оболочки bash, наряду с pwd, cd, и, кстати, той же history и type. Так что, если хотите быстро понять, с чем имеете дело, используйте утилиту type. Она помогает увидеть, чем является конкретная команда — алиасом, частью оболочки или отдельным бинарником.

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

1️⃣ Сначала проверяются алиасы.
2️⃣ Потом проверяются встроенные в оболочку команды.
3️⃣ И только потом ищутся бинарники, определённые в $PATH, причем не абы как, а по порядку следования этих директорий в переменной слева направо.

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

Зная последовательность проверки команд, можно временно сломать какую-то команду. Например, сделать алиас history и назначить ему какое-то другое действие:

# alias history='echo "Здесь истории нет"'
# history
Здесь истории нет

Пока не удалишь созданный алиас, утилита history запускаться не будет, потому что алиас первый в списке на исполнение. А проверить всё это можно с помощью ключа -a:

# type -a history
history is aliased to `echo "Здесь истории нет"'
history is a shell builtin

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

Первый сон был на тему шифровальщиков. Я писал недавно про них заметку, но не помню, то ли после сна о них вспомнил, то ли наоборот — сон был после заметки. Снится мне, как на мой рабочий ноутбук попадает шифровальщик. Я заметил неладное, когда увидел, что все системные иконки на рабочем столе превратились в ярлыки, нажатие на которые ни к чему не приводит. Пытаюсь открыть Этот компьютер (уже давно не Мой), но проводник не запускается.

Горячими клавишами запускаю диспетчер задач и вижу, что какой-то процесс занимает 100% CPU. Почему-то во сне уверенность, что это шифровальщик. Паники нет, потому что знаю, что есть бэкап всей системы с данными. Завершаю работу, но вместо реального завершения работы понимаю, что запускается какая-то заставка, которая имитирует завершение работы, но на самом деле продолжается шифрование. Выключаю ноут зажатием кнопки включения. После этого просыпаюсь и радуюсь, что не надо ничего восстанавливать из бэкапа, так как это был сон.

Кстати, такое поведение вируса никогда не видел. Мозг придумал всё это сам или с чьей-то помощью во сне.

Второй сон совсем недавно приснился. У меня в квартире почему-то постоянно работают мои сервера. Организована мини серверная. Одно время у меня так и было, я хостил сайты дома на самосборном сервере. Но быстро понял, что это так себе идея и больше к домашнему серверу не возвращался. У меня его и нет, кроме небольшого семейного NAS и пары тестовых гипервизоров (HyperV и Proxmox), которые включаются по необходимости, не часто. Возвращаюсь ко сну.

Мне поступает предложение от знакомого — разместить чужой сервер у меня дома. Причём платят прилично, даже больше чем на colocation в ЦОД. Я сначала обрадовался и принял предложение. Мне заплатили и привезли сервер. Потом я во сне начинаю соображать. А зачем они привезли свой сервер ко мне на квартиру, если дешевле разместить его в нормальном ЦОД, где намного стабильнее и интернет, и электроснабжение? Немного покумекав, я догадываюсь, что это может быть выгодно только тем, кто хочет заниматься какой-то противозаконной деятельностью, а виноват в итоге окажусь я, так как тут никакого договора и оплата налом. А в ЦОД надо на юр. лицо договор оформлять. В итоге отказываюсь от предложения и возвращаю уже переданную мне сумму за размещение. Просыпаюсь с мыслью, какой же я все-таки умный. Даже во сне я осторожен и меня так просто не провести 😁

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

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

У человека был гипервизор Hyper-V, смотрящий напрямую в интернет. Встроенный брандмауэр включен, RDP порт открыт только по белым спискам IP. На хосте крутятся виртуалки, в одной из них установлена RouterOS (операционка от Микротик) со своим внешним IP. Все виртуалки в интернет ходят через неё. Соответственно, всё тоже закрыто, проброшены только нужные порты.

В какой-то момент на гипервизор установили Veeam Backup & Replication и не проконтролировали открытые порты. А он открыл для себя TCP 9401 на весь интернет. Через некоторое время через этот порт зашёл шифровальщик, всё зашифровал и оставил информацию, куда обращаться за расшифровкой.

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

Он стал разбираться и нашёл относительно свежую уязвимость, через которую его скорее всего и взломали: CVE-2023-27532. The vulnerable process, Veeam.Backup.Service.exe (TCP 9401 by default), allows an unauthenticated user to request encrypted credentials.

❗️Лишний раз напоминаю, что следите за своими внешними IP адресами. Тут ошибка была в том, что гипервизор сидел на своём отдельном IP адресе напрямую во внешний интернет. Надо было его тоже закрыть Микротиком, раз он есть. Я всегда так делал, если есть отдельная виртуальная машина под шлюз. Пусть она закрывает всю виртуальную инфраструктуру и сам гипервизор. Главное, не забыть настроить её автозапуск, иначе после выключения доступа к гипервизору не будет.

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

У меня тоже были ситуации, когда гипервизор по ошибке оказывался открыт со стороны интернета. Например, программно погасил интерфейс с внешним интернетом, сетевые настройки не прописывал. А в какой-то момент по неизвестной мне причине, этот интерфейс стал активен, а провайдер выдавал настройки внешнего IP по DHCP. Я очень удивился, когда обнаружил свой гипервизор вместе с RDP доступным из интернета. Просто в порядке профилактики просканировал все внешние IP адреса и заметил это.

Так что, если используете Veeam Backup & Replication, обновляйтесь. И не выставляйте в интернет то, чему там не место. За этим надо регулярно следить, так как от ошибок и случайностей никто не застрахован.

📌 Полезные ссылки по теме:
 Esxi: меня взломали! Лечим и понимаем причину
 Автоматическая проверка серверов с помощью OpenVAS
 Проверка хостов на CVE на открытых портах
 Регулярная проверка с помощью Nmap
 Сетевой сканер для поиска уязвимостей - Nessus Scanner

Заберите список в закладки. Что-нибудь наверняка пригодится.

#security