Erro SSL apenas ao executar no systemd

Question

Publicamos um questão mais ampla no StackOverflow, mas acho que alguns dos problemas são provavelmente muito específicos do Ubuntu.

Estou tentando executar o logstash em uma instância aws ec2 executando o Ubuntu 16.04 usando o systemd. Executar o pipeline normalmente (via bin / logstash.bat) funciona bem e os eventos são ingeridos.

Mas quando eu tento executar o serviço no systemd eu recebo erros, dos quais o primeiro é um erro SSL:

Error: no cipher match (OpenSSL::SSL::SSLError)

[2017-02-15T13:08:44,037][ERROR][logstash.pipeline        ] A plugin
had an unrecoverable error. Will restart this plugin.   
Plugin:
<LogStash::Inputs::Heroku app=>"xxxxxx",
codec=><LogStash::Codecs::Multiline pattern=>"^%{TIMESTAMP_ISO8601}
%{WORD}\[\w+(\.\d+)?\]:(\s{3,}| \})", what=>"previous",
id=>"032c3b317ae49982945ec7e8fbf11224be98f237-3", enable_metric=>true,
negate=>false, charset=>"UTF-8", multiline_tag=>"multiline",
max_lines=>500, max_bytes=>10485760>,
id=>"032c3b317ae49982945ec7e8fbf11224be98f237-4", enable_metric=>true>

Eu tentei executar o serviço como root, mas o resultado é o mesmo. Só para esclarecer, isso funciona:

/usr/share/logstash/bin/logstash --path.settings /etc/logstash/

Enquanto isso não acontecer:

sudo systemctl start logstash

Esta é uma instalação limpa do logstash 5.2.1, seguindo os procedimentos sobre elásticos . O Systemd também é executado de acordo com seus procedimentos , para que ele execute o mesmo comando como eu executo manualmente. cat logstash.service output:

[Unit]
Description=logstash

[Service]
Type=simple
User=logstash
Group=logstash
# Load env vars from /etc/default/ and /etc/sysconfig/ if they exist.
# Prefixing the path with '-' makes it try to load, but if the file doesn't
# exist, it continues onward.
EnvironmentFile=-/etc/default/logstash
EnvironmentFile=-/etc/sysconfig/logstash
ExecStart=/usr/share/logstash/bin/logstash "--path.settings" "/etc/logstash"
Restart=always
WorkingDirectory=/
Nice=19
LimitNOFILE=16384

[Install]
WantedBy=multi-user.target

(o resultado é o mesmo quando eu comento o usuário e o grupo acima)

EDITAR: Então, parece que o SSL pode ser causado pelo outro erro que estou recebendo. Eu segui o diário do serviço usando sudo journalctl -f -u logstash & e os logs do próprio serviço em segundo plano e recebi a seguinte saída:

ubuntu@ip-10-0-1-216:~$ sudo systemctl start logstash

ubuntu@ip-10-0-1-216:~$ Feb 15 15:38:19 ip-10-0-1-216 systemd1: Started logstash.

Feb 15 15:38:33 ip-10-0-1-216 logstash[5119]: Sending Logstash's logs to /var/log/logstash which is now configured via log4j2.properties

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Enter your Heroku credentials.

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Email: Password (typing will be hidden):

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Enter your Heroku credentials.

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Email: Password (typing will be hidden):

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Enter your Heroku credentials.

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Email: Password (typing will be hidden):

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Enter your Heroku credentials.

Feb 15 15:38:36 ip-10-0-1-216 logstash[5119]: Email: Password (typing will be hidden):

[2017-02-15T15:38:37,403][ERROR][logstash.pipeline ] A plugin had an unrecoverable error. Will restart this plugin. Plugin: "ros-prd", codec=>"^%{TIMESTAMP_ISO8601} %{WORD}\[\w+(\.\d+)?\]:(\s{3,}| \})", what=>"previous", id=>"9fd55a86d7f6e98e9c1698eb67a66a24364ea902-3", enable_metric=>true, negate=>false, charset=>"UTF-8", multiline_tag=>"multiline", max_lines=>500, max_bytes=>10485760>, id=>"9fd55a86d7f6e98e9c1698eb67a66a24364ea902-4", enable_metric=>true>

Portanto, parece que o erro SSL só é iniciado após os prompts para inserir a senha do heroku.

Então minha (s) pergunta (s):

1. Parece que as credenciais do heroku estão armazenadas em ~ / home / user / .netrc. Como posso fornecer o serviço systemd com acesso a este arquivo para que ele não solicite a senha do heroku?
2. Ou, se o acima não for possível, como posso passar a senha para o serviço? Existe alguma maneira de aproveitar systemd-tty-ask-password-agent talvez?

Answer 1

Se systemd solicitar sua senha, mas a senha não for solicitada, compare esses dois casos entre o ambiente system e o ambiente de shell:

1. O systemd está sendo executado como o mesmo usuário que você usa ao executar com êxito o comando no shell?
2. Quando executado por meio de systemd , a variável de ambiente HOME corresponde ao valor usado no shell? Defina Environment="Home=/home/youruser" no seu arquivo de unidade do sistema, se necessário.

Como mencionado no ticket vinculado, a melhor solução é nunca tentar, cegamente, despejar todas as variáveis de ambiente do ambiente da CLI no ambiente systemd .

A intenção com systemd é fornecer um ambiente isolado e específico para fornecer resultados confiáveis e reproduzíveis ao longo do tempo. Para configurá-lo, você deve saber quais variáveis de ambiente afetam seu aplicativo. É muito provável que esse entendimento ajude seu uso e a solução de problemas do aplicativo posteriormente.

As alterações do ambiente da CLI ao longo do tempo são relativamente "poluídas" com vários valores que não estão relacionados à tarefa que você está tentando executar. Despejar todos esses valores no ambiente systemd pode parecer uma correção rápida, mas cria complexidade e confusão desnecessárias sobre quais variáveis estão realmente afetando o aplicativo.