sudo, &, -b eller --daemon: hvordan kjøre en OpenVPN-klient i bakgrunnen

Uttrykket «kjør det i bakgrunnen» skjuler to spørsmål. Det første er om denne brukeren i det hele tatt kan starte en privilegert prosess; det andre er om sesjonen kan fortsette uten at noen skriver i en terminal. Et skall-ampersand svarer på ingen av dem, og et skript som lagrer et sudo-passord i en variabel, svarer dårlig på det første og lar det andre være urørt. Skill dem, og alternativene blir enkle å sammenligne.

Sammenlign de tre kandidatene på eierskap, ikke på bekvemmelighet.

Tre måter å forlate terminalen, tre forskjellige eiere

Å legge et ampersand etter en kommando ber skallet kjøre den som en bakgrunnsjobb, og jobben tilhører fortsatt det skallet. sudo kan spørre før programmet i det hele tatt starter, og OpenVPN kan etterpå spørre om en nøkkelfrase eller en innlogging. Å legge en kommando som venter på input i bakgrunnen gir en prosess som venter på en terminal ingen ser på. Terminalen frigjøres; samhandlingen ikke.

Det er det billigste alternativet og det som feiler mest forvirrende, fordi forespørselen dukker opp på et sted operatøren allerede har forlatt.

sudo -b er ikke en håndterer av påloggingsinformasjon

sudo -b kjører kommandoen i bakgrunnen fra sudos eget perspektiv, noe som høres ut som funksjonen som mangler og ikke er det. Ifølge sudo-manualen oppfører interaktive kommandoer seg generelt dårlig i den modusen, og skallets jobbkontroll kan ikke administrere prosessene den lager. Den flytter prosessen uten å gi den en måte å svare på spørsmål. Ingenting ved den leverer en nøkkelfrase for en privat nøkkel eller en innlogging til en gateway.

Hvis tilkoblingen trenger samhandling, er løsningen en støttet ikke-interaktiv autentiseringsordning, ikke en annen måte å starte samme forespørsel på.

--daemon endrer programmet, ikke innloggingen

--daemon ber OpenVPN selv om å koble seg fra etter initialiseringen. 2.6-manualen bemerker at syslog-omdirigering skjer når alternativet parses, selv om frakoblingen skjer senere, så meldinger kan slutte å vises i terminalen tidligere enn forventet. Stillhet etter det punktet beviser ingenting om tunnelen. Legg til en eksplisitt --log eller --log-append slik at utdataen havner et sted du kan lese.

Daemonmodus fjerner også konsollen permanent. En beskyttet privat nøkkel trenger askpass i den modusen, og påloggingsinformasjon skrevet inn på konsollen kombinert med hurtigbufringsvalg kan etterlate en senere reagodkjenning uten noe sted å spørre. Kontroller autentiseringsmodellen mot den installerte versjonen før du antar at en bakgrunnsstart overlever sin første nøkkelrotasjon.

Hva sudo-validering gir, og hva den ikke gir

sudo -v validerer eller fornyer den bufrende lokale påloggingsinformasjonen, og autentiserer hvis policyen krever det. Den starter ikke OpenVPN, autentiserer ikke mot gatewayen og garanterer ikke at en senere kommando i skriptet er tillatt. sudo -n betyr det motsatte: ikke spør, feil i stedet. Det gjør en lokal autorisasjonsfeil eksplisitt, noe som er nyttig, og det sier ingenting om hva OpenVPN vil spørre om senere.

Ingen av alternativene er grunn til å gi alle passordfrie kommandoer eller å sende et administratorpassord inn i et skript.

Foretrekk en eier som kan observeres

For en maskineid tunnel, bruk tjenesteforekomsten distribusjonen støtter. En slik eier gir start, stopp, status og logger, og den overlever at sesjonen din avsluttes. Å sette sammen skallbakgrunn, daemonisering og en omstartsløkke rundt hverandre skaper tre eiere for én tunnel og ingen klar beskjed om hvilken som kjører.

Uansett hva du velger, verifiser ressursen tunnelen finnes for. En vellykket startforespørsel er en prosesshendelse, ikke bevis på en fungerende tilkobling.