С памятью в Linux всё сложно. Многие не понимают, как в принципе её смотреть и на какое конкретно значение обращать внимание. Особенно тяжело разбираться в этом после такого родного и понятного диспетчера задач в Windows, который чётко показывает, сколько у тебя памяти использовано и сколько свободно. В Linux использование памяти процессами — сложный вопрос. Вы не сможете просто запустить какую-то программу и сразу понять, что у нас с памятью процесса.

В заметке речь пойдёт о том, как посмотреть, что конкретно занимает память в каком то процессе. Возьмём для примера Nginx или Php-fpm. У них много модулей, поэтому бывает интересно заглянуть, а сколько каждый из них может потреблять памяти.

Для этого сначала посмотрим PID материнского процесса:
# ps ax | grep nginx

А теперь смотрим потребление памяти с помощью pmap. Эта утилита обычно есть в стандартном системном наборе.
# pmap 1947 -p

Если я правильно понимаю, то данная команда в самом низу показывает всю виртуальную память процесса (VSZ или VIRT), которая включает в себя в том числе и библиотеки, которые могут быть разделены между разными процессами, а также то, что в swap. То есть эта такая условная метрика, с которой не понятно, что делать. Мастер процесс Nginx и все его рабочие процессы будут занимать одну и ту же виртуальную память.

Если использовать ключ -x, то увидим ещё и резидентную память (RES или RSS).
# pmap 1947 -x

Это память процесса без swap, включает в себя память, занимаемую разделяемыми библиотеками, но только ту, что реально находится в оперативной памяти и используется в данный момент. Это уже больше похоже на реальное потребление процесса, но всё равно не точно, потому что если у процесса есть форки, то они все будут занимать одинаковое количество RSS памяти. Сумма занимаемой ими памяти не будет соответствовать тому, что реально занято в оперативе.

Ключ -d добавляет ещё одну метрику writeable/private:
# pmap 1947 -d

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

Информацию pmap берёт из /proc/PID/smaps и превращает её в удобочитаемый формат.

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

#linux #terminal

Увидел на неделе вот этот мем с девопсом. Не знаю почему, но в голове сразу же возникла идея, что тут не хватает продолжения со словом девопёс. Решил реализовать.

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

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

#мем

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

⇨ Введение в базы данных

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

Особенное внимание рекомендую уделить индексам. Я как-то писал о них заметку. Иногда проблему с производительностью СУБД можно решить добавлением индексов, про которые просто все забыли, либо разработчиков давно уже нет и за базой никто не следит. В общем случае индексы делают разработчики сами. Это если понимают, что это такое.

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

#обучение #бесплатно

На днях вышел релиз Debian 12 Bookworm. Для меня это не стало сюрпризом, так как недавно я уже смотрел эту версию и проверял, как проходит обновление с прошлого релиза. У меня уже довольно много серверов под управлением Debian, так что вопрос меня касается напрямую.

Решил не откладывать задачу на потом и сразу рассмотреть изменения новой версии. Я написал подробную статью с обновлением с 11-й версии на 12-ю. Постарался рассмотреть наиболее значимые моменты обновления в соответствии с рекомендациями самих разработчиков из заметки Upgrades from Debian 11 (bullseye).

⇨ https://serveradmin.ru/kak-obnovit-debian-11-do-debian-12-bookworm/

Из основных нововведений, помимо обновления пакетов, я отметил следующие:

◽В установочные образы включили некоторые прошивки из репозитория non-free. Это сделано для лучшей поддержки железа во время установки. Debian всегда очень внимательно относился к проприетарному софту, выделяя его в отдельный репозиторий non-free. В этом релизе решили сделать некоторые исключения. Поэтому добавлен ещё один репозиторий для проприетарных прошивок non-free-firmware.

◽В Debian 12 добавлен пакет ksmbd-tools, который реализует функциональность файлового сервера на базе протокола SMB3. Сервер работает на базе модуля ядра Linux. Подобная реализация более эффективна с точки зрения производительности, потребления памяти и интеграции с расширенными возможностями ядра. При этом ksmbd не претендует на полноценную замену Samba. Скорее как расширение для неё.

