[IRC-Dev CVS] [CVS] Module ircd-ircdev: Change committed
Brought to you by:
zolty
Menu
▾
▴
[IRC-Dev CVS] [CVS] Module ircd-ircdev: Change committed
|
From: Toni G. <zo...@us...> - 2005-04-22 16:53:33
|
CVSROOT : /cvsroot/irc-dev
Module : ircd-ircdev
Commit time: 2005-04-22 16:53:23 UTC
Removed files:
doc/history/IRC-Hispano/CAMBIOS2_10_06
doc/history/IRC-Hispano/CAMBIOS2_10_07
doc/history/IRC-Hispano/CAMBIOS2_10_H_01
doc/history/IRC-Hispano/CAMBIOS2_10_H_02
doc/history/IRC-Hispano/CAMBIOS2_10_H_03
doc/history/IRC-Hispano/CAMBIOS2_10_H_04
doc/history/IRC-Hispano/CAMBIOS2_10_H_05
doc/history/IRC-Hispano/CAMBIOS2_10_H_06
Log message:
Borrar lo que huele mal ;)
---------------------- diff included ----------------------
Index: ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_06
diff -u ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_06:1.1.1.1 ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_06:removed
--- ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_06:1.1.1.1 Mon Sep 8 03:34:26 2003
+++ ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_06 Fri Apr 22 09:53:25 2005
@@ -1,321 +0,0 @@
-$Id: CAMBIOS2_10_06,v 1.1.1.1 2003/09/08 10:34:26 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 :)
Index: ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_07
diff -u ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_07:1.1.1.1 ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_07:removed
--- ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_07:1.1.1.1 Mon Sep 8 03:34:26 2003
+++ ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_07 Fri Apr 22 09:53:25 2005
@@ -1,793 +0,0 @@
-$Id: CAMBIOS2_10_07,v 1.1.1.1 2003/09/08 10:34:26 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"
Index: ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_H_01
diff -u ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_H_01:1.1.1.1 ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_H_01:removed
--- ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_H_01:1.1.1.1 Mon Sep 8 03:34:26 2003
+++ ircd-ircdev/doc/history/IRC-Hispano/CAMBIOS2_10_H_01 Fri Apr 22 09:53:26 2005
@@ -1,147 +0,0 @@
-$Id: CAMBIOS2_10_H_01,v 1.1.1.1 2003/09/08 10:34:26 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 extenc...
[truncated message content] |
