En febrero de 2004 puse en mi casa mi servidor web: un portátil Pentium 133 Mhz, con 32 Mb de RAM, funcionando con Debian GNU/Linux. En septiembre de 2006 tuve que apagarlo porque me fui a estudiar al extranjero (de Erasmus). Aquí explico qué problemas me dio durante los dos años y medio que estuvo encendido (sin reiniciar), y los resultados conseguidos.
Septiembre 2006 (actualizado el 18-09-2006), Daniel Clemente Laboreo
Necesitaba un sitio en donde alojar mi página web (www.danielclemente.com), que fuera estable, fácil de actualizar, barato y que causara pocas molestias.
Decidí usar un servidor propio, o sea, un ordenador encendido todo el día en mi casa. Lo que le pedía entonces era:
Esta parte está explicada en el artículo "Cómo monté mi servidor". Resumiendo, lo que hice fue:
Escondí el portátil en una estantería de mi habitación, y lo dejé encendido ahí todo el día, junto con mi ordenador grande, unos cuantos aparatos de red, y muchos cables; incluso tuve que poner un cable de 30 metros de largo que iba hasta el router.
¡No! Quería un ordenador que no hiciera ruido, y el que puse sí que hacía, porque tenía disco duro. Pero bueno, es muy poco y no molesta; más ruido hacen mis pantallas...
Por lo demás, el servidor funcionó muy bien: aguantó dos años y medio encendido (sin reiniciar) y probablemente habría aguantado más si no lo hubiera apagado yo... Durante todo este tiempo no me causó molestias: simplemente me olvidaba de que estaba funcionando.
Sobre la instalación que hice: bueno, pues me equivoqué en varias cosas, pero al ser un proyecto pequeño, las consecuencias no fueron graves. También hice varias chapuzas, que luego explico.
Toda la experiencia me sirvió para aprender mucho para la próxima vez, y para escribir más artículos. Por ejemplo, otro de mis objetivos era que gastara poco, pero no tenía ni idea de cuánto gasta un ordenador, y en Internet no encontré nada que me ayudara. Al final me tocó escribirlo a mí, aunque no entiendo mucho del tema del consumo eléctrico... Pero descubrí que sí que gastaba poco (unos 9 W).
Pocos días después de poner en marcha mi servidor, llegó el primer reto: una avalancha de visitas que venía del portal Barrapunto. No es que fueran muchas, (unas 2.300 el día en el que más hubo), pero entraban todos a la vez y saturaban mi línea ADSL. Esto pasa en muchos portales de noticias importantes, y en el caso de Barrapunto se habla del efecto Barrapunto.
Escribí una sección sobre cómo afectó esto a mi servidor web. Me di cuenta de un problema importante, que no había tenido en cuenta: el tamaño de los ficheros de registro. Yo había dejado 50 Mb para guardarlos todos, y es suficiente porque se graban comprimidos, de forma que las visitas de todo un mes quedaban en un fichero de menos de 1 Mb (al principio; luego fue más).
Lo que no había pensado es que durante el mes, ese fichero está totalmente descomprimido, y no ocupa 1 Mb, sino 20 Mb, 50, 90, 100, o más (lo he visto hasta de 220 Mb).
Me di cuenta pronto de que una partición de 50 Mb era insuficiente para el registro de todo un mes sin comprimir, y decidí hacer una chapuza de la que ahora me arrepiento: rehacer la tabla de particiones para juntar la partición de registro con la partición raíz (/). Recomiendan reiniciar después de hacer un cambio en la tabla de particiones, pero no lo hice... y no sabía si cuando reiniciara seguiría funcionando.
Para evitar este problema, una solución mejor habría sido usar LVM en vez del sistema anticuado de cambiar la tabla de particiones.
Rectifico: la solución es más fácil: no hace falta conservar el registro de todo un mes. Se puede grabar sólo la última semana, o los últimos tres días, y pasarlo al programa de estadísticas cada poco tiempo. Éste es el que se encarga de transformar los datos en información útil.
Lo del Barrapunto me afectó otras veces, con diferentes cantidades de tráfico generado. Aquí pongo unos números sobre visitantes diarios en el día más relevante de cada vez:
O sea, que tampoco hay mucha diferencia. Lo malo de una avalancha de visitas es que quieren entrar todos a la vez y algunos se quedan sin poder entrar. Eso es un problema serio y hay que tenerlo en cuenta y preparar clones de la página en otros servidores.
Cambiando a otro tema... He dicho que el servidor llevaba dos años y medio encendido cuando lo apagué. Pero ¿es que no se va la luz en mi casa? Pues sí, pero ¡eso no le afecta! Es un ordenador portátil, y tiene conectada la batería, que curiosamente aún aguanta.
Cuando tenía 75 días de vida, hubo un corte de luz bastante largo: de 3 horas, y sin embargo lo soportó. Al principio me parecía inexplicable, ya que la batería era de segunda mano, y además yo había usado bastante el portátil antes de colocarlo como servidor. Pensé en por qué soportaba tanto tiempo encendido, y descubrí lo siguiente:
Muy bonito, pero no ocultaré la verdad: si se va la luz, la web no va. Para evitarlo tendría que tener un SAI al que conectar el router y switch.
Pero ya me va bien lo de que el ordenador descanse cuando hay un apagón. Así me ahorro tener que encenderlo y apagarlo, que da problemas porque hay que estar físicamente en el sitio para comprobar que se hace bien. Si conociera mejor los sistemas de encendido y apagado automáticos, podría hacer que al detectar un apagón, el Linux se hiberne (Software Suspend va muy bien) y luego se encienda otra vez cuando vuelva a haber tráfico.
Algo peor me pasó el 14 de septiembre de 2004. La historia empieza mal: había tormenta, y cayó un rayo...
Resulta que uso un router 3Com OCR 812, caro y malo, que incluye un hub de 4 puertos (o sea, que se le pueden conectar 4 ordenadores). Otra de sus características interesantes es que: con cada rayo que cae, el puerto del ordenador que esté encendido en ese momento se estropea. Lo he comprobado en dos ocasiones (con ordenadores distintos). Por tanto, me quedan 2 de los 4 puertos... :-)
Sé que tendría que usar un protector contra sobretensiones con protección para teléfono, pero en ese momento no lo tenía.
El día ése, al servidor no le pasó nada, pero se quedó desconectado de la red hasta que llegué a casa y lo cambié de puerto.
Mi conexión a Internet inicial (febrero de 2004) era un ADSL 256/128 Kbits. Como 8 bits son 1 byte, esto quiere decir que había una velocidad máxima teórica de 32 Kb/s para recibir datos ("bajada") y 16 Kb/s para enviarlos ("subida"). Naturalmente, en la práctica es todo más lento.
Me han preguntado varias veces que si es suficiente, y respondo que eso es subjetivo, pero que hacer el cálculo es muy fácil. Supongamos que yo puedo ofrecer una velocidad de subida de 12 Kb/s; eso quiere decir que 1 persona podrá descargar cosas de mi web a 12 Kb/s. Si son 2 personas descargando cosas a la vez, pues bajarán a 6 Kb/s. Si son 3, pues a 4 Kb/s. Si son 4, a 3 Kb/s. Etc. ¿Es eso suficiente? Pues depende; eso lo sabrás tú. A mí, personalmente, me parece bien, porque entra poca gente a la vez en mi página y no me molesta que esperen (lo siento por ser sincero...).
En octubre de 2004, Telefónica "dobló" el ancho de banda de las conexiones ADSL, pero entre comillas, porque lo que hizo fue cambiar sólo la velocidad de bajada. Mi ADSL pasó de 256/128 a 512/128. Consecuencias de esto:
Al menos me sirvió para poder usar más mi línea para otras cosas mientras el servidor seguía funcionando. Por cierto, el tráfico que generaba mi servidor no hacía mucho más lenta la conexión. En todo este tiempo que lo he tenido no me ha molestado (excepto en los pocos casos de avalanchas de visitas).
Un año después, en octubre de 2005, volvieron a doblar la velocidad, pero esta vez sin las comillas: la pasaron de 512/128 a 1024/300. Esto ya me fue muy bien, porque la página tenía cada vez más visitas. Daba una velocidad máxima teórica de 128 Kb/s de bajada y 37'5 Kb/s de subida, aunque en la práctica no pasaba de los 100 y 34 Kb/s (suficiente).
¿Qué cable largo? Éste:
Va del router a mi habitación, que está en la otra punta de la casa. Sé que me quedó un poco chapucero (sobre todo eso de atravesar la puerta... :-), y por eso el 17 y 18 de septiembre de 2005 hice una instalación mejor (con mucha ayuda y mucha silicona).
Preferí hacer una instalación que no necesitara hacer agujeros, para no estropear la casa. Acabé haciendo un recorrido bastante largo por dentro de casa, enganchando el cable por las esquinas. Lo pegué con silicona y le puse alguna grapa (especial para esto) en los sitios difíciles, como esquinas. Me dijeron que la silicona no aguantaba, pero ha aguantado más de un año y aún no se ha caído. Pongo unas cuantas fotitos. Primera tanda:
El cable va bien pegado a las esquinas, y si no fuera gris se vería menos. En sitios difíciles (como en la foto 3) tuve que usar alcayatas, grapas, y masilla pégalo-todo. En la quinta foto se pueden ver mejor lo de las grapas. En la sexta está muy bien puesto (sólo con silicona) y casi no se ve.
Ahora la segunda tanda de fotos (abajo). A medio camino le puse una cajetilla con un conector de red que hace de puente, por si alguna vez quiero enganchar un ordenador ahí (ver primera foto). Justo ahí es donde está la televisión grande, así que me va bien por si quiero conectar el PC a la TV. Ah, y aquí se ve que el "cable" en realidad son dos, que se unen en esa cajetilla. Cada uno mide 30 metros.
La tercera muestra cómo el cable atraviesa una puerta acordeón deslizable (es fácil; hay una rendija), pero en la cuarta y quinta se ve cómo pasa por el pomo de la puerta de mi habitación. Era el único agujero que había en la puerta, así que no podía elegir. Volví a colocar el pomo, y ahora se abre y cierra de manera normal (y no se cae ninguna pieza). En la última foto se ve que sobró cable. El tramo final pasa por encima de la puerta (lo enganché con masilla pega-todo) y llega a mi ordenador.
En realidad todo esto lo hice para tener Internet en mi habitación... :-) El servidor ya lo había movido de sitio el 18 de julio de 2004, y ya no estaba en mi habitación, sino en un armario justo debajo del router, sin tener que pasar por los 70 metros de este nuevo cable.
Paso a temas de software: hablaré de la memoria RAM. El servidor tiene sólo 32 Mb, pero eso es suficiente (luego hablaré de cómo y en qué se usaba).
Lo malo es que una vez, por septiembre de 2005, me olvidé de esto y abusé del uso de memoria. Estaba haciendo un CGI (un programita que se ejecuta en el servidor) que generaba una página personalizada con información sobre el daño que Internet Explorer hace a Internet.
El algoritmo que necesitaba era largo: había que leer el fichero fuente, procesarlo con dislines (un lenguaje que diseñé) para seleccionar las secciones pedidas, y pasarlas por txt2tags para generar el HTML.
Se me ocurrió la "fantástica" idea de hacer una tubería, típica de Linux, para pasar el texto de un programa a otro, de izquierda a derecha. Algo parecido a:
cat texto | ./dislines -opciones | ./txt2tags -opciones
El problema es que dislines está hecho en Perl, txt2tags en Python, y mi programa era otro script en Perl. Por tanto, había que tener abierto todo a la vez, y al final tenía en memoria al servidor web, a 2 intérpretes de Perl, y al intérprete de Python (que ocupa muuuucho). Todo junto y durante mucho rato; demasiado para 32 Mb.
Cuando alguien usó esto en un momento de mucha carga, el kernel entró en estado de "Out of memory", y entonces el gestor de memoria de Linux tiene que matar a algún proceso, ya que hay que cerrar algo para liberar memoria. Por eso, calcula cómo de "malo" es cada proceso, elige al más "malo" y lo mata.
El problema es que puede tomar la decisión "equivocada"
(desde el punto de vista
del usuario), y, por ejemplo, decidir que:
como el proceso thttpd es el que
más memoria está consumiendo, si se le mata se liberará mucha memoria
(y eso es bueno).
Por eso me encontré con que esa vez el Linux me mató a thttpd
(¡qué cruel que eres, Linux!),
aunque entiendo sus motivos
(los he visto en su código fuente :-).
No puedo evitar explicar el funcionamiento del algoritmo para
elegir el proceso al que matar...
Está en
oom_kill.c
en el código de Linux,
y se entiende muy bien.
Se mata al proceso que más puntos de maldad (p) tiene.
Para calcular p:
p la memoria que ocupa el proceso
p la mitad de la memoria ocupada por cada hijo del proceso (ya que si alguno crea demasiados hijos, es candidato a morir)
p por la raíz cuadrada de este número
p por la raíz cuarta de este número
p
p se reduce a una cuarta parte
p a una cuarta parte
oom_adj, que se encuentra en /proc/ y es personalizable por el administrador. Si es positivo, se multiplica p por "2 elevado a ese número" (esto acerca su muerte), y si es negativo, se divide p por "2 elevado al valor absoluto del número" (se le hace más invencible).
Los pasos 2 y 8 no están en la versión del kernel que usaba (2.4.25-pre8) pero sí en la 2.6; ambos se añadieron en la versión 2.6.11 (detalles). Como ves, el paso 8 es una gran ventaja, ya que permite hacer casi inmortal a un proceso concreto. Necesito poder hacer eso en mi servidor, y por eso el kernel 2.6 habría sido una ventaja en ese aspecto. Pero aún estaba poco maduro en cuanto a seguridad; por eso usé el 2.4.
Bueno, ¿de qué hablaba? Ah, sí, de un CGI. Al final tuve que programarlo de otra forma para que no consumiera tanta memoria, y quedó así: genpopup3.sh, genpopup3.pl. Simplifiqué el algoritmo de dislines, e hice que generara la entrada para txt2tags en un fichero temporal. Una vez acabado, se ejecuta txt2tags. Le añadí una comprobación para que no hubiera más de una copia del programa a la vez.
He hablado del efecto Barrapunto, pero eso es insignificante comparado con lo que me hicieron el 15 y 16 de abril de 2006: unos 60 ordenadores empezaron a entrar sin parar en mi página, todos a la vez, durante 15 horas.
Naturalmente, no dejaban ancho de banda disponible (aunque el ADSL era de 1024/300 Kbits), y la página dejó de funcionar. Pero el servidor no tenía problemas en aguantar la "carga", porque era poca; el problema era sólo el ancho de banda.
Para no aburrirme, documenté todo lo que hice durante y después de este ataque de denegación de servicio distribuido.
Tuve otros problemitas con mi servidor, ya que yo quería que fuera seguro pero también cómodo, y esto no siempre es compatible.
Un ejemplo: cuando hice mi cortafuegos, sólo permití la entrada por SSH desde mi ordenador grande, de IP 172.26.0.2. Para más seguridad, esa IP tenía una entrada fija en la caché de ARP, de forma que le correspondía siempre la misma dirección MAC. Traduciendo: que -en teoría- sólo podría manejar remotamente el servidor desde mi ordenador, porque sólo su tarjeta de red está permitida en el servidor.
Lo malo llegó cuando mi ordenador se estropeó... se le quemó la placa base, o algo así. ¿Qué iba a hacer? Sólo podía entrar desde el mío, y no lo tenía; tampoco tenía otro al que conectarle la tarjeta de red. Sólo un portátil (que no tiene conector PCI, claro).
Bueno, ningún problema... yo ya sé que en Linux cambiarse la dirección MAC es tan fácil como cambiarse la IP... así que los filtrados por MAC no son muy efectivos. Sólo tenía que ponerme la IP y MAC del ordenador permitido, pero... ¿cuál era? ¡No había apuntado la MAC! Y en la tarjeta de red no salía escrita. Así que no sabía qué MAC ponerme para poder entrar...
Pensé en hacer un programa que las probara todas, pero vi que serían muchas. Aunque consiguiera conocer la mitad de sus cifras (adivinando el proveedor), tardaría más de 4.000 horas probando 1 por segundo.
Tuve que esperarme a tener otro ordenador con PCI en donde poner la tarjeta de red. Claro que también podría haber sacado el servidor portátil de su armario y mirar la MAC permitida ahí, pero no tenía ganas. :-)
Contaré otro caso en el que la seguridad afectó a la comodidad.
Tal como he explicado antes, el kernel está dispuesto a matar
a cualquier proceso que consuma mucha memoria o CPU.
Bueno, pues un problema lo tuve cuando,
por algo que hice mal,
el sshd empezó a consumir mucha memoria.
Pues ¡el Linux lo mató! ¡Mató al sshd, que es el proceso que
permite el control remoto!
O sea, que no sólo cortó la conexión, sino que no pude
entrar más desde mi ordenador.
La única solución fue levantarme, abrir el armario,
y teclear /etc/init.d/sshd start desde ahí.
Otra situación más divertida fue cuando me bloqueé yo mismo
cambiando reglas del cortafuegos.
Estaba por SSH añadiendo reglas y excepciones al filtro de entrada
(INPUT),
hasta que la compliqué demasiado y decidí borrarla y empezar desde cero
a hacer las pruebas.
Hice el iptables -t INPUT -F (quitar todas las reglas de la tabla
de conexiones entrantes),
y entonces el SSH dejó de responder... :-(
¡Claro! Porque la política predeterminada (-P) de esa tabla
era rechazar todas las conexiones,
y por eso estaba bloqueando mi SSH.
Tuve que abrir el armario del servidor y volver a ejecutar
las reglas de mi cortafuegos.
Ahora repasaré el software que usé y explicaré qué tal me ha ido.
thttpd es el servidor web que usé, por los motivos que ya expliqué aquí.
Resumiendo: me fue muy bien, y no me ha defraudado, aunque podría ser aún mejor. Con el tiempo fui pidiéndole cada vez más cosas, y tuve que esforzarme un poco para conseguir las cosas difíciles.
Primero explico lo bueno de thttpd:
Pero también me dio 5 problemas, que no son muy graves, pero que preferiría que estuvieran solucionados. Son:
.html, así que hay que tener todos en Unicode o todos en ISO-8859-1. No vale usar una etiqueta <meta> ya que el Content-Type del HTTP tiene preferencia (lo siento por no explicarlo más a fondo). Cuando quise usar Unicode hice algunas chapuzas basadas en mi programa webch, o usé XHTML: asocié siempre ISO-8859-1 con HTML, y siempre UTF-8 con XHTML. Vaya lío...
Location: correspondiente. Me encontré con que thttpd añadía un código 302 Found automáticamente, pero yo quería un 301 Moved Permanently, y lo cambié en el código fuente de thttpd. La diferencia entre el 302 y el 301 está explicada en el RFC 2616, sección 10.
Son sólo pequeñas molestias... pero lo sufiente molestas como para hacerme buscar otro servidor en donde no ocurran. Hay otro servidor interesante que apareció y creció mientras mi servidor seguía funcionando: lighttpd, que también es más rápido que Apache (igual que el thttpd), pero que permite más cosas que thttpd: compresión gzip, PHP, redirecciones, estadísticas automáticas, ...
thttpd me gustó, pero creo que en el futuro usaré lighttpd, que también es muy sencillo.
También me ha ido muy bien el Linux; me ha permitido aprovechar muy bien un ordenador poco potente. Dos años y medio después de encenderlo seguía tan "fresco" como al principio.
Pero no elegí el Linux por esto, ni por ser rápido, estable, ligero o gratis. Lo elegí por un tema que no se ve a simple vista: la licencia que trae, que es la GPL y por tanto cuenta como "software libre". Básicamente, lo de que un programa sea "software libre" significa que viene con un texto que dice:
Pues por esto me gusta el Linux en servidores, al igual que otros sistemas operativos que también son "software libre", como FreeBSD, NetBSD y OpenBSD.
Técnicamente, el Linux no me dio problemas. Usé la versión 2.4.25-pre8, o sea, la 2.4.24 con varios parches. Esta versión salió el 29 de enero de 2004, y desde entonces se le han encontrado algunas vulnerabilidades, incluso alguna explotable (aunque no me afectaba). Como eso ya me lo imaginaba desde el principio, le añadí varias medidas de seguridad:
-T, para tener en cuenta que la entrada del usuario puede estar siempre "contaminada"
Todo esto sirve para hacer más interesante y difícil una intrusión. Desgraciadamente, nadie se esforzó en buscar fallos de seguridad, con lo que me aburrí mucho.
Una cosa que me molestó de la versión 2.4.25 de Linux es que en caso de acabarse la memoria RAM, el kernel decide él solo a qué proceso matar, y yo quiero participar también en esa decisión :-) Tenía que haber cambiado el algoritmo en el código fuente, o usar el parche que incluyeron en la versión 2.6.11, que ya lo permite.
Para un servidor volvería a usar Linux 2.4, porque me fue muy bien. La rama 2.6 está muy bien para ordenadores de escritorio, pero incluso en 2006 parece que aún no es muy estable...
Por cierto, no tuve ningún problema con la distribución Debian estable. Hubo muy pocas actualizaciones de programas (una cada muchos meses), y muy fáciles de instalar (debido al apt-get).
Instalé Pure-FTPd para hacer de servidor FTP, pero ¡casi nunca lo usé! El protocolo FTP se diseñó hace tiempo y creo que no funciona muy bien en el mundo actual, lleno de routers y cortafuegos. Me explico: FTP ofrece dos modos, activo y pasivo:
He hecho este gráfico para acabar de entenderlo:
Pues bien, hay veces en las que ¡no funciona ninguno de los dos! Por ejemplo, quiero conectarme desde mi universidad hasta mi casa. En la universidad no aceptan conexiones entrantes, así que el modo activo no funcionaría. Pero si soy yo quien intenta conectar a un puerto alto (1000 y pico) de mi casa, tampoco podré, o porque no me dejan en la universidad (sólo dejan salir por los puertos "normales") o porque en mi servidor está cerrado. Para que el modo pasivo funcione, tendría que permitir entrar por todos esos posibles puertos, que son decenas de miles.
Quizás hay otras soluciones, pero veo que con FTP hay que complicarse un poco. Para transferir ficheros, acabé usando ssh (con scp), que además va cifrado.
Así que el pure-ftpd está muy bien (ninguna queja), pero no lo usé.
Usé ssh para poder hacer las tareas de administración de sistemas desde mi ordenador grande, sin tener que ir físicamente a donde estaba el servidor. Ningún problema.
Pero para trabajar en mi página web, lo que hacía era montarla en mi ordenador grande mediante shfs, que usa SSH. Así aparecían todos los ficheros de mi web y podía tratarlos como si fueran locales... bueno, con un problemita: los tiempos de modificación de los ficheros. Los dos ordenadores (el grande y el servidor) no estaban puestos a la misma hora, y nunca me quedaba claro de a cuál de los dos ordenadores correspondía la fecha que veía en cada fichero. A veces parecía que el campo hora era incluso incorrecto...
Esto parece poco importante, pero hacía que make no funcionara bien
(ya que se basa en las marcas de tiempo).
No he tenido tiempo de investigar esto,
pero se me ocurren dos posibles soluciones para shfs:
Creo que éste es un problema difícil, pero algo hay que hacer para que funcione el Makefile.
Otro programa que usé fue awstats, para hacer las estadísticas. Muy bueno en general, pero me resultó bastante incómodo en varias cosas:
decodeutfkeys), que tuve que modificar bastante para que me funcionara con la versión de Perl que tenía (5.6). Aquí está el parche que hice.
El tener poca memoria RAM (32 Mb) no me dio problemas... Sólo uno, con un CGI mal programado, que ya he explicado antes y que fue por culpa mía.
Aquí hay una muestra del estado de la memoria en un
momento de bastante trabajo (martes 29 de octubre de 2006):
free -m,
ps axu.
El thttpd era siempre lo que más consumía;
algunas veces eran 5 Mb,
otras 9, otras menos de 5, ...
Depende de la situación.
El resto de programas gastan muy poco.
Intentaré explicar cómo se dividía la memoria en ese momento
(todo esto está escrito en el free -m de antes):
free) cuadra todo.
Ah, y no tenía partición de intercambio,
tal como expliqué aquí.
Tampoco había programas inutilizados que llevar a la pdi.,
porque casi todo lo que había en RAM era útil
(excepto los gettys, que me olvidé de quitar, pero ocupan poco).
En total: que con 8 Mb ya me habrían cabido los mismos programas, pero cuanta más RAM, mejor, ya que puede usarse como caché, y eso en un servidor web ayuda muchísimo.
Cada día a las 6:25 se actualizaban las estadísticas. He hecho una hoja de cálculo (en formato OpenDocument) con las estadísticas de los 30 meses de actividad. Se ve esto:
Lo de que crezcan las visitas ya era predecible, porque también han aumentado los contenidos y el ancho de banda disponible. Pero aún me queda mucho para que el número de visitas sature cualquier servidor.
Con las estadísticas aprendí (aparte de que son mentiras :-) que cuando más gente entra son los miércoles, y cuando menos los fines de semana (sáb. y dom.). Esto se ha cumplido siempre, y por eso si algún día tenía que usar mucho Internet, intentaba que fuera un no-miércoles.
Entre las estadísticas se encuentra una lista de frases usadas por los visitantes que han llegado mediante un buscador de Internet. Esto es posible porque cuando se hace clic en un enlace, el navegador envía la dirección URI del enlazante. A este dato se le llama en inglés referer, aunque está mal escrito, ya que se dice referrer.
Con el tiempo acumulé una lista de más de 180.000 frases distintas. Tengo mejores cosas que hacer que leerlas, pero aquí pondré unas pocas que vi y que me parecen curiosas o divertidas. Les he corregido las faltas de ortografía.
qué hago si el Internet Explorer no quiere funcionar
si abro Google me sale una página de juegos y no la puedo quitar
me molesta un programa de Internet
cómo hacer trampa en el Buscaminas
cómo hacer girar la configuración de mi PC
quiero navegar en Internet, ¿cómo lo hago?
quiero escribir; necesito un editor
a la CPU le falta temperatura para encenderse
me va lento Internet, ¿será porque tengo virus?
cómo hacer un tubo para que haga mucho ruido
páginas para chatear con personas que les gusta que se les mire
querido Google, quiero saber de los paquetes en los estándares de protocolos
por qué molestan los mosquitos en los oídos
cómo hacer dinero rápido en el extranjero
¿quién soy?
quiero piratear Internet
comida turca
portal de Belén en Javascripts
maquinaria de carnicería de segunda mano
wc hinchable
algo bueno
www.quierosexo.com
abecedario elfo
lo más interesante de Internet
qué más le puedo poner a mi web
cosas que hacer en tiempo libre
cómo hacer escaneos aleatorios de IPs y puertos
demostrar tonterías matemáticas
no voy a dejar entrar eso en mi casa
Lo raro es que acabaron en mi página...
Por cierto, otra cosa que me ha hecho gracia es encontrar mi página al buscar "Internet Explorer" desde MSN. Estuvo así durante mucho tiempo.
Había días en que, por aburrimiento o por tareas de comprobación, quería ver si estaba entrando alguien a mi página, cuántos, qué pedían y de dónde venían. Para eso podría entrar por SSH al servidor y mirar el fichero de registro, pero encontré una solución más fácil.
A mi router (3Com OCR 812) le puedo conectar 4 ordenadores por detrás, pero el sistema que usa es el de un concentrador, o sea, que es como un "ladrón" de ordenadores: lo que le llega, lo reenvía a todos los ordenadores. Si fuera un router mejor, en vez de eso tendría un conmutador, que como su nombre indica, en vez de hablar con todos los ordenadores a la vez va comunicándose individualmente con cada uno de ellos; así es más seguro, (pero también son más caros).
Esta imagen aclara las diferencias:
Bueno, pues como he dicho, mi router es de los que envían el tráfico a todos los ordenadores. Por eso, todas las peticiones que llegaban a mi servidor también llegaban a mi ordenador grande.
O sea, que monitorizando el tráfico en mi propio ordenador
podía ver cuánta gente estaba entrando en el servidor.
Un programa como tcpdump o wireshark permite hacer esto,
pero es más cómodo usar urlsnarf, que muestra sólo las direcciones
pedidas por HTTP,
y por eso da una salida que parece un fichero de registro.
Bueno, le falta por decir el tamaño de los ficheros transferidos.
En casos de aburrimiento, podía poner un programita como
urlsnarf -n | perl -lne '/google.*q=(.*?)&/ and ($_=$1)=~s/\+/ /g and print;'
y contemplar las búsquedas en Google usadas para entrar en mi página.
Sí, es espionaje... pero me va bien para saber qué quiere la gente
que llega a mi página.
Gracias a esto he descubierto que la mayoría van a salir desilusionados
:-) (Lo siento).
Encendí el ordenador cerca del 20 de febrero de 2004, y lo apagué el 5 de septiembre de 2006. Unos 930 días en total. Entre medio no lo apagué en ninguna vez; de eso estoy seguro... Pero los demás no opinan lo mismo :-)
Por ejemplo, el propio ordenador decía al final:
amarok:root # uptime 20:44:16 up 429 days, 4:18, 2 users, load average: 0.00, 0.00, 0.00
Ni siquiera la hora es la buena... pero es que lo de los 429 días tampoco. Sin embargo, en la tabla de procesos se veía que se habían abierto en 2004. Al principio pensaba que la pila del ordenador estaba gastada, pero de todas formas yo estaba actualizando la hora por NTP. Pero luego descubrí la causa de este misterio...:
Resulta que Linux usa un reloj interno para contar el tiempo, y su valor máximo en la versión 2.4 es de 497 días. Por tanto, no se puede ver un tiempo de actividad mayor, ya que al 498º día el tiempo vuelve a cero. En el kernel 2.6, el límite es de 49'7 días.
¿Y de dónde viene eso? Pues de que:
También se puede usar un contador de 64 bits. Así podríamos contar (a 100 Hz) hasta unos 5.849 millones de años, que ya parece suficiente. Hay un parche de 2001 que ya hace eso, pero me parece que no viene activado por defecto porque lo de contar mal el número de días de actividad no es muy importante.
Bueno, pues también explicaré algo de Netcraft, que tiene una página donde intenta calcular el tiempo de actividad de cada servidor. Miré el mío:
¡Ahí dicen que estoy reiniciando! Dicen que ha durado unos 490 y pico días... Bueno, ya acabo de explicar lo del máximo de 497 días, así que no hay ningún misterio; es por eso. Incluso en su lista de preguntas frecuentes lo dicen. Ponen que les pasa con HP-UX, NetApp NetCache, Linux 2.6, Solaris y FreeBSD, o sea, una parte importante de los servidores. Moraleja: Netcraft no es fiable para hacer las típicas comparativas sobre qué sistema operativo aguanta más.
Creo que la mejor pieza de mi servidor ha sido el disco duro, porque es la que más trabajo ha tenido que aguantar.
Yo me compré el portátil de segunda mano, y ya venía con este disco, usado. Yo mismo usé el portátil durante unos meses, y lo llevaba a todas partes (en esos tiempos aprendía cosas de wireless). Bueno, pues después de todo ese trote, lo puse como servidor (¡con el mismo disco duro!). Y dos años y medio después (unos 5.000 millones de vueltas, a 4.000 rpm) aún funcionaba bien.
Es un IBM-DDLA-21620 de 1'6 Gb
(más datos: hdparm).
Y según las estadísticas sacadas mediante SMART
(ver smartctl -a /dev/hda:
Estoy contento con este disco duro. Me ha durado unos tres años sin ningún error. Eso sí, a los pocos meses de usarlo empezó a hacer un poquito más de ruido, pero muy poco. Una vez desconectado, este disco me siguió siendo útil.
Pues más tranquilo :-)
Se apagó bien. Al arrancarlo otra vez, me dijo eso de "El sistema de archivos / lleva 939 días sin comprobarse; probándolo ahora". No encontró fallos en el disco duro. Tampoco hizo ningún ruido extraño ni se bloqueó.
Sorprendentemente, la batería aún duraba mucho: cuatro horas y veinte minutos... (con el disco duro en reposo). Me parece increíble. Yo imaginaba que estar dos años y medio conectado a la corriente (sin parar) era suficiente para destrozar la batería... Pero resulta que esta batería aguantó como si nada.
En total, que el portátil quedó completamente usable, y en muy buen estado. Supongo que al disco duro le queda poca vida, pero ya es más de la que esperaba. Espero seguir usando este portátil durante mucho tiempo, porque -sinceramente- es el mejor que he visto nunca, aunque sólo sea un Pentium 133 Mhz con 32 Mb de RAM. En mi opinión, los ordenadores actuales no son tan buenos... :-)
Desde que puse el artículo sobre el servidor, recibí muchos correos relacionados. Algunos eran sólo un "gracias por el tutorial" (¿qué tutorial? Si sólo eran notas para mí... No pretendía explicar nada...). Pero otros correos vienen cargados de dudas, y responderlas quita bastante tiempo. He llegado a recibir entre 1 y 3 consultas al día, que es mucho.
Como además las preguntas eran siempre acerca de lo mismo, decidí aplicar el siguiente método: en vez de escribir dos veces la misma respuesta, escribirla una vez y ponerla en Internet para que los demás encontraran más fácilmente la información. Mi ideal era entonces que toda la información sobre redes y servidores estuviera disponible en Internet.
Creo que el sitio ideal para resolver muchas dudas informáticas es la Wikipedia. Es una "enciclopedia libre que todo el mundo puede editar"; eso quiere decir que:
Pues empecé a ampliar la información sobre servidores, Linux, e informática en general, pero hay mucho trabajo por hacer, y yo solo no puedo. He pedido ayuda muchas veces para mejorar artículos que considero importantes (ejemplo), pero no he visto ninguna mejora en muchos meses. Muchos artículos siguen estando incompletos, con faltas de ortografía, o mal explicados. ¡Y yo no puedo corregirlo todo!
Bueno, paso a contar las dos dudas más preguntadas:
`www.___.com`Pues ya sabes: si quieres ayudar, elige un artículo en la Wikipedia y haz de él un artículo destacado. Desde esta página he enlazado muchos.
De vez en cuando también recibía alguna crítica, queja o amenaza (lo digo en serio). Pero básicamente, lo que me dijeron es que me había complicado mucho. Creo que es verdad: me compliqué mucho para aprender más, y eso me gusta. Vivir fácil y cómodamente (lo que quieren casi todos) es muy aburrido.
Es que instalar un servidor web es muy fácil. Ejemplo: la distribución Ubuntu es una de las más fáciles de usar para los que no saben de informática. Pues además tienen una versión para servidor, que una vez instalada (en 15 minutos) ya deja el ordenador funcionando con una solución LAMP: Linux, Apache, MySQL, PHP. Todo con software libre. ¿No es demasiado fácil...?
Cuando hice mi trabajo final del Bachillerato (en el instituto),
también tuve que complicarme a propósito,
porque instalar el servidor web Apache consiste en escribir
apt-get install apache,
y él solo se baja de Internet el programa, lo instala, lo configura, y lo deja funcionando.
Algo más tenía que hacer para llenar hojas...
Algunas personas sí que me ayudaron recomendándome programas o soluciones alternativas. En concreto, lo que me dijeron varias es que ahora sí que hay algún "aparatito pequeño que consume poco y que va con Linux", como el Linksys NSLU2.
El NSLU2 parece perfecto para hacer de servidor: gasta poco, lleva Linux, tiene tarjeta de red, USB, y no lleva disco duro. En realidad está pensado para compartir por red los discos que le conectes, pero hay muchos usuarios que le han añadido funciones, porque al ser Linux, tienen el código fuente disponible.
Lo malo que le veo es que no es un ordenador "normal", y no ha sido diseñado para que la gente trastee cómodamente; por eso creo que me daría algunos problemas. He tenido muy malas experiencias con los "aparatos" en general: no se dejan controlar, y se me estropean y no puedo hacer nada para arreglarlos. Por ejemplo, ya tengo un PDA estropeado para el que necesité un destornillador especial, un cable especial, programas especiales, y aún así no pude arreglarlo (y el fabricante no me ayudaba).
Yo uso el software libre porque me gustan las condiciones de uso que ofrecen las licencias como la GPL; son muy cómodas, y me permiten hacer lo que quiera, sin limitaciones. Bien, pues cuando uso aparatitos, me siento como si usara software privativo (no libre). Yo quiero tener más libertad en cuanto al hardware, y para eso ya me va bien un ordenador antiguo (sin DRM).
Desde que tengo mi página web en Internet recibo mucho más
spam.
Eso era previsible y ya puse mis correos con mecanismos antispam,
por ejemplo: n142857 /-/arrob@/-/ g m a i l punto com.
A veces me complicaba tanto que costaba descifrarlo...
Pero el spam venía por otros sitios también:
El spam sigue siendo un problema muy molesto en Internet. El primer método que usé para evitarlo fue cambiar de dirección de correo cuando una se volvía inusable, pero resulta que hay muchos otros tipos de spam, no sólo en correo electrónico.
Otra molestia a tener en cuenta en tu servidor web es el enlace directo a ficheros internos. Por ejemplo: alguien decide que una imagen de tu página está bien, y la usa en la suya; pero no copiándola a su servidor, como es habitual, sino mediante un enlace (a la tuya). Entonces, cada vez que alguien entra a su página, te llegan peticiones a ti, y tú le estás haciendo de servicio de alojamiento. No he tenido problemas graves con esto, pero si los hubiera, se puede activar una opción en el servidor web para que lo evite.
Sí, definitivamente. He aprendido mucho por haber puesto un servidor en mi casa. No sólo me ha servidor de infraestructura para alojar mi web, sino que me ha abierto nuevos problemas e intereses.
Como consecuencia de haber puesto el servidor web, escribí muchas otras cosas:
Además me sirvió para aprender de todos estos temas, y me enseñó mucho para la próxima vez. En total, que ha sido una buena experiencia.
Aquí pongo las lecciones aprendidas para la próxima vez:
sshd, que lo uso de vez en cuando.
danielclemente.com o www.danielclemente.com. Tenía los dos funcionando, y no supe hacer que uno redirigiera al otro (con thttpd es difícil hacerlo sin tocar el código).
init al modo monousuario, y se quedaron por ahí abiertos los procesos getty para cada terminal (ver ps). Ocupaban poco (60 Kb cada uno).
`cat cont`+1) no está a prueba de hebras... ("threads"). Podría perderse una actualización en algún caso.
cron un solo proceso (y no dos) que primero hiciera las estadísticas y luego rotara. Por cierto, en este caso el nivel de carga subía bastante, a 2 y un poco más; bueno, este número era deducible, pues había dos procesos corriendo en la cola (el gzip y el awstats) junto con el thttpd trabajando poquito.
Ah, me falta decir que quité el servidor de mi casa porque me iba de Erasmus a Alemania durante 6 meses. La página la moví a un servidor de pago que me prestó un amigo; resultó más rápido, pero no tan protegido como el mío.
Todo este documento está con licencia GFDL, que es algo complicada de entender, pero vale la pena, porque te permite hacer trabajos derivados sin tener que pedirme permiso (ver condiciones en la licencia). Las imágenes tienen licencias muy variadas, que he recogido en este fichero; la mayoría son dominio público o GFDL.
Autor: Daniel Clemente Laboreo. Correo: n142857 /@arroba@/ gmail.com.
Escribí esto en septiembre de 2006, y lo actualicé por última vez el 18-09-2006.
El artículo está accesible mediante
http://www.danielclemente.com/amarok/resulta.html
(y el original mediante
http://www.danielclemente.com/amarok/ ).
FIN.