La programación de tareas en Unix (y sistemas similares como BSD, Solaris, HP-UX, AIX, Linux, MacOS X, etc.) se basa en un pequeño programa que permanece como demonio en nuestro sistema y mantiene una tabla de ejecución de comandos basados en tiempo y con una granularidad de un minuto. Es decir, no se puede programar una tarea con una exactitud mayor de un minuto (por ejemplo, no se podría decir que algo se ejecute cada 20 ó 30 segundos).

La tabla de tareas programadas (crontab)

En cualquier sistema, si escribimos como cualquier usuario la orden: crontab -e; entraremos inmediatamente en un editor en el que nos debería de mostrar información de la tabla de tareas programadas, o un fichero con un comentario indicando el formato… o en el peor de los casos, un fichero vacío.

Rellenar este fichero es tener en cuenta que los datos debe de estar separados por uno o más espacios, significando cada campo:

• minutos: el minuto en el que se va a ejecutar el cron.
• hora: la hora en la que se va a ejecutar el cron.
• día del mes: día del mes en el que se va a ejecutar el cron.
• mes: mes en el que se va a ejecutar el cron.
• día de la semana: día de la semana en que se ejecutará el cron. Este será en formato numérico de 0-7, siendo domingo tanto el cero como el siete.
• comando: el comando a ejecutar.

Si se configura lo siguiente:

0    5    *    *    *    /home/yo/mi_comando
*/5  *    *    *    *    /home/yo/mi_otro_comando
0,30 *    *    *    *    /home/yo/otro_comando_mas
0    0    *    *    7    /home/yo/dominguete

La primera línea le dice al sistema que se ejecute cuando sean las 5:00h de cada día, y ejecutará mi_comando. La segunda línea hace que mi_otro_comando se ejecute cada 5 minutos. La tercera línea indica que otro_comando_mas debe de ejecutarse en el minuto 00 y 30 de cada hora. Por último, la línea cuatro, hace que la ejecución de dominguete se haga solo el domingo y a las 0:00h.

Cron para administradores

Si estás programando una tarea para que se ejecute de forma recurrente en el sistema, que además requiere de unos permisos especiales o específicos para que se ejecute, es decir, necesita ser un usuario específico o root, entonces debe de programarse dicha tarea en la tabla de crontab del sistema, donde, además de especificar el tiempo, se puede especificar el usuario que la llevará a cabo.

Esto se configura en el fichero /etc/crontab (o en los ficheros fraccionados que puedes encontrar en la mayoría de sistemas en /etc/crontab.d). El usuario aparece como campo antes del comando. Solo hay que indicar el nombre del usuario y listo.

Cron para usuarios

Si tienes un usuario en el sistema y quieres hacer algo como que se ejecute fetchmail cada 15 minutos y rescate el correo de tus cuentas de correo en tu propia cuenta del servidor, tan solo tienes que ejecutar el comando de edición de crontab -e, y poner en el fichero algo como esto:

*/15  *    *    *    *     fetchmail

Con esto, tendremos asegurada la ejecución cada 15 minutos del comando (justamente en los minutos 0, 15, 30 y 45 de cada hora).

Cosas a tener en cuenta

Algunas preguntas que nos pueden asaltar son:

• ¿Cómo puedo ver los cron que tengo configurados sin editarlos? estos y otros comandos puedes revisarlos a través de man crontab, pero a modo de reseña rápida, sería: crontab -l
• Si pongo */7 en la primera hora se ejecuta el cron en los minutos 0, 7, 14, 21, 28, 35, 42, 49, 56, ¿y en la siguiente hora? Pues en los mismos minutos. El sistema de cron no asegura que algo se ejecute con una distancia exacta de tiempo, de hecho, la sintaxis lo revela, si el minuto es divisible por 7, se ejecuta, sino no.

Si tienes más preguntas del estilo, agrégalas como comentario y las incluiré en este apartado.

Bonus Track: el comando at

Antes de dar por finalizado el artículo… vamos a pensar, ¿qué pasa si quiero programar una tarea para que se ejecute hoy a las 1:30h… pero solo hoy? … o incluso, ¿si quiero que se ejecute dentro de 2 horas? Pues para eso empleamos el comando at.

Por ejemplo, si queremos que se ejecute a las 18:30h del mismo día por la tarde, basta con decir:

$ at 18:30
at> fetchmail
at> 
job 1 at Fri Nov 25 18:30:00 2011

Ten presente que se debe de presionar Ctrl+D para finalizar (<EOT>). Podemos ver el comando en la cola con el comando atq, o incluso eliminarlo con el comando atrm.

Para programar un comando dentro de 2 horas, sería:

$ at now + 2 hours
at> fetchmail
at> 
job 1 at Fri Nov 25 9:05:00 2011

Con lo que el comando se ejecutaría en dos horas, a contar desde que se lanzó el comando.

También se permite programar la tarea lanzando la ejecución de un fichero de comandos (shell script), así como una gran flexibilidad de configuración horaria. Todo está aquí: man at.

Conclusiones

La programación de tareas es algo trivial en un equipo informático, para los usuarios de GNU/Linux, sobretodo, cuando quieres que el equipo se apague a una determinada hora, convierta un fichero por la noche cuando ya no usas el equipo y pueda ser saturado sin problemas, o quieras programar limpieza de ficheros de forma periódica, descarga de noticias, etc, etc. es más fácil hacerlo con estos programadores que tener que hacerlo a mano.

Estimados, he decidido liberar la obra para que los interesados puedan disfrutarla de modo libre y distribuirla.

http://www.hackingetico.com

Espero que la disfruten, saludos.

Por lo que, tenemos ya a disposición de todo el mundo este increíble libro sobre seguridad y redes, de la mano de un autor que trabaja día a día en empresas de seguridad y sobre problemas de seguridad reales.

Lo que se trata en el libro, visto por capítulos es Cultura Hacker, Técnicas de búsqueda de información, Ingeniería social, Fuerza Bruta, Aplicaciones Web (XSS, Exploits, …), Inyección de SQL, Servidores Linux y Servidores Windows.

En esencia, son unas muy buenas lecciones sobre administración de sistemas, de cara a la seguridad y mantenerse alerta de por donde pueden venir los ataques más comunes. También tiene capítulos muy aconsejables para programadores, a nivel de codificación para evitar la creación de códigos maliciosos como exploits, o inyecciones de scripting o código SQL.

Debería de ser el libro de cabecera de todo administrador de redes y técnico en seguridad de todas las empresas TIC.

Estos elementos de conexión usan unos puertos específicos para la conexión, pero el primero no es nada seguro (todo se transmite en plano, tal y como se ve en pantalla, a través de la red) y el segundo requiere de la apertura de un puerto, que en muchas redes está filtrado o es inaccesible.

Para esto, Markus Gutschke, ha creado un sistema que se aprovecha de las nuevas ventajas de la web (HTTP, HTML y Javascript puro y duro) para realizar una conexión vía HTTP con el servidor y poder abrir una sesión de consola. El proyecto se llama Shell In A Box.

La principal ventaja es que se puede lanzar tal cual, en un puerto como el 8080, y ya está. Funcionando. Pero lo mejor es usar Apache para configurarlo de modo que se quede detrás, y a través de una conexión SSL, para que no sea interceptable lo que se va escribiendo, ya que sino, sería tan inseguro como usar telnet directamente.

El propio código tiene un fichero INSTALL en el que se detalla la instalación y configuración, ya sea cual sea la forma en la que se desee.

Una curiosidad, es que, además de disponer del modo LOGIN, que es el que tiene más utilidad, ya que se puede disponer de una consola al equipo servidor a través de conexión HTTP, pero también se puede obtener un SSH a otra máquina (o la propia) y la ejecución de un comando específico:

shellinabox --service=/:USER:/:top

Esto, por ejemplo, abriría una interfaz para visualizar el top de la máquina.

Es una muy buena herramienta que puede facilitar mucho la gestión de servicios (sobre todo de cara al acceso).

El caso es que la empresa y la comunidad que soportan ambas distribuciones (incluso distros comos OpenSuSE o SuSE, Mandriva y otras similares) les pasa que desarrollan versiones de forma bastante rápida (una o dos al año), con lo que, pasando 5 años, pueden haber salido unas 10 versiones posteriores del producto.

Esto genera problemas, sobre todo para la comunidad y la empresa que las mantiene, que deben de ir cerrando soporte de las antiguas, porque sino sería un caos el mantenimiento de 10 distros con versiones distintas de los códigos que se incluyen. A día de hoy, RedHat no suele mantener nada más que dos versiones, al última y su anterior, y Fedora Core, como mucho, da soporte a las 3 ó 4 últimas, con lo que, yendo actualmente por la versión 12, es lógico que el soporte a la versión 2 y 3 ha expirado hace bastante tiempo.

¿Qué pasa si hemos instalado un servidor web con estas distribuciones y queremos mantenerlo para nuestro correo, página web y otros menesteres?, pues que sino actualizamos, llegará el momento en el que haya vulnerabilidades en el código de nuestro servidor de correo, nuestro servidor web, o que queramos simplemente actualizar la versión del CMS que estamos usando y necesite una versión superior de Python, PHP o Ruby, o no tengamos forma de instalarla, a menos que vayamos tirando de compilación.

En Debian también pasa algo parecido. El ritmo de liberación de las distribuciones es más lento, con lo que da un tiempo mayor de permanencia de una distribución a su siguiente liberación. Pero el cambio es mucho mayor en este sentido, puesto que las versiones, cuando se cambian, son saltos bastante grandes y requiere de un mayor esfuerzo de adaptación.

¿Qué hacer?, básicamente, ir actualizando y mantenerse al tanto de cuando sale la siguiente liberación de la distribución que estamos usando y, sobretodo, planificar tiempos cada 5 ó 6 meses, para actualizar las distribuciones a sus versiones superiores, ya que así estaremos más protegidos de posibles vulnerabilidades.

Tener presente que si el cambio no se realiza, puntualmente, antes de que el soporte oficial a la distro que tenemos instalada expire, nos veremos en la situación de tener un sistema con agujeros de seguridad, que es propenso a fallos y sobre el que, cada día que pase, será más complicado instalar software nuevo.

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.

El problema viene al querer aplicar escalabilidad al proyecto. Cuando no solo hay un equipo implicado, sino que existen dos o tres, los cuales hay que configurar bajo ciertas circunstancias.

Lo primero que pensé, es que, si le puedo notificar a la red de que sucede un evento en concreto, ya sea a una sola máquina o conjunto definido de estas (pero para todos los equipos la misma configuración), facilitaría la puesta en producción. Con lo que me puse a buscar y encontré MQ, message queue.

El encolado de mensajes

La comunicación de los equipos informáticos se basa en mensajes, en eventos, que deben de poder transmitirse de unos a otros cuando sucedan (si es que se quiere tener la máxima fiabilidad en la información que se trata).

Una forma es comunicar directamente al implicado, lo cual resulta un poco tedioso si los implicados son muchos y muy distintos.

Otra forma es mediante un sistema JMS o un MQ, como RabbitMQ.

El encolado de mensajes es un sistema que permite que un elemento perteneciente a un sistema de información, pueda comunicar un estado, evento o mensaje informativo o imperativo a otro conjunto de elementos dentro del sistema, para que interactúe con él.

Por ejemplo, si tenemos un servidor web, una interfaz, que controla un conjunto de máquinas encargadas realizar llamadas salientes, rastrear páginas de la web para almacenar información para un buscador o similar, y la interfaz quiere enviar parámetros nuevos de configuración a estas, puede hacerlo mediante el envío de un mensaje generalizado a ese conjunto de máquinas, y estas máquinas recibirán el mensaje en el momento que lo soliciten.

Esta utilidad es igualmente buena para cuando una interfaz web, por ejemplo de un estudio fotográfico, carga imágenes desde la web, las retoca con algún tipo de efecto, ajuste, etc. y más adelante permite su descarga. El sistema web puede enviar el evento al sistema de retocado de que hay una imagen disponible, y cuando la imagen ya está disponible, el sistema de retocado puede enviar otro mensaje de vuelta diciendo que ya está.

