sudo, &, -b of --daemon: hoe om 'n OpenVPN-kliënt in die agtergrond te laat loop
'n Ampersand bevry die terminaal, nie die aanmelding nie. Vergelyk sudo -b, --daemon en 'n diensinstansie volgens wie die proses besit en wie vrae beantwoord.
Twee vrae skuil in die frase 'laat dit in die agtergrond loop'. Die eerste is of hierdie gebruiker hoegenaamd 'n bevoorregte proses mag begin; die tweede is of die sessie kan voortduur sonder dat iemand in 'n terminaal tik. 'n Skulp-ampersand beantwoord nie een van die twee nie, en 'n skrip wat 'n sudo-wagwoord in 'n veranderlike stoor, beantwoord die eerste sleg terwyl dit die tweede onaangeraak laat. Skei hulle en die opsies word maklik om te vergelyk.
Vergelyk die drie kandidate op eienaarskap, nie op gerief nie.
Drie maniere om die terminaal te verlaat, drie verskillende eienaars
'n Ampersand agter 'n opdrag vra die skulp om dit as 'n agtergrondtaak te laat loop, en die taak behoort steeds aan daardie skulp. sudo kan vra voordat die program eers begin, en OpenVPN kan daarna vra vir 'n sleutelfrase of 'n aanmelding. Om 'n opdrag in die agtergrond te plaas wat insette verwag, lewer 'n proses wat op 'n terminaal wag waarna niemand kyk nie. Die terminaal word bevry; die interaksie nie.
Dit is die goedkoopste opsie en die een wat die verwarrendste misluk, want die vrae verskyn op 'n plek wat die operateur al verlaat het.
sudo -b is nie 'n bestuurder van geloofsbriewe nie
sudo -b laat die opdrag in die agtergrond loop vanuit sudo se eie perspektief, wat klink soos die ontbrekende funksie en dit nie is nie. Volgens die sudo-handleiding werk interaktiewe opdragte oor die algemeen verkeerd in daardie modus, en skulp-taakbeheer kan nie die prosesse bestuur wat dit skep nie. Dit skuif die proses sonder om dit 'n manier te gee om vrae te beantwoord. Niks daaraan verskaf 'n privaatsleutelfrase of 'n poortaanmelding nie.
As die verbinding interaksie nodig het, is die oplossing 'n ondersteunde nie-interaktiewe verifikasiereëling, nie 'n ander manier om dieselfde vrae te begin nie.
--daemon verander die program, nie die aanmelding nie
--daemon vra OpenVPN self om ná inisialisering los te maak. Die 2.6-handleiding merk op dat syslog-herleiding plaasvind wanneer die opsie ontleed word, selfs al gebeur die losmaking later, so boodskappe kan vroeër as verwag uit die terminaal verdwyn. Stilte ná daardie punt bewys niks oor die tonnel nie. Voeg 'n eksplisiete --log of --log-append sodat die uitset beland waar jy dit kan lees.
Daemon-modus verwyder ook die konsole permanent. 'n Beskermde privaatsleutel benodig askpass in daardie modus, en konsol-ingevoerde geloofsbriewe gekombineer met kas-opsies kan 'n latere herautentisering laat met nêrens om te vra nie. Kontroleer die verifikasiemodel teen die geïnstalleerde weergawe voordat jy aanneem 'n agtergrondbegin sal sy eerste sleutelhernuwing oorleef.
Wat sudo-validering koop en nie koop nie
sudo -v valideer of verfris die gekasde plaaslike geloofsbrief en verifieer as die beleid dit vereis. Dit begin nie OpenVPN nie, verifieer nie by die poort nie, en waarborg nie dat 'n latere opdrag in die skrip toegelaat word nie. sudo -n beteken die teenoorgestelde: moenie vra nie, misluk eerder. Dit maak 'n plaaslike magtigingsfout eksplisiet, wat nuttig is, en dit sê niks oor wat OpenVPN later sal vra nie.
Nie een van die opsies is 'n rede om omvattende wagwoordlose opdragte toe te staan of om 'n administrateurwagwoord in 'n skrip in te voer nie.
Verkies 'n eienaar wat waargeneem kan word
Vir 'n masjienbesitte tonnel, gebruik die diensinstansie wat die verspreiding ondersteun. Daardie eienaar bied begin, stop, status en logboeke, en dit oorleef die einde van jou sessie. Om skulp-agtergrondplasing, daemonisering en 'n herbegin-lus om mekaar te bou, skep drie eienaars vir een tonnel en geen duidelike antwoord oor watter een loop nie.
Wat jy ook al kies, verifieer die hulpbron waarvoor die tonnel bestaan. 'n Suksesvolle beginversoek is 'n prosesgebeurtenis, nie bewys van 'n werkende verbinding nie.