Restic — хорошо известная программа для резервного копирования. Она достаточно проста, чтобы переноситься на любую ОС, и, вероятно, поэтому с ней не прилагается полноценный пример настройки на среднестатистической Linux-системе. Исправим это данным постом.

Поставим задачу следующим образом:

1. Автоматический бэкап запускается ежедневно.
2. Бэкап хранит только важные файлы и данные.
3. Бэкап также включает в себя содержимое баз PostgreSQL, которое можно восстановить psql -f.

В какой-то момент начинает требоваться отладить программу, которую нельзя отладить на рабочем компьютере. В моем случае потребовалось отладить программу, общающуюся по D-Bus с iwd, демоном, заведующим соединениями по Wi-Fi, на ноутбуке.

В VSCode есть аддон Remote Development, специально предназначенный для подобных случаев. Меня он не устраивал по нескольким причинам:

1. Автоматическое подписание коммитов GnuPG из VSCode не заработало.
2. Не заработал SSH-агент (вероятно, из-за отключенного проброса агента).
3. Не заработало, казалось бы, имеющееся в RD открытие локальной директории на удаленной машине (часть нужных файлов не была включена в версионный контроль, а ручным копированием по сети каждый раз заниматься не хотелось).

Я пишу на Go, так что хак, который я буду описывать, предназначен для отладчика Delve. Сам подход меняется мало вне зависимости от языка программирования; аналогичное можно сделать с используемым в VSCode для Python ptvsd и любым другим отладчиком, позволяющим удаленные соединения.

DNSCrypt — довольно популярный вариант защиты обычно не шифруемого DNS-трафика от внешних лиц. Клиентский резолвер dnscrypt-proxy поддерживает в том числе протокол DNS-over-HTTPS, позволяя разрешать доменные имена через DoH.

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

Пользование виртуальными машинами на Linux в Hyper-V из коробки — несколько менее комфортное занятие, чем с гостевыми Windows-машинами. Причиной тому является то, что Hyper-V все же изначально не предназначался для десктопного пользования; нельзя просто взять, поставить пакет гостевых дополнений и получить работоспособное графическое ускорение, буфер обмена, общие директории и другие радости жизни, как это происходит в VirtualBox.

Hyper-V сам предоставляет несколько сервисов интеграции — так, гости могут пользоваться службой теневого копирования (VSS) хоста, гостям можно послать сигнал выключения, гости могут синхронизировать системное время с хостом виртуализации, с хоста возможен обмен файлами с виртуальной машиной (Copy-VMFile в PowerShell). Для некоторых гостевых операционных систем, в числе которых, конечно, находится и Windows, в приложении Virtual Machine Connection (vmconnect.exe) доступен Enhanced Session Mode, работающий по протоколу RDP и позволяющий пробрасывать в виртуальную машину дисковые устройства и принтеры, а также пользоваться общим буфером обмена.

Enhanced Session Mode из коробки работает в Windows в Hyper-V сразу после установки. С гостями на Linux нужно устанавливать RDP-сервер, поддерживающий vsock (специальное виртуальное сетевое адресное пространство в Linux, предназначенное для коммуникации с гипервизором). Если для Ubuntu в приложении VMCreate, идущим с Hyper-V на настольных редакциях Windows, есть специальный подготовленный шаблон виртуальной машины, в котором работающий с vsock RDP-сервер XRDP уже предустановлен, то с другими дистрибутивами все менее однозначно — так, у автора этого поста получилось включить ESM в Fedora. Здесь же мы активируем Enhanced Session Mode для виртуальной машины с Arch Linux.