sudo, &, -b eller --daemon: korleis køyra ein OpenVPN-klient i bakgrunnen

Uttrykket «køyr det i bakgrunnen» skjuler to spørsmål. Det første er om denne brukaren i det heile kan starta ein privilegert prosess; det andre er om økta kan halda fram utan at nokon skriv i ein terminal. Eit skal-ampersand svarar på ingen av dei, og eit skript som lagrar eit sudo-passord i ein variabel, svarar dårleg på det første og lèt det andre vera urørt. Skil dei, og alternativa blir enkle å samanlikna.

Samanlikn dei tre kandidatane på eigarskap, ikkje på komfort.

Tre måtar å forlata terminalen på, tre ulike eigarar

Å leggja eit ampersand etter ein kommando ber skalet køyra han som ein bakgrunnsjobb, og jobben høyrer framleis til det skalet. sudo kan spørja før programmet i det heile startar, og OpenVPN kan etterpå spørja om ein nøkkelfrase eller ei innlogging. Å leggja ein kommando som ventar på inndata i bakgrunnen gjev ein prosess som ventar på ein terminal ingen ser på. Terminalen blir frigjord; samhandlinga ikkje.

Det er det billegaste alternativet og det som feilar mest forvirrande, fordi førespurnaden dukkar opp på ein stad operatøren alt har forlate.

sudo -b er ikkje ein handterar av påloggingsinformasjon

sudo -b køyrer kommandoen i bakgrunnen frå sudos eige perspektiv, noko som høyrest ut som funksjonen som manglar og ikkje er det. Ifølgje sudo-manualen oppfører interaktive kommandoar seg generelt dårleg i den modusen, og jobbkontrollen til skalet kan ikkje styra prosessane han lagar. Det flyttar prosessen utan å gje han ein måte å svara på spørsmål. Ingenting ved han gjev ein nøkkelfrase for ein privat nøkkel eller ei innlogging til ein gateway.

Viss tilkoplinga treng samhandling, er løysinga ei støtta ikkje-interaktiv autentiseringsordning, ikkje ein annan måte å starta same førespurnad på.

--daemon endrar programmet, ikkje innlogginga

--daemon ber OpenVPN sjølv om å kopla seg frå etter initialiseringa. 2.6-manualen merkar seg at syslog-omdirigering skjer når valet blir parsa, sjølv om fråkoplinga skjer seinare, så meldingar kan slutta å visast i terminalen tidlegare enn venta. Stillheit etter det punktet beviser ingenting om tunnelen. Legg til ein eksplisitt --log eller --log-append slik at utdataen hamnar ein stad du kan lesa.

Daemonmodus fjernar òg konsollen permanent. Ein verna privat nøkkel treng askpass i den modusen, og påloggingsinformasjon skriven inn på konsollen saman med hurtigbufringsval kan etterlata ei seinare reautentisering utan nokon stad å spørja. Kontroller autentiseringsmodellen mot den installerte versjonen før du går ut frå at ein bakgrunnsstart overlever den første nøkkelrotasjonen sin.

Kva sudo-validering gjev, og kva ho ikkje gjev

sudo -v validerer eller fornyar den bufra lokale påloggingsinformasjonen, og autentiserer viss policyen krev det. Ho startar ikkje OpenVPN, autentiserer ikkje mot gatewayen og garanterer ikkje at ein seinare kommando i skriptet er tillaten. sudo -n tyder det motsette: ikkje spør, feil i staden. Det gjer ein lokal autorisasjonsfeil eksplisitt, noko som er nyttig, og det seier ingenting om kva OpenVPN vil spørja om seinare.

Ingen av alternativa er grunn til å gje alle passordfrie kommandoar eller å senda eit administratorpassord inn i eit skript.

Føretrekk ein eigar som kan observerast

For ein maskineigd tunnel, bruk tenesteførekomsten distribusjonen støttar. Ein slik eigar gjev start, stopp, status og loggar, og han overlever at økta di blir avslutta. Å setja saman skal-bakgrunn, daemonisering og ein omstartsløkke rundt kvarandre skapar tre eigarar for ein tunnel og inga klar melding om kven som køyrer.

Uansett kva du vel, verifiser ressursen tunnelen finst for. Ein vellukka startførespurnad er ei prosesshending, ikkje prov på ei fungerande tilkopling.