		*Últimos Cambios*
	Blog personal: El hilo del laberinto

Módulo ChanLog

Última Actualización: 31 de Octubre de 2003 - Viernes

El objetivo de este log es disponer de un sistema "oficial", simple y práctico para que los "founders" que lo deseen puedan realizar log de sus canales, y recibirlos cómodamente por correo electrónico.

Las normas básicas son las siguientes:

Solo se puede activar el sistema de log sobre canales registrados.
El log de un canal SOLO lo puede activar su fundador.
El log de un canal lo puede desactivar su fundador y cualquier oper o admin de la red.
Los canales en los que se está haciendo log serán advertidos convenientemente mediante la presencia del "bot" dentro de los mismos, y notificaciones periódicas del objeto de su presencia en el canal.
Ni yo ni IRC-Hispano damos ninguna garantía sobre la calidad, estabilidad o futura disponibilidad de este servicio, ni sobre su privacidad.
Tanto yo como IRC-Hispano nos reservamos el derecho de desactivar el log de canales concretos.

Preguntas y Respuestas Frecuentes

Algunos enlaces interesantes
- [IRC-DEV] Re: ChanLog, ChanFollower y otras consideraciones
¿Cuál es el formato del log?
Cada línea contiene tres componentes: Un "TimeStamp", el nick del remitente y el texto en sí del mensaje, en bruto y sin procesar.
El "TimeStamp" es un número que indica el número de segundos transcurridos desde el 1 de Enero de 1970 GMT.
¿Por qué se usa un "TimeStamp" en vez de usar algo "estándar" como el formato "[hh:mm]" del mIRC?
En realidad el formato "TimeStamp" es el estándar. El formato del mIRC... es del mIRC :-).
Utilizar "TimeStamp" tiene muchas ventajas:
- Es el formato estándar y universal.
- Es un formato independiente de "zonas horarias" y similares. Es decir, da lo mismo en qué sitio del mundo te encuentres, el "TimeStamp" es siempre consistente y "usable" para todo el planeta. Si generásemos logs en formato "[hh:mm]", lo haríamos con la hora de la España peninsular. Si estás en Canarias o, peor aún, en Hispanoamérica o Nueva Zelanda, nuestro "[hh:mm]" no tendría sentido para tí.
  Enviándote un "TimeStamp" estándar, puedes convertirlo a tu formato "[hh:mm]", respetando tu zona horaria. Es más, el sistema de "TimeStamp" no tiene ningún problema ni sufre de discontinuidades cuando se producen los cambios de horario Verano/Invierno (el famoso "Daylight Time Saving").
- Los "TimeStamp" se pueden comparar directamente unos con otros, aunque hayan pasado décadas entre los diferentes registros y correspondan a diferentes puntos del planeta. Para comparar dos fechas "[hh:mm]" es necesario, en primer lugar, saber si se corresponden a la misma zona horaria. Luego hay que saber si son del mismo día o no.
- La precisión de un "TimeStamp" es de un segundo, y su rango es de décadas. La precisión de "[hh:mm]" es de un minuto, y su rango de 24 horas.
- El formato "TimeStamp" se puede pasar fácilmente a cualquier otro sistema, incluyendo "[hh:mm]", pero al revés no es posible. Por eso este formato es un estándar y "[hh:mm]" no, porque es más general y puede convertirse a otros formatos sin dificultad.
  En mIRC, por ejemplo, puedes obtener la fecha de una línea usando el comando "asctime()". Por ejemplo, escribe "$asctime(1058539474)" en una ventana del mIRC, pulsa luego el tabulador y obtendrás la fecha equivalente en tu zona horaria. En el caso de la españa peninsular saldría "Fri Jul 18 16:44:34 2003".
