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.

Dennis Ritchie ha sido una persona muy influyente dentro del mundo de la informática, ya que trabajó en el cenit de la misma, en una de las empresas que comenzó a cambiarlo todo, gracias a su potencial humano (Ritchie, Kernighan y Thompson en un principio y otros como Stroustrup después), con desarrollos como el lenguaje C y el sistema operativo Unix.

Recordando una entrada de Genbeta del verano, podemos decir que, Si no fuera por Dennis Ritchie y por Ken Thompson, UNIX jamás hubiera existido, tampoco hubiera existido por tanto BSD, o Solaris o Minix y mucho menos Linux, tampoco existiría Mac OS X. Y si no fuera especialmente por Dennis Ritchie, no existiría C, no existirían muchos conceptos que en su día rompieron esquemas a través de su innovadora visión y se convirtieron en al ABC de la teoría de los sistemas operativos por lo que sería complicado que hubieran existido hoy sistemas como Windows, PlayStation, o PCs. Por lo que le debemos mucho a este hombre. ¡Adiós, maestro!

Por ello, voy a explicar lo que son los procesos de este tipo de sistemas operativos (sobre todo orientándome en GNU/Linux).

¿Qué es un proceso?

Un proceso es un programa software que se carga en memoria y comienza a ejecutarse de forma secuencial. Un proceso puede, a su vez, según el sistema operativo, contener elementos paralelos de ejecución, como pueden ser hilos (threads). La ejecución de los procesos se puede ver con el comando:

ps xa

En GNU/Linux, cada proceso puede a su vez, lanzar otros procesos hijos. Estos dependerán del padre, de modo que cuando el proceso padre muera, los procesos hijos recibirán la señal de que deben de finalizar su ejecución.

La dependencia de procesos puede verse con el comando:

pstree

Procesos y recepción de Señales

Cada proceso que se ejecuta en el sistema operativo está preparado para recibir una serie de señales y actuar en consecuencia. El comando kill es el empleado de forma cotidiana para enviar de forma manual estas señales.

Las señales que se pueden enviar, en resumen, son:

Si queremos enviar a un proceso una señal específica, por ejemplo, que debe de terminar de inmediato, solo habrá que escribir:

kill -9 12123

Esto le dice al sistema operativo que debe de eliminar forzosamente el proceso 12123.

Estados de los procesos

Un proceso puede tener estados básicos de:

Un proceso que está en ejecución en primer plano, es decir, en la consola, puede ser detenido mediante la pulsación de ^C (Ctrl+C). Esta comando, envía al proceso activo la señal de SIGTERM.

Si se presiona la combinación de teclas ^Z (Ctrl+Z), se enviará la señal de SIGSTOP. Para volver a retomar el proceso ejecutar el comando fg.

Entorno de ejecución

Cuando estamos en una consola (un tty, pts o similar), tenemos a nuestra disposición un intérprete de comandos en el que podemos lanzar procesos en cualquier momento.

Estos procesos pueden detenerse mediante la pulsación de ^C, como habíamos dicho antes, pero también pueden detenerse (con ^Z).

¿Qué sucede cuando se detienen?, básicamente, se genera en un entorno de ejecución un identificador (que es informado entre corchetes, justo antes de la palabra Stopped, en el texto que sale nada más pulsar la combinación de teclas).

Este entorno se puede consultar con el comando jobs. Por ejemplo, si ejecutamos el vim y presionamos ^Z, volvemos a la consola con este mensaje:

[1]+  Stopped                 vim

Si ejecutamos el comando jobs, obtenemos:

$ jobs
[1]+  Stopped                 vim

A estos comandos podemos acceder directamente por su número, de modo que el comando kill, por ejemplo, se puede emplear de la siguiente forma:

$ kill -18 %1

[1]+  Stopped                 vim

¿Por qué nos responde eso y no volvemos a vim?, esto es debido a que el entorno vim requiere de una interacción con el usuario, por lo que no puede ser llevado a segundo plano. Si escribimos el comando bg (background) obtendremos el mismo resultado, debido a que el comando bg es para llevar un proceso detenido a segundo plano.

Si escribimos fg (foreground), recuperamos la interfaz de vim. ¿Qué pasa cuando tenemos varios vim parados?, en ese caso, podemos usar como parámetro el número de identificador del vim que queremos reactivar.

Prioridades

Hay muchas veces, que queremos que un proceso se ejecute con mayor prioridad que otro proceso que esté en el sistema. Que un proceso tenga prioridad para su ejecución, quiere decir que no tendrá que esperar sobre otro que tenga menos prioridad cuando requiera de la CPU para realizar su ejecución, por lo que, debe de ejecutarse más rápido.

Con esto, no obstante, hay que tener mucho cuidado, ya que otorgarle a un proceso pesado una prioridad muy alta, puede acarrear que el sistema se quede bloqueado, hasta que el proceso libere un poco al programador de tareas.

