sudo, &, -b ou --daemon: como passar um cliente OpenVPN para segundo plano

Na frase «execute-o em segundo plano» escondem-se duas perguntas. A primeira é se este utilizador pode sequer iniciar um processo privilegiado; a segunda é se a sessão pode continuar sem que ninguém escreva num terminal. Um ampersand da shell não responde a nenhuma, e um script que guarda uma palavra-passe sudo numa variável responde mal à primeira e deixa a segunda intacta. Separe-as e as opções tornam-se fáceis de comparar.

Compare os três candidatos por propriedade, não por conveniência.

Três formas de deixar o terminal, três donos diferentes

Acrescentar um ampersand a um comando pede à shell que o execute como tarefa em segundo plano, e a tarefa continua a pertencer a essa shell. O sudo pode perguntar antes de o programa sequer começar, e o OpenVPN pode perguntar depois por uma frase-passe de chave ou um início de sessão. Pôr em segundo plano um comando que espera entrada produz um processo à espera de um terminal que ninguém observa. O terminal é libertado; a interação não.

É a opção mais barata e a que falha de forma mais confusa, porque o pedido aparece num local que o operador já abandonou.

O sudo -b não é um gestor de credenciais

sudo -b executa o comando em segundo plano na perspetiva do próprio sudo, o que soa como a funcionalidade em falta e não é. Segundo o manual do sudo, os comandos interativos costumam comportar-se mal nesse modo, e o controlo de tarefas da shell não consegue gerir os processos que cria. Move o processo sem lhe dar forma de responder a perguntas. Nada nele fornece uma frase-passe de chave privada ou um início de sessão na gateway.

Se a ligação precisa de interação, a solução é um esquema de autenticação não interativo suportado, não outra forma de lançar o mesmo pedido.

O --daemon muda o programa, não o início de sessão

--daemon pede ao próprio OpenVPN que se destaque após a inicialização. O manual da versão 2.6 nota que o redirecionamento do syslog ocorre quando a opção é analisada, embora o destacamento ocorra mais tarde, pelo que as mensagens podem deixar de aparecer no terminal mais cedo do que o esperado. O silêncio depois desse ponto não prova nada sobre o túnel. Acrescente um --log ou --log-append explícito para que a saída fique num local que possa ler.

O modo daemon também remove a consola permanentemente. Uma chave privada protegida precisa de askpass nesse modo, e as credenciais introduzidas na consola combinadas com opções de cache podem deixar uma reautenticação posterior sem local onde perguntar. Verifique o modelo de autenticação face à versão instalada antes de assumir que um arranque em segundo plano sobreviverá à primeira renovação de chave.

O que a validação sudo compra e o que não compra

sudo -v valida ou renova a credencial local em cache, autenticando se a política o exigir. Não inicia o OpenVPN, não se autentica na gateway e não garante que um comando posterior no script seja permitido. sudo -n significa o contrário: não pergunte, falhe. Isso torna explícita uma falha de autorização local, o que é útil, e não diz nada sobre o que o OpenVPN pedirá mais tarde.

Nenhuma das opções é motivo para conceder comandos sem palavra-passe a todos ou para encaminhar uma palavra-passe de administrador para um script.

Prefira um dono que possa ser observado

Para um túnel pertencente à máquina, use a instância de serviço suportada pela distribuição. Esse dono fornece início, paragem, estado e registos, e sobrevive ao fim da sua sessão. Montar o segundo plano da shell, a demonização e um ciclo de reinício uns à volta dos outros cria três donos para um único túnel e nenhuma resposta clara sobre qual está a correr.

Escolha o que escolher, verifique o recurso para o qual o túnel existe. Um pedido de início bem-sucedido é um evento do processo, não prova de uma ligação a funcionar.