Generalidades
El UDB tiene como principal objetivo distribuir información a nivel global en la red y de forma síncrona.
Una de las formas para distribuir esa información es hacerlo por bloques, permitiendo su paginación y clasificación de una forma clara y ordenada.
Al tratar la información por bloques permite una gran y plena flexibilidad. Los bloques se estructuran por ítems y valores (numéricos y alfanuméricos).
Así pues, estos bloques se estructuran de forma jerárquica en árbol. Puede imaginarse como un árbol que se va ramificando, cuyas ramas son los items y sus hojas los contenidos.
Esta enorme versatilidad ofrece un sinfín de posibilidades.
Versión actual:
3.6
Bloques
Puesto que existen dos clases de valores (numéricos y alfanuméricos) es necesario distinguirlos de alguna forma.
Todos los valores que estén precedidos por el símbolo '*' se tomarán como valores numéricos. De otra forma, alfanuméricos.
No obstante, si son datos alfanuméricos que empiezan por '*' y deben ser tratados como tales, deben escaparse, es decir, utilizar \*.
Existen cinco bloques: N (nicks), C (canales), I (ips), S (set) y L (links).
El bloque N contiene los nicks y todo lo que les concierne. Se estructura de la siguiente forma:
- N::<nick>::P <contraseña> -> contiene la contraseña del nick
- N::<nick>::V <vhost> -> su host virtual
- N::<nick>::B <motivo> -> razón de su prohibición (si este bloque está presente no se permite su uso)
- N::<nick>::S <motivo> -> razón de su suspenso (si este bloque está presente recibe el flag +S)
- N::<nick>::O *<bits> -> flags de operador (preoper, oper, devel, etc.). Es un número:
BDD_OPER 0x1 -> recibe automáticamente el flag +h
BDD_ADMIN 0x2 -> recibe automáticamente los flags +oa y privilegios globales de administrador.
BDD_ROOT 0x4 -> recibe +oN y privilegios de gestión de servidores (/rehash, /restart, etc.)
NOTA: se requiere la anteposición de '*' para indicar que es un valor numérico (entero largo).
- N::<nick>::D <metodo> -> metodo de cifrado de la contraseña. Métodos que acepta:
{"plain"|"crypt"|"md5"|"sha1"|"sslclientcert"|"ripemd160"}
- N::<nick>::M <modos> -> contiene los modos de operador que puede utilizar:
ohaAOkNCWqHX
- N::<nick>::K <snomask> -> contiene las snomask de operador que puede utilizar:
cfFjveGnNqS
- N::<nick>::W <whois> -> contiene su swhois
- N::<nick>::A <ip> -> acceso sólo a esta ip (CIDR para un rango de ips)
Todos estos campos se dan en el momento que el usuario se identifica correcamente con /nick nick:pass
NOTA UDB3.2: A partir de esta versión, se aceptan las contraseñas generadas por el comando /mkpasswd.
El bloque C contiene los canales y todo lo que les concierne. Se estructura de la siguiente forma:
- C::<#canal>::F <nick> -> nick del fundador. El fundador recibe +oq al entrar al canal
- C::<#canal>::M <modos> -> modos del canal
- C::<#canal>::T <topic> -> topic del canal
- C::<#canal>::A::<usuario> NULL -> es un subloque que contiene los nicks de las personas que pueden entrar (no precisa contenido). Si este bloque está presente sólo podrán entrar en el canal los nicks que figuren en sus subloques.
Por ejemplo C::<#canal>::A::Trocotronic NULL -> Sólo Trocotronic, con el modo +r, podrá entrar en el canal.
- C::<#canal>::B <motivo> -> #canal prohibido
- C::<#canal>::S <motivo> -> no da +oq al fundador
- C::<#canal>::P <contraseña> -> Contraseña del canal para darse +ao. Se usa /join # pass o /invite nick # pass
- C::<#canal>::D <desafio> -> Desafío de la contraseña del canal
- C::<#canal>::O *<opts> -> Fija distintas opciones para el canal
C_OPT_PBAN 0x1 -> Si figura este flag, hay protección de bans: sólo el autor de los bans puede quitarlo (excepto founder y opers).
C_OPT_RMOD 0x2 -> Si figura este flag, los modos que haya en canal estarán bloqueados, no se podrán cambiar (excepto founder y opers).
NOTA: se requiere la anteposición de '*' para indicar que es un valor numérico (entero largo).
El bloque I contiene las ips y todo lo que las concierne. Se estructura de la siguiente forma:
- I::<ip|host>::S *<nº clones> -> nº de clones que se permiten desde esa ip
NOTA: se requiere la anteposición de '*' para indicar que es un valor numérico (entero largo).
- I::<ip|host>::E <GZQST> -> Es inmune a
Glines,
Zlines,
Qlines,
Shuns y
Throttles.
- I::<ip>::H <host> -> Establece una resolución DNS inversa para esa ip, haciéndola apuntar a ese host.
El bloque S contiene aspectos de la configuración de la red. Se estructura de la siguiente forma:
- S::L <clave alfanumérica> -> la clave de cifrado a usar para encriptar el host de los usuarios
- S::J <sufijo> -> sufijo para las ip virtuales
- S::N <nick!user@host> -> máscara de NickServ
- S::C <nick!user@host> -> máscara de ChanServ
- S::I <nick!user@host> -> máscara de IpServ
- S::S *<nº clones> -> número de clones permitidos en la red
NOTA: se requiere la anteposición de '*' para indicar que es un valor numérico (entero largo).
- S::T <mensaje quit> -> mensaje que se muestra si esta conexión sobrepasa su capacidad otorgada
- S::Q <mensaje quit> -> mensaje que se muestra si se rebasa los clones permitidos
- S::D <metodo> -> desafío global con el que se cifran las contraseñas
- S::F <v>:<s> -> Si el usuario intenta más de <v> veces durante <s> segundos una contraseña incorrecta, es bloqueado.
- S::P <prefijos> -> Prefijos para los modos qaohv en este orden. Por defecto, ~&@%+.
El bloque L contiene información sobre links de servidores. Se estructura de la siguiente forma:
- L::<servidor>::O *<opts> -> Fija distintas opciones para este link
L_OPT_DEBG 0x1 -> Establece este servidor como debug. Recibe todos los cambio de usuarios UDB (modo +r por ejemplo).
L_OPT_PROP 0x2 -> Establece este servidor como propagador. Es el único servidor que puede propagar datos por la red. Sólo puede haber
UNO.
ATENCIÓN: Si se propaga esta opción y ya hay otro link propagador, el bloque entero se borrará!
L_OPT_CLNT 0x4 -> Permite la conexión de clientes en el caso de que sea un servidor no-UDB leaf y que a su vez esté configurado como
uline.
El bloque K contiene las diferentes *lines que se desean guardar. Se estructura de la siguiente forma:
- K::F::=<regexp>::T <tipo -> Tipo de target al que afecta la regexp. Misma sintaxis que /spamfilter.
- K::F::=<regexp>::A <accion -> Acción a tomar. Misma sintaxis que /spamfilter.
- K::F::=<regexp>::K *<tkltime -> Duracción de la *line si se usa. Misma sintaxis que /spamfilter.
NOTA: se requiere la anteposición de '*' para indicar que es un valor numérico (entero largo).
- K::F::=<regexp>::R <razon> -> Razón de la line. Misma sintaxis que /spamfilter.
- K::G::<hostmask>::R <razon> -> Razón para la gline.
- K::Z::<ip>::R <razon> -> Razón para la zline.
- K::S::<hostmask>::R <razon> -> Razón para el shun.
- K::Q::<nick>::R <razon> -> Razón para la qline.
NOTA SOBRE EL SPAMFILTER:
Puesto que las regexp pueden contener espacios, deberán cifrarse en BASE64 y mandarse con el símbolo '=' delante para indicar que están cifradas y deben descifrarse.
La línea de spamfilter no se ejecuta hasta que no se recibe la línea correspondiente a la razón (R). Es decir, si no se recibe esta línea, el spamfilter no actuará. Por esta razón, la línea R debe ser la última en enviarse.
Estos cuatro bloques se guardan en distintos archivos en forma
binaria. Es muy importante este dato, puesto que garantiza el mismo tamaño bajo todos los sistemas operativos.
Para evitar manipulaciones externas, estos cuatro archivos están controlados por un sistema que detecta si se ha modificado un archivo vía externa. Si se diera este caso, se borra todo el archivo
y se solicita de nuevo en caso de estar conectado.
Tokens
Desde la versión 3.5, los ítems de cada bloque pueden tokenizarse (activo por defecto) mediante configuración pre-compilación. Se recomienda usar los ítems tokenizados para ahorrar espacio tanto en el disco duro como en las negociaciones.
Su equivalencia se define en la siguiente tabla:
| Bloque | Ítem | Token |
| N (nicks) | pass | P |
| vhost | V |
| forbid | B |
| suspendido | S |
| oper | O |
| desafio | D |
| modos | M |
| snomasks | K |
| swhois | W |
| acceso | A |
| C (canales) | fundador | F |
| modos | M |
| topic | T |
| accesos | A |
| forbid | B |
| suspendido | S |
| pass | P |
| desafio | D |
| opciones | O |
| I (ips) | clones | S |
| nolines | E |
| host | H |
| S (set) | clave_cifrado | L |
| sufijo | J |
| NickServ | N |
| ChanServ | C |
| IpServ | I |
| clones | S |
| quit_ips | T |
| quit_clones | Q |
| desafio | D |
| flood | F |
| prefijos | P |
| L (links) | opciones | O |
| K (*lines) | tipo | T |
| accion | A |
| tkltime | K |
| razon | R |
Comandos
Toda la manipulación y tratamiento de los bloques se hace mediante el comando de IRC DB. La sintaxis básica es la siguiente:
:<servidor> DB <destino> <comando> <parámetros>
El servidor es el nodo que efectúa el comando. Algunos de estos comandos requieren que sea HUB. Si se da el caso y no lo es, el comando no se procesa y
no se propaga.
El destino es el servidor de destino. Puede aceptar una máscara (ej: *.redyc.com).
El comando es la orden que se quiere solicitar. Estos comandos son:
- INF: solicita información.
- RES: solicita un resumen.
- INS: inserta un registro (HUB).
- DEL: borra un registro (HUB).
- DRP: borra un bloque (HUB).
- ERR: manda un error.
- OPT: optimiza.
- FDR: fin de resumen.
- BCK: copia de seguridad.
- RST: restaurar copia de seguridad.
INF
Pide información sobre un bloque. Su sintaxis es:
:<servidor> DB <destino> INF <bloque> <crc32> <última-hora-OPT>
El bloque sólo puede ser N, C, I, S o L, según se precise. El parámetro crc32 corresponde al valor del cifrado del contenido de su archivo mediante el algoritmo CRC32.
El último parámetro corresponde a la última hora GMT en que se ha recibido un OPT. Si no se ha recibido ninguno, vale 0. Cada vez que se recibe un OPT se guarda
la hora en que se ha efectuado el comando y es la que se utiliza como último parámetro.
Por ejemplo,
:servicios.colossus DB irc.redyc.com INF N 86BDAF5B 0
Donde el crc32 corresponde al crc32 del contenido de su archivo (el archivo en modo binario).
Este comando va estrechamente ligado al RES e inicia la unión de dos servidores. Véase más adelante.
Conviene que el servidor de destino sea uno concreto (no usar '*.redyc.com' por ejemplo).
RES
Solicita un resumen. Su sintaxis es:
:<servidor> DB <destino> RES <bloque> <bytes>
El parámetro bytes corresponde al número de bytes que ocupa el archivo correspondiente a este bloque.
Por este motivo, es muy importante manipular los archivos en modo binario, ya que si no se hace este número puede variar entre servidores.
Si al solicitar este comando el número de bytes no se corresponde, el nodo que más registros tiene (HUB
seguro) se los manda, a partir del byte especificado.
Conviene que el servidor de destino sea uno concreto (no usar '*.redyc.com' por ejemplo).
INS
Inserta un registro en el bloque. Su sintaxis es:
:<servidor> DB <destino> INS <byte> <bloque>::<item>::<item>::...::<item> <valor>
El parámetro byte indica en qué byte del archivo debe insertarse este registro. Si este byte no es el que le corresponde,
no se insertará.
Por ejemplo,
:servicios.colossus DB * INS 98 N::Trocotronic::V trocotronic.redyc.com
Insertaría un registro en toda la red, siendo 98 el byte al que toca escribir en el archivo (recomiendo mandar siempre el tamaño del archivo en aquel instante).
El control de bytes es delicado, puesto que un byte por encima o por debajo pararía la propagación y el registro no se insertaría. Se utiliza básicamente para mantener los archivos
completamente sincronizados y que no haya desorden en la inserción de registros.
Cabe mencionar que si un registro, con su contenido, es idéntico al que hay, no se insertará y devolverá un ERR E_UDB_REP. Es decir, mandar dos veces o más la misma línea, sólo provocará que se inserte una vez el registro.
DEL
Borra un registro de un bloque. Su sintaxis es:
:<servidor> DB <destino> DEL <byte> <bloque>::<item>::<item>::...::<item>
El parámetro byte es el mismo que en el caso anterior, puesto que los registros borrados se insertan en el archivo sin valor.
Por ejemplo, el archivo nicks.udb podría estar estructurado de la siguiente forma:
Trocotronic::P a5ed0961cc1ea2df74884c29a2eff96b
Trocotronic::D md5
Trocotronic::O *4
Trocotronic::V trocotronic.root.redyc.com
Trocotronic::O
Como se observa, la última línea quita el estado de operador, puesto que no hay contenido. Nótese que los saltos de línea son con '\n' y no con '\r\n'.
DRP
Borra un bloque a partir de un byte. Su sintaxis es:
:<servidor> DB <destino> DRP <bloque> <byte>
Trunca un archivo a partir del byte especificado. Generalmente se usa 0 para borrarlo completamente.
Este bloque es muy delicado, puesto que un byte mal especificado cortaría los registros por el medio.
Es muy importante utilizar este comando con cabeza, puesto que puede causar desincronización y nadie sabe qué efectos puede provocar.
ERR
Manda un error. Su sintaxis es algo variable, según el error que se cometa. No repercute en los servidores. Tan sólo es útil para los desarrolladores y conocer
por qué ocurre el error. Su sintaxis es:
:<servidor> DB <destino> ERR <comando-respuesta> <errno> [parámetros]
El comando-respuesta corresponde al comando que ha generado el error. El errno corresponde al número de error. Estos son:
- E_UDB_NODB (1): el bloque no existe.
- E_UDB_LEN (2): el número de bytes no se corresponde.
- E_UDB_NOHUB (3): no eres hub y este comando requiere que lo seas.
- E_UDB_PARAMS (4): faltan parámetros y el comando no se puede propagar.
- E_UDB_NOOPEN (5): ha sido imposible abrir el archivo.
- E_UDB_FATAL (6): ha ocurrido un error inesperado.
- E_UDB_RPROG (7): Existe un resumen en progreso.
- E_UDB_NORES (8): Ha mandado un FDR sin haber solicitado un RES.
- E_UDB_FBSRV (9): No tiene permisos para propagar registros (propagador no coincide).
- E_UDB_REP (10): El dato que se manda a insertar ya existe y es el mismo.
Por ejemplo, una respuesta típica de error sería:
:irc.redyc.com DB servicios.colossus ERR INS 2 N 83
Sería una respuesta de error a servicios.colossus puesto que ha mandado un INS al bloque N y el número de bytes no se corresponde (él tiene 83).
Si un servidor recibe una respuesta 2, truncará este bloque a partir del número de bytes que le indique y propagará un DRP bytes en sentido contrario.
Conviene que el servidor de destino sea uno concreto (no usar '*.redyc.com' por ejemplo).
OPT
Optimiza un archivo. Cada vez que se propaga este comando se compacta el bloque de tal forma que se eliminan los registros repetidos y no se insertan en el archivo.
Este comando es útil hacerlo por lo menos una vez al día, puesto que reduce considerablemente el tamaño de los archivos.
:<servidor> DB <destino> OPT <bloque> <hora-GMT>
La hora a usar es la que haya en el momento de propagar el comando en la franja GMT (funciones time(0) en C o $gmt en mIRC).
FDR
Indica que se ha terminado el resumen de un bloque. Este comando debe mandarse después del último INS o DEL (en caso de existir) a un servidor que ha solicitado un RES.
Si no se utiliza, el servidor seguirá pendiente de los datos en la red y no se podrán insertar nuevos registros.
:<servidor> DB <destino> FDR <bloque> 0
BCK
Realiza una copia de seguridad de un bloque en particular y le asigna un nombre.
Si se realiza una copia con un nombre ya existente, se sobreescribirá y se perderá la que hubiera.
:<servidor> DB * BCK <bloque> <nombre>
Se recomienda darle un nombre tipo HHmmDDMMYYYY, donde HH son la hora, mm el minuto, DD el día, MM el mes y YYYY el año que se realiza la copia.
Los servidores que estén compilados con soporte ZLIB, guardarán la copia en un archivo comprimido reduciendo a la mitad su tamaño aproximadamente.
RST
Restaura una copia de seguridad realizada con BCK.
NOTA: el nombre de la copia debe existir. Si se propaga un nombre que no existe, toda la red perderá ese bloque y se propagará de nuevo.
Por tanto, si hay algún servidor que no posea esa copia, truncará la red a partir de este punto.
:<servidor> DB * RST <bloque> <nombre> <hora>
La hora que se especifica es la misma que la se usa en un OPT. Todos los servidores actualizarán su hora OPT a ésta.
Negociación
En el momento que se unen dos servidores hay que seguir unos pasos para sincronizar los bloques.
Lo primero que se manda es la cabecera PROTOCTL UDB3.6[=parámetro1,parámetro2,etc], antes de PASS y de SERVER. Si se soportan más protocolos se usarán a continuación. Por ejemplo PROTOCTL U3.6=params TOKEN VL.
De momento está reservado para un uso futuro.
Por ejemplo, para el caso de Colossus, sería PROTOCTL UDB3.6 VL NOQUIT...
Una vez se han linkado empieza la sincronización. Es muy importante que
toda la negociación se haga antes de recibir el EOS (End Of Synch). Si se inserta (y en tal caso, se propaga) un registro antes del EOS,
sus efectos son impredecibles. Así, que es bueno tener un control para que si no se ha recibido el EOS no se propaguen registros nuevos (menos los que se resumen, obviamente).
La negociación y consulta del estado de bloques se inicia con el envío de un INF. El servidor de destino debe ser solamente el servidor al que se linka (no usar '*').
Una vez se ha recibido el INF remoto se procede a :
- Si los crc32 son distintos:
- Si el gmt recibido es mayor: vaciar todo el bloque y solicitarlo de nuevo (RES 0).
- Si el gmt recibido es igual, pedir un RES indicando el número de bytes que posee el archivo de dicho bloque.
El nodo que tenga más registros deberá pasarle al otro los que le faltan. Para ello situará el puntero en el archivo justo en el byte indicado en el RES y empezará a mandar los registros desde ese byte.
- Si los crc32 son idénticos: está todo en orden, no hay que hacer nada.
Cualquier resumen de bloques se efectúa mediante INS (si hay valor) y DEL (si no hay valor).
Un ejemplo clásico sería este:
:servicios.colossus DB irc.redyc.com INF C 86BDAF5B 0
:servicios.colossus DB irc.redyc.com INF I 8391F83D2 1107168820
:servicios.colossus DB irc.redyc.com INF N 2FE83A7B 0
:servicios.colossus DB irc.redyc.com INF S 4E91A417 0
:servicios.colossus DB irc.redyc.com INF L 3F12B912 0
:irc.redyc.com DB servicios.colossus INF C 86BDAF5B 0
:irc.redyc.com DB servicios.colossus INF I 8391F83D2 0
:irc.redyc.com DB servicios.colossus INF N 2FE83A7B 0
:irc.redyc.com DB servicios.colossus INF S 4E91A417 0
:irc.redyc.com DB servicios.colossus INF L 3F12B912 0
Como los crc32 coinciden, no se prosigue porque todos los archivos son idénticos (aunque las horas sean distintas).
Veamos otro ejemplo:
:servicios.colossus DB INF irc.redyc.com C 86BDAF5B 1107168820
:servicios.colossus DB irc.redyc.com INF I 8391F83D2 1107168820
:servicios.colossus DB irc.redyc.com INF N 2FE83A7B 1107168820
:servicios.colossus DB irc.redyc.com INF S 4E91A417 1107168820
:servicios.colossus DB irc.redyc.com INF L 3F12B912 1107168820
:irc.redyc.com DB servicios.colossus INF C 86BDAF5B 1107168820
:irc.redyc.com DB servicios.colossus INF I 8391F83D2 1107168820
:irc.redyc.com DB servicios.colossus INF N F97381A8 1107168820
:irc.redyc.com DB servicios.colossus INF S 4E91A417 1107168820
:irc.redyc.com DB servicios.colossus INF L 3F12B912 1107168820
:servicios.colossus DB irc.redyc.com RES N 2738
:irc.redyc.com DB servicios.colossus RES N 2338
:servicios.colossus DB * INS 2338 N::Trocotronic::M kXW
:servicios.colossus DB * INS 2357 N::Trocotronic::O *4
:servicios.colossus DB * DEL 2375 N::Trocotronic::V
...
:servicios.colossus DB irc.redyc.com FDR N 0
Todas las horas son las mismas, pero como se ve, el bloque N está desincronizado, puesto que los crc32 no coinciden. Así que se mandan los RESúmenes de este bloque. Y como servicios.colossus tiene más registros, se los manda.
Seguiría insertando registro o borrándolos según se diera. Atención al número de bytes que se va incrementando.
Partimos del byte 2338, el siguiente registro estará en el byte 2357 puesto que "Trocotronic::M kXW" ocupa 18 bytes + 1 del \n = 19 bytes. 2338 + 19 = 2357.
El siguiente estará en 2357+18=2375, puesto que "Trocotronic::O *4" ocupa 17 bytes + 1 del \n. El siguiente estará en 2375+15=2390 puesto que "Trocotronic::V" ocupa 14 bytes + 1 del \n.
Y así sucesivamente.
DBQ
Este comando proporciona diversa información muy útil. Su sintaxis es:
/DBQ [servidor_destino] <bloque>[::contenido]
- servidor_destino: es opcional e indica a qué servidor hay que efectuar esta consulta. Acepta comodines.
- bloque: corresponde a los bloques soportados: N, C, I, S o L.
- contenido: devuelve el contenido de una cadena en formato item::item::item valor. Si se especifica un item sin valor, se devolverán los items inferiores, si los hubiere.
Por ejemplo, /dbq C::#redyc::F devolvería el fundador de #redyc.
/dbq N::Trocotronic devolvería toda la información de Trocotronic (modos, snomasks, oper, etc.).
/dbq * S::C todos los servidores enviarían un raw indicando la máscara de ChanServ.
/dbq [*] <bloque> este comando es especial respecto a los anteriores. Si no se especifica ningún contenido, se manda información de interés perteneciente a este bloque.
El raw devuelto viene dado por la siguiente forma:
<id> <tot> <pos> <TS> <crc32> [*]
- id: id o identificación del bloque.
- tot: número de registros de primer nivel que tiene ese bloque. Por ejemplo, nos dice cuántos nicks, canales o ips hay en cada bloque.
- pos: siguiente posición a escribir en el archivo.
- TS: hora del último OPT.
- crc32: desafío crc32 correspondiente al archivo del bloque.
- *: si está presente un asterisco al final, indica que hay un resumen en curso de este bloque. Posiblemente por no haber mandado a tiempo el comando FDR.
Mencionar, que para una correcta sincronización, al hacer /dbq * <bloque> todos los servidores deben devolver la misma información (el parámetro hash puede variar entre servidores).