Почему в контейнере интернет / apt может не работать В обычной системе (не в контейнере) всё обычно работает «из коробки», потому что там сеть настраивается автоматически. В контейнере всё немного по-другому: Контейнер получает интернет через хост-машину (компьютер, на котором запущен Incus). DNS (то, что превращает google.com в IP-адрес) тоже должен приходить от хоста. Очень часто в новых Debian/Ubuntu внутри контейнера включается штука под названием systemd-resolved — она пытается сама настроить DNS, но в контейнере у неё это получается плохо или вообще не получается. В итоге в файле /etc/resolv.conf оказывается либо пусто, либо только строка nameserver 127.0.0.53, либо вообще ничего полезного → интернет не работает, apt update зависает или очень медленно идёт. Это одна из самых частых проблем у новичков с контейнерами. Самый простой и надёжный способ исправить (для большинства случаев) Зайдите в контейнер и выполните эти 4 команды подряд: # 1. Отключаем систему, которая мешает systemctl disable --now systemd-resolved # 2. Удаляем старый (неправильный) файл rm -f /etc/resolv.conf # 3. Создаём нормальный файл с публичными DNS-серверами echo "nameserver 8.8.8.8" > /etc/resolv.conf echo "nameserver 1.1.1.1" >> /etc/resolv.conf # 4. (опционально) Защищаем файл от перезаписи chattr +i /etc/resolv.conf После этого сразу попробуйте: ping 8.8.8.8 ping google.com apt update Должно заработать почти мгновенно. Почему именно эти DNS-сервера 8.8.8.8 → Google Public DNS 1.1.1.1 → Cloudflare DNS Они быстрые, надёжные, находятся по всему миру и почти никогда не падают. Что будет после перезагрузки контейнера? Если вы не поставили chattr +i, то после перезапуска контейнера файл /etc/resolv.conf может снова стать неправильным. Тогда просто повторите команды 1–3 заново (или сделайте маленький скрипт, который запускается при старте). Короткая памятка (скопируйте и сохраните) # Быстрый фикс DNS в контейнере Debian/Ubuntu systemctl disable --now systemd-resolved rm -f /etc/resolv.conf echo "nameserver 8.8.8.8" > /etc/resolv.conf echo "nameserver 1.1.1.1" >> /etc/resolv.conf # Чтобы не слетало после перезагрузки: chmod 644 /etc/resolv.conf # Проверка ping google.com apt update Теперь интернет должен работать стабильно.

Снятие ограничений для Docker в Incus на Debian 13 Введение При запуске Docker внутри контейнера Incus (LXC) на Debian 13 можно столкнуться с ошибкой: OCI runtime create failed: open sysctl net.ipv4.ip_unprivileged_port_start file: permission denied Эта ошибка возникает не из-за Docker, а из-за ограничений безопасности LXC-контейнера. В данной статье объясняется, что именно блокируется и почему команда: incus config set incus-jitsi security.privileged true incus restart incus-jitsi решает проблему. Архитектура по умолчанию Стандартная схема: Host Debian 13 └── Incus container (unprivileged) └── Docker └── Docker containers По умолчанию Incus создаёт непривилегированные контейнеры (unprivileged). Это означает: UID 0 внутри контейнера ≠ root на хосте используется user namespace запрещена запись в ряд файлов /proc/sys запрещены некоторые операции с cgroups ограничены сетевые sysctl Почему Docker не запускался Docker использует: namespaces cgroups overlayfs изменение sysctl runtime runc При запуске контейнера runc применяет стандартные параметры OCI, включая попытку изменить: /proc/sys/net/ipv4/ip_unprivileged_port_start В unprivileged LXC: доступ к этому sysctl запрещён запись блокируется механизмами user namespace + AppArmor Docker получает permission denied Даже если внутри контейнера вы root — это "виртуальный" root. Что делает security.privileged true Команда: incus config set incus-jitsi security.privileged true переключает контейнер в privileged режим. После перезапуска: incus restart incus-jitsi контейнер: больше не использует user namespace UID 0 внутри контейнера = UID 0 на хосте получает расширенные права к /proc может изменять sysctl получает доступ к большему набору kernel capabilities снимаются ограничения на часть cgroup операций Фактически контейнер становится максимально близким к полноценной виртуальной машине по правам (но без собственного ядра). Почему это помогло Docker После включения privileged: runc смог записать sysctl не произошло блокировки при reopen fd container init завершился успешно Docker-контейнер стартовал То есть проблема была не в Docker, а в том, что LXC запрещал операции, необходимые для запуска вложенной контейнеризации. Что именно было снято При переходе в privileged режим: Ограничение До После User namespace включён отключён UID mapping remapped прямой Запись в /proc/sys ограничена разрешена Kernel capabilities урезаны расширены Работа Docker частично блокируется работает Важное предупреждение security.privileged=true снижает безопасность. Контейнер: получает почти полный root-доступ к хосту может потенциально повлиять на систему не изолирован так строго, как unprivileged Для production-систем рекомендуется: использовать security.nesting=true вместо privileged или запускать Docker в Incus VM (--vm) или запускать Docker непосредственно на хосте Когда допустимо использовать privileged лабораторные стенды тестовые окружения разработка домашний сервер Для публичных сервисов (например, Jitsi Meet) лучше рассмотреть VM. Итог Команда: incus config set <container> security.privileged true снимает ограничения user namespace и расширяет права контейнера до уровня, необходимого для полноценной работы Docker внутри Incus. Это решает проблему запуска, но делает контейнер менее безопасным. Оптимальный баланс между работоспособностью и безопасностью — security.nesting=true без privileged режима.