- Puedes tomar varios ficheros de logs y juntarlos, y tendrás referencias de tiempo consistentes en los "TimeStamp". Eso no ocurre con otros formatos.
Me parece muy bonito lo del "TimeStamp" y sus ventajas, pero los ficheros de logs que me enviais no me sirven para mis programas de análisis y estadísticas
Como ya se ha comentado, convertir un "TimeStamp" a cualquier otro formato es trivial. Si no sabes o no puedes hacerlo, pídele a algún programador novato que te eche una mano.
En lenguaje Python, por ejemplo, se puede hacer algo así para pasar a "[hh:mm]":
```
import sys,time
for i in sys.stdin :
  j=i.find(" ")
  ts=i[:j]
  lo_demas=i[j+1:]
  print time.strftime("[%H:%M]",time.localtime(int(ts))),lo_demas
```
¿Por qué el bot insiste en enviar un mensaje de aviso al canal cuando ya me ha avisado por privado cuando entré en el mismo?
Hacer log en un canal es una decisión muy importante. Para evitar suspicacias o comentarios del estilo de "es que yo no sabía", "es que me engañaron" o "pensé que era otra cosa", es muy importante que el bot haga lo posible por informar al usuario. La aceptación de los logs DEBE ser una decisión consciente y meditada de cada usuario del canal, no algo que el fundador del canal pueda activar sin dar más explicaciones.
El bot envía el aviso al canal cada dos horas. No debería ser un problema.
No basta con los avisos por privado porque:
- Si el cliente de IRC no abre una ventana nueva al bot, podemos perder el mensaje en la vorágine de saludos de entrada de CHAN, scripts de usuarios, etc.
- Si hay "splits" en la red, el bot no envía el mensaje cuando ésta se vuelve a unir.
- Puedes tener un "silence" al bot.
¿Por qué el bot envía un "privado" en vez de un "Notice"?
Los "notices" sencillamente no se ven.
Ver punto anterior sobre la importancia de que el mensaje se vea.
Cuando el bot me envía el aviso, sufro de "flood" o "lag" debido a que me sale el "whois" en la ventana de estado.
Desactiva la opción de hacer whois de forma automática en los privados, en tu cliente de IRC. Es un problema de configuración tuyo, no del bot.
De todas formas esto muy probablemente deje de ser un problema en el futuro. Estamos en ello.
¿Por qué se dice que no se garantiza la privacidad de los logs?. ¿Nos espiais?
En realidad ese comentario tiene como misión el protegerme a mí y a IRC-Hispano.
En este momento (Julio 2003) el bot envía los logs al founder a diario y, seguidamente y de forma inmediata, los borra del servidor. En un momento dado, en mi sistema solo existen los logs del día, que serán enviados por la noche y eliminados. De esta forma me protejo de que "alguien" (tanto IRC-Hispano como un juez) me exija los logs de un determinado canal de hace tres meses. No puedo entregar lo que no tengo.
Pero los logs se envían por correo electrónico, atravesando infinidad de equipos informáticos. Quedan guardados en el buzón del usuario, a disposición de su administrador de sistemas o de cualquier becario contratado y con acceso a esa máquina. Puedo tener un compromiso de seguridad en mi sistema y que se me cuele un "hacker" y acceda a los logs. Pueden ocurrir infinidad de cosas que vulneren la privacidad de los logs.
Es por ello por lo que no puedo garantizar su privacidad, aunque lo quisiera (que lo quiero). Existen demasiados riesgos y la mayoría no están bajo mi control. Por ello prefiero advertir al usuario que si bien hago todo lo posible y más por proteger su intimidad, me es imposible garantizársela al 100%. Ni yo ni nadie puede hacerlo.
En ese sentido me parece cuando menos recomendable advertir de este hecho, para que el usuario sea consciente del riesgo y tome una decisión meditada por sí mismo.
En resumen, los canales que quieran garantizar su privacidad no deberían usar el bot o, al menos, deberían utilizar sistemas criptográficos como BulletProof. En el futuro publicaré un script que permita "descifrar" los logs de canales protegidos con BulletProof, si conoces su clave (el bot NO la conoce y guardaría los logs cifrados).

ToDo

Cuando se desactiva el log de un canal, ¿qué hacemos con los logs que ya tengamos y que no hemos enviado aún por correo electrónico?. Peor aún, si tiempo después se reactiva el log en el canal, al (nuevo) fundador le llegarán los logs antiguos también.
Para certificar que los logs no han sido manipulados, se podría usar algún esquema de firma digital o, al menos, tabla confiable de hashes.
En los mensajes periódicos, poner quién es el fundador del canal.
Permitir enviar los logs a direcciones de correo arbitrarias, pero con la seguridad de que el envío está autorizado.
Script de descifrado de logs BulletProof, si se dispone de la clave correcta.
Afrontar el caso de que el fundador de un canal cambie a un nuevo nick, y que dicho nick no tenga "+r".
Eliminar canales con fundador no "+r".
Poner el tamaño del log en el mensaje de correo electrónico.
Documentar y enlazar herramientas para convertir los logs a formatos más fáciles de manejar para los usuarios finales, como el formato mIRC.

Historia

Los números de versión que se indican se refieren a "commit" en el CVS interno. El número de versión cargado en Olimpo en un momento dado es visible usando el comando "dllist".

