Logrotate ne lit plus le fichier de configuration de lien symbolique en raison de la propriété non root

15

Nous effectuons actuellement une mise à niveau d'Ubuntu 12.04 LTS vers 14.04 LTS sur nos serveurs d'applications ruby on rails, et nous avons remarqué que les fichiers journaux ne tournent plus.

Sur les deux machines, nous avons un fichier /var/app-name/config/logrotateappartenant à notre utilisateur Unix deployerqui contient un fichier logrotate valide comme suit:

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

Celui-ci est ensuite lié dans le /etc/logrotate.d/répertoire en tant queapp-name

Sur notre serveur Ubuntu 12.04, nous avons logrotate 3.7.8 qui fonctionne très bien. Il va dans le var/app-name/log/répertoire et fait tourner tous les fichiers journaux

Mais sur le serveur Ubuntu 14.04, nous avons logrotate 3.8.7 qui ne fait pas tourner les fichiers journaux pour notre application.

Lorsque je débogue ceci via sudo logrotate -d -f /etc/logrotate/.confj'obtiens la sortie suivante:

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

En poursuivant cela dans le code, il semble que cette modification ait été ajoutée pour le flux de version 3.8.x: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

Si je change la propriété du fichier lié /var/app-name/config/logrotateà rootalors il recommence à fonctionner. Mais étant donné que ce fichier fait partie de mon application et créé par le cadre de déploiement capistrano que nous utilisons dans cet état, je préfère ne pas avoir à modifier sa propriété, alors qu'il fonctionnait très bien.

Les fichiers de configuration de liens symboliques sont-ils donc recommandés / pris en charge par logrotate?

Et si c'est le cas, si c'est le refus d'utiliser mon fichier (détenu par deployer) qui est lié par un lien symbolique dans le /etc/logrotate.drépertoire, être considéré comme un bug?

Ou existe-t-il une autre approche recommandée pour la rotation des journaux spécifique à l'application?

(également demandé sur unix StackExchange )

ubuntu permissions logrotate

— baleine
source

Bonne question! Je vois qu'il y a eu une discussion plus tard sur la vérification par rapport au nom d'utilisateur "root" au lieu de uid == 0, mais cela n'a pas non plus déclenché la question de savoir pourquoi la propriété de la racine est requise.

— agtoever

6

Le problème est qu'un fichier de configuration logrotate peut exécuter n'importe quelle commande en tant que root (en utilisant des strophes prérotate / postrotate). Par conséquent, vous accorderiez effectivement à votre deployerutilisateur les privilèges root en lui donnant un accès en écriture aux fichiers dans /etc/logrotate.d/. Donc non, ce n'est pas un bug.

Si vous faites confiance à votre utilisateur déployeur, je suppose que vous pouvez résoudre le problème en lui donnant les droits sudo pour copier des fichiers /etc/logrotate.d/. En supposant, bien sûr, que l'utilisateur déployeur n'est pas le même que celui utilisé par l'application Web.

— pelle
source

Notre approche a toujours été de préférer créer des liens symboliques depuis des répertoires externes à l'application vers des fichiers d'application, de telle sorte que chaque déploiement non seulement repousse la nouvelle application, mais également toute modification du fichier de configuration. Même donner au déployeur les droits de déployer du code en dehors du répertoire d'application viole cette approche - mais avoir également à chown un fichier d'application pour être détenu par root après le déploiement semble également être une mauvaise chose (tm). Peut-être que l'approche originale ne peut plus fonctionner correctement avec logrotate 3.8.0+

— phantomwhale

2

@phantomwhale Votre approche originale a implicitement donné à votre utilisateur déployeur des privilèges root complets. Ce n'est pas nouveau dans logrotate 3.8. Si vous souhaitez restreindre les droits du déployeur tout en lui permettant de mettre à jour la configuration, je pense que vous devez utiliser autre chose que logrotate.

— pelle

2

Je me rends compte que je suis un peu en retard à la fête, mais j'avais un problème similaire et j'ai pensé partager ma solution.

Mes problèmes ont commencé quand logrotateje n'ai pas lu la configuration que j'avais écrite. Je ne voulais pas déployer de nouvelles configurations dans un dossier appartenant à root parce que je ne voulais pas que l'utilisateur de déploiement ait un accès root à quoi que ce soit .

Au début, j'ai essayé de courir en logrotatetant qu'utilisateur de déploiement, mais il s'est plaint d'avoir accès au fichier d'état à l'adresse /var/lib/logrotate/state. J'ai ensuite lu la page de manuel. Vous pouvez spécifier le fichier d'état qui logrotateutilise! Donc, il m'a semblé une meilleure solution pour configurer un cron quotidien à exécuter en logrotatetant qu'utilisateur de déploiement avec un fichier d'état personnalisé. De cette façon, aucun accès root n'est requis par l'utilisateur de déploiement ou l'application.

Voici comment vous spécifiez le fichier d'état:

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

Vous pouvez maintenant exécuter logrotate comme n'importe quel utilisateur et propriétaire de configuration que vous aimez!

— dayer4b
source