ntpd в systemd-nspawn

Вопрос или проблема

Я экспериментирую с контейнеризацией различных частей своей серверной инфраструктуры, и одна из служб, которую я хотел бы запускать в контейнере, — это демон ntp.

Я использую systemd-nspawn (systemd 233) в качестве гипервизора, а также процесса инициализации внутри контейнеров.

Версия ntpd — 4.2.8p10.

Каждый раз, когда я пытаюсь запустить ntpd внутри контейнера, он аварийно завершает работу с ошибкой cap_set_proc(): операция не разрешена:

21 окт 11:10:23 ntpd[51]: ntpd [email protected] Пт окт 20 23:28:39 UTC 2017 (1): Запуск
21 окт 11:10:23 ntpd[51]: Командная строка: ntpd -g -n -u ntp:ntp
21 окт 11:10:23 ntpd[51]: Не удается установить RLIMIT_MEMLOCK: операция не разрешена
21 окт 11:10:23 ntpd[51]: proto: точность = 0.335 мкс (-21)
21 окт 11:10:23 ntpd[51]: Ожидает подключения на 0 v4wildcard 0.0.0.0:123
21 окт 11:10:23 ntpd[51]: Ожидает подключения на 1 lo 127.0.0.1:123
21 окт 11:10:23 ntpd[51]: Прослушивание на маршрутизирующем сокете на fd #18 для обновлений интерфейса
21 окт 11:10:23 ntpd[51]: mlockall(): Не удается выделить память
21 окт 11:10:23 ntpd[51]: start_kern_loop: ntp_loopfilter.c строка 1119: ntp_adjtime: операция не разрешена
21 окт 11:10:23 ntpd[51]: set_freq: ntp_loopfilter.c строка 1082: ntp_adjtime: операция не разрешена
21 окт 11:10:23 ntpd[51]: cap_set_proc() не удалось сбросить привилегии root: операция не разрешена

Что я пробовал до сих пор:

  1. Собрать ntpd без включенных возможностей — он запускается правильно, но все равно возникают те же проблемы с разрешениями syscall ntp_adjtime.
  2. Запускать systemd-nspawn с --private-users=0 и без --private-users вообще.
  3. Экспериментировать с возможностями для самого systemd-nspawn (в основном CAP_SYS_TIME и CAP_NET_BIND_SERVICE).
  4. Экспериментировать с возможностями для ntpd внутри контейнера.

Все это не дало положительных результатов, и я сомневаюсь, что я упустил. Любые идеи будут очень полезны.

Ух ты, удивительно, что на это не ответили за 7 лет.

Я использовал флаг --capability из командной строки для chronyd, который необходим для samba-ad-dc.service на контроллере домена, который я настраиваю внутри системного контейнера Debian 12.

Пример:

#!/bin/sh
CONTAINER_PATH='/var/lib/machines/domaincontroller'
CHRONYD_REQUIREMENT='CAP_SYS_TIME'

sudo systemd-nspawn -b \
    --capability="${CHRONYD_REQUIREMENT}" \
    --directory="${CONTAINER_PATH}" &

Ответ или решение

Ваша цель заключается в развертывании демона NTP (Network Time Protocol) в контейнере, управляемом systemd-nspawn на основе системы Linux. Однако, у вас возникают проблемы с запуском ntpd, которые связаны с ограничениями прав доступа и системой управления временем. Давайте подробно рассмотрим ваши проблемы и возможные решения.

Проблемы с запуском ntpd в контейнере

  1. Ошибка cap_set_proc(): Эта ошибка указывает на то, что ntpd не может изменить свои права доступа, что часто связано с отсутствием необходимых привилегий, когда вы работаете в контейнере.

  2. RLIMIT_MEMLOCK: Ограничение, предписывающее NTP блокировать определенное количество памяти, также может вызвать проблемы, особенно если контейнер не имеет достаточно прав.

  3. mlockall() и ntp_adjtime: Эти функции требуют привилегий, которые по умолчанию ограничены в контейнеризованной среде, поскольку они взаимодействуют с системным временем и могут влиять на глобальные настройки.

Решения для запуска ntpd в systemd-nspawn

Для успешного запуска ntpd в container с использованием systemd-nspawn, вам следует выполнить следующие шаги:

  1. Настройка прав доступа:

    • Вы можете попробовать запустить контейнер с дополнительными возможностями. Запустите контейнер с флагами --capability для предоставления необходимых прав, например:
      sudo systemd-nspawn -b --capability=CAP_SYS_TIME --capability=CAP_NET_BIND_SERVICE --directory=/var/lib/machines/your-container
  2. Изменение конфигурации контейнера:

    • Убедитесь, что файл конфигурации вашего контейнера (/etc/systemd/nspawn/your-container.nspawn) включает необходимые параметры. Вам может потребоваться добавить:
      [Exec]
      Capability=CAP_SYS_TIME
      Capability=CAP_NET_BIND_SERVICE
  3. Проверка системных ограничений:

    • Убедитесь, что настройки ограничений на уровне ядра (например, с помощью ulimit) разрешают необходимые операции, такие как mlockall.
  4. Обновление NTP:

    • Рассмотрите возможность использования более новой версии NTP или альтернатива, например, chronyd, которая может быть более совместима с контейнером. Chrony также позволяет настроить необходимые права доступа аналогичным образом.
  5. Запуск контейнера с дополнительными флагами:

    • Попробуйте запускать ваш контейнер с параметрами --private-users=0, чтобы разрешить взаимодействие с системным пользователем. Это может помочь если контейнер не может корректно идентифицировать пользователя.
  6. Проверка логов:

    • Обратите внимание на логи NTP для диагностики. Важно понимать, какие именно ошибки возникают, и проверяйте, появляется ли какая-либо информация, указывающая на причины отказа в работе.

Заключение

Запуск NTP внутри контейнера systemd-nspawn может быть сложной задачей, особенно из-за ограничений безопасности и привилегий. Однако, соблюдая вышеуказанные шаги, вы сможете минимизировать большинство проблем и обеспечить корректную работу службы NTP. Pokupite Хотя это может потребовать некоторого экспериментирования, успех в этой области может привести к более эффективному и надежному управлению временными параметрами в вашей серверной инфраструктуре.

Если вопросов больше не осталось, желаю удачи в ваших начинаниях с контейнерами и службой NTP!

Оцените материал
Добавить комментарий

Капча загружается...