Tengo problemas con los comandos que le indican a nginx que use nuevos archivos de registro. Estoy usando Ubuntu 18.04, nginx/1.14.0, logrotate 3.11.0
Si creo archivos nuevos access.logen error.log/var/log/nginx, ya sea manualmente o mediante logrotate, no se usan y en su lugar el servicio usa los archivos de registro antiguos (a los que he cambiado el nombre access.log.1para esta prueba, simulando lo que hace logrotate).
Probé los siguientes comandos (por separado). Ninguno de ellos produce ningún mensaje de error, todos producen el resultado esperado. Pero nginx se niega a dejar de utilizar los registros antiguos.
service nginx rotate
invoke-rc.d nginx rotate
kill -USR1 `cat /var/run/nginx.pid`
También verifiqué que el .pidarchivo anterior esté en el lugar correcto.
La única forma en que he podido hacer funcionar la rotación de registros es a través de service nginx reload, que hace el trabajo, pero también recarga los archivos de configuración. Sé que no hay tiempo de inactividad con una recarga, pero aún así prefiero recargar lo menos posible y es por eso que quiero ponerme a service nginx rotatetrabajar.
Estoy casi seguro de que se debe a problemas de permisos en /var/log. Recientemente, hemos configurado un cronjob para garantizar que los archivos de registro tengan permisos seguros. Esto fue para una auditoría, ya que la empresa pentest sugirió varias medidas de seguridad con respecto al registro. El cronjob que configuramos se ejecuta al arrancar:
#!/bin/bash
setfacl -Rm u::rwx,g::r--,o::--- /var/log
find /var/log -type f -exec chmod g-wx,o-rwx "{}" + -o -type d -exec chmod g-w,o-rwx "{}" +
chmod g+wx /var/log
chown -R www-data:adm /var/log/nginx
Estos son los permisos de los directorios y archivos relevantes después de ejecutar el cronjob:
El directorio /var/log en sí:
drwxrwx--- 14 root syslog 4096 Aug 27 10:01 log
El directorio /var/log/nginx en sí:
drwxr----- 2 www-data adm 4096 Aug 24 02:25 nginx
Y el contenido de /var/log/nginx (usamos registros con nombres personalizados en nuestra configuración de nginx):
-rwxr----- 1 www-data adm 0 Aug 24 02:24 access.log
-rwxr----- 1 www-data adm 108 Aug 24 02:24 error.log
-rwxr----- 1 www-data adm 49317 Aug 27 10:11 x3nr0s.access.log
-rwxr----- 1 www-data adm 798 Aug 27 10:02 x3nr0s.error.log
Si ejecutamos logrotate --force /etc/logrotate.d/nginx -v(detalladamente), o incluso un manual touchpara crear nuevos archivos, se crean con 640 permisos (según el archivo de configuración de logrotate). Por lo que he leído con 640 es suficiente:
-rwxr----- 1 www-data adm 0 Aug 24 02:24 access.log
-rw-r----- 1 www-data adm 0 Aug 27 10:13 error.log
-rwxr----- 1 www-data adm 1972 Aug 27 10:13 error.log.1
-rw-r----- 1 www-data adm 0 Aug 27 10:13 x3nr0s.access.log
-rwxr----- 1 www-data adm 51521 Aug 27 10:13 x3nr0s.access.log.1
-rw-r----- 1 www-data adm 0 Aug 27 10:13 x3nr0s.error.log
-rwxr----- 1 www-data adm 798 Aug 27 10:02 x3nr0s.error.log.1
Como puede ver, los archivos nuevos permanecen vacíos y el registro continúa en el archivo antiguo. También verifiqué la salida detallada de logrotate y todo parece estar funcionando bien con respecto a la sección postrotate. (Que se ejecuta invoke-rc.d nginx rotate. Como mencioné anteriormente, este comando no parece rotar nada...)
Como última prueba, intenté otorgar al usuario permisos de ejecución para los nuevos archivos e hice un archivo service nginx rotate. Aún así, nginx usa los archivos antiguos. Algunas otras respuestas mencionan verificar si el espacio en disco está lleno. No lo es.
¡Agradecería ayuda con esto! Gracias.
Informacion adicional
Aquí está mi configuración de /etc/logrotate.d/nginx:
/var/log/nginx/*.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 www-data adm
sharedscripts
prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi \
endscript
postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
endscript
}
Como se mencionó anteriormente, la única manera de lograr que logrotate y nginx funcionen correctamente con los nuevos archivos de registro es reemplazando la postrotatesección con service nginx reload.
Aquí está el resultado de ps -ef | grep nginx:
root 1367 1 0 10:45 ? 00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 1368 1367 0 10:45 ? 00:00:00 nginx: worker process
www-data 1369 1367 0 10:45 ? 00:00:00 nginx: worker process
www-data 1370 1367 0 10:45 ? 00:00:00 nginx: worker process
www-data 1371 1367 0 10:45 ? 00:00:00 nginx: worker process
root 15247 14835 0 11:19 pts/0 00:00:00 grep --color=auto nginx
Aquí está el getfacl/var/log:
# file: var/log
# owner: root
# group: syslog
user::rwx
group::rwx
other::---
Y aquí está el getfacl/var/log/nginx:
# file: var/log/nginx
# owner: www-data
# group: adm
user::rwx
group::r--
other::---
Respuesta1
Es /etc/logrotate.d/nginxel predeterminado y debería funcionar.
Sin embargo, cambiar el postrotate.dcomando para forzar a nginx a recargar su configuración (y usar el nuevo archivo de registro)
service nginx reload >/dev/null 2>&1
podría ser una solución rápida.
A menudo, cuando un servicio que normalmente funciona no puede crear, abrir, cambiar el nombre o cambiar un archivo, los derechos de acceso están involucrados.
Aquí los accesos se han cambiado (por razones de seguridad), pero la acl predeterminada también debería funcionar/segura, sin involucrar setfacllo cual es poderoso, pero no aparece inmediatamente cuando se usan las lsopciones predeterminadas.
La acl predeterminada es, por/var/log
drwxrwxr-x 18 root syslog 4096 Aug 27 07:25 /var/log/
y el nginx predeterminado (en realidad) es
drwxr-x--- 2 www-data adm 4096 Aug 27 07:25 /var/log/nginx/
nginxEstá bien, /var/logpodría ser un poco más ajustado.
drwxrwx--x 18 root syslog 4096 Aug 27 07:25 /var/log/
que permiten othersvisitar el directorio (y más abajo) pero les impiden enumerar el contenido.
En cuanto a facl, el getfaclcomando enumerará cuáles son las ACL reales agregadas para /var/logy , /var/log/nginxlo /var/log/nginx/*que podría revelar un problema.
Por cierto, haz también un
dpkg-statoverride --list
para verificar qué ACL establecerá el instalador después de una actualización o instalación, y tal vez cambiar o agregar una línea si es necesario (hombre dpkg-statoverride)