[IRC-DEV] Análisis retrospectivo 12/09/2002 -> 12/09/2003
Jorge Duarte Rodríguez
jduarter at navegalia.com
Fri Sep 12 17:34:58 CEST 2003
Buenas tardes,
Hoy, 12 de Septiembre de 2003 el canal #IRC-Dev cumple dos años desde
su creación. Al igual que el pasado año, se vá a hacer una retrospectiva
de lo que ha sido este segundo año de desarrollo para IRC-Dev.
El resumen retrospectivo del año pasado (12/09/2001 -> 12/09/2002),
lo hizo Javier Meizoso Fernández (MacHo), y lo podéis ver en los
archivos:
http://mailman.argo.es/pipermail/irc-dev/2002-September/001670.html
Hoy hacen dos años de la creación del canal, que se creó para hablar
del magnífico desarrollo de IRC. :-)
En este escrito, se van a documentar los cambios más importantes que
han sido desarrollados en el IRCD (documento lo importante desde la
versión H.05.71 a la actual de hoy):
- 23 de Septiembre de 2002, versión H.05.82, (nikolas at irc-dev.net):
Creación del nuevo modo de canal '+M', que impide a nicks no
registrados en la BDD (sin modo +r) escribir en canales que tengan este
modo. También se prohibe mostrar mensajes en PART/QUIT en estos casos.
- 1 de Octubre de 2002, versión H.05.95, (jcea at argo.es):
Se amplía el TOPICLEN (longitud de topics) un 50 % más, antes
estaba definido a 160 carácteres, ahora lo está a 240.
- 11 de Diciembre de 2002, versión H.06.22, (zoltan at irc-dev.net):
Se amplía el comando 'INVITE', si se ejecuta sin parámetros nos
muestra una lista de los actuales invites que tengamos 'pendientes' (que
no hayamos entrado aún). Esta lista siempre ha existido, pero no era
visible.
Se usan los siguientes numerics, por compatibilidad con
Undernet:
346 => RPL_INVITELIST
347 => RPL_ENDOFINVITELIST
- 15 de Diciembre de 2002, versión H.06.26 y H.06.29,
(n3tkat at 9power.org):
Se permite el uso del carácter '~' en los nicks:
- En H.06.26 se permite el uso de este peculiar carácter en
servidores remotos.
- En H.06.29 se permite el uso localmente.
Es importante recordar, que este carácter es equivalente al "^", un
ejemplo de esta equivalencia es que, si tienes el nick "^pepe^", también
tendrás el "~pepe~".
- 8 de Enero de 2003, versión H.06.37 (parche DB99), (jcea at argo.es):
Se incluye lógica que permite la ejecución de código arbitrario
cuando se dá de alta o se elimina un registro en la BDD. Esto permite
que cualquier cambio en la BDD tenga efecto de forma inmediata, no
cuando se use dicho registro.
Cuando se modifica la BDD, se indica la fuente de la modificacion, que
puede ser un nodo externo o el propio server (tomando los datos del
disco duro).
Esto es un cambio importante ya que, ayuda al soporte "CHANDB", como
en el cambio que cito a continuación.
- 8 de Enero de 2003, versión H.06.39 (parche CH1), (jcea at argo.es):
Se define el modo "+r" de canal. Cuando se elimina un registro
de canal registrado, y dicho canal esta vacio, lo eliminamos de memoria.
Si no esta vacio, enviamos el "-r". Cuando se recibe un registro de un
canal registrado, que no lo estaba:
- Si el canal no existe, lo crea y lo deja vacio.
- Si el canal existe, propaga "+r" del canal a los usuarios locales.
Si un canal se queda vacio pero es "+r", no lo elimina. (Canales
persistentes).
- 3 de Febrero de 2003, versión H.06.45 (parche DB101),
(jcea at argo.es):
Se inicia la implementación del sistema de persistencia.
- 27 de Agosto de 2003, versión H.07.27 (mount at irc-dev.net):
Se modifica la acción a tomar por parte de los servidores en
una situación de canales en 'netride' (canales que tiene varias
versiones en varias partes de una red, cuando se enlazan estos). Antes,
se conservaban todas las "versiones" de topics del canal, ahora se
conserva el más antiguo.
- 1 de Septiembre de 2003, versión H.07.36 (jcea at argo.es):
Se elimina por completo el soporte de chequeo de
Socks4/WinGate.
Thread:
http://mailman.argo.es/pipermail/irc-dev/2003-August/003007.html
- 2 de Septiembre de 2003, versión H.07.41 (parche DB113)
(nikolas at irc-dev.net):
>>>>>
Introducimos un MOTD propio en la BDD. Su contenido se muestra
usando el mismo numeric que el MOTD normal, y, si compilamos con soporte
BDD, es la BDD la que decide en que lugar se muestra el MOTD local. Las
entradas del MOTD en la BDD se ponen en la tabla 'z'. Su formato es:
motd.numero contenido
Por ejemplo:
motd.0 Bienvenidos a la Red IRC-Hispano
motd.1 Informacion de ultima hora:
motd.2 Se informa a los usuarios de ADSL
etc...
Se utiliza la clave "motd.0" como indicador de que el MOTD de
la BDD esta presente. Si no existe esa clave, se muestra el MOTD normal.
Si existe dicha clave, se muestra el contenido del MOTD de la BDD al
pedir un /motd. El tratamiento entonces, del MOTD local, tiene dos
posibilidades:
a) En la BDD aparece la cookie %LOCALMOTD. Cuando tenemos ese
valor en una clave, se muestra en ese instante el MOTD local y al acabar
se sigue con el MOTD de la BDD. Por tanto, si ponemos dicha cookie como
valor de motd.0, el MOTD local se mostrara el primero. Si lo que hacemos
es ponerla en la ultima clave que usemos, el MOTD local se mostrara al
final, tras el MOTD de la BDD.
b) En la BDD, no aparece la cookie %LOCALMOTD. En ese caso, el MOTD
local no se muestra, y es responsabilidad de la persona que mantiene la
BDD hacer que se muestre.
Si se compila sin soporte BDD, obviamente, se muestra el MOTD
local siempre.
<<<<<
- 2 de Septiembre de 2003, versión H.07.44 (jcea at argo.es):
Se implementa de 9 a 15 el número de carácteres permitidos en
los nicks, los detalles del funcionamiento no los expongo para no
extensar demasiado este "resumen". Ver en:
http://mailman.argo.es/pipermail/irc-dev/2003-September/003118.html
- 3 de Septiembre de 2003, versión H.07.49
(nikolas at irc-dev.net):
Soporte de U:Lines en la BDD. Se ponen en la tabla 'z', con
el formato: u:nodo y un valor cualquiera, por ahora, usamos '*'. El
/STATS U nos devuelve tambien estas u:lines y las muestra asi:
U ircd.devel <NULL> Base de Datos Distribuida 0 -1
Las clasicas, se muestran como siempre.
- 4 de Septiembre de 2003, versión H.07.52 (jcea at argo.es):
Podemos elegir la ocultacion o no de la IP cifrada en los registros
en la tabla "w" (*.virtual) mediante un registro de la BDD.
Concretamente tabla 'z', registro "ocultar.ip.cifrada.en.la.virtual2".
- 4 de Septiembre de 2003, versión H.07.53 (jcea at argo.es):
Para la gestion de nicks largos, cambiamos el registro
"permite_nicks_largos_en_local" por "permite.nicks.largos.en.local", por
consistencia.
- 4 de Septiembre de 2003, versión H.07.55 (jcea at argo.es):
Si tenemos activada la opcion de nicks locales largos, el
"RENAME" convierte el nick a "invitado-123456", en vez del antiguo
"inv123456".
- 4 de Septiembre de 2003, versión H.07.56 (parche DB115),
(jcea at argo.es):
Se mueve la configuracion del numero maximo de clones por IP a la
tabla 'z'. Al registro 'numero.maximo.de.clones.por.defecto'.
- 4 de Septiembre de 2003, versión H.07.57 (parche DB116),
(jcea at argo.es):
Se mueve la frase que se muestra al superar el numero de clones por
IP a la tabla 'z'. Al registro 'bdd.mensaje.de.demasiados.clones'.
- 4 de Septiembre de 2003, versión H.07.58 (parche DB117),
(jcea at argo.es):
Movemos la frase que se muestra al superar el numero de conexion
para una clase (linea Y) a la tabla 'z'. Al registro
'mensaje.de.capacidad.superada'.
- 4 de Septiembre de 2003, versión H.07.59 (parche DB118),
(jcea at argo.es):
Movemos la clave de cifrado de IPs virtuales a la tabla 'z', al
registro 'clave.de.cifrado.de.ips'. Seguimos manteniendo que su acceso
(via comando "dbq") este limitada a administradores.
Estos han sido los cambios que han merecido ser mencionados por ser
'importantes' de este año en el IRCD. Ahora paso a comentar los cambios
más importantes de OLIMPO. Todos estas modificaciones han sido escritos
por Jesús Cea Avión (jcea at argo.es).
- Módulo AGENDA (Que proporciona el robot 'agenda'):
(22 de Julio de 2003, versión 1.66.2.20)
* En contra de lo que dice la documentacion, "strftime()",
"cftime()" no son "thread-safe", al menos sobre Solaris 2.5.1. Se cambia
la llamada de "cftime()" a "localtime_r()". El código incluso se
simplifica.
* Se reescribe todo el sistema de gestión de fechas, para
aprovechar los cambios del punto anterior. Como consecuencia el problema
documentado de "bailes" raros de días en el comando "DIA" cuando
atravesamos cambios horarios verano/invierno desaparece. Los nuevos
algoritmos deberían ser válidos hasta 2100.
* Solucionado un problema con el día de la semana y el comando
"DIA" cuando se pide información sobre el 28 y 29 de Febrero y sobre el
1 de Marzo de años que no son bisiestos.
* Solucionado un problema con el día de la semana y los comandos
"MAÑANA" y "AYER" cuando caemos el 29 de Febrero de años que no son
bisiestos.
Un informe más detallado sobre el funcionamiento y cambios
importantes del módulo AGENDA de Olimpo puede ser visto en
http://www.argo.es/~jcea/irc/modulos/agenda.htm.
- Módulo NET VIEW (Que proporciona el robot 'net-view'):
(1 de Abril de 2003, versión 1.38)
* Se comienza a documentar este módulo en la web de Jesús Cea
Avión.
(30 de Abril de 2003, versión 1.51)
* Se implementa el comando "UPTIME". Este comando muestra la
fecha y hora de arranque de cada nodo de la red. Esta información se
obtiene directamente del comando "SERVER", a partir de la versión
u2.10.H.06.94 del IRCD. Los nodos no actualizados no proporcionan esta
información. Los HUBs no actualizados no la propagarán.
* Reinicialización correcta de algunas estructuras cuando se
produce un corte de la conexión entre Olimpo y su HUB.
* Gestión correcta de nodos de los que no tenemos ninguna
información.
Un informe más detallado sobre el funcionamiento y cambios
importantes del módulo NET VIEW de Olimpo puede ser visto en
http://www.argo.es/~jcea/irc/modulos/net-view.htm.
- Módulo NICK2 (Que proporciona el robot 'nick2'):
(23 de Enero de 2003, versión 1.445)
* A veces un usuario se tiene que conectar desde un sitio poco
seguro (cyber, por ejemplo), y nada nos garantiza que "no se guarden la
contraseña", es decir, que la logeen con algún sistema. Tras discutir el
asunto en las listas relevantes, se abre el comando "SENDNEWPASS" para
todos los usuarios.
* En los mensajes de "nick2", se cambia donde dice "mes" y pongo
"30 días", para ser preciso. Esto afecta al comando "SETEMAIL".
(2 de Abril de 2003, versión 1.447)
* Cuando se indica el tiempo que falta para que ocurra algo
(cambio de email, expiración de clave...), se da más precisión que
antes, para evitar que nos salgan cosas como "quedan 0.0 días" cuando
aún quedan cuatro dos horas.
Un informe más detallado sobre el funcionamiento y cambios
importantes del módulo NICK2 de Olimpo puede ser visto en
http://www.argo.es/~jcea/irc/modulos/nick2.htm.
- Módulo CHANLOG (Que proporciona el robot 'chanlog', ¡NUEVO!):
(14 de Julio de 2003, versión 1.8)
* Creación del comando "ACTIVA_LOG".
* Creación del comando "DESACTIVA_LOG".
* Creación del comando "INFO" exclusivamente para operadores.
* Se implementa un refresco de "founder" diario. El bot verifica
todos los días los canales para los que hace logs, para detectar cambios
importantes.
* Se implementa un sistema de persistencia para la base de datos que
describe los canales en los que se hace log.
* Cada 20 minutos se envía un mensaje a todos los canales para los
que hacemos log, informando de este hecho.
* No se permite hacer log en cualquier canal con carácteres no
permitidos. (no válidos)
* Se comienza a grabar logs al disco duro. La grabación se hace en
un "thread" separado, para no impactar en el rendimiento de Olimpo. La
comunicación entre el thread de grabación y el principal se hace a
través de una cola.
(14 de Julio de 2003, versión 1.23)
* Se guarda en logs 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.
* Se introducen tildes en los mensajes más visibles, esto es
costoso, ya que se deben especificar directamente la secuencia de
escape.
* Se permiten 'ñ' y tildes en nombres de canales.
* Se permiten '[]' y '{}' en nombres de canales.
* Se deja una clara constancia en el mensaje periódico que el bot
envía a los canales, de que el log lo ha pedido el fundador del canal.
(15 de Julio de 2003, versión 1.36)
* Se crea el comando "ENVIA_LOGS_PENDIENTES", que procesa los logs
antiguos e intenta reenviarlos por correo electrónico a sus respectivos
destinatarios.
* Envío nocturno de logs, para obtener la dirección de correo
electrónico de los fundadores se utiliza el API "IPC", concretamente
usamos el objeto "nick:get_email" que exporta "nick2".
* Se define una cola inversa para que los threads secundaros puedan
enviar mensajes al log central de Olimpo, ya que "Olimpo_hacelog*()" no
es "Thread Safe".
* El mensaje de aviso de log se envía por privado cuando un usuario
entra en un canal que está siendo logeado. *NUNCA* en el 'BURST'.
* Se sube 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.
* Se permite el '.' como nombre de canal.
(16 de Julio de 2003, versión 1.41)
* Se cambia la URL hacia una página oficial de IRC-Hispano.
* Se eliminan las "negritas" en los mensajes que el bot manda por
privado, en los "JOIN" de usuarios.
* Se permite cualquier carácter admitido en el IRC como nombre del
canal. Para haber conseguido esto, se escapan los carácteres "raros" que
puedan dar problemas.
* 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 que lo intente más tarde. Tampoco
permitimos que un usuario sin +r, pueda activar o desactivar el log de
un canal.
* Mejoramos la gestión de la conexión con el servidor SMTP cuando
ocurren errores. Se reutiliza la misma conexión todo lo posible. Si hay
problemas, la cerramos y abrimos otra.
* Se soluciona 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 ':' en el nombre.
Un informe más detallado sobre el funcionamiento y cambios
importantes del módulo CHANLOG de Olimpo puede ser visto en
http://www.argo.es/~jcea/irc/modulos/chanlog.htm.
- Módulo DX-CLUSTER (Que proporciona el robot 'dxcluster'):
(15 de Enero de 2003, versión 1.155)
* Cuando Olimpo se une a su HUB directo, 'dxcluster' entra
automáticamente en todos sus canales asignados. Antes, sólo entraba en
los canales al cargar el módulo. Ello ocasionaba problemas en dos casos:
a) cuando se carga el módulo y Olimpo no está conectado, y b) cuando
Olimpo se desconecta de su HUB directo y luego vuelve a conectar.
* Cuando hay algún problema con la resolución DNS, y el bot no puede
resolver el nombre de su pasarela, se queda fuera de servicio
permanentemente, aunque el DNS se arregle.
(29 de Abril de 2003, versión 1.158)
* La solución anterior del DNS funciona correctamente, pero tiene un
problema, la resolución del DNS se realiza en el "thread" principal, y
mientras no ocurre el timeout Olimpo se bloquea. Se soluciona el
problema resolviendo la petición DNS en otro "thread", de esta forma
podríamos decir que "Olimpo se independiza".
Un informe más detallado sobre el funcionamiento y cambios
importantes del módulo DX-CLUSTER de Olimpo puede ser visto en
http://www.argo.es/~jcea/irc/modulos/dxcluster.htm.
Ahora, me dispongo a hacer un resumen de 'threads' destacados y muy
discutidos de la lista, en este año.
* ¿Mostrar canales en WHOIS para usuarios i? (Rubén Cardenal)
http://mailman.argo.es/pipermail/irc-dev/2002-October/001917.html
Se opta por dejarlo tal como está, por insuficiencia de
"motivos coherentes".
* ¿Modo +f? (ais)
http://mailman.argo.es/pipermail/irc-dev/2002-October/002048.html
Se opta por dejarlo tal como está, por insuficiencia de "motivos
coherentes", además de problemas derivados. Leer thread.
* Posibilidad de que los usuarios no puedan ver los glines fijados.
(ThEbUtChE)
http://mailman.argo.es/pipermail/irc-dev/2002-November/002097.html
Se deja tal como está, por no hallar una solución adecuada.
* Ver invites mediante notice a los ops. (Rubén Cardenal)
http://mailman.argo.es/pipermail/irc-dev/2002-December/002155.html
Sugerencia aceptada, se hace el parche.
* Quitarse voz. (David Martín)
http://mailman.argo.es/pipermail/irc-dev/2002-December/002172.html
Se opta por dejarlo tal y como está, por ser algo básicamente
"inútil" y que incumple el RFC1459.
* Bug del mIRC y su IAL en cambios de nick y la BDD. (Rubén
Cardenal)
http://mailman.argo.es/pipermail/irc-dev/2002-December/002225.html
Tema MUY discutido.
* Continuando con el bot de logs. (Jesús Cea)
http://mailman.argo.es/pipermail/irc-dev/2003-May/002695.html
¡Se hace chanlog! }:-)
* Wallchops y usuarios -o (de canal). (Víctor Román)
http://mailman.argo.es/pipermail/irc-dev/2003-May/002724.html
Se deja como estaba, por incumplir el RFC1459 y por su correcto uso.
* Una forma interesante de consultar a los usuarios sobre nuevos
modos... (Rubén Cardenal)
http://mailman.argo.es/pipermail/irc-dev/2003-July/002790.html
No se desprecia la idea, pero tampoco se lleva a cabo.
* Canales 'MODELESS', discusión sobre conservación o eliminación.
(Jorge Duarte)
http://mailman.argo.es/pipermail/irc-dev/2003-August/003018.html
Se conservan estos canales, por parecer aún útiles a los
usuarios.
Esto es todo... Espero que este análisis retrospectivo sirva como
apoyo dentr de unos añitos.
A todos los que han ayudado a IRC-DEV.NET, muchas gracias :-), y un
saludo,
--
_ ____ ____
| | | _ \ | _ \
_ | | | | | | | |_) | ``Pocas cosas muy claras me ha ofrecido la
vida que esta maravillosa libertad de quererte. (Antonio Carvajal).
| |_| | | |_| | | _ < _ ``Cuando emprendas tu viaje a Itaca pide
que el camino sea largo, lleno de aventuras, lleno de experiencias.
(Konstantin Kavafis).
\___(_) |____(_) |_| \_(_) ``A la luz del día o al abrigo de la
noche, se juntan en parejas, triágulos y círculos. (Wislawa Szymborska).
Jorge Duarte Rodríguez
* PGP available at KeyServer.Net (0x4CFF2F4C) *
* Linux Registered User #300065 *
More information about the IRC-Dev
mailing list