motivación
¿Por qué meterte en mandangas si ya hay muchos sitios donde puedes albergar tu proyecto? Voy a dar cuatro razones: tres excusas baratas y una buena de verdad.
La primera razón es: por aprender. Como me contaron en Primero de BOFH, la senda del BOFH tiene múltiples vericuetos, y nunca se sabe cuándo te tocará mantener un servidor con código dentro.
La segunda es tenerlo todo a tu gusto. ¿Que quieres un wiki?, pues lo instalas. ¿Que de repente se te va la olla y quieres destruirlo todo en plan Ciudadano Kane?, pues sólo tienes que coger tu servidor y estrellarlo -- imaginad a Orson Welles en plena rabieta sentándose a su ordenador y abriendo una sesión SSH. Muy triste. (Ejem, esto último olvidadlo.)
La tercera es por sencillez. Sí, amigos, cuando hace unos años intenté distribuir mi primer proyecto libre, fui incapaz de endiñarle mi clave pública al engendro de SourceForge. Vale, era bastante novato y ahora me manejo bastante mejor con ssh; pero aun así, prefiero aprender a instalar cosas útiles que no a usar un programa propietario de unos de pahí.
La cuarta razón, y más importante, es mantener el control. En esos sitios tienen que autorizarte un montón de cosas, para empezar la creación de un proyecto nuevo. Esto es un factor clave si se trata de un proyecto corporativo; es posible que necesites una lista de correo de hoy para mañana, y depender de terceras partes no parece buena idea. Además pueden cambiarte el servidor de cvs, tener los servidores colapsados, mil cosas imprevisibles.
En resumen, cuando tienes tu propio servidor no dependes de otros.
objetivo
Tenemos dos dominios, foo y bar. Sólo el dominio foo contiene el código del proyecto.
Vamos a echar un vistazo al software disponible para las distintas tareas propuestas, y a los posibles problemas que puedan darse. No quiero meterme aquí en discusiones de que si arch, que si subversion, más que nada por desconocimiento; yo he encontrado un programa que me mola para cada tarea. Sin embargo, sí doy una mínima justificación de por qué he elegido cada cosa; y os animo a colocar vuestras sugerencias en los comentarios. Mi objetivo es mostrar lo fácil que es a cualquiera que le tenga un poco de miedo (por ejemplo yo mismo hace un mes), y de paso recoger vuestras ideas para mejorar y ampliar el servidor.
tareas
Queremos, por supuesto, dar acceso al código fuente. Suele distribuirse en forma de archivo zip y tarball comprimido (no, no es un ataque de bola de dragón; se trata de un tar.gz). También queremos dar acceso anónimo a nuestro árbol de cvs; para nota, por medio de un navegador.
Tenemos que colocar una web con la documentación y los archivos para bajar; nos interesa, lógicamente, saber cuánta gente accede a la web, se baja el código, y los errores que les puedan salir. No vendría mal controlar cuándo nos visita Google, qué navegadores usan los usuarios, y tal.
Tener una web significa ser un webmaster, y esto a su vez tener un correo webmaster@foo.com. Así que necesitamos un servidor de correo, y ya puestos no vendrían mal unas listitas... Así los usuarios / desarrolladores pueden suscribirse y cotillear de qué flamewars se cuecen.
Como usamos una línea ADSL para servirlo todo, no queremos que se nos colapse a la mínima (ejemplo: usamos un clon de eMule para muestrear el último disco de Luis Miguel y bitTorrent para descargar la beta de Mandrake 10.1, a la vez que nos estamos bajando media internet con el navegador, y hay usuarios accediendo). Vamos, que hay que racionalizar el ancho de banda. Vamos a suponer que ya tenemos un cortafuegos potente que no se saltaría ni el mismísimo Nerón; ponerle un poco de traffic shaping es buena idea, como se explica en el Linux Advanced Routing & Traffic Control HOWTO.
Y por supuesto hay que hacer copias de seguridad periódicas. No, esto no es broma, cuando tienes un servidor con código es importante.
[Nota: siendo pedante, lo único que hace falta para liberar un proyecto es distribuirlo con código fuente, y (opcionalmente) una dirección de correo para que te manden los parches. Nada de lo que precede es estrictamente necesario, aunque siguiendo el modelo "bazar" del bigotes pistolero, sí es bastante recomendable. Así se puede delegar parte del desarrollo en terceras personas que estén interesadas, tener a la gente informada, y coordinar las versiones desde un servidor central.]
al lío
Empezamos con una Debian pelada, más que nada porque fue la primera distro de Ñu/Linux que me funcionó en el servidor. Usaremos la versión testing, es decir: instalas la versión estable 3.0 rc2 "woody" de cedé y le colocas las fuentes de testing "sarge" en /etc/apt/sources.list.
deb http://security.debian.org/ stable/updates main contrib
deb http://security.debian.org/ testing/updates main contrib
deb http://http.us.debian.org/debian stable main contrib
deb http://http.us.debian.org/debian testing main contrib
deb http://non-us.debian.org/debian-non-US stable/non-US main contrib
No, si ya sé que muchos podéis teclear todo esto con los ojos vendados; pero si alguien empieza desde cero a lo mejor le sirve.
servidor web
Sobre esto no hay mucha discusión posible, ¿o sí? Pues aunque estemos todos de acuerdo en que el servidor HTTP de Apache es la mejor opción, aún tenemos que decidir cuál de las muchas versiones disponibles usar. Yo personalmente me quedo con la 2.0.X, que me gusta un montón porque es muy completa y la configuración es muy sencilla, sobre todo en la versión de Debian: los módulos y los sitios activos están en directorios distintos.
Así que elijo apache2-mpm-worker, la más rápida sin ser experimental. Para activar los módulos necesarios sólo hay que hacer enlaces simbólicos de modules-available en modules-enabled. Aquí sólo vamos a necesitar dos: cgi.load y auth_digest.load..
Al contrario que otras distribuciones (como Mandrake), Debian usa /etc/apache2/ para la configuración y /var/log/apache2/ para guardar los ficheros de log; después habrá que tenerlo en cuenta. Tranquilos, que no os voy a contar cómo crear la configuración; es un proceso simple pero con más trampas que Golpe en la Pequeña China.
cvs
A mucha gente no le gusta el cvs. En realidad, a nadie le gusta demasiado el cvs -- a poco que lo uses te das cuenta de sus limitaciones, como no poder renombrar ficheros o agrupar cambios. Y además es inseguro. ¿Por qué entonces lo seguimos usando? Ah, la tontería humana.
Por fortuna, en Debian hay un paquete cvsd que crea automáticamente un chroot y todo; así por lo menos no te pueden comprometer demasiado la máquina. De paso no hay que tener andando inetd, más conocido como the internet superserver, que lo odio: es esa cosa que arranca procesos cuando le da la gana y con el usuario que más rabia le da. Nada nada, un proceso andando y va que chuta. Además así podemos crear fácilmente usuarios de cvs sin que tengan acceso a la máquina, como se explica en su documentación.
Para acceso web al cvs usaremos cvsweb, más que nada por la originalidad del nombre. La configuración es muy sencilla, aunque no es muy recomendable permitirle servir directamente el código original. Así que yo cada hora le digo a la máquina que corra el siguiente script chorra (/etc/cron.hourly/cvsweb.sh):
#!/bin/bash
rsync -a /var/lib/cvsd/foo /home/cvsweb/
chmod -R a+X,a+r /home/cvsweb/
con lo cual via web se ve sólo una copia (la del directorio home de un usuario ficticio). Aunque me craqueen el programa éste hasta las cejas, poco destrozo pueden hacer.
correo
Ahora tendremos que poner una dirección de contacto en las páginas que pongamos en el servidor. (Una de yahoo.com no queda muy profesional.) Tras intentar con escaso éxito usar qmail, me decido por exim4: parece sencillo y además Debian te lo configura casi entero al instalarlo. Es importante para las listas que vamos a crear decirle que divida la configuración en varios ficheros.
Para las listas elijo mailman de GNU, basándome en motivos altamente técnicos: el logo es bonito y el dominio list.org es chulo. Es importante configurar /etc/mailman/mm_cfg.py antes de crear las listas, para que no cojan vicios chungos desde el principio. Luego se crean:
# newlist mailman
# newlist foo
La primera es obligatoria del sistema, la segunda y posteriores como uno quiera. Normalmente habría listas foo-user y foo-dev, para que los usuarios no den mucho el coñazo a los desarrolladores (y viceversa); en mi caso por el momento sólo he creado una. Y ya está. Hay que tocar un poco la configuración de exim4, pero viene todo muy bien explicado en README.EXIM. La de Apache apenas hay que modificarla; añadimos a foo.conf lo siguiente:
# enable mailman
ScriptAlias /mailman/ "/usr/lib/cgi-bin/mailman/"
Alias /pipermail/ /var/lib/mailman/archives/public/
Alias /images/mailman/ /usr/share/images/mailman/
y listo. Sólo nos queda suscribirnos a nuestras propias listas, mandar un mensaje de prueba (desde la cuenta de yahoo.com que antes despreciábamos, para algo sirve) y comprobar que queda archivado.
estadísticas
Como ya apunto en mi diario, me he decidido por awstats 6.1, básicamente por su propia comparativa. Y también estoy muy contento con este programita.
Primero se crean los ficheros de configuración en /etc/awstats/, según la documentación. En el mío he puesto:
LogFile="/var/log/apache2/foo-access.log"
LogType=W
LogFormat=1
SiteDomain="www.foo.com"
AllowToUpdateStatsFromBrowser=1
AllowFullYearView=3
HostAliases="localhost"
DirData="awstats-data/"
porque la configuración de ejemplo no me gustaba. Así permitimos que se actualice desde la propia página web, que se pueda ver un año completo, y le decimos que guarde los datos en el directorio /var/www/cgi-bin/awstats-data/ para que no se mezclen con el script (ya que crea un fichero por cada mes de datos que recoge).
Luego hay que configurarlo para que pueda accederse desde fuera; yo incluyo lo siguiente en mi /etc/apache2/sites-available/foo.conf:
# enable awstats
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
<Location /cgi-bin/>
AuthType Basic
AuthName "stats for foo"
AuthUserFile /var/www/cgi-bin/.passwd
Require valid-user
</Location>
Alias /icon "/usr/share/awstats/icon/"
y eso es todo lo que hace falta, aunque la documentación diga que hay que usar más alias a css's y tal. Bueno, yo he colocado autentificación básica por motivos que explico más abajo.
A no ser que sólo tengáis un dominio, también hay que modificar el fichero /etc/cron.d/awstats que viene con la distribución. Yo lo tengo así, para mis dos dominios:
0,10,20,30,40,50 * * * * root cd /var/www/cgi-bin/ && ./awstats.pl -config=foo > /dev/null
0,10,20,30,40,50 * * * * root cd /var/www/cgi-bin/ && ./awstats.pl -config=bar > /dev/null
[Nota: lo he puesto como root porque (por algún motivo que desconozco) no me funcionaba de otra manera.]
Ahora veremos que cada 10 minutos va a actualizar el fichero del mes en curso guardado en /var/www/cgi-bin/awstats-data. Cuando accedamos a la página de estadísticas, tendrán siempre menos de 10 minutos de desfase.
copia de seguridad
Sobre esto no tengo mucho que decir, más que apuntaros el genial tutorial en tres entregas que puso aquí mismo amphora sobre "Bacula
el vampiro". Sí os señalo este artículo de Linux Gazette donde, aparte de mostrar cómo hacer copias de seguridad sólo con rsync y cron, nos cuenta las posibilidades de almacenamiento de las mismas. De menos segura a más, son
- en la misma partición del disco duro: pésima porque puede corromperse;
- en otra partición de tu ordenador: mala porque los discos duros cascan;
- en otro disco duro: no muy allá porque te pueden chorizar el ordenador o se te puede quemar el queo;
- en otro ordenador de la red: no está mal, pero si el ladrón es fuerte o tiene mucho tiempo podría llevarse todo lo que pille;
- en un ordenador remoto: muy buena porque ya sería mala suerte que ardiera tu casa y tu oficina, pongamos;
- en otro planeta: ideal porque te protege del temible holocausto nuclear o incluso de un posible levantamiento de zombies debido a lo malos que somos en general con el medioambiente.
Bueno, la última opción la he colado yo, pero captáis la idea. Es interesante como mínimo hacer copias de seguridad separadas del repositorio cvs para poder albergarlas cómodamente en sitios remotos, que es lo más importante. Yo soy mal ejemplo porque sólo hago copias de seguridad a mano y cuando me acuerdo, pero por lo menos las copio a otras máquinas de la misma red. Conste que mi próxima mejora va a ser usar bacula.
más seguridad
Ahora que tenemos una máquina conectada a internet distribuyendo código, hay muchos otros aspectos de seguridad que considerar. Tantos que voy a centrarme en los más llamativos.
- Según leo en todos sitios, el acceso a un repositorio CVS usando el protocolo pserver es muy inseguro: a menudo se descubren vulnerabilidades. Es importante aplicar los parches regularmente (yo lo hago cada semana o así), en éste y otros programas. Vamos, que
apt-get update y apt-get upgrade son tus amigos. Espero que cuando sarge pase a ser stable se pueda automatizar más el proceso, bajando sólo las actualizaciones de seguridad.
- Es también importante correr los mínimos procesos posibles, y cerrar en el cortafuegos todos los puertos que no se usen. nmap es útil para saber qué puertos tienes abiertos. En general, instala lo mínimo necesario; echa a correr menos cosas todavía si es posible; y cierra todo hasta que te haga falta. Si ves algún proceso raro que corre en tu máquina, sospecha.
- Ahora puede que tengas usuarios conectándose desde cualquier sitio y por tanto a todas horas. Es importante que se pueda administrar la máquina en remoto y de forma segura, para poder arreglar cualquier problema estés donde estés. Normalmente esto significa tener arrancado el demonio sshd, que viene con el paquete
ssh.
- Un problema que yo no he resuelto es el de firmar los archivos que se distribuyen. Y la verdad, en todos los sitios serios lo hacen. Esto significa como mínimo guardar el hash, y normalmente firmar con una clave gpg. Pero si tienes un solo servidor no tiene tanto sentido; igual que te craquean el archivo, te cambian el hash o la firma. De todas formas, que sepáis que hay que hacerlo; si no, puede llegar un señor malo y meterle un rootkit a tu programa. La gente cuchichearía a tus espaldas en las fiestas de firma de claves pgp durante varias semanas.
limitaciones
El servidor que yo uso, a pesar de ser bastante robusto (tiene discos SCSI, por ejemplo, y conector de vídeo DVI), no deja de ser una estación de trabajo HP del '95 rescatada del basurero. El procesador a 180 MHz, equivalente más o menos a un PII a 300 MHz, tiende a agobiarse fácilmente con tareas complejas como correr un programa en perl. Así que he decidido no dar acceso anónimo ni al cvsweb ni a las estadísticas, ambos en perl -- por respeto a su venerable edad.
Otra cosa que me he saltado es dar acceso anónimo al cvs. Como ya dije antes, el protocolo pserver es altamente inseguro. Aunque tengamos un chroot en cvsd, no tengo ganas de que me juaqueen el bicho con lo mono que me ha quedado. El acceso anónimo sólo empeoraría las cosas.
El ancho de banda de subida que da una línea ADSL, aunque sea de ésas caras, es bastante limitado. Ante esto no puedo hacer nada; creo que lo mejor es buscarse réplicas para albergar los ficheros gordos (zip y tar.gz), por ejemplo usando el hosting gratuito que acompaña muchas veces a las líneas ADSL. Hmm, buena idea, no se me había ocurrido hasta ahora, en serio. Además de paso podéis almacenar ahí las copias de seguridad si no son muy grandes. Jo, estoy que me salgo.
conclusión
Pues nada, ya sólo nos queda mandar la noticia a FreshMeat y esperar a que lleguen los incautos, MWAHAHAHAHAHA. ¡Valiente truco para buscarse usuarios a los que borrarles las cuentas!
