Nota de Importancia
Este documento pretende explicar el funcionamiento del sistema de Base de Datos Distribuídas que el DarkU ha heredado de iRC-Hispano. Si desea información detallada del funcionamiento del protocolo dirijase a http://www.argo.es/~jcea/ . Para el funcionamiento de nuestras bases de datos sintaxis y modificaciones que emplea del DarkU lea el documento que se expone a continuación.
Este documento intentaré mantenerlo lo más actualizado posible siendo el principal manual de referencia del DarkU para el funcionamiento de su BDD. Este manual estará adaptado a la última versión del DarkU disponible para su descarga.
Bases de Datos Distribuidas
Una base de datos distribuida es un tipo de base de datos que no reside en un único punto, sino que esta base de datos se archiva en diferentes puntos, por ejemplo de una red. Este tipo de bases de datos requieren ciertos sistemas de coordinación y actualización que eviten desincronismo entre las bases de datos distribuidas.
El objetivo de una base de datos distribuida en el DarkU no es otro que ofrecer la posibilidad de permitir ciertos servicios a nivel de ircd sin necesidad de depender de unos Bots de Servicio centrales. No obstante estos bots serán necesarios para la introducción de valores en la BDD.
El sistema empleado en DarkU es el mismo que se emplea en iRC-Hispano, en cuento a protocolo, con ciertos cambios para adaptarlo a los servicios que se estimaron oportunos. El sistema de BDD esta formado por una serie de «tablas», con estas tablas nos referimos a cada una de las bases de datos que nos servirán para ofrecer un determinado servicio o el almacenaje de unos datos relativos a diferentes temas.
Cada una de estas tablas cuenta con un HASH que se verifica cuando dos nodos hacen un NET.JOIN al producirse esto en caso de ser distinto, los HUBs reenvian la BDD a ese nodo o los valores que no tengan y han cambiado mientras estaba fuera de la red. Cada uno de los registros a su vez es marcado con un numero de serie el cual indica el número de registro, esto nos sirve para una vez identificado un HASH saber que valores han cambiado y no tiene el nuevo nodo y reenviarlo. En cierto modo actua como un sistema de versiones.
Para el paso de una tabla (DB) de un nodo a otro se emplea un comando el DB, este comando esta restringido exclusivamente para servidores y tiene varias opciones como cojer registros, mostrarlos, distribuir un nuevo registro. Los únicos nodos capaces de modificar la BDD son los HUBs, por eso hay que tener cuidado con la configuración de las H-lines.
Si nosotros queremos introducir nuevos registros en la BDD debemos hacerlo con un nodo se servicios de bots que tenga privilegios de HUB (H-line) y emplearemos la siguiente sintaxis:
DB [nodo] [numero de serie] [tabla] [valor] :[contenido]
Los valores mencionados anteriormente se corresponden con los siguientes:
[nodo] -> El servidor al que enviarás el nuevo registro. ‘*’ para enviarlo a toda la red.
[nº serie] -> Se corresponde con el siguiente número a introducir en la BDD, podemos verlo en la ‘S=’ del /stats b sumandole 1 a dicho valor.
[tabla] -> Se corresponde con la base de datos en la que introduciremos los nuevos registros.
[valor] -> Se refiere al nick, IP, etc… sobre el que guardaremos información, varia según la finalidad de la tabla.
[contenido] -> Los datos que asociamos a ese valor.
Tambien tenemos diversos comandos que nos pueden interesas como IRCops o Administradores del DarkU para comprobar y verificar el estado de la Base de datos:
DBQ [nodo] [registro]: Nos muestra en un nodo determinado (‘*’ para todos) el valor para un registro dado
STATS B: Nos muestra el número de registros activos en la BDD y el numero de serie (‘S=’ sumandole 1 nos dará el siguiente valor que debemos emplear para meter un nuevo registro en la BDD)
b Tabla ‘c’ S=000000000 R=000000000
b Tabla ‘i’ S=000000002 R=000000002
b Tabla ‘n’ S=000018799 R=000000287
b Tabla ‘o’ S=000000622 R=000000020
b Tabla ‘v’ S=000000000 R=000000000
b Tabla ‘w’ S=000000051 R=000000002
b Tabla ‘z’ S=000000057 R=000000046
Cuando queremos borrar un registro de una tabla debemos introducir un nuevo registro para esa taba pero sin ningún valor. Esto hará que haya un nuevo registro nulo distribuyendose por toda la red y evitando que ese registro tenga valor alguno.
Las tablas de la BDD (versión 6.xx o superior)
Tabla ‘c’ ([#canal] :[modos])
Tabla para el registro de canales. Todo canal que figure en esta tabla adquiere el modo +r y es persistente (no se elimina de memoria cuando sale el ultimo usuario) manteniendo el topic, modos a pesar de quedarse vacío. El registro debe de ser el nombre del canal y el valor se corresponde con el MLOCK, los modos fijados por defecto en el canal y que no pueden ser cambiados.
Tabla ‘i’ ([IP/Máscara] :[Número de clones])
Es la tabla encargada de regular los clones de la red para permitir excepciones según desde donde se acceda.
Tabla ‘n’ ([nick] :[clave])
Nos permite registrar un nick. Al registrar un nick solo el propietario podrá ponerselo y así disfrutar de modo +r y todas las ventajas que esto conlleva. La clave del nick debe de ir encriptada con el algoritmo TEA.
Nicks Suspendidos -> Cuando añadimos un nick y al final de su clave introducimos un ‘+’, ese nick se considera suspendido, no gozará de +r y será marcado con el modo +S (Suspend) y mostrado en su whois.
Nicks Prohibidos -> Esta tabla tambien permite el registro de nicks prohibidos (Forbidden), estos nicks no los podrá utilizar nadie en la red. Para prohibir un nick en el campo de la clave debe introducirse solamente un ‘*’
Tabla ‘o’ ([nick] :[privilegios])
Esta tabla nos permite poner «BDD flags» a un usuario. Estos flags permitirán al usuario posteriormente la fijación de determinados modos especiales con sus consiguientes privilegios en la red. Estos flags fijados en la BDD podrán ponerse de forma que se pongan automaticamente a un nick cuando se identifique o simplemente permitir a ese nick ponerselo si así lo requiriese.
Los modos positivos serán puestos al usuario nada más identificarse con su nick mientras que los modos negativos (precedidos de un ‘-‘) serán habilitados para que el usuario se los ponga a voluntad. Un ejemlo de privilegios automáticos serían ‘a’, ‘aA’, ‘+a’. Un ejemplo de privilegios para poner a voluntad sería ‘-h’, ‘-hA’. Un ejemplo mixto ‘a-A’ o ‘+a-A’.
La lista de privilegios es la siguiente:
flag ‘a’ -> Administrador de Red.
flag ‘A’ -> Administrador de Servidor.
flag ‘B’ -> Bot oficial de la Red.
flag ‘c’ -> Co-Administrador de Red.
flag ‘h’ -> Operador de Red.
flag ‘p’ -> Pre-Operador de Red.
flag ‘k’ -> Poder usar el modo k.
flag ‘X’ -> Poder usar el modo X.
Tabla ‘v’ ([nick] :[IP virtual])
Establece una Máscara personalizada totalmente para un nick registrado en la tabla n. Cuando un nick tiene una máscara asignada en la tabla v toda su IP real sera substituida por esta de cara a la red.
Tabla ‘w’ ([nick] :[IP virtual])
Establece una máscara personalizada para un nick registrado en la tabla n. Al final del valor de la máscara personalizada añadirá ‘.virtual’. Se puede configurar además el ircd para que al comienzo de la v-mask personalizada muestre o no la IP cifrada, esta configuración se realizará en la tabla z.
Tabla ‘z’ ([valor] :[contenido])
Esta es la tabla de configuración de la red. En ella hay una serie de valores predefinidos para la configuración de la red. A continuación se explican los valores y que deben contener.
‘motd.*’
Estos registros definen un MOTD genérico y global para toda la red. Se introduce el mensaje substituyendo el * por números de linea del 0 hacia arriba (motd.0, motd.1, motd.2,…) Si alguno de estos registros tiene valor «%LOCALMOTD» o no existen se muestra el MOTD local, sino el global.
‘bot.virtual.nickserv’
Define el nick que se asignará para los mensajes de Nickserv derivados del uso de la BDD.
‘bot.virtual.chanserv’
Define el nick que se asignará para los mensajes de Chanserv derivados del uso de la BDD.
‘numero.maximo.de.clones.por.defecto’
Clones máximos permitidos para todas las conexiones que no tengan un registro propio en la tabla i.
‘mensaje.de.demasiados.clones’
Mensaje que se muestra cuando excedes la cantidad de clones disponibles para tu conexión.
‘mensaje.de.capacidad.superada’
Mensaje que se muestra cuando se sobrepasa la capacidad de un servidor.
‘clave.de.cifrado.de.ips’
Clave para generar las IPs virtuales que se asignan por defecto.
‘nombre.de.la.red’
El nombre que usa la red. Gracias a este parametro se puede cambiar y fijar un NETWORK name general y uniforme a toda la red.
‘dominio.de.la.red’
El dominio que usa la red. Util para mostrar en la protección de los servidores o en las IPs virtuales generadas en modo automático.
‘ocultar.ip.cifrada.en.la.virtual2’
Si se introduce un contenido a este valor las IPs virtuales de la tabla w incluirán delante de la parte personalizada la IP virtual cifrada.
‘ocultar.servidores.en.el.map’
Al introducir un contenido a este valor se habilitará la variable y se ocultaran los servidores en el MAP, LINKS, WHOIS y WHO no sabiendo en que servidor esta cada usuario. Si el valor es 1 en el MAP se oculta solo el nombre del servidor con un ‘*’, si el valor es 2 se oculta el MAP totalmente.
‘u:*’
Equivale a una U-line pero distribuida a toda la red. El * debe substituirse por el nombre del servidor. El valor de las lineas U se ignora.
‘p09:*’
Nos permite definir nodos P09 que se linkaran a la red. El * debe de ser substituido por el nombre del servidor en cuestion y el valor será el numérico que tendrá en la red.