Quizás esto último podría hacerse mejor con una base de datos, pero con el sistema de mensajería, se eliminan los datos en el momento que ya no se necesitan, mientras que con la base de datos, esos datos podrían permanecer ahí de forma indeterminada.

Conclusiones

Los sistemas de encolado de mensajes tienen su utilidad, sobre todo, en sistemas formados por varias máquinas, con roles bien definidos y en las que se quiere afinar lo que son las conexiones y comunicaciones entre las máquinas.

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.

El problema que intenta solucionar este sistema es el siguiente. Imagina que tenemos un sistema que hace múltiples escrituras y lecturas de una base de datos. No es difícil, seguro que conoces cientos de sistemas que lo hacen. Ahora, ten en cuenta que, los accesos a base de datos, depende para qué, realizan ciertos bloqueos, para asegurarse de que la información a modificar o a leer (incluso) no es modificada por nadie, hasta que termine su actividad.

En MySQL, por ejemplo, existen distintos tipos de bloqueos, muchos de ellos automáticos, que hacen el bloqueo de una tabla completa, o de ciertas partes específicas, al hacer una actividad de modificación, o un bloqueo compartido, para hacer actividades de lectura (solo bloquea en este caso a los que intentan escribir).

Pero en tema de índices, hay muchos SGBD que usan sistemas de índices que al actualizarse, se bloquean completamente, dejando, no solo las escrituras bloqueadas, sino también las lecturas, creando un lag de acceso a los datos.

Interbase fue la primera base de datos que eliminó la contención, los deadlocks y garantizaba transacciones ACID mediante el sistema MVCC. La idea es: no actualizar ni eliminar nunca una fila del disco. Si deseas actualizar, se agrega una nueva fila con la misma clave primaria, la cual oculta la antigua fila. Si deseas eliminar, agrega una nueva fila que etiqueta la clave primaria como eliminada, la cual oculta la antigua fila.

Las viejas filas no eran nunca actualizadas, así que no era necesario implementar ningún sistema de bloqueo y la contención (o espera) mágicamente desapareció.

El sistema, no obstante, tiene pequeños defectos: usa más espacio de disco y puede ser algo más lento a la hora de leer datos. La buena noticia es que los datos se pueden respaldar (realizarse un backup) en cualquier momento sin bloquear el sistema.

En MySQL, los tipos de tablas Falcon (a partir de la versión 6.0) e InnoDB (antes de la 6.0), implementan este sistema para las actualizaciones (updates) usando bloqueo a nivel de fila, lo cual puede causar un tiempo de espera para otros procesos (contención).

En PostgreSQL se usa el comando VACUUM para actualizar las base de datos, es decir, implementar las transacciones agregadas al final en lugar de a las que reemplazan y eliminar las tuplas marcadas para reclamar más espacio en disco. Esta operación demora, pero hace que la base de datos pase de un consumo alto de disco duro, al ajustado que debe de ser, antes de la próxima sesión crítica

Hay otras bases de datos que también implementan Multiversion concurrency control, tal y como menciona la wikipedia, tales como:

• Berkeley DB: que es una base de datos a nivel de fichero, como puede ser SQLite, pero sin uso del lenguaje SQL.
• CouchDB: de la cual ya comenté algunas cosas en otro artículo.
• Oracle 7: y superiores.
• Microsoft SQL Server 2005: y superiores. El soporte es opcional, se pueden configurar los niveles de aislamiento (isolation) para poder usar MVCC o no.
• MySQL: a través de InnoDB o Falcon, pero se usa nivel de bloqueo por fila, en lugar de snapshot.

Más información:

• PostgreSQL 8.3: Concurrency Control
• MVCC and snapshot-capable database – Do It Yourself
• PostgreSQL: ¿la base de datos empezó a consumir exageradamente espacio de disco? (actualizado)
• On Transaction Isolation Levels
• PostgreSQL MVCC and VACUUM

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

Aquí os dejo el enlace: PostgreSQL: Instalación, Configuración y Trucos.