Las prioridades se otorgan con el comando nice. Por ejemplo, si queremos realizar un find con prioridad sobre los demás procesos normales, sabiendo que el número de prioridad por defecto es 10, y que los valores oscilan entre -20 y 19, siendo -20 la prioridad más alta y 19 la más baja, podemos ejecutar:

nice -n 5 find -iname mifichero

Cuando ejecutamos el comando ps, junto al estado del proceso, que ya se vió antes, aparece un segundo caracter, que se refiere a la prioridad siendo:

Conclusiones

La importancia de saber cómo manejar los procesos, los estados que pueden tener, cómo se organizan y las prioridades que pueden tener es crucial para un administrador de sistemas, y cualquiera que desee saber, en un momento dado, si la CPU de su equipo comienza a sobre-utilizarse, o incluso de que haya muchos procesos que ocupen la memoria y permanezcan de forma fija en modo parado.

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 sistema GNU/Linux, al igual que su inspiración Minix, y la raíz de estos sistemas, Unix, se basan en ficheros. Todo es un fichero. Por ello, la seguridad de acceso a este tipo de información es muy importante.

Usuarios y Grupos

Los sistemas *nix, se basan en una estructura basada en grupos y usuarios. Un usuario puede ser una persona que tiene acceso al sistema mediante una contraseña y usa una consola, o puede ser un programa, un sistema servidor o un concepto abstracto (por ejemplo cdrom) en el que se agrupan una serie de ficheros, ejecución de servicios o servidores, etc.

Los grupos son como los usuarios, es decir, pueden tener propiedad sobre un fichero. Esto se hace para limitar o facilitar el acceso a los ficheros a un grupo de usuarios. Cada usuario puede estar en uno o varios grupos, así como cada grupo puede tener uno o varios usuarios.

… ¿y como se enlaza todo esto?

Los permisos en los sistemas *nix se basan en tres partes. Cada fichero y directorio tiene permisos específicos para: usuario, grupo y otros. Esto quiere decir que, si el fichero pertenece a un usuario y a un grupo determinado, podemos limitar los permisos para este usuario en particular, para ese grupo y para los demás.

Al realizar ls -lh en la consola es cuando se ve esta información en consola:

-rwxr-xr-x     1 bombadil  users      2K 12 nov  2009 marubio.jpg
-rw-r--r--     1 bombadil  users     50B  2 nov  2009 marubio.txt
-rwxr-xr-x     1 bombadil  users      5K 12 nov  2009 marubio2.jpg

Como se puede ver, la primera columna de la izquierda, hay un guión inicial que indica si es directorio (d) o fichero (-), después, se indican tres letras por tipo de permisos, en este caso sería:

• rwx, para el usuario, se dan los permisos de lectura (r), escritura (w) y ejecución (x).
• r-x, para los usuarios que no sean bombadil y pertenezcan al grupo users, se dan los permisos de lectura (r) y ejecución (x).
• r-x, y para los usuarios que no sean bombadil, ni pertenezcan al grupo users, se le dan los permisos de lectura (r) y ejecución (x).

¿Qué es eso de ejecución?

Básicamente, los permisos varían si se trata de un fichero o de un directorio, ya que la lectura (r) indica que se pueda leer el fichero o ver los ficheros que hay dentro de un directorio, así la escritura (w) indica que se pueda cambiar un fichero o crear ficheros en un directorio.

El permiso más extraño, el de ejecución (x), en caso de un fichero indica que se pueda ejecutar. Es decir, si se trata de un shell script, un programa compilado, o un script de consola de tipo python, etc., que se pueda ejecutar directamente (sino habría que lanzarlo desde algún intérprete.

En el caso de un directorio, indica si se puede acceder al directorio o no. Es curioso porque es casi como el atributo de lectura, solo que si tienes lectura y no escritura, se permite listar el directorio, pero no acceder con el comando chdir (o cd).

Equivalencia numérica

Hay mucha gente que esto de rwx le sonará un poco a chino y pensará… los permisos de tipo rwxr-xr-x son los 755 de toda la vida

Pues sí, los permisos se pueden dar de forma numérica también, teniendo en cuenta de que son valores octales, se puede dar un valor desde 000 a 777, siendo el primer dígito para el usuario, el segundo para el grupo y el último para los otros. Por tanto:

0 -> ---
1 -> --x
2 -> -w-
3 -> -wx
4 -> r--
5 -> r-x
6 -> rw-
7 -> rwx

Permisos especiales

Además de todo esto, hay dos permisos especiales que tienen unas propiedades bastante curiosas. El primero de ellos es el superuser grant. Este permiso se puede otorgar a programas que se deban de ejecutar como superusuario, pero solo se pueda dar a binarios, los programas de tipo scripting no tienen esta propiedad, ya que, realmente, se ejecutan desde un intérprete que no tendrá este bit de permiso activo.

Como ejemplo, podemos ver el programa passwd. Este programa ejecutado desde consola necesita acceder a ficheros como shadow y passwd para poder cambiar la clave del usuario:

-rwsr-xr-x 1 root root 39K dic  6  2009 /usr/bin/passwd

El segundo permiso especial es el sticky. Este permiso se otorga en especial a los directorios. Cuando un directorio tiene este permiso, quiere decir que cualquier usuario podrá tener acceso al directorio y crear incluso ficheros, pero no podrá modificar y ver nada más que los que sean de su propiedad.

Este atributo es el que se suele usar para el directorio tmp de los sistemas *nix, de servidores multiusuario. Cuando un programa necesita volcar información en este directorio, con este atributo, nos aseguramos que ningún otro usuario puede modificar o ver esta información temporal:

drwxrwxrwt 5 root root 12K ago  5 18:32 /tmp

Conclusiones

Los sistemas *nix tienen sistemas de permisos y usuarios muy simples, comparados con los sistemas de permisos de sistemas con Windows. Esto no quiere decir que sean peores ni mejores, son simples, y por ello flexibles y potentes. Así mismo, en los sistemas GNU/Linux se han implementado unas políticas añadidas de seguridad que no solo permiten el acceso o no a un recurso, sino a nivel de aplicación, el uso de una forma u otra de ese recurso.

No obstante, y sinceramente, el uso llano de estos permisos suele ser suficiente para la mayoría de los casos, no necesitando ninguna capa más que afine el nivel de privilegios, cuyo uso suele ser más complejo.

La idea es jugar, como si de una pistola se tratase, con el comando rm -rf / (lo cual elimina TODOS los ficheros del disco duro y unidades montadas que se tengan -si son accesibles-). El comando toma un número aleatorio y prueba si es divisible por seis. Si es así… ¡bang!, estás muerto, sino, puede volver a tirar

[ $[ $RANDOM % 6 ] == 0 ] && sudo rm -rf / || sudo echo “You live”

Curioso, ¿no?

NOTA: este blog no se hace responsable de los malos usos de los comandos expuestos, de si se elimina toda la información de su disco por un uso irresponsable del mismo, etc. Mi consejo… no lo uséis… o al menos, crear una jaula para jugar.

La filosofía Unix se basa en algunos apartados básicos que todo buen informático debería de emplear en sus desarrollos, ya sea a nivel de sistemas o gestión. El uso de estas directivas, asegura que el trabajo, cuanto más pase el tiempo, más llevadero será.

Las directivas son, básicamente:

• Escribe programas que hagan una sola cosa y la hagan bien: esto quiere decir que los programas deben de ser lo más atómicos posible y que se compruebe mucho su rendimiento y funcionamiento para hacerlo lo mejor posible.
• Escribe programas que trabajen juntos: de nada sirve escribir programas que sirvan para una tarea específica y que, después, cuando esa tarea se modifique de cierta forma, haya que reescribir todo el programa. Es mejor dividir el problema en varios programas y después desechar o reescribir solo uno de esos pequeños programas, cuando se necesite, o incluso hacer nuevos.
• Escribe programas que manejen flujos de texto, pues esa es la interfaz universal: todo lo que se hace con entrada y salida en formato textual es más fácil de enlazar con otros programas, así como reutilizarla en el pasado, presente y futuro.

En estos conceptos se basa la mayoría de software libre que existe, por lo que servidores como sendmail o postfix, se basan en pequeños servidores y/o programas que hacen partes de todo un proceso y, mediante sus ficheros de configuración, se pueden enlazar de una u otra forma, así como usar otros programas y/o servidores en lugar de los que vienen por defecto y, así, extender su funcionalidad.

Sobre filosofía Unix, de una forma más extensa, Mike Gancarz, escribe las siguientes líneas:

• Lo pequeño es hermoso.
• Haz que cada programa haga una sola cosa, pero que la haga bien.
• Construye un prototipo lo antes posible.
• Elige portabilidad sobre eficiencia.
• Guarda los datos en archivos de texto plano.
• Aprovecha funcionalidades del software.
• Usa scripts de shell para aumentar la funcionalidad y portabilidad.
• Evita interfaces de usuario captivas.
• Haz de cada programa un filtro.

Esto no quiere decir que lo realizado sobre interfaces gráficas sea malo, o no respete estas premisas, puesto que muchas de estas interfaces hacen uso de programas que sí respetan al máximo estas premisas y que, favoreciendo la penúltima directiva escrita por Mike, permiten ver los comandos que ejecutan, junto con todos los argumentos.

Concluyendo, pensemos que el trabajo que se realiza día a día, no solo ese software que programamos por amor al arte, debe de sernos de utilidad, no solo en el momento en que nos lo piden para solucionar un problema dado, sino como “caja de herramientas” para la solución de miles de problemas que se deban de resolver en un futuro, quizás no muy lejano

Vía: La filosofía UNIX