​​До появления Proxmox Backup Server я часто отдавал предпочтение при выборе гипервизора Hyper-V из-за того, что для Proxmox VE не было функционального инструмента для бэкапов VM, кроме его встроенного средства, которое делало только полные бэкапы.

С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.

Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.

Сразу перечислю основные ограничения этого клиента:

▪ бэкап только на уровне файлов или образов дисков, не системы целиком;
▪ официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
▪ нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.

Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.

Ставим Proxmox Backup Client на Debian:

# wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
# mcedit /etc/apt/sources.list.d/pbs-client.list
Вставляем туда для Debian 12
deb http://download.proxmox.com/debian/pbs-client bookworm main
Для Debian 11:
deb http://download.proxmox.com/debian/pbs-client bullseye main
Для Debian 10:
deb http://download.proxmox.com/debian/pbs-client buster main
Ставим клиента:
# apt update && apt install proxmox-backup-client

Теперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:

# proxmox-backup-client backup root.pxar:/ --repository 10.20.1.47:main

Здесь мы указали:
◽root.pxar - имя архива в формате pbs
◽/ - бэкапим корень системы
◽10.20.1.47 - адрес pbs сервера
◽main - имя datastore

По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория: user01@pbs@10.20.1.47. То есть мы указали созданного вручную пользователя user01@pbs.

Для того, чтобы не вводить пароль пользователя вручную, можно задать его через переменную окружения PBS_PASSWORD.

Смотреть содержимое бэкапов можно как через веб интерфейс, так и тут локально. Причём бэкап можно примонтировать через fuse. Сморим снэпшоты и выбираем любой для монтирования:

# proxmox-backup-client snapshot list --repository 10.20.1.47:main
# proxmox-backup-client mount host/debian12-vm/2024-02-06T19:19:12Z root.pxar --repository 10.20.1.47:main /mnt/backup

Очень быстро и удобно. При желании бэкапы можно шифровать.

#proxmox #backup

Посмотрел вчера видео на тему проброса видеокарты в Proxmox:

▶️ Проброс видео карты в Proxmox

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

1️⃣ Отредактировать параметры ядра хоста, отключить некоторые стандартные драйвера видеокарты.
2️⃣ Пересобрать initramfs хоста, перегрузить его.
3️⃣ Выбрать особые настройки VM, отключить у неё экран.
4️⃣ После этого добавить в неё видеокарту.

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

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

p.s. Рекомендую канал и сайт автора. Там есть интересные и полезные материалы.

#proxmox

​​У браузера Firefox и всех остальных, что созданы на его основе, есть отличительная особенность, которая кому-то нравится, кому-то нет. Всё зависит от ситуации. У этого браузера своё собственное хранилище сертификатов, куда можно добавлять доверенные центры сертификации, минуя системное хранилище ОС. Для централизованного управления это скорее минус, а для индивидуального использования больше плюс.

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

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

Всё это можно сделать. Но, к примеру, у меня наберётся с десяток одиночных гипервизоров, где я не буду всего этого делать, потому что нет смысла. Доступ из интернета к ним открывать не буду. Я работаю с ними один, к ним нет доступа из интернета. Они принадлежат разным проектам и не объединены между собой. Мне проще забрать с этих гипервизоров pve-root-ca.pem, добавить в браузер, чтобы не засорять систему и сохранить учётки для быстрого входа. Доступ к ним всё равно закрыт списками IP адресов на файрволе.

Для того, чтобы настроить доверие для самоподписанного сертификата Proxmox, который создаётся во время установки гипервизора, надо зайти в веб интерфейсе в раздел System ⇨ Certificates. Выбрать сертификат pve-root-ca.pem, открыть его исходный текст. Скопировать и сохранить его в любой текстовый файл, указав ему расширение .crt.

Далее идём в браузер на основе Firefox. Я использую портированный LibreWolf. Переходим в Settings ⇨ Privacy & Security ⇨ Certificates ⇨ View Certificates. Там делаем Import сохранённого сертификата. Теперь из этого браузера при входе на веб интерфейс Proxmox не будет предупреждения. У вас появится возможность сохранить данные аутентификации.

#proxmox

​​На днях вышло обновление Proxmox 8.2, в котором появилось несколько интересных нововведений. Самое полезное на мой взгляд - импорт виртуальных машин из VMware ESXi. Я не сразу понял, как это реализовано. Обновил тестовый гипервизор, всё там пересмотрел и не нашёл импорт. Полез в документацию.

1️⃣ Работает он следующим образом. В списке Storage, доступных для добавления, появился новый тип - ESXi. Для добавления нужно указать его адрес и рутовую учётку. После этого в списке этого хранилища будут отображаться виртуальные машины хоста ESXi, откуда можно быстро выполнить импорт. Сделано удобно с минимум необходимых телодвижений. Жду, когда то же самое появится для Hyper-V. Лично для меня это более актуально.

2️⃣ Второе значительное изменение - появилась возможность в качестве встроенного файрвола использовать nftables, а не iptables. Пока это надо явно включить. Переход на nftables только прорабатывают, собирают обратную связь. В будущих релизах он заменит iptables окончательно. Так что можно потихоньку переползать. Кто не знаком с nftables, у меня есть небольшая статья по базовым правилам.

3️⃣ Третье важное дополнение. В настройках встроенных бэкапов появилась новая вкладка Advanced с дополнительными настройками процесса снятия бэкапов. Туда переехали настройки по ограничению ширины канала при бэкапе. А также добавилась новая настройка Backup fleecing, которая включает режим буферизации на локальный диск. Перед передачей на внешнее хранилище, бэкап работающей машины может кэшироваться на отдельном локальном storage, который можно выбрать из подключенных. Это снизит нагрузку на работающую VM во время снятия бэкапа и в целом ускорит процесс, так как кэшировать можно на наиболее ненагруженное хранилище. Возможно будет иметь смысл выделить отдельное хранилище под это дело.

Остальные изменения не такие существенные, поэтому перечислю их кратко:
◽появилась утилита proxmox-auto-install-assistant для подготовки установочного образа с готовыми настройками для установки без участия человека;
◽в веб интерфейс добавлена возможность настройки проброса устройств в lxc контейнеры;
◽в настройках ACME можно добавить любой другой удостоверяющий центр, отличный от Let's Encrypt;
◽изменились некоторые настройки веб интерфейса: не активируется режим редактирования полей при попытке скопировать данные оттуда, актуально, к примеру, для поля Notes с описанием VM, также изменилось положение кнопки с отменой введённых настроек.

Посмотреть, как все изменения выглядят в веб интерфейсе, можно вот в этом видео:

▶️ https://www.proxmox.com/en/services/videos/proxmox-virtual-environment/whats-new-in-proxmox-ve-8-2

Нравится, как команда Proxmox оформляет все свои обновления. Максимально подробно и текстом, и в виде роликов. Другим компаниям бы брать пример.

#proxmox

​​Пока прошлые статьи писал про сертификаты и Proxmox, возник вопрос. А как добавить в доверенные сертификат от Proxmox Backup Server, чтобы браузер не ругался? У него почему-то нет CA сертификата в веб интерфейсе, как в VE, который можно добавить в доверенные.

Немного поискал информацию и нашёл в официальной wiki на эту тему отдельную статью. Меня в ней привлекло вот что. В самом конце рассматривается случай, когда PBS и VE стоят на одной машине (Using Certificates from Proxmox VE). Авторы предлагают для PBS использовать тот же сертификат, что и для VE.

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

Пошёл смотреть документацию по установке PBS. Там есть отдельный раздел Install Proxmox Backup Server on Proxmox VE. Так что технически никаких проблем нет. Можно ставить PBS на хост виртуализации. Есть единственное предупреждение:

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

Предупреждение очевидное. Надо это понимать. Лично мне локальные копии нужны, чтобы в случае чего оперативно восстановить виртуальную машину из локального бэкапа. Само собой, он не единственный.

В целом, я бы всё же не рекомендовал ставить на один хост и PBS, и VE. Мне кажется, лучше в виртуалке (или в lxc) поднимать. Я не сторонник что-то настраивать на самих гипервизорах. Тогда они становятся невзаимозаменяемыми. Если есть возможность, лучше всё переносить в виртуальные машины. Если умрёт сервер, то простое восстановление виртуальных машин из бэкапа вернёт всю функциональность. А если что-то на гипервизоре настроено, то надо восстанавливать, и предварительно бэкапить, его настройки. Где-то это может быть оправдано, где-то нет.

Я если что-то и делаю на гипервизоре, так это только iptables настраиваю с nat. Все настройки - это единственный конфиг для iptables. Нетрудно сохранить.

#proxmox

​​Если вдруг вам хочется чего-нибудь странного, то могу вам кое-что предложить. Например, запустить контейнеры Docker в LXC контейнере Proxmox. Я изначально думал, что это так просто не сработает. Всегда запускаю контейнеры в виртуалках. Тут решил попробовать в LXC, сразу заработало.

Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:

# apt install curl
# curl https://get.docker.com | bash -
# docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.

#proxmox #docker

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

С помощью Cloud-Init в Proxmox можно автоматически добавить в виртуальную машину:

- пользователей, пароли, ключи для SSH
- настройки DNS
- сетевые настройки
- выполнить принудительное обновление пакетов

Технически это выглядит следующим образом.

1️⃣ Вы настраиваете виртуальную машину так, как вам нужно. Ставите нужные пакеты, настраиваете ПО, если надо. Отдельно устанавливаете пакет с cloud-init:
# apt install cloud-init
Можно использовать готовые образы уже с cloud-init внутри:
https://cloud.debian.org/images/cloud/
https://cloud-images.ubuntu.com/
https://dl.astralinux.ru/ui/native/mg-generic/alse/cloud/
Proxmox поддерживает готовые образы, сформированные для OpenStack.

2️⃣ Из этой виртуальной машины делаете эталонный шаблон средствами Proxmox (пункт меню convert to template).

3️⃣ Создаёте из этого шаблона виртуальную машину. Добавляете к ней отдельное устройство Cloudinit Drive.

4️⃣ В настройках виртуальной машины есть отдельный раздел Cloud-init, где можно индивидуально для конкретной машины задать перечисленные выше настройки.

Без Cloud-Init пришлось бы руками лезть в новую виртуалку и менять эти параметры. А так они аккуратно задаются через интерфейс управления и потом применяются. Работает просто и удобно. Настраивается тоже без проблем.

Описанная выше инструкция с техническими подробностями есть в Wiki Proxmox. Там же FAQ по этой теме:

- Cloud-Init Support
- Cloud-Init FAQ

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

#proxmox

​​Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.

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

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

То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:

# journalctl --vacuum-size=256M

Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.

Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.

Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.

#proxmox #backup

▶️ Всем хороших тёплых летних выходных. Желательно уже в отпуске в каком-то приятном месте, где можно отдохнуть и позалипать в ютуб. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными.

⇨ Установка Opnsense в Proxmox
Обзор популярного программного шлюза OPNsense, аналога pfSense. Практики в видео почти нет, в основном разговоры о самой системе и о софтовых шлюзах. Автор просто выполнил установку и самую начальную настройку.

⇨ Best operating system for Servers in 2024
Небольшой обзор современных гипервизоров и систем для решения различных задач. Интересно для расширения кругозора, если с чем-то не знакомы. Автор кратко рассказывает о VMware ESXi, Nutanix AHV, Proxmox VE, XCP-ng, Talos Linux, Flatcar Container Linux, Fedora CoreOS, Windows Server, TrueNAS Scale, Ubuntu, Debian, Qubes OS, Tails OS, Kali Linux.

⇨ Установка Kubernetes
Название ролика не соответствует содержанию. Самой установки там нет, но есть содержательная беседа трёх специалистов на тему Кубернетиса. Можно просто послушать, не смотреть, где-то в машине или метро.

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

⇨ The terminal WARS begins! // Warp vs Wave
Какие-то супер навороченные терминалы. Не слышал ни про первый, ни про второй. Да и пользоваться ими не буду. Навскидку, чтобы ими начать пользоваться, надо изучать, как Vim. Они его, кстати, заменяют. Не вижу большого смысла во всём этом для администрирования серверов. Но посмотреть было интересно. Там и шаринг кода, и AI помощник, и общие хранилища, и много всяких других фишек, помимо базовых. Позже выяснил, что их под винду и нет. Сборки только для Linux и MacOS.

⇨ Zabbix workshops: Zabbix proxy high-availability and load balancing
⇨ Zabbix workshops: New web monitoring features in Zabbix 7.0
Два больших ролика (~по часу) на заданные темы. Показаны практические примеры по настройке. То есть специалист сидит, настраивает на реальном мониторинге и нам рассказывает. Люблю такой формат, потому что тут конкретика. Смотреть просто так смысла нет, но если будете настраивать эти вещи, то видео очень пригодятся.

⇨ Meet ChangeDetection - A Self-Hosted Website Change Detector!
Подробный обзор очень интересной бесплатной системы мониторинга за сайтами, их состоянием и контентом. Заинтересовался этой штукой. Запланировал попробовать и написать заметку. Это не просто мониторинг, но и отслеживание изменений контента для различных задач. Например, можно следить за ценами, погодой, курсами и т.д.

#видео

​​Существует известный проект Turnkey Linux, который предлагает готовые преднастроенные образы Linux для решения конкретных задач - файловый сервер, веб сервер, впн сервер и т.д.. Я уже ранее писал про него. Там нет чего-то особенного, что с одной стороны хорошо, а с другой вроде и не надо особо. В основном там используется стандартное open source ПО с веб управлением через webmin. Всё это можно и самому настроить при желании, но тут это уже сделали за вас.

Особо нигде не афишируется, что Turnkey Linux интегрируется с Proxmox. Можно использовать готовые шаблоны LXC контейнеров Turnkey Linux в Proxmox. Для того, чтобы они появились в веб интерфейсе гипервизора, в разделе CT Templates, необходимо в консоли гипервизора выполнить команду:

# pveam update
update successful

После этого заходите в локальное хранилище с Container template и смотрите список доступных шаблонов. Увидите 110 шаблонов turnkeylinux.

Для каких-то тестовых задач или временных виртуалок неплохое решение, так как контейнеры разворачиваются очень быстро и не требуют начальных настроек. В несколько кликов можно запустить контейнер с DokuWiki, Nextcloud, OpenLDAP, Snipe-IT, ownCloud и т.д. И посмотреть на них.

#proxmox

Если вы используете динамический размер дисков под виртуальные машины, то рано или поздно возникнет ситуация, когда реально внутри VM данных будет условно 50 ГБ, а динамический диск размером в 100 ГБ будет занимать эти же 100 ГБ на гипервизоре.

Я раньше решал эту задачу для HyperV и виртуалок с Linux. Сейчас уже не помню точную реализацию, но смысл был в том, что незанятое пространство внутри VM надо было принудительно заполнить нулями и выполнить что-то со стороны гипервизора. Помню виртуалку в 500 ГБ, где реально использовалось 40 ГБ. Она была очень критичная, там был самописный call центр на базе Elastix. Интересно, кто-нибудь помнит его? Хороший был продукт для VOIP. Так вот, эта виртуалка занимала на диске гипервизора реальные 500 ГБ и не получалось её перенести в доступное для этого окно. Call центр почти круглые сутки работал. Ужать по размеру диска её не получилось, но когда она стала занимать реальные 40 ГБ, переносить её стало значительно проще и быстрее.

