Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Monta un servidor para un proyecto libre

Software
Por man ls
departamento libera tu proyecto , Sección Software Libre
Puesto a las Sun Aug 15th, 2004 at 07:05:20 PM CET
Vale, has programado tu código chachi-pilongui y quieres que el resto del mundo lo use también. ¿Y ahora qué?

Hay varias opciones para albergar tu proyecto: SourceForge, Savannah (que mira tú por dónde es un fork de SourceForge) y otros. Apache no es una opción, no admiten proyectos nuevos. Aquí veremos la más interesante: montártelo tú.

 


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

  1. en la misma partición del disco duro: pésima porque puede corromperse;
  2. en otra partición de tu ordenador: mala porque los discos duros cascan;
  3. en otro disco duro: no muy allá porque te pueden chorizar el ordenador o se te puede quemar el queo;
  4. 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;
  5. en un ordenador remoto: muy buena porque ya sería mala suerte que ardiera tu casa y tu oficina, pongamos;
  6. 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!

< Configuraciones gráficas (27 comments) | Segunda petición de contribuciones para las IV Jornadas Andaluzas de Software Libre (2 comments) >
Enlaces Relacionados
· Freshmeat
· escomposlinux.org
· SourceForge
· Savannah
· fork de SourceForge
· Apache
· Ciudadano Kane
· código del proyecto
· Linux Advanced Routing & Traffic Control HOWTO
· modelo "bazar"
· el servidor HTTP de Apache
· 2.0.X
· Golpe en la Pequeña China
· mailman de GNU
· el logo es bonito
· list.org
· mi diario
· awstats 6.1
· su propia comparativa
· Bacula
· el
· vampiro
· este artículo de Linux Gazette
· cuando sarge pase a ser stable
· servidor que yo uso
· FreshMeat
· borrarles las cuentas
· More on Software
· Also by man ls

Encuesta
¿Qué te parece este auto-hosting?
· Pobre, muy pobre 4%
· Pesao 13%
· SourceForge es mejor 13%
· Hombre, notamal 18%
· Tá chulo 36%
· La rubia lo haría así 13%

