sudo, &, -b sau --daemon: cum trimitem un client OpenVPN în fundal
Un ampersand eliberează terminalul, nu autentificarea. Comparați sudo -b, --daemon și o instanță de serviciu după cine deține procesul și cine răspunde la solicitări.
În expresia „rulează-l în fundal” se ascund două întrebări. Prima este dacă acest utilizator poate porni deloc un proces privilegiat; a doua este dacă sesiunea poate continua fără ca cineva să tasteze într-un terminal. Un ampersand de shell nu răspunde la niciuna, iar un script care păstrează o parolă sudo într-o variabilă răspunde prost la prima și o lasă neatinsă pe a doua. Separați-le și opțiunile devin ușor de comparat.
Comparați cei trei candidați după proprietate, nu după comoditate.
Trei moduri de a părăsi terminalul, trei proprietari diferiți
Adăugarea unui ampersand la o comandă cere shell-ului să o ruleze ca sarcină de fundal, iar sarcina aparține în continuare acelui shell. sudo poate întreba înainte ca programul să înceapă, iar OpenVPN poate întreba apoi o frază de acces a cheii sau o autentificare. Trecerea în fundal a unei comenzi care așteaptă intrare produce un proces care așteaptă un terminal pe care nimeni nu îl urmărește. Terminalul este eliberat; interacțiunea nu.
Este opțiunea cea mai ieftină și cea care eșuează cel mai confuz, pentru că solicitarea apare într-un loc pe care operatorul l-a părăsit deja.
sudo -b nu este un gestionar de acreditări
sudo -b rulează comanda în fundal din perspectiva sudo însuși, ceea ce sună ca funcția lipsă și nu este. Potrivit manualului sudo, comenzile interactive se comportă de obicei prost în acel mod, iar controlul sarcinilor al shell-ului nu poate administra procesele pe care le creează. Mută procesul fără a-i da o modalitate de a răspunde la întrebări. Nimic din el nu furnizează o frază de acces pentru cheia privată sau o autentificare la poartă.
Dacă conexiunea are nevoie de interacțiune, soluția este un aranjament de autentificare neinteractiv acceptat, nu o altă cale de a lansa aceeași solicitare.
--daemon schimbă programul, nu autentificarea
--daemon cere OpenVPN însuși să se desprindă după inițializare. Manualul versiunii 2.6 notează că redirecționarea syslog are loc la analizarea opțiunii, deși desprinderea are loc mai târziu, așa că mesajele pot înceta să apară în terminal mai devreme decât se aștepta. Tăcerea după acel punct nu dovedește nimic despre tunel. Adăugați un --log sau --log-append explicit pentru ca ieșirea să ajungă într-un loc pe care îl puteți citi.
Modul daemon elimină și consola definitiv. O cheie privată protejată are nevoie în acel mod de askpass , iar acreditările introduse de la consolă combinate cu opțiuni de cache pot lăsa o reautentificare ulterioară fără loc unde să întrebe. Verificați modelul de autentificare față de versiunea instalată înainte de a presupune că o pornire în fundal va supraviețui primei reînnoiri a cheii.
Ce oferă validarea sudo și ce nu oferă
sudo -v validează sau reîmprospătează acreditarea locală din cache, autentificând dacă politica o cere. Nu pornește OpenVPN, nu se autentifică la poartă și nu garantează că o comandă ulterioară din script este permisă. sudo -n înseamnă opusul: nu întreba, eșua. Asta face explicit un eșec local de autorizare, ceea ce este util, și nu spune nimic despre ce va cere OpenVPN mai târziu.
Niciuna dintre opțiuni nu este un motiv pentru a acorda tuturor comenzi fără parolă sau pentru a trimite o parolă de administrator într-un script.
Preferați un proprietar care poate fi observat
Pentru un tunel deținut de mașină, folosiți instanța de serviciu acceptată de distribuție. Un astfel de proprietar oferă pornire, oprire, stare și jurnale, și supraviețuiește încheierii sesiunii dumneavoastră. Asamblarea fundalului shell-ului, a demonizării și a unei bucle de repornire unul în jurul celuilalt creează trei proprietari pentru un singur tunel și niciun răspuns clar despre care rulează.
Orice ați alege, verificați resursa pentru care există tunelul. O cerere de pornire reușită este un eveniment de proces, nu dovada unei conexiuni funcționale.