Прорабатываю тему централизованного хранения логов в Loki. Потом для удобства объединю её в большую статью. Уже наметил план. Решил, чтобы вечно не откладывать, резать слона по частям, а не пытаться сразу всё сделать.

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

1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них

Сегодня разберу вопрос отправки журналов с логами Windows. Как бы не пытались аврально импортозаместиться, всё равно инфраструктура на Windows - значительная часть. А может и бóльшая, смотря как считать.

На удивление, настройка Alloy оказалась довольно замороченной, несмотря на то, что есть документация. ИИ по какой-то причине предлагает постоянно неработающие конфигурации. Я что с Linux, что с Windows в итоге разбирался сам.

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

Установка Alloy в Windows максимально простая - скачиваем установщик из репозитория и запускаем. Нужен будет файл alloy-installer-windows-amd64.exe.

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

Покажу пример с тремя стандартными журналами: System, Application и Security. Положил работающий и отлаженный файл конфигурации в репозиторий. На винде отлаживать неудобно, так как если в конфигурации была ошибка, служба тупо не запускалась с неинформативной ошибкой. Приходилось вручную всё проверять и пробовать разные варианты.

В итоге получил то, что хотел. Для логов назначил две метки:

◽️instance = "имя сервера", например WINSRV01.
◽️job = "имя сервера"-"имя журнала", то есть WINSRV01-application.

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

Редактируем конфигурацию, перезапускаем службу Alloy и идём в Grafana смотреть логи. Никаких дополнительных настроек делать не надо. Loki сам парсит виндовые логи и выделяет в них стандартные поля: event_id, channel, level, security_userId, timeCreated и т.д. По ним сразу можно делать выборку.

Несмотря на некоторые трудности и неудобства стека на базе Loki и Alloy, пользоваться им приятно в том плане, что базовые настройки относительно просты и функциональны. Можно особо не заморачиваясь просто отправлять логи в Loki и с ними тут будет удобно работать. Он сам распарсит стандартные типы, что позволит сразу выборки делать и рисовать дашборды. Когда изучал ELK с парсингом больше ковырялся. Тут он как-то проще работает.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#loki #logs #devops

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

Я в разное время использовал следующих представителей этих программ:

◽️ GoodSync - очень крутая и функциональная программа, но платная. Она старая, с большой историей, в том числе лекарств. Если надо, без проблем всё находится. У меня до сих пор хранится и работает какая-то древняя версия 15-ти летней давности.

◽️ FreeFileSync - это более простой аналог GoodSync, но зато полностью бесплатный. При этом кроссплатформенный. Много всего умеет, в том числе подключатся к некоторым облачным дискам, или к тем же линуксам по sftp.

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

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

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

К чему я это всё. Как уже не первый раз бывало, я недавно увидел упоминание бесплатной программы под Windows - SyncToy. Ей сто лет в обед, входила в состав PowerToys и полностью бесплатна. Решает ровно одну задачу - синхронизация двух каталогов. Поддерживает 3 режима синхронизации:

- полная двусторонняя синхронизация каталогов;
- односторонняя синхронизация изменений в одном каталоге;
- односторонняя синхронизация изменений с сохранением удалённых файлов, изменения перезаписываются.

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

Мне стало любопытно проверить самую старую версию последнего релиза от 2009 года. Скачал, проверил подпись, проверил на вирусы, всё чисто (загрузил к себе). Установил на свежую Win11, и всё заработало. Предварительно нужно через Панель управления в компонентах системы установить .NET Framework 3.5. У меня он уже стоял, так что программа сразу заработала без каких-либо проблем и ошибок.

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

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

# robocopy "D:\Source" "E:\Backup" /MIR

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

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

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#windows #backup

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

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

📌 Особенности Zerobyte:

▪️Приятный и логичный веб интерфейс.
▪️В качестве бэкенда для бэкапов использует Restic. У меня было много заметок про него с примерами, можно по тэгу посмотреть, так что не буду повторяться и рассказывать, что это такое.
▪️В качестве бэкенда для хранения может использовать локальную директорию, S3, Rest Server, SFTP, Rclone и некоторые другие облачные хранилища.
▪️Может бэкапить локальные директории, SMB и NFS шары, ресурсы, доступные по WebDAV и SFTP.

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

