У меня та же проблема, когда lxc работает без привилегий. Но если контейнер работает с привилегиями, то rootless podman, кажется, работает.

Думаю, это зависит от вашей задачи. Для меня всё ценное уже будет находиться внутри LXC. Если он скомпрометирован, то уже не так важно, что технически над ним есть хост, который, скорее всего, в порядке. Мне ценность LXC в лёгких бэкапах и снапшотах, к которым можно вернуться при тестировании изменений. Если выбирать между одним и другим, я бы предпочёл, чтобы безопасность обрабатывалась на уровне Podman. Я пока не встречал ничего, что указывало бы на то, что запуск привилегированного LXC хуже, чем запуск пакетов вроде podman напрямую на хосте, но эта тема не самая простая для исследования.

Несколько полезных советов для тех, кто случайно сюда попал:

Просто чтобы повторить, в любом LXC, где запущен podman, зайдите в Options > Features и убедитесь, что включена опция Nesting (а также Keyctl, если podman работает без прав root). Отсутствие этого привело меня к большому разочарованию.

Вы можете получить последнюю версию Podman (с улучшенной сетевой конфигурацией и ZFS) напрямую из Debian, используя APT pinning. Просто добавьте репозиторий testing в /etc/apt/sources.list:

Code: deb https://ftp.debian.org/debian testing contrib main non-free non-free-firmware

Затем создайте /etc/apt/preferences.d/pref и добавьте:

Code: Package: *
Pin: release a=testing
Pin-Priority: 50

Затем выполните:

apt update
apt-cache policy

Это должно показать репозитории Testing/Trixie и пометить их приоритетом 50. Теперь у вас есть репозиторий, но он не будет использоваться, если вы вручную не установите из него пакет. Так, apt install -t trixie podman установит/обновит Podman 4.9+ и его зависимости (включая pasta) из репозитория testing.

Также многие пользователи сталкиваются со странными ошибками при работе в режиме rootless из-за того, что использование sudo/su для переключения между учетными записями может нарушить некоторые переменные, от которых зависит podman. К счастью, если установить пакет systemd-container, то можно использовать Bash: machinectl shell --uid <UsernameHere> для создания чистой сессии пользователя из вашей корневой сессии и выйти из нее с помощью Ctrl+ ]]].

При разрешении TUN-сетевого подключения для LXC для передачи в podman в режиме rootless, я предпочитаю добавлять обе группы cgroups внизу файла /etc/pve/lxc/<ContainerIDHere>.conf, на всякий случай:

Code: lxc.cgroup.devices.allow: c 10:200 rwm
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net dev/net none bind,create=dir

Если вы уже сделали снимки этого LXC и эти строки не работают, возможно, вам также нужно добавить их в базовую группу выше снимков.

Запуск контейнеров podman при загрузке – довольно странная штука. В отличие от Docker, он не имеет демона, поэтому по умолчанию ничего не запускается. Старый способ запуска контейнеров автоматически — это создание отдельной службы Systemd для каждого контейнера. В новых версиях эта опция помечена как устаревшая (что вызвало небольшое возмущение), хотя они заявили, что нет планов по её удалению. В качестве альтернативы предлагают Quadlets, которые чем-то напоминают конфигурации docker compose, где весь файл записывается непосредственно в Systemd, но они специфичны для podman и имеют совершенно другой синтаксис. Я предпочитаю избегать обеих этих вещей и просто создаю одну службу Systemd, которая запускается при загрузке и запускает все контейнеры с параметром --restart=always, что делает все примерно так же просто, как с Docker.

Сначала необходимо включить linger для пользователя, под которым запущен podman, чтобы службы могли автоматически запускаться от имени этого пользователя без необходимости входить в систему:

Bash: loginctl enable-linger <RootlessUsernameHere>

Затем, как этот пользователь, создайте ~/.config/systemd/user/podman-restart.service со следующим содержимым:

Code: [Unit]
Description=Podman Start All Containers With Restart Policy Set To Always
Documentation=man:podman-start(1)
StartLimitIntervalSec=0
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
RemainAfterExit=true
Environment=LOGGING="--log-level=info"
ExecStart=podman $LOGGING start --all --filter restart-policy=always
ExecStop=/bin/sh -c 'podman $LOGGING stop $(podman container ls --filter restart-policy=always -q)'

[Install]
WantedBy=default.target

Затем запустите ее с помощью:

Bash: systemctl --user daemon-reload
systemctl --user start podman-restart
systemctl --user enable podman-restart

Ты тоже успел поработать с pasta? У меня podman не может найти pasta, хотя она установлена.