sudo, &, -b vagy --daemon: hogyan tegyünk egy OpenVPN-klienst háttérbe

A „futtasd a háttérben” kifejezésben két kérdés rejlik. Az első, hogy ez a felhasználó egyáltalán indíthat-e jogosultságokkal rendelkező folyamatot; a második, hogy a munkamenet folytatódhat-e anélkül, hogy bárki gépelne egy terminálba. A shell-ampersand egyikre sem ad választ, és az a szkript, amely sudo-jelszót tárol egy változóban, rosszul válaszol az elsőre, a másodikat pedig érintetlenül hagyja. Válassza szét őket, és a lehetőségek könnyen összehasonlíthatók.

A három jelöltet a tulajdonjog, ne a kényelem szerint hasonlítsa össze.

Három mód a terminál elhagyására, három különböző tulajdonos

Ha egy parancs után ampersandot teszünk, a shell háttérfeladatként futtatja, és a feladat továbbra is ahhoz a shellhez tartozik. A sudo már azelőtt kérdezhet, hogy a program elindulna, és a OpenVPN utána kérdezhet egy kulcsmondatért vagy bejelentkezésért. Egy bemenetet váró parancs háttérbe küldése olyan folyamatot hoz létre, amely egy olyan terminálra vár, amelyet senki sem figyel. A terminál felszabadul; az interakció nem.

Ez a legolcsóbb lehetőség, és ez hibázik a legzavarosabban, mert a kérés olyan helyen jelenik meg, amelyet a kezelő már elhagyott.

A sudo -b nem hitelesítőadat-kezelő

sudo -b a sudo saját nézőpontjából futtatja a parancsot a háttérben, ami a hiányzó funkciónak hangzik, de nem az. A sudo kézikönyve szerint az interaktív parancsok általában rosszul viselkednek ebben a módban, és a shell feladatkezelése nem tudja kezelni az általa létrehozott folyamatokat. Áthelyezi a folyamatot, de nem ad neki módot a kérdések megválaszolására. Semmi sem biztosít benne privátkulcs-jelmondatot vagy átjáró-bejelentkezést.

Ha a kapcsolat interakciót igényel, a megoldás egy támogatott, nem interaktív hitelesítési elrendezés, nem pedig ugyanazon kérés másik indítási módja.

A --daemon a programot változtatja meg, nem a bejelentkezést

--daemon arra kéri magát az OpenVPN-t, hogy inicializálás után váljon le. A 2.6-os kézikönyv megjegyzi, hogy a syslog-átirányítás az opció feldolgozásakor történik, bár a leválás később következik be, így az üzenetek a vártnál korábban eltűnhetnek a terminálról. Az utána következő csend semmit sem bizonyít az alagútról. Adjon hozzá egy explicit --log vagy --log-append elemet, hogy a kimenet olyan helyre kerüljön, ahol el tudja olvasni.

A daemon mód véglegesen eltávolítja a konzolt is. Egy védett privát kulcs ebben a módban askpass igényel, és a konzolon megadott hitelesítő adatok a gyorsítótárazási beállításokkal együtt egy későbbi újrahitelesítést kérdezési hely nélkül hagyhatnak. Ellenőrizze a hitelesítési modellt a telepített verzióval szemben, mielőtt feltételezi, hogy egy háttérindítás túléli az első kulcsfrissítést.

Mit ad a sudo-érvényesítés és mit nem

sudo -v érvényesíti vagy frissíti a gyorsítótárazott helyi hitelesítő adatot, és hitelesít, ha a szabályzat megköveteli. Nem indítja el az OpenVPN-t, nem hitelesít az átjáró felé, és nem garantálja, hogy a szkript későbbi parancsa engedélyezett lesz. sudo -n az ellenkezőjét jelenti: ne kérdezz, hanem vallj kudarcot. Ez nyilvánvalóvá teszi a helyi engedélyezési hibát, ami hasznos, és semmit sem mond arról, mit fog kérni az OpenVPN később.

Egyik lehetőség sem ok arra, hogy mindenkinek jelszó nélküli parancsokat adjunk, vagy hogy rendszergazdai jelszót juttassunk egy szkriptbe.

Olyan tulajdonost részesítsen előnyben, amely megfigyelhető

Gép által birtokolt alagúthoz használja azt a szolgáltatáspéldányt, amelyet a disztribúció támogat. Az ilyen tulajdonos indítást, leállítást, állapotot és naplókat biztosít, és túléli a munkamenet végét. A shell háttérfuttatásának, a daemonizálásnak és az újraindítási huroknak egymás köré építése három tulajdonost hoz létre egy alagúthoz, és nincs világos válasz arra, melyik fut.

Bármit is választ, ellenőrizze az erőforrást, amelyért az alagút létezik. A sikeres indítási kérés folyamatesemény, nem egy működő kapcsolat bizonyítéka.