Я для примера подключил к Zerobyte шару по SMB и забэкапил её в S3 бакет Селектела. Доступ в S3 настроен через Rclone, так что начнём настройку с него. Ставим на сервер, где будет работать Zerobyte:

# apt install rclone

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

# rclone ls selectel_s3:zerobyte

Теперь рисуем конфигурацию compose.yml для запуска панели. Я обнаружил в ней один баг, из-за которого не получалось в качестве источника для бэкапов смонтировать внутрь контейнера SMB или NFS ресурс. Контейнеру не хватает каких-то прав. Решается добавлением этих прав или запуска контейнера в привилегированном режиме. Если это недопустимо, то можно монтировать ресурсы к хосту и прокидывать в контейнер.

Вот мой итоговый compose.yml:

services:
  zerobyte:
    image: ghcr.io/nicotsx/zerobyte:v0.25
    container_name: zerobyte
    restart: unless-stopped
    cap_add:
      - SYS_ADMIN
      - SYS_PTRACE
    security_opt:
      - seccomp:unconfined
      - apparmor:unconfined
    ports:
      - "4096:4096"
    devices:
      - /dev/fuse:/dev/fuse
    environment:
      - TZ=Europe/Moscow
      - BASE_URL=http://192.168.137.29:4096
      - APP_SECRET=f47c06b21f12a2261f9dd
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /var/lib/zerobyte:/var/lib/zerobyte
      - /mnt/backup:/backup
      - ~/.config/rclone:/root/.config/rclone:ro

Запускаем:

# docker compose up -d

Идём в веб интерфейс по IP адресу сервера на порт 4096, создаём нового пользователя.

Теперь вам нужно создать Volume - это источник бэкапов. Потом создаём репозиторий - место, где будут храниться бэкапы. В качестве бэкенда указываем Rclone и настроенный ранее Remote в Селектеле.

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

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

В целом продукт интересный, мне понравился. Если продолжит развитие, то завоюет популярность.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#restic #backup

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

Основной у меня Яндекс.Браузер. Не скажу, что он мне прям сильно нравится. Постоянно им стал пользоваться, когда у него синхронный перевод видео появился. С тех пор привык к нему и пользуюсь по сей день. Качество перевода лучше, чем то, что сейчас Youtube выкатил. Да и выбирать особо нечего из отечественного, чтобы и на компе, и на смартфоне работал с синхронизацией данных между устройствами. Мне нравится фишка, когда вкладку из смартфона можно на комп перекинуть или в обратную сторону. Не знаю, есть ли это у других, но тут постоянно пользуюсь.

Также постоянно использую встроенный в винду Edge. Там нет ни закладок, ни паролей, ни расширений. В нём сразу открываются все редакторы, где я готовлю публикации в каналы и на сайт. Мне удобно, когда всё это отдельно открывается.

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

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

Вообще, я несколько раз пытался начать пользоваться на постоянку Firefox и всё время что-то было не так. Складывается ощущение, что кроме движка Chrome для браузеров ничего не осталось. И нет смысла пробовать что-то другое и тратить своё время.

Некоторое время назад открыл для себя проект ungoogled-chromium. Я слышал про него давно, но всё руки не доходили попробовать. Это голый chromium без каких-либо доработок и улучшений, где просто вырезали всё, что связано с Google. Он получился простой, быстрый и лаконичный. Есть портабельная версия. Я её и использую.

Для того, чтобы спокойно ставить в chromium расширения из магазина chrome, в него надо установить расширение chromium-web-store. Для этого надо скачать из раздела releases свежую версию Chromium.Web.Store.crx. Зайти в chromium, открыть в адресной строке chrome://flags/#extension-mime-request-handling и выставить там параметр Always prompt for install. После этого файл Chromium.Web.Store.crx можно просто перетащить в окно браузера и установить.

