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

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

Пользуясь случаем, хочу попросить проголосовать за мой канал, так как это открывает некоторые дополнительные возможности по настройке: https://t.iss.one/boost/srv_admin.

📌 Больше всего пересылок:
◽️Сборка Windows 11 Enterprise G (612)
◽️Настройка NFS сервера (482)
◽️RDP Defender для защиты RDP подключений (409)
◽️Утилита ss вместо netstat (387)
◽️Ограничение потребления памяти с помощью systemd (364)

📌 Больше всего комментариев:
◽️Массовый BSOD на Windows (362)
◽️Настройка NFS сервера (223)
◽️Гипервизор для одной виртуальной машины (207)

📌 Больше всего реакций:
◽️Гипервизор для одной виртуальной машины (233)
◽️Сборка Windows 11 Enterprise G (200)
◽️Утилита ss вместо netstat (181)

📌 Больше всего просмотров:
◽️Массовый BSOD на Windows (9855)
◽️Бесплатные курсы от Selectel (9854)
◽️Дистрибутивы Linux в браузере (9635)

#топ

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

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

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

# apt install scalpel

Далее нам нужно указать сигнатуры восстанавливаемых файлов. Часть сигнатур есть в самом файле конфигураций - /etc/scalpel/scalpel.conf. Ещё более подробный список можно посмотреть тут в репозитории. Я не совсем понял, какие заголовки должный быть у обычного текстового файла, коим являлся мой скрипт. По идее там особых заголовков и нет, а искать можно по содержимому. Так что я добавил в scalpel.conf следующее:

NONE   y   1000   #!/bin/bash

В данном случае #!/bin/bash это начало моего скрипта. Я их все так начинаю. Запускаем сканирование с выводом результатов в /tmp/restored:

# mkdir /tmp/restored
# scalpel /dev/mapper/zabbix-vg-root -o /tmp/restored

zabbix-vg-root - корневой и единственный lvm раздел этого сервера. Если у вас не используется lvm, то это будет что-то вроде /dev/sda2 и т.д.

Программа минуты за 3-4 просканировала раздел на 50G и вывела результаты в указанную директорию. Там было около сотни различных текстовых скриптов, а нужный мне был где-то в самом начале списка, так что мне даже по содержимому искать не пришлось. Сразу нашёл при беглом осмотре. Всё содержимое файла сохранилось.

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

#restore #linux

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

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

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

2️⃣ Можно посмотреть список изменённых файлов за последнее время. Не факт, что поможет, так как изменить дату модификации файла не сложно, но тем не менее, это может помочь:

# find /var/www/site -type f -mtime -30 ! -mtime -1 -printf '%TY-%Tm-%Td %TT %p\n' | sort -r

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

3️⃣ Смотрим журналы операционной системы, в том числе аутентификации по SSH. На них хорошо бы ставить мониторинг и отправлять эту информацию на сторонний лог сервер. Смотрим задачи cron, at и systemd timers. Куда конкретно смотреть, писал в отдельной заметке по запланированным задачам.

4️⃣ Не часто, но иногда можно что-то увидеть в истории shell команд или истории команд клиентов СУБД:
◽ # cat ~/.bash_history
◽ # cat ~/.mysql_history
◽ # sudo -u postgres psql
◽ # \s

5️⃣ Имеет смысл проверить целостность исполняемых файлов согласно эталонным хеш-значениям из DEB и RPM пакетов.

# dpkg --verify
# rpm -Va

6️⃣ Проверяем системных пользователей, прописанные для них шеллы, прописанные ключи для SSH соединений. Проверяем домашние директории пользователей, от которых работает веб сервер и другие запущенные службы, на предмет подозрительных скриптов. То же самое делаем во временных директориях.

7️⃣ Проверяем прослушиваемые приложениями порты и исходящие подключения:

# ss -tulnp | column -t
# ss -ntu

8️⃣ На всякий случай можно посмотреть и список процессов. Иногда там и вручную глаз за что-то зацепится. Майнеров сразу будет видно.

# ps axf

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

⇨ Взлом сервера centos через уязвимость Bash Shellshock
⇨ Взлом сервера через уязвимость на сайте
⇨ Заражение web сервера вирусом криптомайнером
⇨ Как взламывают веб сервера

#security

В продуктах Proxmox не так давно появилась возможность использовать сторонние SMTP сервера для отправки уведомлений. Точнее, стало возможно через веб интерфейс настроить аутентификацию на внешнем сервере. В PVE вроде бы с 8-го релиза появилась эта настройка, в PBS не помню точно.

В разделе меню Notification обоих продуктов появился новый тип уведомлений SMTP, где можно указать привычные параметры внешних почтовых серверов. Тем не менее, если для отправки используется бесплатный почтовый сервис типа Yandex, Mail или Gmail, я предпочитаю настраивать по старинке через локальный Postfix, который так же использует внешний SMTP сервер с аутентификацией.

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

