Automatizar proceso en screen

Uno de mis programas favoritos para administrar servidores es screen pues permite multiplexar una terminal como si fuera varias terminales (ventanas de comandos); es decir que luego de establecer una conección al servidor (mediante SSH) se pueden poner a correr varios programas como si se tuviera varias conexiones establecidas a la vez.

Además se puede salir y desconectarse del servidor, dejando corriendo cada uno de esos programas.  Al volver a conectarse se pueden re-tomar esas terminales que se dejaron abiertas. Sería como poner a correr un programa en un PC y apagar el monitor que se enciende al día siguiente; esto hace screen, cuando se desconecta y se vuelve a conectar a los servidores remotos (en la nube).

Generalmente conecto por SSH e invoco screen, dentro del cual pongo a correr lo que necesito; pero me surgió la necesidad auotmatizar (sin mi intervención) todo para actuar en varios servidores y aquí describo como lo he hecho.

Se puede invocar screen con el programa a correr y quedar desvinculado (deattached) de la terminal screen, invocándolo de esta forma:

screen -dmS prueba watch ls -al
  • -d hace que screen se invoque en forma desvinculada, es como escribir «C-a d» dentro de screen
  • -m hace que screen ignore si hay otro screen corriendo
  • -S prueba es el nombre de la sesión de screen, que luego puede ser usado para gestionar la misma en forma automatizada

ahora solo hay que llamarlo en una sesión ssh:

ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto screen -dmS prueba watch ls -al

(los parámetros de la sesión ssh son ejemplo y deben adaptarse al caso particular)

Luego de ejecutar esto se obtiene nuevamente el prompt local ($), pero ha quedado corriendo una sesión screen en el servidor remoto que está ejecutado el watch ls -al, veámoslo:

$ ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto screen -ls
There is a screen on:
	24411.prueba	(00/22/2113 33:44:55 PM)	(Detached)
1 Socket in /var/run/screen/S-root.
$
$ ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto ps ax | grep -i screen
24411 ?        Ss     0:00 /usr/bin/SCREEN -dmS prueba watch ls -al

para apagarlo, también remotamente, se puede enviar la señal TERM al PID remoto:

ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto 'kill $(screen -ls | grep prueba | cut -d. -f1)'

para los screen de nuestra sesión prueba. Si se quieren apagar todos los screen, se puede invocar más fácilmente asi:

ssh -p222 -i ~/.ssh/cert1 rodolfo@server.remoto 'kill $(pidof SCREEN)'

Mi requerimiento en varios servidores, me llevó a armar un pequeño script que recibe por parámetros start/stop y devuelve la lista de screen corriendo:

#!/bin/bash
# ejecuta screen remotos en los SERVERS

SERVERS="server1 server2 server3 server4 server5"

case $1 in
start) for i in $SERVERS; do
       ssh -p222 -i ~/.ssh/cert1 rodolfo@$i screen -dmS prueba watch ls -al
       done ;;
stop)  for i in $SERVERS; do
       ssh $i 'kill $(pidof SCREEN)'
       done ;;
*)     typeset -i a=1
       for i in $SERVERS; do
          echo "$a ==== $i"
          ssh $i '/usr/bin/screen -list | grep Detached'
          a=$a+1
       done ;;
esac

exit 0

El correo electrónico es una carta abierta, no espere confidencialidad

postcard

En algun momento alguien se convenció que el correo electrónico es confidencial y personalmente creo que es un error de los que estamos en Tecnologías de la Información mantener a los usuarios convencidos de esto.

Si Ud. es de los que cree que su correo con información confidencial solo será leido por el destinatario, está equivocado. Le digo más: si envía esa información en una carta abierta por el correo tradicional o en una post-card, posiblemente sea menos leído que si la envía por correo electrónico.

El correo electrónico es una carta abierta que es procesada por «clasificadores» y «carteros» incansables y meticulosos que leerán cada palabra de su correo, analizarán sintáctica y lexicamente su mensaje y tomarán decisiones sobre el mismo.

