Аспро: ЛайтШоп [тема: Podman в режиме без прав root в контейнере LXC]

Podman в режиме без прав root в контейнере LXC

Sun, 06 Jul 2025 15:06:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я следовал вашему руководству и теперь могу успешно запускать podman в rootless режиме. Но появилась другая проблема: после перезагрузки LXC появляется ошибка: Error: current system boot ID differs from cached boot ID; an unhandled reboot has occurred. Пожалуйста, удалите директории "/tmp/storage-run-1001/containers" и "/tmp/storage-run-1001/libpod/tmp" и перезапустите Podman, когда я пытаюсь запустить podman. Мне приходится удалять директории, как вы сказали, чтобы снова запустить podman после загрузки. Вы знаете, как решить эту проблему?
06.07.2025 15:06:00, yushi.

Podman в режиме без прав root в контейнере LXC

Sun, 04 Aug 2024 08:18:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Ты тоже успел поработать с pasta? У меня podman не может найти pasta, хотя она установлена.
04.08.2024 08:18:00, smarthomejarvis.

Podman в режиме без прав root в контейнере LXC

Tue, 14 May 2024 14:04:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Можно запускать контейнеры из compose-файлов, которые не поддерживают все специфичные для Podman функции (например, pods), но могут быть полезны для вещей, которые представлены только в таком формате, вроде SWAG proxy. Dockge — отличный веб-интерфейс для этого. Использует сокет совместимости с Docker для управления контейнерами, но не обязательно должен оставаться запущенным после настройки, и отлично работает в rootless режиме. Сначала устанавливаете пакет podman-docker. Я использую тестовую репозиторие, так как использую её для Podman: `apt install -t trixie podman-docker`. Затем настраиваете сокет и добавляете его переменную в bash:

Bash:
`systemctl --user enable podman.socket`
`systemctl --user start podman.socket`
`systemctl --user status podman.socket`
`export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock`
`echo 'export DOCKER_HOST=unix:///run/user/$UID/podman/podman.sock' >> ~/.bash_profile`

Затем просто устанавливаете Dockge как обычно, но перед запуском его compose.yaml измените путь к томам на `/var/run/user//podman/podman.sock:/var/run/docker.sock`. С Yacht я не пробовал, но они тоже управляют Podman через сокет, так что результаты могут быть разными.

Если нужно запускать привилегированные TCP-порты в rootless режиме (например, обратный прокси, слушающий на 443), но не хотите давать rootless пользователям доступ к этим портам, документация Podman отмечает, что redir — это крутая альтернатива. Просто включите linger, если вы этого еще не сделали, затем установите redir: `apt install redir` и добавьте следующее в новый файл, например, `/etc/systemd/system/redir443.service`:

```
[Unit]
Description=Redirect tcp port 443 to 1443 with redir

[Service]
ExecStart=/bin/redir -sn :443 127.0.0.1:1443

[Install]
WantedBy=multi-user.target
```

чтобы перенаправить трафик, поступающий на хост-порту 443, чтобы Podman-сервис мог его получить на 1443. Повторяйте то же самое для любых других портов, которые хотите, затем включайте:

Bash:
`systemctl daemon-reload`
`systemctl enable --now redir443.service`

Кстати, если просто хотите протестировать это до следующей перезагрузки, можно пропустить всё это и запустить redir :443 127.0.0.1:1443
14.05.2024 14:04:00, DHigginson.

Podman в режиме без прав root в контейнере LXC

Tue, 14 May 2024 09:38:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Несколько полезных советов для тех, кто случайно сюда попал:

Просто чтобы повторить, в любом 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 для создания чистой сессии пользователя из вашей корневой сессии и выйти из нее с помощью Ctrl+ ]]].

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

Затем, как этот пользователь, создайте ~/.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
14.05.2024 09:38:00, DHigginson.

Podman в режиме без прав root в контейнере LXC

Tue, 07 May 2024 10:17:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Вчера наконец-то заработало. Непривилегированный Alpine LXC с Podman, работающим от имени пользователя без прав root. Требуется включение вложенности, пока времени на изучение этого вопроса не было. (PVE: команда на хосте Proxmox, LXC: команда на LXC) Дайте Proxmox-у доступ к большему количеству под-UID/GUID: Bash: PVE> vi /etc/subuid
root:100000:200000 # ::
PVE> vi /etc/subgid
root:100000:200000 Отобразите UID/GUID контейнера на UID/GUID хоста: Bash: PVE> vi /etc/pve/lxc/.conf
#
lxc.idmap: u 0 100000 165536 # uids 0..165536 (контейнер) -> 100000..265536 (хост)
lxc.idmap: g 0 100000 165536 # gids Проверьте отображение UID/GUID контейнера: Bash: LXC> cat /proc/self/uid_map
0 100000 165536 Дайте непривилегированным пользователям в LXC, которые будут использовать Podman, доступ к под-UID/GUID: Bash: LXC> vi /etc/subuid
username:100000:65536
LXC> vi /etc/subgid
username:100000:65536 Разрешите LXC доступ к ядру tun (требуется slirp4netns): Bash: PVE> vi /etc/pve/lxc/.conf
lxc.cgroup2.devices.allow: c 10:200 rwm # cgroup2 для PVE >= 7.0
lxc.mount.entry: /dev/net dev/net none bind,create=dir Установите Podman: Bash: LXC> apk add podman py3-pip shadow shadow-subids
LXC> pip3 install podman-compose --break-system-packages
LXC> rc-update add cgroups Войдите как пользователь без прав root и попробуйте запустить Podma: Bash: LXC> podman run --rm hello-world Alpine, похоже, требует пакеты shadow и shadow-subids, чтобы работала /usr/bin/newuidmap. Я пока не знаю, всё ли работает, но запуск podman-compose с конфигурацией Gotify, которая у меня валялась, прошёл без проблем. Надеюсь, это поможет.
07.05.2024 10:17:00, Mich4.

Podman в режиме без прав root в контейнере LXC

Mon, 11 Mar 2024 10:17:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Думаю, это зависит от вашей задачи. Для меня всё ценное уже будет находиться внутри LXC. Если он скомпрометирован, то уже не так важно, что технически над ним есть хост, который, скорее всего, в порядке. Мне ценность LXC в лёгких бэкапах и снапшотах, к которым можно вернуться при тестировании изменений. Если выбирать между одним и другим, я бы предпочёл, чтобы безопасность обрабатывалась на уровне Podman. Я пока не встречал ничего, что указывало бы на то, что запуск привилегированного LXC хуже, чем запуск пакетов вроде podman напрямую на хосте, но эта тема не самая простая для исследования.
11.03.2024 10:17:00, DHigginson.

Podman в режиме без прав root в контейнере LXC

Tue, 05 Mar 2024 18:39:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Я даже не пробовал, потому что, на мой взгляд, это кажется немного бессмысленным. В таком решении сам podman и каждый контейнер, работающий на уровне root в LXC, могут иметь права root на хосте. Я нашел несколько тем, где запуск podman без привилегий в контейнере LXC без привилегий не рекомендуется или даже не приветствуется из-за вложенной изоляции, которая не работает. Конечно, Proxmox это не поддерживает. Так что я сдался и запускаю podman в легковесной debian vm с Cockpit. Работает отлично, но потребляет примерно 0,5 ГБ RAM больше.
05.03.2024 18:39:00, marceliszpak.

Podman в режиме без прав root в контейнере LXC

Tue, 05 Mar 2024 18:06:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
У меня та же проблема, когда lxc работает без привилегий. Но если контейнер работает с привилегиями, то rootless podman, кажется, работает.
05.03.2024 18:06:00, completion.

Podman в режиме без прав root в контейнере LXC

Sun, 18 Feb 2024 14:25:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
Когда я смотрю на конфигурационный файл lxc, вижу: root@proxmox:~# cat /etc/pve/lxc/106.conf arch: amd64 cores: 2 features: nesting=1 hostname: Test memory: 8192 net0: name=eth0,bridge=vmbr2,firewall=1,hwaddr=BC:24:11:49:21:6B,ip=dhcp,type=veth ostype: debian rootfs: local-zfs:subvol-106-disk-0,size=30G swap: 512 unprivileged: 1 root@HomeServer:~# Неужели там не хватает определения lxc.idmap?
18.02.2024 14:25:00, marceliszpak.

Podman в режиме без прав root в контейнере LXC

Sun, 18 Feb 2024 03:41:00 +0300

Podman в режиме без прав root в контейнере LXC Proxmox Виртуальная Среда в форуме Proxmox Виртуальная Среда.
У меня проблема с запуском Podman от имени не-root пользователя в LXC. Я пробовал это на LXC, основанных на Debian и Fedora, без успеха. Установка прошла нормально, от имени root всё работает, но любая команда Podman от имени не-root пользователя заканчивается так:

cockpit@Test:~$ podman info
ERRO[0000] running `/usr/bin/newuidmap 4852 0 1000 1 1 165536 65536`: newuidmap: write to uid_map failed: Operation not permitted
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1

от имени root:

cockpit@Test:~$ sudo podman info
[sudo] password for cockpit:
host:
arch: amd64
buildahVersion: 1.28.2
cgroupControllers:
- cpu
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon_2.1.6+ds1-1_amd64
path: /usr/bin/conmon
version: 'conmon version 2.1.6, commit: unknown'
cpuUtilization:
idlePercent: 98.59
systemPercent: 0.41
userPercent: 1
cpus: 2
distribution:
codename: bookworm
debian:
version: "12"
eventLogger: journald
hostname: Test
idMappings:
gidmap: null
uidmap: null
kernel: 6.5.11-8-pve
linkmode: dynamic
logDriver: journald
memFree: 8258920448
memTotal: 8589934592
networkBackend: netavark
ociRuntime:
name: crun
package: crun_1.8.1-1+deb12u1_amd64
path: /usr/bin/crun
version: |-
crun version 1.8.1
commit: f8a096be060b22ccd3d5f3ebe44108517fbf6c30
rundir: /run/crun
spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
exists: true
path: /run/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: false
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns_1.2.0-1_amd64
version: |-
slirp4netns version 1.2.0
commit: 656041d45cfca7a4176f6b7eed9e4fe6c11e8383
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.4
swapFree: 0
swapTotal: 0
uptime: 0h 10m 36.00s
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries: {}
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mount_program:
Executable: /usr/local/bin/overlayzfsmount
Package: Unknown
Version: 'mount from util-linux 2.38.1 (libmount 2.38.1: selinux, smack, btrfs, verity, namespaces, assert, debug)'
overlay.mountopt: nodev
graphRoot: /var/lib/containers/storage
graphRootAllocated: 32212254720
graphRootUsed: 1242038272
graphStatus:
Backing Filesystem: zfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 0
runRoot: /run/containers/storage
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 4.3.1
Built: 0
BuiltTime: Thu Jan 1 00:00:00 1970
GitCommit: ""
GoVersion: go1.19.8
Os: linux
OsArch: linux/amd64
Version: 4.3.1
User has its subordinates defined
cockpit@Test:~$ grep cockpit /etc/subuid /etc/subgid
/etc/subuid:cockpit:165536:65536
/etc/subgid:cockpit:165536:65536

Та же установка на VM работает безупречно, но в LXC я не могу заставить её работать.
18.02.2024 03:41:00, marceliszpak.