Últimos Cambios
|
|
|
|
Últimos Cambios |
|
|
|
||
| Mi estado actual
en Jabber/XMPP:
| |||
Última Actualización: 24 de Diciembre de 2003 - Miércoles
Este módulo permite el empleo, por fin, de la base de datos distribuída para la gestión y autentificación de usuarios en el IRC.
Sí, este web está escrito para "iniciados". Si eres un usuario a lo que todo esto le suena a chino, mírate estos enlaces:
El IRC no distingue mayúsculas y minúsculas, por lo que nicks como "PePe" y "pEpE" son equivalentes. El IRC, asimismo, define algunas letras "especiales", debido a sus orígenes finlandeses. Dichas "letras" son "^", "~", "[", "{", "]" y "}".
El "^" es equivalente al "~", el "[" a "{" y el "]" a "}". Y viceversa.
Efectivamente, los caracteres permitidos son las letras (mayúsculas y minúsculas), los números y los caracteres "[" y "]". Si introduces otros caracteres diferentes, se convertirán a uno de los caracteres válidos. Las reglas de conversión son técnicas y no se detallan aquí. La recomendación es que no se utilicen otros caracteres distintos de los válidos.
Correcto. Se pueden meter otros caracteres, pero se convertirán a uno de esos cuatro.
La conversión almacena una clave "normalizada" en la base de datos distribuída. Cualquier clave que una vez "normalizada" coincida con ella, se dará por buena.
Explicación técnica:
Las claves de "nick2" son claves de 64 bits, divididas en dos grupos de 32 bits. El primer grupo está representado por los primeros 6 caracteres de la clave, y el segundo grupo por los otros seis. Se representan, pues, 32 bits con 6 caracteres.
Pero dado que cada carácter proporciona 6 bits de información (64 combinaciones), con 6 caracteres proporcionando 6 bits, tenemos 36 bits, no 32.
Para reducir los 36 bits a 32, la convención que usa "nick2" es que el primer carácter de cada grupo sólo proporcione 2 bits, en vez de los 6 de los que es capaz. Eso reduce el primer carácter de cada grupo a cuatro valores, que son "A", "B", "C" y "D".
Las reglas de caducidad de los registros en "nick2" son equivalentes a las del "nick" actual.
"getnewpass" sólo responde a usuarios con modo "+r". Si acabas de migrar y no has cambiado de nick, sigues sin tener el modo "+r".
Lo que debes hacer es ponerte un nick cualquiera y, seguidamente, volver a ponerte tu nick real, con la clave que te ha dado "nick2". En ese momento obtendrás el modo "+r" y te funcionará el comando "getnewpass".
Las claves que "nick2" genera al migrar un nick no son aleatorias, como pueda creerse, sino que se toma la clave original que estaba en "nick", se "normaliza" y, el resultado, es la clave proporcionada por "nick2".
Por lo tanto, si dos nicks tienen la misma clave en "nick", tendrán la misma clave en "nick2" al hacer la migración, hasta que se les dé una clave nueva con "getnewpass".
Como se ha explicado en el punto anterior, mientras no se cambie la clave con "getnewpass", la clave de "nick" y la de "nick2" son EQUIVALENTES, aunque sean distintas. Es decir, se pueden utilizar ambas, como se ha descrito más arriba.
Se recomienda, no obstante, utilizar la de "nick2".
No la recuerdes. Escríbela en un papel (mejor en dos y guárdalos en sitios distintos, por si pierdes uno), en el móvil, etc.
No insistas con "getnewpass"; las claves generadas son aleatorias y no te va a dar nunca la que tú quieres :-)
Usa el comando "setpass".
Nota Importante:
Aunque el tema está todavía abierto a discusión, el modo "+r" abrirá la puerta a un enorme número de servicios nuevos, que se irán poniendo online a lo largo de los próximos meses. Un ejemplo es la agenda, por poner un caso, lleva funcionando un par de años.
Debido a ello, es imperativo que el modo "+r" esté muy protegido, ya que puede dar acceso a datos de carácter personal y sensible. En ese sentido hemos preferido que las claves las proporcionemos nosotros, de forma aleatoria, y así poder garantizarles una calidad de 64 bits. Aunque muchos usuarios saben cómo crear y usar claves de calidad, la mayoría de la población de IRC-Hispano sigue usando el "pw1234" original proporcionado por "nick"...
Se recomienda encarecidamente a los usuarios que usen "getnewpass" para que el sistema les genere una clave aleatoria, óptima en términos de calidad y seguridad.
Las claves de nick y nick2 pueden no coincidir, según las circunstancias. La solución más sencilla es que cuando cambiemos de clave en nick2, pidamos a un oper de la red que nos haga un "SENDPASS".
Hay que recordar, no obstante, que la clave que se fijará en "nick" no es la clave del usuario, si no la versión normalizada de la misma.
Esta medida es temporal, y no será necesaria cuando se implemente directamente el "GHOST" a nivel de servidor.
Para ello hay dos explicaciones:
nick2 solo maneja claves de hasta 12 caracteres. Si poner más, se ignoran. Asimismo, cuando metas la clave sólo se tendrán en cuenta los primeros 12 caracteres.
nick2 completa la clave introducida, hasta los doce caracteres que utiliza, con letras "A". Ese relleno es opcional a la hora de escribir la clave: lo podemos escribir entero, no escribir ninguno en absoluto, o poner cualquier número de letras "A". Todas esas claves son equivalentes.
Debido a todo lo dicho en esta sección y otras, recordamos a los usuarios que la forma de tener la clave más segura y de mayor calidad es emplear el comando "getnewpass", que nos garantiza 64 bits 100% aleatorios. Si usamos "setpass" la calidad de las claves dependerá de la pericia del usuario, y la experiencia dicta que, en general, la calidad de las claves elegidas por el usuario es baja.
Si te molesta aprenderte una clave tan larga y difícil, ¡no te la aprendas!. La copias en tu móvil, la escribes en un papel que llevas en tu cartera, etc. :-).
Las últimas versiones de nick2 ya no envían esa información al usuario.
Las últimas versiones de nick2 ya no publicitan el parámetro "token" en la ayuda, para evitar confusiones a los usuarios.
Existen dos opciones:
Si la clave del usuario en "nick" contenía caracteres no válidos, existe la posibilidad de que la clave obtenida al migrar no funcione. En ese caso la solución es avisarme, para que le dé una clave nueva y se la envíe por email.
Los usuarios que migran ahora no se encontrarán con este problema, porque si a "nick2" no le gusta la clave, generará una, 100% aleatoria y válida.
Se supone que no hay usuarios con este problema, porque el bug se solucionó enseguida y los usuarios con claves no válidas ya deberían haber informado sobre su problema, con lo que ya lo tendrán solucionado.
Dependiendo del tipo de letra que estemos utilizando, algunos caracteres de la clave pueden confundirse. Un claro ejemplo son el "O" y el "0", así como el "l", "1" e "I".
Exactamente lo mismo que se ha hecho siempre, pero usando "nick2" en vez de "nick". En particular, "nick2" dispone del comando "sendpass", para que el usuario reciba su clave por correo electrónico. Si "nick2" se queja de que un usuario no está migrado, debemos ejecutar el comando en "nick", como siempre.
Actualmente "nick2" envía la clave al usuario, tanto haya migrado como no.
Eso es debido a que es un usuario "+r" histórico, que no migró a "nick2" sino que se le dio de alta en el sistema antes de la existencia de dicho bot. Existen, aproximandamente, unos 300 usuarios en dicha situación. Son usuarios a los que se le dio de alta de forma manual para evaluar el funcionamiento de "+r", la agenda, etc.
Dado que dichos usuarios existen en el sistema con "+r" antes de existir "nick2", el bot desconoce la clave del usuario. Como no la conoce, no puede enviarla por email.
Existen dos soluciones:
Es importante recordar que si bien la clave "AAAAAAAAAAAA" no es válida para autentificarse en la red, si se ha hecho un "SENDPASS", sí permitirá hacer un ghost a través de "nick". Esto no se considera un problema porque los nicks históricos desaparecerán pronto de la red, ya que son una pesadilla de mantenimiento.
Si el "drop" se realiza a través de "creg", éste se encargará de informar tanto a "nick" como a "nick2".
Dado que "creg" no verifica el correcto funcionamiento de su orden de borrado, si "nick2" está fuera de servicio, el borrado se perdería. Este hecho, normalmente, es fácilmente detectable porque tiempo después se puede verificar que el nick sigue existiendo. En ese caso, basta con realizar un nuevo "drop" sobre el mismo nick.
Este comando es exclusivo de "nick" y no afecta a "nick2". En otras palabras:
En el futuro es posible que se implemente un comando "suspend" en "nick2", pero es poco probable.
Si lo que se pretende es dar un toque de atención a un usuario, se recomienda el uso del comando "NICKFORBID" de "nick2". Dicho comando prohibirá el uso del nick en cuestión en la red, por lo que no podrá ni acceder a los servicios de "nick" ni a los de "nick2". Este comando no es destructivo, y su efecto se deshace con "NICKUNFORBID". El usuario recuperará su nick, su clave de acceso y todos los servicios, como si nada hubiera pasado.
En algunos momentos resultaría muy conveniente que "nick2" hiciese un rename:
Lamentablemente esta funcionalidad necesita disponer de U-Line en toda la red, algo que -hoy por hoy- resulta una utopía.
Por razones de seguridad, los OPER están obligados a cambiar de clave de forma periódica. Los criterios son los siguientes:
Hay dos posibilidades:
Los opers no tienen acceso al comando "SETPASS", por razones de seguridad. La activación de una nueva clave debe realizarse a través del comando "GETNEWPASS".
Para evitar usos "inteligentes" del flag "+h", "nick2" no permite el uso del comando "SETPASS" a ningún usuario que haya tenido el modo "+h" en los últimos tres meses.
Si has dejado de ser un OPER, recuperarás el uso de "SETPASS" al cabo de tres meses. Mientras tanto, deberás seguir usando "GETNEWPASS".
"nick2" no guarda las fechas de los cambios de clave de todos los usuarios, lo que sería un gasto inútil de recursos. Tan solo almacena la fecha de cambio de clave para los nicks con modo "+h"; es decir, para los OPER.
Si eres un OPER reciente, "nick2" no tiene ni forma de saber la fecha de tu último cambio de clave, ni sabe si lo hiciste con "SETPASS" o "GETNEWPASS". Por lo tanto, se cura en salud y asume que ya te has pasado de plazo. Esto permite, asimismo, asegurarnos de que los nuevos OPER tengan una clave de calidad.
Los números de versión que se indican se refieren a "commit" en el CVS interno. El número de versión cargado en Olimpo en un momento dado es visible usando el comando "dllist".
El "token" es un valor aleatorio, diferente para cada conexión (aunque sea el mismo nick) y con una validez de 20 minutos. Su aleatoriedad es de 30 bits, por lo que existen unos mil millones de posibilidades.
Este comando debe ejecutarse de forma manual de vez en cuando. Por ejemplo, una o dos veces por semana.
Hago una versión intermedia, que migre los registros administrativos actuales al nuevo sistema de nombramiento.
Un nick es especial cuando ha conectado alguna vez con el modo "+h".
Aunque el problema ya está solucionado, es muy posible que muchas claves en la base de datos estén mal. Afortunadamente, son recuperables.
Me escribo un pequeño programa que lee la base de datos de disco, y comprueba si las claves coinciden con las distribuidas por BDD. Si es el caso, no hace nada. Si no es el caso, va eliminando caracteres al final de la clave, y volviendo a comprobar, hasta que coincide. Cuando coincide, actualiza la clave real.
Si el usuario, tras la migración, hizo un "SETPASS" o un "GETNEWPASS", la clave en la base de datos será correcta, ya que el problema se producía, exclusivamente, durante el proceso de migración.
Dado que este registro crece sin cesar a medida que se van eliminando nicks, añado este comando para borrarlo y empezar desde cero.
Antes de ejecutar este comando debemos asegurarnos de que todos los módulos dinámicos que entienden de nicks estén al día en cuanto a "NICKDROPS" (por ejemplo, la agenda), porque sino puede ser que dejemos de borrar registros de usuarios que ya no existen.
Para dotar de esa información a los nicks ya registrados, casi 60.000 en este momento, en este módulo se los pregunto uno por uno a "NiCK".
El problema no tiene efectos a largo plazo, ya que la clave del nick no será conocida y, por tanto, el nick acaba por expirar por inactividad, un mes más tarde.
Problema solucionado.
Esto me permite programar objetos de ejecución diferida de forma independiente entre sí: expiración de nicks, expiración de claves de opers, cambios de email diferidos, etc.
En principio "NICK2" acepta peticiones de registro salvo que:
Al terminar la sesión, el usuario tiene dos opciones:
Una opción sugerida por un OPER de la red consiste en abrir el comando
"SENDNEWPASS" a todos los usuarios, con la particularidad de que un usuario
"normal" sólo pueda cambia la clave de su propio nick.
Tras discutir el asunto en las listas relevantes, se acepta la propuesta y
se abre el comando "SENDNEWPASS" para todos los usuarios.
Insistimos, no obstante, en que usar la clave de nick desde una conexión que
no nos merece confianza está ABSOLUTAMENTE desaconsejado. Evítelo en
lo posible.
Las escrituras al histórico van a la base de datos actualizable.
Las lecturas del histórico (comando "HISTORY") van a ambas bases de datos,
fusionando sus resultados en uno solo.
Utilizo CDB ("Constant DataBase") para la base de datos estática.
En el estado actual de IRC-Hispano, es un comando muy lento porque
tiene que revisar toda la base de datos. Más aún, si la operación es muy
lenta y la conexión con el HUB se corta, Olimpo va a morir al intentar actualizar
la BDD con el flujo cerrado.
El script python (2.3.*) que uso para convertir la base de datos histórica a CDB
es el siguiente:
Migramos una base de datos que ocupa 104 megabytes, y contienen 418.764 registros.
La CDB resultante mide 65 megabytes.
El problema se soluciona si invocamos una recogida de basuras manual.
El problema parece que reside en la interacción de los objetos "nuevos" (los que
heredan de "object") con el sistema de recogida de basuras.
Parece que son más remolones para ser liberados de forma
automática ("reference counters").
La solución parece ser cerrar manualmente las CDB cuando se descarga el módulo.
Preguntas y Respuestas Frecuentes
import bsddb
import cdb
import cPickle as pickle
a=bsddb.hashopen("db.nicks-historico2") # La base de datos renombrada
b=cdb.cdbmake("/tmp/db.nicks-historico.CDB.Dic2003","/tmp/db.nicks-historico.CDB.Dic2003.tmp")
i=0
for k,v in a.iteritems() :
i+=1
v=pickle.dumps(pickle.loads(v)[0],pickle.HIGHEST_PROTOCOL)
b.add(k,v)
print i,b.numentries
b.finish()
