Logrotate ya no lee el archivo de configuración de enlace simbólico debido a la propiedad no root

15

Actualmente estamos actualizando Ubuntu 12.04 LTS a 14.04 LTS en nuestros servidores de aplicaciones ruby on rails, y hemos notado que los archivos de registro ya no están girando.

En ambas máquinas tenemos un archivo /var/app-name/config/logrotatepropiedad de nuestro usuario de Unix deployerque contiene un archivo logrotate válido de la siguiente manera:

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

Esto luego se enlaza simbólicamente al /etc/logrotate.d/directorio comoapp-name

En nuestro servidor Ubuntu 12.04 tenemos logrotate 3.7.8 que funciona bien. Entra en el var/app-name/log/directorio y gira todos los archivos de registro

Pero en el servidor Ubuntu 14.04 tenemos logrotate 3.8.7 que no rota los archivos de registro para nuestra aplicación.

Cuando depuro esto a través sudo logrotate -d -f /etc/logrotate/.conf, obtengo el siguiente resultado:

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

Persiguiendo esto en el código, parece que este cambio se agregó para la secuencia de lanzamiento 3.8.x: https://github.com/demands/logrotate/commit/b8ce386a969c60e5c8ee78023c24a1ba0aab1526

Si cambio la propiedad del archivo vinculado /var/app-name/config/logrotatea, rootentonces comienza a funcionar nuevamente. Pero dado que este archivo es parte de mi aplicación, y creado por el marco de implementación de capistrano que usamos en este estado, prefiero no tener que alterar su propiedad, cuando solía funcionar bien.

Entonces, ¿los archivos de configuración con enlaces simbólicos son recomendados / admitidos por logrotate?

Y si es así, ¿debería verse como un error el deployerrechazar el uso de mi archivo (propiedad de ) que está enlazado en el /etc/logrotate.ddirectorio?

¿O hay otro enfoque recomendado para la rotación de registros específicos de la aplicación?

(también preguntado en unix StackExchange )

ubuntu permissions logrotate

— Phantomwhale
fuente

¡Buena pregunta! Veo que hubo una discusión más adelante sobre la verificación del nombre de usuario "root" en lugar de uid == 0, pero también eso no provocó la pregunta de por qué se requiere la propiedad de root.

— agtoever

6

El problema es que un archivo de configuración logrotate puede ejecutar cualquier comando como root (usando estrofas prerotate / postrotate). Por lo tanto, efectivamente estaría otorgando a su deployerusuario privilegios de root al darle acceso de escritura a los archivos /etc/logrotate.d/. Entonces no, no es un error.

Si confía en su usuario de despliegue, entonces supongo que podría resolver el problema otorgándole los derechos sudo para copiar archivos /etc/logrotate.d/. Asumiendo, por supuesto, que el usuario implementador no es el mismo usuario con el que se ejecuta la aplicación web.

— pelle
fuente

Nuestro enfoque siempre ha sido preferir el enlace simbólico de los directorios externos a la aplicación en los archivos de la aplicación, de modo que cada implementación no solo expulse la nueva aplicación, sino también cualquier cambio en el archivo de configuración. Incluso otorgarle al implementador los derechos para implementar código fuera del directorio de la aplicación viola este enfoque, pero igualmente tener que crear un archivo de aplicación para que sea propiedad de la raíz después de la implementación también se siente como algo malo (tm). Quizás el enfoque original por lo tanto ya no puede funcionar bien con logrotate 3.8.0+

— phantomwhale

2

@phantomwhale Su enfoque original implícitamente le dio a su implementador privilegios de root completos. Eso no es nuevo en logrotate 3.8. Si desea restringir los derechos del implementador mientras aún le permite actualizar la configuración, entonces creo que necesita usar algo que no sea logrotate.

— pelle

2

Me doy cuenta de que llego tarde a la fiesta, pero estaba teniendo un problema similar y pensé en compartir mi solución.

Mis problemas comenzaron cuando logrotateno leí la configuración que había escrito. No quería implementar nuevas configuraciones en una carpeta propiedad de root porque no quería que el usuario de implementación tuviera acceso root a nada .

Al principio traté de ejecutar logrotatecomo usuario de implementación, pero se quejó de tener acceso al archivo de estado en /var/lib/logrotate/state. Entonces leí la página del manual. ¡Puede especificar el archivo de estado que logrotateusa! Por lo tanto, me pareció una mejor solución para configurar un cron diario para ejecutar logrotatecomo usuario de implementación con un archivo de estado personalizado. De esta forma, el usuario de implementación o la aplicación no necesitan acceso a la raíz.

A continuación se explica cómo se especifica el archivo de estado:

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

¡Ahora puede ejecutar logrotate como cualquier usuario y propietario de la configuración que desee!

— dayer4b
fuente