Um único drop-in de OpenVPN mudou todos os túneis: instância versus modelo

Uma política de reinício adicionada para um túnel começa a valer para todos os túneis da máquina. Não é um bug do systemd; é a diferença entre um drop-in de instância e um drop-in de modelo. O caminho sob o qual você escreve o arquivo decide quantos serviços o herdam.

Escolha o escopo antes da configuração. Os dois diretórios parecem quase idênticos, e só um deles é limitado à instância que você pretendia.

O sintoma: uma edição, todos os túneis

Um drop-in específico da instância fica sob um diretório nomeado pela instância completa, como [email protected]. Um drop-in de modelo fica sob [email protected], com o sinal @ e nenhum nome de instância entre eles. O primeiro se aplica apenas a office. O segundo se aplica a cada serviço instanciado a partir desse modelo.

A forma de modelo não alcança um modelo [email protected] separado e não alcança serviços não relacionados com openvpn no nome.

Escolha o diretório que corresponde ao escopo

Os dois diretórios ficam sob /etc/systemd/system/. Omitir o último componente system cria um caminho que o systemd não lê como uma substituição de sistema, e essa é uma forma silenciosa de fazer um arquivo de aparência correta não fazer nada. Escreva o caminho completo uma vez e reutilize-o.

Um drop-in também precisa do cabeçalho de seção correto. As configurações de serviço vão sob [Service]. Um arquivo com configurações mas sem seção é ignorado ou rejeitado, e a unidade continua se comportando como antes enquanto o arquivo fica ali com aparência de autoridade.

Mantenha o propósito no nome do arquivo se adicionar mais de um drop-in. A ordem lexicográfica decide a mesclagem, e um nome que diz o que o arquivo faz torna essa ordem legível.

Leia a unidade mesclada antes de escrever

Leia a unidade mesclada antes de escrever qualquer coisa. systemctl cat [email protected] imprime a unidade principal e cada drop-in que se aplica, em ordem de mesclagem. Compare-a com uma segunda instância quando estiver considerando uma mudança de modelo. Essa comparação mostra exatamente quais serviços herdariam a edição.

Um arquivo de instância não apaga as configurações do modelo. Ambos são mesclados, então um valor do modelo que você esqueceu ainda pode estar em vigor.

Outros drop-ins nomeados, configurações de execução e configuração fornecida por pacotes também participam. Não presuma que o arquivo que você editou por último seja a unidade inteira. A saída mesclada é a unidade.

Mantenha a política da unidade fora do perfil

Mantenha separadas a política da unidade e a configuração de VPN. Uma diretiva de perfil não se torna sintaxe válida do systemd por estar sob [Service]. Uma configuração de reinício também não pertence a um arquivo .ovpn.

Essa separação é também a razão pela qual uma política de reinício não é o mesmo que a recuperação de pares que o OpenVPN faz sozinho. Decida que comportamento você quer antes de escolher um escopo.

Aplique e verifique a instância

Depois da mudança, recarregue as definições do gerenciador com systemctl daemon-reload. Essa recarga não reinicia o túnel; ela apenas relê os arquivos de unidade. Em seguida, aplique a ação de ciclo de vida que você pretendia à instância exata.

Verifique relendo a unidade carregada e observando o comportamento que você mudou. Um reinício que carrega trabalho ativo merece uma interrupção planejada, não um teste rápido em um túnel de produção. Anote o propósito e o escopo da substituição ao lado da implantação para que a próxima pessoa saiba se o arquivo deveria ser compartilhado.

Se a política é realmente compartilhada, mova-a deliberadamente para o modelo e verifique uma segunda instância antes de dar por concluído. A referência de unidades do systemd documenta a precedência dos drop-ins e a ordem de mesclagem.