14/Jul/03 Versión 1.8
- Creación del comando "ACTIVA_LOG". Hay que tener cuidado de comprobar si se está haciendo log del canal ya, tanto al ejecutar el comando como al completar su proceso tras la respuesta de "chan". Esto es así porque puede haber "lag" y el usuario intenta ejecutar el comando varias veces antes de que llegue la respuesta de "chan".
- Creación del comando "DESACTIVA_LOG". Este comando está disponible para los "opers" de la red y para el usuario que conste como "founder" del canal. El "founder" se toma de la activación del log, y se refresca a diario. No se hace consulta con "chan", para no depender de la presencia de ese bot a la hora de desactivar un log.
  Si hay un cambio de "founder", habrá una ventana durante la que el nuevo administrador del canal no podrá eliminar el log.
- Creación del comando "INFO". Muestra la información de log detallada para un canal concreto. Actualmente muestra quien y cuando activó el log. En el futuro se mostrará más información. Este comando está disponible SOLO para "opers".
- Creación del comando "LISTA". Muestra quien y cuando activó el log en cada canal. Este comando está disponible SOLO para "opers".
14/Jul/03 Versión 1.15
- Implemento un refresco de "founder" diario. Es decir, el bot verifica todos los canales para los que hace log, una vez al día, para detectar cambios de founder, pérdida de registro, etc.
- Implementación del sistema de persistencia para la base de datos que describe los canales en los que se hace log.
  Tenemos cuidado con no hacer actualizaciones innecesarias de la BDD durante el refresco diario de fundadores y estado de canales.
- Como notificaciones de aviso, cada 20 minutos se envía un mensaje a los canales en los que hacemos log, informando de este hecho.
- Para facilitarme la vida a la hora de grabar los logs en disco, configuro una lista de caracteres permitidos en los nombres de los canales. No se hará log en cualquier canal con caracteres no permitidos. El filtro actual es bastante restrictivo, así que informo a la gente que tenga problemas de que me envíe un memo con el nombre de su canal, para ir afinando el filtro poco a poco.
- Grabación de logs a disco duro. La grabación la hago en un "thread" separado, para no impactar en el rendimiento de Olimpo. Esto es importante si, por ejemplo, el almacenamiento de los logs se realiza de forma remota mediante algún protocolo como CORBA.
  La comunicación entre los dos "thread", el principal y el de grabación, se realiza a través de una cola.
14/Jul/03 Versión 1.23
- Guarda en los logs de los canales, información sobre el lanzamiento del bot, su parada, y la activación y desactivación de logs para cada canal. De esa forma queda constancia de quien desactivó un log, por un lado, y de los segmentos horarios en los que el bot no está activo, por estar parado.
- Pongo tildes en los mensajes más visibles. Me resulta costoso porque debo especificar directamente la secuencia de escape.
- Permito tildes y la letra eñe en el nombre del canal.
- Permito los corchetes y las llaves, abiertos y cerrados.
- En el mensaje periódico que mando a los canales, dejo constancia clara de que el log lo ha pedido el fundador del canal.
15/Jul/03 Versión 1.36
- Creación del comando "ENVIA_LOGS_PENDIENTES", que procesa los logs antiguos e intenta reenviarlos por correo electrónico a sus destinatarios. Este comando está disponible solo para mí.
- Envío nocturno de logs.
  Para obtener la dirección de correo electrónico de los fundadores, se utiliza el API "IPC". En concreto se accede al objeto "nick:get_email", que exporta "nick2".
- Dado que la grabación de "Olimpo.hace_log*()" no es "Thread Safe", definimos una cola inversa para que los threads secundarios puedan enviar mensajes al log central de Olimpo.
- El mensaje de aviso de log se envía por privado cuando el usuario hace un "join". ATENCIÓN: No se envían mensajes en el BURST.
- Subo el envío de mensajes globales a los canales a uno cada dos horas, tras media hora de lanzar el bot e inmediatamente se introduce el bot en un nuevo canal.
- Permito el punto en el nombre del canal.
16/Jul/03 Versión 1.41
- Cambia la URL hacia una página oficial de IRC-Hispano.
- Quito la negrita en los mensajes que el bot manda por privado, en el "join".
- Permitimos cualquier carácter admitido en el IRC para el nombre del canal. Aunque originariamente pensé utilizar el nombre cifrado del canal y codificado en hexadecimal o base64, finalmente opto por utilizar un esquema de "secuencias de escape". Es decir, los canales sin caracteres "raros" aparecerán normales en el disco duro, y los que contengan caracteres "raros" aparecerán con dichos caracteres "escapados".
  La secuencia de escape se identifica con un símbolo de dos puntos (":") seguido del código LATIN-1 del carácter problemático, en hexadecimal.
  - Cuando se activa el log de un canal, si dicho canal contiene caracteres "raros", guarda en una estructura de datos adicional el nombre "escapado". Eso permite acceder rápidamente a esa información sin necesidad de regenerarla al vuelo. Adicionalmente, solo habrá sobrecarga en canales con nombres "raros".
  - Cuando se envían los logs al "Thread" de logs, se le envía el nombre correcto.
  - Cuando se están revisando los logs almacenados en disco duro para hacer el envío, "desescapa" los canales donde sea necesario.
  - Los mensajes que se graban en el log respecto a la activación o desactivación del servicio son enviados al fichero de log correcto.
