Puncte:0

Nu se pot rula comenzi systemctl pe gazdă din containerul care funcționa până la Ubuntu 16.04

drapel ve

Când sistemul de operare gazdă este Ubuntu 16.04 sau RHEL 7.x, următoarea comandă funcționează, ajutându-ne să rulăm comenzi systemctl pe gazdă din containerul docker:

# nsenter --mount=/hostroot/proc/1/ns/mnt -- systemctl start dummy.service

Dar în noile sisteme de operare gazdă, Ubuntu 20.04 și RHEL 8.x, acest lucru nu funcționează și primim următoarea eroare:

# nsenter --mount=/hostroot/proc/1/ns/mnt -- systemctl start dummy.service
Conectarea la magistrală eșuată: nu există date disponibile

Am atașat un exemplu minimalist și comenzi pentru a rula și a reproduce problema:

Exemplu de serviciu pe care am vrut să-l pornesc pe gazdă, din container:

# cat /etc/systemd/system/dummy.service
[Unitate]
Descriere = serviciu fals
[Serviciu]
ExecStart=/usr/bin/sleep infinity

Dockerfile al containerului meu:

# Cat Dockerfile
DIN ubuntu:20.04
ENV TZ=UTC
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN apt update -y --fix-missing
RUN apt install -y util-linux
SEMNAL DE OPRIRE SIGRTMIN+3
CMD [ "/bin/bash" ]

Construiți imaginea:

# docker build -t trial .

Ștergeți orice recipiente vechi:

# docker rm -f trial

Rulați imaginea:

# docker run -it -d --net=host --privileged -v /:/hostroot -v /sys/fs/cgroup:/sys/fs/cgroup:ro --name trial trial

Reproduce problema:

# docker exec -it trial bash
# nsenter --mount=/hostroot/proc/1/ns/mnt -- systemctl start dummy.service
Conectarea la magistrală eșuată: nu există date disponibile

Aș dori să știu dacă există opțiuni suplimentare sau orice comandă de rulare docker care trebuie modificată pentru a funcționa.

Puncte:0
drapel cn

M-am uitat la asta câteva ore bune, se pare că metoda sd_bus_start a fost modificat pentru a include verificări suplimentare. Nu am reușit să restrâng ce altceva caută, totuși am reușit să găsesc o soluție mai elegantă pentru a îndeplini aceeași sarcină folosind comenzi systemctl de la distanță în loc să montez toate directoarele de pe gazdă.

Sistem la distanțăctl

systemctl acceptă comenzi de la distanță prin intermediul --gazdă / -H steag. Utilizează ssh pentru a se conecta la gazda de la distanță, așa că va fi necesară o pereche de chei ssh. Deoarece controlăm gazda pe care ne aflăm, acest lucru este destul de simplu de configurat.

Comanda Docker (sau Kubernetes arg)

Iată comanda completă care poate fi utilizată, voi descompune fiecare parte mai jos. Ipotezele containerului sunt că are systemctl și ssh instalat, containerul rulează în rețeaua gazdă și că rădăcină directorul principal al contului este montat (puteți folosi o altă utilizare dacă doriți).

(ls ~/.ssh/id_rsa || ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa -q -N "") 
  && (grep -qxF $(cat ~/.ssh/id_rsa.pub) ~/.ssh/authorized_keys || echo $(cat ~/.ssh/id_rsa.pub) > ~/.ssh/authorized_keys)
  && (grep -qxF „StrictHostKeyChecking nu” ~/.ssh/config || echo „StrictHostKeyChecking nu” >> ~/.ssh/config)
  && (grep -qxF "UserKnownHostsFile /dev/null" ~/.ssh/config || echo "UserKnownHostsFile /dev/null" >> ~/.ssh/config)
  && systemctl -H [email protected] pornește nfs-server.service

Această comandă vede dacă ~/.ssh/id_rsa fișierul există, altfel creați unul.

(ls ~/.ssh/id_rsa || ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa -q -N "")

Acum adăugăm cheia noastră publică la cheile noastre autorizate dacă nu există deja în fișier.

(grep -qxF "$(cat ~/.ssh/id_rsa.pub)" ~/.ssh/authorized_keys || echo "$(cat ~/.ssh/id_rsa.pub)" > ~/.ssh/authorized_keys)

Acest lucru poate fi, probabil, mai sigur dacă îl puneți într-o secțiune din configurația ssh numai pentru 127.0.0.1, dar avem nevoie

(grep -qxF "StrictHostKeyChecking nu" ~/.ssh/config || echo "StrictHostKeyChecking nu" >> ~/.ssh/config) 
  && (grep -qxF "UserKnownHostsFile /dev/null" ~/.ssh/config || echo "UserKnownHostsFile /dev/null" >> ~/.ssh/config)

În sfârșit avem realitatea systemctl comanda. Observați -H [email protected].

systemctl -H [email protected] porniți nfs-server.service

Pentru securitate maximă, cel mai bine ar fi să setați mai întâi cheile și utilizatorii în afara containerelor (prin Ansible sau similar) și să permiteți numai systemctl -H comandă în interiorul containerului.

Aravindhan Krishnan avatar
drapel ve
Vă mulțumim că ați alocat timpul prețios cu asta.De asemenea, am ajuns la o inferență foarte asemănătoare (deși doar prin observare și nu prin citirea codului) că unele noi verificări suplimentare cauzează schimbarea comportamentului. De asemenea, am observat că în sistemele de operare anterioare, o astfel de execuție a comenzii a dus la o prăbușire. Probabil systemd-dev a remediat această problemă care provoacă anomalii de comportament utilizatorului final. Soluția sugerată de dvs. este aceeași pe care am primit-o și de la canonical. Mulțumiri

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.