Предположим, контейнер называется cont-incus-yuno-1 Вот самый простой и надёжный способ перенести контейнер cont-incus-yuno-1 на другой компьютер с помощью Incus (работает для контейнеров, даже запущенных): На исходном сервере (где контейнер сейчас работает) Создайте экспорт (рекомендуется остановить контейнер для консистентности, но можно и на живую): Вариант А — остановить (самый безопасный): incus stop cont-incus-yuno-1 incus export cont-incus-yuno-1 cont-yuno-backup.tar.gz incus start cont-incus-yuno-1 # можно сразу запустить обратно, если нужно Вариант Б — на живую (быстрее, но есть небольшой риск несогласованности файловой системы): incus export cont-incus-yuno-1 cont-yuno-backup.tar.gz Полезные флаги (добавляйте по желанию): --instance-only — очень рекомендуется, если не нужны снапшоты (файл будет намного меньше и быстрее создаваться) --optimized-storage — если хранилище позволяет (zfs/btrfs), делает ещё меньше размер Пример с флагами (самый популярный вариант): incus export cont-incus-yuno-1 cont-yuno-backup.tar.gz --instance-only --optimized-storage Получится файл cont-yuno-backup.tar.gz (или как вы его назовёте) размером от нескольких сотен МБ до десятков ГБ — зависит от содержимого контейнера. Перенесите файл на другой компьютер любым удобным способом: scp rsync флешка / внешний диск облако (если объём позволяет) # пример через scp scp cont-yuno-backup.tar.gz user@новый-ip:/home/user/ На целевом сервере (куда переносите) Убедитесь, что Incus установлен и работает той же или новее версии (экспорт с более новой версии на старую часто не работает). Если контейнер использует нестандартные профили (кроме default), создайте их заранее на новом сервере: incus profile list # посмотреть, какие профили есть # если нужно — скопируйте конфиг профиля и создайте: incus profile create myprofile incus profile edit myprofile Импортируйте: incus import cont-yuno-backup.tar.gz cont-incus-yuno-1 Или с другим именем, если хотите: incus import cont-yuno-backup.tar.gz yuno-new Запустите: incus start cont-incus-yuno-1 # или incus start yuno-new Проверьте, что всё работает: incus list incus console cont-incus-yuno-1 # или incus exec ... -- bash Полезные замечания Если после импорта контейнер не стартует из-за MAC-адреса → удалите/сгенерируйте новый: # 1. Посмотреть, какой именно MAC "застрял" в базе Incus incus info incus-yuno-std | grep volatile.eth0.hwaddr # или полная картина incus config show incus-yuno-std --expanded | grep hwaddr # 2. Самый простой и безопасный способ — попросить Incus сгенерировать новый MAC incus config unset incus-yuno-std volatile.eth0.hwaddr # или явно задать новый (можно опустить — сам сгенерирует) # incus config set incus-yuno-std volatile.eth0.hwaddr 00:16:3e:xx:yy:zz # 3. Попробовать запустить incus start incus-yuno-std Если на новом сервере другое хранилище (например, был zfs, стал dir или btrfs) — импорт обычно проходит нормально, но иногда нужно указать пул: incus import cont-yuno-backup.tar.gz cont-incus-yuno-1 --storage default Размер файла и время создания/переноса — главный ограничивающий фактор. Если контейнер очень большой (>20–30 ГБ) — подумайте, не лучше ли воспользоваться rsync содержимого или incus copy по сети (если есть хоть какая-то связь между серверами).

Снятие ограничений для Docker в LXC на Ubuntu 24.04 # Template used to create this container: /usr/share/lxc/templates/lxc-download # Parameters passed to the template: --dist debian --release bookworm --arch amd64 # For additional config options, please look at lxc.container.conf(5) # Включаем поддержку вложенных контейнеров (nesting) lxc.include = /usr/share/lxc/config/nesting.conf # Отключаем ограничения AppArmor для полной свободы действий lxc.apparmor.profile = unconfined # Разрешаем все устройства (для работы Docker) lxc.cgroup.devices.allow = a # Убираем ограничения на capabilities (полные права для контейнера) lxc.cap.drop = # Разрешаем монтирование системных директорий с правами чтения-записи lxc.mount.auto = proc:rw sys:rw # Distribution configuration lxc.include = /usr/share/lxc/config/common.conf lxc.arch = linux64 # Container specific configuration lxc.rootfs.path = dir:/var/lib/lxc/container_native/rootfs lxc.uts.name = container_native # Network configuration lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.hwaddr = 00:16:3e:7f:79:c0 lxc.net.0.ipv4.address = 10.0.3.170/24 lxc.net.0.ipv4.gateway = 10.0.3.1 Этот конфиг LXC работает на хосте Ubuntu 24.04 и позволяет нормально запускать Docker с Jitsi внутри контейнера Конфиг создаёт привилегированный LXC-контейнер (без lxc.idmap, от root) с Debian 12 внутри. Он включает ключевые настройки для nested контейнеризации (Docker внутри LXC): lxc.include = /usr/share/lxc/config/nesting.conf — включает nesting. lxc.apparmor.profile = unconfined — полностью отключает AppArmor. lxc.cgroup.devices.allow = a — разрешает все устройства. lxc.cap.drop = — сохраняет все capabilities. lxc.mount.auto = proc:rw sys:rw — монтирует /proc и /sys с правами записи. На Ubuntu 24.04 этот конфиг работает стабильно, и Docker (включая сложный стек Jitsi с web, prosody, jicofo, jvb) запускается без ошибок. На Debian 13 (или старых версиях) часто возникают проблемы с overlay2, cgroups, сетью или capabilities. Вот подробное объяснение причин. 1. Более свежее ядро Linux Ubuntu 24.04 использует Linux kernel 6.8 (с возможными обновлениями до новее через HWE). Это обеспечивает отличную поддержку: cgroups v2 (единой иерархии, которую Docker предпочитает по умолчанию). overlayFS (storage driver overlay2 в Docker — самый эффективный). Вложенных namespaces и устройств для nested контейнеров. Docker и Jitsi (особенно JVB с UDP-портами и сетевыми привилегиями) требуют современных фич ядра. На старом ядре (например, 6.1 в базовом Debian) могут быть баги или отсутствовать оптимизации → ошибки при создании контейнеров. 2. Более лояльный и современный AppArmor Ubuntu активно развивает AppArmor (Canonical — основной контрибьютор). В Ubuntu 24.04 профили для nested контейнеров менее строгие: даже без unconfined многие системные вызовы проходят. nesting.conf в Ubuntu включает улучшения для вложенных контейнеров (лучшая поддержка overlay, cgroups, capabilities). В Debian AppArmor строже и консервативнее → даже с nesting часто блокирует вызовы, нужные Docker (mount namespace, cap_sys_admin для JVB, сетевые операции). Поэтому требуется явное unconfined. На Ubuntu ваш конфиг с unconfined работает, но часто достаточно и без него — система "прощает" больше. 3. Автоматические улучшения для nested контейнеров в LXC Версия LXC в Ubuntu 24.04 — новее (5.x–6.x с патчами от Canonical). nesting.conf в Ubuntu авто-разрешает многие вещи: Полный доступ к cgroups для Docker. Лучшую работу с устройствами и capabilities. Монтирование /proc и /sys без дополнительных настроек. В Debian nesting менее "щедрый" → нужны дополнительные строки (например, ручное монтирование cgroup2). Ubuntu ориентирована на облака/контейнеры (Canonical продвигает LXD/LXC), поэтому баги с Docker внутри LXC фиксятся быстрее. 4. Привилегированный режим "из коробки" Контейнер привилегированный (нет idmap) → root внутри имеет почти полные права на хостовом ядре. В комбинации с свежим ядром и AppArmor это даёт Docker всё необходимое: Управление cgroups. Создание overlayFS. NET_ADMIN/SYS_ADMIN для сетей Jitsi. На Debian даже в привилегированном режиме строгий AppArmor и старое ядро могут ограничивать. 5. Специфика Jitsi в Docker Jitsi требует: UDP-порты (10000/10001) с NET_ADMIN. Много устройств (timerfd, RTC). Полные capabilities для JVB (видеомост). На Ubuntu это проходит гладко благодаря ядру и nesting. На Debian часто падает JVB или web с ошибками "shim task", "mount namespace" или "overlay not supported". Итог: Ubuntu 24.04 "заточена" под современную контейнеризацию — свежее ядро, лояльный AppArmor и оптимизированный LXC делают ваш конфиг достаточным. Debian более консервативен и стабилен, но требует дополнительных настроек (как в исправленном конфиге из обсуждения: без privileged-ключа, с ручным cgroup2). Поэтому на Ubuntu всё работает "из коробки", а Jitsi запускается без проблем. Если переходите на Debian-хост — используйте полный исправленный конфиг с монтированием cgroup2.

Удаление LXD Повлияет ли удаление LXD на ранее установленный LXC? Нет, это не удалит LXC! LXD и LXC — это разные пакеты. Различия: LXC (Linux Containers) — низкоуровневые инструменты контейнеризации (lxc-create, lxc-start, etc.) LXD — система управления контейнерами поверх LXC (демон, REST API, дополнительные функции) Проверьте, что удаляется и что остается: Что удалит apt remove --purge lxd lxd-client: # Удалит только пакеты LXD: lxd # демон LXD lxd-client # клиентская часть LXD Что останется: # Основные пакеты LXC останутся: lxc # основные инструменты LXC lxc-utils # утилиты LXC lxc-templates # шаблоны контейнеров liblxc1 # библиотеки LXC Проверьте установленные пакеты LXC: # Посмотреть установленные пакеты LXC/LXD dpkg -l | grep -E "lxc|lxd" # Пример вывода (LXC останутся): # ii lxc 5.0.3-0ubuntu2 amd64 # ii lxc-utils 5.0.3-0ubuntu2 amd64 # rc lxd 1:0.8 # "rc" значит удален # rc lxd-client 1:0.8 # "rc" значит удален Incus будет работать с существующим LXC: Incus использует те же низкоуровневые инструменты LXC, так что после удаления LXD вы сможете установить Incus, и он будет работать с уже установленным LXC. Если хотите удалить ВСЁ (и LXC тоже): # Удалить LXD sudo apt remove --purge lxd lxd-client # Удалить LXC (только если уверены!) sudo apt remove --purge lxc lxc-utils lxc-templates liblxc1 lxcfs # Для Incus LXC не нужен, он использует свою реализацию Рекомендация: Оставьте LXC установленным. Incus будет работать нормально, и у вас останутся низкоуровневые инструменты для управления контейнерами напрямую, если понадобится.

Шаг 1: Подготовка системы # Обновляем список пакетов и систему sudo apt update sudo apt upgrade -y # Устанавливаем базовые утилиты, которые могут пригодиться sudo apt install -y curl wget gnupg software-properties-common # Для Debian 13 так: sudo apt install -y curl wget gnupg ca-certificates apt-transport-https Шаг 2: Настраиваем репозиторий Backports # Добавляем репозиторий backports echo "deb http://deb.debian.org/debian bookworm-backports main" | sudo tee /etc/apt/sources.list.d/bookworm-backports.list # Настраиваем приоритеты, чтобы избежать проблем с экспериментальными пакетами sudo tee /etc/apt/preferences.d/90-bookworm-backports << EOF Package: * Pin: release a=bookworm-backports Pin-Priority: 500 Package: incus* Pin: release a=bookworm-backports Pin-Priority: 1000 Package: * Pin: release a=experimental Pin-Priority: 1 EOF # Обновляем список пакетов с учетом новых репозиториев sudo apt update Шаг 3: Установка Incus (без QEMU) # Устанавливаем Incus без рекомендательных пакетов (исключаем QEMU) sudo apt install -t bookworm-backports incus --no-install-recommends -y # Для Debian 13: sudo apt install incus --no-install-recommends -y Шаг 4: Запуск службы Incus # Запускаем службу Incus sudo systemctl start incus incus.socket # Включаем автозапуск sudo systemctl enable incus incus.socket # Проверяем статус sudo systemctl status incus Шаг 5: Настройка Incus # Запускаем инициализацию с настройками по умолчанию sudo incus admin init --auto Что делает --auto: Создает storage pool default с бэкендом dir Создает сетевой мост incusbr0 с NAT Включает IPv6 Настраивает API на локальный socket Шаг 6: Проверка установки # Проверяем, что демон работает sudo systemctl status incus # Проверяем список контейнеров (должен быть пустым) sudo incus list # Проверяем информацию о сервере sudo incus info Шаг 7: Настройка прав пользователя (опционально) Чтобы не использовать sudo для каждой команды, добавьте своего пользователя в группу incus: # Добавляем текущего пользователя в группу incus sudo usermod -a -G incus-admin $USER # Применяем изменения группы (или перелогиньтесь) newgrp incus-admin # Проверяем группы # Должны видеть incus-admin в списке groups # Проверяем, что теперь можно работать без sudo incus list Шаг 8: Запуск первого контейнера # Запускаем контейнер с Ubuntu 22.04 incus launch images:ubuntu/22.04 test-container # Проверяем, что контейнер запустился incus list # Заходим в контейнер incus exec test-container -- bash # Внутри контейнера можно проверить систему cat /etc/os-release exit Полезные команды для начала работы # Просмотр доступных образов incus image list images: | head -20 # Создание контейнера с конкретным дистрибутивом incus launch images:debian/12 my-debian incus launch images:alpine/3.18 my-alpine # Остановка контейнера incus stop test-container # Удаление контейнера incus delete test-container # Просмотр информации о хранилище incus storage list # Просмотр сетевых настроек incus network list Если нужна поддержка виртуальных машин (позже) # Установка QEMU для поддержки ВМ sudo apt install -t bookworm-backports qemu-system-x86 -y # Теперь можно запускать виртуальные машины incus launch images:ubuntu/22.04 my-vm --vm Возможные проблемы и решения Проблема: Команда incus не найдена # Перезагружаем или перелогиниваемся sudo reboot # или newgrp incus Проблема: Нет доступа к socket # Проверяем группу пользователя groups $USER # Если нет incus, добавляем и перелогиниваемся sudo usermod -a -G incus $USER newgrp incus Проверка успешной установки После выполнения всех шагов у вас должен быть: Работающая команда incus Контейнер test-container в статусе "RUNNING" Доступ к Incus без sudo (если настроили группу) Как узнать на каком порту слушает incus Способ 1: Команда incus config # Показывает текущий адрес и порт incus config show | grep https_address # Или конкретно incus config get core.https_address Способ 2: Системные утилиты # Показывает все слушающие порты sudo netstat -tlnp | grep incus # Или с помощью ss (более современная) sudo ss -tlnp | grep incus # Ищем процесс incus sudo lsof -i -P -n | grep incus Способ 3: Проверка через systemd # Смотрим статус службы sudo systemctl status incus # Или смотрим сокеты sudo systemctl list-sockets | grep incus Способ 4: Если Incus не слушает порт # Проверяем текущую конфигурацию incus config show # Если порт не настроен, устанавливаем sudo incus config set core.https_address ":8443" # Перезапускаем sudo systemctl restart incus # Проверяем снова sudo ss -tlnp | grep 8443 Способ 5: Проверка всех сетевых соединений # Показывает все открытые порты sudo netstat -tulpn # Или только TCP порты sudo netstat -tlnp Пример вывода когда всё работает: $ sudo ss -tlnp | grep incus LISTEN 0 128 0.0.0.0:8443 0.0.0.0:* users:(("incus",pid=1234,fd=10)) Это значит Incus слушает на порту 8443 на всех интерфейсах. Если порт не настроен: # Настраиваем порт sudo incus config set core.https_address "0.0.0.0:8443" # Или только локальный доступ sudo incus config set core.https_address "127.0.0.1:8443" # Перезапускаем sudo systemctl restart incus # Проверяем sudo ss -tlnp | grep incus Краткая памятка: # УСТАНОВИТЬ порт (работает) ✅ sudo incus config set core.https_address ":8443" # ПРОВЕРИТЬ что слушает (работает) ✅ sudo ss -tlnp | grep incus # ПОСМОТРЕТЬ конфигурацию (только с sudo) ✅ sudo incus config show