После установки этого расширения можно заходить в магазин chrome и устанавливать любые хромовские расширения. Я лично поставил uBlock Origin Lite с максимально жёсткими списками, чтобы даже в погоде Яндекса всю рекламу вырезал, и ZeroOmega для управления проксями. Только вчера узнал, что это форк другого расширения, которое я активно использую - SwitchyOmega. Его к сожалению забросили и больше не развивают. Надо переходить на актуальный форк.

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#полезное #разное

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

Есть одиночный выделенный сервер с одним внешним IP под PVE. Он будет работать в связке с другими, но связь только через интернет по VPN. Тут есть 2 варианта организации сети:

1️⃣ Настраиваем на гипервизоре файрвол, NAT, возможно SDN с DHCP, пробрасываем порты в виртуальные машины и там настраиваем всё, что нужно. Например, VPN сервер.
➕ Простота и скорость настроек.
➖ Настраивать нужно сам гипервизор и потом бэкапить его настройки. Это осложняет перенос, если нужно переехать. Да и в целом концепция с настройками чего-то на самом гипервизоре не очень удобна. От уровня железа лучше абстрагироваться, перенося всё в виртуальные машины. Сам гипервизор становится точкой входа в инфраструктуру, что тоже не очень удобно и безопасно.

2️⃣ На гипервизоре настраивается виртуальная машина в роли шлюза. В неё прокидывается внешний IP адрес. Она становится шлюзом по умолчанию для всех виртуалок и самого гипервизора.
➕ Все настройки внутри VM, которую можно забэкапить и перенести. На гипервизоре настраивается только сеть и больше ничего. Внутри виртуальной машины можно настроить всё, что угодно, ни в чём себя не ограничивая. Это может быть CHR с RouterOS или OPNSense.
➖ Более сложные сетевые настройки и очень желательно постоянный доступ по IP-KVM. У некоторых провайдеров бывают проблемы с такой схемой из-за их особенностей сети. Если VM со шлюзом не поднимется по какой-то причине, доступа к гипервизору не будет.

Есть третий вариант - купить несколько IP адресов на один сервер. Если сервера дорогие, то экономить на IP смысла нет, лучше заказать. Это и проще, и функциональнее. Я так часто делал. Но если сервак бюджетный, то переплачивать за /29 или /28 подсеть, а с дедиками обычно сразу подсеть продают, не хочется. Там цена адресов может быть сопоставима с самим сервером.

Я настраивал сеть по второму примеру. Нарисовал схему, как это выглядит на практике, и прикрепил внизу. Пример взял с реально настроенного сервера. Пишу по шагам, как настраивал.

1️⃣ На железном сервере 1 сетевой интерфейс eth0 с IP адресом 45.95.177.210. Ставлю на этот сервер PVE. Доступ к веб интерфейсу, соответственно, по этому IP адресу.

2️⃣ Создаю на этом сервере бридж vmbr0 и добавляю в него интерфейс eth0. Сетевые настройки IP адреса из eth0 переношу в vmbr0. Делаю это напрямую в файле /etc/network/interfaces, так как через веб интерфейс PVE не получится.

3️⃣ Добавляю ещё один бридж vmbr1 без привязки к физическому интерфейсу. Этот бридж будет использоваться для связи виртуальных машин и гипервизора между собой.

4️⃣ Проверяю внимательно настройки и перезагружаю сервер. После перезагрузки он поднимется с двумя настроенными интерфейсами:
◽️vmbr0 - внешний IP адрес
◽️vmbr1 - локальный IP адрес

5️⃣ Создаю виртуальную машину под шлюз, подключаю к ней vmbr0 и vmbr1. Ставлю эту VM в автозагрузку, чтобы поднималась вместе с гипервизором.

6️⃣ Переношу настройки внешнего IP адреса с vmbr0 гипервизора на сетевой интерфейс VM, где подключен vmbr0. На vmbr1 настраиваю локальный IP адрес и убеждаюсь, что гипервизор и виртуалка видят друг друга.

7️⃣ Комментирую настройки внешнего IP адреса на гипервизоре, чтобы они остались только внутри VM.

