Failed to allocate manager object astra linux

Работа с systemd-nspawn в Linux

Опубликовано: 07.02.2023

Используемые термины: Docker, Podman, LXD, Linux. В двух словах, systemd-nspawn — платформа контейнеризации на основе systemd. Ее очевидный плюс заключается в нативности (для любой системы на основе systemd требуется минимум установок и настроек). Из минусов отмечу более сложный процесс настройки и запуска контейнеров. Обо всем по порядку.

Установка

Для работы с systemd-nspawn нам нужно выполнить установку пакета systemd-container. В разных системах это делается, немного, по-разному. а) На Linux Deb (Debian / Ubuntu / Astra Linux):

Подготовка образа

В отличие от других популярных аналогов (Docker, Podman, LXD) systemd-nspawn не имеет своего репозитория с образами, из которых мы можем легко получить контейнер. Поэтому нам необходимо создать свои собственные шаблоны. Для systemd-nspawn образ — это система, установленная в каталог с помощью Debootstrap/Yumbootstrap. Рассмотрим процесс немного подробнее.

Инструменты Debootstrap и Yumbootstrap очень капризные. При работе с ними можно столкнуться с большим количеством разных ошибок. По возможности, я укажу решение некоторых из них. Для минимизации проблем, мы можем выполнить установку системы в каталог на соответствующей платформе, например, если нам нужна Astra Linux, то запускаем debootstrap на Astra Linux. После готовый каталог копируем на машину, где хотим использовать systemd-nspawn.

Debootstrap (образы с deb-linux)

Для установки в каталог системы на основе Debian нам нужно использовать инструмент debootstrap. Его можно установить из базовых репозиториев. В зависимости от системы, на которой мы будем работать, наши действия будут отличаться. а) Если работаем на Linux Deb (Debian / Ubuntu / Astra Linux):

После установки debootstrap можно приступать к установки системы. Посмотрим содержимое каталога /usr/share/debootstrap/scripts:

В нем находится набор готовых скриптов для различных дистрибутивов Linux на основе Deb. Мы должны найти соответствующее название для системы, которую хотим установить в каталог. Предположим, нам нужно работать с Ubuntu 22.04. Ее кодовое название Jammy. Проверяем, что такой скрипт есть:

* в нашем примере будет использоваться скрипт jammy для установки Ubuntu в каталог /var/lib/machines/image-ubuntu-jammy.

Мы можем получить ошибку Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg. Для решения проблемы нам нужно получить gpg-ключ и сохранить его в соответствующем каталоге. Выполняем команды:

Выполняем необходимые команды (например по инструкции С чего начать настройку любого UNIX сервера) и выходим из chroot:

Готово — мы получили deb-образ, который может использоваться в качестве шаблона для контейнеров systemd-nspawn.

Yumbootstrap (образы с rpm-linux)

Утилита yumbootstrap позволит установить в каталог системы на базе RPM. Ее нет в репозиториях, но она идет в поставке с файлами для сборки установочных пакетов deb и rpm. Перейдем в каталог для хранения исходников:

Далее команды для сборки и установки под разные типы дистрибутивов Linux будут отличаться. а) Если работаем на Deb (Debian / Ubuntu / Astra Linux):

б) Если работаем на RPM (Rocky Linux): В процессе сборки мы можем столкнуться с рядом проблем. Рассмотрим все нюансы.

* обратите внимание, что мы устанавливаем именно python версии 2. Для 3-й версии выскакивает ошибка синтаксиса при попытке собрать пакет.

Если мы получим ошибку error: attempt to use unversioned python, define %__python to /usr/bin/python2 or /usr/bin/python3 explicitly, открываем файл:

Мы можем получить ошибку python-setuptools is needed by yumbootstrap. В некоторых дистрибутивах на основе RPM нет пакета python-setuptools — либо python2-setuptools, либо python3-setuptools. Но так как сборщик требует, именно, python-setuptools, внесем правки в spec-файл:

* в нашем примере теперь будет требоваться уже установленный нами пакет python2-setuptools. После снова собираем исходники:

Также на данном этапе мы можем столкнуться с ошибкой ERROR: ambiguous python shebang in . #!/usr/bin/python. Change it to python3 (or python2) explicitly. Открываем файл:

# Replace ambiguous python with python2
py_shebang=$(echo «$shebang» | sed -r -e ‘s@/usr/bin/python(\s|$)@/usr/bin/python2\1@’)

* насколько я смог разобраться, в некоторых системах неправильно определяется оригинальный путь до python2. В моем примере идет подмена неправильного /usr/bin/python на правильный /usr/bin/python2. Решение не самое изящное, но работает.

После установки yumbootstrap можно установить систему в каталог. Смотрим список дистрибутивов, для которых есть шаблоны yumbootstrap:

* в нашем примере будет использоваться шаблон centos-7 для установки Ubuntu в каталог /var/lib/machines/centos-7. Система установлена. При необходимости ее отредактировать, вводим:

Выполняем необходимые команды (например по инструкции С чего начать настройку любого UNIX сервера) и выходим из chroot:

Готово — мы получили rpm-образ, который может использоваться в качестве шаблона для контейнеров systemd-nspawn.

Создание контейнеров

1. Сначала мы скопируем ранее созданный шаблон в папку контейнера.
2. После запустим контейнер без init. В данном режиме мы сможем задать пароль учетной записи root.
3. Полноценный запуск в интерактивном режиме. С целью убедиться, что контейнер работает.
4. Настроим автозапуск контейнера.

Создание контейнера из образа

На самом деле, создать новый контейнер из образа, это скопировать ранее созданный шаблон в каталог /var/lib/machines.

Каталог не обязательно должен быть /var/lib/machines, но для systemd-nspawn предусмотрены шаблоны команд, которые удобнее использовать, если контейнеры находятся, именно, в этой папке.

Скопируем /var/lib/machines/image-ubuntu-jammy и создадим контейнер ubuntu-jammy:

cp -R /var/lib/machines/image-ubuntu-jammy /var/lib/machines/ubuntu-jammy

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to allocate manager object: Read-only file system #301

Failed to allocate manager object: Read-only file system #301

Comments

Fedora 31 has Podman 1.6.2 and I’m really looking forward to experimenting with the networking features introduced in 1.6.0.

My setup is a netinstall of Fedora 31, ran mkdir and setsebool.

Running the example without oci-systemd-hook:

podman run --name freeipa-server-container -ti \ -h ipa.example.test \ -v /sys/fs/cgroup:/sys/fs/cgroup:ro \ --tmpfs /run --tmpfs /tmp \ -v /var/lib/ipa-data:/data:Z freeipa/freeipa-server 

Detected virtualization container-other. Detected architecture x86-64. Set hostname to . Initializing machine ID from random generator. Failed to create /machine.slice/libpod-40be75b58db6c907334a1bd689a16ff8813026e6580e2d9882d1e19c1eaa7ff0.scope/init.scope control group: Read-only file system Failed to allocate manager object: Read-only file system [. ] Failed to allocate manager object. Exiting PID 1. 

Nothing interesting in journalctl.

With oci-systemd-hook installed and running:

run --name freeipa-server-container -ti \ -h ipa.example.test \ --read-only \ -v /var/lib/ipa-data:/data:Z freeipa/freeipa-server 

I get this error on the terminal:

Error: error executing hook /usr/libexec/oci/hooks.d/oci-systemd-hook (exit code: 1): OCI runtime error 

systemd[1]: Started libpod-conmon-ebc52bb01e6f2a503a1fcc782d26d321f350da926328b084e594a4617528d611.scope. systemd[1]: tmp-crun.96bQtZ.mount: Succeeded. systemd[798]: tmp-crun.96bQtZ.mount: Succeeded. systemd[1]: Started libcrun container. oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: rootfs=/var/lib/containers/storage/overlay/3cffee1bc3321b7e845e2e81608f23b2f048b0a3caed9f06b467116bcfe75140/merged oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: gidMappings not found in config oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: GID: 0 oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: uidMappings not found in config oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: UID: 0 oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: /run already present as a mount point in container configuration, skipping oci-systemd-hook[15119]: systemdhook : 0::/machine.slice/libpod-ebc52bb01e6f2a503a1fcc782d26d321f350da926328b084e594a4617528d611.scope : ebc52bb01e6f oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: ::/machine.slice/libpod-ebc52bb01e6f2a503a1fcc782d26d321f350da926328b084e594a4617528d611.scope oci-systemd-hook[15119]: systemdhook : ebc52bb01e6f: Failed to get memory subsystem path for the process: File exists systemd[1]: libpod-ebc52bb01e6f2a503a1fcc782d26d321f350da926328b084e594a4617528d611.scope: Succeeded. systemd[798]: tmp-crun.Nl4WYz.mount: Succeeded. systemd[1]: tmp-crun.Nl4WYz.mount: Succeeded. audit: NETFILTER_CFG table=filter family=2 entries=100 audit: NETFILTER_CFG table=filter family=2 entries=99 

Result is the same with or without the —read-only option.

I’ve replicated this issue 4 times in 3 different machines. I haven’t gotten it to work with the oci-systemd-hook installed, I get the same error everytime. The only way that I’ve gotten it to work is with -v /sys/fs/cgroup:/sys/fs/cgroup and oci-systemd-hook uninstalled. I don’t understand the implications.

While pouring through issues, I understand the read-only options are so that changes to the container aren’t persistent across restarts. But I regularly run my containers with the —rm option anyway and I get a new one every time. What I really care about is the data persisted in the volumes. Can I safely ignore all the read only measures?

The text was updated successfully, but these errors were encountered:

Источник