Cómo monté mi servidor web
Aquí explico las ideas que tuve durante el montaje y los respectivos problemas y soluciones. En lo que invertí más tiempo fue en la parte teórica: pensar todos los detalles (todos) sobre papel. Cuando ya tuve todas las decisiones hechas pude empezar a montarlo y a solucionar los imprevistos.
En total tardé menos de un mes, a ritmo lento (era mi mes de vacaciones). Aquí pondré todo en orden cronológico.
Virtual hosting… vhosting para los amigos
Eso mismo. Al ponerme un servidor ya sabía que habría más cosas alojadas aparte de mi web, y ya que me he preocupado de montarlo prefiero que sirva de algo más que de contenedor para la basura que es mi web.
Mucha gente crea carpetas en su servidor, por ejemplo www.miservidor.com/~pepe, o www.serv.com/users/yo o cosas así, lo malo es que si no te gusta esa dirección tienes que hacer una redirección por HTTP, y eso es muy feo.
Lo del virtual hosting es mucho más elegante: imaginemos que Google y Slashdot leen esta web y me piden alojar sus páginas en mi servidor. Entonces los root servers de DNS traducirían google.com y slashdot.org a mi IP, 217.126.10.173.
Y si vienen de los dos sitios a mi IP, ¿cómo distingo qué página dar a cada visitante? Pues por la petición HTTP que me hacen. Ejemplo:
GET / HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040215
Accept: text/xml,application/xml,application/xhtml+xml,text/html, etc, etc, etc
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Fíjate en el campo Host, ése es el que le dice qué dominio ha pedido. Con esta información, que entiende mi servidor, ya sé qué página dar, en este caso será la / (lo dice la petición GET) del host www.google.com.
Esta petición es HTTP/1.1, por tanto es obligatorio especificar el Host. El problema es que en HTTP/1.0 es opcional y en HTTP/0.9 no hay nada de eso (sólo un GET página). Puedes ver en qué consiste cada versión aquí: HTTP 0.9, HTTP 1.0, HTTP 1.1.
Por suerte no quedan muchos navegadores que usen la 0.9 (al menos yo no he visto ninguno). En todo caso, mi idea es tener como mínimo dos webs: la mía, a la que se entra desde www.danielclemente.com o danielclemente.com, y una ‘por defecto’ a la que se entrará si no has especificado ningún Host o si has escrito la IP a mano. Esta página tendría un índice de las páginas que alojo en mi servidor y la forma de entrar en ellas.
El entorno para chroot
Dentro del directorio /f tenía que crear una estructura de directorios y archivos propia de un sistema UNIX para que se ejecutara el servidor web y los programa CGIs. El chroot lo que hace es convertir en raíz (/) el directorio especificado, por lo que si, dentro de la jaula, el usuario root te hace un rm -rf /, sólo te habrá borrado el directorio de chroot.
Lo primero que pensé es que ya habría mini-distribuciones de Linux preparadas para esto que contengan los programas necesarios: bash, ls, gcc, perl, … Seguro que hay, pero no busqué mucho y decidí hacerlo a mano. Descubrí que es muy fácil si se usan las herramientas apropiadas. Esta captura de pantalla deja claro el proceso (‘captura’ en modo texto aquí):
Y así con cada programa, tienes que copiar las librerías que necesita (ya sabes, man ldd si no sabes qué hace).
Opciones de thttpd
Lo bueno de elegir un servidor sencillo es que pude revisar todo el código fuente y leerme y entender por completo el manual de uso. Sabiendo manejar el programa entero, no tuve ningún problema.
thttpd no necesita archivo de configuración; todas las opciones se pasan como parámetros. Por eso me hice un script que hacía lo siguiente:
#!/bin/sh
/bin/thttpd -p 80 -d /f -r -u webo -dd web -c “\
217.126.10.173/cgi-bin/*|\
danielclemente.com/cgi-bin/*|\
www.danielclemente.com/cgi-bin/*|\
amarok/cgi-bin/*|\
172.26.0.11/cgi-bin/*\
” -l /f/log/este_mes -v
Explicación:
- -p 80: es el ‘por defecto’, pero sólo para asegurarme. Mi intención era que thttpd no se ejecutara como root sinó como un usuario normal, y por tanto pensaba usar un puerto no privilegiado (ej. 8000) y hacer NAT desde el router, pero como para el chroot hace falta ser root (luego baja de privilegios), acabé usando el 80.
- -d /f: directorio al que entra al ejecutar el programa
- -r: hacer chroot en el directorio del programa (o sea, el /f de la opción anterior)
- -u webo: usuario al que cambiar después de hacer las cosas que requieren ser root. Es importante no ser root dentro del chroot, porque entonces es ‘fácil’ salir mandando unas señales.
- -dd web: directorio al que entra después de haber hecho el chroot. O sea, que las webs están en /f/web
- -c “blablabla”: archivos que deben ejecutarse en vez de mostrarse, o sea CGIs. Además han de ser ejecutables (+x). Tengo que poner cada nombre de host (aunque la web sea la misma) por la diferencia que se hace con lo del virtual hosting: quizás alguien quiera que desde miweb.com vayan los CGIs pero desde www.miweb.com no. Nota que el * lo traduce el bash a los nombres de archivo que hay en ese momento en cada directorio, por lo que si luego añades nuevos CGIs hay que reiniciar el servidor dándole la nueva lista.
- -l /f/log/este_mes: dónde añadir los logs (lo explico luego)
- -v: hacer virtual hosting. En /f/web no habrá una web con su index.html, sinó directorios, cada uno llamado con un nombre de host (ej. www.miweb.com) y con su index.html y familia dentro.
El proceso se arranca como demonio; para hacer pruebas va bien el -D que lo deja en primer plano.
Logs
Me hice este script que rota y archiva los logs, muy sencillo. Está en /etc/cron.monthly
#!/bin/sh
# Rotar logs. EJECUTAR EL PRIMER DÍA DE CADA MES
cd /f/log
rm -f hace12meses.gz
mv hace11meses.gz hace12meses.gz
mv hace10meses.gz hace11meses.gz
mv hace9meses.gz hace10meses.gz
mv hace8meses.gz hace9meses.gz
mv hace7meses.gz hace8meses.gz
mv hace6meses.gz hace7meses.gz
mv hace5meses.gz hace6meses.gz
mv hace4meses.gz hace5meses.gz
mv hace3meses.gz hace4meses.gz
mv hace2meses.gz hace3meses.gz
mv hace1mes.gz hace2meses.gz
/bin/gzip este_mes
mv este_mes.gz hace1mes.gz
kill -HUP `pidof thttpd` || /root/servweb
Si no sabías lo que era rotar logs, pues ya lo sabes (es descartar el más viejo para que quepa uno nuevo; sólo tengo 12 posiciones). La última línea reinicia el servidor web o, en caso de que no esté activo, lo inicia.
También podía haber usado herramientas automáticas que lo hacen, como logrotate. Pero mi script es más sencillo porque tiene sólo lo que yo quiero.
Un watchdog para el servidor web
Puede que, por alguna razón rara, el proceso thttpd muera y me quede sin servidor. Por eso me hice un ‘watchdog’, o ‘perro guardián’, que comprueba periódicamente si está activo y si no lo está lo inicia. Al principio se ejecutaba cada día porque no encontré un /etc/cron.hourly (lo mímino era daily)… pura vagancia. Luego le añadí 05 * * * * root /root/wdogweb al /etc/crontab para ejecutarlo cada hora a los 05 minutos.
El script es realmente sencillo y muy bonito:
#!/bin/sh
pidof thttpd || /root/servweb
# equivale a: if ! pidof thttpd; then /root/servweb; fi
Me han comentado que hay utilidades como daemontools que se encargan de arrancar y vigilar servicios, pero ahora que ya he aprendido a usar cron creo que no me hace falta otro programa para hacer lo mismo. No digo que no sea útil; al contrario, va muy bien por si tienes muchos servidores.
Servidor FTP
Necesito uno para dos cosas:
- Subir/bajar archivos de la web, no sólo yo sinó cualquier otro usuario
- Espacio temporal para chorradas al que pueda acceder desde cualquier sitio.
Y quiero uno como el servidor web, que sea sencillo y elegante (sin chapuzas). Me miré muchos (me fue bien un ‘apt-cache search ftp’ en una Debian inestable), pero eran difíciles de entender, y muchos no funcionaban o directamente no compilaban por fallos en el código. Al final acabé usando ‘el de siempre’: mi preferido, el pure-ftpd.
Lo compilé con la opción de chroot virtual (–with-virtualchroot), que encierra a cada usuario en su directorio personal, pero si hay un enlace que lleva fuera deja seguirlo. Éste es el caso, ya que el usuario dc, por ejemplo, tiene en su home /home/dc el enlace simbólico /home/dc/web que le lleva a /f/web/danielclemente.com (su web). Sin esta opción no deja salir del $HOME de ninguna manera.
El servidor lo arranco con este comando:
/usr/local/sbin/pure-ftpd -A -B -u 100 -C 5 -4 -E -k 90
Qué hace cada cosa:
- -A: hacer chroot() en el home de cada usuario (excepto root, pero root no se conectará)
- -B: arrancar en segundo plano
- -u 100: no pueden entrar los usuarios con UID menor de 100 (root y otros de sistema)
- -C 5: máximo 5 conexiones por IP
- -4: escuchar sólo conexiones IPv4 (no sé usar IPv6, mejor lo desactivo)
- -E: no permito conexiones anónimas, aunque es interesante activarlo, así entra gente que ni conoces y te deja programas (lo malo es que suelen ser ilegales).
- -k 90: no deja subir nada más si el disco duro está lleno al 90%
Acceso al FTP desde fuera
Quiero una cuenta FTP multiuso que sirva para dejar notas y ficheros sueltos y poder acceder desde cualquier sitio. Será casi público, pero con contraseña.
No voy a usar las cuentas de la web, porque el FTP es inseguro (va en texto plano) y no hay conexión SSH directa al servidor, por tanto no puedo usar sftp. Eso no va muy bien y puede dar problemas, pero no doy acceso SSH por seguridad (más adelante me lo pensaré).
Por tanto, lo que hice fue crear una cuenta ‘basura’, de nombre efetepe, grupo efetepe, y una contraseña realmente absurda.
Empiezan los problemas serios: esto se cuelga
Ahora me tocaba hacer un cortafuegos y probar la seguridad, así que le hice varios nmap como de costumbre. Lo curioso fue que al cabo de varios nmaps empezó a tener los puertos cerrados. Me extrañó, porque aún no había puesto ningún IDS, pero luego descubrí -levantándome y sacándole de su sitio- que se había quedado colgado. (Quizás es un nuevo sistema de seguridad; lo he visto en acción en las últimas versiones de Windows).
No me costó mucho descubrir cuál era el problema, ya que al pasar archivos grandes por FTP pasaba lo mismo. Curiosamente, el ping -f lo aguantaba, pero los escaneos rápidos de nmap no. Usando las opciones de velocidad de nmap, vi que se colgaba sólo con -T3 para arriba, el -T2 ya iba bien. Lo característico del -T2 es que manda los paquetes en serie, o sea uno detrás del otro. -T3 ya empieza a mandar varios a la vez, y eso es lo que hacía que se colgara la tarjeta de red PCMCIA.
Comparar distancias entre ordenadores
Haciendo pruebas con el ping -f y otros descubrí el ‘ping adaptativo’, estaba en la primera página del man ping. La sintaxis es ping -A host y consiste en mandar pings lo más rápido que pueda sin perder paquetes. Eso no quiere decir ‘muy muy rápido’, sinó lo más rápido posible. Si ve que se pierden paquetes manda más despacio.
Mandamos un ping, que viaja a través del cable, llega a su destino y vuelve en forma de respuesta. Nada más llegar mandamos otro, y así todo el rato. Por el tiempo que tardan en volver podemos adivinar cómo de lejos está el destino. Naturalmente, depende de muchas condiciones, por eso no he hablado de medir distancias sinó de comparar. Las pruebas que he hecho en mi casa son creíbles y se corresponden con la topología de mi red.
Supongo que si se llaman ICMP echo request y reply es por esto; también podemos saber cómo de lejos está una pared por el tiempo que tarda en llegar el eco.
No pierdo el honor; arreglo lo del cuelgue
La verdad es que no tenía ni idea de por qué fallaba la tarjeta de red, sólo sabía que no era normal. Probé muchas cosas sin parar, porque no puedo ir diciendo por ahí que ‘mi Linux se cuelga y no sé cómo arreglarlo’. Después de tocar muchas cosas y de compilar muchos kernels, descubrí la opción mágica que lo solucionaba:
Dentro de la sección de dispositivos de red, en la del 8139too, “RealTek RTL-8139 PCI Fast Ethernet Adapter support”, hay una que pone “Use PIO instead of MMIO”. Hay que activarla.
Ahora aguanta sin problemas un while :; do nmap -vv -P0 -T5 -p1-65535 -r amarok; done
iptables
Nada complicado; el servidor usará FTP y HTTP desde fuera y SSH desde mi ordenador ‘grande’ (cuya dirección MAC es estática y por tanto siempre corresponderá a la misma IP).
Además sólo analizo las conexiones nuevas (las que sólo tienen el bit SYN activado), acepto las de loopback, no acepto UDP, y sí que dejo ICMP request y reply. Todo lo demás lo ignoro (DROP). Las conexiones salientes las acepto (para que funcione el FTP) pero el forwarding no.
Me queda este script para ejecutar al inicio:
#!/bin/sh
# Mi cortafuegos; 13/2/2004 1:49 AM, Daniel Clemente
iptables -F INPUT
iptables -A INPUT -m state –state ESTABLISHED -j ACCEPT
iptables -A INPUT -m state –state NEW -i lo -j ACCEPT
iptables -A INPUT -m state –state NEW -i eth0 -p tcp –dport 20 -j ACCEPT
iptables -A INPUT -m state –state NEW -i eth0 -p tcp –dport 21 -j ACCEPT
iptables -A INPUT -m state –state NEW -i eth0 -p tcp –dport 80 -j ACCEPT
iptables -A INPUT -m state –state NEW -i eth0 -s 172.26.0.2 -p tcp –dport 22 -j ACCEPT
iptables -A INPUT -m state –state NEW -i eth0 -p icmp –icmp-type echo-request -j ACCEPT
iptables -A INPUT -m state –state NEW -i eth0 -p icmp –icmp-type echo-reply -j ACCEPT
iptables -P INPUT DROP
iptables -F FORWARD
iptables -P FORWARD DROP
iptables -F OUTPUT
iptables -P OUTPUT ACCEPT
Cambios en el router
El ordenador destino por defecto es el grande, de nombre pc. Para el servidor sólo tuve que redirigirle los puertos 20, 21 y 80; el resto de puertos se refieren al ordenador grande.
Normalmente el router (OCR 812) tiene una página web de configuración en el puerto 80; la cambié al puerto 8000 de esta forma:
disable network service httpd
set network service httpd socket 8000
enable network service httpd
save all
Cómo probé el virtual hosting yo solito
Ahora necesitaba probarlo todo un poco: pedí que me hicieran unos escaneos de puertos, pero aún me quedaba mucho por probar sobre lo de servir páginas distintas dependiendo de la página pedida.
Puse dos páginas diferentes: una para cuando se entrara por 172.26.0.11 y otro para cuando se entrara por 217.126.10.173. ¿Cuál es el problema? Pues que si yo, desde el host pc (172.26.0.2), intento conectar a 217.126.10.173, la petición llega al router, y éste debería redirigirla al servidor (172.26.0.11) aplicando el NAT, pero no lo hace. No lo hace porque está configurado para aplicar estas reglas de redirección de puertos sólo a las conexiones que vienen de la red ATM que tiene configurada, o sea de fuera.
Para simular conexiones desde fuera lo más cómodo es tener una shell en algún ordenador y conectar desde ahí, pero en ese momento no tenía ningún login y password preparados para eso. Lo que hice fue buscarme unos proxys de Telefónica, configurar mi navegador, y acceder a mi IP (pública). Entonces la petición sí que venía de fuera, y el router la redirigía al puerto 80 del servidor. Le dije al Mozilla que no usara proxy para acceder a los 172.26.0.*, y así ya podía entrar al mismo ordenador de dos formas distintas, y cada una recibiendo una respuesta distinta.
Quiero un contador; no tengo PHP
Cuando usaba PHP me hice un index.php que incluía un contador en modo texto, y no me costó mucho. Pero ahora he decidido no poner PHP en el servidor web, y tengo que hacerme un contador nuevo. ¿Qué puedo hacer?
Podría instalar PHP como un programa (en vez de como extensión de servidor) y hacer que se ejecute como CGI, pero para hacer un programita que suma 1 a una variable no me hace falta todo eso.
Es fácil hacer un contador en bash. El siguiente comando ya sirve:
echo $(( `cat cont` + 1 )) > cont
El problema es que no puedo incrustar en mi index.html el contenido del archivo cont. Me gustaría hacer un <#include “cont”> pero en HTML eso no se puede hacer y thttpd no es de los que tienen Server Side Includes (bueno, tiene, pero no es nada cómodo).
Podría hacer que el fichero index.html fuera un ejecutable (CGI) que mediante echos mande la página y con un ‘cat cont’ meta el número correspondiente en el sitio que toca. Me parece bastante chapucero… prefiero tener todos los CGIs en el mismo sitio.
En HTML no se puede incrustar contenido text/html, pero sí imágenes (se hace con la etiqueta IMG). O sea, que mi CGI podría crear una imagen, y hacer un cat mandándola con el Content-type correspondiente. Y ahora, ¿cómo creo una imagen -por ejemplo un PNG- que tenga escrito un número? Eso lo hacen los magníficos programas de ImageMagick; por ejemplo con este comando:
# blanco.png es todo blanco. Seguro que hay formas mejores de hacer esto…
convert -font helvetica -pointsize 25 -fill blue -draw “text 5,22 ’142857′” blanco.png texto.png
Aparte de ser muy chapucero, esta solución requiere meter muchísimos programas, librerías y fuentes dentro del chroot, y además sería bastante lento.
Encontré otro programa (también dentro de ImageMagick) muy útil, es montage y sirve para juntar imágenes. Me bastaría con tener los dígitos del 0 al 9 cada uno en un archivo, y luego, mediante un script, ir juntando cifras para hacer cada número. Por último, servir la imagen con un cat. Ejemplo:
montage 1.png 4.png 2.png 8.png 5.png 7.png 142857.png
Sería lento, pero tampoco mucho. Tendría que hacer el script que creara la lista de parámetros a partir del número leído; ahora mismo no se me ocurre ninguna forma fácil de hacerlo, pero con sed, awk o perl se puede. Me falta tiempo para esto… antes tengo que aprender a usar los paquetes de coreutils y leerme el man bash.
Tiene que haber programas que hagan solos lo de crear una imagen con un número escrito. No busqué mucho, pero encontré uno, swc (simple web counter), pero no me gustó porque ha tenido un fallo importante de seguridad y -lo importante- porque usa imágenes GIF, que es un formato con un sistema de compresión patentado por Unisys Corporation, el LZW. Me da asco meterme en estos temas, así que mejor no uso el programa. Yo lo veo como una trampa.
Resumiendo, que no puedo incrustar texto en HTML, pero sí imágenes (IMG). Entonces me acordé de que también se pueden incluir scripts; ahí vi la solución. Hice un script llamado cuenta así:
#!/bin/bash
echo “Content-type: text/plain”
echo
echo -n $(( `cat cont` + 1 )) > cont
echo -n document.write\(\”
cat cont
echo -n \”\)\;
Y luego sólo tenía que incluírlo en todas las páginas que quiera con <SCRIPT TYPE=”text/javascript” src=”cgi-bin/cuenta”></SCRIPT>
El problema es que no todos los navegadores soportan JavaScript. Normalmente los que no lo soportan tampoco muestran imágenes, así que creo que mi solución es tan efectiva como la de la imagen. De todas formas sigue siendo una chapuza que he de arreglar cuando me aburra.
Copias de seguridad periódicas
Siempre hay que hacer una copia de seguridad de todo; aunque la web esté en mi casa es posible que el portátil se queme (tal como han pronosticado algunos) o que el disco duro deje de girar de tanto arrancarlo y pararlo. Prefiero no fiarme y mantener una copia actual en mi ordenador grande (desde ahí la puedo pasar a CDs).
Lo hice con este script, bakupa, que es para ejecutar en el ordenador grande (172.26.0.2). 172.26.0.11 es el servidor.
#!/bin/sh
# Esto hace una copia de la web del servidor, y la archiva
# 17-2-2004 Daniel Clemente
dia=`date +%Y_%m_%d`
mkdir temp
echo Pon password del usuario dc
scp -r dc@172.26.0.11 :/f/web/danielclemente.com/* temp
tar jcvf ${dia}.tar.bz2 temp
rm -rf temp
Trabajar cómodamente en mi web
Lo de tener un servidor FTP rápido donde dejar la web ya es bastante cómodo, pero quiero más: quiero montar el árbol de directorios de mi web (en el servidor) en un directorio local.
Para eso está el NFS, pero es muy complicado de configurar y a veces poco seguro. Samba estaba bien, pero no quiero instalarle más cosas al servidor, y menos eso (a ver si ahora va a tener tantos recursos compartidos como los Windows que me encuentro por Internet).
Lo que me interesa son los módulos para el kernel que implementan un sistema de archivos basado en FTP o en SSH. No hay que tocar nada del servidor, sólo tener los servidores correspondientes. O sea, que los kernels los tengo que modificar en el ordenador ‘grande’, el servidor no lo toco para nada.
Hay un proyecto llamado lufs que hace todo esto con muchos sistemas de archivos, pero lo vi demasiado extenso comparado con los proyectos que trabajan sólo con uno.
El de FTP es ftpfs, y me fue bien pero me daba un error de “Stale NFS file handle” al querer cambiar de directorio. De todas formas, el FTP no es seguro, así que probé por SSH.
El de SSH se llama shfs y es muy fácil de usar. Aquí (Linuca) vi un tutorial que me ayudó un poco con unos problemas que tuve con el kernel. Lo conseguí poner, y, bueno, funciona perfectamente. Tampoco hay mucho más que decir.
Ahora puedo usar Mozilla Composer y mis programas preferidos para tocar archivos del servidor sin tener que instalarlos en el servidor.
Cambios en el dominio
Ahora mi página sería accesible para todos cuando escribieran mi dirección IP en su navegador (por suerte tengo IP fija y sería siempre la misma). Pero lo que yo quiero es que se pueda entrar desde www.danielclemente.com.
¿Qué hace falta para eso? Pues comprar (en realidad alquilar por un año) un dominio libre y hacer que se traduzca a mi IP cuando alguien lo escriba. Hay unos cuantos ordenadores importantes por el mundo que mantienen una tabla con la equivalencia entre cada nombre de dominio y cada IP: son los servidores DNS.
Para que añadan un registro que apunte a tu IP tienes que pagar, aunque no mucho. Por ejemplo, yo lo compré en GoDaddy por unos 9 dólares USD, y vale por un año. No voy a hacer propaganda de ninguna empresa; busca ‘domain registrars’ que es que como se llaman en inglés. Que sepas que un .com te puede salir por $7 o $30 dependiendo de en dónde te dejes timar, y un .es de 100 euros para arriba, más gastos de patentes, tasas, trámites, etc. (¡viva el Ministerio de Ciencia y Tecnología!).
Ah, el registro de un .com suele ser fácil. Tienes que dar datos ciertos sobre tu nombre, dirección, teléfono y e-mail, y pagar con tarjeta de crédito (una de esas ‘virtuales’ ya vale). Como pagas, tienes soporte técnico que te ayudará en todo.
Una vez “comprado” el dominio, hay varias opciones (todas hay que buscarlas desde el ‘Centro de control’ de la web del registrador): por ejemplo, puedes redirigirlo a otra página, poner un mensaje de ‘En venta’, alojar algún archivo (pero con publicidad ya que el hosting se paga aparte) o decir directamente a qué IP está ligado ese dominio.
Lo que yo hice fue informar a todo el mundo de que www.danielclemente.com = 217.126.10.173. De eso se encargan los servidores DNS; pero como yo no tenía ganas de poner un servidor DNS en mi ordenador, usé los servidores de GoDaddy para añadir esa entrada mediante una opción de su web (es un servicio que dan gratis). Como todos los DNS están relacionados, un cambio en uno de ellos se propaga a todos los del mundo en unas horas.
Encontré una opción perdida en la web que permitía editar el archivo de zonas DNS; desde ahí pude incluir la línea A necesaria. Quedó así:
| Nombre de zona | Tipo | Valor |
|---|---|---|
| @ | A | 217.126.10.173 |
| www | CNAME | @ |
La A da la traducción de danielclemente.com (que sale representado como @) y el www es un alias a @, o sea, que tanto danielclemente.com como www.danielclemente.com resuelven a mi IP. De hecho, todos los subdominios traducen a mi misma IP, así que seguro que podría quitar el www ése.
Tuve que esperar dos días para que los cambios surtieran efecto, y después fue muy bonito ver la ‘propagación DNS’: poco a poco esta información fue llegando a todos los servidores -incluso a los pequeños, pero más tarde- empezando desde los de la empresa de dominios hasta llegar a todos los del mundo. Es fácil comprobarlo usando órdenes como éstas:
dig www.danielclemente.com # Uso los servidores configurados en mi /etc/resolv.conf
dig @195.235.113.3 www.danielclemente.com # A ver qué hay en el de Telefónica
dig @PARK3.SECURESERVER.NET www.danielclemente.com # A ver qué piensan los de GoDaddy (los primeros en actualizarse)
Conclusiones
Por fin tengo mi servidor montado; creo que me he enrollado bastante en algunos puntos pero tenía ganas de hacerlo.
Resumiendo, he montado mi propio servidor desde cero tanto a nivel hardware como software. En realidad es poca cosa (servidor web y ftp), pero lo poco que hace lo hace muy bien. Lo he pensado todo mucho y creo que he tomado la mejor decisión en cada momento, con varias excepciones: sé que he hecho bastantes ‘chapuzas’ (o ‘problemas que no he resuelto de forma elegante’), pero soy consciente de ello y las arreglaré cuando haya aprendido lo suficiente.
He aprendido mucho, y lo importante es que no me he repetido. Ya pasé muchos meses escribiendo y pensando cómo montar un servidor que hiciera de todo para mi instituto (fue mi ‘Treball de Recerca’ del Bachillerato, y ganó un premio CIRIT de la Generalitat). Todo el tiempo que perdí con eso no lo he vuelto a perder aquí, y tampoco se parecen mucho. En el servidor-que-hace-de-todo de mi instituto sólo tuve que instalar cada cosa, una detrás de otra. En este estudio resuelvo mis necesidades personales, y eso cuesta mucho más que hacer apt-gets.
Una conclusión importante que deberías sacar si ya has leído hasta aquí es que el documento se acabará pronto…
Septiembre 2006: bueno… no del todo, porque cuando apagué el servidor (dos años y medio después), escribí qué tal funcionó mi servidor.
Sobre este documento
- Todo esto lo he escrito la tercera semana de febrero de 2004. El trabajo físico lo había empezado un mes antes.
- Licencia: FDL, los programas GPL y las imágenes igual. No hace falta que me pidas permiso para usar partes del documento, pero conserva mi nombre por algún lado o un enlace aquí: www.danielclemente.com/amarok
- Lenguaje: he intentado poner todos los acentos y letras; avísame si hay erratas. Sé que he mezclado los tiempos verbales de formas muy raras, pero es que no sabía con cuál quedarme. Iba a poner en cursiva los extranjerismos, pero hay tantos que tendrás que saber detectarlos.
- Idiomas: en principio no traduciré el documento a otros idiomas, porque el español es fácil de aprender (al menos más fácil que el inglés).
- Las fotos de mala calidad las he hecho con una Best Buy Easy Point & Click y con el driver spca50x. La cámara tenía más calidad antes de que la abriera y le hiciera cosas por dentro.
- El dibujo del cortafuegos es mío…
Lo hice con una tableta gráfica Wacom usando sodipodi y gimp. El diseño vectorial es éste: cortafuegos.svg (abrir con sodipodi). - Lo he hecho todo con el Mozilla Composer, es magnífico. Sobre todo me ha gustado lo de que genere la ‘Tabla de contenidos’ automáticamente. Confieso haber usado también vim para tomar notas.
- Llevaba años queriendo poner esta imagen. Gracias otra vez, Mozilla Composer.
\n
Posts Relacionados:
¿Disfrutaste esta entrada? Por qué no dejas un comentario abajo y continúas la conversación, o te suscribes a mi feed y obtienes artículos como este enviados a tu lector de feeds.
Es muy interesante el articulo, e instruccional sigue publicando mas de estos temas.