Por Lehenda ( Cservice Team )

Muchas de las FAQ (Frequent Asked Questions) que se tratan en este apartado son dudas y problemas que se atienden cada dia en #opers_help. Por tanto, este documento no es solo una web de preguntas y respuestas, sino tambien un HOW TO (como hacerlo), asi que en los casos en los que no sea estrictamente necesaria la participacion de un IRCop o un Cservice se explicara el modo en el que el usuario puede arreglar el problema.

1. Porque al identificarse ante Scytale, este da el op (@) pero luego una de las redes lo quita?
2. Quien son y a que se dedican los IRCop y Cservice?, como se puede contactar con ellos?.
3. Que son, en que consisten, y para que sirven las mascaras?
4. Se han cambiado los modos en un canal; como se puede arreglar esto cuando no se tiene acceso al canal porque los modos +k o +i estan activados. Que se debe hacer para cambiarlos?
5. Por que un determinado nodo no deja entrar y dice que la IP tiene una K-line? ademas luego responde que el server debe de tener Resolucion Inversa, que es eso?.

6. Poteccion de canales: ¿Que es un Takeover?

7. ¿Que es un split y que provoca? ¿Porque desaparecen los demas usuarios: se han caido?



1. Porque al identificarse ante Scytale, este da el op (@) pero luego una de las redes lo quita?
Primero hay que empezar explicando lo que es un 'desinch' (abreviatura para 'desinchronization'). Como su nombre indica es una desincronizacon entre redes, del modo que estas no contienen los mismos operadores, y por tanto no reconocen como operador a Scytale en el canal. O sea que no es problema del acceso sino de las redes (en partucular del servidor que este negando todo lo que Scytale o cualquier usuario haga).


2. Quien son y a que se dedican los IRCop y Cservice?, como se puede contactar con ellos?.
Un IRCop es un colaborador de un servidor y este servidor, a su vez es un nodo del IRC (para entendernos es un IRC Server), o sea no todos los servidores de Internet son servidores de IRC y por tanto no todos tienen un IRCop. El IRCop se encarga principalmente de los problemas que los usuarios que se conectan a traves de ese servidor de Internet y de IRC puedan tener dentro de irc-hispano.org (aunque esto no quiere decir que no se ocupe de los usuarios no conectados mediante su server).

Un Cservice es otro usuario parecido a un IRCop, en verdad, muchas de sus funciones coinciden, aunque el Cservice no esta asociado a ningun servidor. Podriamos decir que un Cservice es un representante autorizado del Service Channel (Servicio de Canales), y su funcion, en terminos generales, es la de ayudar a todo aquel usuario que se encuentre dentro de irc-hispano.org y que pueda requerirle.

Tanto los IRCop como los Cservice tienen como mision conjunta velar por la red y como ya se ha dicho antes muchas de sus funciones son las mismas (hay otras no comunes, como pueden ser autorizacion de canales, decisiones sobre la red... pero no vamos a comentarlas por no hacer mas extensiva esta FAQ).

En contra de la vision que se tiene, los Cop, (llamaremos asi, aunque no es del todo correcto, tanto a los IRCop como a los Cservice), no son maquinas ni nicks sin nadie detras. La razon por la que no contestan a muchos de los chat pueden ser diversas, pero seguro que todas tienen en comun el hecho de que esten velando por la red: ya sea ayudando a otros usuarios, o bien arreglando problemas que se presentan dia a dia. Por tanto, se recomienda tener paciencia cuando se habla con un Cop y este no responde de inmediato; piensa que son unos dos mil usuarios (cuando no son mas) lo que entran cada dia en irc-hispano.org, y casi todos tienen sus propios problemas y dudas.

Los IRCop y Cservice estan facilmente localizables en el canal #opers_help, donde aparte de ayuda, se puede encontrar informacion autorizada; pero sobre todo, RECUERDA, ten paciencia si tu duda o problema no es resuelto al instante. GRACIAS.


3. Que son, en que consisten, y para que sirven las mascaras?
Antes de empezar es mejor recordar o explicar lo que es una IP. Se podra definir IP como un numero o un nombre que el servidor de Internet con el que te conectas te da cada vez que estableces una conexion, ya sea con Internet o el IRC. Para empezar, podemos decir que no siempre es el mismo numero sino que varia en cada conexion (hablaremos de numero -la famosa IP o Internet Protocol- ya que el nombre -DNS- es en definitiva una 'traduccion' de los numeros, para asi poder recordarlos mejor (resolución inversa)).

Pues bien, la IP que el servidor te otorga en cada conexion es distinta, en caso de acceder por un ISP o proveedor de acceso, pero siempre va a tener una parte en comun. Lo veremos mejor con un ejemplo (se recuerda que la IP esta totalmente elegida al azar); asi tenemos la IP 223.254.254.3 , la proxima vez que nos conectemos, nuestra IP podria ser 223.254.254.67 , como se puede ver diferente, pero siempre tendra la primera parte en comun. La parte fija es otorgada por la red a nuestro servidor (o host) mientras que el numero que cambia es el que nos da el servidor. Es lo que llamamos IP dinamica. Ahora que ya se ha explicado lo que es una IP vamos a ver lo que en realidad se necesita para construir una mascara, que es la que en definitiva dara el acceso a Scytale.

Una mascara esta compuesta por nick!user@host. Para evitar los cambios de estos tres parametros se utilizan los *. Asi una mascara general seria *!*@* donde las tres caracteristicas no estan distinguidas y es valida para todos los usuarios independientemente de su servidor o host. De cualquier forma, no se recomienda el uso de un * para el host (la IP), ya que evidentemente eso daria posibilidad a alguien que por cualquier circunstancia conociera una clave registrada a acceder al bot sin estar autorizado debidamente.

Por tanto es preferible dar los accesos al bot cerrando al usuario por mascaras, es decir, añadir una mascara por cada maquina con la que se conecte. La forma evidente de evitar esta variablilidad de la IP es, por supuesto, colocar un * en el lugar de la variable. Asi: 223.254.257.* podria ser la mascara de acceso. De todos modos esto no impide que otros usuarios que se conectan con el mismo servidor puedan identificarse, pero la unica forma de evitar el acceso de todos los usuarios de un server al bot, es que el usuario registrado no divulgue su clave.

Sin embargo, y esto conviene avisarlo, en el caso de DNS (IP mediante nombres) las variables van delante de la parte fija, de manera que el host de la mascara queda de la siguiente forma: @*.hispano.org (el server vuelve a ser de nuevo ficticio). La parte general, no variable, como se puede comprobar, queda en ultima posicion.

Se puede tambien, si se quiere, controlar aun mas ese acceso al bot, especificando tambien, dentro de la mascara el IDnick (nick de identificacion ante Scytale, que va antes de !). Eso obligaria al usuario que quiere autentificarse a hacerlo cuando esta usando su IDnick y no funcionaria con otro. La parte del user (despues de !) se puede dejar como variable (*).

NOTA: El ejemplo que hemos presentado correspondiente a las IP pertenece a la clase C de redes, que es el tipo de redes mas pequeño que nos podemos encontrar, ya que solo varia un numero; sin embargo en otro tipo de redes (clases A y B) pueden variar mas numeros, lo que obliga a tener cuidado. De todas formas, siguen la misma sintaxis y se puede poner un * despues de la parte fija independientemente de si cambian uno o dos numeros.


4. Se han cambiado los modos en un canal; como se puede arreglar esto cuando no se tiene acceso al canal porque los modos +k o +i estan activados. Que se debe hacer para cambiarlos?
Para empezar podemos decir que no es necesaria la ayuda de un Cop para solucionar el problema; ademas hay varias formas para que un usuario normal pueda cambiar los modos por si mismo: aqui explicaremos la mas sencilla. Aunque lo que si se necesita es tener acceso al bot para ese canal, si no se tiene, la unica solucion es que un Cop los cambie. Ojo!, nos estamos refiriendo a canales registrados; si el canal no lo estuviera, tambien funcionaria el comando que mostramos a continuacion, pero en este caso habria que introducirlo con /.

Por otra parte, es conveniente avisar que el Cop no esta autorizado a cambiar el modo +b, es decir, el baneo de un canal, pues evidentemente, si un usuario ha sido baneado de un canal, no es asunto del Cop sino de los propios usuarios del canal. Por otra parte, los modos +k (necesidad de clave para el acceso a un canal) y +i (con invitacion) estan prohibidos dentro del grupo de canales registrados (salvo en muy raras excepciones y con canales muy determinados); el usuario debe comunicar a un Cop, si se da la circunstancia de que por si solo no puede quitar el modo +k o +i.

La forma mas sencilla de cambiar los modos es con el comando mode. Una vez identificado ante el bot se pone esta sintaxis, tambien con un /msg o /query a Scytale: mode #canal +/-(modos) *. En el espacio de los modos se especifican los que se quieren quitar o poner. Es importante el * del final ya que elimina la pass, y da acceso total a todos los modos.

Es importante comentar que si el modo que se encuentras puesto en un canal registrado es +k (con clave) se debe de conocer esa clave si lo que se quiere es eliminarla; como seguramente se ignorara, hay que adjudicarle una nueva (la que el usuario quiera) para luego porder asi quitarla. Asi las sintaxis para +k son: primero mode #canal +k (clave inventada) y luego mode #canal -k (clave inventada).