Настройка Postfix простая. Не помню, устанавливается ли он в свежих версиях PVE и PBS по умолчанию, но если нет, то надо поставить:

# apt install postfix

И затем добавить в конфиг /etc/postfix/main.cf, например, для Яндекса:

relayhost = smtp.yandex.ru:465
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_generic_maps = hash:/etc/postfix/generic

Если эти же параметры где-то выше уже объявлены, то закомментируйте их там. Создаём файл /etc/postfix/sasl_passwd такого содержания:

smtp.yandex.ru [email protected]:userpass123

Эти данные нужны для аутентификации. Убедитесь, что у файла права 600, чтобы никто, кроме рута, не смог его прочитать.

Создайте файл /etc/postfix/generic:

root@pve [email protected]

Здесь мы настраиваем, чтобы все письма от локального пользователя root сервера с именем pve отправлялись с заменой адреса отправителя на [email protected]. Иначе Яндекс не примет письмо к отправке. У других почтовых сервисов может не быть таких ограничений и этот шаг можно будет пропустить.

Формируем на основе текстовых файлов локальные базы данных, с которыми будет работать postfix, и перезапускаем его:

# postmap /etc/postfix/generic /etc/postfix/sasl_passwd
# systemctl restart postfix

Можно проверять отправку. Проще всего это сделать в веб интерфейсе PVE. Для этого идём в раздел Datacenter ⇨ Notification. Там по умолчанию уже есть способ отправки типа sendmail с указанным Target mail-to-root. Это как раз отправка почты с помощью Postfix на ящик системного пользователя root@pam. Ящик для него можно указать в настройках пользователя: Datacenter ⇨ Permissions ⇨ Users ⇨ root ⇨ E-Mail.

Выбираем способ отправки sendmail и жмём Test. Можно сходить в консоль сервера и проверить лог отправки. Если всё прошло успешно, то в /var/log/mail.log будет примерно следующее:

pve postfix/pickup[941603]: 4C81718E07A1: uid=0 from=<[email protected]>
pve postfix/cleanup[941760]: 4C81718E07A1: message-id=<20240820202545.4C81718E07A1@pve>
pve postfix/qmgr[941604]: 4C81718E07A1: from=<[email protected]>, size=894, nrcpt=1 (queue active)
pve postfix/smtp[941762]: 4C81718E07A1: to=<[email protected]>, relay=smtp.yandex.ru[77.88.21.158]:465, delay=0.48, delays=0.03/0.02/0.17/0.26, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net 1724185545-jPUEPlgXtGk0-KOiggjh6)
pve postfix/qmgr[941604]: 4C81718E07A1: removed

Сервер успешно использовал relay=smtp.yandex.ru и отправил с его помощью письмо [email protected], получив status=sent. Письмо ушло адресату, отправляющий сервер принял его в обработку.

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

#proxmox

Вчера в комментариях к заметке со скриптом речь зашла про шебанг (shebang). Слово какое-то непонятное. Я первые года и Unix админил, и скрипты писал, и слова такого не знал, пока случайно не услышал.

Шебанг - это то, с чего начинается практически любой скрипт:

#!/bin/bash

или так

#!/bin/sh

Интуитивно и так было понятно, для чего это. Конструкцию с sh я использовал, когда работал с FreeBSD. Перейдя на Linux, стал использовать bash. Причём именно в таком виде:

#!/bin/bash

Хотя указывать его можно не только так. Но абсолютно во всех дистрибутивах, с которыми я работал, по /bin/bash был именно bash либо в явном виде, либо символьной ссылкой на него. Так что если не хотите лишний раз забивать себе голову новой информацией, то пишите так же. Вероятность, что что-то пойдёт не так, очень мала. У меня ни разу за всю мою карьеру с таким шебангом проблем на Linux с bash скриптами не было. Исключение - контейнеры. Там отсутствие bash - обычное дело. Но там тогда и скрипты не будут нужны.

Тем не менее, шебанг можно указать и более точно без привязки к конкретному пути в файловой системе:

#!/usr/bin/env bash

Расположение bash будет взято из окружения, в котором будет запускаться скрипт. Так писать дольше, поэтому я такую конструкцию не использую.

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

# bash script.sh

А если не указать явно, то будет использована оболочка по умолчанию. Большая часть скриптов, с которыми я работаю, успешно отработает и в sh, и в bash. Именно эти оболочки наиболее распространены, остальное экзотика для серверов. Есть ещё dash, но, насколько я помню, она полностью совместима с sh.

