script

  • Este artículo muestra cómo correr un script o comando en un cliente de Bacula, justo antes de que comience el trabajo de backup para el mismo. Esto es muy necesario para el caso de los servidores de bases de datos, donde se requiere realizar un volcado (dump) de las bases de datos a disco (por ejemplo mysqldump o pg_dump) para que sean parte de la copia de seguridad.

  • Comparto un script sencillo que permite borrar automáticamente backups viejos en un servidor GNU/Linux.

  • Hoy liberé un nuevo script Bash, llamado "checkmyfarm", para dar soporte a mi sistema de actualización de servidores en paralelo. Este script tiene el propósito de enviar un único mail incluyendo el resumen de actualizaciones disponibles en todos los servidores de la granja, y reemplaza al viejo verificar_actualizaciones.sh (el cual corría individualmente en cada servidor). De esta forma, en lugar de recibir un mail por cada servidor, recibo un único mail con el resumen de actualizaciones disponibles en todos los servidores de mi granja.

  • He publicado una nueva versión de mi script mailgun-mta.bash, que ahora soporta el uso de opciones y argumentos de línea de comandos como destinatario, asunto y remitente. Mi idea (tal como mencioné en artículos anteriores) es lograr reemplazar el comando mail por este script. De forma que todo el correo saliente desde un servidor sea a través del servicio en la nube de Mailgun.

  • Muchas veces debemos realizar una tarea de mantenimiento en un servidor que involucra una cantidad de pasos, suele ser muy compleja, y a su vez requerir una cantidad importante de comandos. Si además se trata de un servidor crítico, debemos realizarla en el menor tiempo posible para no afectar a los usuarios y servicios. Como buen administrador de sistemas (sysadmin, en la jerga de los informáticos) uno debe documentar metódicamente todo lo que hace. He aquí el problema en estas situaciones, se debe realizar una tarea compleja en tiempo récord lo cual impide documentar mientras se ejecuta la tarea (lo que recomiendan todas las metodologías de gestión de tecnologías de la información). Es decir, no hay tiempo para cargar contenido en una Wiki, no hay tiempo para documentar. Al menos no hay tiempo para documentar mientras se ejecuta la tarea. Entonces no queda otra alternativa que documentar una vez finalizado, testeado y cerrado el caso, o peor, cuando tenga tiempo. El resultado es que la documentación termina siendo pobre, y muchas veces se pierden pasos y/o detalles importantes que afectan de forma crítica el éxito de la misión.

    Lamentablemente esta situación se repite a diario en la mayoría de los colegas sysadmins, quienes están tan saturados de trabajo que directamente nunca tienen tiempo para documentar nada (la documentación no es una prioridad para la Gerencia, gran error). Luego la empresa (o al menos la gestión de IT) para la cual trabaja Pepe (suponiendo que Pepe es el sysadmin) se vuelve Pepe-dependiente. A esta altura ya me fui por las ramas, estoy detallando aspectos de una mala gestión de IT, en lugar del tema que presenta el título.

    Volviendo al punto, este artículo describe el uso de una excelente herramienta que me ayudó a documentar en muchas ocasiones. La pregunta para afrontar el problema de forma exitosa es: "¿Cómo hago para guardar todo lo que escribí en la línea de comandos, incluyendo las salidas de los mismos, sin tener que copiar y pegar constantemente?". La respuesta es simple: utilizar el comando script.

  • Una característica muy interesante que posee el servidor Fast CGI de PHP (PHP-FPM) es la posibilidad de detectar, y registrar en un log, aquellas solicitudes que tienen un tiempo de ejecución elevado. Esto puede ser de gran utilidad para descubrir cuales son las páginas de un sitio Web que tardan demasiado tiempo en procesar en el servidor, y por ende cargan demasiado lento.

  • En este artículo comparto un sencillo script Bash que desarrollé para calcular el uptime (el tiempo que ha transcurrido desde que ha iniciado) de un servidor HTTP Apache. No confundir con el uptime del sistema operativo (tiempo transcurrido desde que ha iniciado el sistema, se obtiene con el comando uptime), sino que se trata de obtener el tiempo que lleva en ejecución el servicio "apache2" (el cual puede ser mucho menor al del sistema operativo si el servicio ha sido reiniciado).

  • En sistemas FreeBSD, el módulo del kernel coretemp provee el controlador de dispositivo para acceder a los sensores de temperatura presentes en los microprocesadores Intel Core.

  • Al desarrollar scripts Bash, frecuentemente se necesita o desea poder obtener ciertos parámetros en forma de argumentos de línea de comandos, es decir, al momento de invocar el script. Esta es una tarea sencilla si nuestro script necesita un único parámetro por línea de comandos. Sin embargo, si deseamos soportar cualquier número de argumentos y opciones que requieran o no un parámetro adicional, las cosas se complican. Especialmente si la mayoría de los parámetro son opcionales y deseamos soportar cualquier orden.

    Este artículo demuestra una técnica simple para recuperar opciones y parámetros como argumentos de línea de comandos al desarrollar scripts Bash.

  • Hace varias semanas comencé a armar un compilado de rock nacional (argentino). Una especie de reseña histórica desde el tema "La Balsa" del año 1967, perteneciente a la banda Los Gatos, hasta la actualidad. Me llevó mucho tiempo pero puedo decir que he terminado. Fue un arduo trabajo de investigación (en parte gracias a Wikipedia) para recopilar todos los temas (474 en total).

    Una vez terminado, me encontré con que algunos temas tenían los tags ID3 cargados, otros nada, y otros tenían incluso hasta letras e imágenes de portadas embebidas. Pero en general, dado que provenían de diferentes álbumes y fuentes, los tags no respetaban patrón alguno. Por ello quise borrarlos a todos. Aunque claro, no podía hacer este trabajo manualmente, pues me llevaría muchísimo más tiempo. Entonces se me ocurrió utilizar un script Bash y una herramienta de edición de tags ID3 de línea de comandos para cargarlos a partir de los nombres de archivos.

  • Combinando la salida leída del dispositivo /dev/random (generador de números aleatorios del kernel Linux) con tr y head, es posible generar diferentes tipos de cadenas de caracteres (strings) ya sea para utilizar en scripts, crear claves o contraseñas, o simplemente divertirse un rato (?)

    He aquí algunos ejemplos.

  • Luego de bloquear intentos de acceso a mi sitio Web, se me ocurrió tratar de determinar el país de origen de las direcciones IP de los atacantes.

    Existen muchos sitios Web que dan esta información (geolocalización de una dirección IP) de forma gratuita, sin embargo necesitaba una alternativa desde línea de comandos, para poder luego automatizar la conversión de IP a país y sacar una estadística al respecto.

  • Hoy me topé en Google Plus con este divertido sitio que simula escribir código C como lo hacen en las películas: hackertyper.net. Luego de probarlo, se me ocurrió implementarlo con un script Bash, para ejecutarlo en la consola y simular que trabajo jejeje.

  • Luego de haber instalado y configurado mi servidor OpenLDAP con PostgreSQL como backend, habían quedado una serie de tareas pendientes. Entre ellas, una de las primeras era instalar un script de inicio System V, a fin de levantar el demonio slapd automáticamente al iniciar el sistema, y gestionar el servicio a través de la herramienta service.

  • A partir de la arquitectura de mi sistema de actualización de servidores, decidí implementar un nuevo script para verificar el estado de las VMware Tools, y reinstalarlas de forma desatendida cuando sea necesario.

  • Una nueva entrega de La biblia del SysAdmin. Sólo una de muchas pendientes. Con la llegada del Curso introductorio a la Administración de Sistemas GNU/Linux tal vez apure a publicar un par de capítulos más. A fin de que sirvan como puntapié y lectura posterior al curso que estaré dictando próximamente.

    A lo largo de una serie de artículos voy a publicar los principios básicos que todo SysAdmin debe respetar, practicar y predicar a sus pares. Estos principios los he tomado (y orgullosamente puedo decir que he respetado casi en su totalidad) del artículo General SysAdmin Principles & Guidelines publicado por el Dr. Joe Chung.

  • El día de hoy tuve que auditar permisos en un servidor de bases de datos MySQL, y me encontré con la dificultad que el mismo no provee una herramienta o comando para volcar todos los permisos (grants) de todos los usuarios. Por ello me vi en la necesidad de desarrollar un pequeño script Bash para llevar a cabo esta simple tarea. Pequeño script al que luego le agregué alguna funcionalidad básica para realizar filtrado y formateo de la salida.

  • En el artículo Sysadmin vago: cómo actualizar todos los servidores de tu organización ejecutando un único comando expliqué de qué forma es posible lanzar actualizaciones de múltiples servidores GNU/Linux (Debian y CentOS) desde un simple script Bash, utilizando un servidor de administración centralizado y SSH con autenticación con clave pública.

    La limitación de este esquema era que trabajaba de forma secuencial, es decir, se actualizaba de a un sistema por vez. Por lo tanto en este artículo voy a demostrar cómo he mejorado mi script para lanzar todas las actualizaciones en paralelo (so pena de saturar un poco el enlace y/o Web proxy) sin necesariamente perder el control del proceso.

  • Un problema común en servidores que manejan grandes volúmenes de datos es quedarse sin espacio disponible en alguna partición. Este inconveniente puede ser crítico, si el sistema de archivos que se queda sin espacio disponible hospeda algún directorio crucial para el funcionamiento del sistema, como por ejemplo el directorio /var y sus subdirectorios.

  • Además de PostgreSQL y MySQL, en nuestra organización utilizamos servidores de gestión de bases de datos IBM Informix. Se trata de un producto de software de gestión de bases de datos propietario, licenciado por IBM, que corre sobre sistemas Unix.

    Al tratarse de software propietario, collectd (y creo que ninguna otra solución de recolección de métricas) no posee un plugin para monitorear servidores de bases de datos Informix. Por ende me dispuse a crear un script Bash que permita monitorear servidores Informix y almacene las métricas en una base de datos InfluxDB, el cual comparto en este artículo.