5. Por que un determinado nodo no deja entrar y dice que la IP tiene una K-line? ademas luego responde que el server debe de tener Resolucion Inversa, que es eso?.
Ante todo, convendria avisar que no es culpa del usuario que su maquina este K-lined en un determinado servidor de IRC. Esta suspension temporal no es debida a un mal uso por parte del usuario, sino por la causa que se relata a continuacion.

Podriamos empezar definiendo a grandes rasgos lo que es una K-line; este es un mensaje del servidor, que corta la conexion de un usuario a la red. En este caso particular de Resolucion Inversa, sucede cuando el usuario presenta, por asi decirlo IP numerica, que no ofrece una resolucion de 'ubicacion' de la maquina. Existen varios motivos por los que un determinado server requiera que los usuarios conectados a traves de el cumplan el requisito de Resolucion Inversa. Podriamos señalar como una de las mas importantes, facilitar el trabajo de los operadores de red (IRCop) que por cualquier motivo necesiten saber que conexion esta utilizando un determinado usuario o a que organizacion pertenece. Esto no lo pueden saber a primera vista si la conexion se hace con una IP numerica, y la resolucion de esa IP requiere bastante trabajo (consultas en el RIPE y en el ES-NIC...). Por tanto es muy normal que algunos servidores exijan la Resolucion Inversa. Otra razon para este requisito tambien podria ser que el servidor quisiera mantener estadisticas fiables sobre que usuarios se conectan a el, cuanto tiempo, a que hora...

Para la resolucion de la IP se ha creado un dominio especial, este es in-addr-arpa, que contiene las direcciones IP de todos los host en fragmentos separados (mediante puntos) e inversos. Por ejemplo, una IP (totalmente al azar) de 149.76.12.4 corresponde al nombre de 4.12.76.149.in-addr.arpa . Para asociar los nombres en el dominio de in-addr.arpa con nombres de hosts (maquinas, para entendernos mejor), se utiliza un tipo de recurso denominado PTR. Este trabajo corresponde al servidor y no es necesario que el usuario realice ningun cambio en su maquina, sino que el mismo puede ponerse en contacto con su proveedor, y que luego su server pida a su carrier (Telefonica, etc) el derecho a que se les de el dominio inverso que le corresponde.

Cuando el proveedor ya dispone del in-addr.arpa, la IP numerica se transforma en 'nombres' y asi facilita el trabajo de todo el mundo. A cada maquina que establece una conexion con el se le asignara un nombre ya especificado en los registros del server (dependiendo de que sistema utilice sera un fichero diferente -podemos señalar que en Linux es /etc/named.rev-) y que siempre sera el mismo. Esta invariabilidad se debe al recurso de registro PTR.


 
6. Poteccion de canales: ¿Que es un Takeover? ¿Protege Scytale contra ellos?
Un Takeover es la apropiacion indebida de un canal por un usuario ajeno a el. Existen varias formas de 'secuestrar' un canal: hacerse con control de las @ o cambiar los modos de canal. En cualquier caso, esta apropiacion es ilegal y el usuario tiene derecho a protestar y a que se le devuelva el canal. Antes del desarrollo y puesta en funcinamiento de Scytale los Takeover eran problemas bastante dificiles de resolver y cualquiera podia hacerse con el control de un canal no propio. Esto creaba gran cantidad de problemas y hacia que los usuarios nunca se sintieran protegidos contra los hackers de canal. Hoy en dia, el bot elimina cualquier oportunidad de apropiacion indebida. Vamos a dedicar esta FAQ a mostrar como se evita un Takeover.

Scytale controla el @ del canal, es decir, es siempre reconocido como el operador del canal y nunca puede ejercersele un Deop. Por tanto, en un canal registrado siempre se podra contar con ayuda del bot ante cualquier usuario que intente hacerse con el control del canal (recuerda que no es necesaria la @ para activar comandos en el bot, solo es indispensable la autentificacion). De todas formas, para que nadie que no sea de confianza no tenga @ se pueden activar las opciones de canal para Scytale, strictop y noops (ver cursillo sobre Scytale, en esta misma web, para explicacion y activacion de las opciones del comando chanopt). De esta forma, Scytale protege de forma directa contra los Takeover.

Aun existe otra forma de apropiacion, mas comun si cabe, y esta es el cambio de los modos de canal. El procedimiento que normalmente sigue el que se apropia de canal es el siguiente: se hace con el control de las @ (empresa dificil si Scytale se encuentra dentro y las opciones de canal arriba explicadas en modo on); establece un baneo general del tipo *!*@*; ejecuta un mass-kick y define como modos de canal +stink:

+s: 'secret' (=secreto), el canal existe pero no aparece cuandos se hace un /list.
+t: 'topic', solo los ops pueden cambiar el topic.
+i: 'invite', es necesaria la invitacion de un op del canal para acceder a el.
+n: 'no messages', lo mensajes de fuera del canal no aparecen en el general.
+k: 'key', es indispensable el uso de una clave para entrar en el canal.
Si el asaltante ha seguido los pasos arriba explicados el canal tomado se encontrara en estos momentos cerrado: nadie podra entrar en el y cambiar los modos, solo Scytale permanece dentro. ¿Que se hace contra este tipo de ataques?. Si se ha prestado atencion al cursillo sobre Scytale se vera que existe una forma muy facil de arreglar esto. Recuerda que Scytale se quedara sin compañia en el canal en el momento en el que el asaltante tambien se vaya. Por tanto, si se ha desactivado una de las opciones de canal: el stay (con parametro off), cuando el bot vea que se encuetra solo dentro del canal, el tambien saldra, y por tanto en el momento que el canal vuelva a ser accedido otra vez, Scytale entrara y restablecera los modos predefinidos por defmodes (normalmente +tn) y eliminara los bans no ejecutados a traves de el, que estan solo presentes en el cuadro de canal (para verlos haz doble click con tu raton sobre el panel general).

De cualquier modo, si por alguna circunstancia, el canal siguiera siendo inaccesible, existe otra forma de arreglar el 'desaguisado', mediante el comando resetchan. Este comando hara que Scytale entre y salga del canal y restablezca los modos predefinidos en defmodes quitando los que puso el agresor. Para resetear un canal se requiere como level minimo 350; si no hay nadie que posea ese nivel, es recomendable acudir a un Cservice.

NOTA: Se puede comprobar, que se ha explicado en su totalidad como se hace un Takeover. Esto no se haria si, en la actualidad, un Takeover no fuera totalmente inutil, no reversible o presentara algun problema para el canal. Por otra parte, como se ha visto en esta FAQ, se hace indispensable que por lo menos el administrador del canal y los usarios con levels superiores, comprendan y manejen bien las opciones de canal para Scytale.


7. ¿Que es un split y que provoca? ¿Porque desaparecen los demas usuarios: se han caido?
NOTA: Para entender mejor esta explicacion conviene que tengamos una idea de como estan conectados los distintos nodos entre si y la configuracion final en la red que forman.

Explicando por encima el proceso, los usuarios se conectan a un nodo que se integraba dentro de una red comun (con base en un programa: el ircd), formada por mas servidores y establecen una comunicacion entre todos los usuarios como si todos pertenecieran a un mismo IRC Server. Pero, ¿que pasa si uno de los enlaces que mantienen unidos a esas redes se rompe? ¿que les ocurre a los usarios que estan conectados por ese servidor?, ¿y a los demas?.

Cuando una red rompe su enlace con las demas, (hay diferentes causas para esta ruptura accidental: malas configuraciones, caida del servidor...), se produce lo que se llama un 'netsplit' (en español 'ruptura de redes') o abreviadamente 'split'. Ahora imaginemonos a la estructura que las redes forman entre si, como si fuera un arbol (esto nos ayudara a ver con mas claridad que sucede), y a las tres redes (Arrakis, Catalunya.net y Encomix) que estan conectadas mediante tres hubs (ejes) como las ramas desde donde parten las demas. Si uno de los hubs se rompiera se aislaria una red, se apartaria de las otras dos, y arrastraria junto a ella a todos aquellos nodos que dependen de ella para establecer su conexion con la red conjunta que forman los tres servidores. Pero la red puede no romperse por aqui, sino por cualquier otro lugar, y si el servidor sirve de puente para que otro nodo se conecte, de igual modo, este ultimo tambien se desconectara de la red principal.

Los usuarios conectados mediante ese nodo que se rompe, o por cualquier otro que se apoye en el, perderan su contacto con la red principal, es decir, desapareceran de la vista de los usuarios de los otros servidores. Para ambas partes del 'arbol', los demas usuarios se han desconectado. Ahora tenemos dos IRC: IRC-HISPANO y otro formado por la red que se ha caido, como si fuera un irc privado, solo para los suarios de un determinado servidor. A parte de esto, los splits tambien provocan 'desinchs' (ver FAQ n.1) entre los servidores cuando se vuelven a reconectar.
Lo unico que el usuario puede hacer si el split tarda demasiado en deshacerse, es cambiar su IRC Server y buscar uno que no se encuentre separado, pues hay situaciones en las que el split solo lo puede arreglar el servidor afectado y en esos momentos su IRCop no se encuentra online.