Motion e Systemd - servizio e permessi

A volte mi capitano quelle giornate in cui in cui mi fisso col voler risolvere dei problemi veramente marginali che magari mi fanno perdere ore e ore di tempo. Credo comunque che, sebbene poi il risultato sia decisamente modesto, lo sforzo sia  ampiamente ripagato dalla soddisfazione di aver imparato qualcosa di nuovo.

Tempo fa installai su un client con centos7 il programma motion, che serve per gestire telecamere usb/ip per la videosorveglianza. Il demone viene avviato da un'unità di servizio di systemd, ovvero questa:

/usr/lib/systemd/system/motion.service

Il demone inoltre ha un suo file di configurazione in /etc/motion/motion.conf

Non è tanto importante motion in se in quanto ciò che sto scrivendo si può applicare a qualsiasi altro servizio.

Quando si va a installare l'rpm di motion viene creato un utente motion appartenente al gruppo video: il demone poi di default avrà i permessi di questo utente. Ho però avuto l'esigenza di far si che questo demone funzionasse con un utente diverso, ovvero il mio (merli).
Per far questo è bastato editare il file di unità (vabbè, sarebbe stato meglio copiarsi l'unità in /etc/systemd/system) e specificare nella sezione [service] queste 2 semplici direttive

Una volta avviato, il servizio però si lamentava che il file /var/log/motion.log non era più scrivibile: questo perchè era di proprietà di motion.video. Ho quindi cambiato con chown i permessi al file e tutto ha funzionato correttamente.

Il problema è nato dal fatto che, a ogni riavvio, malgrado io avessi dato a mano i giusti permessi al file di log, questo tornava a essere di proprietà di motion.video, di fatto impedendo a motion di partire correttamente in fase di boot. Questo spiacevole inconveniente (il cambio di permessi) accadeva anche avendo disabilitato completamente il demone motion, cosa che mi ha fatto imbufalire: perdere il "controllo" su ciò che avviene in un sistema infatti è parecchio irritante e in questo systemd è davvero maestro.

Per prima cosa ho cercato di capire se il cambio avenisse in fase di shutdown o di reboot. Ho spento la macchina, riavviato con una distribuzione live, montato il file system e guardato i permessi del file: ho così avuto la conferma che il problema si verificava in fase di boot e non di shutdown.

Per capire cosa stesse accadendo ho provato ad abilitare il demone audit sul file di /var/log/motion.log, che, nelle mie sperenze, mi avrebbe avvisato a ogni cambio di permessi. Non sto a spiegare esattamente cosa ho fatto anche perchè non ho avuto alcun risultato concreto: il problema è che i permessi venivano modificati prima dell'avvio di audit, che quindi non riusciva a registrare alcuna informazione utile.

Alla fine ho trovato il responsabile: il servizio temporizzato systemd-tmpfiles-setup.service che viene fatto partire all'avvio del pc e che lancia il comando systemd-tmpfiles --remove --create (vedi il mio precedente articolo, qui). Lo scopo di questo servizio è quello di  creare tutti i temporanei del sistema. Per qualche motivo l'rpm di motion va ad  installare il file

/usr/lib/tmpfiles.d/motion.conf

che contiene

Quindi (una volta capito è anche intelligente la cosa) a ogni riavvio viene verificato che il file esista e che i permessi siano quelli qui sopra riportati. E' bastato cambiare l'UID del file di log qui sopra per risolvere.

Per evitare problemi nel futuro è anche opportuno modificare i permessi in /etc/logrotate.d/motion, altrimenti dopo la rotazione dei log il file ricreato avrà i permessi sbagliati.

Print Friendly, PDF & Email