[IRC-DEV] Actualización "RELEASE CANDIDATE" del IRCD
Jesus Cea Avion
jcea at argo.es
Wed Apr 9 21:10:22 CEST 2003
Por favor, todos los nodos de IRC-Hispano (y redes que utilicen ese
código fuente) que PUEDAN deben actualizar el IRCD a la versión
u2.10.H.06.93 o superior, que es la actualmente disponible en el CVS.
Esta versión nueva incluye dos tecnologías muy novedosas e interesantes,
y que necesitamos probar a fondo. Se trata de "canales persistentes" y
"BDD persistente". Si todo va bien, en unos días se convocará una
actualización OBLIGATORIA en IRC-Hispano.
El procedimiento de actualización recomendado es CVS. Si se usa el
sistema TAR, por favor, asegúrate de que te estás bajando la versión
correcta mirando el fichero ".patches".
Procedimiento: http://www.argo.es/~jcea/irc/ircd10_h_06.htm
Dos detalles:
a) Cuando en la configuración se nos pregunte el tamaño de MMAP caché:
- El valor mínimo recomendado (a fecha de hoy) para plataformas
32 bits es de 16 Mbytes. Se subirá en el futuro.
- El valor mínimo recomendado (a fecha de hoy) para plataformas
64 bits es de 24 Mbytes. Se subirá en el futuro.
- Si tienes disco duro y quieres olvidarte de cambiar este valor
en el futuro, cúrate en salud y selecciona 99Mbytes.
b) Si eres miembro de IRC-Hispano, ve al directorio de instalación
del IRCD y elimina el directorio "database" con todo su contenido.
El formato de la BDD (Base de Datos Distribuido) ha cambiado,
aunque es compatible con los datos antiguos.
Eliminando la BDD local se fuerza un refresco en cuando se produce
el "netjoin" con el resto de la red y los datos que lleguen se
almacenarán en el formato nuevo.
Es importante que toda la red siga el mismo formato para facilitar
la vida a las herramientas que tengo permanentemente a la caza de
inconsistencias entre las BDD de los nodos.
Si su nodo no pertenece a IRC-Hispano, consulte con el personal
técnico de su red.
Cambios desde la última versión obligatoria:
>>>>>
$Id: CAMBIOS2_10_H_06,v 1.87 2003/04/09 15:54:22 jcea Exp $
* 2003/04/09 jcea at argo.es (u2.10.H.06.93)
CLEANUP
-----------------------------------------------------------------------
Limpiamos y simplificamos un poco el codigo de los parches anteriores.
* 2003/04/09 jcea at argo.es (u2.10.H.06.92)
FEATURE
-----------------------------------------------------------------------
Soporte +l-l en canales persistentes.
* 2003/04/09 jcea at argo.es (u2.10.H.06.91)
FIX
-----------------------------------------------------------------------
Completamos el soporte de +k-k en canales persistentes y solucionamos
un par de bugs.
* 2003/04/09 jcea at argo.es (u2.10.H.06.90)
FEATURE
-----------------------------------------------------------------------
Soporte inicial de obligatoriedad o prohibicion de +k en canales
persistentes.
* 2003/04/09 jcea at argo.es (u2.10.H.06.89)
FIX
-----------------------------------------------------------------------
Solucionado un problema en cuando hay bajas en la BDD de canales
persistentes y el MMAP cache falla, al arrancar el programa. Bajo
ciertas circunstancias el canal podia sobrevivir.
* 2003/04/09 jcea at argo.es (u2.10.H.06.88)
FIX
-----------------------------------------------------------------------
Los modos +s y +p son incompatibles, así que:
- Controlamos que no nos lleguen juntos como modos obligatorios.
si es el caso, +s prima.
- Si llega un +s obligatorio, metemos un +p prohibido implicito.
- Idem si lo que llega es un +p.
Adicionalmente, controlamos que no lleguen modos obligatorios y
prohibidos que coincidan. Es decir, no puede aparecer "+s-s" como
modos de canal por BDD. Si es el caso, los modos obligatorios priman.
* 2003/04/08 jcea at argo.es (u2.10.H.06.87)
FIX
-----------------------------------------------------------------------
Algunos problemas introducidos con los parches anteriores, cuando
un canal persistente se convierte a nopersistente y viceversa de forma
repetida.
* 2003/04/08 jcea at argo.es (DB110 - u2.10.H.06.86)
FEATURE
-----------------------------------------------------------------------
Gestionamos cambios de modos controlados de usuarios en canales
persistentes.
* 2003/04/08 jcea at argo.es (DB109 - u2.10.H.06.85)
FEATURE
-----------------------------------------------------------------------
Los canales persistentes pueden tener modos permitidos y prohibidos,
gestionados a traves de la BDD.
Con este parche se empiezan a implementar. De momento solo se tienen
en cuenta cuando llega un registro nuevo por la BDD o cuando se
arranca
desde el sistema de MMAP cache.
*NO* se gestiona aun los cambios de modos de otros nodos o usuarios.
* 2003/04/08 jcea at argo.es (u2.10.H.06.84)
FIX
-----------------------------------------------------------------------
Cuando se hace un "die", hacemos "flush" de las conexiones antes
de meternos con el MMAP cache.
* 2003/04/08 jcea at argo.es (u2.10.H.06.83)
FIX
-----------------------------------------------------------------------
Cuando se hace un "restart", primero completa el MMAP cache, y luego
corta las conexiones con los usuarios, no al reves. Asi no nos
encontramos intentando conectar y la conexion siendo rechazada porque
el servidor esta trabajando en el MMAP cache, grabandolo, y aun
ni siquiera ha reiniciado.
* 2003/04/08 jcea at argo.es (u2.10.H.06.82)
FIX
-----------------------------------------------------------------------
Solucionado un problema con los canales persistentes y los "bounces"
de modos.
* 2003/04/08 jcea at argo.es (DB108 - u2.10.H.06.81)
FEATURE
-----------------------------------------------------------------------
Si en el MMAP cache hay canales persistentes, los procesa cuando se
reinicia el servidor.
* 2003/04/08 jcea at argo.es (u2.10.H.06.80)
FIX
-----------------------------------------------------------------------
Si el MMAP cache parece correcto, pero algun HASH de las tablas nos
detecta algun problema, sen~alamos un MISS.
* 2003/04/08 jcea at argo.es (u2.10.H.06.79)
CLEANUP
-----------------------------------------------------------------------
"/stats b" muestra el taman~o reservado para el MMAP de cache.
* 2003/02/26 jcea at argo.es (u2.10.H.06.78)
CLEANUP
-----------------------------------------------------------------------
Limpieza cuando un nodo se compila sin soporte de persistencia.
* 2003/02/26 jcea at argo.es (u2.10.H.06.77)
FIX
-----------------------------------------------------------------------
Inicializacion correcta de ciertas estructuras en plataformas
de 64 bits.
* 2003/02/25 jcea at argo.es (u2.10.H.06.76)
CLEANUP
-----------------------------------------------------------------------
Limpieza del codigo de persistencia, a favor de maquinas de 64 bits.
* 2003/02/20 jcea at argo.es (u2.10.H.06.75)
FIX
-----------------------------------------------------------------------
Bucle infinito en "/die".
* 2003/02/20 jcea at argo.es (u2.10.H.06.74)
FIX
-----------------------------------------------------------------------
Un par de fixes mas en la persistencia.
* 2003/02/20 jcea at argo.es (u2.10.H.06.73)
FIX
-----------------------------------------------------------------------
Solucionado un problemilla en la generacion y verificacion de la
cache.
* 2003/02/20 jcea at argo.es (u2.10.H.06.72)
FIX
-----------------------------------------------------------------------
Solucionamos un problemilla con el alta de registros nuevos
provenientes
de la red.
* 2003/02/20 jcea at argo.es (u2.10.H.06.71)
FEATURE
-----------------------------------------------------------------------
En el "/stats b" da informacion sobre la memoria que podria liberarse.
* 2003/02/20 jcea at argo.es (u2.10.H.06.70)
FIX
-----------------------------------------------------------------------
Algunos retoques a "portable_stat" ya que en Solaris, por ejemplo,
"st_atime" es un macro.
* 2003/02/20 jcea at argo.es (u2.10.H.06.69)
FEATURE
-----------------------------------------------------------------------
La estructura "stat" de ficheros es portable si nos limitamos a
acceder a los elementos documentados. Pero si lo que estamos es
comparando estructuras directamente memoria a memoria, no es portable
ni podemos especificar campos "internos" de forma portable.
Esto es importante, por ejemplo, a la hora de ignorar el efecto de
"atime" de un fichero. No podemos inicializar ese campo a un valor
fijo de forma portable, porque en Solaris, por ejemplo, nos aparece
un campo de nanosegundos.
Al final opto por definir una estructura "portable_stat" interna
al IRCD, con los campos que queremos, y que son comunes a
todas las plataformas.
* 2003/02/20 jcea at argo.es (u2.10.H.06.68)
FIX
-----------------------------------------------------------------------
Solucionado un problema con "u2.10.H.06.63", donde el estado de un
fichero se sobreescribia de forma incorrecta, provocando un "die"
al realizar la siguiente verificacion.
* 2003/02/20 jcea at argo.es (u2.10.H.06.67)
FIX
-----------------------------------------------------------------------
En el parche "u2.10.H.06.63" tambien hay que tener en cuenta el caso
de truncar la BDD.
* 2003/02/20 jcea at argo.es (u2.10.H.06.66)
FIX
-----------------------------------------------------------------------
Con el nuevo sistema de verificacion de BDD y cache de persistencia,
hacer un "make install" mientras estaba un IRCD funcionando, lo mata,
porque este detecta una modificacion no autorizada de la BDD.
Modifico el script de instalacion para evitar este problema, y
aprovecho para hacer un poco de limpieza.
* 2003/02/20 jcea at argo.es (u2.10.H.06.65)
FEATURE
-----------------------------------------------------------------------
Si todo parece correcto, no hace falta que revisemos la BDD byte
a byte.
* 2003/02/20 jcea at argo.es (DB107 - u2.10.H.06.64)
FEATURE
-----------------------------------------------------------------------
La segunda parte del parche anterior es guardar en la cache de
persistencia la informacion detallada de los ficheros BDD (struct
stat)
y contrastarla con la recarga de la cache, para verificar si hay un
HIT o no.
* 2003/02/20 jcea at argo.es (DB106 - u2.10.H.06.63)
FEATURE
-----------------------------------------------------------------------
Optimizamos la implementacion del sistema de persistencia, en
particular de la verificacion de la cache, cuando se carga.
El primer paso es guardarnos informacion detallada sobre los ficheros
de BDD, para detectar modificaciones sin necesidad de leerlos byte
a byte.
- Carga inicial de la BDD (cuando hay un cache MISS).
- Lectura de la BDD para enviarla en un BURST.
- Escritura de un nuevo registro en la BDD.
- Compactacion de la BDD.
* 2003/02/20 jcea at argo.es (u2.10.H.06.62)
FIX
-----------------------------------------------------------------------
Obtener la informacion sobre la "arena" persistente puede ser una
operacion lenta, asi que solo la damos en un "/stats b" si
el usuario es +o.
* 2003/02/06 jcea at argo.es (u2.10.H.06.61)
FIX
-----------------------------------------------------------------------
Bajo ciertas circunstancias, el sistema de persistencia podia borrar
las BDD.
* 2003/02/06 jcea at argo.es (u2.10.H.06.60)
FIX
-----------------------------------------------------------------------
Solucionados algunos problemas de sobreescritura de memoria.
* 2003/02/06 jcea at argo.es (u2.10.H.06.59)
FIX
-----------------------------------------------------------------------
Solucionado un "assert()" cuando teniamos un "cache HIT".
* 2003/02/06 jcea at argo.es (u2.10.H.06.58)
FEATURE
-----------------------------------------------------------------------
Sigo progresando en la implementacion del sistema de persistencia...
Implemento el almacenamiento de la persistencia. Con esto ya
deberiamos
poder hacer pruebas reales.
* 2003/02/06 jcea at argo.es (DB105 - u2.10.H.06.57)
FEATURE
-----------------------------------------------------------------------
Sigo progresando en la implementacion del sistema de persistencia...
Guarda los "hashes" internos de la BDD en el sistema de persistencia.
Con este parche se supone completada lo que es la "carga" de la
cache de persistencia. Ahora solo quedaria la parte de grabacion.
* 2003/02/06 jcea at argo.es (u2.10.H.06.56)
FEATURE
-----------------------------------------------------------------------
Sigo progresando en la implementacion del sistema de persistencia...
Comprueba que el fichero de "hashes" no haya cambiado respecto
a la actualizacion del fichero de cache.
Guarda en el sistema de persistencia los datos "bookeeping" de la BDD.
* 2003/02/06 jcea at argo.es (u2.10.H.06.55)
FEATURE
-----------------------------------------------------------------------
Un "rehash" no debe recargar la BDD, porque eso es un proceso lento
y lo sera aun mas. Debemos buscar otros mecanismos para comprobar
la integridad de la BDD.
* 2003/02/05 jcea at argo.es (u2.10.H.06.54)
FEATURE
-----------------------------------------------------------------------
Importante optimizacion de velocidad en un "cache MISS".
* 2003/02/05 jcea at argo.es (u2.10.H.06.53)
FEATURE
-----------------------------------------------------------------------
Un par de retoques mas...
* 2003/02/05 jcea at argo.es (u2.10.H.06.52)
FIX
-----------------------------------------------------------------------
Solucionados varios problemas de los parches anteriores.
* 2003/02/05 jcea at argo.es (u2.10.H.06.51)
FEATURE
-----------------------------------------------------------------------
Clarificacion de la evaluacion de si el fichero MMAP de cache para
BDD nos sirve o no, al arrancar.
Cuando se acepta, lo marcamos para que no sea aceptado de nuevo
si el servidor intenta leerlo otra vez sin haberlo volcado nuevamente
a disco. Esto es interesante porque si hay algun problema con el
fichero, y muere el servidor, al volver a arrancar lo volvera a tomar
de nuevo y volvera a morir.
Actualizamos el "/stats b" para que nos diga si hemos tenido un
cache HIT o MISS.
* 2003/02/05 jcea at argo.es (u2.10.H.06.50)
FEATURE
-----------------------------------------------------------------------
Aunque el fichero MMAP de cache para la BDD tiene un taman~o fijo,
permito que la memoria usada dentro de el cambie de longitud. Ello
posibilita definir un fichero muy largo sin penalizar su
carga/descarga
cuando se usa poca memoria, especialmente en lo que se refiere al
calculo del HASH para detectar corrupciones. En vez de generar un HASH
cubriendo todo el fichero, se considera solo lo que realmente se
esta utilizando.
Se modifica "/stats b" para que se muestre el maximo historico
de ocupacion, durante la ejecucion de la instalcia de IRCD actual.
* 2003/02/04 jcea at argo.es (u2.10.H.06.49)
FEATURE
-----------------------------------------------------------------------
Muestra datos sobre el sistema de persistencia en el "/stats b".
* 2003/02/04 jcea at argo.es (DB104 - u2.10.H.06.48)
FEATURE
-----------------------------------------------------------------------
Con este parche el sistema de persistencia esta autocontenido 100%,
incluyendo el "metadata" de "malloc".
* 2003/02/04 jcea at argo.es (DB103 - u2.10.H.06.47)
FEATURE
-----------------------------------------------------------------------
Los registros ya son almacenados en el bloque persistente, aunque
todavia no hacemos que sobrevivan a rearranques del servidor.
* 2003/02/04 jcea at argo.es (DB102 - u2.10.H.06.46)
FEATURE
-----------------------------------------------------------------------
Primera implementacion de "malloc()" persistentes.
* 2003/02/03 jcea at argo.es (DB101 - u2.10.H.06.45)
FEATURE
-----------------------------------------------------------------------
Implementacion minima de la cache de BDD.
* 2003/01/21 nikolas at irc-dev.net (u2.10.H.06.44)
FEATURE
-----------------------------------------------------------------------
En el numeric 252 (ircops, helpers y bots online) cambiamos el orden
en que se envian los contadores de manera que el primero en aparecer
sea el de helpers, por ser mas significativo que el de ircops.
* 2003/01/16 nikolas at irc-dev.net (u2.10.H.06.43)
FEATURE
-----------------------------------------------------------------------
En el tiempo de expiracion de las g-lines se incluye informacion con
la zona horaria.
* 2003/01/09 nikolas at irc-dev.net (u2.10.H.06.42)
FIX
-----------------------------------------------------------------------
Compilando *SIN* soporte BDD se muestra el resumen de modos del
numeric
379.
* 2003/01/09 jcea at argo.es (u2.10.H.06.41)
FIX
-----------------------------------------------------------------------
Corrige algunos problemas para permitir compilar el servidor sin
soporte de BDD.
* 2003/01/08 jcea at argo.es (CH2 - u2.10.H.06.40)
FEATURE
-----------------------------------------------------------------------
Si llega un modo '+r' para un canal a traves de la red (burst o cambio
de modo normal), lo ignoramos.
Cuando un canal pierde '+r', pierde tambien '+S' y '+A'.
* 2003/01/08 jcea at argo.es (CH1 - u2.10.H.06.39)
FEATURE
-----------------------------------------------------------------------
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.
* 2003/01/08 jcea at argo.es (DB100 - u2.10.H.06.38)
FEATURE
-----------------------------------------------------------------------
A la hora de normalizar las claves de la BDD, permite lógica distinta
segun la tabla de que se trate.
Incluyo logica de normalizacion de nombres de canales.
Soporte del canal 'c', de registro de canales.
Ya hay cierto soporte antiguo para el canal 'c', que tengo que evaluar
si sigue siendo correcto o no. Muevo esa logica a la tabla 'z' hasta
poder revisarla despacito y con buena letra.
* 2003/01/08 jcea at argo.es (DB99 - u2.10.H.06.37)
FEATURE
-----------------------------------------------------------------------
Se incluye logica que permite la ejecucion de codigo arbitrario cuando
se da 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).
* 2003/01/07 nikolas at irc-dev.net (u2.10.H.06.36)
FIX
-----------------------------------------------------------------------
Ajuste en el contador de helpers. En exit_client eliminamos el flag de
helper para no volverlo a restar en exit_one_client.
* 2003/01/02 jcea at argo.es (u2.10.H.06.35)
CLEANUP
-----------------------------------------------------------------------
Elimino unos "warnings" en los parches anteriores.
* 2003/01/01 nikolas at irc-dev.net (u2.10.H.06.34)
FEATURE
-----------------------------------------------------------------------
Usuarios con +k se saltan la limitacion de targets y de cambios de
nick
consecutivos.
* 2002/12/31 nikolas at irc-dev.net (u2.10.H.06.33)
FIX
-----------------------------------------------------------------------
Un ajuste mas en el contador de helpers. No se contabilizaban las
salidas por exit_client :)
* 2002/12/31 nikolas at irc-dev.net (u2.10.H.06.32)
FEATURE
-----------------------------------------------------------------------
En un VERSION vemos el numero maximo de canales por usuario. Aparece
tras el valor de CLIENT_FLOOD. Asimismo, chequeamos que su valor este
entre 1-99 (99 < MAXCHANNELSPERUSER > 1).
* 2002/12/31 nikolas at irc-dev.net (u2.10.H.06.31)
FEATURE
-----------------------------------------------------------------------
Nuevo numeric para el WHOIS:
/* 379 */
{RPL_WHOISMODES, "%s :Utiliza los modos [%s]"},
Devuelve las letras de los modos visibles del usuario. El criterio
para
mostrar u ocultar modos es el mismo que para el WHO.
Se ha modificado la funcion umode_str(aClient *cptr), que servia para
calcular la cadena de modos que se envia en un BURST para que acepte
un
segundo parametro: umode_str(aClient *cptr, aClient *acptr), de tal
modo que calcula tambien, si acptr != NULL, los modos de cptr visibles
por acptr.
* 2002/12/26 jcea at argo.es (Z14 - u2.10.H.06.30)
FIX
-----------------------------------------------------------------------
Inicializacion correcta de ZLIB, que podia dar problemas bajo ciertas
circunstancias, incluyendo la caida del servidor.
* 2002/12/16 n3tkat at 9power.org (u2.10.H.06.29)
FEATURE
-----------------------------------------------------------------------
Segunda parte del parche para permitir el ~ en los nicks. Ahora, ya
permitimos su uso de forma local.
<<<<<
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea at argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
More information about the IRC-Dev
mailing list