С Proxmox сейчас стало всё намного проще. Никаких ручных действий. Если у вас в виртуалках динамические диски, а это иногда оправданно для экономии места, когда есть возможность расселять виртуалки, когда на гипервизоре заканчивается место (так делают почти все хостеры VPS), то достаточно выполнить пару простых действий, чтобы виртуалки занимали тот объём, сколько реальных данных там есть.

Для этого можно воспользоваться официальным руководством:

⇨ Shrink Qcow2 Disk Files

Достаточно указать тип дискового контроллера Virtio-SCSI, а для самого диска установить параметр Discard. После этого внутри VM с Linux выполнить команду:

# fstrim -av

Все современные дистрибутивы Linux имеют systemd службу с fstrim и таймер для запуска. Диск на самом гипервизоре ужмётся до реального размера данных внутри VM. Проверить это можно так:

# qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 1.32 GiB
cluster_size: 65536

Если внутри витуалки добавить занимаемый объём, то это сразу же будет видно на гипервизоре:

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

Смотрим ещё раз на файл диска:

# qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 3.32 GiB
cluster_size: 65536

Удаляем в виртуалке файл:

# rm testfile

Смотрим на размер диска:

# qemu-img info vm-100-disk-0.qcow2
image: vm-100-disk-0.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 3.32 GiB
cluster_size: 65536

Ничего не поменялось. А если сделаем fstrim внутри VM, реальный размер диска уменьшится.

То же самое можно сделать и с уровня гипервизора, но для этого нужно будет выключить виртуальную машину, что неудобно, но иногда тоже может пригодиться. Это можно сделать с помощью утилиты virt-sparsify из комплекта libguests-tools:

# virt-sparsify --in-place vm-100-disk-0.qcow2

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

#proxmox #виртуализация

​​Я не так давно делал заметку про исчерпание свободного места на PBS (Proxmox Backup Server). Напомню, что если у вас закончилось свободное место, то нет штатной возможности освободить его здесь и сейчас, кроме как удалить весь Datastore полностью. Если вы просто удалите ненужные бэкапы, то придётся ждать сутки, когда они реально освободят занимаемое место.

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

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

1️⃣ Удалите лишние бэкапы в разделе Datastore ⇨ Content
2️⃣ Перейдите в консоль PBS и выполните там команду:

find /path2pbs-datastore/.chunks -type f -print0 | xargs -0 touch -d "-2 days"

3️⃣ Идём опять в веб интерфейс, выбираем наш Datastore и запускаем Garbage Collect.

Все удалённые бэкапы удалятся окончательно, освободив свободное место.

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

# touch testfile
# stat testfile
# touch -d "-2 days" testfile
# stat testfile

После работы touch с ключом -d метка Modify уехала на 2 дня назад.

Если я всё правильно понимаю, то штатный процесс Garbage Collect удаляет все помеченные на удаление блоки со временем последнего изменения больше суток назад. Соответственно, меняя дату блоков на 2 суток назад, мы гарантированно провоцируем их удаление. Не совсем понимаю, почему нельзя было сделать отдельным пунктом GC удаление помеченных на удаление блоков здесь и сейчас, но как есть, так есть.

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

#proxmox

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

1️⃣ Самый простой способ - настроить ограничение по IP с помощью настроек pveproxy. Я об этом подробно рассказывал в отдельной заметке. Достаточно создать файл /etc/default/pveproxy примерно такого содержимого:

ALLOW_FROM="192.168.13.0/24,1.1.1.1"
DENY_FROM="all"
POLICY="allow"

И после этого перезапустить службу:

# systemctl restart pveproxy.service

2️⃣ С помощью iptables. Если заранее не настроили iptables, то на работающем сервере лучше не пробовать настраивать, если у вас нет прямого доступа к консоли. Если файрвол вообще не настраивали, то в общем случае понадобятся два правила:

/usr/sbin/iptables -A INPUT -i enp5s0 -s 192.168.13.0/24,1.1.1.1 -p tcp --dport 8006 -j ACCEPT
/usr/sbin/iptables -A INPUT -i enp5s0 -p tcp --dport 8006 -j DROP

Первое разрешает подключения из подсети 192.168.13.0/24 и ip адреса 1.1.1.1. Второе правило запрещает все остальные подключения к веб интерфейсу. Правила эти можно сохранить в файл и подгружать во время загрузки сервера или явно прописать в /etc/network/interfaces примерно так:

auto enp5s0
iface enp5s0 inet static
address 5.6.7.8/24
dns-nameservers 188.93.17.19 188.93.16.19
gateway 5.6.7.1
post-up /usr/sbin/iptables -A INPUT -i enp5s0 -s 192.168.13.0/24,1.1.1.1 -p tcp --dport 8006 -j ACCEPT
post-up /usr/sbin/iptables -A INPUT -i enp5s0 -p tcp --dport 8006 -j DROP

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

Я сам всегда использую iptables. Настраиваю его по умолчанию на всех гипервизорах. Примерный набор правил показывал в заметке.

3️⃣ Вы можете установить Nginx прямо на хост с Proxmox, так как по своей сути это почти обычный Debian. У Nginx есть свои способы ограничения доступа по ip через allow/deny в конфигурации, либо по пользователю/паролю через basic auth. Бонусом сюда же идёт настройка TLS сертификатов от Let's Encrypt и доступ по 443 порту, а не стандартному 8006.

Ставим Nginx:

# apt install nginx

Настраиваем базовый конфиг /etc/nginx/sites-available/default:

server {
listen 80 default_server;
server_name _;
allow 192.168.13.0/24;
allow 1.1.1.1/32;
deny all;
return 301 https://5.6.7.8;
}
server {
listen 443 ssl;
server_name _;
ssl_certificate /etc/pve/local/pve-ssl.pem;
ssl_certificate_key /etc/pve/local/pve-ssl.key;
proxy_redirect off;
allow 192.168.13.0/24;
allow 1.1.1.1/32;
deny all;
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass https://localhost:8006;
proxy_buffering off;
client_max_body_size 0;
}
}

Разрешили подключаться только с указанных адресов. Это пример с использованием стандартных сертификатов. Для Let's Encrypt нужна отдельная настройка, которая выходит за рамки этой заметки. Для того, чтобы закрыть доступ паролем, а не списком IP адресов, необходимо настроить auth_basic. Настройка легко гуглится по ключевым словам nginx auth_basic, не буду об этом рассказывать, так как не умещается в заметку. Там всё просто.

Этот же Nginx сервер можно использовать для проксирования запросов внутрь виртуалок. Удобный и универсальный способ, если вы не используете отдельную виртуалку для управления доступом к внутренним ресурсам.

После настройки Nginx, доступ к веб интерфейсу по порту 8006 можно закрыть либо через pveproxy, либо через iptables.

#proxmox

В продуктах 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 user01@yandex.ru:userpass123

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

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

root@pve user01@yandex.ru

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

Формируем на основе текстовых файлов локальные базы данных, с которыми будет работать 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=<user01@yandex.ru>
pve postfix/cleanup[941760]: 4C81718E07A1: message-id=<20240820202545.4C81718E07A1@pve>
pve postfix/qmgr[941604]: 4C81718E07A1: from=<user01@yandex.ru>, size=894, nrcpt=1 (queue active)
pve postfix/smtp[941762]: 4C81718E07A1: to=<superadmin@yandex.ru>, 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 и отправил с его помощью письмо superadmin@yandex.ru, получив status=sent. Письмо ушло адресату, отправляющий сервер принял его в обработку.

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

#proxmox

Я ранее делал пару заметок на тему бесплатных инструментов для организации 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