◽По умолчанию не используется rsyslog для записи системных логов. Вместо этого предлагают использовать journalctl для просмотра логов systemd. Если хотите (а мы хотим) по старинке системные логи в текстовом виде в /var/log, установите пакет system-log-daemon.

◽Из дистрибутива выпилили утилиту which, которая объявлена устаревшей. Вместо неё предлагают использовать type. Это приведёт к поломке многих скриптов, где часто используют which для определения полного пути к бинарнику. Не забудьте установить вручную whitch, если она у вас используется.

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

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

Я один свой сервер уже обновил, всё прошло штатно. Остальной прод торопиться обновлять не буду. Подожду месячишко, другой.

Скоро наверное Proxmox свою новую версию выкатит. Он обычно подгоняет свои релизы под релизы Debian. Я уже видел инфу про появление 8-й беты.

#debian

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

1️⃣ Первое это символ ^, который означает начало строки. Например, можно в каком-то конфиге исключить все строки с комментариями, которые начинаются на #:
# grep -E -v '^#' nginx.conf
Тут важно именно в начале строки найти #, потому что он может быть и в рабочей строке конфига, когда комментарий стоит после какого-то параметра, и его убирать не надо.

Когда проверял этот пример, заметил, что в стандартном пакете Nginx в Debian, конфиг по умолчанию включает в себя комментарии, где в начале строки идёт табуляция, потом #. Соответственно, пример выше не помог избавиться от комментариев. При этом в консоли bash вы просто так не введёте табуляцию в строку. Чтобы это получилось, необходимо ввести команду выше, навести указатель на символ сразу после ^, нажать Ctrl-V и потом уже на tab. Таким образом вы сможете найти все строки, которые начинаются с табуляции и символа #. Это очень удобно чистит конфигурационные файлы от комментариев.
# grep -E -v '^ #' nginx.conf
Получится что-то типа такого, но если вы скопируете эту команду, то она у вас не сработает. Нужно именно в своей консоли нажать Ctrl-V и tab.

Также символ начала строки удобно использовать в поиске, когда надо найти что-то по началу имени файла.
# ls | grep ^error
error-windows-10-share-110x75.png
error-windows-10-share-110x75.png.webp
error-windows-10-share-150x150.png
В этой директории были файлы со словом error не только в начале имени.

2️⃣ Второй символ $, который означает конец строки. Можно сразу же продолжить последний пример. Там есть файлы с двойным расширением. Это пример с реального веб севера, где модуль конвертации файлов в webp породил такого рода имена файлов. Выведем файлы только с расширением png. Если действовать в лоб, то получится вот так:
# ls | grep .png
error-windows-10-share-110x75.png
error-windows-10-share-110x75.png.webp
error-windows-10-share-150x150.png

А если c $, получим то, что надо:
# ls | grep .png$
error-windows-10-share-110x75.png
error-windows-10-share-150x150.png

Можно совместить:
# ls | grep ^error | grep png$

А вместе символы ^$ означают пустую строку, что тоже удобно для чистки конфигурационных файлов. Удалим строки, начинающиеся на # и пустые:
# grep -E -v '^#|^$' nginx.conf

#bash #script

​​В выходные просматривал тематические ролики из youtube, которых накопилось некоторое количество. В одном из них увидел упоминание веб интерфейса для Ansible. Речь идёт про ролик: This web UI for Ansible is so damn useful!. Я сразу обратил на него внимание и запомнил, чтобы посмотреть, когда будет время.

В видео речь идёт про Ansible Semaphore. Я видел недавно его упоминание в некоторых TG каналах. Подумал, что выкатили какой-то новый продукт, поэтому на него обратили внимание. Но на самом деле нет. Это старый open source проект из 2015 года. Ранее о нём не слышал, поэтому решил посмотреть, что это такое. Специально никогда не искал веб интерфейс для Ansible, как-то не было необходимости. Вообще не знаю ни одного бесплатного решения для этой задачи.

Как я уже сказал, Ansible Semaphore — open source проект, написанный на чистом Go, а веб интерфейс с примесью Vue. С его помощью можно создавать и запускать плейбуки, превращая всё это в подобие CI/CD системы на минималках. То есть это для тех, кому не надо GitLab или Jenkins, но хочется автоматизации на базе ansible.

