cambio atributos de comandos.log

Hola

Estoy teniendo un inconveniente con los procesos en background.
El tema pasa por el cambio en los atributos

-rwxrwxr-- 1 www-data www-data 54346 mar 14 10:27 /guarani3/instalacion/logs_comandos/comandos.log
a
-rwxrwxr-- 1 root root 54346 mar 14 10:27 /guarani3/instalacion/logs_comandos/comandos.log

sin causa aparente.
Alguien tiene alguna idea?
Adjunto logs de auditoria.
Si necesitan mas info…

Emilio


log_auditoria.rar (564 KB)

Buenas Emilio, seguramente cuando corres los comandos administrativos lo haces con el usuario root o con sudo, entonces seguramente cambia ese valor en las carpetas.
Deberías volver a agregar los permisos para el usuario apache para que esto no te pase.

Saludos.

Hola Jose

No es esa la situación.
Ya lo controlé.

Otra idea?

Emilio

Hola Emilio,

no soy muy ducho con esto de leer los logs de SO, menos en el formato de audit… asi que te voy a hacer un par de consultas de lo poco que encontre:

  • Corren via cron los comandos en background?.. fuera de un par de login tuyos, el resto de las entradas validas son de cron.
  • Que usuario tienen especificado en el crontab para esas corridas?, si no le especificaron un usr distinto lo va a ejecutar como root y por ende cambiarte el owner del archivo.
Adjunto logs de auditoria. Si necesitan mas info....
El tema con estos logs es que tienen mucho relleno que dificulta la lectura (todos esos nabos con login attempt failed), ademas el formato no es precisamente algo a lo que estemos acostumbrados o con lo que tengamos experiencia, asi que la info que podemos obtener de ahi es poca en ppio.

Es verdad que para estos casos con el log de php o apache no alcanza… pero bueno, de preferir … .prefiero un journal que es algo que podemos ver con mas cotidianeidad.

Saludos

Hola Richard

Lo unico que se ejecuta con cron es la limpieza de sesiones de php y los mail_notificador cada media hora.

Los comandos de gestion de la base, los ejecuto yo como root. No se ejecutan con cron.

Los comandos de los procesos en background calculo que los ejecuta apache. Ni idea.

y si se te ocurre algo te puedo mandar todos los logs del sistema.
tambien puedo ejecutar lo que necesites cuando detecte un cambio en el archivo.

Emilio

Emilio,
vayamos por partes asi eliminamos opciones

el notificador de mails… por lo que veo de la doc de G3 lo dejan programado en el crontab del usuario actual (si estabas como root en ese momento… por ahi viene),
Opciones:

  • Editar /etc/crontab derecho viejo (si es que esta ahi el comando) y pegarle el usr de apache adelante para que se ejecute con dicho usuario.
  • Eliminar la config actual (del usr que sea) y ejecutar crontab -u www-data -e y luego pegar ahi la linea para enviar_emails_notificador. De esa forma, se ejecuta con el usr de apache
Los comandos de gestion de la base, los ejecuto yo como root. No se ejecutan con cron.
Asumo que vas por psql no?, si es asi.. no problem.

Si vas por guarani o toba xxxx ahi tenes otra fuente posible, pensa que un simple guarani regenerar te modifica ese archivo y si lo ejecutaste como root… ya estas, lo mismo un toba base o guarani x… todo comando por consola, si lo corres como root despues acordate de cambiarle los permisos a la carpeta instalacion para restaurar el owner a Apache.

Igual por como venia el hilo, supongo que no es algo que este sucediendo a consecuencia de una accion manual… de cualquier forma nunca esta de mas.

Los comandos de los procesos en background calculo que los ejecuta apache. Ni idea.
Deberian, shell_exec tiene que ejecutar con los permisos del proceso padre.. salvo que el script a ejecutar tenga fijado SUID, lo que seria loco. Creo que por aca, al menos no hay mucha opcion a que le pegue el cambiaso.
y si se te ocurre algo te puedo mandar todos los logs del sistema. tambien puedo ejecutar lo que necesites cuando detecte un cambio en el archivo.
Mira.. .basicamente ese archivo es escrito por todo comando toba de consola, ya sea que lo corras vos manualmente, cron o que se lance en background desde apache.

Lo que esta interesante saber (ya que tenes la posibilidad de detectar el cambio y si se puede) es que PID lanza el cambio, con lo cual despues podriamos rastrear en audit el nro de proceso y verificar un posible origen. Igual primero vayamos descartando lo mas sencillo asi no nos enroscamos de gusto.

Yo le pongo los porotos al notificador de mails… pero si no llega a ser, seguimos buscando algun patron en la modificacion del mismo.
Por cierto, apache deberia empezar a quejarse en cuanto se le cambia el owner a este archivo… con lo cual rastrear el error_log de apache no estaria de mas tampoco, sabemos que tenemos que buscar especificamente que no puede escribir ese archivo… como para darle un contexto de tiempo tambien.

Saludos

Hola

Estado de situación

Se cambio el cron que ejecuta /guarani enviar_emails_notificador -c 20 para que lo ejecute el apache

Con esto se disminuyó bastante el cambio del owner del comandos.log.
Pero no finalizó.
Hay veces que aparece con owner root.

Lo que creo que puede estar ocurriendo es alguna concurrencia al momento de rotar los logs del guarani.
Sigo con esto pendiente.

Gracias por la ayuda.

Emilio

Hola

Para resolver este problema se armó un script que reestablece los permisos sobre los directorios del guarani.
En el cron, luego de una ejecución guarani… se ejecuta el script anterior.
Y en cada momento que se hace algo manualmente, se ejecuta dicho script.
Con esto se acabaron los problemas.

Emilio