В конце прошлого года по каналам проскочило упоминание новой веб панели для бэкапов на базе 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

Недавно посмотрел видеообзор менеджера соединений Nexterm. Причём это не обычный менеджер, а веб сервис с разграничением прав доступа и некоторыми другими возможностями. Сразу скажу, что это прямой аналог Apache Guacamole, про который я много раз писал и которым я сам часто пользуюсь, но намного лучше. Никогда не любил настраивать Apache Guacamole. Он неудобен в настройке. Всегда ждал, когда же появится что-нибудь более современное и удобное. И вот наконец дождался.

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

Я Nexterm развернул, настроил, добавил несколько серверов, попользовался. Мне очень понравился и простотой настройки, и удобством пользования, и функциональностью. Отмечу основные возможности:

▪️Подключение к серверам по SSH, RDP, VNC или TELNET через браузер.
▪️Для соединений по SSH работает обзор файлов через SFTP.
▪️Для серверов с подключением по SSH можно включить простенький оперативный онлайн мониторинг с хранением метрик 24 часа.
▪️Поддерживается 2FA с помощью TOTP.
▪️Настроенные подключения можно раскладывать по организациям со своими настройками, учётными данными и пользователями, которым разрешён доступ.
▪️Все соединения логируются, есть возможность записывать сессии.
▪️Соединениям можно присваивать тэги для группировки.
▪️Можно подключить ИИ ассистента, который будет подсказывать команды в консоли. Поддерживается Ollama, ApenAI и совместимые с ним.
▪️Есть приложения для всех популярных систем, чтобы подключаться к серверу напрямую. Причём приложения легковесные. Под Windows всего 15 МБ весит, работает на базе WebView2.
▪️Проект полностью бесплатный, исходники открыты.

Запускается Nexterm в Docker, так что никаких проблем с установкой нет. Я подготовил вот такой compose.yml и запустил:

services:
  nexterm:
    image: germannewsmaker/nexterm:latest
    container_name: nexterm
    network_mode: host
    restart: always
    environment:
      - ENCRYPTION_KEY=02bdb65a028c37b2628c3727f3821530a629c40c25843b5268ceeb79a2c4033e
    volumes:
      - ./nexterm-data:/app/data

Дальше сходил по IP адресу сервера на порт 6989 и создал учётку администратора. В веб интерфейсе всё просто и понятно. Нетрудно пройтись по всем разделам, чтобы понять, что программа умеет и как настраивается.

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

Продукт оставил сугубо положительные впечатления. Всё понравилось. Получился Infrax на минималках. Всё, что касается удалённого доступа реализовано примерно так же, но в целом попроще. Никакой поддержки контейнеров и гипервизоров там нет. Только SSH, RDP и VNC.

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

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

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

#remote #менеджеры_подключений