В шебанге можно указать какие-то нюансы интерпретатора. В основном это актуально для python. Он как минимум может быть разных версий на одной и той же системе. Особенно это было актуально во времена перехода с python2 на python3. Когда был только python2 в шебангах могли указать python и скрипт выполнялся 2-й версией, так как именно она была в системе по умолчанию. Когда в системах стала появляться 3-я версия, для старых скриптов надо было отдельно ставить 2-ю и явно её указывать, либо редактируя шебанги в скриптах, либо запуская нужную версию явно:

# python2 script.py

Из экзотического применения шебангов можно привести примеры с awk или ansible:

#!/usr/bin/awk -f

#!/usr/bin/env ansible-playbook

И awk, и ansible-playbook являются интерпретаторами кода, так что для простого и быстрого запуска скриптов, написанных для них, можно использовать соответствующие шебанги, чтобы сразу запускать скрипт по аналогии с башем:

# ./my-playbook.yaml

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

Строки с шебангом могут содержать дополнительные аргументы, которые передаются интерпретатору (см. пример для awk -f выше). Однако, обработка аргументов может различаться, для переносимости лучше использовать только один аргумент без пробелов внутри. Теоретически это можно обойти в env, но на практике я не проверял. Увидел сам вчера в комментариях:

#!/usr/bin/env -S python3 -B -E -s

#bash

​​Приезжал на днях в квартиру, где совершенно не работает Youtube. Всё лето живу на даче с мобильным интернетом. С замедлением ютуба не сталкивался. На мобильном он работает нормально. А в квартире мобильная связь не очень, пользоваться некомфортно, поэтому всё на проводном интернете. Без ютуба совсем грустно. В качестве роутера работает Mikrotik.

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

⇨ https://disk.yandex.ru/d/RAbdhp0lAFBfOw

Я промаркировал этот список через mangle и сделал отдельный маршрут для этого маркированного списка через зарубежный VPS, к которому подключаюсь по OpenVPN. Теперь Youtube работает нормально сразу для всех домашних. Простое и удобное решение без лишних заморочек. Несмотря на то, что многие говорят, что openvpn и wireguard блокируют, у меня они пока работают нормально. Провайдер - Ростелеком.

#mikrotik

​​Для редактирования и совместной работы с документами через браузер есть два наиболее популярных движка с открытым исходным кодом:

▪️ OnlyOffice
▪️ Collabora Online

Про #OnlyOffice я регулярно пишу, можно посмотреть материалы под соответствующим тэгом. Там же есть инструкции по быстрому запуску продукта. Решил то же самое подготовить по Collabora Online, чтобы можно было быстро их сравнить и выбрать то, что больше понравится.

Движок для редактирования документов работает в связке с каким-то другим продуктом по управлению файлами. Проще всего потестировать его в связке с ownCloud. Запускаем его:

# docker run -d -p 80:80 owncloud

Идём по IP адресу сервера https://10.20.1.36, создаём учётку админа и логинимся. В левом верхнем углу нажимаем на 3 полоски, раскрывая меню и переходим в раздел Market. Ставим приложение Collabora Online.

Переходим опять в консоль сервера и запускаем сервер collabora:

# docker run -t -d -p 9980:9980 -e "extra_params=--o:ssl.enable=false" collabora/code

Возвращаемся в веб интерфейс owncloud, переходим в Настройки ⇨ Администрирование ⇨ Дополнительно. В качестве адреса сервера Collabora Online указываем https://10.20.1.36:9980. На этом всё. Можно загружать документы и открывать их с помощью Collabora Online. У меня без каких-либо проблем сразу всё заработало по этой инструкции. Работает, кстати, эта связка довольно шустро. Мне понравилось. Погонял там с десяток своих документов и таблиц.

Редактор Collabora Online сильно отличается от Onlyoffice как внешним видом, так и архитектурой. Если у Onlyoffice обработка выполняется на клиенте, что нагружает его, но снимает нагрузку с сервера, то Collabora Online всё обрабатывает на сервере. Мне кажется, это скорее плохо, чем хорошо. Ресурсов сервера потребляет в разы больше, чем Onlyoffice. Но при таком подходе надёжнее работает совместное редактирование, так как реально оно происходит на сервере, а клиентам передаётся только картинка.

Интерфейс Onlyoffice больше похож на Excel, интуитивно с ним проще работать. Основные форматы - .docx, .xlsx, .pptx. Соответственно и совместимость с ними лучше. Collabora построена на базе LibreOffice, а он заметно отличается от Excel, так что переход будет более болезненный. Основные форматы - .odt, .ods, .odp. Майкрософтовские документы открывает хуже.

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

#docs #fileserver

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

⇨ Свой распределённый S3 на базе MinIO — практический опыт наступания на грабли / Алексей Плетнёв

Выступление двухгодичной давности, но я его посмотрел только на днях. У крупной компании возникла потребность в большом файловом хранилище (100 TБ данных и 100 ТБ трафика в месяц). Готовые решения отбросили из-за дороговизны. Решили строить своё на базе известного сервера MinIO.

