Logrotate non legge più il file di configurazione con collegamento simbolico a causa della proprietà non root

15

Attualmente stiamo eseguendo l'aggiornamento da Ubuntu 12.04 LTS a 14.04 LTS sui nostri server applicazioni ruby on rails e abbiamo notato che i file di registro non ruotano più.

Su entrambe le macchine abbiamo un file di /var/app-name/config/logrotateproprietà del nostro utente unix deployerche contiene un file logrotate valido come segue:

/var/app-name/log/*.log {
  daily
  rotate 365
  delaycompress
  compress
  dateext
  dateformat -%Y%m%d
  missingok
  copytruncate
}

Questo viene quindi collegato alla /etc/logrotate.d/directory comeapp-name

Sul nostro server Ubuntu 12.04 abbiamo logrotate 3.7.8 che funziona perfettamente. Va nella var/app-name/log/directory e ruota tutti i file di registro

Ma sul server Ubuntu 14.04 abbiamo logrotate 3.8.7 che non ruota i file di registro per la nostra applicazione.

Quando eseguo il debug tramite sudo logrotate -d -f /etc/logrotate/.confottengo il seguente output:

Ignoring /etc/logrotate.d/app-name because the file owner is wrong (should be root).

Inseguendo questo nel codice, sembra che questa modifica sia stata aggiunta per il flusso di rilascio 3.8.x: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

Se cambio la proprietà del file collegato a symlink /var/app-name/config/logrotatea, rootallora ricomincia a funzionare. Ma dato che questo file fa parte della mia applicazione e creato dal framework di distribuzione capistrano che utilizziamo in questo stato, preferirei non dover alterarne la proprietà, quando funzionava bene.

Quindi i file di configurazione con collegamento simbolico sono consigliati / supportati da logrotate?

E se è così, dovrebbe essere il rifiuto di usare il mio file (di proprietà di deployer) che è linkato nella /etc/logrotate.ddirectory, essere visto come un bug?

Oppure esiste un altro approccio consigliato per la rotazione dei registri specifici dell'applicazione?

(richiesto anche su unix StackExchange )

ubuntu permissions logrotate

— phantomwhale
fonte

Buona domanda! Vedo che in seguito si è discusso del controllo con il nome utente "root" anziché uid == 0, ma ciò non ha innescato la domanda sul perché sia richiesta la proprietà root.

— agtoever,

6

Il problema è che un file di configurazione logrotate può eseguire qualsiasi comando come root (usando stanze prerotate / postrotate). Pertanto, si darebbero effettivamente deployeri privilegi di root dell'utente concedendogli l'accesso in scrittura ai file /etc/logrotate.d/. Quindi no, non è un bug.

Se ti fidi del tuo utente deployer, immagino che potresti risolvere il problema dandogli i diritti sudo per copiare i file /etc/logrotate.d/. Supponendo, ovviamente, che l'utente del distributore non sia lo stesso utente in cui è in esecuzione l'app Web.

— pelle
fonte

Il nostro approccio è sempre stato quello di preferire il collegamento simbolico da directory esterne all'applicazione in file dell'applicazione, in modo tale che ogni distribuzione non solo espellesse la nuova applicazione, ma anche qualsiasi modifica del file di configurazione. Anche dare al deployer i diritti di distribuire il codice al di fuori della directory dell'applicazione viola questo approccio, ma ugualmente dover chown un file di applicazione per essere post-deploy di proprietà root sembra anche una cosa negativa (tm). Forse l'approccio originale quindi non può più funzionare bene con logrotate 3.8.0+

— phantomwhale

2

@phantomwhale Il tuo approccio originale ha implicitamente conferito al tuo utente di distribuzione i privilegi di root completi. Non è una novità in Logrotate 3.8. Se si desidera limitare i diritti del deployer pur consentendogli di aggiornare la configurazione, penso che sia necessario utilizzare qualcosa di diverso da logrotate.

— pelle,

2

Mi rendo conto di essere in ritardo per la festa, ma avevo un problema simile e pensavo che avrei condiviso la mia soluzione.

I miei problemi sono iniziati quando logrotatenon avevo letto la configurazione che avevo scritto. Non volevo distribuire nuove configurazioni in una cartella di proprietà di root perché non volevo che l'utente di distribuzione avesse accesso root a nulla .

All'inizio ho provato a correre logrotatecome utente deploy, ma mi sono lamentato di avere accesso al file di stato su /var/lib/logrotate/state. Poi ho letto la pagina man. È possibile specificare il file di stato che logrotateutilizza! Quindi, mi è sembrata una soluzione migliore per impostare un cron giornaliero da eseguire logrotatecome utente di distribuzione con un file di stato personalizzato. In questo modo, l'utente root o l'applicazione non devono accedere alla radice.

Ecco come specificare il file di stato:

logrotate --state /path/to/status /path/to/custom_logrotate.conf

Ora puoi eseguire logrotate come qualsiasi utente e proprietario della configurazione che ti piace!

— dayer4b
fonte