sudo, &, -b eller --daemon: hur man kör en OpenVPN-klient i bakgrunden

Uttrycket ”kör det i bakgrunden” döljer två frågor. Den första är om den här användaren alls får starta en privilegierad process; den andra är om sessionen kan fortsätta utan att någon skriver i en terminal. Ett skal-ampersand besvarar ingen av dem, och ett skript som lagrar ett sudo-lösenord i en variabel besvarar den första dåligt och lämnar den andra orörd. Skilj dem åt och alternativen blir lätta att jämföra.

Jämför de tre kandidaterna efter ägande, inte efter bekvämlighet.

Tre sätt att lämna terminalen, tre olika ägare

Att lägga ett ampersand efter ett kommando ber skalet köra det som ett bakgrundsjobb, och jobbet tillhör fortfarande det skalet. sudo kan fråga innan programmet ens startar, och OpenVPN kan sedan fråga efter en nyckelfras eller en inloggning. Att lägga ett kommando som väntar på inmatning i bakgrunden ger en process som väntar på en terminal som ingen tittar på. Terminalen frigörs; interaktionen inte.

Det är det billigaste alternativet och det som misslyckas mest förvirrande, eftersom frågan dyker upp på en plats som operatören redan har lämnat.

sudo -b är inte en hanterare av inloggningsuppgifter

sudo -b kör kommandot i bakgrunden ur sudos eget perspektiv, vilket låter som funktionen som saknas och inte är det. Enligt sudo-manualen beter sig interaktiva kommandon i allmänhet illa i det läget, och skalets jobbkontroll kan inte hantera processerna den skapar. Det flyttar processen utan att ge den ett sätt att svara på frågor. Inget i det ger en nyckelfras för en privat nyckel eller en inloggning till en gateway.

Om anslutningen behöver interaktion är lösningen en stödd icke-interaktiv autentiseringsordning, inte ett annat sätt att starta samma fråga.

--daemon ändrar programmet, inte inloggningen

--daemon ber OpenVPN självt att koppla loss efter initieringen. 2.6-manualen noterar att syslog-omdirigering sker när alternativet tolkas, även om losskopplingen sker senare, så meddelanden kan sluta visas i terminalen tidigare än väntat. Tystnaden efter den punkten bevisar inget om tunneln. Lägg till en uttrycklig --log eller --log-append så att utdata hamnar någonstans där du kan läsa den.

Daemonläget tar också bort konsolen permanent. En skyddad privat nyckel behöver askpass i det läget, och inloggningsuppgifter som skrivs in på konsolen tillsammans med cache-alternativ kan lämna en senare omautentisering utan någonstans att fråga. Kontrollera autentiseringsmodellen mot den installerade versionen innan du antar att en bakgrundsstart överlever sin första nyckelrotation.

Vad sudo-validering ger och vad den inte ger

sudo -v validerar eller förnyar den cachade lokala inloggningsuppgiften och autentiserar om policyn kräver det. Den startar inte OpenVPN, autentiserar inte mot gatewayen och garanterar inte att ett senare kommando i skriptet tillåts. sudo -n betyder motsatsen: fråga inte, misslyckas i stället. Det gör ett lokalt auktoriseringsfel explicit, vilket är användbart, och det säger inget om vad OpenVPN kommer att fråga efter senare.

Inget av alternativen är skäl att ge alla lösenordsfria kommandon eller att skicka ett administratörslösenord in i ett skript.

Föredra en ägare som kan observeras

För en maskinägd tunnel, använd tjänstinstansen som distributionen stöder. En sådan ägare ger start, stopp, status och loggar, och den överlever att din session avslutas. Att bygga skalets bakgrundskörning, daemonisering och en omstartsloop runt varandra skapar tre ägare för en tunnel och inget tydligt svar på vilken som körs.

Vad du än väljer, verifiera resursen som tunneln finns för. En lyckad startbegäran är en processhändelse, inte bevis på en fungerande anslutning.