8️⃣ Перезагружаю гипервизор и подключаюсь по внешнему IP к VM со шлюзом.

9️⃣ Настраиваю проброс портов со шлюза на гипервизор, чтобы к нему был доступ.

Схема полностью рабочая. Описывал её в своей старой статье по организации сети в PVE. В Selectel она нормально работает. Я ошибся с тем, что временно на VM во время настройки сделал выход в интернет через гипервизор, а потом забыл поменять шлюз по умолчанию. После перезагрузки терял доступ к гипервизору.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#proxmox #network

Недавно в обсуждениях всплыл вопрос использования Rclone c Яндекс.Диском. У последнего заявлена поддержка этого облака. Я много работал с Яндекс.Диском в разное время. У него очень низкая стоимость хранения. Туда можно очень дёшево положить одну из копий бэкапов, чем я и занимался.

Для работы с облачным диском в Linux в разное время я использовал разные инструменты, так как Яндекс периодически менял условия доступа и ставил палки в колёса для нежелательных методов.

1️⃣ Доступ по протоколу webdav. Он и сейчас заявлен, как доступный протокол, но работать по нему фактически невозможно. Скорость никакая, постоянные разрывы связи.

2️⃣ Консольный клиент для Linux. Большие объёмы данных через него удобно загружать, но есть один нюанс. Через консольный клиент нельзя просто загрузить файлы в облако, без синхронизации локального и удалённого каталога. То есть у вас локально должно быть достаточно свободного места для копии облачных файлов. Для небольших виртуалок, с которых надо просто забрать файл, это не подходит.

3️⃣ Использование API. Рабочий вариант для каких-то ситуаций, но надо заморочиться с настройкой доступа и выпуском токенов. Сейчас может упростили процедуру, но когда я занимался, немного утомился от этой кухни.

4️⃣ Использование Rclone. По ссылке пример использования в Windows 3 года назад. Тогда работало нормально. Можно было даже примонтировать облачный диск к системе с помощью Rclone.

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

Показываю, как с ним работать. Устанавливаем rclone:

# apt install rclone

Настраиваем конфигурацию для Яндекс.Диска:

# rclone config

Дальше будут нюансы. Я действовал по инструкции на сайте rclone. Для аутентификации в сервисе через OAuth понадобится браузер. В результате будет получен токен, который можно использовать где угодно. То есть машина с браузером понадобится один раз для получения токена.

Я использовал свой ноутбук с Windows, а Rclone для получения токена запустил в WSL. Для этого воспользовался приведённой выше инструкцией, а когда в консоли увидел ссылку вида http://127.0.0.1:53682/auth?state=rOjTxRP71Dexbyal-faud, просто скопировал её в браузере и там же залогинился в сервис. Если у вас нет возможности запустить браузер локально вместе с запуском Rclone, а на удалённой машине нет GUI, то можно сделать проброс порта с удалённой машины на локальную через SSH:

# ssh -L localhost:53682:localhost:53682 username@remote_server

Почитать, как это работает, можно в заметке.

На выходе получил конфигурацию в файле ~/.config/rclone/rclone.conf вида:

[yandex]
type = yandex
token = {"access_token":"y0_g8MWLxkkwkw_Cn9EpiGIH_A","token_type":"OAuth","refresh_token":"2:AAAbtrsyM:23rBwLS_kWbXMr6V1Mr7xA","expiry":"2027-02-24T18:49:25.82348698+03:00"}

Эту конфигурацию можно перенести на целевой сервер и там работать с Яндекс.Диском. Сама работа выглядит примерно так.

Создаём директорию backup:

# rclone mkdir yandex:backup

Копируем туда файл:

# rclone copy ics-13.0.0-2025.12.08-14.40.iso yandex:backup

Смотрим содержимое директории:

# rclone ls yandex:backup

Удаляем файл:

# rclone delete yandex:backup/ics-13.0.0-2025.12.08-14.40.iso

Очищаем корзину:

# rclone cleanup yandex:

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

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#rclone #backup