[IRC-Dev CVS] Module ircdh: Change commited ircdh/doc/history CAMBIOS2_10_06,NONE,1.1 CAMBIOS2_10_07
Brought to you by:
zolty
Menu
▾
▴
[IRC-Dev CVS] Module ircdh: Change commited ircdh/doc/history CAMBIOS2_10_06,NONE,1.1 CAMBIOS2_10_07,NONE,1.1 CAMBIOS2_10_H_01,NONE,1.1 CAMBIOS2_10_H_02,NONE,1.1 CAMBIOS2_10_H_03,NONE,1.1 CAMBIOS2_10_H_04,NONE,1.1 ChangeLog,NONE,1.1 ChangeLog.07,NONE,1.1 ChangeLog.10,NONE,1.1
|
From: Zolty <zo...@us...> - 2002-08-21 17:59:43
|
Update of /cvsroot/irc-dev/ircdh/doc/history
In directory usw-pr-cvs1:/tmp/cvs-serv10291/ircdh/doc/history
Added Files:
CAMBIOS2_10_06 CAMBIOS2_10_07 CAMBIOS2_10_H_01
CAMBIOS2_10_H_02 CAMBIOS2_10_H_03 CAMBIOS2_10_H_04 ChangeLog
ChangeLog.07 ChangeLog.10
Log Message:
2002-08-21 Toni Garcia <zo...@ir...>
* ircd/common.c/.h: Ha sido eliminado.
* ircd/table_gen: La tabla de caracteres que estaba en common.c ha sido colocado
en este nuevo fichero.
* ircd/ircd_string.c/h: Las funciones que estaban en common.c y en support.c
han sido movidos al nuevo fichero. Y se sustituyen en el codigo los
"strtoken" por el nuevo "ircd_strtok".
* Movidos los archivos viejos de "ChangeLog" de Hispano y Undernet al
directorio doc/history. A partir de ahora se documentan los cambios en
este fichero "ChangeLog".
--- NEW FILE: CAMBIOS2_10_06 ---
$Id: CAMBIOS2_10_06,v 1.1 2002/08/21 17:59:40 zolty Exp $
* 1999/11/11 sa...@ap... (patch.db51) FIX
-----------------------------------------------------------------------
Cambiados todos los 'unsigned long' de s_bdd.c a 'unsigned int', pues
en realidad solo necesitamos u_int32_t, y usando 'unsigned long' tenwmos
problemas en arquitecturas de 64 bits. Los mismos cambios en las
funciones que llamaban a tea() en s_user.c
* 1999/11/11 sa...@ap... (patch.vip4) FIX
-----------------------------------------------------------------------
Segun lo decidido, se cambia el algoritmo de criptación de direcciones
al siguiente modelo:
VIRTUAL = TEA( clave, ip<<32 + (clave>>32)&0xffff0000 + n)
Siendo 'clave' el valor que contiene el registro '.' de la tabla de
direcciones virtuales, que se irá cambiando periodicamente.
Este fix permite que los usuarios baneados por dirección virtual no
puedan abusar, conectando de nuevo o cambiando el nick, pues hay una
relación directa entre la dir virtual y la real.
* 1999/10/26 sa...@ap... (patch.dbh15) FEATURE
-----------------------------------------------------------------------
Para facilitar la migración a autentificación por server, creamos una
tabla 't' (residente), que PERMITE que los usuarios se autentifiquen
de la misma forma que los de la tabla 'n'. Si ponen clave, esta ha de
ser la correcta. Si no la ponen les molesta con un par de NOTICEs.
En VERSION del server aparece como DBH15
* 1999/10/15 sa...@ap... (patch.p9hispano) FIX
-----------------------------------------------------------------------
He definido los numeros de nodo P9 para los services en numnicks.c,
dado que n2k ha destruido la "autoasignación" de numeros de nodo para
los P9.
* 1999/10/14 sa...@ap... (patch.dbh14) FIX
-----------------------------------------------------------------------
He modificado la respuesta al /STATS B, para hacerla mas corta y le he
añadido el soporte de las nuevas BDD.
* 1999/10/13 sa...@ap... (patch.xmode2) FIX
-----------------------------------------------------------------------
Arreglado un pekeño bug cosmetico, que ocurria cuando mediante XMODE
intentabamos por ejemplo dar +o a alguien que ya tiene +o, quedando
visible el intento como '+x' sin parametro alguno.
* 1999/10/13 sa...@ap... (patch.dbh13) FEATURE
-----------------------------------------------------------------------
Implemento comando DBQ sustituyendo el DBH de usuario, con el formato:
[<:origen>] DBQ [<server>] <tabla> <clave>
Si <server> existe pero no somos nostros, lo rutaremos al server en
cuestión para que sea él quien contesta. Se acepta server '*' para
broacast y los tipicos comodines 'jupiter.*'
* 1999/10/10 sa...@ap... (patch.vip3) FIX
-----------------------------------------------------------------------
Las desconexiones (QUIT) involuntarios (Ping timeout / Read error) ya
no muestran el hostname del usuario si este tiene el modo +x activo.
El /WHO busca sobre la direccion virtual en lugar de la real en los
usuarios +x excepto si quien mira es un +X, en cuyo caso mira en ambas.
* 1999/10/05 sa...@ap... (patch.vip2) FEATURE
-----------------------------------------------------------------------
Se cambia el modo de trabajo de /WHOIS y /WHO para que lo hagan segun
sugerencias de jcea. El propio usuario se ve a si mismo como lo haria
un +X. Y la primera linea (311) de WHOIS da el host real y en la linea
codigo 378 informamos de la dirección virtual.
* 1999/10/05 sa...@ap... (patch.dbh12) FIX
-----------------------------------------------------------------------
Las nuevas funciones base64toint() que han introducido en el parche de
undernet8 necesitan tener completamente rellenado el string, antes se
conformaban con tener \0's al final. Lo correcto es tal como lo han
dejado en esta versión, pero es incompatible con lo anterior.
Solución: a las claves cortas se les añaden tantas 'A' al final como
sea preciso.
* 1999/10/05 sa...@ap... (patch.dbh11) FIX
-----------------------------------------------------------------------
Al introducir el parche de undernet8 y posteriores, se nos pasó cambiar
el %c%c%c por %s%s para imprimir el nick numerico extendido en el
comando BMODE. Se ha optimizado el modo de delimitar el final de de
cadenas en las modificaciones introducidas en la autenticación usuario.
Se han cambiado los %c a %s en protocolos DB y DBH para uso correcto de
la macro NumServ(). Puestos a arreglar, el make install crea con los
permisos adecuados las tablas DBH.
* 1999/09/14 sa...@ap... (patch.vip) FEATURE
-----------------------------------------------------------------------
Se introducen dos nuevos flags de usuario: +x y +X, el primero oculta
la dirección ip(o hostname) del usuario y el segundo (+X) permite ver
las direcciónes reales al ejecutar /WHOIS /WHO /USERIP y /USERHOST
Solo los usuarios +r acceden, automaticamente, a +x, pudiendo cambiar
a -x y +x a voluntad mientras perdure el flag +r
Solo los usuarios +o (ircops) y +h (OPERS) pueden activar el flag +X
El formato de las direcciones es @GaRaBaTo12Ch.virtual, y este valor
se calcula en todos los servers cuando el usuario activa +x,
guardandose en un campo especifico: User->virtualhost
Si los servers encuentran en la nueva tabla V un registro para el nick
en cuestión, instalan el valor del registro en User->virtualhost,
permitiendo así definir ips virtuales fijas para ciertos usuarios.
El valor del GaRaBaTo12Ch se calcula en make_virtualhost() de s_user.c
y es basicamente:
garabato = base64(tea(tea(nick,password),ip<<32+xyz<<8));
haciendose imposible crear una relación de ips virtuales a reales, asi
como su desencriptación por parte de los usuarios. La unica forma de
conseguir averiguar una ip a partir de una virtual sera analizando los
logs de los distintos servidores de servicios.
he modificado además el codigo refernete a BAN para que acepte ban por
virtual, y el ban a real afecte tambien a los +x.
he cambiado el antiguo codigo 378 (ke ya movimos en su dia) al 380
he ocupado el codigo 378 para que nos indique la ip/host real del user
tal como lo hacen otros daemons de irc. El 379 lo he reservado para
que muestre los modos de usn usuario, como enotras redes, pero esto es
asunto de otro parche.
El comando /TRACE solo será accesible a Opers +o y HelpOps +h, antes
era accesible a todos. Este comando no oculta IPs.
No puedo considerar el codigo terminado, la version queda reflejada
como VIP+, activandose en el configurador dentro de la sección HISPANO,
siendo desactivable por si nos da problemas.
* 1999/09/14 sa...@ap... (patch.no_whois_secret) UNFEATURE
-----------------------------------------------------------------------
Elimina completamente el parche patch.whois_secret
* 1999/07/31 sa...@ap... (patch.dbh10) FIX
-----------------------------------------------------------------------
Corrección del BMODE, pues se producian algunos desynch.
Lo he simplificado, y para ello he tenido que meter un parametro
adicional a set_mode(), que se usa en m_botmode (1) y m_mode (0).
Si el parametro es 1 (BMODE), se hace badop=0, bounce=0, asi no se queja
nadie. Como el arreglo es en la recepción, sera necesario que este activo
en todos los servers antes de que sea operativo.
Por error, en DBH9 deje abierto a IRCops el comando BMODE, ahora es solo
server-server.
El BURST de p10 no parsea los modos +R+A+S de canal, tb lo he arreglado.
Queda reflejado como DBH10+
* 1999/07/30 sa...@ap... (patch.whois_secret) FEATURE
-----------------------------------------------------------------------
Si asi lo pedimos en la configuración (make config),
OPERS_SEE_IN_SECRET_CHANNELS, el whois les muestra a los IrcOP o +k la
lista de canales secretos (+s) donde esta el usuario
Se documenta en /VERSION como W+/W-
* 1999/07/29 sa...@ap... (patch.dbh9) FEATURE
-----------------------------------------------------------------------
Incorpora el comando SERVER-SERVER BMODE, con formato:
:origen BMODE ChanServ #canal +modos :parametros
ChanServ se busca en la tabla B, y se nos traduce a 'CHaN!^@^', y es lo
que veran los usuarios en los cambios de modos del canal realizados por
los servers (autoops, etc). Para mas info ver codigo m_botmode() en
chammel.c
Modos de usuario:
B -> Modo Bot, permite TODO sobre canales, sin estar dentro,
limitado a los BOTS, no se puede colocar en modo usuario.
Se ha usado un bit de nustro campo Client->hmodes
Modos de Canal:
r -> Canal Registrado (existe en tabla C, no se puede poner/quitar)
R -> Canal Restringido, solo acepta users Registrados
A -> Activacion de autoop para los ke salgan en tabla C
S -> Modo Secure OP (no implementado de momento)
Se han usado 4 bits del campo chptr->modes.modes:
#define MODE_REGCHAN 0x020000
#define MODE_REGNICKS 0x040000
#define MODE_AUTOOP 0x080000
#define MODE_SECUREOP 0x100000
* 1999/07/29 sa...@ap... (patch.noproxy4) FIX
-----------------------------------------------------------------------
Se corrige el tema caida por timeout si tienes el 1080 cerrado sin aviso
mediante firewall. Ahora deja al usuario enganchado 90 segundos antes de
dejarle entrar.
Queda reflejado como PX4+ o PX4- en el /VERSION
* 1999/07/29 sa...@ap... (patch.noproxy3) FIX
-----------------------------------------------------------------------
Se elimina el chekeo de Socks y el de Ident sobre puerto de servers
Queda reflejado como PX3+ o PX3- en el /VERSION
* 1999/07/29 sa...@ap... (patch.dbh8) FEATURE
-----------------------------------------------------------------------
Implementa el nuevo modo de usuario -/+h, conocido en otras redes como
HelpOperator, que vendrian a ser los Oper del irc-hispano.
Este modo (+h) se activa automaticamente si el nick esta registrado y
ademas en la tabla O (de OPERS). Los oper se lo pueden quitar o poner a
su antojo. La unica finalidad del modo +h es aparecer en el /WHOIS
indicando que el usuario es un Operador de Servicios IRC (raw 310)
Ademas mejora la implementacion de los modos automaticos al cambiar
de nick.
* 1999/07/28 sa...@ap... (patch.noproxy2) FIX
-----------------------------------------------------------------------
Algunos cambios cosmeticos en los textos enviados al usuario.
El patch.noproxy no compila modo DEBUG, este lo arregla.
Queda reflejado como PX2+ o PX2- en el /VERSION
* 1999/07/28 sa...@ap... (patch.noproxy) FEATURE
-----------------------------------------------------------------------
Implemento un checker de Socks4-Proxies (wingates incluido).
La implementación esta en s_socks.c y s_socks.h, pero ha sido necesario
tocar ligeramente s_bsd.c, ircd.c y s_res.c. En la estructura Client de
struct.h he añadido el campo socksfd en la parte extendida de clientes
locales. En s_bsd.h he creado las macros y usado un par de bits del
campo client->hmodes.
Implementacion:
- Llega conexion nueva
- Se lanzan en paralelo los checkers de DNS, ident y proxy
- Se atiende al user cuando los tres han finalizado
Cuando lanzamos el cheker de proxy, este se intenta conectar al puerto
de socks4 del usuario (1080), si lo consigue, mediante protocolo socks4
le solicita al proxy que habra una conexion a la direccion/puerto del
ircd que el usuario ha conectado. Se analiza la respuesta de socks4 y
si nos confirma la conexión, es un proxy abiero y lo desconectamos del
irc informandole de la causa.
Mientras se hace el proceso de checking de Proxy, el server envia unos
NOTICE al usuario para que vea lo que le está haciendo. He tenido que
usar writes directos al cptr->fd, pk al no estar registrado el usuario
en el momento del cheking, no podia usar las colas de salida.
Esta opcion se puede activar/desactivar (PROXY_PROTECTION) en el make
config, siempre que hayamos seleccionado DB_HISPANO. Queda reflejado
en el /VERSION como PX+ o PX-
* 1999/07/21 sa...@ap... (patch.DBH6) FIX
-----------------------------------------------------------------------
Cambia la forma de trabajo del flag +r, impidiendo que el user
se lo quite, y (des)activandose solo ante autentificacion, y no ademas
por la llegada de un registro DBH, como hasta ahora.
Introduce algunos cambios cosmeticos en la consulta de la BD
(comando DBH en modo user).
Como estaba mirando la causa de que los DBH2 regalen modos +k a
los users, he cambiado a logica positiva la parte del condicional que
hace que NO sea aceptado el modo +k cuando:
- no lo tenias y no eres server y no eres ircop
y no (estas registrado y estas en la DB de OPERS)
en lugar de la equivalente pero menos inteligible:
- no lo tenias y no eres server y no eres ircop
y (no estas registrado o no estas en la DB de OPERS)
Aunque el bug quedo solucionado en DBH3.
Puestos a arreglar, añado el DBPATH de la DB10 como prefijo a los
ficheros usados por la DBH.
* 1999/07/06 sa...@ap... (patch.whois_renumber) FIX
-----------------------------------------------------------------------
Este patch renumera algunos codigos de respuesta del WHOIS para hacerlos
mas universales. Se activa si usamos DB_HISPANO/DB_ESNET. Los codigos
renumerados son:
307 (undernet) IP del usuario -> 378 el usado en otras redes
308 (hispano) Nick Registrado -> 307 el usado en otras redes
Esto hace ke BitchX se sienta inmensamente feliz :)
* 1999/07/06 sa...@ap... (patch.DBH3) FEATURE
-----------------------------------------------------------------------
En el fichero struct.h he ampliado con un nuevo campo la estructura
Client, es un unsigned int llamado hmodes. Esto nos permitira dispo-
ner de 32bits adicionales como flags de usuario. Estos nuevos flags
son propagados si se definen en la tabla user_hmodes[] de s_user.c
En este parche se hace uso del bit de menor peso de este nuevo campo,
en el fichero s_bsd.h:
#define HMODES_NICKREGISTERED 0x00000001
Y las macros asocicadas:
IsNickRegistered(cptr);
SetNickRegistered(cptr);
ClearNickRegistered(cptr);
Cuando alguien se pone un nick, se hace un Clear, y si acierta la clave
se hace un SetNickRegistered.
Este flag queda reflejado con la letra 'r' en los modos de usuario, y
solo es aceptada si la envia un server (o por la autentificacion).
Si un usuario esta conectado y registra su nick en los servicios, este
flag se activara cuando llegue su registro DBH/DB. Y le sera borrado
cuando se llegue un borrado de su registro. Los cambios son informados
al usuario y propagados a la red.
El /WHOIS ha sido ampliado (whocmds.c) para mostrar este nuevo 'flag'
y he ocupado el ERROR 308 en los fichero s_err.c y numeric.h
He cambiado los condicionales que comprueban en tablas si nick registrado
por la nueva macro IsNickRegistered()
Queda reflejado en el /VERSION como DBH3.Nr+...., cambiando el anterior
texto (DBH2.N+....). He decidido cambiar a DBH3, pk las macros son y
seran ampliamente usadas en futuras DBH's, y hago desaparecer la opcion
de compilacion DBH_NICK_HACK quedando integrado todo su codigo en el
que es activado por el #define DB_HISPANO
-----------------------------------------------------------------------
* FINAL o INICIO de CAMBIOS, segun se mire :)
--- NEW FILE: CAMBIOS2_10_07 ---
$Id: CAMBIOS2_10_07,v 1.1 2002/08/21 17:59:40 zolty Exp $
* 2000/10/10 jc...@ar... (---) FIX
-----------------------------------------------------------------------
Un "make distclean" tambien elimina los ficheros de la "zlib". Esto
es bastante importante si cambiamos de arquitectura.
Tambien se eliminan los ficheros de cache del "configure", por la
misma razon.
* 2000/10/05 jc...@ar... (---) FEATURE
-----------------------------------------------------------------------
Un "/map" muestra, adicionalmente a lo normal:
- El "numeric" del servidor
- El lag con ese servidor (medido a partir de los "create")
- El numero de usuario conectados a ese servidor
* 2000/10/05 jc...@ar... (---) FEATURE
-----------------------------------------------------------------------
Cuando se echa a un usuario con una nueva GLINE, se le informa a el
y a los que tengan activada la mascara "s" correspondiente, de
la razon del GLINE.
* 2000/10/05 jc...@ar... (DB77) FEATURE
-----------------------------------------------------------------------
Peticion de Sisco:
el mensaje de 'class full' de cuando la clase de usuario se llene,
que diga que su clase en este server esta llena, que pruebe
/server libres.irc-hispano.org , Es muy efectivo y ya fue probado
con exito en la transicion de pulsar a pulsar2....
* 2000/10/05 jc...@ar... (---) FEATURE
-----------------------------------------------------------------------
Mostrar en "/stats Y" cuantos usuarios hay conectados
en cada clase. Sino la unica opcion es hacer un
"/trace", lo que ocasiona FLOOD.
* 2000/08/16 jc...@ar... (clones7) FEATURE
-----------------------------------------------------------------------
Las conexiones con clones no heredan "targets", para evitar que
las sesiones se quiten targets entre si.
* 2000/06/20 jc...@ar... (DB76) FEATURE
-----------------------------------------------------------------------
Hago que los usuarios locales no puedan ACTIVAR los modos "SAR", aunque
el server los acepta si llegan de un usuario remoto.
De esta forma los usuarios no juegan con modos que no estan
desplegados aun.
* 2000/06/13 jc...@ar... (ZLIB10) FIX
-----------------------------------------------------------------------
Tras horas de investigacion descubro un fallo en la implementacion
de las "microrafagas": cuando trabajamos con microrafagas es
perfectamente posible que tengamos que hacer FLUSH varias veces (no
solo una), ya que ZLIB puede ir almacenando compresion de forma
interna, y no soltarla hasta el final.
Por tanto, hay que comprobar este caso especificamente, y no confiar
en que un buffer de salida lo bastante grande sea suficiente, ya que
antes se usaba ese buffer para un unico comando, y ahora lo usamos
para todas las microrafagas que, en el caso de un NETJOIN, pueden
ser varios megabytes.
Cuando tengo que hacer varios FLUSH, aprovecho para usar "send_queued()".
* 2000/06/13 jc...@ar... (Undernet20) SYNC
-----------------------------------------------------------------------
Parches Undernet hasta version 12.
Oculto la IP de los nodos tambien en el comando "uping".
* 2000/06/12 jc...@ar... (ZLIB9) FEATURE
-----------------------------------------------------------------------
Para evitar la posible carga de los malloc/free durante las microrafagas,
implemente un sistema de cache, de forma que no haga falta pedir/liberar
memoria constantemente.
La cache se va purgando poco a poco, de forma que si en un momento
dado se pidieron muchos recursos, esto se van liberando poco a poco.
* 2000/06/12 jc...@ar... (ZLIB8) FIX
-----------------------------------------------------------------------
Toda "microrafaga" que se abra, debe ser cerrada. Hay que tener cuidado
con posibles "return" entre la apertura y cierre, ya que impiden el
correcto cierre de la "microrafaga" si no se programa adecuadamente.
Para curarnos en salud, an~ado una rutina nueva que fuerza una
inicializacion del modulo de "microrafagas" entre lecturas de
las conexiones server<->server. De esta forma cualquier microrafaga
"huerfana" sera clausurada correctamente.
An~ado tambien otro comando para eliminar "cptr" que se hayan cerrado,
del sistema de "microrafagas". De esta forma no nos preocupara que
una conexion se cierre mientras esta en una "microrafaga".
* 2000/06/12 jc...@ar... (ZLIB7) FEATURE
-----------------------------------------------------------------------
Intento realizar el FLUSH de compresion por grupos, no por comandos
aislados. Ello supone la deteccion y aprovechamiento de las microrafagas,
que son cuando se van a generar varios comandos de salida por una
o mas conexiones.
El caso mas obvio es un "netjoin", cuando el servidor transfiere al otro
extremo todo el BURST.
Otro caso bastante evidente es cuando se lee un bloque de otro nodo;
cuando ese bloque tiene varios comandos, podemos considerar que hasta
su final estamos trabajando con una "microrafaga".
Por ultimo, tenemos el caso de la BDD.
Cuando se cierra una microrafaga, se hace FLUSH de lo que pudiese
haber quedado.
* 2000/06/08 jc...@ar... (ZLIB6) CLEANUP
-----------------------------------------------------------------------
Introduzco algunos "assert()" para casos que no deberian ocurrir nunca,
y verifico todas las llamadas a la libreria ZLIB y de gestion de
memoria asociadas, por si alguna falla (no deberia).
* 2000/06/08 jc...@ar... (indent6) CLEANUP
-----------------------------------------------------------------------
"make indent".
* 2000/06/06 jc...@ar... (ZLIB5) FIX
-----------------------------------------------------------------------
El servidor no compilaba correctamente si el sistema en el que se
va a instalar NO tenia instalado ya la ZLIB (aunque use la local al
servidor, no la instalada en el sistema).
* 2000/05/23 jc...@ar... (CONFIG5) FEATURE/FIX
-----------------------------------------------------------------------
Corregido un bucle infinito cuando se evalua la configuracion.
"/stats f" muestra la configuracion de las lineas "F".
La negociacion en los enlaces se activa en el "make config".
Cambiados los textos de los "DEFINE".
* 2000/05/23 jc...@ar... (CONFIG4) FEATURE
-----------------------------------------------------------------------
Cambio "NACK" por "REQ", que es mas logico.
Hago que las negociaciones entre nodos sean configurables mediante una
nueva "F"-line.
El primer campo indica el sentido salida, y el segundo el sentido entrada.
Las mayusculas indican SIEMPRE, y las minusculas NUNCA.
De momento defino "z" como ZLIB.
* 2000/05/18 jc...@ar... (ZLIB4) FEATURE/FIX
-----------------------------------------------------------------------
Un "stats l" muestra el trafico transferido realmente, y su nivel
de compresion.
Solo crea las estructuras de datos de compresion cuando se ha negociado
afirmativamente la compresion (de forma independiente en cada sentido).
Este cambio corrige tambien un grave "memory leak", debido a que se
inicializaban unos 300Kbytes por conexion de usuario, para soportar
posible compresion, pero no se liberaba si no se habia negociado
compresion.
* 2000/05/18 jc...@ar... (ZLIB3) FEATURE
-----------------------------------------------------------------------
Primera version que se va a probar en la red en produccion. Se ha
modificado "stats l" para que indique el porcentaje de compresion en
recepcion y en transmision, por cada enlace.
* 2000/05/18 jc...@ar... (CONFIG3) FEATURE
-----------------------------------------------------------------------
Lo anterior no funciona todo lo bien que debiera, por multiples motivos
explicados en mi web.
Ahora trabajo considerando que algunas peticiones son "especulativas",
y se accede a ellas o se ignoran tras resolverse el tipo de conexion.
* 2000/05/18 jc...@ar... (CONFIG2) FEATURE
-----------------------------------------------------------------------
Cuando se unen dos servers, se envia un "ping" y toda la negociacion,
y solo se manda el BURST cuando llega el "pong" de respuesta.
Ello permite negociar ANTES de transmitir el burst.
* 2000/05/17 jc...@ar... (CONFIG1) FEATURE
-----------------------------------------------------------------------
Primera implementacion del protocolo de negociacion entre servidores.
Se basa en el PPP. Un servidor solicita a otro una "feature" mediante
un NAK, y este la confirma activa con un ACK. Si no reconoce la
feature, devuelve un REJ.
* 2000/05/17 jc...@ar... (ZLIB2) FEATURE
----------------------------------------------------------------------
An~ado los flags "ZLIB_ESNET_IN" y "ZLIB_ESNET_OUT" a la estructura
de servidor. Tambien an~ado dos estructuras "z_stream".
Compilo la libreria ZLIB *ANTES* de compilar el servidor, para que
no se enlace con una version anticuada o preinstalada.
Compresion de la salida a servidor activada "a pin~on fijo", para
verificar que funciona bien.
* 2000/05/16 jc...@ar... (ZLIB1) FEATURE
-----------------------------------------------------------------------
An~adida la libreria ZLIB de forma interna, para no depender de que
se tenga una version instalada y actualizada en el sistema.
Se configura y se compila correctamente. Se an~ade una opcion de
configuracion para permitir activar o desactivar la "feature" en tiempo
de compilacion.
* 2000/05/16 jc...@ar... (Undernet19) SYNC
-----------------------------------------------------------------------
Parches Undernet hasta version 11.
* 2000/04/04 jc...@ar... (DB75) FIX
-----------------------------------------------------------------------
Correccion al parche DB71. Si el HUB manda una orden de borrado, no
hace falta mandarle nada mas, ni registros ni "B", ya que la orden de
borrado sera confirmada y se pedira la base de datos de nuevo.
* 2000/04/04 jc...@ar... (DB74) FIX
-----------------------------------------------------------------------
El parche db52 es erroneo, porque bajo ciertas condiciones se saltaba
"hubs", y es imperativo desconectar de todos ellos.
El sintoma es que si una tabla es muy corta, si se corrompe se genera
un bucle entre el nodo y el hub. Ver parche DB71.
* 2000/04/04 jc...@ar... (---) FIX
-----------------------------------------------------------------------
Compila con la opcion de DEBUG activada.
* 2000/04/03 jc...@ar... (DB73) FIX?
-----------------------------------------------------------------------
En algunas maquinas parece que la compactacisn da problemas, por alguna
razon desconocida. En Solaris parece que todo funciona bien, y no he
logrado reproducir el problema en mis Linux.
He modificado la forma de realizar las compactaciones para verificar
si se trata de un bug del Kernel Linux, bajo determinadas condiciones,
o no.
* 2000/03/28 jc...@ar... (---) FEATURE
-----------------------------------------------------------------------
Elimino la opcion "DBH_OPER_HACK_ONLYREG" en la configuracisn, ya que
ahora mismo no tiene sentido. No obstante dejo todo el codigo en el
servidor, para el futuro.
* 2000/03/28 jc...@ar... (---) FEATURE
-----------------------------------------------------------------------
Por defecto, los opers deberian poder entrar en cualquier canal usando
el comando "join # OPER". Ahora esta puesto que solo puedan entrar en
los canales registrados en la base de datos distribuida, lo que es un
problema porque no hay ninguno :-)
En el futuro se devolvera a este flag a su valor normal.
Por lo pronto, la compilacion de servidores nuevos debe realizarse
cambiando esta opcion en el "make config". Probablemente, lo mas
inteligente seria eliminar esta opcion.
* 2000/03/09 jc...@ar... (VIP13) FIX
-----------------------------------------------------------------------
Elimina las dependencias big endian/little endian a la hora de calcular
las IPs virtuales.
Por otra parte, el codigo original de savage era defectuoso y no
permitia recuperar una IP cifrada. Cambio el sistema de cifrado.
* 2000/03/09 jc...@ar... (VIP12) FIX
-----------------------------------------------------------------------
Complemento al parche VIP11: aparte del kill, tampoco muestra en el
status de los usuarios conectados al servidor, cuando un IRCop ejecuta
el comando "/oper" con exito.
Si "/oper" falla, solo se enteran los IRCops, no todos los usuarios.
Esto ya estaba de antes.
* 2000/03/09 jc...@ar... (db71) FIX
-----------------------------------------------------------------------
Cuando un nodo detecta que una de las bases de datos locales esta
corrupta, la borra y solicita actualizaciones a su HUB. Habia un
problema cuando la base de datos en si era lo bastante pequen~a como
para transferirla en una unica rafaga:
- El nodo con la BDD corrupta borra la base de datos y emite un "J 0"
a su hub, indicandole que le reenvie de nuevo.
- Si el HUB tenia ya el grifo abierto, envia una orden de borrado y
la base de datos. Si cabe entera en una rafaga, abre el grifo de nuevo.
- El nodo original recibe la orden de borrado y la responde con
otro "J 0"
- Dado que el HUB recibe otro "J 0" con grifo abierto, se vuelve
a repetir el proceso.
La solucion a este problema es no enviar la base de datos, sino un
comando "B num_registro", para que el otro extremo nos la pida. Es
decir, no hacemos un "push", sino que tiene que ser el otro extremo
quien nos haga el "pull".
* 2000/03/09 jc...@ar... (VIP11) FIX
-----------------------------------------------------------------------
Cuando un IRCop hace un "kill", en el "path" aparece su IP virtual,
si tiene.
* 2000/03/08 jc...@ar... (db70) FIX
-----------------------------------------------------------------------
Cuando llegaba una orden de compactacion de la base de datos con
contenido (por ejemplo, una frase explicativa), se producia una
compactacion (correcto) y no se guarda dicho registro en memoria
aunque si en disco (correcto).
El problema es que si se reinicia el servidor IRC, o se hace un
/rehash, se leen todos los registros de disco... incluyendo el
registro de compactado... y se almacena en memoria (mal).
Lo que hago es leer todo el fichero, como siempre, y al final
borrar cualquier posible registro de compactado que hayamos
podido capturar en memoria. El problema solo se producia cuando
se releia la base de datos de disco (reinicio o rehash) *Y*
el registro de compactado tenia algun texto explicativo.
* 2000/03/08 jc...@ar... (db69) FEATURE
-----------------------------------------------------------------------
En resumen, si un nick registrado cambia a otro nick (independientemente
de que este registrado), anula sus flags:
r - Nick Registrado
h - Operador (helper)
x - Ocultacion de IP
Adicionalmente, si no es IRCop, anula tambien el flag:
X - Poder ver IPs ocultas.
02/Mar/00
Complemento a la entrada siguiente.
Cuando se pasa de un nick registrado a otro tambien
registrado, deberia haber un estado "intermedio"
sin registro, para que se detecte correctamente que
se trata de otro usuario tambien registrado. Ejemplo:
:pepe mode :-rhx
:pepe nick :juan
:juan mode :+rhx
O eso o, lo logico, ampliar el comando "nick" para que
envie tambien los modos.
02/Mar/00
Cuando un usuario con nick registrado pasa a nick
sin registrar, el servidor deberia quitar los modos
ANTES de cambiar el nick.
En realidad, lo bueno seria que justo antes del cambio
de nick se enviasen los modos que se PIERDEN y justo
despues los modos que se ganan.
* 2000/02/15 jc...@ar... (db68) FIX
-----------------------------------------------------------------------
Si un "helper" cambia de nick y se pone otro nick
registrado, el resto de la red no lo vera como
"helper", pero su nodo lo seguira considerando
"helper". Problema detectado por {^DaNi^}.
Debe propagar modos al resto de la red y ajustar modos
en el nodo local.
* 2000/01/24 jc...@ar... (NoProxy17) FEATURE
-----------------------------------------------------------------------
Si la verificacion SOCKS no llega a conectar, porque por ejemplo la
maquina destino tiene un cortafuegos o lo tiene el propio servidor de
IRC (no deberia bloquear la salida), almacena en la cache SOCKS que
la verificacion tuvo exito.
* 2000/01/24 jc...@ar... (undernet18) SYNC
-----------------------------------------------------------------------
Parches Undernet.
Glines a canales
Ocultacion de las IPs de los nodos/HUBs.
* 2000/01/21 jc...@ar... (NoProxy16) FIX
-----------------------------------------------------------------------
El parche original de SOCKS hace verificacion de SOCKS tambien cuando
un servidor se conecta a otro. Y encima el servidor que realiza la
verificacion en aquel que inicia la conexion... Lo cual es innecesario.
* 2000/01/21 jc...@ar... (undernet17) SYNC
-----------------------------------------------------------------------
Sincronizacion con parches Undernet. Un operador puede entrar en un
canal local si usa la clave "OVERRIDE".
* 2000/01/20 jc...@ar... (NoProxy15) FIX
-----------------------------------------------------------------------
En NoProxy14 se leia el canal, pero luego no se hacia nada con el
y se seguia enviando a #opers.
* 2000/01/20 jc...@ar... (NoProxy14) FEATURE
-----------------------------------------------------------------------
Las notificaciones de proxy abierto no se envian a #opers, sino al
canal que se indique en la BDD "b" bajo la clave "sockschannel".
* 2000/01/20 jc...@ar... (VIP10) FIX
-----------------------------------------------------------------------
Si un usuario cambia de nick, hay que regenerar su
IP virtual. Sino, nos sigue saliendo la antigua
cuando se vuelve a poner el nick.
Se nota si la IP virtual del usuario cambia, por ejemplo
porque cambie la clave de cifrado o porque cambie
su entrada en la BDD "v".
Lo sencillo es borrar la IP virtual cuando se cambia el nick.
* 2000/01/18 jc...@ar... (NoProxy13) FIX
-----------------------------------------------------------------------
A veces, cuando un proxy esta abierto, parece que informa de ello
dos veces. La casuistica es sencilla: si se inician dos conexiones
desde un proxy abierto, como cuando se inicia la verificacion
todavia no sabemos el resultado, haremos dos verificaciones y, por
tanto, dos informes.
La solucion es sencilla: antes de imprimir el informe, hay que ver
si ya tenemos su valor en la cache. Si es asi, no informa en
absoluto, porque se acaba de hacer.
Lo malo es que la segunda vez suele indicar la IP resuelta, y con
esto lo perdemos.
* 2000/01/17 jc...@ar... (clones6) FEATURE
-----------------------------------------------------------------------
Cuando se dice que el resultado de una verificacion
SOCKS esta "cached", debe indicarse tambien
cuanto tiempo de vida le queda.
* 2000/01/17 jc...@ar... (clones5) FIX
-----------------------------------------------------------------------
?Corrige el problema de core dump?.
* 2000/01/17 jc...@ar... (NoProxy12) FEATURE
-----------------------------------------------------------------------
Dado que ahora se hace cache tanto del resultado positivo como negativo
de la verificacion de proxy, ya no tiene sentido tener una cache
separada para no hacer "flood" de mensajes de aviso (NoProxy10).
* 2000/01/17 jc...@ar... (indent5) CLEANUP
-----------------------------------------------------------------------
"make indent".
* 2000/01/17 jc...@ar... (NoProxy11) FEATURE
-----------------------------------------------------------------------
Despliego una cache negativa de proxies abiertos. Si un proxy esta
abierto, y tiene iline, le doy 30 minutos de cache. Si no tiene
iline, le pongo 4 horas.
El efecto es comparable a tener una gline local.
* 2000/01/17 jc...@ar... (NoProxy10) FEATURE
-----------------------------------------------------------------------
No muestra mensajes repetidos de proxy inseguro (NoProxy9) si
las conexiones se producen en menos de 10 minutos.
* 2000/01/17 jc...@ar... (clones4) FEATURE
-----------------------------------------------------------------------
Si una conexion tiene clones reconocidos, no hereda "target".
* 2000/01/14 jc...@ar... (NoProxy9) FEATURE
-----------------------------------------------------------------------
Cuando se detecta la entrada desde un proxy inseguro, el servidor en
cuestion debe anunciarlo en el canal "#opers".
* 2000/01/14 jc...@ar... (VIP9) FIX
-----------------------------------------------------------------------
Completa VIP8.
* 2000/01/14 jc...@ar... (VIP8) FEATURE
-----------------------------------------------------------------------
"Lazy Virtual Host".
Calcula el Virtual Host solo la primera vez que alguien solicita
informacion sobre ese usuario. De esta forma nos ahorramos calcular
host virtuales de forma innecesaria, ademas de repartir el cifrado
a lo largo del tiempo, en vez de concentrarlo en, por ejemplo,
el BURST.
La casuistica es:
+ Activar +x
- Cuando se conecta un usuario con nick registrado
- Cuando un usuario se pone +x
- Cuando nos llega un usuario con +x remoto
+ Desactivar +x
- Cuando un usuario de pone -x
- Cuando el nick se desregistra desde la red
* 2000/01/14 jc...@ar... (VIP7) FIX
-----------------------------------------------------------------------
Si a un usuario se le va a cifrar su IP, pero la clave de cifrado no
esta en la base de datos, se pone el host ""no.hay.clave.de.cifrado".
Incluyo algunos "Sanity Checks" en el trabajo con la base de datos
de IPs virtuales.
* 2000/01/11 jc...@ar... (VIP6) FEATURE
-----------------------------------------------------------------------
Un "UserIP" sobre un usuario con IP protegida debe mostar "0.0.0.0", no
"127.0.0.1".
* 2000/01/11 jc...@ar... (VIP5) FEATURE
-----------------------------------------------------------------------
No permite que un servidor remoto ponga en un usuario arbitrario los
modos +h, +x, o +X.
Si un nick no esta registrado (o se desregistra), no tolera +h, +x, +X.
* 2000/01/11 jc...@ar... (Undernet16) SYNC
-----------------------------------------------------------------------
Sincronizacion con parches Undernet.
* 2000/01/10 jc...@ar... (db67) FIX
-----------------------------------------------------------------------
Los cambios efectuados no tenian en cuenta que pudiese llegar por
la red un registro no normalizado.
* 2000/01/10 jc...@ar... (indent4) CLEANUP
-----------------------------------------------------------------------
"make indent".
* 2000/01/10 jc...@ar... (db66) FEATURE
-----------------------------------------------------------------------
Sigo preparando la gestion directa de las BDD a partir de su MMAP. En
esta ocasion, paso la responsabilidad de la escritura en disco a
"db_alta()".
* 2000/01/10 jc...@ar... (db65) FEATURE
-----------------------------------------------------------------------
Cuando se busca un registro, devolvemos una copia, y no el registro
real. De esta forma vamos preparando el camino para eliminar los
registros de memoria y leerlos directamente de MMAP.
Como el resto del programa no sabe esto, trabajamos con una pequen~a
cache de registros (32 valores), en la que se van copiando los
registros que se piden, sobreescribiendo los registros antiguos
en un anillo.
* 2000/01/10 jc...@ar... (db64) FEATURE
-----------------------------------------------------------------------
No almacenamos el destinatario en memoria.
* 2000/01/10 jc...@ar... (db63) FEATURE
-----------------------------------------------------------------------
Ya no se usan "malloc/free" para trabajar con la memoria temporal
necesaria para normalizar datos en la base de datos; cuando se va a
realizar una operacion, vemos si el bloque que tenemos es suficiente.
Si no lo es, lo libera y pide otro mas grande.
De esta forma eliminamos muchas llamadas de gestion de memoria, y
reducimos la fragmentacion.
Tambien se corrigen un par de BUGS en la gestion de memoria de las BDD.
* 2000/01/10 jc...@ar... (clones3) FEATURE
-----------------------------------------------------------------------
El mensaje cuando se supera el limite de clones
deberia publicitar la pagina web de compra.
El mensaje a imprimir se referencia como el registro ".." en BDD - 'i'.
* 2000/01/10 jc...@ar... (db62) FEATURE
-----------------------------------------------------------------------
Cuando el servidor muere por culpa de la base de datos, se guarda en
el SYSLOG el PATH al directorio con la base de datos problematica.
* 2000/01/10 jc...@ar... (db61) FIX
-----------------------------------------------------------------------
En la instalacion "make install" se usaba IRCDOWN/IRCDGRP para fijar
los permisos de la base de datos, cuando deberia utilizarse
IRC_UID/IRC_GID. En todo caso, ambos valores deberian ser equivalentes,
salvo por el hecho de que uno es informacisn textual y el otro es
numerico.
* 2000/01/05 jc...@ar... (undernet15) SYNC
-----------------------------------------------------------------------
Sincronizacion con parches Undernet.
* 2000/01/04 jc...@ar... (db60) CLEANUP
-----------------------------------------------------------------------
Mas aislamiento de BDD y borrado de una rutina que ya no se utiliza.
* 2000/01/03 jc...@ar... (db59) FIX
-----------------------------------------------------------------------
Es importante recordar que cuando se an~ade la gestion de una nueva BDD
hay que modificar el "make install", para que no la borre cada vez
que se instala una nueva version del servidor.
Eso era lo que pasaba con la base de datos "t".
* 2000/01/03 jc...@ar... (db58) FIX
-----------------------------------------------------------------------
[13:03] <YaW> Si un usuario tiene el nick registrado en la DB y al conectar se identifica (/server servidor
puerto nick pass). El servidor primero hace un MODE en P9 y posteriormente un NICK en P10.
[13:03] <YaW> solucion: pasarlo todo en la linea NICK
JCEA:
Cuando se introduce la clave en el nick, se envia
inmediatamente el modo sin que se haya propagado
aun el nuevo usuario, ya que todavia no se ha
registrado contestando al PING
Si la clave se introduce como "pass", pasa lo mismo.
La solucion es sencilla: cuando se van a propagar los modos por la red,
solo lo hace si el USUARIO esta registrado. Es decir, si se ha conectado,
ha introducido sus datos y ha respondido al PING.
* 2000/01/03 jc...@ar... (db57) FEATURE
-----------------------------------------------------------------------
Parche complementario al anterior, verificando tambien las BDD leidas
desde disco. Este parche no deberia ser necesario si no fuera porque
ya se han propagado bases de datos corruptas, antes de desplegar DB56.
* 2000/01/03 jc...@ar... (db56) FEATURE
-----------------------------------------------------------------------
Solo acepta un registro nuevo cuando referencia una BDD correcta. Es
decir, cuando la BDD referenciada es 'a'-'z' o 'N'.
En particular, no acepta registros cuyo campo de base de datos conste
de mas de un caracter. De esa forma se pretende limitar el peligro
de cometer un error si se utilizan comandos "RAW".
* 2000/01/03 jc...@ar... (db55) FEATURE
-----------------------------------------------------------------------
Aumenta la informacion que proporciona la respuesta al comando "Q"
de las bases de datos distribuidas. Ahora proporciona tambien el numero
de registros que contiene.
Este cambio es compatible con el protocolo previo, a nivel de servidores.
No asi a nivel de SERVICES que implementen "Q".
* 2000/01/03 jc...@ar... (db54) CLEANUP
-----------------------------------------------------------------------
Concentra todas las operaciones "internas" (menos el hashing) de las
bases de datos en el modulo de bases de datos. Entre otras cosas, eso
supone exportar menos entorno en el *.h
* 2000/01/03 jc...@ar... (undernet14) SYNC
-----------------------------------------------------------------------
Fix Y2K proveniente de Undernet. En realidad el problema ocurre todos
los an~os, entre el periodo en que la zona local ha cambiado de an~o,
pero GMT todavia no lo ha hecho.
* 1999/12/21 jc...@ar... (patch.global7) FIX
-----------------------------------------------------------------------
Cuando un global se pasaba de nodo en nodo, se perdia el texto del mensaje.
* 1999/12/20 jc...@ar... (patch.clones2) FIX
-----------------------------------------------------------------------
Si tiene permiso de clones, nunca debe bloquear las conexiones con
"Throttled".
En la version anterior, solo se eliminaba la posibilidad de throttle
cuando se superaba el numero maximo de conexiones, no cuando se
entraba y salia repetidamente.
* 1999/12/16 jc...@ar... (patch.global6) FIX
-----------------------------------------------------------------------
Por alguna extran~a razon, borre un parametro de una funcion con
parametros variables, provocando core dump.
* 1999/12/16 jc...@ar... (patch.global5) FIX
-----------------------------------------------------------------------
Se iban an~adiendo prefijos "Mensaje Global" en cada "hop".
* 1999/12/16 jc...@ar... (patch.NoProxy8) FEATURE
-----------------------------------------------------------------------
En la cache NoProxy, si la conexion proviene de una IP con clones,
se le dan cuatro horas de validez, en lugar de los 30 minutos.
* 1999/12/13 jc...@ar... (undernet13.patch) SYNC
-----------------------------------------------------------------------
Fix proveniente de Undernet.
* 1999/12/13 jc...@ar... (patch.indent3) SYNC
-----------------------------------------------------------------------
"make indent".
* 1999/12/13 jc...@ar... (patch.global4) FIX
-----------------------------------------------------------------------
Soluciona "Target Left IRC".
* 1999/12/13 jc...@ar... (patch.global3) FIX
-----------------------------------------------------------------------
Corregido Core Dump.
* 1999/12/10 jc...@ar... (patch.global2) FEATURE
-----------------------------------------------------------------------
Con el cambio anterior, ya no se reconocen los mensajes globales.
An~adimos el texto "MENSAJE GLOBAL", asi como el nick del remitente
y la mascara de destino.
* 1999/12/10 jc...@ar... (patch.global1) FEATURE
-----------------------------------------------------------------------
Para evitar que el mIRC meta los globales en la ventana de status,
hacemos que cada usuario vea el global como un mensaje privado
dirigido a el personalmente.
Por cierto, un privado con destino "$..." se distribuye entre los usuarios
conectados a los servidores que cumplen la mascara.
Si el destino es "#...", el global se distribuye entre los usuarios de
la red cuya IP/Hostname cumple la mascara.
Si se requiere una personalizacion mayor, se puede recurrir al envio
de mensajes personales o, mejor, /privmsg n1,n2,n3,n4,n5...
* 1999/12/10 jc...@ar... (patch.NoProxy7) FIX
-----------------------------------------------------------------------
Los servidores no tienen entrada en IPcheck, asi que no debemos hacer
"SetIPChecked()" de forma indiscriminada en "IPcheck_proxy_cache_set()".
* 1999/12/10 sa...@ap... (patch.dbh17) FIX
-----------------------------------------------------------------------
El pseudoBot de nicks nos habla por NOTICE en lugar de PRIVMSG, lo hago
pensando en no liar mucho la migración de cara a los scripts.
* 1999/12/09 jc...@ar... (patch.NoProxy6) FIX
-----------------------------------------------------------------------
El parche "NoProxy5" no hacia cache dependiendo del tipo de error en el
intento de conexion para verificar.
* 1999/12/09 jc...@ar... (patch.NoProxy5) FEATURE
-----------------------------------------------------------------------
Mantiene una cache del resultado de las comprobaciones de PROXY abierto.
Si el proxy estaba cerrado, le da una validez de 30 minutos. Si el
PROXY estaba abierto, realiza la comprobacion de nuevo siempre.
* 1999/12/09 jc...@ar... (undernet12.patch) SYNC
-----------------------------------------------------------------------
Incluimos los tres primeros parches de Undernet para 2.10.07
Algunos detalles:
- Uno de los parches permite que los IRCops no tengan limitado el
numero de canales en los que puede entrar simultaneamente. Eso ya
estaba implementado en nuestro codigo.
- Otros parches conceden numerosos privilegios a los IRCops, dentro
de canales locales. Nosotros hacemos lo mismo, pero para todos
los canales, no solo los locales.
* 1999/11/19 sa...@ap... (patch.db53) FIX
-----------------------------------------------------------------------
Linux 2.0/libc5 no contiene algunas definiciones en mman.h, como són
MAP_NORESERVE y MAP_FAILED. Digital Unix no contiene MAP_NORESERVE,
los he incorporado en s_bdd.h, MAP_NORESERVE=0 y MAP_FAILED=((void*)-1)
* 1999/11/18 sa...@ap... (patch.db52) FIX
-----------------------------------------------------------------------
Si está corrupta una tabla, al hacer REHASH (o kill -1) muere el daemon
al desconectar de los hubs, pk un puntero keda invalidado. Se ha
corregido con este patch.
* 1999/11/18 sa...@ap... (patch.dbh16) FEATURE
-----------------------------------------------------------------------
Los textos referentes a autenticación de usuario se enviaran con origen
nombe.de.server y NOTICE , excepto si existe un registro 'nickserv' en
la tabla 'b', en cuyo caso se enviaran con origen el contenido de dicho
registro mediante PRIVMSG. Resumiendo:
:jupiter.irc-hispano.org NOTICE usuario :*** Utiliza /NICK usuari...
o bien:
:NiCK PRIVMSG usuario :*** Utiliza /NICK usuario:clave para ident...
* INICIO de CAMBIOS para "ircu2.10.07"
--- NEW FILE: CAMBIOS2_10_H_01 ---
$Id: CAMBIOS2_10_H_01,v 1.1 2002/08/21 17:59:40 zolty Exp $
* 2000/11/16 jc...@ar... (VIP18 - u2.10.H.01.28) FIX
-----------------------------------------------------------------------
Cuando un usuario cambia de nick registrado a no registrado, y al
reves, y el nick registrado tiene IP virtual propia, la IP virtual del
usuario no cambia.
Ahora se verifican posibles cambios en la IP virtual cuando el
usuario gana o pierde el flag "+r".
* 2000/11/16 jc...@ar... (u2.10.H.01.27) CLEANUP
-----------------------------------------------------------------------
"make indent"
* 2000/11/16 jc...@ar... (VIP17 - u2.10.H.01.26) FIX
-----------------------------------------------------------------------
Modificamos el servidor para que una red hibrida con nodos con IP
virtual para todo el mundo, y nodos con IP virtual solo para registrados
puedan convivir sin problemas.
Los nodos mas restrictivos no pondran el +x a sus usuarios, pero deben
aceptar el +x que les llegue de otro nodo.
* 2000/11/16 jc...@ar... (VIP16 - u2.10.H.01.24) FIX
-----------------------------------------------------------------------
Aparecian algunos usuarios ajenos con modo "+x" de forma aleatoria.
El problema se producia cuando un usuario externo cambiaba de nick,
que siempre se le ponia el "+x", aunque el nodo original no enviase
dicho modo.
* 2000/11/16 jc...@ar... (VIP15 - u2.10.H.01.23) FEATURE
-----------------------------------------------------------------------
Solo debe verificar la clave de nick registrado cuando se trata de
conexiones locales.
Solo acude a la base de datos para ver si un nick esta registrado
si se trata de una conexion local.
Esto incrementa el rendimiento de forma notable, sobre todo en los
"net join".
* 2000/11/15 jc...@ar... (u2.10.H.01.22) FEATURE
-----------------------------------------------------------------------
Cuando se produce un "connect", solo se informa del mismo a los
IRCops y Helpers.
* 2000/11/15 jc...@ar... (u2.10.H.01.21) FEATURE
-----------------------------------------------------------------------
Cuando un usuario esta siendo bloqueado por "silence",
deberia salirle algo en pantalla.
Esto afecta a "invite", "message" y "notice".
Tambien afecta a "cnotice" y "cprivmsg".
Los mensajes cuyo destinatario es un canal, no informan si hay
un silence en algunos usuarios de un canal.
* 2000/11/15 jc...@ar... (u2.10.H.01.20) FEATURE
-----------------------------------------------------------------------
Los Helpers pueden solicitar listados largos "who", y ven los modos
"i", "w" y "g" de los usuarios, como se fueran IRCops.
* 2000/11/15 jc...@ar... (u2.10.H.01.19) FEATURE
-----------------------------------------------------------------------
Los opers deberian tener acceso al flag "x" del
comando /who.
* 2000/11/15 jc...@ar... (VIP14 - u2.19.H.01.18) FEATURE
-----------------------------------------------------------------------
Todos los usuarios tienen IP virtual.
* 2000/11/06 jc...@ar... (u2.10.H.01.16) FEATURE
-----------------------------------------------------------------------
Define un par de flags nuevos para no mezclar demasiado el tema de
los informes de "rename".
Documentado en http://www.argo.es/~jcea/irc/modos.htm
* 2000/10/19 jc...@ar... (u2.10.H.01.15) FEATURE
-----------------------------------------------------------------------
Un "/who" a un Oper (Helper) tambien devuelve el asterisco marcador
de IRCop, de forma que algunos scripts te sacan con colorines :-).
* 2000/10/19 jc...@ar... (u2.10.H.01.14) FEATURE
-----------------------------------------------------------------------
Cuando un usuario hace un "/who 0 o" tambien le salen los Opers, ya
que los IRCops son una especie en extencion en IRC-Hispano :-).
* 2000/10/19 jc...@ar... (---) FIX
-----------------------------------------------------------------------
Solucionado un problema con el comando "LIST", que ocasionaba que solo
aparecieran los canales cuyo topic ha cambiado en los ultimos 10 minutos.
El problema era debido a un fallo de reconocimiento de la version del
servidor, por parte del mIRC. Se ha solucionado cambiando nuestra
version de server, de "ircu2.10.H.01.13" a "u2.10.H.01.13".
Un sistema de deteccion un tanto precario...
* 2000/10/16 jc...@ar... (---) FIX
-----------------------------------------------------------------------
Solucionado un problema de compilacion cuando se configura el servidor
para que no soporte compresion en los enlaces.
Solucionado un problema de dependencias para "m_config.c".
* 2000/10/15 jc...@ar... (NICK05) FIX
-----------------------------------------------------------------------
El Kill se mandaba dos veces.
* 2000/10/15 jc...@ar... (NICK04) FIX
-----------------------------------------------------------------------
Problemas cuando se hace un "rename" a un nick al que ya se hizo
rename antes. El usuario se mata, porque el nick reasignado esta en uso,
pero luego se intentaba hacer cosas con el AUNQUE ya estaba muerto.
Ello generaba "core dump" esporadicos.
* 2000/10/15 jc...@ar... (NICK03) FIX
-----------------------------------------------------------------------
El cliente recibia dos veces su cambio de nick.
* 2000/10/15 jc...@ar... (NICK02) FIX
-----------------------------------------------------------------------
Solucionado un problema con el "RENAME" si el nick primitivo tie...
[truncated message content] |
