înregistrare Logare
Puncte:0
Brad Solomon avatar Ubuntu

rsyslog.service nu a fost găsit de Ansible în timpul preseed late_command

drapel pt
Brad Solomon

Constat continuu că anumite lucruri „pur și simplu nu funcționează” atunci când sunt executate ca preseed/the_command într-un fișier prestabilit Ubuntu Bionic. (Același lucru este valabil și pentru autoinstalarea pentru Ubuntu Focal.) În acest caz particular, încerc să rulez un rol Ansible (în special, Canonical Ubuntu 18.04 LTS pentru Ansible STIG) împotriva țintei ca a late_command:

șir de comandă d-i preseed/late_command \
    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'

Aici impune.sh este doar un înveliș în jur ansible-playbook.

Această instalare din ISO pe Virtualbox eșuează cu:

Nu s-a putut rula comanda preseedată... <comandă> s-a terminat cu codul de ieșire 2

Încă mă pot conecta la casetă ca ubuntu și devin rădăcină. Văd că Ansible a fost instalat cu succes (este specificat inițial în pkgsel/include).

apoi deschid /var/log/installer/syslog pe țintă și găsiți că ansible-playbook a eșuat când nu a putut găsi rsyslog.service:

introduceți descrierea imaginii aici

Acest lucru este confuz ca rsyslog.service este cu siguranță activat și activ după instalare, lucru pe care îl pot confirma systemctl (starea | este activ) rsyslog.

Deci ceea ce vreau să înțeleg aici este:

  • De ce Ansible nu poate găsi rsyslog.service în timpul instalării, chiar dacă pare a fi activat?
  • Ce factori sunt diferiți în ceea ce privește instalarea care duc la faptul că lucrurile par să se rupă de obicei sau să nu fie disponibile?
  • Aș fi mai bine să rulez asta ca un script onboot sub init.rc, apoi ultima linie se elimină după terminare?

Legate de: Anumite comenzi (de exemplu, modprobe sau usermod) eșuează ca comenzi tardive în autoinstalarea Ubuntu

132
1 + 0
Puncte:1
Andrew Lowther avatar Ubuntu
drapel jp
Andrew Lowther

Lucrul cheie de reținut este că în țintă comenzile sunt executate în a chroot mediu inconjurator. Ele nu sunt executate într-un sistem complet pornit în care procesele de bază precum systemd rulează și sunt disponibile.

Testare

Am configurat un playbook bazat pe sarcinile STIG din captură de ecran și l-am rulat din preseed. Am vazut aceleasi rezultate ca si tine.

  • Cartea de joc
---
- gazde: localhost
  gather_facts: nu
  conexiune: locală

  sarcini:
    - nume: verificați dacă rsyslog.service este instalat
      coajă:! systemctl list-unit-files | grep „^rsyslog.service[ \t]\+”
      changed_when: Fals
      check_mode: nu
      înregistrare: rezultat
      failed_when: rezultat.rc > 1

    - nume: stigrule_219160_rsyslog_enable
      serviciu:
        nume: rsyslog.service
        activat: "da"
  • Fișier parțial preseed
d-i pkgsel/include string ansible
șir de comandă d-i preseed/late_command \
    wget -P /target/ http://REDACTED/my_playbook.yml ; \
    in-target ansible-playbook -i /dev/null -b -v /my_playbook.yml

Pachete bionice ansible 2.5.1 și acea versiune a modulului de serviciu pare să execute systemctl arată rsyslog.service. Acest lucru nu funcționează într-un mediu chroot. Pentru a demonstra, dacă deschid un terminal în mediul de instalare și rulez in-target systemctl arată rsyslog.service apoi fișierul jurnal va afișa rezultatul

in-target: rulează în chroot, ignorând cererea: show

Remediere potențială

Am găsit un patch în Ansible 2.3 care abordează problema că systemctl va ignora comenzile atunci când rulează într-un mediu chroot. Acest lucru a fost aplicat doar la systemd modul totuși și nu serviciu modul. Mi-am actualizat playbook-ul și acesta rulează cu succes.

---
- gazde: localhost
  gather_facts: nu
  conexiune: locală

  sarcini:
    - nume: verificați dacă rsyslog.service este instalat
      coajă:! systemctl list-unit-files | grep „^rsyslog.service[ \t]\+”
      changed_when: Fals
      check_mode: nu
      înregistrare: rezultat
      failed_when: rezultat.rc > 1

    - nume: stigrule_219160_rsyslog_enable fix
      systemd:
        nume: rsyslog.service
        activat: "da"

Prin urmare, este posibil să puteți progresa mai mult modificând sarcinile STIG din utilizarea serviciu modul pentru a utiliza systemd modul.

0 + 4
Brad Solomon avatar
drapel pt
Brad Solomon
Mulțumesc pentru acest răspuns util. Am avut o descoperire când am descoperit astăzi că `ctrl+z` vă va introduce într-un shell bash ca rădăcină în mediul de instalare cu /cdrom și /target pe sistemul de fișiere (primul fiind ISO montat). Acest lucru a deschis o mulțime de depanare mai ușoară, inclusiv descoperirea, așa cum menționați aici, că majoritatea systemctl nu este disponibilă într-un mediu chroot. Deci, aceasta nu este o problemă ansible, în sine, și faptul că curtin in-target este un chroot /target sub capotă pare să fie cauza de bază a majorității problemelor de comportament pe care le-am întâlnit.
0
Răspunde
Brad Solomon avatar
drapel pt
Brad Solomon
FWIW, probabil că vom alege să folosim ansible dintr-un nod de control separat prin ssh (așa cum ar trebui să se facă, aș spune) după ce procesul de instalare s-a încheiat pentru un grup de noduri și acestea sunt accesibile prin ssh, unde chroot este în afara imaginii.
0
Răspunde
Brad Solomon avatar
drapel pt
Brad Solomon
Datorită faptului că am putut intra în shell-ul de instalare, acum am reușit să rezolv acesta: https://askubuntu.com/a/1355980/919528. S-ar putea să găsești asta interesant
0
Răspunde
Andrew Lowther avatar
drapel jp
Andrew Lowther
@BradSolomon Cred că rularea ansible dintr-un nod de control va fi mai puțin problematică. Ar trebui să existe o opțiune de deschidere a unui shell din meniul drop-down „Ajutor” din interfața de utilizare a programului de instalare. De obicei folosesc doar `Alt-F2`. A se vedea https://askubuntu.com/a/1257186/376778. Puteți chiar și SSH în mediul de instalare dacă setați (sau capturați) parola utilizatorului „instalator” (YMMV, în funcție de versiunea subicută): https://askubuntu.com/a/1322129/376778
1
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.