Otro blog de Administración Sistemas

Hoy, leyendo el rss de hacker news he visto un post bastante interesante, en el que enseñaban como obtener estadísticas individuales de entrada salida para cada proceso por separado. Esto es posible en kernels posteriores al 2.6.28 por defecto, pero para las versiones anteriores de kernel, o parcheamos, o utilizamos el magnifico script de xaprb.

Primero necesitaremos descargar el script que te permite leer las estadísticas del kernel. Para ello ejecutamos en una consola:

# wget http://maatkit.googlecode.com/svn/trunk/util/iodump

A continuación tenemos que decirle al kernel que muestre los mensajes de Entrada/Salida para cada proceso ejecutando este comando:

# echo 1 > /proc/sys/vm/block_dump

A continuación con el script que nos hemos descargado en el paso 1, capturamos los mensajes sobre Entrada/Salida que esta emitiendo el kernel.

# while true; do sleep 1; dmesg -c; done | perl iodump

Este script debemos ejecutarlo durante tanto tiempo como queramos, y tras terminarlo con Ctrl+C, se nos mostraran las estadísticas de entrada salida para cada proceso en ejecución. En mi caso estos son los datos devueltos:

TASK                   PID      TOTAL       READ      WRITE      DIRTY DEVICES
pdflush                 31        643          0        643          0 sda4
kjournald2             769        277          0        277          0 sda4
firefox-bin           9490         17          1         16          0 sda4
gconfd-2              4063          4          0          4          0 sda4
firefox-bin           9505          1          1          0          0 sda4

Como podéis ver obtenemos el Pid del proceso, el número de operaciones de escritura y el número de operaciones de lectura para cada uno, así como el dispositivo sobre el que se ejecutan dichas operaciones.

Y así de sencillo, espero que esta operación os sea tan utíl como lo ha sido para mí en incotables ocasiones.

Actualización: En servidores en producción con una alta carga de entrada salida, tened mucho cuidado con el espacio en disco, ya que los mensajes se iran guardando en /tmp/ y si son demasiados puede dejaros sin espacio en unas horas.

Otro post rapidito, esta vez para explicar como crear un par de claves para nuestro usuario y autentificarlo automáticamente contra un servidor ssh.

En este “Ejercicio” intervienen 2 máquinas, un equipo personal o un servidor A, y un equipo remoto o servidor B contra el que queremos autentificarnos. Esto suele utilizarse tanto para acceder a un servidor desde tu equipo local, como para autentificar un servidor contra otro para una transferencia que use ssh, como por ejemplo un scp, o un rsync.

Lo primero que tenemos que hacer es crear el par de claves para el usuario que queremos autentificar, esto lo haremos en nuestro equipo personal, o en el servidor que lanza la autentificación.

# ssh-keygen -t dsa

Cuando nos pida contraseña no debemos ponerle ninguna, si no estaremos en las mismas.

Una vez completado el proceso, tendremos dos ficheros nuevos en nuestro directorio home, por ejemplo:

/home/ajerez/.ssh/id_dsa.pub

/home/ajerez/.ssh/id_dsa

id_dsa.pub es la clave pública, la cual se copiara en el servidor remoto al que queremos acceder, y se contrastara contra la privada del equipo origen en cada conexión.

Ahora vamos a poner la clave pública en su sitio, dentro del servidor remoto.

Supongamos que nuestro usuario del equipo local es “ajerez”, y el usuario del equipo remoto contra el que queremos acceder es “remoteuser”, pues bién, debemos crear en el servidor (si no existe ya), el fichero /home/remoteuser/.ssh/authorized_keys, y dentro del fichero authorized_keys, meter el contenido del fichero id_dsa.pub para el usuario “ajerez” de nuestra máquina local o servidor A.

Si queremos hacerlo todo del tirón,  y tenemos habilitado el acceso ssh en la máquina local, podemos ejecutar el siguiente comando en el servidor remoto:

ssh maquinalocal -l ajerez “cat /home/ajerez/.ssh/id_dsa.pub” » /home/remoteuser/.ssh/authorized_keys

Una vez echo esto, desde nuestro equipo local podremos ejecutar:

localhost# ssh remoteuser@maquinaremota

y deberíamos acceder del tirón al equipo remoto, sin pedirnos contraseña ni nada.

Y esto es todo, esta es una práctica bastantes extendida, sencilla y que nos ahorrara mucho tiempo, pero tampoco debemos abusar de ella, sobre todo en entornos de red, ya que si tuviéramos una máquina con acceso ssh sin contraseña a todas los equipos de nuestra red, puede convertirse en un objetivo muy jugoso para usuarios malintencionados. Y recordad, tened siempre controlado el fichero id_dsa, ya que cualquiera con ese fichero, podrá acceder a vuestro server sin necesidad de usar contraseña.

Nota: Para usuarios de windows no se como esta la cosa, así que os recomendaría crear las claves con un equipo linux y luego instalarlas en nuestro cliente ssh de windows.

Este post, a diferencia del anterior, va a ser bastante corto, y así va a ser porque lo que os voy a relatar ahora es una operación bastante sencilla. A pesar de ello yo tarde un tiempo en empezar a utilizarla asiduamente en mi día a día como Administrador de sistemas.

Bueno vayamos al grano, lo que vamos a ver hoy es como crear un túnel desde nuestro servidor o servidores, que nos permita acceder a servicios que de otra manera serian inaccesibles.

Por ejemplo, supongamos que tenemos una red con N servidores, y solo uno de ellos, tiene acceso shell público habilitado, y es el que usamos como punto de entrada para todos los servidores. Ahora, supongamos que en al menos una de las N-1  máquinas que nos quedan, tenemos instalado un servidor de bases de datos mysql, este servidor de base de datos mysql será visible para todas las máquinas dentro de la subred, en el datacenter, pero no lo será desde nuestra oficina o casa por ejemplo, al menos de manera directa.

Con este escenario en mente, supongamos que queremos acceder con una aplicación como mysql workbench al servidor de base de datos que tenemos en la máquina “inaccesible”, en principio seria imposible si no abriéramos el puerto 3306 (o el que este usando mysql), a todo internet, ni que decir tiene que esto no es muy buena idea.

Gracias al tuneling por ssh podemos solventar este problema abriendo una conexión por shell con nuestro servidor, que haga corresponder un puerto de tu máquina local, con el puerto del servicio en cuestión, es decir

ssh -fNg -L 10000:localhost:3306 usuario@ipremota

Con esta instrucción redireccionaremos el puerto 3306 de la maquina remota, al puerto 10000 de nuestra máquina local.

Ahora bien, en el escenario que yo he planteado, el servicio mysql esta en otra máquina que no es la que tiene acceso shell, por lo tanto, en la que si tenemos acceso, debemos ejecutar otro tunel, que redirija el puerto de mysql del server en cuestion, a alguno de la máquina con acceso, y luego este puerto resultante, direccionarlo a tu máquina local. Parece un poco lío, pero no es más que concatenar redireccionamientos de puertos de una máquina a otra.
Ejemplo.

1. ssh -fNg -L 3307:server1:3306 usuario@ip-privada-server2-mysql. Con esto estariamos sirviendo en el puerto 3307 de la máquina con acceso shell público, el mysql de la máuina privada.

2. ssh -fNg -L 10000:localhost:3307 usuario@ipremota. Con este otro comando, redireccionamos a nuestra máquina local el puerto 3307 del server, que a su vez es un tunel del 3306 de la máquina privada.

Espero que os sirva de ayuda este post, y que no os hayáis perdido en el N-1