📌 Причины, почему выбрали MinIO:

◽Open Source
◽Производительный
◽Распределённая архитектура
◽Легко масштабируется и разворачивается
◽Сжатие файлов на лету
◽Общая популярность проекта

📌 Проблемы, с которыми столкнулись при внедрении и эксплуатации:

▪️ Не очень информативная документация
▪️ По умолчанию модель отказоустойчивости такова, что при неудачном стечении обстоятельств выход из строя буквально нескольких дисков на одном сервере может привести к потере информации, хотя на первый взгляд кажется, что чуть ли не потеря половины кластера не приведёт к этому
▪️ Нельзя расширить существующий кластер. Можно только создать новый и присоединить его к текущему.
▪️ При обновлении нельзя перезапускать ноды по очереди. Рестартить надо разом весь кластер, так что без простоя сервиса не обойтись.
▪️ Вылезла куча критических багов, когда пропадали все пользователи и политики, бились сжатые файлы, неверно работало кэширование и т.д.
▪️ Реальный срок восстановления после замены диска непрогнозируемый. Нагрузка при этом на диски сопоставима с эксплуатацией RAID5.
▪️ Нет мониторинга производительности дисков. Если один диск жёстко тормозит, тормозит весь кластер. Эту проблему ты должен решать самостоятельно.

Для полноценного теста отказоустойчивого распределённого хранилища достаточно следующего железа. 3 одинаковые ноды:

- 8 CPU
- 16G RAM
- SSD NVME для горячих данных
- HDD для холодных

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

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

Отдельно было интересно узнать мнение автора о Ceph. Они от него отказались из-за сложности в обслуживании. MinIO настроили один раз и он работает практически без присмотра. Ceph требует постоянного наблюдения силами специально обученных людей.

#S3

▶️ Пока ещё Youtube худо-бедно работает, продолжаем впитывать информацию. Тормозить стал уже и на мобильном интернете. Вчера явно заметил разницу. Пришлось пустить траф на ноуте через внешнюю прокси, чтобы нормально смотреть видео.

Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными и полезными.

⇨ Настройка роутера MikroTik с BGP для просмотра видео дома
Автор рассказал, как решить вопрос со скоростью ютуб с помощью динамической маршрутизации на роутерах Mikrotik.

⇨ Proxmox CLUSTER. Что это и зачем? Создание кластера из 3 узлов (nodes)
Описание работы кластера Proxmox и пример настройки кластера из трёх нод. Автор настраивает сеть, объединяет узлы в кластер, показывает на практике, как работает миграция виртуальных машин между узлами кластера, настраивает HA.

⇨ RocketChat - Powerful, Chat and Communications platform. Rivals Slack, Teams, and more!
Обзор бесплатного self-hosted чат-сервера. У меня было много заметок по нему на канале, можно найти через поиск. Я сам постоянно обслуживаю и немного использую Rocket.Chat. Знаю его неплохо. Не могу сказать, что он мне нравится, но из бесплатного ничего лучше не знаю. В целом, работает нормально. Если у кого-то есть по нему вопросы, можно задавать.

⇨ Подробное описание начальной настройки OPNsense с нуля
Огромное (1,5 часа) видео по настройке программного шлюза OPNsense. Автор разобрал настройки файрвола, vlan, управляемого свитча.

⇨ Установка Next Generation FireWall Zenarmor в OPNsense
Установка и настройка бесплатного NGFW (Next Generation Firewall) Zenarmor в софтовый файрвол OPNsense. Интересное решение, раньше не слышал о нём.

⇨ Proxmox: LXC контейнер показывает ерунду по CPU
Небольшой баг с LXC контейнерами в Proxmox, когда они показывают нагрузку не за себя, а по всему хосту. Я с этим, кстати, тоже сталкивался, но думал, что так и надо. Просто забивал. Решение очень простое, в видео приведено.

⇨ Synology BACKUP! Active Backup for Business. Обзор функий, настройка. Windows и Linux backup. VM
Встроенная в Synology система бэкапа для компьютеров и серверов под управлением Windows и Linux, а так же сетевых дисков и некоторых систем виртуализации. Автор на конкретных примерах показал, как это работает. Весьма функциональная, удобная и простая в настройке штука.

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

#видео

​​Для быстрого доступа к СУБД Mysql очень удобно использовать небольшой скрипт Adminer, который представляет из себя ровно один php файл и запускается на любом хостинге. Я бы не писал о нём в очередной раз, если бы не столкнулся на днях с некоторыми нюансами при его использовании, так что решил оформить в заметку, чтобы самому потом не забыть.

С помощью Adminer можно создать пользователя и базу данных, назначить или изменить права, посмотреть содержимое таблиц, выгрузить или загрузить дамп. Лично мне для административных целей больше ничего и не надо. Разработчики, работая над сайтом, обычно просят phpmyadmin. Я не очень его люблю, потому что он монструозный, для него надо ставить дополнительные расширения php, поддерживать это дело.