Si, cada correo electrónico es analizado por sistemas informáticos. Su mensaje será leído por el anti-spam que le aplicará reglas para determinar si Ud. está queriendo difundir propaganda no deseada, será leído por el antivirus que determinará si hay códigos no aceptados, será leído por sistema de políticas de lenguaje (si entra o sale de una organización que las aplica), será catalogado por filtros, será registrado por sistemas estadísticos y, al final de todo, será guardado en texto plano junto con el resto de sus correos y podrá ser accedido por todo el personal técnico (y software) con acceso suficiente para revisar su correo.

Si, el correo electrónico es una carta abierta, y si Ud. piensa que por enviar su mensaje en un documento adjunto (p.ej. PDF) tiene más confidencialidad, le digo que es irrelevante. ¿Como cree que luego el buscador le encuentra sus textos dentro de los PDF? pues, los mismos clasificadores y carteros electrónicos estarán leyendo esos documentos adjuntos también.

Me llama la atención el artículo publicado en el Portal Montevideo.Com: «Google admite que no se puede esperar total privacidad al usar Gmail«, cuando ellos mismos son prestadores de un servicio de correo. ¿acaso Montevideo.Com puede asegurar que los correos @montevideo.com.uy son totalmente privados?

Es hora de decir las cosas claramente:

Al igual que en el correo tradicional, si Ud. no se preoupa en poner su carta en un sobre y cerrarlo, nadie le va a asegurar confidencialidad. En el correo electrónico, si no cifra su correo, nadie puede asegurarle confidencialidad.

Hay que explicarle a nuestros usuarios que los correos electrónicos NO SON CONFIDENCIALES, a menos que tomen medidas al respecto.

En el 2004 dicté varias veces una conferencia «Seguridad en los e-mail«, tratando de difundir esto.

Linux Containers ¿cuántos Linux quieres tener?

Linux Containers (LXC) es un sistema de virtualización con Software Libre nativo en GNU/Linux, que habilita aislar procesos y recursos sin la necesidad de correr software de interpretación y emulación, ni las complejidades de otros sistemas de virtualización. LXC permite además la virtualización en entornos ya virtualizados como Cloud Computing y está siendo una herramienta muy apreciada por los DevOps para crear entornos efímeros donde correr aplicaciones en entornos controlados y deshechables. Se presentarán los principales  aspectos técnicos de los  LXC desde un punto de vista práctico; pues si necesitas otro Linux alcanza con pedírselo al tu kernel. También se presenta Docker como herramienta de automatización de PaaS.

Público Objetivo: Usuarios de GNU/Linux, administradores de redes, SysAdmins y DevOps.  Público en general.

Requisitos: Nociones de virtualización; de preferencia conocer comandos de shell.

Conferencia dictada en:

Puppet para hacer el trabajo por ti en el Datacenter

Para manejar un número importante de servidores en un datacenter, originalmente contábamos con un conjunto de scripts que ajustaban la instalación a nuestras políticas; con la virtualización comenzamos a usar templates; pero hoy día con el advenimiento de la nube y las aplicaciones que crean servidores, necesitamos mayor flexibilidad para atender requisitos variables y muy particulares, pero además se necesita un método que permita asegurar que cualquier cambio de políticas pueda ser impactado rápidamente en toda la granja. Puppet hace ese trabajo por ti en el Datacenter. En esta presentación se aborda también algunos ejemplos prácticos en los que Puppet está siendo utlizando con éxito.

Público Objetivo: Técnicos encargados de administración de servidores, SysOps y DevOps, administradores de centros de datos.

Requisitos: Conocimientos de sistemas operativos (Unix), administración de servidores.

Conferencia dictada en:

Realidad Virtual y Metaversos

Las tecnologías de la información nos ofrecen nuevos modos de vincularnos y conocer nuestro entorno, nuestro Mundo. Esta presentación es una breve introducción sobre cómo esas tecnologías están facilitando lo que se ha dado en llamar el Metaverso. Se presentan la realidad aumentada, los mundos espejos, los mundos virtuales y el lifelogging; con un repaso por los mundos virtuales más aceptados en la actualidad.

Público Objetivo: Docentes y personas vinculadas a la educación, público en general.

Requisitos: No.

Conferencia dictada en: