miércoles, 15 de mayo de 2019

Rsyslog: Logrotate

Voy a añadir una opción más a la configuración que hice recientemente para rsyslog. Para poder ver los datos que se envían desde el dispositivo que estamos analizando al servidor de logs correctamente, el hecho de que esté lleno de resultados de hace días no ayuda nada. Para ello se usa logrotate.

¿Cómo lo he configurado? Bien. He encontrado que existe un fichero en /etc/logrotate.conf y otros ficheros dentro de la carpeta /etc/logrotate.d/. De los ficheros que aparecían estaban asteriskdpkgsambarsyslog.

Para forzar a que se cambien los ficheros diariamente para los dos aparatos que me interesa analizar, el SPA3102 y el teléfono Grandstream he incluido las siguientes líneas en el fichero de rsyslog:

/var/log/spa3102.log
/var/log/grandstream.log
{
        rotate 31
        daily
        dateext
        missingok
        notifempty
}

Las notas que puedo hacer al respecto:

  • rotate: número de ficheros que quiero que se me generen.
  • daily: quiero que se hagan diariamente.
  • dateext: concatenar la fecha en los ficheros cuando se copian en vez de usar números.
  • missingok: Por lo que he entendido, si el fichero de log (¿original?) falta, no se genera ningún error.
  • notifempty: no rotar el fichero cuando este esté vacío.

Como no me terminaba de convencer hacer la prueba con todo lo que contiene rsyslog he decidido copiar y pegar la configuración aquí mostrada, sólo para Grandstream, en su propio fichero.

Después de la configuración he ejecutado la siguiente instrucción:

#logrotate -f -v /etc/logrotate.d/grandstream.conf

El resultado, además de rotar ficheros que no se habían tocado en mucho tiempo, es que me ha concatenado al fichero /var/log/grandstream.log la fecha, pero no me ha generado otro nuevo. Si miro su contenido, puedo ver que en dicho fichero se siguen guardando datos. Esto me hace preguntarme: ¿Me concatenará siempre la fecha o será sólo hoy? 

---

Si bien cuando empecé escribiendo este artículo, el sistema no se comportó como esperaba, me esperé unos días más para ver qué sucedía. ¿Qué tengo ahora? 

Ahora sí que tengo los ficheros con su nombre original y sus copias diarias con la extensión de "-aaaammdd" (año, mes, día). El único problema: no se están haciendo en el momento adecuado, por lo que tengo ficheros que dicen que son, por ejemplo, del día 15, que contienen datos del 14 y del 15. :
Así, tengo:
  • grandstream.log-20190515: registros de las 6H del 14 a las 6H del día 15.
  • grandstream.log: a partir de las 6H del día 15.
Ejecutando:

#cat /var/lib/logrotate/status

Es posible ver cuándo se rotó cada fichero. Y, en efecto, las horas cuadran con respecto al desfase mostrado en los logs que necesito analizar. Repasando el comando de más arriba:

#logrotate -dfv /etc/logrotate.d/grandstream.conf

Gracias a que he revisado con más detenimiento el resultado de su ejecución he podido corregir algunos de los ficheros de configuración aquí explicados (pero yo lo muestro sin me avise de errores). 

Con respecto a las horas a las que se produce la rotación ya he encontrado la razón de esa hora tan rara. La rotación se realiza con un cron diario (/etc/cron.daily/). Dentro de esa carpeta, entre otros ficheros, se encuentra el relacionado con logrotate. A su vez, la ejecución de cada uno de los scripts que tiene que lanzar cron, independientemente de que sean diarios, semanales, mensuales... Se hace a través de la configuración que se encuentra dentro de /etc/crontab. Este fichero muestra la hora y minuto que cuadra con la que se muestra en el contenido de los logs al final del más reciente con su extensión de fecha y al principio del que se ha creado.

Lo voy a dejar aquí. Sólo me queda tomar la decisión de dejarlo tal cual, quitar la extensión de fecha (y que me salga la numeración), cambiar la hora para la ejecución de todos los diarios, forzar a que se roten sólo esos ficheros a las 0H (y por lo tanto, al intentar hacerlo de nuevo a las 6H no tendrá efecto)... Ya veré.


Sólo para tener un listado de los distintos sitios que he visitado (y así poder buscar en un posible futuro si es necesario, aunque creo que he perdido alguno):

jueves, 9 de mayo de 2019

Grandstream GXP1405 I: Prensentación

Recientemente me hice con un teléfono VoIP Grandstram GXP 1405, ya deprecated, para incluirlo en mi centralita Asterisk.

Grandstream GXP 1405
Grandstream GXP 1405

Como se puede ver es muy sencillo. Tiene para configurar dos líneas, típico botón de poner el altavoz para manos libres, PoE (si bien también trae una fuente de alimentación), permite conectarle una diadema para hablar por micrófono, la (típica) posibilidad de usarlo de switch para ponerle el PC... Vamos, lo más típico que uno se puede encontrar en un trasto de este tipo en una oficina.

Seguro que puede apreciar en la pantalla LCD hay tres llamadas perdidas de unas cuantas pruebas que estuve haciendo. Eso es porque ya lo tengo configurado. Entre otras opciones permite configuración vía http(s). Desconozco por qué pero ayer mismo me dio problemas y tuve que tirar de https, cuyo certificado no está reconocido, pero para el caso, me sirve. 

