Category Archives: redes

Pretty URLs

Muchas veces hemos visto las URL de algunos sitios que tienen, tras una interrogación de cierre (?) una hilera de valores con iguales (=) separados por ampersand (&). No obstante, hay otros muchos sitios que sus URLs, más específicamente sus URIs, son palabras en minúscula, con algunos guiones y números escasos, separados por barras inclinadas (/). Este último método es conocido con pretty urls.

Tener este tipo de URLs, o URIs en nuestro dominio, se puede hacer mediante la creación de directorios y especificando los ficheros dentro de los mismos que tengan los nombres (sin extensión) que queremos que se visualicen en la barra del navegador… pero no es nada útil y es complejo, sobre todo cuando se usan entornos como WordPress o similares, donde el contenido de la base de datos dicta lo que aparece en la página, y es totalmente dinámico.

La solución que se puede emplear: rewrite. En Apache, a través del módulo mod_rewrite, se pueden crear reglas de redireccionado de modo que una URL que es:

http://midominio.com/?p=129&a=crea-usuario

Se puede convertir en:

http://midominio.com/crea-usuario/129

En el caso concreto, tan solo bastaría con agregar un bloque de configuración como el siguiente:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/(.+)/([0-9]+)$    /index.php?p=$2&a=$1

Para más información vea la documentación oficial de Apache.

La Regla de los Nueves

Esto es algo que aprendí, ahora hace ya unos 5 años, cuando comencé a instalar mi primer servicio de alta disponibilidad.

En un artículo sobre el tema, la alta disponibilidad, se decía que la disponibilidad de un servicio, servido únicamente por una máquina, normalmente es de un 90%, con lo que, a lo largo de un año (365 días) el servicio se ha mantenido en funcionamiento un máximo del 90%, aproximadamente, y ha tenido un tiempo de inactividad del 10% (más o menos unos 36 días).

Con sistemas de alta disponibilidad, es decir, teniendo más de una máquina siriviendo un servicio, la proporción se incrementa, pero siempre a razón de nueves. Es decir, con dos máquinas, tenemos una disponibilidad del 99%, con tres máquinas tenemos un 99,9%, con cuatro un 99,99% y así sucesivamente.

Como nota curiosa, hace poco leí que los sistemas desarrollados sobre Erlang/OTP tienen una alta disponibilidad de nueve nueves (99,9999999%), lo cual me parece algo increíble, pero totalmente cierto, ya que he probado la infraestructura y realmente es muy estable.

Escalado de Ruby on Rails

Después de liberar el primer proyecto escrito en Ruby on Rails, cuando lo pasamos a producción, nos dimos cuenta de que el sistema funcionaba realmente lento. En algunos casos, incluso, no respondía, con lo que buscamos información por internet y vimos:

Mongrel y Thin no son multi-hilo

Fue algo que nos sorprendió mucho, una aplicación servidora secuencial, que atiende las peticiones una a una y, en caso de que una petición se tarde un par de segundos (que las teníamos :-S ), el sistema se queda trabado durante todo ese tiempo.

Las soluciones posibles eran dos:

  • Phusion Passenger, también conocido como mod_rails, es un módulo para Apache que mantiene tantos hilos como peticiones se vayan gestionando, siempre con unos límites máximos y mínimos, tal y como apache suele hacerlo.
  • Ngnix + Thin, esta solución fue un poco más artesana, por decirlo de alguna forma, ya que consistía en configurar este servidor web como proxy inverso, para hacer el balanceo de peticiones entre todos los hilos de thin que se quieran cargar en el sistema. Descartamos en este punto a mongrel por comentarios que había leído en otros blogs.

Bien, por correr lo más posible, lanzamos tantos hilos como nos fue posible en la máquina que dedicamos al proyecto y, nos complació ver que podía aguantar hasta 40 hilos, sin que sus CPUs lo notasen apenas. Con lo que conseguimos un pool de 40 puertos dedicados a atender peticiones HTTP.

En otra máquina se configuró un proxy inverso. En el escenario de pruebas usamos nginx, aunque el tenerlo en la misma máquina y hacer pruebas masivas, nos dio como resultado que una cantidad importante de peticiones se perdían o transformaban en respuestas de tipo 500 por parte de nginx. Optamos entonces por un balanceador que tiene la compañía vía hardware, muy rápido y, a día de hoy el sistema web tira tan rápido y casi mejor que el que tenemos montado en PHP :-)

