sudo, &, -b ou --daemon: como pór un cliente OpenVPN en segundo plano

Na frase «execútao en segundo plano» escóndense dúas preguntas. A primeira é se este usuario pode sequera iniciar un proceso privilexiado; a segunda é se a sesión pode continuar sen que ninguén escriba nun terminal. Un ampersand da shell non responde a ningunha, e un script que garda un contrasinal de sudo nunha variable responde mal á primeira e deixa intacta a segunda. Sepáreas e as opcións vólvense fáciles de comparar.

Compare os tres candidatos por propiedade, non por comodidade.

Tres formas de deixar o terminal, tres donos distintos

Engadir un ampersand a un comando pide á shell que o execute como traballo en segundo plano, e o traballo segue pertencendo a esa shell. sudo pode preguntar antes de que o programa sequera comece, e OpenVPN pode preguntar despois por unha frase de contrasinal de clave ou un inicio de sesión. Poñer en segundo plano un comando que espera entrada produce un proceso que espera un terminal que ninguén mira. O terminal libérase; a interacción non.

É a opción máis barata e a que falla de forma máis confusa, porque o aviso aparece nun lugar que o operador xa abandonou.

sudo -b non é un xestor de credenciais

sudo -b executa o comando en segundo plano desde a perspectiva do propio sudo, o que soa como a función que faltaba e non o é. Segundo o manual de sudo, os comandos interactivos adoitan comportarse mal nese modo, e o control de traballos da shell non pode xestionar os procesos que crea. Move o proceso sen lle dar unha forma de responder preguntas. Nada nel proporciona unha frase de contrasinal de clave privada nin un inicio de sesión na pasarela.

Se a conexión necesita interacción, a solución é un mecanismo de autenticación non interactivo compatible, non outra forma de lanzar o mesmo aviso.

--daemon cambia o programa, non o inicio de sesión

--daemon pide ao propio OpenVPN que se separe tras a inicialización. O manual da versión 2.6 sinala que a redirección de syslog ocorre ao analizar a opción, aínda que a separación ocorre máis tarde, así que as mensaxes poden deixar de aparecer no terminal antes do esperado. O silencio despois dese punto non demostra nada sobre o túnel. Engada un --log ou --log-append para que a saída chegue a un lugar onde poida lela.

O modo demoño tamén elimina a consola de forma permanente. Unha clave privada protexida necesita askpass nese modo, e as credenciais introducidas por consola combinadas con opcións de caché poden deixar unha reautenticación posterior sen ningún lugar onde preguntar. Comprobe o modelo de autenticación coa versión instalada antes de supor que unha arranque en segundo plano sobrevivirá á súa primeira renovación de clave.

Que compra a validación de sudo e que non

sudo -v valida ou renova a credencial local na caché, autenticando se a política o esixe. Non inicia OpenVPN, non se autentica coa pasarela e non garante que se permita un comando posterior do script. sudo -n significa o contrario: non preguntes, falla. Iso fai explícito un fallo de autorización local, o que resulta útil, e non di nada sobre o que OpenVPN pedirá despois.

Ningunha das dúas opcións é motivo para conceder comandos sen contrasinal a todo o mundo nin para pasar un contrasinal de administrador a un script.

Preferir un dono que se poida observar

Para un túnel propiedade dunha máquina, use a instancia de servizo que admita a distribución. Ese dono ofrece inicio, parada, estado e rexistros, e sobrevive ao final da súa sesión. Montar a execución en segundo plano da shell, a demonización e un bucle de reinicio uns arredor doutros crea tres donos para un só túnel e ningunha resposta clara de cal está a funcionar.

Escolla o que escolla, verifique o recurso para o que existe o túnel. Unha solicitude de inicio correcta é un evento do proceso, non proba dunha conexión que funcione.