Neprivilegiat este o măsurătoare, nu o setare

Restaurarea unui container pe Proxmox este același apel de API cu crearea unuia. Se face un POST către punctul final pentru containere de pe un nod, i se dă arhiva și se adaugă indicatorul care transformă crearea într-o restaurare. Calea pentru mașina virtuală nici măcar nu are acel indicator: acolo arhiva însăși este restaurarea. Simetria aceea este comodă și ascunde o capcană, pentru că unul dintre câmpurile din acel apel descrie o proprietate de securitate care are deja o valoare în interiorul arhivei.

Dacă trimiteți valoarea sigură, s-ar putea să stricați containerul. Dacă lăsați câmpul afară, s-ar putea să puneți un container privilegiat într-o flotă care nu ar trebui să aibă niciunul. Singura mișcare corectă este să citiți mai întâi arhiva și apoi să acționați după ce spune ea.

Două puncte finale care seamănă între ele

Calea pentru mașina virtuală și cea pentru container diferă în mai multe locuri decât sugerează numele:

Două dintre acele rânduri sunt ușor de greșit într-un fel care produce o eroare derutantă. Proxmox numește arhiva unui container șablon de sistem de operare, pentru că același parametru le acceptă pe amândouă, iar la o mașină virtuală prezența lui archive este ea însăși restaurarea, așa că nu există un indicator separat. Iar images și rootdir sunt două tipuri diferite de conținut: o stocare poate să îl ofere pe unul fără celălalt, așa că a cere images peste tot respinge o stocare de containere perfect bună, în timp ce a nu verifica deloc îi întinde clientului o propoziție despre directoare de containere care nu înseamnă nimic pentru el.

Care dintre cele două feluri este acesta se stabilește o singură dată. Este citit din numele fișierului de arhivă în momentul în care arhiva este listată, este păstrat odată cu punctul de restaurare și este trimis împreună cu instrucțiunea; agentul își alege punctul final după acel cuvânt și nu are nicio cale de rezervă. Trebuie să funcționeze în acest sens, pentru că un 404 de la Proxmox nu face deosebirea între un invitat de celălalt fel și un invitat care nu mai există. Încercarea celuilalt punct final după un 404 ar lăsa o mașină virtuală ștearsă să fie adresată drept container, iar pe un cluster unde acel număr a fost între timp reatribuit se atinge invitatul greșit.

Un indicator nu este trimis niciodată, iar el se numește force. Aceasta este restaurarea aditivă: o mașină apare lângă original, iar originalul continuă să ruleze. force este indicatorul cu care Proxmox suprascrie un invitat existent, există pe amândouă punctele finale și aparține celuilalt fel de restaurare, care are propriul lui mesaj, propria lui permisiune și o confirmare tastată. A-l lăsa definitiv în afara acestei căi de cod este mai ieftin decât a ține minte să nu îl setați.

Un indicator este trimis întotdeauna, iar el se numește unique. Fără el, invitatul restaurat moștenește adresele hardware ale plăcilor de rețea originale, iar două mașini care răspund la aceeași adresă înseamnă o întrerupere pe chiar mașina pe care aveați grijă să nu o atingeți.

Trei refuzuri înainte să se scrie ceva

Fiecare verificare prealabilă există pentru că alternativa este un citat de la Proxmox pe baza căruia un client nu poate face nimic. Arhiva trebuie să mai fie acolo, pentru că platforma o alege dintr-un index care este prin construcție o observație despre trecut. Numărul-țintă trebuie să fie liber, iar liber trebuie să însemne liber pe hipervizor și nu liber în propria noastră evidență: platforma alocă în interiorul intervalului pe care îl administrează, așa că un invitat creat manual de cineva este cât se poate de real și cu totul absent din orice evidență ținem noi. Iar stocarea țintă trebuie să accepte tipul de conținut potrivit.

Pentru un container există o a patra, iar despre ea este acest articol.