En el próximo artículo comentaré las configuraciones, arquitecturas y demás seguidas, sobre todo a nivel de nginx y thin, que es lo que realmente interesa.

¿Cómo funciona el sistema de correo?

Esta es una pregunta que no todo el mundo se formula y, realmente, no es tan simple contestar. Quizás de todos los servicios de Internet, el sistema de correo es uno de los más complicados que existe (si no tenemos en consideración la VoIP, claro :-P ).

Conceptos

En principio, vamos a definir algunos términos que usaremos de forma natural en el resto del artículo, para adentrar lo que son los términos de funcionamiento del email:

  • MUA: (Mail User Agent, Agente de Usuario de Correo), es el sistema que se encarga de recibir y enviar emails usando los protocolos STMP (para el envío) y POP3 o IMAP (para la recepción). Ejemplos de MUA son evolution, kmail, sylpheed o incluso squirrelmail (los webmails).
  • MTA: (Mail Transfer Agent, Agente de Transferencia de Correo), es el sistema que se encarga de tomar el email de un MUA o de otro MTA y entregarlo a otro MTA o a un MDA, en caso de que el email pertenezca al dominio propio del MTA. Ejemplos de MTA son postfix, qmail, exim, cyrus y courier.
  • MDA: (Mail Delivery Agent, Agente de Entrega de Correo), es el sistema que se encarga de la recpeción del email por parte de un MTA, y lo almacena de la forma que tenga configurada. Los MDA pueden almacenar en disco, base de datos o llamar a otro programa para hacer el procesado de emails (p.ej: listas de correo, sistemas de control de incidencias, etc.). Ejemplos de MDA son procmail, maildrop… cyrus y courier implementan también sus propios MDA.
  • MAA: (Mail Access Agent, Agente de Acceso de Correo), es el sistema que se encarga del acceso al correo almacenado. Sería como la oficina de correos, y por ello su protocolo más usado es POP3 (Post-Office Protocol version 3). Se encarga de hacer accesible lo buzones a equipos remotos. Ejemplos de MAA son dovecot, uw, qpopper… cyrus y courier implementan también sus propios MAA.

Funcionamiento

Un ejemplo básico, desde el punto de vista de un usuario sería:

  • Un usuario abre su MUA (evolution, por ejemplo), escribe un email desde su buzón yo@miemail.com a un amigo, que tiene la dirección de correo el@suemail.com.
  • Su programa MUA se conecta con el MTA que está en el dominio miemail.com, este MTA comprueba que el remitente es suyo, pero que el destinatario es de otro dominio, por lo que realiza un relay del email al MTA del dominio suemail.com.
  • El MTA del dominio suemail.com ve que el destinatario es propio, por lo que, libera el email a su MDA.
  • El MDA comprueba el usuario a través de los alias y las reglas configuradas en el equipo y libera el email en el soporte, buzón y carpeta que tiene configurados.
  • El usuario el se conecta a un webmail, que hace de MUA para leer sus emails.
  • Los MUA, para leer emails, ya sean aplicaciones en el equipo o webmails, se conectan a MAA para leer los emails vía POP3 o IMAP, y estos MAA acceden a los datos que han liberado los MDA, por lo que el puede leer el email de yo.

Como dato a tener en cuenta, podemos ver las cabeceras del mensaje completas y aparecerán unas cabeceras redundantes que tienen por nombre Received. Estas cabeceras se agregan a cada paso por un MUA, MTA y MDA.

Spam

Por la forma de funcionamiento del protocolo SMTP (MTA), los antiguos programas que solo comprobaban el remitente y el destinatario, se veían en el problema de que esos datos se pueden falsear sin problemas, con lo que la veracidad de los mismos queda entredicho.

Para solventar estos problemas, se han desarrollado varios sistemas, antispam y de seguridad de conexión, que aseguran, en la medida de lo posible, que estos problemas no sucedan, pero aún así, hay una guerra entre desarrolladores de sistemas de correo para realizar sistemas cada vez más seguros, y spammers para el desarrollo de sistemas que salten esta seguridad.

Por ello, el uso de filtros es cada vez más común en los MTA, MDA e incluso los MUA.

Servidor de hora en GNU/Linux

