rsyslog.service не найден Ansible во время preseed late_command

Я постоянно обнаруживаю, что некоторые вещи «просто не работают», когда preseed/late_commandв предустановленном файле Ubuntu Bionic. (То же самое относится к автоматической установке для Ubuntu Focal.) В этом конкретном случае я пытаюсь запустить роль Ansible (в частности, Canonical Ubuntu 18.04 LTS для Ansible STIG) против цели как late_command:

      d-i    preseed/late_command    string \
    in-target /usr/bin/curl -fsSL -o /opt/stig.zip {{ di_preseed.stig_role_url }}; \
    in-target /usr/bin/unzip -qq /opt/stig.zip -d /opt; \
    in-target /usr/bin/unzip -qq /opt/ubuntu1804STIG-ansible.zip -d /opt; \
    in-target /bin/sh -c -- 'cd /opt && ANSIBLE_LOG_PATH=/var/log/ansible.log /bin/sh enforce.sh'

Здесь enforce.shэто просто обертка.

Эта установка из ISO на Virtualbox завершается с ошибкой:

      Failed to run preseeded command ... <command> finished with exit code 2

Я все еще могу войти в ящик как ubuntuи стать root. Вижу, что Ansible успешно установился (изначально указано в pkgsel/include).

тогда я открываю /var/log/installer/syslogна цель и найти, что ansible-playbookне удалось, когда он не смог найти:

Это сбивает с толку, так как наверняка включено и активно после установки, что я могу подтвердить с помощью systemctl (status|is-active) rsyslog.

Итак, что я пытаюсь понять здесь:

  • Почему Ansible не может найти rsyslog.serviceво время установки, даже если он включен?
  • Какие факторы отличаются в установке, что приводит к тому, что вещи обычно ломаются или недоступны?
  • Было бы лучше запустить это как скрипт при загрузке под init.rc, а затем последнюю строку он удалит после завершения?

Связано: некоторые команды (например, modprobe или usermod) не работают как поздние команды в автоустановке Ubuntu.

Источник

1 ответ

Главное помнить, что in-targetкоманды выполняются в chrootОкружающая среда. Они не выполняются в полностью загруженной системе, где запущены и доступны основные процессы, такие как systemd.

Тестирование

Я настроил playbook на основе задач STIG на скриншоте и запустил его из preseed. Я видел те же результаты, что и вы.

  • Плейбук
      ---
- hosts: localhost
  gather_facts: no
  connection: local

  tasks:
    - name: check if rsyslog.service is installed
      shell: ! systemctl list-unit-files | grep "^rsyslog.service[ \t]\+"
      changed_when: False
      check_mode: no
      register: result
      failed_when: result.rc > 1

    - name: stigrule_219160_rsyslog_enable
      service:
        name: rsyslog.service
        enabled: "yes"
  • Частичный preseed-файл
      d-i pkgsel/include string ansible
d-i preseed/late_command string \
    wget -P /target/ http://REDACTED/my_playbook.yml ; \
    in-target ansible-playbook -i /dev/null -b -v /my_playbook.yml

Доступные бионические пакеты 2.5.1и эта версия сервисного модуля , по- видимому, выполняется systemctl show rsyslog.service. Это не работает в среде chroot. Чтобы продемонстрировать, если я открою терминал в среде установщика и запущу in-target systemctl show rsyslog.serviceто файл журнала покажет вывод

      in-target: Running in chroot, ignoring request: show

Возможное исправление

Я нашел патч в Ansible 2.3, который решает проблему , заключающуюся в том, что systemctl игнорирует команды при работе в среде chroot. Это было применено только к модулю, но не к модулю. Я обновил свою пьесу, и она успешно работает.

      ---
- hosts: localhost
  gather_facts: no
  connection: local

  tasks:
    - name: check if rsyslog.service is installed
      shell: ! systemctl list-unit-files | grep "^rsyslog.service[ \t]\+"
      changed_when: False
      check_mode: no
      register: result
      failed_when: result.rc > 1

    - name: stigrule_219160_rsyslog_enable fixed
      systemd:
        name: rsyslog.service
        enabled: "yes"

Таким образом, вы можете продвинуться дальше, изменив задачу (задачи) STIG, не используя serviceмодуль для использования systemdмодуль.

Источник
Другие вопросы по тегам