Trei lucruri de făcut cu o arhivă privilegiată, iar două sunt greșite în tăcere

Containerele neprivilegiate sunt valoarea implicită sigură, iar platforma nu are cum să exprime altceva. Așa că, atunci când o arhivă se dovedește a ține un container privilegiat, agentul are exact trei opțiuni.

Prima este să trimită totuși indicatorul de neprivilegiat. Proxmox aplică atunci o mapare de identitate peste sistemul de fișiere restaurat; propria lui descriere a parametrului spune că acel câmp nu ar trebui modificat manual. Restaurarea reușește, sarcina raportează că totul este în regulă, iar containerul nu funcționează.

A doua este să omită câmpul. Proxmox ia atunci valoarea din arhivă, iar un container privilegiat intră în flotă: unul care împarte nucleul gazdei cu privilegii de root, adică exact lucrul pe care politica există ca să îl prevină.

A treia este să refuze, cu o propoziție care spune ce se află în arhivă. Asta se și întâmplă, și se întâmplă înainte să se scrie ceva. Nu se trimite deloc o cerere de creare a containerului.

Citirea configurației care se află în interiorul arhivei

Măsurătoarea este un singur apel către punctul final de extragere pentru arhivă. Trei detalii merită știute.

Răspunsul este text și nu JSON. Este fișierul de configurare al containerului, o cheie și o valoare pe linie, exact așa cum stă pe disc, așa că are nevoie de propriul lui analizor mic, alături de cel care se ocupă de JSON-ul API-ului.

Iar absența cheii înseamnă opusul a ceea ce înseamnă de obicei absența. Proxmox scrie linia de neprivilegiat numai atunci când este adevărată. O configurație fără ea descrie un container privilegiat. Orice cititor care tratează „negăsit” drept „necunoscut, probabil în regulă” lasă să treacă exact cazul pentru care a fost construită verificarea, așa că această comparație este generoasă cu ce acceptă drept adevărat și refuză tot restul.

Dacă configurația nu poate fi citită deloc, restaurarea este refuzată la fel, iar citatul de la Proxmox călătorește înapoi odată cu ea. Acela este de obicei un mesaj despre permisiuni, pentru că punctul final de extragere cere drepturi de copiere de siguranță pe invitat și drepturi de alocare pe stocarea de copii de siguranță. Eșecul închis are aici un cost real: un jeton de API căruia îi lipsește o singură permisiune nu poate restaura un container, iar motivul este o verificare și nu o limitare. Rămâne totuși partea corectă în care să eșuați, pentru că întrebarea deschisă din spatele ei are două răspunsuri greșite în tăcere.

Aceeași citire răspunde la o a doua întrebare

Configurația din interiorul arhivei spune și ce puncte de montare au făcut parte din ea, iar regulile Proxmox de acolo nu sunt cele la care se așteaptă lumea:

Al treilea rând este cel periculos. Pe discul unei mașini virtuale, excluderea este excepția, iar includerea este valoarea implicită; pe un punct de montare de container este exact invers. A inversa asta produce un tabel de acoperire care spune „în copia de siguranță” despre cea mai obișnuită configurație existentă, ceea ce este mai rău decât să nu existe niciun tabel, pentru că este o promisiune.

Secțiunile de instantanee din configurație sunt sărite. Altfel, un container cu cinci instantanee ar aduce cinci versiuni ale aceluiași sistem de fișiere rădăcină, fiecare dintr-un moment arbitrar.

Un singur apel servește ambele întrebări, și nu două, pentru că două apeluri ar putea descrie două arhive diferite. Iar verdictul este calculat pe platformă, nu de agent: agentul raportează liniile așa cum le-a găsit, iar nu există niciun câmp în care ar putea afirma o acoperire completă, chiar dacă ar vrea. Ceva demonstrabil în afara copiei de siguranță bate ceva nemăsurat, așa că un container cu un bind mount și o linie ilizibilă este parțial și nu necunoscut, iar linia ilizibilă își păstrează propriul cuvânt în tabel.

