O script de início do OpenVPN não executa um comando

Question

Background : Estou configurando Transmission (v2.93) e OpenVPN (v2.4.6) em uma jaula (uma cadeia de plugins FreeNAS 11.1) e quero adicionar um script --up ao OpenVPN que solicitará Transmission para alterar sua porta de escuta (usando o programa transmission-remote ).

Meu openvpn.conf contém o seguinte (entre outros):

verb 4
script-security 2
up /usr/local/etc/openvpn/set_port.sh
up-restart ;only to make the up script be executed on restarts
           ;but disabling this changes nothing

e o script set_port.sh contém (um script mínimo que ainda reproduz o comportamento):

#!/usr/local/bin/bash
/usr/local/bin/transmission-remote --auth rpc_user:rpc_pass -p 6666 2>&1 > output.txt
echo 'the script itself runs: '$(pwd) $(whoami) > status.txt

O script tem todas as permissões (777) e o binário ( transmission-remote ) tem todas as permissões. Estou ciente de que o caminho para o binário é na verdade um link flexível, então eu o substitui pelo caminho real ( /usr/pbi/transmission-amd64/.sbin/transmission-remote ), mas o comportamento que observo é o mesmo.

Problema : quando eu inicio o OpenVPN ( service openvpn start ), o próprio script é executado, mas o comando atual falha misteriosamente: a porta não está sendo atribuída (verificada) olhando através de Transmissão Remota GUI e o comando gera saída vazia.
O conteúdo dos arquivos de depuração é o seguinte:
output.txt está vazio (com e sem redirecionamento stderr )
status.txt diz como esperado: the script itself runs: /usr/local/etc/openvpn root .

No entanto, quando eu executar este script manualmente ( ./set_port.sh ), o comando mencionado será concluído com êxito: output.txt dirá localhost:9091/transmission/rpc/ responded: "success" e a porta será alterada.

O que estou perdendo?

Similar para esta pergunta , exceto que não estou recebendo nenhuma "permissão negada" mensagens - parece que o comando não é sequer executado (se eu echo $(<that command>) > file.txt , eu recebo um arquivo vazio). This one também é um pouco relacionado, mas o OP está perguntando sobre --client-connect e eventualmente resolve o problema escrevendo caminhos completos para os programas que eles querem executar - isso não ajudou no meu caso (mas se eu echo $(ls /usr/local/bin) > log.txt , o lista de binários está correta).

Atualizar por solicitação do @ roaima. Eu mudei o set_port.sh para o seguinte:

#!/usr/local/bin/bash
exec >debug.txt 2>&1
set -x
echo script is running
/usr/pbi/transmission-amd64/.sbin/transmission-remote  --auth rpc_user:rpc_pass -p 6666 2>&1 > output.txt

depois enxaguado e repetido. O arquivo debug.txt continha estas linhas:

+ echo script is running
script is running
+ /usr/pbi/transmission-amd64/.sbin/transmission-remote --auth rpc_user:rpc_pass -p 12345
/usr/local/etc/openvpn/test.sh: line 5:  6795 Segmentation fault      /usr/pbi/transmission-amd64/.sbin/transmission-remote --auth rpc_user:rpc_pass -p 12345 2>&1 > output.txt

    

Answer 1

Olhando para a linha

/usr/local/etc/openvpn/test.sh: line 5:  6795 Segmentation fault      /usr/pbi/transmission-amd64/.sbin/transmission-remote --auth rpc_user:rpc_pass -p 12345 2>&1 > output.txt

Parece que seus executáveis possuem bibliotecas incompatíveis. Por favor, verifique novamente como você construiu seu chroot. (Eu não uso o FreeBSD há anos e anos, então não posso dar dicas sobre como fazer isso, desculpe.)

    

Answer 2

Eu não tenho idéia sobre a incompatibilidade de bibliotecas que está acontecendo aqui, especialmente que tudo isso acontece em uma "cadeia de plugins" do FreeNAS e eu não sei como ela está configurada. No entanto, consegui contornar o problema para atingir o objetivo de fazer com que o OpenVPN configurasse a Transmissão na rota.
Nota : a seguinte resposta NÃO resolve o problema da falha de segmentação, portanto Eu não vou marcá-lo como aceito.

A solução é baseada na seguinte observação: enquanto transmission-remote segfaulted se chamado pelo OpenVPN, ele funcionaria perfeitamente se cron o chamasse:

1. Deixe openvpn.conf como está.

2. Em set_port.sh , em vez de chamar transmission-remote , armazene o número da porta em um arquivo - por exemplo, assim: echo $port > $path/port-id (daqui em diante assumirei% variávelpath leva à pasta onde nós armazenamos os scripts, etc.)

3. Crie um novo script, vamos chamá-lo de actually_set.sh , com o seguinte:

#!/usr/local/bin/bash
if [ -f $path/port-id ]; then
  port=$(cat $path/port-id)
  rm $path/port-id
  transmission-remote -n 'rpc_user:rpc_pass' -p $port
fi

4. Defina cron para chamar o script acima a cada minuto. Eu coloquei o seguinte no meu crontab:
   * * * * * /usr/local/etc/openvpn/ports/tp_setter.sh

Answer 3

Se você definir o nível verb para 3-4, provavelmente verá avisos sobre os scripts não serem executados. Por padrão, o OpenVPN 2.2+ só chama certos built-ins. Você precisa relaxar usando script-security :

--script-security level

This directive offers policy-level control over OpenVPN's usage of external programs and scripts. Lower level values are more restrictive, higher values are more permissive.

Settings for level:

0 -- Strictly no calling of external programs.
1 -- (Default) Only call built-in executables such as ifconfig, ip, route, or netsh.
2 -- Allow calling of built-in executables and user-defined scripts.
3 -- Allow passwords to be passed to scripts via environmental variables (potentially unsafe).

Você precisa ter certeza de que você tem script-security definido para 2 ou 3 (2 se você não precisar enviar senhas para o script, 3 caso contrário.)