En las redes internas de la mayoría de empresas, se sucede la necesidad, muchas veces, de tener sincronización horaria en las máquinas para mejorar el rendimiento y la calidad de los datos a almacenar, de cara  a anotaciones y lanzamiento de tareas programadas.

La sincronización horaria es completamente posible de llevar, simplemente, instalando un servidor de hora NTP dentro de nuestra red, para que nos haga de servidor de sincronización.

En España, generalmente, se suele usar hora.rediris.es como servidor de hora, puesto que es un sistema formado por varios servidores, algunos de ellos con el uso de relojes GPS.

Muchos sistemas ya tienen el servidor ntpd instalado. En otros habrá que hacer la instalación, ya sea del paquete con nombre: ntp, ntp-server, ntpd…

El archivo de configuración, normalmente: /etc/ntp.conf; debería de tener un contenido parecido a este:

driftfile /var/lib/ntp/ntp.drift
statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
server hora.rediris.es
 
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
 
restrict 127.0.0.1
restrict ::1
 
restrict 192.168.123.0  mask  255.255.255.0 notrust
 
broadcast 192.168.123.255
disable auth
broadcastclient

Con esto, el servidor de hora recién instalado, servirá como repetidor para los equipos de la red interna. En caso de tener un solo equipo, en ese caso es mejor tomar el archivo de /etc/ntp.conf y modificarlo levemente para hacer que el sistema fucnione, y nada más.

Espero que os sirva de ayuda.

¿Se nos hunde Internet?

Después de varias noticias algo catastrofistas, ha llegado la última que, en sí, podría afectar a todos los usuarios de Internet, puesto que se basa en el propio protocolo TCP/IP. Hasta el momento, la compañía sueca Outpost24, solo ha dejado caer la noticia y la promesa de extenderla en una conferencia.

En lo que llevamos de año, se han sucedido grandes vulnerabilidades de seguridad. La primera ha afectado la protocolo DNS, la segunda al protocolo BGP y ha habido otra vulnerabilidad sobre SSL que ha afectado solo a las distribuciones Debian y derivadas del mismo.

Esta última vulnerabilidad afecta al TCP/IP, aunque matizan los expertos que, de momento, solo es supuesta y que no solo afecta a IP, sino al conjunto TCP/IP. De momento, hasta que sea publicada la vulnerabilidad de forma específica por la compañía sueca, estamos ante, incluso, un posible FUD.

De todas formas, Internet, la concepción de sus protocolos más usados (como DNS y SMTP), no estaban pensandos para ser seguros, sino prácticos, puesto que Internet era una red a la que pocos tenían acceso. Hoy en día, el enfoque ha cambiado, pero los protocolos siguen siendo los mismos y, quizás, el problema haya sido la forma de parcheo que se ha realizado sobre los protocolos existentes, en lugar de optar por desarrollar mejores protocolos orientados a las necesidades actuales.

¿Estamos ante una necesidad de cambio en los protocolos de Internet?, ¿se nos hunde Internet?, no lo creo… pero llegan momentos difíciles y quizás vientos de cambio ;-)

Cloud Software

Con este título, comienza a surgir una tendencia a usar más servicios en web. Esto viene acompañado de la liberación hace unos días de Google Chrome, el cual, aseguraban muchos expertos que no hace la competencia a Internet Explorer, Safari o Firefox, sino que se la hace a Windows.

Esto viene determinado porque el navegador se ha convertido en todo un sistema operativo en el que se ejecutan aplciaciones que se cargan de forma remota. Lo que ya habían visualizado hace años Sun con el uso de sus paquetes en forma de nombre de dominio y otros… pero de una forma mucho más transparente.

En el navegador web, solo hay que poner una dirección web (URL) y con ello se puede acceder a un software con el que se interactúa para: leer el correo (Gmail, Yahoo!, Hotmail…), tener la agenda de contactos (en los mismos webmails), escribir diarios (blogs como Blogger), organizar las fotos e imágenes (fotoblogs o galerías tipo Flickr)… e incluso tener acceso a bancos, tiendas, el Estado…

Microsoft ultima su Office Online, junto con aplicaciones de tipo Office que ya tenía en uso Google mediante Google Docs, y con ello, con todo en Internet, ¿qué más da ejecutar un Windows, GNU/Linux, MacOS X…?

Redes en Linux

Este artículo ha pasado a formar parte de bosqueviejo.org, puede verlo en sus formatos html y pdf.