Votos: 22
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Monta un servidor para un proyecto libre | 8 comentarios (6 temáticos, 2 editoriales, 0 ocultos)
Elegir el software a juego con el hw del servidor (5.00 / 1) (#2)
por jorginius ("jorginius" en Google Mail) a las Sat Aug 14th, 2004 at 01:46:49 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

El servidor que yo uso, a pesar de ser bastante robusto [...] 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

El cvsweb sí que genera contenidos dinámicos y carga al servidor pero el awstats genera páginas estáticas (se puede configurar) así que se hagan muchas o pocas consultas, Perl sólo se ejecuta una vez cada x tiempo y no estás ganando nada por ese lado al dejarlas como privadas.

Por otra parte, no sé cuantos hits recibes ni cuantas veces consultas los logs, pero correr el awstats cada 10 minutos me parece una pasada, más que nada por lo que pesa. Con correrlo una o dos veces al día creo que sobra (a horas intempestivas y con baja prioridad).

Sobre cvsweb, puedes usar mod_perl para mejorar bastante el rendimiento. El truco está documentado en Running CGI Scripts with mod_perl. No hace milagros pero seguro que notas la mejora en tu hardware.

Mailman está escrito en Python y es bastante pesado. Otras soluciones mucho más ligeras son Sympa y eCartis para la interfaz web de las listas.

Evidentemente, hay aplicaciones más exigentes que otras pero en general deberías evitar programas escritos en Python, en PHP y en Perl (por ese orden). Busca siempre módulos del Apache o CGI escritos en C, y para scripts que manejen logs o para pequeñas tareas de administración en el cron o para pequeños CGI, si puedes hacerlo en Awk y en shell script antes que en Perl mucho mejor.



Sí pero cuidadín (none / 0) (#3)
por man ls a las Sat Aug 14th, 2004 at 02:55:30 PM CET
(Información Usuario)

Por otra parte, no sé cuantos hits recibes ni cuantas veces consultas los logs, pero correr el awstats cada 10 minutos me parece una pasada, más que nada por lo que pesa. Con correrlo una o dos veces al día creo que sobra (a horas intempestivas y con baja prioridad).
Tienes más razón que un santo, lo acabo de cambiar. Pero hay un problema: el objeto de correrlo cada 10 minutos es también para que procese el fichero de log antes de que logrotate lo cambie: una vez que se renombra a access.log.1, awstats pasa de él. Si logrotate corre digamos a las 6:25 y awstats a las 6:30, todas las semanas se perderá todo un día de estadísticas.

En esta página recomiendan trastear con logrotate, cosa que está bastante por encima de mis posibilidades de BOFH. Así que lo que he hecho es fijarme en que logrotate se ejecuta como proceso diario en /etc/cron.daily, comprobar la hora a la que corre en /etc/crontab:
25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
y cambiar /etc/cron.d/awstats:
0 6 * * * root cd /var/www/cgi-bin/ && ./awstats.pl -config=foo > /dev/null
10 6 * * * root cd /var/www/cgi-bin/ && ./awstats.pl -config=bar > /dev/null
que me parece más sencillo.
Mailman está escrito en Python y es bastante pesado. Otras soluciones mucho más ligeras son Sympa y eCartis para la interfaz web de las listas.
La interfaz web no es lo que más me preocupa, porque mailman genera páginas estáticas en /var/lib/mailman/archives/public/. ¿Se cargará mucho el servidor cuando haya cierta actividad en las listas?

[ Padre ]


Más Mailman (none / 0) (#4)
por jorginius ("jorginius" en Google Mail) a las Sat Aug 14th, 2004 at 03:49:13 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

el objeto de correrlo cada 10 minutos es también para que procese el fichero de log antes de que logrotate lo cambie

Buena puntualización :-). En efecto, hay que tener cuidado.

La interfaz web no es lo que más me preocupa, porque mailman genera páginas estáticas en /var/lib/mailman/archives/public/.

Bueno, la parte de altas, bajas y de gestión es dinámica. Además, alguna vez tendrás Perl y Python a un mismo tiempo sirviendo peticiones y puede ser excesivo.

Una cosa que no trae la parte dinámica de Mailman es un buscador de mensajes.

¿Se cargará mucho el servidor cuando haya cierta actividad en las listas?

Supongo que depende de tu configuración, de cómo configures Mailman y de si lo tienes con un alias, a lo Majordomo, porque cada mensaje que reciba la lista sería procesado por un script de Python (con arranque de intérprete cada vez incluido) y eso no es bueno... No sé cómo se engancha en el Exim.

El eCartis (por decir algo) es bastante más rápido. Si ya tienes Mailman puesto es cuestión de dejarlo crecer. Después si ves que no sirve siempre puedes cambiarlo sin muchos traumas.

De todas formas, en esto del rendimiento el MTA tiene mucho que decir (en cómo se despachan los mensajes) y los discos y el ancho de banda. Es cuestión de probar: podrías hacerte tu mismo mailbombing y ver que pasa.

[ Padre ]


 
Mi opcion (none / 0) (#5)
por Envite a las Mon Aug 16th, 2004 at 08:50:21 PM CET
(Información Usuario)

una web con apache que no tiene casi nada
0% de copias de seguridad (mea culpa)
cvs, con cvsweb, pero SIN PSERVER
y listitas de correo con mailman y qmail


pos eso, que a correr
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire



¿Sin copia de seguridad? (none / 0) (#6)
por man ls a las Thu Aug 19th, 2004 at 06:06:41 PM CET
(Información Usuario)

¡Tsck, tsck! Por lo menos hazte una copia manual de vez en cuando, que no viene mal.

Si tienes cvsweb es que tienes el módulo de cgi's activado, con lo cual ya puedes colocar estadísticas con muy poco esfuerzo. A mí la curiosidad de si entra mucha gente no me dejaría dormir -- aparte de que tengo que informar a mi gerente de cómo va la cosa.

[ Padre ]


Weno... (none / 0) (#8)
por Envite a las Wed Aug 25th, 2004 at 07:09:39 PM CET
(Información Usuario)

Copia de seguridad de la "ultima version" la hay en mi "working directory" de CVS, aunque claro, es el mismo disco duro.

En cuanto a estadísticas, pues sí, las hay:
http://www.rolamasao.org/webalizer
No estoy de acuerdo con lo que dices, pero defenderé con mi vida tu derecho a decirlo.
Voltaire

[ Padre ]


 
Monta un servidor para un proyecto libre | 8 comentarios (6 temáticos, 2 editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda