Linking To Other Servers.es
From the makers of InspIRCd.
Contents |
Linkeando a otros Servidores con InspIRCd y con Servicios
Mucha gente corre un servidor IRCd y lo quieren linkear a otro, para formar una red. También corren servicios u otro pseudo-servidor para agregarle servicios a sus usuarios.
Esta guía tiene las instrucciones para poder linkear a otros servidores, y es valida para cualquier version 1.1 de InspIRCd.
Antes de Empezar
Primero, debes estar seguro de tener la ultima version de InspIRCd o de los servicios, etc. La mayoría de las compatibilidades son con las versiones mas recientes de cada programa que uses. Esas versiones pueden estar disponible en nuestro sitio o en sourceforge o en el SVN.
Descomprime, Configura e instala todos los programas que vayas a usar.
Configuración de InspIRCd para Linkear
Cuando estés configurando tus servidores InspIRCd, la configuración del Operador (etiquetas <class> y <type>) deben ser identicas en todos los servidores. También tienes que estar seguro de cargar los mismos módulos en todos los servidores.
SI NO SIGUES LAS INSTRUCCIONES AL PIE DE LA LETRA, TENDRÁS DESINCRONIZACIONES EN TU RED!
Tu necesitas cargar el modulo m_spanningtree.so. Este modulo hace posible que todas las funciones para linkear de InspIRCd sean posibles, sin el, no puedes linkear servidores. Para cargarlo, en tu configuración debes poner:
<module name="m_spanningtree.so">
Una vez cargado, las siguientes etiquetas serán soportadas en tu archivo de configuración:
<bind address="" port="7777" type="servers">
Sin m_spanningtree.so, el tipo servers no podrá ser usado. Para seguir con esta guía, supongamos que vas a linkear tus servidores bajo el puerto 7777. Recuerda que puedes usar cualquier puerto que quieras.
Cada servidor tambien debe tener la etiqueta <link>, esto hará que los servidores coincidan con la etuiqueta <link> para poder conectar. Por ejemplo, imagina que tienes 2 servidores, servidor.a (con la direccion IP 4.3.2.1) y servidor.b (con la direccion IP 1.2.3.4), en la configuración de servidor.a debes tener:
<link name="servidor.b"
ipaddr="1.2.3.4"
port="7777"
sendpass="contraseña1"
recvpass="contraseña2">
...y en la configuración de servidor.b, debes tener:
<link name="server.a"
ipaddr="4.3.2.1"
port="7777"
sendpass="contraseña2"
recvpass="contraseña1">
NOTA: Es importante recordar, de que aunque en la etiqueta <link> aparezca una opción llamada ipaddr, también se pueden poner hostnames ahí. Se podrá demorar un poquito más al conectar, ya que debe resolver la dirección del hostname.
Configuración Avanzada
Autoconectar Servidores
La configuración para linkear les puede dar trabajo, pero por ejemplo, para unas situaciones más compejas, tu necesitas configuraciones más avanzadas. El primer problema es, que con la configuración dada anteriormente, si tienes una falla en la conexion y hay un netsplit, los servidores de deslinkearan y un operador tendrá que usar de nuevo el comando /CONNECT. Para aliviar este problema, puedes agregar la variable autoconnect a uno de los servidores (NO TODOS):
<link name="servidor.b"
ipaddr="1.2.3.4"
port="7777"
autoconnect="60"
sendpass="contraseña1"
recvpass="contraseña2">
Esto hará que servidor.a se auto conecte cada 60 segundos. No debes poner esta opción a los dos servidores, porque si los dos servidores tratan de conectarse al mismo tiempo y sucede, puede haber un gran riesgo de colisiones de nicks e incluso de los mismos servidores.
Conexiones Encriptadas entre Servidores
Si tu quieres hacer una conexion segura entre los servidores, con encripcion tu puedes habilitar la opcion de encriptación en el link. Para hacer eso, debes estar seguro de que m_ssl_openssl.so o m_ssl_gnutls.so sea cargado. Antes del modulo m_spanningtree.so en tu archivo de configuración, como se muestra abajo;
<module name="m_ssl_openssl.so"> <module name="m_spanningtree.so">
Para concretar el enlace, deben usar el mismo modulo de SSL. Debes actualizar las etiquetas para que al linkear se soporte la conexión segura. Usa el valor 'openssl' si estas usando m_ssl_openssl.so, o el valor 'gnutls' si usas el modulo m_ssl_gnutls.so.
<link name="servidor.b"
ipaddr="1.2.3.4"
port="7777"
autoconnect="60"
sendpass="contraseña1"
recvpass="contraseña2"
transport="openssl">
Cuando conectes los servidores, estarán encriptados. Y se mostrará algo así:
--- SNOTICE *** LINK: Verified incoming server connection from test.chatspike.net[127.0.0.1] (test test) --- SNOTICE *** LINK: Connection from test.chatspike.net[127.0.0.1] using transport openssl --- SNOTICE *** LINK: Bursting to test.chatspike.net. --- SNOTICE *** LINK: Finished bursting to test.chatspike.net.
Conexiones Comprimidas entre Servidores
Si quieres una conexion comprimida para poder guardar bando de ancha, puedes habilitar zlib en el link. Para hacer eso, debes estar seguro de cargar el modulo m_ziplink.so y despues de m_spanningtree.so en tu archivo de configuración, como se muestra abajo;
<module name="m_ziplink.so"> <module name="m_spanningtree.so">
Comprueba de que la opción esté al último, como muestra el ejemplo:
<link name="servidor.b"
ipaddr="1.2.3.4"
port="7777"
autoconnect="60"
sendpass="contraseña1"
recvpass="contraseña2"
transport="zip">
Cuando se conecten tus servidores, ellos estarán usando una conexión comprimida. Y se mostrará algo así:
--- SNOTICE *** LINK: Verified incoming server connection from test.chatspike.net[127.0.0.1] (test test) --- SNOTICE *** LINK: Connection from test.chatspike.net[127.0.0.1] using transport zip --- SNOTICE *** LINK: Bursting to test.chatspike.net. --- SNOTICE *** LINK: Finished bursting to test.chatspike.net.
NOTA IMPORTANTE: Trata de nunca mezclar los módulos de SSL con la Compresión en el mismo link. Esto gastará CPU y memoria, porque el protocolo SSL negocia compresión automáticamente, así que es innecesario.
Conexion "Failover"
La conexión "Failover", hará que automaticamente te conectes a otro servidor, si es que el servidor principal al que tratas de conectarte esté no disponible.
<link name="servidor.b"
ipaddr="1.2.3.4"
port="7777"
autoconnect="60"
sendpass="contraseña1"
recvpass="contraseña2"
failover="servidor.c">
With this configuration, when you link server.b, if the connection is unsuccessful, then InspIRCd will instantly attempt to link server.c instead. If server.c is unsuccessful, any of its failover settings (if any) are followed. Note that when using failover links, only errors which occur before a connection is accepted are considered to be candidates for a failover. For example, 'Connection refused' or 'Connection timed out' will cause a failover, but 'invalid password' will not. This is because if the server is up and accepts the connection, it is running and just wrongly configured and failover should not occur.
U-Lines
Services and various other pseudo-servers (such as Defender) must be U lined. A U lined server has extra privileges which allow the server to perform such parlour tricks as opping users from outside a channel, or executing commands which are not in the <class> they are using.
If a server must be U lined, then it must be U lined on all servers (you must not forget one, or that server will attempt to stop mode changes and it all gets desynced), using the following configuration tag:
<uline server="server.s">
This assumes that we want to uline server.s. If you want to U line several servers, you must have several tags (do not put several addresses into one tag, this will not work).
Linking The Servers
On IRC, once you are opered, and the configuration laid out above is in place correctly, you may now link your servers. For the sake of this example, we will assume that you are opered and connected to the ficticious server server.a. You would type this:
/CONNECT server.b
And, if everything is set up correctly and all goes to plan, you will see text like this in your notices window of your client:
[15:14] --- *** CONNECT: Connecting to server: server.b (1.2.3.4:7777) [15:14] --- *** Connection to server.b[1.2.3.4] established. [15:14] --- *** Bursting to server.b [15:14] --- *** Finished bursting to server.b
If you had an oper also sitting on server.b, they would in turn see the following:
[15:14] --- *** Verified incoming server connection from server.a[4.3.2.1] (Other server) [15:14] --- *** Bursting to server.a. [15:14] --- *** Finished bursting to server.a.
Users will join, servers will merge, and we're done! That's all there is to it!
Remote connecting
If you want to connect server.b and you are not currently on server.a, you can use the RCONNECT command:
/RCONNECT server.a server.b
You may use wildcards in either of these fields. All servers matching the wildcard in the first parameter will answer, so if you want to make all servers try to connect to server.b for example, you can issue a command like this:
/RCONNECT * server.b
Note that in most cases this is not useful, except for when you are trying to relink your network after a particularly large split.
Taking down Server Links
To remove a server which is linked in InspIRCd, connect to the server, and use /SQUIT. For example if you are on server.a and you want to quit server.b, issue the following command:
/SQUIT server.b
This will cause server.a to close its connection to server.b.
Remote SQUIT
You can use /RSQUIT (which takes two parameters) if you want to disconnect a remote server (one youre not directly connected to):
/RSQUIT server.c server.b
This tells server.b to disconnect its link to server.c.