Для понимания возможностей Ansible Semaphore, покажу, какие там реализованы сущности. Тогда станет понятно, что он умеет. Там реализованы:
◽Задачи, для запуска плейбуков.
◽Шаблоны для этих задач.
◽Репозитории для подключения кода плейбуков и приложений.
◽Инвентарь, то есть список серверов, для которых можно выполнять задачи.
◽Хранилище ssh ключей и переменных.

Посмотреть всё это можно в публичном demo:
⇨ https://demo.ansible-semaphore.com

Работает всё это как обычная CI/CD система. Подключаем репозиторий с приложением, репозиторий с плейбуками. Создаём задачу, которая следит за репозиторием приложения и в случае коммита выполняет какие-то плейбуки из репозитория с ними.

Настроить всё это дело в Ansible Semaphore легко. Настроек немного, можете ознакомиться сами в Demo. Я посмотрел видео, чуток почитал доков (там совсем немного, сразу понятна последовательность действий) и посмотрел, как это реализовано в демке.

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

У меня для личного использования есть отдельная виртуалка с ansible, откуда я запускаю все свои плейбуки. Туда как раз будет уместно поставить Ansible Semaphore.

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

#ansible #devops

​​Автор классного ютуб канала RomNero выпустил подробное видео с разбором чат-сервера на базе протокола [matrix]. Я делал по нему заметку пару лет назад, а лет пять назад тестировал и писал статью. Ссылку не даю, так как нет смысла. Она уже сильно устарела.

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

Недавно я успешно внедрил в небольшой компании (60-70 сотрудников) Rocket.Chat. Уже накопился некоторый опыт по настройке, поддержке, обновлению, бэкапу и т.д. Думаю, ещё немного подожду и напишу подробную статью. У этого решения есть как плюсы, так и минусы. Я остановился на нём, потому что он популярен, отзывы в целом неплохие. Плюсов больше чем минусов. Субъективно, мне кажется это наиболее подходящим вариантом на текущий момент по совокупности факторов.

Возвращаюсь к видео: Matrix messenger. Лучшая, бесплатная и ДЕЦЕНТРАЛИЗОВАННАЯ сеть для общения. Я его посмотрел целиком, было интересно, хотя почти вся информация была мне известна. Но если вы не знакомы с этим решением, то рекомендую.

Автор объяснил принцип работы протокола Matrix и чат-сервера на его основе Synapse. Он подробно разобрал установку и настройку сервера и клиентов, начиная от создания DNS записей и заканчивая просмотром логов для решения проблем.

Со стороны решение на базе Matrix выглядит привлекательно. Лично меня останавливает от его использования мало реальных отзывов и личного опыта тех, кто его использовал. Не понятно, насколько в итоге это всё удобно за пределами тестовых лабораторий, стендов и заметок с обзорами. По конкурентам такие отзывы и опыт есть (Mattermost, Zulip, Rocket.Chat).

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

#chat

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

Основные проблемы будут в том, что либо команда на удаление будет выполняться очень долго, либо она вообще не будет запускаться и писать что-то типа Argument list too long. Даже если команда запустится, то выполняться может часами и вы не будете понимать, что происходит.

Я взял несколько наиболее популярных способов для удаления файлов и каталогов и протестировал скорость их работы. Среди них будут вот такие:
# rm -r test/
# rm -r test/*
# find test/ -type f -delete
# cd test/ ; ls . | xargs -n 100 rm #только для файлов работает
И последняя команда, ради которой всё затевалось:
# rsync -a --delete empty/ test/
Мы создаём пустой каталог empty/ и копируем его в целевой каталог test/ с файлами. Пустота затирает эти файлы.

Я провёл два разных теста. В первом в одном каталоге лежат 500 тыс. файлов, во втором создана иерархия каталогов одного уровня, где в каждом лежит немного файлов. Для первого теста написал в лоб такой скрипт:

#!/bin/bash

mkdir test
count=1
while test $count -le 10
do touch test/file$count-{000..50000}
count=$(( $count + 1 ))
done
ls test | wc -l

Создаю 500 000 файлов в цикле по 50 000 с помощью touch. Больше за раз не получается создать, touch ругается на слишком большой список аргументов. После этого запускаю приведённые выше команды с подсчётом времени их выполнения с помощью time:
# time rm -r test/
и т.д.

