Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización: 12 de Febrero de 1.998 - Jueves
Message-ID: <34D8884A.D0AB5EA4@argo.es> Date: Wed, 04 Feb 1998 14:24:58 -0100 From: "Jesús Cea Avión" <jcea@argo.es> Organization: Argo Redes y Servicios Telematicos, S.A. To: "ircops@esnet.org" <ircops@esnet.org> Subject: [IRCOPS-ESNET] PARCHES OBLIGATORIOS (y 1)
Hola a todos. Aquí empieza una serie de parches obligatorios. Los podéis encontrar en http://www.argo.es/~jcea/irc/ircd.htm. Los que no quieran complicarse la vida pueden coger directamente el código parcheado.
Los cambios que aportan son los siguientes:
Este parche evita el único problema conocido del argobot... la caída por flood. Aunque el bot tiene un sistema de control de flujo, su empleo con unos parámetros bajos reduce su rendimiento y con unos parámetros altos no siempre puede evitar el "Excess Flood".
He probado el parche bastante y parece ir bien, aunque al mIRC parece que le daba algún chungo... Si alguien lo puede probar un poco más, que lo vea.
Este parche también hace que todos los parches ESNET anteriores sean visibles a través del comando "/version", además de poder configurarse desde el propio script "configure" que viene con la versión UNIX.
Este parche, *OBLIGATORIO*, permite el uso de modos extendidos. Gracias a él un IRCop puede actuar en un canal como si tuviese op, aunque no sea así. Entre otras cosas, puede pasarse op a sí mismo :). Con ello se pretende incrementar de forma notable la independencia respecto a OLIMPO. Para utilizarlo basta con especificar una "x" en el modo. Para que el sistema funcione, TODOS LOS SERVIDORES DEBEN IMPLEMENTARLO.
Este parche tiene dos opciones: el permitir el uso de XMODE en la red (OBLIGATORIO en ESNET) y el permitir que un IRCop local al nodo haga uso de ese privilegio (VOLUNTARIO).
Este parche, no obstante, tiene el problema de que en caso de split, y dependiendo de las circunstancias, los servidores "del otro lado" no reconocerán que se tiene op. Eso es lo que se llama "desynch" y ocurre también en IRC-Hispano/Undernet, aunque las razones y las soluciones no son exactamente las mismas.
Mi parche tiene la peculiaridad de, para evitar tráfico y falsas alarmas en las auditorías, no propagar el modo "x" si ya tenemos OP. Ello crea un problema si intentamos pasarnos op a nosotros mismos (por ejemplo), porque el otro lado no reconoce que tengamos op. Como para nuestro lado sí que lo tenemos, el modo no se propaga. Lo explico con un ejemplo:
La red se divide en dos trozos, por split:
| Nuestra zona | Enlace entre zonas | La otra zona |
|---|---|---|
| No tenemos OP | Cortado | No existimos en este lado |
| Nos damos op | ||
| Net.Join | ||
| Este lado ya nos ve. Nuestro lado
nos pone op, pero esta zona no lo reconoce (depende de las circunstancias). En condiciones normales toda la red nos quitaría OP, pero si estamos puestos como CS (modo +k), esta zona no nos consigue quitar el op. Consecuencia: en nuestra zona tenemos OP, y en ésta no. | ||
| Hacemos cualquier operación
que exija op. | ||
| Esta zona deshace la operación
porque para ella no tenemos OP. |
En este momento estamos en "desync". Hay dos formas de solucionarlo:
a)
| El IRCop invoca a Olimpo
para darse op, aunque en esta zona ya lo tiene | |
| Esta zona reconoce la orden
de Olimpo y nos pone op. |
Ya estamos sincronizados. La otra posibilidad es:
b)
| Nos quitamos op a nosotros
mismos | |
| Cuando el cambio llega a esta zona
se acaba, porque aquí ya no tenemos op | |
| Nos volvemos a dar OP
con el modo extendido | |
| Esta zona ya recibe el el modo bien |
El problema del método A es que se depende de Olimpo (aunque mucho menos que hasta ahora), y del método B que hay un tiempo durante el cual no somos ops. Si, además, estamos definidos como +k, primero debemos quitarnos ese modo, luego el op, luego ponernos el +k de nuevo y darnos op a nosotros mismos. Cuatro pasos, no está mal :)
La parte positiva es que los casos de "desync", que ya digo que pasan también en otras redes de IRC, se dan en circunstancias concretas, como que el que haya creado el canal esté del otro lado del split.
Como he dicho para que este parche funcione, tiene que ser instalado en TODOS los servidores de IRC. Mientras haya uno sólo que no lo ponga, los modos "rebotan" en él. Hay un caso curioso, no obstante, y bastante práctico: Si teníamos OP y lo hemos perdido, podemos utilizar el modo X *AUNQUE* haya servidores sin parchear en la red. Esto es debido a un tema de sellos temporales, que se dan cuando alguien nos pasa op, y no se borran aunque nos quedemos sin él };-).
En cuanto a las posibilidades de abuso, si usamos la "x" teniendo ya OP, simplemente se ignora (el modo extendido no aportaría nada). Si no tenemos OP, la gente del canal verá una maravillosa X en los cambios de modo. Si ellos la intentan usar, el servidor les dirá que no le reconoce el modo, como ha ocurrido siempre; ese modo sólo es accesible a IRCops. No se generan, aunque lo he estado pensando, mensajes globales como los descarados HACK(4) de Olimpo. Es algo que, en el futuro y según cómo se abuse de esto, se puede poner o no. Lo que sí se hace es propagar la X por la red, de forma que Olimpo hace log de todos los usos que se hagan de esos modos extendidos, con fines de auditoría.
Corinto lleva con estos parches desde ayer. Acabo de corregir un bug en el XMODE, que hacía que no se pudieran poner canales en invitación. Si algún "adelantado" se bajó los parches antes de leer este mensaje, que los vuelva a coger };-)
Como se indica en el topic, los parches son obligatorios. No obstante, no considero apropiado fijar una fecha límite, de momento, para el despliegue total. Los nodos deberían irse actualizando a medida que sus operadores encuentren 20 minutos libres. Mientras no se hayan actualizado todos los nodos no se podrán aprovechar todas las ventajas, pero no es el momento de presionaros (todavía };-). Pero si tenéis un huequecito, idlos instalando.
Recordad, parches en http://www.argo.es/~jcea/irc/ircd.htm.
Estos parches empiezan a tocar cosas delicadas. Si alguien nota algo raro, me puede llamar por teléfono a las cuatro de la mañana :-).
PS: JJ, ve añadiendo los parches ESNET al servidor NT, si no te es mucha molestia. Los Undernet1 tómatelos con calma... los han vuelto a cambiar (han incluído un parche mío... ya soy famoso :). Para la gente de UNIX, no preocuparos; esos cambios no os afectan, y cuando lo hagan los incluiré en mi página y lo avisaré aquí.
PPS: Con los parches nuevos el "./configure" hace varias preguntas para compilar condicionalmente todos los parches ESNET hasta el momento. Por otra parte, un "/version" muestra la cadena ".ESNET." seguida de:
| JG | Parche Join | "+" activado
"-" desactivado |
| CS | Parche Channel Service | "+" activado
"-" desactivado |
| CSF | Parche Channel Service No Flood | "+" activado
"-" desactivado |
| XM | Parche Xmode | Compilado y activo para soporte de red <- Obligatorio
"-" Sólo para soporte de red (IRCops remotos) <- Por lo menos éste "+" También lo pueden usar los IRCops locales |
--
Jesus Cea Avion _/_/ _/_/_/ _/_/_/
jcea@argo.es http://www.argo.es/~jcea/ _/_/ _/_/ _/_/ _/_/ _/_/
_/_/ _/_/ _/_/_/_/_/
PGP Key Available at KeyServ _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibnitz
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
