As atualizações não assistidas não usarão mailx quando executadas pelo Systemd

Question

Eu configurei unattended-upgrades nos servidores executando o Raspbian ( Raspbian GNU/Linux 9.4 (stretch) ). Versão de upgrades não assistidos: 0.93.1+nmu1

Atualiza o trabalho, mas estou tendo problemas com o relatório de e-mail. Quero usar mailx para enviar relatórios. Se eu executar a atualização com o comando unattended-upgrade -v -d , o relatório será enviado e ele usará a configuração de e-mail que eu tenho em /root/.mailrc .

Quando unattended upgrades é executado pelo timer Systemd ( apt-daily-upgrade.timer ), no entanto, ele não usa mailx .

Se sendmail estiver presente, ele será usado para enviar o e-mail. Nesse caso, o e-mail é enviado, mas o remetente é root@hostname e as mensagens são marcadas como spam.

Se não houver sendmail , vejo esse erro no diário de apt-daily-upgrade :

Cannot start "/usr/sbin/sendmail": executable not found (adjust *sendmail* variable)

Não consigo entender por que diferentes programas de e-mail são usados dependendo de como a tarefa foi iniciada.

Eu tentei editar o programa% python unattended-upgrades para forçá-lo a usar mailx :

if os.path.exists(SENDMAIL_BINARY):
        ret = _send_mail_using_sendmail(from_email, to_email, subject, body)
    elif os.path.exists(MAIL_BINARY):
        ret = _send_mail_using_mailx(from_email, to_email, subject, body

Alterei a variável SENDMAIL_BINARY para apontar para um caminho inexistente, de modo que seria forçado a usar mailx . Isso também funcionou quando invocado unattended-upgrades manualmente, mas falhou quando foi executado pelo Systemd. (E o erro acima sobre a tentativa de usar sendmail ainda é registrado.)

Como posso forçar o unattended upgrades a usar mailx mesmo quando ele é executado automaticamente pelo systemd e o que está causando a diferença no programa Mail que é usado?

EDITAR:

Arquivo de unidade do sistema que executa atualizações autônomas:

[Unit]
Description=Daily apt upgrade and clean activities
Documentation=man:apt(8)
ConditionACPower=true
After=apt-daily.service

[Service]
Type=oneshot
ExecStart=/usr/lib/apt/apt.systemd.daily install
KillMode=process
TimeoutStopSec=900

    

Answer 1

Sua pergunta é uma variação do FAQ Por que as coisas funcionam de maneira diferente no systemd? .

Um dos benefícios do systemd é que ele fornece um ambiente de execução consistente. Para erro do lado da segurança e simplicidade, as variáveis de ambiente definidas são mínimas.

Os documentos relacionados no systemd ambiente de execução detalham o que está definido.

Você mencionou que sua configuração estava no diretório root home. man mailx confirma Está procurando em ~/.mailrc , ao contrário do caminho fixo /root/.mailrc .

Os systemd docs esclarecem que a variável $HOME só é definida quando a diretiva User= é usada. Você não compartilhou seu arquivo systemd service, mas presumo que, como você está executando a tarefa como root, você não usou a diretiva User= . Isso poderia explicar parte do seu problema.

Também parece que um caminho que você deseja pode não ser definido pela sua variável de ambiente $PATH quando executado por systemd . Você pode confirmar isso substituindo a linha ExecStart= no seu serviço por:

 ExecStart=/bin/echo "My path is $PATH"

Se o caminho mailx não estiver listado, você poderá definir explicitamente com uma diretiva Environment= .

Se essas dicas explícitas não resolverem seu problema, confira as Perguntas frequentes relacionadas acima para mais possibilidades.