Если я пользуюсь сам, то обычно просто закидываю adminer на сайт, делаю, что мне надо и потом сразу удаляю. В этот раз решил оставить на некоторое время и закрыть через basic_auth в Nginx (на самом деле в Angie). Вроде бы нет ничего проще:

# wget https://github.com/vrana/adminer/releases/download/v4.8.1/adminer-4.8.1-mysql-en.php
# mv adminer-4.8.1-mysql-en.php /var/www/html/adminer.php

Закрываем паролем. Создаём файл с учёткой:

# htpasswd -c /etc/nginx/.htpasswd admineruser21

Добавляем в Nginx:

location /adminer.php {
auth_basic "Administrator’s Area";
  auth_basic_user_file /etc/nginx/.htpasswd;
}

Перезапускаю Nginx, проверяю. Пароль не спрашивает, доступ прямой. Всё внимательно проверяю, ошибок нет. Я 100 раз это проделывал. Тут нет никаких нюансов. Но не работает.

Быстро догадался, в чём тут дело. В Nginx есть определённые правила обработки locations. Я с этой темой когда-то разбирался подробно и кое-что в памяти осело. Ниже для php файлов уже есть location:

location ~ \.php$ {
....
}

Он с регулярным выражением, поэтому обрабатывается раньше и при первом же совпадении поиск прекращается. Так что до моего location с паролем очередь просто не доходит. Сделать надо так:

location ~ adminer.php {
  auth_basic "Administrator’s Area";
  auth_basic_user_file /etc/nginx/.htpasswd;
.......................  
}

Тут надо указать все те же настройки, что у вас стоят для всех остальных php файлов в location ~ \.php$. И расположить location с adminer выше location для остальных php файлов. Это важно, так как судя по документации:

Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location.

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

#webserver #nginx #mysql

​​В выходные youtube в рекомендации показал видео от сотрудника центра по восстановлению данных со сломанных накопителей. Видео скучное и малоинформативное, поэтому ссылку не привожу. Основная идея там была такая. Мастер не рекомендовал использовать SSD диски в качестве внешних дисков в боксах, потому что ячейки в них довольно часто теряют заряд при длительном хранении, особенно дешёвые, что приводит к потере данных. Рассказал он всё это на примере восстановления данных с одного из таких дисков.

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

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

#железо

​​Существует несколько наиболее популярных систем управления конфигурациями:

▪️ Saltstack 
▪️ Chef
▪️ Puppet
▪️ Ansible

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

🔹Saltstack - написана на Python, для работы на хосты устанавливается агент, хотя есть и безагентный режим работы с ограниченными возможностями. Проект стартовал в 2011 году. Работает по модели pull, где сервер публикует задачу, а агенты принимают ее и асинхронно выполняют практически в режиме реального времени. Архитектурно система разработана для поддержки огромных инфраструктур с тысячами и десятками тысяч серверов.

🔹Chef - написан на Ruby, также использует клиент-серверную архитектуру с агентами на хостах. Стартовал в 2009 году. Имеет большое сообщество и как следствие обширный набор "рецептов" по установке и настройки различного оборудования и софта. Например, Gitlab использует Chef для установки и управления self-hosted версии своего сервера.

🔹Puppet - написан на Ruby, также использует клиент-серверную архитектуру с агентами на хостах. Стартовал в 2005 году. Агенты периодически обращаются к серверу и забирают изменения настроек. Язык конфигурации довольно сложен, но и возможностей там очень много. Будет актуален для больших и сложных систем. Из того, что я помню, Foreman использует Puppet.

🔹Ansible - написан на Python, не требует установки агентов. Работает по модели push. В качестве транспорта использует SSH соединения. Проект стартовал в 2012 году, в 2015 его купил Red Hat и начался стремительный рост популярности. По факту сейчас это наиболее распространённая система управления конфигурациями. Её отличает простота настройки и запуска в работу. Будет актуальна даже на малых масштабах инфраструктуры. Есть ряд проблем на больших проектах с тысячами серверов. Возможно там это будет не самое подходящее решение. Язык разметки конфигураций YAML. Читается и пишется относительно легко. За счёт этого и отсутствия агентов для взаимодействия и стал так популярен. Есть хорошая документация, которой достаточно для эксплуатации.

На сегодняшний день системному администратору или девопсу обязательно надо знать Ansible, даже если вы сами не собираетесь описывать инфраструктуру с его помощью. Большое количество софта описано с помощью ролей Ansible. Это может сильно упростить установку и эксплуатацию. Например, через Ansible можно быстро развернуть Ceph, Kubernetes, кластер Patrony и т.д. Также под весь популярный софт попроще есть наборы плейбуков для установки, обновления. Тот же Zabbix агент обновлять или ставить с нуля на группу хостов. У меня была подборка обучающих материалов по Ansible.

Насчёт популярности остальных могу только субъективно погадать. Saltstack точно менее популярен остальных, а вот Puppet и Chef могут рядом идти, хотя Chef всё же наверное популярнее. Не знаю, кто из них лучше. Я только в общих чертах о них слышал, сам никогда не работал с ними. Не приходилось сталкиваться. А вот с Ansible постоянно.

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

#ansible

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

Особенно важно выполнять обновление систем в Tmux или Screen, так как обрыв соединения в этот момент может привести к реальным проблемам. Я и сам сталкивался, и читатели присылали свои проблемы по этой же части. У меня были заметки на этот счёт.

Для Tmux есть плагин Tmux Resurrect, который позволяет сохранить состояние Tmux со всеми панелями и окнами и порядком их размещения. Вы сможете подключиться в свою настроенную сессию не только в случае отключения, но и перезагрузки Tmux или всего сервера. То есть вы можете настроить в первом окне несколько панелей, к примеру, с htop, tail каких-то логов, переход в какую-то директорию. Во втором окне что-то ещё. Потом сохранить эту сессию. Даже если сервер будет перезагружен, вы сможете восстановить всё окружение.

Демонстрация, как это работает:
▶️  https://vimeo.com/104763018

Установить Tmux Resurrect можно либо через Tmux Plugin Manager, либо напрямую:

# git clone https://github.com/tmux-plugins/tmux-resurrect

Добавляем в ~/.tmux.conf в самое начало:

run-shell ~/tmux-resurrect/resurrect.tmux

Заходим в сессию Tmux и сохраняем её состояние через prefix + Ctrl-s, по умолчанию префикс это Ctrl-b, то есть жмём Ctrl-b потом сразу Ctrl-s. Внизу будет информационное сообщение, что сессия сохранена. Восстановить её можно будет через комбинацию Ctrl-b потом сразу Ctrl-r.

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

#linux #terminal

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

⇨ Расследуем фантомные чтения с диска в Linux

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

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

1️⃣ Через iostat смотрим нагрузку на диск и убеждаемся, что кто-то его активно читает. Сейчас уже не обязательно iostat ставить, так как htop может показать то же самое.

2️⃣ Запускаем blktrace в режиме наблюдения за операциями чтения с выводом результата в консоль:

# blktrace -d /dev/sda1 -a read -o - | blkparse -i -

Вывод примерно такой:

259,0  7   4618   5.943408644 425548 Q RA 536514808 + 8 [questdb-ilpwrit]

В данном случае RA 536514808 это событие чтения с диска начиная с блока 536514808.

3️⃣ Смотрим, что это за блок:

# debugfs -R 'icheck 536514808 ' /dev/sda1

debugfs 1.46.5 (30-Dec-2021)
Block Inode number
536514808 8270377

То есть этот блок имеет номер айноды 8270377.

4️⃣ Смотрим, что это за файл:

debugfs -R 'ncheck 8270377' /dev/sda1
Inode Pathname
8270377 /home/ubuntu/.questdb/db/table_name/2022-10-04/symbol_col9.d.1092

Нашли файл, который активно читает процесс questdb-ilpwrit.

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

Был уверен, что это можно сделать проще, так как я уже занимался подобными вопросами. Вспомнил про утилиту fatrace. Она заменяет более сложные strace или blktrace в простых случаях.

# apt install fatrace

Просто запускаем её и наблюдаем

# fatrace

В соседней консоли откроем лог:

# tail -n 10 /var/log/syslog

Смотрим в консоль fatrace:

bash(2143): RO /usr/bin/tail
tail(2143): RO /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
tail(2143): O  /etc/ld.so.cache
tail(2143): RO /usr/lib/x86_64-linux-gnu/libc.so.6
tail(2143): C  /etc/ld.so.cache
tail(2143): O  /usr/lib/locale/locale-archive
tail(2143): RCO /etc/locale.alias
tail(2143): O  /var/log/syslog
tail(2143): R  /var/log/syslog

Результат тот же самый, что и выше с blktrace, только намного проще. В fatrace можно сразу отфильтровать вывод по типам операций. Например, только чтение или запись:

# fatrace -f R
# fatrace -f W

Собираем все события в течении 30 секунд с записью в текстовый лог:

# fatrace -s -t 30 -o /tmp/fatrace.log

Не хватает только наблюдения за конкретным процессом. Почему-то ключ -p позволяет не задать конкретный пид процесса для наблюдения, а исключить из результатов операции процесса с этим pid:

# fatrace -p 697

Можно исключить, к примеру bash или sshd. Они обычно не нужны для расследований.

Рекомендую заметку сохранить, особенно про fatrace. Я себе отдельно записал ещё вот это:

# debugfs -R 'icheck 536514808 ' /dev/sda1
# debugfs -R 'ncheck 8270377' /dev/sda1

#linux #perfomance

​​Развернул и потестировал очень любопытный бесплатный продукт - JumpServer. Сразу скажу на что он похож - Apache Guacamole, Trasa (проект умер) или Myrtille, но более функциональный и простой в настройке. Из минусов - есть баги и он китайский. Но в целом работает. У меня получилось очень быстро развернуть и настроить для простых подключений по SSH и RDP.

📌 JumpServer позволяет:

◽Вести локальную базу пользователей с различными методами аутентификации с логированием их действий.
◽Организовывать этим пользователям удалённый доступ к другим хостам по SSH, RDP или веб. То есть можно настроить в том числе доступ к веб интерфейсу различных устройств. Отдельно поддерживается доступ к различным СУБД.
◽Использовать в качестве клиента для подключения браузер или отдельный SSH и RDP клиент от самого JumpServer.
◽Настраивать разветвлённую структуру групп хостов и пользователей с различными правами доступа.

Установка и настройка выглядят следующим образом:

1️⃣ Разворачиваем систему с помощью скрипта. Всё запускается в Docker. Он должен быть самой свежей версии. На более старых возникает баг, не стартует один контейнер. Я с этим столкнулся на Debian 12. Пришлось подключать репу Docker и ставить самую свежую версию.

# curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

2️⃣ Заходим в веб интерфейс по IP адресу сервера. Учётка по умолчанию: admin / ChangeMe.

3️⃣ В разделе User ⇨ user создаём нового пользователя.

4️⃣ В разделе Assets ⇨ assets добавляем новый хост типа Linux или Windows. Указываете IP адрес хоста и учётную запись для аутентификации.

5️⃣ В разделе Policies ⇨ Authorization создаёте новую политику или изменяете существующую. В ней надо указать учётную запись, которую вы создали и хосты, которые вы добавили. У нас сейчас их по одному, можно соответственно, множественные пересечения делать.

На этом всё. Можно заходить созданным пользователем и пробовать подключаться. Либо тут же попробовать под админом, зайдя в отдельную вкладку Workbench. У меня сразу заработало, но с нюансами. Например, в веб консоли, если запустить mc или htop, то всё виснет. Не работает псевдографика. Я поигрался с настройками и темой, но быстро не смог разобраться, в чём проблема. Альтернатива - использовать отдельный SSH клиент, который интегрируется с JumpServer. Скачать его можно тут же в веб интерфейсе. Подключение по RDP нормально заработало.

В целом, система понравилась. В первую очередь за счёт простоты установки и настройки. Никаких заморочек, всё заработало сразу. Инструкция по быстрому запуску (quickstart) тут.

Что ещё умеет JumpServer:
- Объединять пользователей в группы
- Объединять хосты в группы и делить на зоны
- Каталогизировать хосты по типам платформ, например, Windows, Linux, macOS, BSD и т.д.
- Создавать шаблоны для настроек пользователей
- Автоматически создавать пользователей на управляемых хостах
- Создавать списки ACL с разрешениями или запретами на подключения
- Вести список всех запускаемых в консоли команд

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

#remote

Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

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

#sso #nginx

​​В репозиториях популярных дистрибутивов есть маленькая, но в некоторых случаях полезная программа progress. Из названия примерно понятно, что она делает - показывает шкалу в % выполнения различных дисковых операций. Она поддерживает так называемые coreutils - cp, mv, dd, tar, gzip/gunzip, cat и т.д.

Progress по смыслу немного похожа на pv, но принцип работы там совсем другой. Pv берёт информацию из пайпов, соответственно, надо заранее направить поток в неё, чтобы что-то увидеть. А progress сканирует каталог /proc, находит там поддерживаемые утилиты, далее идёт в fd и fdinfo, находит там открытые файлы и следит за их изменениями.

Для того, чтобы посмотреть прогресс той или иной команды, не обязательно запускать утилиту progress вместе с выполнением. Это можно сделать в любой момент времени. Например, запустили упаковку или распаковку большого архива gz и хотите посмотреть, как она выполняется. Достаточно открыть вторую консоль и там посмотреть. Мне это часто актуально, когда большие дампы sql распаковываю. Иногда это прям очень долго, особенно, когда однопоточный gzip используется.

Покажу сразу на примере. Создадим файл:

# dd if=/dev/urandom of=testfile bs=1M count=2048

За процессом, кстати, тоже можно следить с помощью progress, только не будет отображаться % выполнения, потому что утилита ничего не знает о конечном размере. Будет отображаться только скорость записи в режиме реального времени.

Жмём файл:

# gzip testfile

Открываем вторую консоль и там смотрим за процессом:

# watch -n 1 progress -q
[34209] gzip /tmp/testfile
    6.5% (132.2 MiB / 2 GiB)

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

То же самое будет и с распаковкой:

# gunzip testfile.gz

В соседней консоли смотрим:

# watch -n 1 progress -q
[35685] gzip /tmp/testfile.gz
    76.1% (1.5 GiB / 2.0 GiB)

Progress очень маленькая утилитка, написанная на чистом C (вспоминается песня "Папа может в C"). Размер - 31K. Из зависимостей только небольшая библиотека ncurses для вывода информации от сишных программ в терминал. Есть почти под все линуксы:

# apt install progress
# dnf install progress

⇨ Исходники

#terminal #linux

Пока я был в отпуске, пропустил важную для меня новость. Ну как важную. Была важной, а теперь уже не очень. В общем, компания Битрикс наконец-то выпустила обновление своего окружения VMBitrix 9.0.0. И как вы думаете, на базе какой операционной системы? .... Барабанная дробь .... CentOS Stream 9 😱.

Этим они меня удивили. Самый неудачный выбор, который только можно придумать. Напомню, что до этого окружение было на базе Centos 6 и 7. 7-я версия уже EOL, так что они переехали на Stream. Как я понял, просто поленились и пошли по самому простому пути. Я ни разу ни у кого не видел в проде Centos Stream. Соответственно, не понятно, для кого они это выпустили. Ожидал увидеть Debian или Ubuntu, на худой конец Rocky или Alma, но надеялся на Docker образы.

Поясню, что VMBitrix это готовое преднастроенное окружение для запуска сайтов на базе Bitrix, а так же CRM Bitrix24. Сам сайт, в принципе, всё равно на чём запускать. Он заработает практически на любом хостинге на базе Nginx + Apache + PHP. А вот с Bitrix24 посложнее, потому что там пуши. Настраивать самостоятельно хостинг под него утомительно. Не хочется тратить на это время. Готовое окружение эффективно решает эту задачу, плюс некоторые другие типа многосайтовости, получение сертификатов и т.д. В целом, пользоваться удобно, потому что, во-первых, экономит время, а во-вторых, у всех одинаковое окружение. Это упрощает разработку и перенос продукта.

Я для себя эту задачу уже решил и настроил всё в Debian 12 на базе Angie вместо Nginx. Настройки уже обкатаны, веб сервер работает пару месяцев. Планировал статью написать, но не знаю как по времени сложится. Особо некогда. Если вы работаете с Ubuntu, то рекомендую вот этот материал:

⇨ CRM Битрикс-24 на веб-окружении под Ubuntu 24.04, c поддержкой PUSH и многосайтовости

Это сайт хорошего специалиста. Я с ним пересекался на одном проекте. Если вам нужен проект на Битриксе, рекомендую. По стоимости будет недёшево, но и результат будет хороший в отличие от многих других вариантов. Мне есть с чем сравнивать, так как с Битриксами работаю последние лет 10. Сейчас уже сильно меньше, а лет 5 назад постоянно был вовлечён в разработку. Буквально на днях обращался человек, просил посоветовать кого-нибудь для разработки под Битрикс, потому что уже намучался и отчаялся найти хорошего исполнителя. Это типичная история для тех, кто ввязался в разработку на базе Bitrix. Абсолютно (без преувеличения) все, с кем я пересекался по этой теме, просили посоветовать хорошего разработчика.

Вот, кстати, сама новость про VMBitrix 9.0.0:
⇨ https://dev.1c-bitrix.ru/community/forums/forum32/topic159152/
Там есть все технические подробности.

Можно считать, что VMBitrix больше нет. Не знаю, кто будет себе разворачивать его в прод на базе Centos Stream. Для разработки программистам, наверное, сойдёт, но потом встанет вопрос с переносом в прод. Предвижу истории, когда разработчик будет говорить, что у него всё работает, а на проде будут ошибки. Я сам уже сталкивался с такими моментами, потому что много мелких нюансов по настройке веб сервера, прав доступа, хранения сессий, передачи заголовков, IP адресов и т. д. Если разработчики совсем не понимают в администрировании, то они нормально перенести не смогут.

#bitrix

Провёл почти всё лето с семьёй на даче у родителей. Тут у них старый видик есть с кассетами. Подключается к довольно современному телевизору, у которого присутствуют входы для "тюльпанов". Увидел эту картинку и как-то проникся. Тут наверное есть люди, которые никогда не видели эти провода. Я в начале 90-х познакомился с ними, когда купили видеомагнитофон Panasonic.

У меня ещё и внутренний ТВ тюнер на PCI разъёме есть для компа. Лет 7 назад я оцифровал семейные записи на кассетах. На удивление всё прошло гладко и получилось с первого раза. К сожалению, куда-то потерялась одна кассета. То ли оцифровать забыл, то ли удалил случайно. Предстоит повторить процедуру.

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

#разное