La configuración manual de la línea 1, que es la que se corresponde con el usuario de la centralita que le he creado, no fue del todo complicada. La recuerdo muy sencilla, a pesar de que para cada línea ofrece muchas opciones.

Yendo a general settings:

Grandstream GXP 1405 - Menú para acceder a General settings
Grandstream GXP 1405 - Menú para acceder a General settings
Y la configuración es muy sencilla: poner la dirección IP, el nombre de usuario (o extensión), contraseña y listo:

Grandstream GXP 1405 - General settings
Grandstream GXP 1405 - General settings

Una vez apliquemos los cambios y volvamos a la sección de inicio, veremos el resultado que tenemos en el pantallazo: una línea conectada y la otra no. Si hubiese algún problema cuando inicie sesión, evidentemente, se quedará en rojo. 

Como apenas he jugado con el aparato, mientras estaba escribiendo este post me he encontrado con algunas cosas que me las estudiaré para ver si merece la pena escribir sobre ellas.

Además del servidor web tiene otro ssh, pero la shell es un simple menú que apenas deja tres cambios que prácticamente serán para acceder vía web.

Grandstream GXP 1405 - Configuración vía SSH
Grandstream GXP 1405 - Configuración vía SSH
Y así es como tengo un juguetito más que, al menos las pruebas que hice, funciona bastante bien. Esperemos que en un caso real también lo haga. 

sábado, 4 de mayo de 2019

Rsyslog v8: actualización

Hace un tiempo hice un post sobre rsyslog. Ahora que creía que lo tenía activo, me he encontrado con que no era así. Posiblemente porque reinstalé el sistema. Ahora que he querido volver a ponerlo me he encontrado con que la configuración es ligeramente distinta y no me termina de funcionar del todo bien.

Primero: en /etc/rsyslog.conf descomentar:

  • module(load="imudp")
  • input(type="imudp" port="514")
También habrá que asegurarse de que esta línea está descomentada:
  • $IncludeConfig /etc/rsyslog.d/*.conf
Como se puede ver, hasta aquí la única diferencia que hay con respecto a los parámetros antiguos es que ya no se usan "$ModLoad" ni "$UDPServerRun".

A su vez, en /etc/rsyslog.d/ he creado dos ficheros, uno para cada sistema que necesitaba logear. Su contenido:

:FROMHOST-IP, isequal, "_direccion_ip_sistema_" /var/log/_nombre_fichero_.log

& stop

Me he encontrado con un problema: no se me generan los ficheros. Algunas de las cosas que he leído que se podía hacer era ejecutar:

#/etc/init.d/rsyslog rotate

Que a su vez, según he entendido, fuerza a rotar los ficheros de log y a su vez generar los que no estuvieran creados. Pero no han funcionado.

También he querido buscar datos ejecutando rsyslog en modo debug (o eso he entendido al buscar soluciones:

#rsyslog -dn | more

Como son muchas líneas permitirá ver las lineas. Otra opción: mandarlo a un fichero auxiliar y después hacer un pipe ( | ) con grep

Nos permitirá ver que:
  • Se han localizado los ficheros que hemos incluido en /etc/rsyslog.d/ (puedes buscar la cadena "requested to include" o "config parser".
  • El contenido del filtro, al menos de uno de ellos.
Así, se podrá ver si hay algún problema. En mi caso no me ha terminado de ayudar. 

No obstante, uno de los sistemas sí que están guardando datos en /var/log/messages y en /var/log/syslog.

Que se estén guardando datos en estos ficheros para sólo uno de estos sistemas lo único que me indica es que realmente está escuchando. Por lo tanto, tengo que solucionar varios problemas:
  1. Que no se guarden los datos en los otros ficheros: syslog ni messages.
  2. Que se generen los ficheros que quiero.
  3. Que el equipo del los equipos de los que no se están guardando logs sí se guarden.

La verdad, he hecho muchas pruebas con distintos resultados.

En teoría para el número 1 estaba la opción "& stop". Pero como no se generan (generaban), tampoco estoy muy seguro de que esté sirviendo. 

Asegúrate de que la dirección IP del emisor es la correcta ya que en uno de los casos puse la propia del servidor de logs. De las muchas pruebas que he conseguido hacer, he tenido todo tipo de resultados. 

Continuando con la línea "& stop" para solucionar el número 2: he conseguido que se generen los ficheros comentando esa instrucción. Por un lado, hice la prueba de incluir el contenido de los dos ficheros (sin el stop) en la configuración directamente y así sí que se me generaban los dos ficheros. Pero después, si comentaba esas líneas, dejaba de funcionar. 

También hice lo siguiente: reiniciar tirando del cable el equipo que en ningún momento generaba el log. Como no tiene ninguna otra opción para apagar y encender no ha quedado otro remedio que hacerlo así.

Lo extraño: este del que hablo sólo genera el fichero si se reinicia. Aunque se produzca un evento, desconozco el por qué de ese comportamiento.

Como costará entender las soluciones, a ver si las puedo resumir:
  1. Evitar guardar en messages y syslog: A día de hoy no tengo solución viable.
  2. Reiniciar dispositivos si es necesario. Además, aplicar número 3.
  3. No poner "& stop" bajo ningún concepto, al menos para las necesidades básicas.

Aunque juraría que hice pruebas comentando esa línea maldita, no llego a entender por qué habiendo hecho lo mismo que mostré la anterior vez me ha costado tanto hacerlo funcionar.