| Siguiente: Algunos problemas Superior: SINDOMINIO: Un modelo de Anterior: Pasos previos a la |
Esta era la primera cuestión: dado que nadie tiene acceso físico a la máquina ¿cómo nos conectamos (de forma segura) y trabajamos en ella? La respuesta a esta pregunta era sencilla: SSH. Cerramos el puerto telnet, instalamos un servidor SSH (en aquel momento la única opción para GNU/Linux era no-libre, pero gracias al port del OpenSSH ya no existe ese problema), y ya podíamos trabajar. Posteriormente abrimos también un puerto telnet-ssl, para no quedarnos sin acceso a la máquina en el hipotético caso de que hubiese algún problema con el servidor SSHD.
Lo siguiente era ¿quién tiene acceso shell? Muchas de las personas y colectivos que participan en SINDOMINIO no tienen conocimientos de GNU/Linux, con lo que darles una shell no añadía ninguna utilidad, y ofrecía una posible vulnerabilidad al sistema si toda cuenta de correo tenía shell. Así que la decisión fue sencilla: cuando se da de alta algún nuevo participante no se le da shell, y si quiere tenerla no tiene más que pedirla. Quien no sepa qué es eso, no la va a necesitar, y quien la quiera va a saber qué es.
Otro problema obvio: ¿quién (o quiénes) tienen la contraseña de root? ¿cómo se accede a la cuenta de root?
La respuesta tampoco nos llevó demasiado tiempo: en un primer momento, había 4 personas con conocimientos y experiencia, con lo que esas 4 personas tienen la contraseña de root, cuenta a la que sólo se puede acceder con su, una vez dentro de la máquina, en un canal cifrado e identificado como usuario normal. Además, que fueran varias personas nos permitía mejorar la velocidad de respuesta caso de que su intervención fuese necesaria, liberando a esas personas de una disponibilidad a tiempo completo que en la práctica era inviable.
Por último, el hecho de que una de esas 4 personas viva cerca de donde está alojado el ordenador, nos facilita la solución de problemas sí por alguna circunstancia falla el acceso remoto o no se puede resolver por esa vía (problemas de hardware, DoS, etc.) de forma más o menos rápida.
Para coordinarnos, simplemente creamos un alias de la dirección de correo de root hacia las de los roots, y solucionado.
Hasta aquí, en realidad el método de administración no se diferencia demasiado del de cualquier sitio ``compartido''. Esto es debido, en realidad, a que intentamos, en la medida de lo posible, que la configuración de servicios no necesite la participación de la cuenta root más que cuando sea imprescindible, dando sólo los permisos oportunos a cuentas concretas. Ahora veremos los servicios ``descentrados'' y cómo los gestionamos.
El proceso para darse de alta en SINDOMINIO es el siguiente: la persona o colectivo que desee incorporarse lo solicita por correo a una lista creada al efecto, explicando quién es y por qué se quiere incorpora al proyecto (sd@sindominio.net); ese correo es recibido por un grupo de gente, que se encarga de la parte social de la administración: son quienes mantienen el contacto con esa persona/colectivo, quienes presentan la solicitud a la asamblea, y quienes si se ha aceptado trasmiten esto a quienes generan la nueva cuenta. A su vez, al ser la cuenta pública de SINDOMINIO, son quienes filtran y distribuyen las consultas, dudas, observaciones, etc. a la persona o personas adecuadas, encargadas del servicio en cuestión. Cualquiera que haya administrado un sistema de tamaño medio sabrá que esa parte ``social'' es fundamental para la buena marcha del sitio, con lo que, pese a no requerir conocimientos técnicos, lo incluimos en la parte de administración. Este grupo lo componen actualmente 8 personas, aunque el número va cambiando.
Después de esto, si el alta ha sido aceptada, se pasa el aviso a un segundo grupo, que se encarga de dar el alta, asignar una contraseña y enviársela a su destinatari@ (siempre que es posible, cifrada con GNUPG). Este grupo tiene permisos para dar las altas, así como de cambiar contraseñas --excepto la de root--, gracias a sudo, y actualmente está formado por 2 personas. Todos los usuarios pueden después cambiar su contraseña vía web-SSL las veces que lo deseen.
Desde el principio, vimos que el mantenimiento de la web ``corporativa'' iba a llevarnos bastante trabajo, por lo que rápidamente creamos un equipo de webmasters, con permisos de escritura en todo el árbol /var/www, y coordinados a través de una nueva lista de correo. Al principio se propuso una división de acuerdo a cuatro grandes áreas técnicas, para que cada cual escogiese la que quisiese: diseño, elaboración de contenidos, programación web y administración de los servidores web (APACHE y ZOPE).
Tal división funcional no ha acabado de cuajar y la práctica ha dado lugar a otra estructuración basada mas en proyectos y afinidades que en áreas técnicas, que a grandes rasgos queda así:
Nuestro particular ``contrato social'' consiste en que tanto la BiblioWeb como la ACP o cualquier otro desarrollo que SINDOMINIO pueda emprender en el futuro se basa en software libre, con lo cual dichas herramientas quedarán libremente disponibles para otros proyectos.
Una de las tareas más desagradables en la administración de un sistema abierto es la revisión de los logs del sistema, en busca de errores, anomalías o ataques. En SINDOMINIO esta tarea es menos tediosa, puesto que es asumida por un grupo de gente (esta vez sí, con conocimientos técnicos), lo que permite que ninguna persona tenga que estar revisándolos constantemente.
La configuración de los servicios generales se asumió en principio por quienes teníamos privilegios de root. Tras la congelación de la versión 2.2 de Debian, se realizó remotamente una actualización completa del sistema, con la participación simultánea de todos los roots vía ytalk para tomar decisiones ante las preguntas de configuración y el reinicio de servicios (cualquier error nos podría haber dejado sin acceso al sistema). No obstante, la mayor parte de las configuraciones siguen como al principio, excepto pequeñas modificaciones (creación de nuevas entradas en el DNS, actualización de paquetes y de la versión del kernel, creación de nuevas listas, y otras modificaciones menores), que son llevadas a cabo por el equipo de roots, puesto que tampoco generan excesivo trabajo y algo tienen que hacer ellos :-)
Una excepción a esto fue el cierre del relay, lo que obligó a bastante trabajo durante unas dos semanas, y que fue llevado a cabo por un grupo reducido de personas, mientras el resto intentábamos buscar soluciones y/o información por la red; algunos otros ejemplos ha sido el enlazado de Twig con PostgreSQL --ahora se puede hacer sin más que instalar el paquete Debian, cuyo mantenedor oficial es uno de los roots de SINDOMINIO--, y la puesta en funcionamiento de la ACP. Precisamente, esto es parte del espíritu del modelo: descargar a quienes más conocimientos técnicos tienen de tareas que no los necesitan, para así no cargarles mucho de trabajo y aprovechar mejor los recursos.
Por último, cuando se plantea la puesta en funcionamiento de un nuevo servicio, en muchas ocasiones alguien se presenta voluntario para ponerlo en marcha, lo instala localmente, aprende a configurarlo, lo prueba, y cuando todo esta hecho avisa a algún root para que lo ponga en su estado real (ejemplos de esto han sido el servicio IRC o la herramienta analog de estadísticas web).
Otro de las tareas tediosas de administrar son las listas de correo, una vez que ya están en funcionamiento: dar altas y bajas, revisar las direcciones suscritas, errores de suscripción, mensajes rebotados o no admitidos...Esta tarea se puede descentralizar de forma sencilla con Smartlist, puesto que se puede hacer con comandos vía mail. Actualmente, ninguna de las listas de correo de SINDOMINIO es administrada por un root.
En muchos casos, una de las tareas que más tiempo lleva (y eso que no es puramente una tarea de administración) es la adaptación de aplicaciones a la situación real con la que te encuentras, y SINDOMINIO no es una excepción.
Cuando nos encontramos con la necesidad o conveniencia de desarrollar algo, el método que seguimos es sencillo: se avisa en la lista de administración (que es en la que nos incluimos quienes tenemos conocimientos técnicos, o quienes más interés tienen en adquirirlos) de cuál es el proyecto, y la gente que está interesada se apunta; una vez que el número de gente es suficiente, el proyecto se pone en marcha, siguiendo los métodos que el propio grupo elija (forma de coordinación, herramientas a usar, plazos si son necesarios, conocimientos a adquirir si todavía no se tienen...).