Exibição incorretamente definida ao executar um trabalho root crontab envolvendo GUI

Question

Ao executar o script abaixo do meu usuário local crontab, com sudo antes de /usr/bin/FreeFileSync (última linha do script), uma pequena janela de progresso é aberta na minha GUI e as coisas vão bem. A única coisa é que eu tenho que inserir meu sudo passwd, o que o torna interativo e um tanto desajeitado.

Os privilégios de raiz são necessários para executar o FFS, caso contrário, ele se queixa de não ter direitos para acessar alguns diretórios e arquivos que estão sendo armazenados em backup.

  #!/bin/bash
  # define default display and pass it on to any child process
  # from within the running shell
  DISPLAY=:0.0
  export DISPLAY

  /usr/bin/FreeFileSync /home/user/bu-1.ffs_batch 2> \ 
     /home/user/bu-1.ffs_log 

Quando eu chamo o mesmo script do meu crontab de raiz com sudo crontab -e , FreeFileSync nunca é executado devido ao seguinte erro:

$ cat /home/user/bu-1.ffs_log
16:35:01: Error: Unable to initialize GTK+, is DISPLAY set properly?

Como pode ser visto, eu tenho export DISPLAY=:0.0 dentro do script e meu arquivo crontab raiz está equipado com:

  $ sudo crontab -e | head -4
  [sudo] password for user:

  1 SHELL=/bin/bash
  2 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  3 HOME=/
  4 MAILTO=root

Alguém pode ajudar a solucionar o erro?

EDIT: Pode ser que a execução do crontab do root falhe porque o usuário root não possui sessão aberta e, portanto, não possui stdout para exibir? Posso contornar essa dificuldade pedindo ao root para exibir o stdout de uma sessão do usuário atual? Parece valer uma chance se possível; se sim, como faço isso?

    

Answer 1

Você pode configurar sudo para não precisar de uma senha para um determinado comando e voltar a usar um cron não-root. Para isso, assumindo que um ID de usuário "usuário" deseja executar o comando FreeFileSync as root, crie um arquivo /etc/sudoers.d/user with

user ALL = NOPASSWD: /usr/bin/FreeFileSync

O comando deve ser fornecido com um nome de caminho completo. Se você não listar explicitamente os argumentos para o comando, qualquer argumento será permitido pelo sudo. Substitua ALL pelo seu nome de host (não localhost) para ser mais seguro.

Isso pressupõe que o arquivo /etc/sudoers tenha a linha: (note # não é não é um comentário)

#includedir /etc/sudoers.d

Se não, basta adicionar a entrada do usuário ao / etc / sudoers. Tenha cuidado ao editar este arquivo: use visudo, ou certifique-se de ter o root logado ou um shell executando root para poder fazer qualquer reparo.

Sua entrada user crontab pode então ter o comando:

DISPLAY=:0.0 sudo /usr/bin/FreeFileSync /home/user/bu-1.ffs_batch 2>/home/user/bu-1.ffs_log

ubuntu sudo preservará algumas variáveis de ambiente para o comando, incluindo DISPLAY e HOME (veja a saída de sudo sudo -V ) para que o programa possa ler o arquivo ~ / .Xauthority (continue lendo para detalhes).

Como alternativa, continue usando um crontab raiz: se quando você faz ps alxww|grep X você encontra seu servidor X11 rodando com uma opção -auth , algo assim:

/usr/bin/X :0 ... -auth /var/run/lightdm/root/:0 ...

significa que os clientes devem se conectar usando o segredo no arquivo /var/run/lightdm/root/:0 . Este arquivo contém uma cópia do segredo no arquivo ~/.Xauthority do usuário. Esse "segredo" é apenas um número aleatório arbitrário. Se você é root, você pode ler os dois arquivos, para que seu cliente possa simplesmente fornecer no ambiente:

XAUTHORITY=/var/run/lightdm/root/:0

Como alternativa, você pode definir a HOME como a do usuário da exibição, HOME=/home/user para que o arquivo .Xauthority correto seja encontrado lá.

Como alternativa, você pode exportar o segredo desta para a home de raiz:

xauth -f /home/user/.Xauthority nextract - localhost/unix:0 | sudo xauth -f /root/.Xauthority nmerge -

e depois XAUTHORITY = / root / .Xauthority ou apenas HOME = / root.