Există un indicator care spune dacă a fost citită configurația, iar el nu este decor. Un agent care nu a putut să o citească întoarce o listă goală, iar o listă goală nu se poate deosebi de un container fără puncte de montare, cu deosebirea că al doilea nu există.

Când nimeni nu poate spune ce s-a întâmplat

O restaurare care pornește și apoi își pierde răspunsul, pentru că agentul a repornit sau conexiunea a căzut, nu are voie să fie ghicită. Există trei surse de dovezi: indexul de arhive, mașina care trebuia să apară și starea sarcinii Proxmox. Numai a treia poate stabili un eșec; celelalte două pot doar confirma o reușită, pentru că o arhivă lipsă și o mașină lipsă se potrivesc amândouă la fel de bine cu o restaurare care încă rulează.

Acest raționament are loc pe platformă. Căutarea sarcinii făcută de agent nu face decât să aducă înapoi citatul de la Proxmox și nu trage nicio concluzie proprie, pentru că a decide ce anume înseamnă împreună cele trei surse cere ca rularea și intenția din care a pornit să stea una lângă alta, iar numai platforma le are pe amândouă.

Nimic nu se reîncearcă la nesfârșit. Există un contor cu un plafon de opt încercări, iar la intervalul implicit de șase ore asta iese cam la două zile. Încercările în care sarcina era demonstrabil încă în desfășurare nu se scad din el, pentru că o copie de siguranță mare pe o rețea lentă are voie să dureze o noapte. Când contorul se epuizează, rularea devine necunoscută și niciodată eșuată. Eșuată ar fi o afirmație pe care nu a verificat-o nimeni, iar încheiată ar susține existența unei arhive pe care nu a văzut-o nimeni.

Ce am nota

1. 01Nu trimiteți o valoare pentru o proprietate care există deja în intrare. Citiți-o, apoi ori o confirmați, ori refuzați.
2. 02Aflați ce înseamnă o cheie absentă înainte să scrieți analizorul. Aici înseamnă valoarea nesigură, adică opusul convenției obișnuite.
3. 03Eșuați închis atunci când măsurătoarea nu este disponibilă și spuneți cu voce tare cât costă asta, pentru că cineva se va lovi de ea.
4. 04Faceți ca o singură citire să răspundă la fiecare întrebare la care poate. Două apeluri pot descrie două stări diferite.
5. 05Puneți judecata acolo unde se află contextul. Un observator care nu poate exprima un verdict nu îl poate greși.
6. 06Dați unei reîncercări epuizate propriul ei cuvânt final. Necunoscut este sincer; eșuat și încheiat sunt amândouă afirmații pe care nu le-a făcut nimeni.

Pentru claritate în privința a ceea ce este asta: copiile de siguranță ale clienților stau în spatele unui indicator de lansare care este oprit implicit, așa că nimic din toate acestea nu se poate cumpăra astăzi. Iar limita importantă a dovezilor: nu s-a rulat nicio copiere de siguranță și nicio restaurare reală pe un hipervizor viu. Comportamentul parametrilor de mai sus a fost citit din sursa și din documentația proprii ale Proxmox, iar codul a fost exersat pe un server înlocuitor care răspunde la aceleași puncte finale. Nici apelul de extragere nu a fost încercat pe o arhivă aflată pe un server dedicat de copii de siguranță, ci numai pe o stocare bazată pe fișiere.

Din lucrul la copiile de siguranță de la Provibr. De ce o arhivă pe care nu a restaurat-o nimeni nu este încă o copie de siguranță se află în o copie nerestaurată nu este o copie de siguranță, ce garantează de fapt diferitele moduri de copiere se află în ce garantează modurile vzdump din Proxmox, iar de ce reinstalarea unui container înseamnă o distrugere și o reconstruire se află în reinstalarea unui container este o înlocuire.