31/Jul/03 Versión 1.54
- Si el fundador de un canal tiene una dirección de correo que no contiene una arroba (son registros históricos), entonces nos negamos a activar el log. Si no se puede comprobar la dirección de correo ("nick2" inactivo), informa al usuario de que lo intente más tarde.
- Si un fundador sin el nick registrado (+r) intenta activar o desactivar el log de un canal, le damos un error apropiado.
- Gestionamos mejor la conexión con el servidor SMTP cuando ocurren errores. Intentamos reutilizar la misma conexión todo lo posible. Si hay algún problema, la cerramos y abrimos otra.
- Solucionado un problema cuando se fuerza el procesado de logs pendientes y no hay nada pendiente para enviar.
- Solucionado un problema con la "deserialización" de canales que contienen el carácter de dos puntos (":") en el nombre.
- Corregido un inexcusable error ortográfico en la documentación. Gracias a Macho por señalármelo.
25/Sep/03 Versión 1.61
- Cuando el fundador de un canal es "CReG", se debe desactivar el log para dicho canal, porque su fundador real ya no existe.
- A la hora de volcar las estructuras de datos internas a este módulo, usamos un formato binario, más eficiente y más rápido.
- El último mensaje de log enviado permanece en memoria hasta que se envían mensajes nuevos. Cambio esto para que se libere la memoria tras el envío de cada mensaje de log.
- Envío los mensajes de log comprimidos en formato "ZIP", que debe ser lo más universal que hay. Ponemos mucho cuidado en enviar los "saltos de línea" (formato UNIX) como "retornos de carro"+"saltos de línea" (formato MSDOS).
02/Oct/03 Versión 1.78
- A cada canal se le asigna un "TimeOut". Dependiendo de si existe un "Token" o no para ese canal, hay dos significados:
  - Si existe, significa que el canal está esperando una confirmación. Si nos pasamos del "TimeOut", se elimina canal del sistema de logs.
  - Si no existe, estamos esperando un tiempo hasta solicitar la próxima confirmación. Cuando transcurre ese tiempo, asignamos un nuevo "TimeOut" para el canal y le generamos un "Token", pasando al estado descrito en el punto anterior.
- El tiempo de descanso entre confirmaciones es aleatorio, entre 30 y 40 días.
- La ventana para confirmar un canal en el que ya se hace log es de 7 días.
- La ventana para confirmar un canal con log nuevo es de 24 horas.
- Cuando se lanza por primera vez esta versión de chanlog, todos los canales son marcados como en proceso de renovación.
- Cuando se realiza el envío de logs, damos de baja los canales que no se han confirmado dentro de plazo. Ponemos buen cuidado en no grabar la base de datos tras eliminar cada canal, sino una única vez al final de la operación.
  En realidad en este momento se guarda la base de datos dos veces: la primera vez cuando se revisan las expiraciones y se asignan nuevos "tokens" y cambios de modo a los canales, y la segunda vez cuando se eliminan los canales expirados. Esto es algo que debo mejorar en el futuro.
- Buscamos el objeto "nick:get_email" una vez por operación de envío, no en el envío de cada canal.
- Si un canal está pendiente de renovación, lo señala así en el mensaje de log enviado, indicando el comando concreto que debe ejecutarse para proceder a la renovación. Se indica también cuánto tiempo nos queda para completar la operación, antes de que se deje de hacer log del canal.
- Añado el comando "CONFIRMA", para confirmar periodicamente el log de canales.
- Cuando se activa el log en un canal, se indica al fundador que debe confirmarlo en las próximas 24 horas.
02/Oct/03 Versión 1.78
- Amplío el comando "INFO" para que informe de cuánto queda para la próxima petición de confirmación de un canal o, si ya está en ello, cuánto tiempo le queda al usuario para completar el proceso.
- El envío de logs no funciona correctamente para canales con caracteres no habituales, que hay que "escapar". Simplemente no se enviaban. Solucionado.
- En los canales del punto anterior, los mensajes se envían con un "subject" y un nombre de fichero ZIP incorrecto. Solucionado.

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS