Siguiente: El modelo de administración Superior: SINDOMINIO: Un modelo de Anterior: ¿Por qué un modelo

Pasos previos a la administración

Lo que teníamos que administrar

El primer paso para elegir un modelo es saber a qué situación tiene que responder: en la parte técnica, SINDOMINIO dispone de un PC con Debian GNU/Linux, conectado a la red interna de nuestro proveedor de conexión, con salida a Internet vía frame relay. No dudamos en la elección de GNU/Linux, y en particular de Debian, puesto que nos ofrecía en lo técnico la estabilidad y versatilidad que necesitábamos, junto con la apuesta no mercantilista del proyecto Debian por la difusión del software libre que compartimos plenamente. Tanto el equipo como la conexión se sostienen con aportaciones voluntarias de personas y colectivos, quedando claro que se paga para apoyar un recurso colectivo, pero no un servicio: pagar no da más derechos que no pagar.

Los servicios de los que queríamos disponer fueron:

Correo electrónico:

Como servidor de correo, elegimos POSTFIX, puesto que es libre, es relativamente sencillo de configurar, y a la vez muy versátil, actualizado y potente. Además, contamos con la ayuda de Wietse Venema, su creador, y de Bennet Todd, autor de un pop-before-smtp para POSTFIX, a la hora de cerrar el relay a los spammers (lo cual no era sencillo pues SINDOMINIO no da conectividad a sus usuarios, por lo que no es fácil de antemano distinguir un relay legítimo de un spammer).

Web:

Para esto no había duda, y el clásico APACHE, con servidor seguro incluido, se sigue comportando de manera admirable.

FTP:

Sobre esto hubo más discusión, sobre todo porque cuando arrancamos cada día se descubrían nuevos problemas de seguridad en los servidores clásicos, y al final elegimos PROFTPD: es sencillo de configurar, versátil, y en principio, parecía inmune a muchos de los problemas de seguridad del clásico WU-FTPD. Desgraciadamente, con el tiempo han aparecido también problemas de seguridad con PROFTPD, y ahora mismo estamos pensando si migrar al servidor de OpenBSD.

Listas de correo:

También sobre este tema hubo cierta discusión: el popular MAJORDOMO frente a SMARTLIST; al final, este último fue la elección, por su licencia libre y por estar basado en el conocidísimo PROCMAIL. Con el paso del tiempo hemos comprobado que la elección fue correcta, y ello pese a que aún no hayamos encontrado una interfaz web para la gestión de las listas, si bien es cierto que vía correo-e se hace sin problema.

Correo vía web:

Tras probar con WEBMAIL, lo abandonamos, sobre todo por necesitar el JDK --que no es libre-- y por su excesivo consumo de recursos, a favor del TWIG, que es 100% libre, basado en PHP, altamente configurable, y no consume apenas recursos. Conseguimos enlazarlo con PostgreSQL en lugar de MySQL, que en aquel momento no era libre, si bien era la opción probada y recomendada por los desarrolladores de Twig.

Noticias vía web:

Uno de los primeros proyectos que pusimos en marcha fue la ACP (http://acp.sindominio.net), para lo cual necesitábamos una herramienta que nos permitiese publicar en web noticias de forma sencilla y horizontal, sin mediaciones, así como permitir búsquedas por temas, por días...Las primeras pruebas las hicimos partiendo del software de SLASHDOT y la traducción que ya habían hecho en BARRAPUNTO. Le encontramos un problema: Slashdot, propietaria de los derechos de dicho software, obligaba a incluir su logo y un enlace a su página, lo que, no siendo extremadamente grave, no nos gustaba (por suerte, hoy ya no imponen esa restricción y lo han liberado). Además el código que dejaban disponible era una versión antigua y descuidada, de complicada implementación. Tras un tiempo buscando alternativas, encontramos SQUISHDOT, un weblog que corre sobre ZOPE, con el que estamos funcionando desde entonces.

IRC:

SINDOMINIO cuenta con su propio servidor de IRC, conectado con otros proyectos de carácter similar, como el canadiense TAO, para discutir, coordinarnos y apoyarnos mutuamente. Los servidores de la red SINDOMINIO-TAO son IRCU, el servidor de Undernet.

Lo que exigíamos al modelo de administración

Otro problema a considerar era qué características debía reunir el modelo de administración. Esto era importante, puesto que una administración demasiado jerarquizada, además de ser contraria a nuestra forma de pensar, limitaría en exceso las posibilidades de participar de la gente, algo que queríamos evitar a toda costa. Por contra, una administración abierta pero poco pensada podía llevarnos a tener un sitio desorganizado y difícilmente administrable, además de posiblemente inseguro.

Por tanto, el modelo debía permitir que mucha gente participase en la administración, cada cual desde un espacio diferente y en la medida de sus posibilidades, pero manteniendo una coordinación y un ``protocolo''.