Я не буду приводить все результаты, скажу только, что вариант с rsync самый быстрый. И чем больше файлов, тем сильнее разница. Вариант с rm -r test/* в какой-то момент перестанет работать и будет ругаться на большое количество аргументов.

Для второго теста сделал такой скрипт:

#!/bin/bash

count=1
while test $count -le 10
do mkdir -p test/dir$count-{000..500}
touch test/dir$count-{000..500}/file-{000..100}
count=$(( $count + 1 ))
done
find test/ | wc -l

Создаю те же 500 000 файлов, только не в одной директории, а в 50 000, в каждой из которых внутри по 100 файлов. В такой конфигурации все команды отрабатывают примерно одинаково. Если директорий сделать те же 500 000, а суммарное количество файлов увеличить до 5 000 000, то разницы всё равно нет. Не знаю почему. Если будете тестировать, не забудьте увеличить стандартное количество inodes, быстро упрётесь в лимит в ext4.

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

Кстати, насчёт rsync я когда-то давно писал заметку и делал мем. Как раз на тему случайного удаления полезных данных, если перепутать в аргументах источник и приёмник. Если сначала, как в моём примере, указать пустую директорию, то вы очень быстро удалите все свои полезные файлы, которые собирались скопировать.

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

#linux #bash #script #rsync

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

✅ Linux 🐧

◽traceroute - стандартная утилита Linux для трассировки маршрута. По умолчанию использует udp протокол. С icmp протоколом запускать вот так:
# traceroute -I ya.ru

◽tracepath - похожа на traceroute, использует udp протокол, сразу же в выводе по умолчанию показывает значения mtu и маршрутизаторы, где оно меняется.
# tracepath ya.ru

◽mtr - про эту утилиту делал отдельную заметку. Она совмещает функциональность ping и traceroute одновременно. Может использовать протоколы tcp, udp, icmp. В Windows тоже есть под названием Winmtr.

✅ Windows 💻 

◽tracert - стандартная утилита в Windows для трассировки маршрута. Известна всем.
Использование:
> tracert ya.ru

◽pathping - это чисто виндовый аналог mtr со схожей функциональностью, но поддерживает только icmp запросы. Тоже сочетает в себе ping и tracert. Обычно есть в системе, ставить отдельно не надо.
Использование:
> pathping ya.ru

◽tracetcp - виндовая утилита, которая умеет делать tcp syn запросы по пути следования пакетов, чтобы проверить доступность того или иного порта. Позволяет узнать, где конкретно блокируется какой-то порт. Может делать проверки там, где icmp или udp заблокированы. Надо ставить вручную, скачав с сайта.
Использование:
> tracetcp ya.ru:443
Не знал, что есть программа с такой возможностью. Если где-то по пути порт будет заблокирован, она укажет на этот узел. На Linux аналога не знаю, хотя он бы не помешал.

#network

​​Рассказываю вам про очень классную систему видеонаблюдения. Мне её посоветовали давно, когда я делал публикацию про свою систему видеонаблюдения, которую на даче настроил. И только сейчас дошли руки посмотреть insentry.io. Это в разы лучше того, что получилось у меня.

Insentry — большое коммерческое решение для видеонаблюдения и аналитики. Используется в крупных компаниях, в том числе государственных (например, метрополитен). При этом у них есть абсолютно бесплатная, без каких-либо ограничений лицензия на 16 камер. Доступна вся функциональность редакции Standart, в том числе распознавание номеров автомобилей и лиц людей. На это даётся 10 детекторов. Ограничения на размер хранилища нет.

Запустить сервер Insentry можно в Windows или Linux. В последнем есть готовый Docker образ, который я запустил. Делается всё буквально за 5 минут. Запускаем:

# docker volume create --name insentry-data
# docker run \
--name insentry_watch \
--detach \
--restart unless-stopped \
--network host \
--volume insentry-data:/var/lib \
--volume /etc/timezone:/etc/timezone:ro \
--volume /etc/localtime:/etc/localtime:ro \
--stop-timeout 60 \
cr.yandex/crp5a5q503oamalo3iou/insentry-watch/linux/amd64:23.1.0.27

Идём в веб интерфейс на порт хоста 9200 и создаём нового пользователя. И сразу же оказываемся в веб интерфейсе. Я запустил его в компании, где используется платный видеосервер от LTV и подключил для теста одну камеру. Даже не заходил на неё. Указал IP и учётку. Insentry сам нашёл потоки и добавил их в систему. Через браузер стал возможен просмотр.

Выглядит всё это очень удобно и функционально для бесплатного решения. При этом не нужны никакие регистрации и лицензии. Просить её будут только тогда, когда добавите 17-ю камеру. Да и та стоит всего 1000 р. за лицензию.

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

У продукта аккуратная и небольшая документация, в которой всё по делу. Увидел руководство по установке на Raspberry Pi 4B. Судя по всему, ресурсов этому серверу надо не много, раз он готов работать на одноплатнике.

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

Напомню, что ранее рассказывал про ещё одно отечественное решение SecurOS Lite. Там тоже есть бесплатная версия на 32 камеры, но совсем без аналитики и без мобильных приложений. Там это только в платных редакциях. И сервер только под Windows. У Insentry меньше камер, зато аналитика есть в бесплатной лицензии и сервер под Win и Lin на выбор.

⇨ Сайт

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

​​Сегодня в обед прилёг хостер vdsina, на котором живёт мой сайт. Точнее его локация в Москве. Причём прилёг очень интересно. У него судя по всему проблемы с дисковой подсистемой. Виртуалка работает, но всё, что связано с дисковыми операциями записи, зависает. В итоге я спокойно захожу по SSH, открываю htop и смотрю LA > 50. Если пытаюсь что-то делать в консоли, то подключение зависает.

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

Как это обычно бывает, с переездом возникли проблемы. Расскажу, как у меня устроен бэкап и мониторинг сайта. Бэкапов к меня много:
◽в S3 хранилище дневные, недельные и месячные архивы
◽сервер дома, который сам по ssh ходит и забирает данные
◽копия бэкапов в яндекс.диске
◽копия бэкапов в Synology

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

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

В такой схеме достаточно просто переключить DNS записи и всё заработает на новом сервере. Конечно, без веских причин делать это не хочется, потому что после этого придётся перенастраивать всю схему бэкапа, мониторинг и сбор логов. Это всё хлопотно, потому что не автоматизировано. А не автоматизировано, потому что виртуалки не точные копии друг друга, а используются в том числе и для других целей. Нельзя взять и автоматом накатить все настройки с одного сервера на другой.

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

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

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

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

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

Если интересно, могу более подробно расписать всю эту схему, но тут надо будет целую серию заметок делать, так как материала будет много.

#webserver

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

Я покажу на примере системы Debian и СУБД MariaDB, как настроить аудит всех действий с сервером. Это будет полная инструкция, по которой копированием команд можно всё настроить.

Ставим сервер и выполняем начальную настройку:
# apt install mariadb-server
# mysql_secure_installation

Заходим в консоль Mysql:
# mysql -u root -p

Устанавливаем плагин:
> install plugin server_audit soname 'server_audit.so';
В Debian этот плагин присутствует по умолчанию. Проверить можно в директории /usr/lib/mysql/plugin наличие файла server_audit.so.

Смотрим информацию о плагине и его настройки:
> select * from information_schema.plugins
where plugin_name='SERVER_AUDIT'\G
> show global variables like 'server_audit%';

По умолчанию аудит в СУБД отключён. За это отвечает параметр server_audit_logging. Активируем его:
> set global server_audit_logging=on;

Теперь все действия на сервере СУБД будут записываться в лог файл, который по умолчанию будет создан в директории /var/lib/mysql в файле server_audit.log.

Записываться будут все действия для всех пользователей. Это можно изменить, задав явно параметр server_audit_events, который будет указывать, какие события записываем. Например так:
> set global server_audit_events='QUERY;
В этом параметре поддерживаются следующие значения: CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL, QUERY_DML_NO_SELECT.

Для пользователей можно настроить исключения. То есть указать, для какого пользователя мы не будем вести аудит. Список этих пользователей хранится в параметре server_audit_excl_users. Тут, в отличие от предыдущего параметра, мы указываем исключение. Управляется примерно так:
> set global server_audit_excl_users='user01';

Все подробности по настройке плагина есть в официальной документации.

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

Максимально просто и быстро мониторинг на события можно настроить и в Zabbix. К примеру, сделать отдельные айтемы для строк только с конкретными запросами, например UPDATE или DELETE, или записывать только коды выхода, отличные от 0. Далее для них настроить триггеры на превышение средних значений в интервал времени на какую-то величину. Если происходят всплески по этим строкам, получите уведомление. Но сразу предупрежу, что Zabbix не очень для этого подходит. Только если событий немного. Иначе лог аудита будет занимать очень много места в базе данных Zabbix. Это плохая практика.

Придумать тут можно много всего в зависимости от ваших потребностей. И всё это сделать относительно просто. Не нужны никакие дополнительные средства и программы.

#mysql #security

DevOps CI/CD automation

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

Взял отсюда.

#юмор

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

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

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

Я ожидал, что TryHackMe ограничит доступ для пользователей из РФ, но нет. Без проблем зарегистрировался и получил доступ к выполнению заданий. Всё обучение на английском языке.

Если реально настроитесь обучаться на этом портале, то рекомендую репозиторий по теме и конкретно вот этот документ: From Beginner to Expert Tryhackme Walkthrough.

#обучение #бесплатно #security

Один читатель прислал ссылку на любопытную статью: Сисадмины обречены. В ближайшее время их ждет профессиональная смерть.
⇨ https://www.cnews.ru/news/top/2023-06-08_sistemnye_administratory

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

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

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

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

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

Наверняка в комментариях появятся люди, которые будут писать, что сейчас наоборот, надо всё у себя хранить, облака ненадёжны, в облаках, значит у чужого дяди и т.д. Да, где-то это актуально, но если смотреть глобальную статистику всего сектора IT, то тенденции будут к укрупнению и централизации, а не размежеванию. Облачных провайдеров всё больше и больше. Недавно МТС выкатили своё огромное публичное облако с кучей собственных ЦОДов по всей стране.

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

#мысли

​​Давно не было заметок на тему удалённого управления компьютерами. Напомню, что все наиболее известные программы я уже обозревал и собрал их в одной статье: Топ бесплатных программ для удалённого доступа. Также все подобного рода программы объединены тэгом #remote

Сегодня речь пойдёт об очень интересном и полностью бесплатным (open source) проекте Remotely. Я не буду его описывать, а просто расскажу, как на практике выглядит разворачивание и использование этой системы удалённого доступа. Это будет более наглядно для понимания его работы.

1️⃣ С помощью Docker в пару команд вы запускаете сервер Remotely на любом Linux дистрибутиве. Он сразу же становится доступен через Web интерфейс. Можно зайти и зарегистрировать пользователя.

2️⃣ Скорее всего вам захочется настроить TLS сертификаты или как-то ограничить доступ к веб интерфейсу. Для этого можно настроить Nginx в режиме проксирования.

3️⃣ На целевой машине, которой будете управлять, заходите на адрес веб интерфейса и скачиваете клиента под свою систему. Поддерживается Windows и Linux. Запускаете его, получив ID подключения.

5️⃣ Через веб интерфейс администратор может, зная ID, подключиться к целевой машине. Можно настроить как безусловное подключение, так и с подтверждением со стороны пользователя.

6️⃣ Вы можете создавать организации и отделы и распределять управляемые машины по этим организациям. И создавать различных пользователей с привязкой к этим организациям. То есть система готова к большим распределённым структурам с ограничением доступа.

Из дополнительных возможностей Remotely отмечу:
- Уведомления на email.
- Простенький API.
- Через смартфон веб интерфейс и подключение к хостам тоже доступны, хотя пользоваться неудобно.
- На управляемых компьютерах можно удалённо запускать команды и скрипты.
- Поддерживается брендирование.

▶️ Совсем недавно вышло подробное видео с описанием установки и настройки Remotely. Оно на 100% актуально. Там наглядно и подробно описаны все шаги. Можно использовать как для обзора и знакомства, так и для внедрения.

Remotely можно сравнить с MeshCentral. Похожи тем, что оба работают полностью через веб интерфейс, в том числе подключение к машинам. Кто из них лучше, сказать трудно. Первый написан на C# под .NET 6, второй на JS под Nodejs. Тут я затрудняюсь оценить, что теоретически должно быть лучше в плане языка программирования. Оба активно развиваются, выходят новые версии.

⇨ Исходники

#remote

В ОС на базе Linux есть сокеты. Перекочевали они из Unix, поэтому называются сокетами unix. Сходу обычно не очевидно, что это такое, особенно когда какой-нибудь php-fpm или mysql может работать по tcp или через сокет. И надо выбрать, как ты хочешь, чтобы он работал.

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

❗️Насчёт производительности важно понимать, что разницу вы заметите только при очень больших нагрузках. Для какого-нибудь среднестатистического веб сервера с сайтами большой разницы не будет. Скорее всего она будет в рамках погрешности измерений. Использовать unix сокет предпочтительно, если доступ к сервису нужен только локальный. Тогда извне гарантированно никто не подключится, в отличите от обычного сетевого доступа, где по недогляду можно открыть доступ к сервису для внешних подключений.

Быстро проверить работу сокета подручными средствами можно с помощью утилиты netcat:
# nc -U /run/mysqld/mysqld.sock
В ответ получите то же самое, что получили бы, если бы обратились к tcp порту через telnet:
# telnet 127.0.0.1 3306

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

#linux #system

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

Самый простой пример того, о чём я говорю — автоматическая замена определённого текста в заданных файлах. Мне лично чаще всего это нужно, когда что-то делаешь с исходниками сайтов. Помню, как свои первые сайты делал более 20-ти лет назад на чистом html в Dreamweaver. При этом страниц там было сотни. Обновлял вручную копипастом. Это было тяжело, но в то время большинство сайтов были статичными, так как бесплатных хостингов на php не существовало. Но это я отвлёкся, заметка планируется про другое.

Допустим, у вас есть какой-то большой сайт на php и вам надо во всех файлах заменить устаревшую функцию на новую. В общем случае замену текста можно сделать с помощью sed, примерно так:
# sed 's/old_function/new_function/g' oldfilename > newfilename

Или посложнее пример с вырезанием вредоносного куска кода из всех файлов, которые заразил какой-то вирус. Допустим, это некий код следующего содержания:
<script>function aeaab19d(a)...................</script>
Текста между тэгами script может быть много, поэтому искать проще всего по этому тэгу и началу строки с function aeaab19d(a).
# sed -r 's/<script>function aeaab19d\(a\).*?<\/script>//' test.php
Тут я использую ключ -r для поддержки регулярных выражений, конкретно .*?.

Можно ещё усложнить и выполнить замену кода между каких-то строк. Для усложнения возьмём какой-нибудь XML:
<username><![CDATA[user01]]></username>
<password><![CDATA[password01]]></password>
<dbname><![CDATA[database]]></dbname>
Заменим user01 на user02
# sed -r 's/(<username>.+)user01(.+<\/username>)/\1user02\2/' test.xml
Тут важны круглые скобки и \1 и \2. Мы в первой части выражения запомнили текст в круглых скобках, а во второй части его использовали — сначала первую скобку, потом вторую.

Это были примеры для одиночных файлов, а теперь добавляем сюда find и используем sed на любом наборе файлов, который найдёт find.
# find /var/www/ -type f -name \*.php -exec \
sed -i -r 's/<script>function aeaab19d\(a\).*?<\/script>//' {} \;
Добавляем к sed ключ -i для того, чтобы он сразу изменял файл. Кстати, для find наиболее популярные примеры можете посмотреть через тэг #find.

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

Примеры рекомендую записать. Если надо быстро что-то сделать, то сходу правильно регулярку вы так просто не наберёте. К тому же в таком использовании есть свои нюансы. К примеру, я так и не смог победить команду sed, которая удаляет весь код <script>, если внутри есть переход на новую строку. Вроде бы легко найти, как заставить . в регулярках учитывать и переход на новую строку, но на практике у меня это не получилось сделать. Я не понял, как правильно составить выражение для sed.

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

#linux #bash #script

​​Затрону важную и очень спорную тему готовых сборок операционных систем. Думаю, многие ими пользуются или пользовались. И я пользовался, последние года очень мало, но тем не менее. Думаю, что больше не буду. Последняя сборка была tiny11. Про неё было много негативных комментариев. Я её поставил на древний ноут, отключил обновления и отправил на дачу. Там дети мультики на нём смотрят с внешнего диска. Проблем у меня с ней нет.

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

Я сам очень активно в разное время пользовался сборками следующих сборщиков: Zver (это легенда, не понимаю, за что его ругают, удобные сборки были), KpoJIuK, OVGorskiy, SmokieBlahBlah. Последнего использовал постоянно, начиная с Win8. Нравились его сборки сразу с офисом. Я не активировал никакие твики, настройки и т.д. Мне нужна была Windows с последними обновлениями и желательно с офисом. И всё.

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

Кстати, под Linux тоже куча всяких сборок. Я их никогда не использовал и не видел смысла, так как нет такой проблемы с обновлениями, которые ставятся потом пол дня. Потенциально для них актуальны те же угрозы. Когда-то очень давно ещё во время обучения запускал LiveCD Knoppix и какой-то LiveCD под Freebsd. Даже название забыл, уже не вспомню. Но это так, для тестов и изучения. В работе не пользовался.

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

#windows #security

​​Смотрел на днях на одну интересную бесплатную панель управления хостингом. Про неё будет завтра отдельная заметка. Там вместо Nginx используется LiteSpeed Server, а точнее его open source версия — OpenLiteSpeed. Я с ним очень слабо знаком, поэтому решил навести справки — что это такое, в чём преимущество и почему кто-то решает использовать его, а не проверенный временем Nginx. Когда я его смотрел несколько лет назад, мне он показался каким-то местечковым продуктом без особых перспектив. Я ошибся.

В сети много материалов на тему как LiteSpeed, так и его сравнения с Nginx. Причём материалы и результаты тестов зачастую противоречивы. Каких-то явных преимуществ по производительности одного сервера по сравнению с другим нет, как это было, когда появился Nginx и его сравнивали с Apache. Там различия были значительные и это сразу было видно. Здесь не так. Можно подобрать тесты, где лучше будет один, а в других тестах — другой.

Перечислю особенности LiteSpeed:
◽Совместимость с Apache: правила Rewrite, ModSecurity, .haccess файлы (только в платной версии), понимает конфиги apache в неизменном виде (только в платной версии) и другие возможности.
◽Поддержка многих современных протоколов и технологий: HTTP/3, QUIC, сжатие Brotli и другие.
◽Свой обработчик php — LSAPI.
◽Есть готовый набор плагинов от разработчиков для поддержки популярных панелей управления хостингом или CMS. Например, Wordpress. Для него там очень крутой плагин интеграции.
◽Модуль интеграции PageSpeed Module, интеграция с reCaptcha.
◽Встроенная интеграция с Redis для хранения кэша.
◽Встроенный веб интерфейс для управления, может заменить кому-то веб панели управления хостингом.

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

1️⃣ Для настройки кэширования сайтов Wordpress приходится устанавливать отдельно плагины для статического кэша. Потом отдельно настраивать правила Nginx для быстрой отдачи этого кэша мимо движка Wordpress и обработчика php. У LiteSpeed есть готовый плагин под Wordpress, который всё это делает автоматически, плюс там же и поддержкa Redis. А интеграцию с ним в Nginx тоже надо будет настраивать отдельно. То есть конкретно в этой ситуации LiteSpeed очень сильно упрощает настройку. А CMS Wordpress это, на минуточку, чуть ли не половина всех сайтов в интернете.

2️⃣  Второй пример с шифрованием brotli. Для Nginx приходится вручную собирать свой пакет с поддержкой модуля brotli. Я даже статью когда-то писал об этом. Хлопотное занятие, хотя почему бы не использовать brotli. Он всеми поддерживается, жмёт лучше gzip. Я одно время пользовался, потом надоело собирать самому и забил. В LiteSpeed это работает из коробки.

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

Вывод назрел такой. Если вам не нужны дополнительные возможности LiteSpeed, использовать его нет смысла. Сам ядро веб сервера, насколько я понял, работает плюс минус так же по производительности. Nginx — оптимизированное и эффективное решение. Так просто по производительности его не превзойти. А вот если надо больше, то тут уже можно смотреть на LiteSpeed. Одна только полная совместимость с Apache чего стоит. Надо будет попробовать посадить на него Bitrix. Неужели без всяких изменений поедет быстрее, чем на Apache? Это будет круто. Но кажется это возможно только в платной версии. В open source частичная поддержка apache.

#webserver #litespeed