Blog

El comando terraform import nos permite importar en HashiCorp Terraform recursos que ya existían previamente en el proveedor con el que estemos trabajando, es este caso AWS. Sin embargo, sólo permite importar dichos registros uno por uno, con una ejecución de terraform import cada vez. Esto, aparte de ser tremendamente tedioso, en algunas situaciones se vuelve directamente impracticable. Este es el caso de los registros de una zona DNS de Route53. La tarea puede resultar inabarcable si tenemos varias zonas DNS, y cada una tiene decenas o cientos de registros. En este artículo te ofrezco un script en bash que te permitirá importar en Terraform todos los registros de una zona DNS de Route53 en cuestión de segundos o de pocos minutos.

El siguiente procedimiento describe cómo permitir en Linux el uso simultáneo de 2 interfaces de red conectadas a la misma subred de AWS y que la comunicación funcione tanto a nivel interno (máquinas en la misma subred) como externo (ambas interfaces visibles desde Internet). Esto puede ser útil por ejemplo cuando queremos que una misma instancia aloje un servidor web que sirva peticiones http ó https y al mismo tiempo disponga de un servidor de websockets ws:// o wss:// que escuche en el mismo puerto 80 ó 443 respectivamente. Aunque hay otras formas de conseguirlo como configurar Nginx para que sea capaz de discriminar el tráfico web (http) del tráfico de websockets (ws) y actuar como proxy para redirigir las peticiones correspondientes al servidor de websockets, esta otra solución que planteo me parece más sencilla y en cierta medida más eficiente porque no es necesario redirigir el tráfico, lo cual siempre introducirá una pequeña latencia, y permite mantener ambos servidores totalmente independientes dentro de la misma máquina. La única pega es que necesitaremos asignar 2 direcciones IP elásticas (Elastic IP) a la misma máquina en lugar de 1, pero al mismo tiempo esto nos aportará mayor flexibilidad a la hora de establecer reglas en los grupos de seguridad o en las reglas NAT de la subred.

En este artículo voy a hablar de una app para Android que es extremadamente útil para ejecutar comandos de forma remota en un ordenador Linux: Hot Button SSH Command Widget. Esta aplicación nos permitirá lanzar cómodamente cualquier comando que se nos ocurra en un ordenador remoto a través de SSH con sólo pulsar un botón en la pantalla de nuestro móvil o tablet, lo cual no sólo nos facilitará la automatización de tareas repetitivas, sino que además resulta muy interesante desde el punto de vista de la seguridad por los mismos motivos que expuse en mi artículo Desbloqueo automático de pantalla por proximidad de dispositivo Bluetooth, ya que nos permitirá por ejemplo bloquear y desbloquear la pantalla sin tener que escribir nuestra contraseña una y otra vez a la vista de otras personas.

A raíz de la publicación de la noticia del lanzamiento del Kernel 4.12 de Linux, el cual trae por primera vez activada por defecto la característica KASLR, y casi simultáneamente la publicación de esta otra noticia sobre la implementación de una característica llamada KARL en OpenBSD me ha parecido que sería interesante aclarar las diferencias entre estas técnicas de seguridad, pues pienso que la combinación de ambas va a ser muy importante de cara al futuro de la seguridad de los sistemas, pues van a impedir explotar vulnerabilidades relacionadas con la corrupción de memoria (buffer-overflow).

El fichero .xsession-errors es un fichero de log que utiliza el sistema de ventanas X para registrar todos los errores que se producen en el entorno gráfico de Linux. Dado que todos los entornos de escritorio, ya sea Gnome, KDE, Cinnamon, XFCE, LXDE, etc., y todos los gestores de ventanas más livianos que no llegan a constituir un entorno de escritorio como FVWM, IceWM o Window Maker utilizan el sistema de ventanas X, al final cualquier aplicación gráfica que ejecutemos en nuestro ordenador puede provocar que se escriban mensajes de error en el fichero .xsession-errors, por lo que éste puede crecer de forma descontrolada hasta alcanzar fácilmente un tamaño muy grande de decenas de GB o incluso cientos si la capacidad de nuestro disco lo permite.

Normalmente es fácil saber cuál es el proceso o procesos que están escribiendo sobre un fichero dado en Linux, ya que o bien conocemos previamente su origen, por ejemplo el access_log de Apache, o bien podemos hallarlo fácilmente con los comandos fuser o lsof. Sin embargo, a veces nos ocurrirá que aunque conozcamos el origen o el cometido de un fichero, son tantas las aplicaciones que pueden estar haciendo uso de él simultáneamente, que es muy difícil saber cuál de ellas es la que más escribe o la que lo está haciendo en un momento determinado, lo cual nos resultaría muy útil para saber por ejemplo por qué un fichero de log está creciendo desmesuradamente o qué aplicación está haciendo un uso abusivo de nuestro sistema, ya sea por un fallo o de forma intencionada.

Cuando se nos llena completamente el sistema de ficheros de una partición ext4 alojada en un volumen EBS de Amazon Web Services y no podemos hacer nada por liberar espacio al no querer perder ninguno de los datos almacenados, el único remedio que nos queda es ampliar el volumen y hacer crecer la partición asociada hasta el 100% de su capacidad para disponer nuevamente de espacio libre de almacenamiento.

Partimos en nuestro ejemplo de un volumen de 50 GB lleno al 100% que queremos ampliar a uno nuevo del doble de tamaño, 100 GB:

Dado que la combinación de teclas Control+s es muy utilizada como atajo para la opción de Guardar ficheros en aplicaciones gráficas como editores de texto, editores de imágenes, navegadores web, etc. a veces nos traiciona el subconsciente cuando estamos trabajando desde la línea de comandos de Linux y utilizamos esa misma combinación de teclas cuando estamos por ejemplo editando un documento con Vim con la intención de guardarlo. A partir de ese momento observamos que ninguna tecla responde, la shell se ha bloqueado y ya no podemos hacer nada más en ella y nos entra un sudor frío porque no podemos acceder al documento que estábamos editando y no podemos salvar los cambios.

El valor medio de carga es una métrica muy importante para comprender el comportamiento de un sistema Linux, y sobre todo su estado actual y en el pasado reciente. Muchas veces hay confusión entre su significado y el del porcentaje de uso de CPU, pero en realidad son importantes las diferencias. En este artículo trato de explicar el verdadero significado de ambos y cómo saber si una máquina Linux se encuentra sobrecargada o infrautilizada.

Soy un firme defensor de la simplicidad y del principio de que menos es más, pero en cuanto a la seguridad y el rendimiento de los sistemas de información se refiere, debemos ser capaces de encontrar un equilibrio entre mantener las cosas sencillas y exponernos lo mínimo posible a potenciales amenazas al mismo tiempo que tratamos de obtener las máximas prestaciones de los elementos que configuran nuestro sistema.