Instalación y Configuración de Ganglia en Debian Wheezy 7.0

Este tutorial configura un servidor de monitoreo Ganglia y su interfaz web, y lo deja preparado para trabajar en modo multicast (es la configuración por defecto de Ganglia), luego de instalar el componente cliente de Ganglia en otros servidores, los datos se empiezan a recibir automáticamente en el servidor monitor.

Desde el punto de vista técnico, no realizamos en realidad ninguna configuración, simplemente se instala el software. El paso C) de configuración se realiza al solo efecto de darle un nombre al grupo de servers a monitorear.

La configuración de nombres en los servers - que realizamos durante la instalación en A) y B) - es necesaria para permitir una buena identificación de los hosts en la interfaz web.


Requerimientos
Dos instalaciones base de Debian Wheezy 7.0 terminadas (y actualizada opcionalmente), un cliente y un servidor.

Las IPs de los servidores van a ser obtenidas vía DHCP, de modo de simplificar el tutorial (es una buena práctica configurar los servers con IPs estáticas)

En este caso las IPs son:

• IP del servidor de monitoreo - 192.168.0.100
• IP del cliente de monitoreo  - 192.168.0.105

Pasos para la Instalación y Configuración de Ganglia

A) Instalar cliente
B) Instalar server
C) Configurar server

Luego de este punto ya estamos en condiciones de replicar la instalación del cliente en otros servidores, y en minutos el server monitor Ganglia va a empezar a recibir los datos de monitoreo de esos nuevos servers cliente configurados.



Instalación del cliente Ganglia

1)

- Configurar /etc/hosts con los nombres de los servidores a monitorear.
127.0.0.1       localhost
127.0.1.1       monitor-cliente.local.net  monitor-cliente

- Configurar /etc/hostname:
monitor-cliente

Luego reiniciamos el sistema.


2) Instalación del Cliente Ganglia:

apt-get install ganglia-monitor

Listo

3) Verificar que el servicio esté activo, corremos:

service ganglia-monitor restart

y tendría que ejecutar sin errores.

4) Obtenemos y guardamos la IP del server para asociarla estáticamente a un nombre en el server monitor:

ifconfig



Instalación del servidor Ganglia

1)

- Configurar /etc/hosts con los nombres de los servidores a monitorear.

127.0.0.1       localhost
127.0.1.1       monitor-server.local.net      monitor-server

# servidores adicionales
#
# el nombre debe coincidir con el hostname
# configurado en el server mismo
192.168.0.100 monitor-cliente.local.net  monitor-cliente

- Configurar /etc/hostname:
monitor-server

Luego reiniciamos el sistema.

2) Instalación del Server Ganglia (que incluye la instalación del cliente Ganglia > "ganglia-monitor" para poder monitorearse a sí mismo)

apt-get install ganglia-monitor ganglia-webfrontend gmetad

Aceptar o o no cuando pide reiniciar Apache no es relevante, cualquier opción va a funcionar igual (el script de post-instalación NO carga la configuración de Ganglia-web en Apache)


3) Activar sitio web Ganglia donde ver la información gráfica:

- Ir a /etc/ganglia-webfronted, localizar el .conf de Apache
- Crear un link simbólico del mismo en /etc/apache/conf.d
- Reiniciar Apache (service apache2 restart)

Listo, instalación terminada.


4) Verificar que los servicios estén activos, corremos:

service ganglia-monitor restart
service gmetad restart

y tendrían que ejecutarse sin errores.

Si miramos en la configuración de Apache en /etc/ganglia-webfrontend/apache.conf (activa en Apache con el link que creamos antes), vemos que Ganglia está en el directorio "ganglia" de nuestro webserver.

En un navegador probar Ganglia: http://192.168.0.105/ganglia



Configuración del Servidor Ganglia

1) Configurando Ganglia Fácilmente

- Ver la configuración en el archivo /etc/gmetad.conf (no editar nada)

data_source "My Cluster" localhost


2) Configurar en /etc/gmond.conf

name = "Taller"

y reiniciar servicio Gmond: service ganglia-monitor restart

Nos fijamos ahora en el Ganglia Web como cambió el nombre del cluster Ganglia de "unspecified" ("sin especificar"), a "Taller".


Luego de terminar esta configuración, ya vamos a ver cómo Ganglia empezó a tomar los datos del servidor cliente que acabamos de instalar, y en un par de minutos, solamente se ven los datos del server (localhost), y del cliente (debian-monitor-cliente).

* En el sitio Ganglia, el server debian-monitor-server se ve como "192.168.0.102", que es la IP de localhost para el server.


Soluciones de problemas comunes y Tips

Problema: gráficos que no aparecen (en versiones viejas de Ganglia)
Si para el servidor remoto hay problemas para graficar la información, lo agregamos manualmente al /etc/gmetad.conf del server monitor:

data_source "miservermonitor" localhost
data_source "miotroserver" 192.168.0.101

(los nombres usados en gmetad.conf para el data_source no son relevantes, no figuran en ningun gráfico, solo deben ser diferentes entre sí)


Problema: Hosts (servers) que no existen siguen apareciendo en los gráficos
Si vemos que luego de las pruebas, tenemos varios hosts "fantasma", resultado de haber reconfigurado un par de veces, vamos a reconfigurarlo para eliminar los servidores inexistentes de las gráficas.

Lo vemos claramente en la interfaz:

CPUs Total: 5
Hosts up: 3

(y tenemos configurados solamente 2 hosts)

a) Detenemos gmetad (service gmetad stop) en el server monitor.

b) Vamos al directorio donde se guardan las gráficas: /var/lib/ganglia/rrds

c) Borramos los directorios pertinentes (prestar atencion a los nombres y buscar los nombres de los hosts que no existen).


Tip: Correr una GUI Ganglia mejorada con versiones viejas de Ganglia.
Si nuestra distribución instala una versión vieja de Ganglia, la interfaz web va a ser la anterior a la actual. Se puede usar la interfaz actual (o actualizar manualmente la nueva cuando salgan nuevas versiones), con versiones viejas de Ganglia, sin problemas.

Para actualizar solo la interfaz, lo tenemos que hacer manualmente.

Las instrucciones de abajo configuran la interfaz actualizada en un directorio "/ganglia2" en el webserver, y así seguimos teniendo la interfaz anterior en "/ganglia" (es útil para evitar problemas al actualizar paquetes).

Instrucciones

1) Descargamos el código fuente más nuevo de Ganglia Web:
http://sourceforge.net/projects/ganglia/files/ganglia-web/3.5.2/

2) Instalamos requisitos (figuran en el readme):
apt-get install php-services-json

3) Crear un directorio para instalar allí los archivos de la interfaz actualizada (si usamos el directorio por defecto, va a sobreescribir la interfaz actual, instalada por los paquetes de la distribución):

mkdir /usr/share/ganglia-web-2

4) Descomprimir el archivo bajado en un directorio temporal.

5) Modificar el makefile, cargamos el directorio destino /usr/share/ganglia-web-2

DESTDIR = /usr/share/ganglia-web-2

y como usuario a www-data (el usuario de Apache para Debian):

APACHE_USER = www-data

luego corremos:

makefile install

6) Crear y activar la configuración para Apache:

cd /etc/apache2/conf.d/
touch apache-web2.conf
echo "Alias /ganglia2 /usr/share/ganglia-web-2" > apache2-web2.conf
service apache2 restart

Probamos yendo a la URL:
http:/IP/ganglia2

Training de Monitoreo; instrucciones paso a paso: JffNMS

Siguiendo con la promoción del curso de monitoreo que voy a estar dictando en abril, les copio uno de los instructivos de implementación paso a paso que voy a estar utilizando en el curso. En este caso vemos cómo se instala Jffnms.



Instalación de JffNMS en Debian
-------------------------------

Software: http://www.jffnms.org/
Demo: http://jffnms.enc.com.au/
user: admin
pass: admin

Documentación de soporte
- http://sourceforge.net/apps/mediawiki/jffnms/index.php?title=Linux_Installation
- /usr/share/doc/README.debian


1) apt-get install jffnms

2) Aceptar cuando el asistente ofrece configurar dbconfig-common (configura la DB automáticamente)

- Tener la contraseña de root de mysql
- Usar como contraseña de JffNMS, la cadena "jffnms" (ayuda en la instalación más tarde)
- La configuración de la DB estará en:
/etc/dbconfig-common/jffnms.conf


3) En /etc/jffnms encontramos el archivo de configuración para Apache, crear un enlace simbólico desde /etc/jffnms a /etc/apache2/conf./jffnms-apache.conf (ese sería el nombre del link):

ln -s /etc/jffnms a /etc/apache2/conf./jffnms-apache.conf


4) service apache2 restart

5) Entrar en http://server/jffnms

y

- verificar que el acceso a la DB esté en OK
- verificar qué herramientas no están en OK (para instalarlas si hace falta)

luego grabar

6) Al volver a entrar a http://server/jffnms

el user por default es admin, clave admin

Training de monitoreo de redes y servidores 2013

En este artículo comento detalles del curso de monitoreo de redes y servidores, que voy a dictar próximamente. Los datos de contacto del curso aquí:

"Training de Monitoreo de Redes y Servidores en GNU-Linux y Windows"

El por qué del curso
El trabajo de monitorear infraestructura es comunmente poco considerado como parte de las soluciones de infraestructura. Eso es un error.

Al implementar un sistema, cualquiera sea: un servidor web Apache, un domain controler Active Directory, un servidor de archivos Samba, etc. hay en general varias componente, parte de una solución integral realmente completa:

• Instalación (el software instalado y funcionando)
• Configuración (el software adecuado al contexto y los requerimientos)
• Administración (conocimientos necesarios para la gestión del software y su posterior re-adaptación a cambios en el contexto y/o en los requerimientos)
• Recuperación de Desastres (la planificación y disposición de lo necesario para recuperar el sistema completo luego de una falla total)
• Backup (el resguardo de datos importantes del sistema, de importancia histórica, que no son parte de la instalación desde cero).
• Monitoreo (permite controlar el funcionamiento de la solución, prever emergencias, recibir alertas de fallas que ya ocurrieron y adquirir - y archivar sistemáticamente - información histórica útil que nos permitirá optimizar todas las demás tareas antes mencionadas: configuración, administración, recuperación de desastres, backup, etc., inclusive las nuevas instalaciones serán optimizadas al analizar en retrospectiva la información obtenida del monitoreo).
• Etc.

Como ven la mera instalación y configuración de una solución no está completa sino se incorpora el resto de las componentes que permite garantizar que siga funcionando apropiadamente de modo previsible para la organización que la requiere.

El monitoreo es una de esas componentes clave, y disponer de una adecuada solución de monitoreo global para la infraestructura es de vital importancia. Ese es el por qué de este curso.


Día y Horario
El curso se va a dictar los jueves, de 20.30 hs. a 23.30 hs. (3 hs. en total), una vez por semana.

Costos
Inscripción: AR$ 50
Cuota Mensual: AR$ 250

Duración
4 Meses

Instrucciones Paso a Paso
Bien sigo en preparación detallada del curso de monitoreo de redes y servidores, ¿por qué preparación detallada? Porque al ser un curso práctico (en jerga > "hands-on"), necesito tener instrucciones paso a paso de cada instalación y configuración que se vaya a hacer en clase.

Por eso, además del material de lectura que ya tengo archivado, estoy en estos días creando el "guión" de cada clase, donde voy planificando cómo se va a dar la clase, de qué temas voy a hablar, cuando, etc. Además, estoy planificando qué y en qué orden vamos a ir haciendo para llevar adelante las implementaciones del software que se va a mostrar en el curso.

Claro, este material va a ser parte del curso: instrucciones paso a paso de cómo instalar y configurar - "implementar" - los diferentes software de monitoreo y se entrega a los asistentes (en formato electrónico por cierto).

Sé que hay mucho material ya online, de hecho yo lo estoy usando intensivamente, y los links a los tutoriales son parte de la documentación del curso, sin embargo, cada howto y tutorial se caracteriza porque se hizo en base a X distribución, X versión de esa distribución, utilizando X versión del software y en la práctica, siempre se termina utilizando varios tutoriales (y varias fuentes de documentación), para llegar a un resultado satisfactorio en una implementación, alcanzado así a proveer la solución buscada (en este caso, para el curso). El motivo es que normalmente un solo tutorial no alcanza a brindar todas las respuestas (y la diferencia la suplimos con otros tutoriales y con nuestra propia experiencia).

El trabajo de revisar y documentar paso a paso las implementaciones es necesario - en mi opinión - para un curso como este: es para mutuo beneficio - del que dicta el curso y de los que asisten - el tener tutoriales paso a paso de todo el software, adecuado específicamente, y actualizado a marzo 2013, a las versiones de todo lo que se va a utilizar en el curso.

La distribución: Debian
La distribución que se va a utilizar va a ser Debian Linux Squeeze, que tengo el gusto de estar administrando profesionalmente desde años (antes de Squeeze claro), y ahora mismo.

El 90% de las instalaciones se realizarán usando apt-get y hay un pequeño porcentaje de instalaciones que va a requerir compilar código (los agentes SFlow). No se olviden de las instrucciones paso a paso, para esto también las va a haber.


Tareas Accesorias
Debido a que las implementaciones de software de monitoreo califican como trabajo de administración de sistema de nivel como mínimo intermedio a avanzado, hay muchas, varias técnicas de trabajo - workflow - y de configuración/diagnóstico/reparación que va a hacer falta implementar mientras se realiza el trabajo. Esto también va a ir teniendo el mencionado paso a paso.

Por ejemplo: Cuando se configura un webserver Apache, hace falta determinar qué usuario utiliza Apache para corre, luego hace falta que todos los archivos que van a ser parte del sitio a configurar tengan de owner al usuario de Apache; luego - si no fue creado automáticamente - va a hacer falta crear el archivo de configuración del sitio (que va en un directorio específico, etc. etc.). Todo lo anterior hace falta realizarlo al menos tres veces durante la configuración del software del curso y lo vamos a hacer en directo, no va a haber ninguna transición automágica al estilo "bueno, ahora se configura Apache y listo, queda así".

Hay bastantes tareas accesorias por cierto ("¿cómo se puede ver todas las líneas de un archivo de configuración que no estén comentadas con #?"), pero se ubican muy lógicamente dentro del flujo de trabajo de la instalación y configuración del soft de monitoreo, no va a haber ninguna mezcla de temáticas, sino simplemente serán etapas - un poco más complejas - de la implementación general.

El software de monitoreo
El software que se va a instalar,configurar y administrar va a ser:

- Agentes/Servicios SNMP (Windows y Linux)
- Ganglia (monitoreando Windows, Linux y equipos de red)
- Cacti  (monitoreando Windows, Linux y equipos de red)
- Nagios (monitoreando Windows, Linux y equipos de red)
- Icinga (monitoreando Windows, Linux y equipos de red)
- OpenNMS (monitoreando Windows, Linux y equipos de red)

Software de monitoreo extra
Estoy trabajando (armando los tutoriales paso a paso), para incluir JffNMS y SFlow.

- Agentes SFLOW  (Windows y Linux)
- JffNMS (monitoreando Windows, Linux y equipos de red)

SFlow es el "siguiente" protocolo, lo que se va a usar para reemplazar SNMP a corto o mediano plazo. Por ejemplo, estandariza todas las métricas que publica el agente, minimiza el tráfico necesario para enviar esas métricas (radicalmente respecto a cómo trabaja SNMP), y es seguro por arquitectura (única y exclusivamente transmite información, no hay manera de hacer que un agente SFlow reciba información desde la red, ya que no tiene servicios escuchando en puertos abiertos), por ende no hay posibilidad de explotar vulnerabilidad alguna en agentes SFlow, iniciando el ataque desde fuera del host. Etc. hay bastante más todavía, les sugiero googlear para sorprenderse.

JffNMS lo quiero mostrar porque - al menos en lo que leí hasta ahora - parece una buena opción a OpenNMS. OpenNMS está basado en Java y Postgresql, y JffNMS es software LAMP, así que me llama la atención la posibilidad de implementar un NMS (Network Management System), completo basado en PHP+Mysql (con la escalabilidad que ya sabemos que tiene la arquitectura de esas soluciones, por ejemplo, clusters MySQL).

Bibliografía
La bibliografía que estoy utilizando para los detalles más teóricos del curso (que no figuran ni de casualidad en howtos y tutoriales), son los de abajo. Espero poder repasar algunas partes clave de ese material mientras vamos instalando y recorriendo las instrucciones paso a paso. 

Agentes/Servicios SNMP
- Essential SNMP, 2nd Edition, OReilly

Ganglia
- Monitoring with Ganglia, OReilly

Cacti
- Cacti Network.Monitoring, Packt

Nagios, Icinga
- Nagios Core Administration Cookbook, Packt
- Nagios System and Network Monitoring, 2nd Edition, No Starch Press


La dinámica del curso
Voy a necesitar que cada alumno pueda correr una máquina Debian (virtual o física), en la cual va a poder ir aplicando las instrucciones paso a paso. De este modo, van a poder ir implementando las diferentes soluciones sobre el mismo sistema, y lo van a tener a su disposición para ir customizando y probando posibilidades por su cuenta.

No es lo que voy a recomendar, pero estoy bastante seguro que al haber instrucciones paso a paso, muchos van a decidir relajarse y tomar unos mates mientras dejan pasar el feedback visual del dictante (ese sería yo :-), de todos modos, las instrucciones quedan disponibles por escrito y van a poder implementar el software en cualquier momento.

Ya que vamos a tener múltiples servidores Debian instalados y funcionando, el laboratorio completo va a ser el contexto de implementación y cada server Debian un nodo a monitorear, en ese punto calculo que el tiempo ahorrado en instrucciones paso a paso, lo vamos a gastar en resolver problemas inesperados - que siempre ocurren - en determinadas implementaciones.


Bien, nos estaremos viendo dentro de poco, sldos.

Yaco

Expansión del trabajo remoto IT en Argentina

Las grandes empresas IT tercerizadoras en Argentina dan la impresión de ser la norma o la regla a la cual responde todo el mercado laboral IT argentino, como si fueran un patrón a seguir.

Sin embargo las más grandes tercerizadoras IT de Argentina solo llegan a ocupar a una parte relativamente pequeña del total de todos los empleados IT en el mercado. Así que mirando las ofertas laborales de Linkedin, Bumeran, y demás lugares donde se publica masivamente búsquedas laborales de grandes tercerizadoras IT, cualquiera puede pensar que la tendencia en el empleo es la única que se ve mayormente en esas búsquedas. Es un error.

El empleo remoto en IT crece sin parar desde hace un par de años y cada vez es más común encontrar amigos y ex-compañeros de trabajo que nos cuentan cómo están trabajando para empresas de Chile, para alguna consultora en Brasil o en Israel.

Cómo se accede a estas ofertas? Mayormente NO están disponibles en Linkedin ni en otros portales frecuentados por recruiters de grandes tercerizadoras IT. Hay que ir a buscar estas ofertas a los foros/listas de correo especializados de las herramientas, y con mucha menos frecuencia, se los encuentra en grandes portales de trabajo freelance.

De yapa, los recruiters de grandes tercerizadoras normalmente están baneados de participar en foros/listas de correo, por el volumen de spam que generarían, y las ofertas de trabajo (incluídas las de trabajo remoto), que se encuentran allí suelen ser de muy buen nivel (premium) y/o fáciles de verificar en reputación por crowdsourcing (preguntarle a los demás qué saben de X empresa que está buscando programadores, por ejemplo).


Por ejemplo, para buscar empleo remoto en Python o Ruby en Argentina (lo que quiere decir, poder trabajar en forma remota y en español en lo posible), el lugar indicado es acercarse a las listas de correo de PyAr (Python Argentina), y RubySur (Ruby en LATAM).

PyAr
http://listas.python.org.ar/listinfo/pyar

RubySur
http://groups.google.com/group/rubysur/subscribe

De seguro lo mismo puede decirse de listas de correo especializadas en PHP, Java, Security, Devops (Web Operations), Linux, Wintel, DB, Networking, etc. 

Por supuesto, EL requisito primario para un empleo remoto en IT es saber googlear tu camino hasta la oferta de trabajo.

Cómo medir el "cómo" y no el "qué" en performance laboral en IT

Métricas laborales IT

Uno de los problemas más usuales para los laburantes IT cada fin de año se da con la aparición de los resultados de los Performance Management (PM) Processes:

http://en.wikipedia.org/wiki/Performance_management
".. includes activities which ensure that goals are consistently being met in an effective and efficient manner."

"..incluye actividades las cuales aseguran que los objetivos son consistentemente alcanzado de modo efectivo y eficiente."


Performance Management "para la fábrica"
El modo estándar típico de ver qué tan bien labura un empleado, fuera de ámbitos informáticos es variado, una simplificación muy burda y rudimentaria se puede hacer reduciendo todo el análisis de PM a ver si el trabajo de un empleado responde positivamente a la respuesta que espera el "jefe" a la pregunta "¿Tu empleado hace lo que vos querés que haga?".

Es verdaderamente básico y por ende las mediciones típicas incorporan varios criterios más, a los efectos de "salpimentar" un poco de "realidad" el resultado del PM.

Como ven, el análisis PM típico, clásico, tradicional, se enfoca fuertemente en el "Qué", y no el "Cómo".

Es un enfoque de análisis de rendimiento de un empleado que se ha demostrado fuertemente incompatible con resultados que reflejen efectivamente la realidad de qué tan bueno y qué tan bien trabaja un empleado que realiza tareas altamente especializadas y no repetitivas. 

[En constrate positivo, ese mismo tipo de análisis funciona muy bien con tareas no especializadas y repetitivas, básicamente hablamos de "cantidades simples de algo, realizada en base a un plazo" > Cuantos jeans cosió un costurero en el año (desglose por mes), Cuantas chapas cortó un operario por día/semana/mes/año, etc. etc.]


La "fábrica" y los equipos de trabajo IT
Un craso error habitual en la medición de rendimiento de un empleado IT es que RR.HH. asocie "la fábrica" con el modo de trabajo de un equipo IT. Ello suele culminar con la adopción de un proceso de performance management que se orienta a la medición de "qué" hace el empleado, y no en el "cómo".

En el caso de IT, el "cómo" es vital para la mayoría de las tareas de nivel técnico de medio a alto. Por ejemplo: no es lo mismo que un buen developer escriba 20.000 líneas de código por año, de altísima calidad vs. un developer novato que escribe las mismas 20.000 líneas.

Muy similares ejemplos existen en otras especialidades IT complejas: project management, adm. de sistemas, adm. de redes, adm. de bases de datos, management IT, etc.



El problema al medir el "qué" en IT
El problema que suele tener RR.HH. para medir los "cómo" es que si bien la recolección de datos puede ser automatizada y/o sistematizada, la evaluación de performance suele quedar fuera de las áreas IT, es decir, el análisis queda en manos de personas que tienen menos entendimiento real/profesional de las tareas que los mismos empleados IT.

En el caso típico de la "fábrica" y sus tareas simples y repetitivas, no es mayor inconveniente, casi cualquiera de nosotros entiende mayormente los entresijos de cortar una chapa con maquinaria, al menos luego de una mínima introducción.

Sin embargo, es muy difícil - mucho pero muy difícil - que alguien que no escribió nunca un programa de computadora, entienda realmente el valor del código escritor por un developer, comparandolo con otro código de otro developer.

La solución es simple: la persona que evalúa el rendimiento de un trabajo IT especializado debe ser un especialista en ese trabajo, y debe tener un nivel técnico superior al de aquel que está siendo evaluado.

Más o menos es la misma idea de fondo que hay cuando vamos a estudiar un curso en la facultad: el profesor tiene que saber más que el alumno, sino los resultados no son fiables.


La medición del "cómo"

Las metodologías modernas de medición de rendimiento basada en el "cómo" se hace un trabajo (en vez de "qué" se hace en el trabajo), nacieron en los 70' de mano de algunas técnicas que fueron evolucionando y se diversificaron, justamente para adecuarse a los campos de especialización con los que estaban tratando.


Sabermetrics
http://en.wikipedia.org/wiki/Sabermetrics

Fue una de esas metodologías, y nació para ser utilizada para medir la performance de jugadores de equipos de beisbol. Al momento ya fue adaptada para medir la performance de practicantes de otros deportes ( http://en.wikipedia.org/wiki/APBRmetrics ).

La base de las metodologías de evaluación de performance basadas en el "cómo" es establecer cuales son las características deseables en un empleado. Esta parte es clave, se enfoca directamente en el "cómo" debería hacer algo idealmente un empleado, obviando sistemáticamente el "qué" hace el empleado.

Otra cuestión clave es detallar el mayor número posible de características deseables relativas al trabajo. La simplificación y la reducción de características están fuertemente contraindicadas, hay que intentar aumentar al máximo la clasificación en características especializadas que son deseables para el trabajo del empleado a la vez que se pone un especial énfasis en incluir características que no están exactamente relacionadas con el trabajo del empleado.

Un ejemplo burdo
Por ejemplo, en un developer C#, una característica "no relacionada" podría que fuera muy bueno configurando e instalando switches Cisco L2/L3, o que fuera muy buen pen-tester web en seguridad IT.

[Como ven, el listado de características deseables no se sale del marco de trabajo IT en gral., pero sí se sale completamente del centro habitual de considerar solo las características deseables propias del puesto de trabajo donde se desempeña el empleado específicamente (que es algo obligatorio de hacer en las metodologías tradicionales focalizadas en el "qué").]

Una vez que están definidas todas esas características, se puede realizar valoraciones numéricas con un tope, del 1 al 10 en cada característica. Luego, se busca correlacionar las puntuaciones individuales entre características complementarias según el marco de trabajo del empleado:

Por ejemplo, si un empleado conoce mucho de instalación de servidores Windows, y a la vez es buen developer C#, y a la vez se encarga de trabajar con un cliente que tiene pobremente configurados sus servidores Windows (y/o que está buscando actualizar la versión de los mismos, o migrar a una arquitectura más compleja/mejorada, etc.). Entonces este empleado se convierte en un "jugador valioso".

En contraste un buen developer (tan bueno en C# como el anterior), trabajando para el mismo cliente, no tiene tanto valor como jugador para el equipo...pero podría tenerlo en otro contexto!


La clave de las mediciones de performance por "cómo" vs. "qué" está en eso, encontrar las relaciones ocultas entre capacidades (skills), altamente especializadas, el contexto de trabajo y obtener información detallada y puntual que permita re-ordenar y re-asignar posiciones buscando lograr los mejores resultados.

Y eh aquí el objetivo: Las sabermetrics, usadas en el contexto del beisbol, permitieron cambiar de posiciones a jugadores, buscando optimizar las capacidades combinadas - sumadas - de todos los jugadores para obtener el máximo resultado posible para cada característica deseable necesaria en el trabajo del equipo.

Es decir, una vez que se obtiene los datos, se puede reorganizar la producción y las tarea del equipo IT, de modo tal que - por ejemplo - al colocar en una hoja de cálculo, de modo horizontal, de izq. a derecha...

Nombre de Empleado - Característica 1 - Característica 2 - Característica 3

...se obtenga el máximo posible en cada característica. 

De esta manera, si aparece por ejemplo un cliente con infraestructura basada en servers Linux y necesita developers C# y nuevos servers Windows, pero a la vez no va a dejar Linux, el equipo de trabajo disponga de todos los skills primarios - developers C# - y accesorios, tendientes a lograr los mejores resultados posibles en la asignación.


Recién luego de disponer de todos estos componentes para el análisis: características deseables, valoraciones por característica, y organización/contexto de la tarea del empleado (y posibles planes de reasignación/reoptimización de tareas), se podrá obtener una valoración real de los skills y del desempeño de un empleado en un equipo IT.

Por ejemplo, si tenemos un empleado A, administrador Windows, y lo ponemos a trabajar instalando aplicaciones para un cliente que usa servidores Linux, de seguro que su rendimiento va a ser bastante bajo. Si tenemos un empleado B, administrador Linux y lo ponemos a instalar aplicaciones para ese mismo cliente, va a descollar. 

La asignación es "instalar aplicación XXX en el cliente", a igual nivel de skills para instalar la aplicación XXX, el empleado B va a tener mucho más éxito y mejor performance que el empleado A.

Ahora si tenemos al empleado A trabajando con servers Linux, podríamos buscar ponerlo a trabajar en algun cliente que tuviera servidores Windows, y veríamos como despega su performance.

Administración de sistemas con Midnight Commander

El Norton Commander
http://en.wikipedia.org/wiki/Norton_Commander

Hacia 1988 estaba dando mis primeros pasos en IT, y había un pequeño team de proto-administradores con los que nos pasábamos todo el día desformateando diskettes (para ver qué tenían que los profes no querían que viéramos!), luego de un tiempo empezamos a necesitar desfragmentar y editar los filesystem a nivel de bloque, y descubrimos unas herramientas tremendas, las Norton Utilities. Así nos enteramos que existía el nc (Norton Commander, la evolución del primitivo "NCD" Norton Change Directory), resulta que los profes usaban usaban esta herramienta asiduamente (todos teníamos la misma pregunta "¿qué herramienta DOS permite que la cierres apretando una sola tecla?", la tecla era F10 por cierto), y no nos querían contar cual era, la cerraban rápido cuando aparecían los alumnos y no podíamos ver cual era, nos decían algo como "no les va a servir, es muy avanzada". En fin. Sí que servía, en vez de tener que estar tipeando comandos DOS, con nc podíamos simplemente teclear una o dos veces y realizar tareas 
habituales de adm. de archivos, pero a una velocidad mucho mayor.


El administrador de archivos Midnight Commander (mc) 
mc es básicamente una copia fiel del viejo nc de DOS pero para Linux, con características avanzadas y tuneadas al año 2000 (y no más allá de esos años, no se preocupen, no hace falta más).

Avance rápido a 1999, empecé a usar Linux de corrido por fin (luego de estar tonteando desde el 96'), ya podía hacer la mayoría de las cosas de las que hacía en Win98, pero me faltaba una herramienta como el Explorador de Archivos, rápida, efectiva; no había nada así de bueno y gráfico en Linux todavía, así que me puse a ver esta herramienta modo texto, mc, que ya conocía, pero no le había prestado atención:

http://es.wikipedia.org/wiki/Midnight_Commander
http://www.atareao.es/ubuntu/software-para-tu-ubuntu/midnight-commander-un-gestor-de-dos-paneles-para-el-terminal/

Me resultaba un tanto shockeante estar en la consola y estar usando una herramienta gráfica (creo que mc era la única que conocía, todavía había muy pocas herramientas usando Ncurses - http://es.wikipedia.org/wiki/Ncurses ).


Arma secreta nro. 1: mc para sysadmins
Mc es ciertamente una herramienta top level para mi workflow como sysadmin. Cuando la descubrí, empecé a utilizarla principalmente para ahorrarme el tener que aprenderme uno o dos comandos (find, ln, chown y chmod recursivos), cuando estaba apurado tratando de "activar" mi placa de sonido.

mc no tuvo un equivalente en modo gráfico hasta muchos años después, con la aparición de Krusader (www.krusader.org), que fue el primer adm. de archivos que podía replicar exactamente el workflow usual dentro de mc (y por ende su utilidad).


Más allá de las obvias ventajas, hace unos años atrás noté que algunos sysadmins en Corrientes dejaban de "mostrar" mc durante las charlas en eventos, o cuando me estaban mostrando algo en algun Linux, directamente no lo usaban, ni sabían que existía en gral. Es insufrible (y muy antiproductivo), esperar durante una charla por ejemplo, que cualquiera tipee "a mano" su camino con el comando "cd" entre, por ej. /var/www/sitio/imagenes, luego a /var/www/cgi-bin, luego a /etc/apache2, luego de vuelta a /var/www/sitio, y cometiendo 5 errores de tipeo en el camino (al final los tipos terminaban abriendo una interfaz gráfica, abrían luego 5 consolas, y se metía a cada directorio que iban a usar). En mc podés tener dos directorios abiertos, uno en cada panel, y usar dos (2) teclas para llegar rápidamente a cualquier directorio, sin necesidad de levantar los dedos de las teclas < y >.


De hecho tuve varios conocidos y compañeros de trabajo que eran sysadmins con un año o dos de experiencia de trabajo real, y no conocían mc. El origen de este issue parece ser el que estas personas se habían iniciado como sysadmins con algunos cursos, principalmente basados en Ubuntu, y en esos cursos nadie les mostró que existía mc (ni idea del por qué). Los mismos sysadmins novatos, al no estar familiarizados con el ambiente de administración (www.planetsysadmin.com por ejemplo), ni siquiera tenían idea de que existiera algo tan útil como mc.

En realidad, un sysadmin experimentado puede replicar parte de la funcionalidad de mc, e inclusive tener la misma velocidad al trabajar con archivos (al trabajar, pero NO al tener que moverse y explorar directorios continuamente). En cambio, para los sysadmins novatos mc es una facilidad que no deberían dejar de aprovechar, ya que normalmente están a años de poder trabajar con la misma precisión y velocidad que les brinda mc desde la interfaz gráfica modo texto.


Hay varios motivos por los cuales uso mc para administrar sistemas:

- Bajar la tendencia a errores humanos accidentales (solamente por esto vale la pena usar un file manager gráfico en consola),

- Velocidad de navegación por los filesystems, usando una característica bastante esotérica de activar: "navegación en modo lynx", básicamente podés navegar el filesystem usando solamente las teclas de flechas < y >, y así "subir" y "bajar" por el arbol de directorios, muy rápido (es 100% imposible moverse en consola tan rápido con el comando cd, como uno se puede mover con el modo lynx en mc, no importa si tenés 1 año o 10 años de administrador de sistemas),

El modo de navegación lynx no estuvo activado por default en ningun mc que haya instalado desde 1999 en adelante, lo tenés que configurar, según la versión de mc: 

(en versiones viejas, la instalan Debian/Ubuntu) F9 > Configuracion > y en la ventana "Configuración" tildar - con la barra espaciadora - "Navegación al estilo Lynx"

(en versiones nuevas, la instalan Fedora/Opensuse) F9 > Paneles > y en la ventana "Opciones de los paneles" tildar - con la barra espaciadora - "Navegación al estilo Lynx"

[* tip: activen el "drop-down menu", así al apretar F9 los menúes aparecen sin necesidad de hacer F9 y luego flecha abajo ]

- Awareness: sin necesidad de estar corriendo "pwd" y "ls" cada dos o tres comandos "cd", en todo momento sé, sin duda alguna en qué directorio estoy ubicado y qué archivos y directorios existen allí (no necesito tampoco correr ls -la para ver permisos, fechas, y propietarios de los archivos, en mc los tengo a la vista todo el tiempo),

- Velocidad y facilidad de administración (por ej. si tengo que elegir 14 archivos de entre 35 para moverlos de un directorio a otro: me sitúo en el directorio origen, tab, me situo en el directorio destino, tab, vuelvo al directorio origen, y con la tecla INS selecciono los archivos que quiero mover; 14 de 35 no parece mucho? Si tengo que mover 200 archivos de entre 400, es un trabajo de 10 minutos, incluso si los nombres no son secuencias - tipo file1,file2,file3, etc.)


- mc te permite tener el filesystem local en un panel, y en el otro podés conectarte a otro linux (vía SSH, FTP) o Windows (Samba). Así que las tareas de adm. de archivos remotos se facilitan y aceleran de modo exponencial. 

Respecto a esto último ví varias veces como sysadmins ya con un par de años de experiencia montando LAMPs y cosas similares, se logueaban vía SSH a un server remoto y se ponían a configurar un server FTP para poder copiar archivos a ese server desde un cliente FTP gráfico (porque tenían que trabajar con un par de centenares de files y sin nombre contigûos). Se sorprendían al ver que luego de un "apt-get install mc", podíamos directamente usar mc para conectarnos al server vía SSH y elegir a mano los files en el server de origen y copiarlos fácilmente al server destino (mc brinda la clásica barrita de progreso, y tiene facilidades extendidas, ya que cuando mc encuentra un file con el mismo nombre en el directorio de destino da opciones, y luego continúa con las tareas en ejecución, lo mismo si encuentra algun problema de acceso y no puede escribir/leer algun file/directorio).


Para tareas habituales y avanzadas de adm. de archivos en Linux y desde una consola, básicamente no encontré una manera más rápida, efectiva y segura de hacer muchas (un montón) tareas en poco tiempo y con alta precisión (más aún cuando trabajo con centenares a miles de archivos y tengo que copiarlos/moverlos).

En Debian/Ubuntu

apt-get install mc

En Fedora / Red Hat

yum install mc

En Opensuse:

zypper in mc


Arma secreta nro. 2: mcedit

En una consola tipear "mcedit", apretar F9, y acceden al menú de este editor de texto. Viendo lo que se puede hacer, se pueden imaginar la utilidad de este editor y su facilidad de uso.

Un plus tremendo de mc, es su editor de texto, mcedit. Disponible típicamente haciendo F4 (Editar), sobre un archivo. Tenemos resaltado de sintaxis para Bash cuando codeamos scripts, copiar/pegar texto (se banca muy bien el workflow de: "copiar texto en Windows (desde un notepad)" > "pegar en un archivo abierto en mcedit con la tecla INS"). Y muchas cosas más.

El otro día estaba trabajando con Nano, y un log me indicaba que tenía que editar desde la línea 39 hasta la 54 de un archivo de configuración. Nano no tiene feedback visual de en qué linea estoy ubicado, mcedit sí la tiene (arriba, se ve la cant. de líneas del file, y la línea actual, que cambia si subimos o bajamos por el file), cambié a mcedit hice ALT+l, escribí el nro. de línea 39, salté ahí, luego ALT+l, escribí 54 y ya ví todo el bloque de texto a editar (luego hice F3 y - sin tener que alejar el dedo de F3 - marqué el bloque con las teclas de flechas, F3 de vuelta y terminé de marcar el bloque, luego con F8 lo borré).

En realidad si sabés usar bien Nano, más o menos tenés casi todo lo básico (entrar, editar, guardar y salir), y un poco más (CTRL+g), que también tiene mcedit.

Pero en mcedit tenés feedback visual (eleva el awareness y baja la tendencia a errores humanos) - en Nano no tenés feedback visual directamente - , resaltado de sintaxis para un par de lenguajes (se puede desactivar/activar desde la GUI), nros. de línea a la izq. de cada línea, líneas actuales en la barra superior, menues visuales sin necesidad de recordar/revisar a cada rato los atajos de teclado, etc. 

Es un misterio para mi por qué los cursos para sysadmins novatos enseñan Nano (como editor fácil de usar, pero tenés que memorizar muchos shortcuts), y no enseñan mcedit (tenés un menú gráfico a mano, ahí están las opciones y herramientas del editor, y si te gustan los shortcuts, tambien los tenés a la vista), incluso aunque a veces enseñen algo de uso de mc.

Siempre recomiendo mcedit por sobre Nano, más allá de que mcedit tiene más funcionalidad que Nano, me parece un buen equilibrio entre Nano (editor básico), y vi (editor avanzado). Deberías probarlo y ver.


En Ubuntu, Nano viene como editor por defecto, podeś cambiar a mcedit (luego de instalar mc), con:

sudo update-alternatives --config editor


Links:

Midnight Commander / MC Tutorial
http://www.trembath.co.za/mctutorial.html

"Linux no sirve" y frases similares: un caso de falta de training

Ayer me enteré que un sysadmin conocido tiene entre sus frase favoritas "Linux no sirve para nada", "Linux es una porquería" al mismo tiempo que administra varios servers Linux.

No puedo evitar entender que es una de esas "situaciones de training". Falta de training.

Cuando llegué a HP hace un par de años no sabía administrar clusters Windows Server, ahora lo sé, y es un lujo. Un par de clicks y tenés todo de un lado (failover), otro par y tenés todo del otro de vuelta (failback). Fue difícil? cuando no sabía nada de clusters Windows Server, sí, porque no sabía como se hacía.

La diferencia entre difícil y fácil es la cantidad de training que se tiene sobre una herramienta. Añade mucho la experiencia a que algo sea más fácil aún. No hay tal cosa como es "muy difícil de manejar y por eso no sirve". Si una herramienta "no sirve" es porque se la está usando mal.

Ejemplos
Por ejemplo, Windows Server tiene casos de uso prioritarios, y le gana a cualquier otro OS sin necesidad del mínimo análisis (podés calcular el TCO, pero igual te sale todo más "barato" usar win - en plata, recursos, etc.):

- AD (Active Directory), cuando tenés que manejar muchas workstations Windows (un escenario casi esperable en el 99,99 % de las empresas/organizaciones de hoy)

- Cuando ya tenés licenciado un SQL Server, un app usa SQL Server de backend; con opción a usar otra DB (Oracle por ej.), pero te saldría más caro licenciar Oracle, que licenciar una nueva versión de Windows Server + SQL Server (que incluso puede venir con un discount por el upgrade).

etc.

Linux es una herramienta de nivel industrial hace mucho tiempo. Las empresas y organizaciones lo usan desde años para sostener sus infraestructuras informáticas, sin mucho debate sobre si sirve o si no sirve, lo usan y funciona, punto. Microsoft inclusive tiene un supuesto deployment de cerca de 50.000 servers Linux (sin sumar los últimos que añadió para centralizar la infraestructura de Skype recientemente).

http://arstechnica.com/business/news/2012/05/skype-replaces-p2p-supernodes-with-linux-boxes-hosted-by-microsoft.ars

Los ejemplos son innumerables, pero Linux se usa (y lo uso), diariamente para sostener tantas más innumerables infraestructuras alrededor del mundo, y en ámbitos de misión crítica como empresas de transporte (aerolíneas, trenes, etc.), Bancos, etc. etc.

Para el resto del planeta, no es como que Linux no sirva, no sé si me llego a explicar.

Es todo cuestión de training, ahora mismo estoy haciendo el training oficial de Novell CLP (Certified Linux Professional, para SLES11 - SuSe Linux Enterprise Server 11), junto a muchos novatos en Linux y los ví pasar de preguntar "qué es una consola" y "cómo paso de la GUI - X - a la consola", a discutir casos de uso probables en que el esquema de permisos de usuario estándar+sudo puede usarse sin recurrir a RBAC (soportado en SLES11 y en Linux en gral.).

Linux es difícil de administrar? sí, si no sabés administrarlo (no es ironía), igual que lo es Windows Server si no sabés administrarlo. Alguno de los dos OSes es "difícil" en gral.? En realidad no, para nada, y son muy simples de manejar en realidad. Sí hay muchas apps que son muy difíciles de deployar (hay ejemplos para ambas plataformas), y la solución es la misma, training, leer y entrenarse, probar en ambientes de testing, y si es muy complicado, darle el tiempo apropiado (regulando ese tiempo al nivel de skillset de los administradores).

Nubes Privadas para dummies

Este artículo comenzó igual que la mayoría de los problemas interesantes, con una simple pregunta

¿Por qué iniciarse en infraestructuras de cloud privada?.

Desde el punto de vista del especialista en infraestructura, solo puede llamar a una respuesta "Qué? Todavía no comenzaste a implementar una private cloud?"

Sí, es así de necesario.

En el fondo es bueno

La cuestión de fondo es que las private clouds son una solución a diversos problemas de infraestructura que han estado dando vueltas en los datacenters desde poco tiempo después de que se hizo el avance - o retroceso, es cuestión de opiniones - tecnológico de grandes mainframes propietarios a "pequeños" servers (primero el hard propietario de Digital, Sun, etc. y luego a Intel, AMD, ahora inclusive yendo a ARM).

Si todavía tienes pocos servers en tu datacenter, este es el momento de empezar a ganar insight en infraestructura de private clouds. De ese modo tendrás listo el skillset y el expertise para el momento en que llegues a los problemas que se desprenden de usar servers individuales, luego sumarles storage externo (SANs y similares), luego empezar a virtualizar servers físicos en hipervisores y luego empezar a utilizar manejadores de hipevisores.

Una cloud privada es justo el tipo de software que puedes utilizar junto con los manejadores de hipervisores o para reemplazarlos por completo (depende de la solución y del producto) y resolver los problemas que todavía no mencioné (de hecho).

¿Qué ganamos con más trabajo?

Parecería obvia la respuesta, pero vamos a los sucios detalles.

La ganancia de utilizar private clouds son muchas, en principio puedo referenciar las listas de problemas de las páginas de datasheets de los varios vendors de soluciones de virtualización, que es donde vas a encontrar el 100% de los problemas que resuelve una infraestructura virtualizada.

Luego de eso, para qué querrías complicarte la vida con el montaje de una private cloud? La respuesta es simple: no es complicarte, si ya llegaste al último paso y estás usando manejadores de hipervisores en tu día de oficina típico como sysadmin, ya estás a las puertas de:

- Necesitar manos extra ($$$ en más sysadmins), y/o

- Necesitar más tiempo de trabajo propio ($$$ y !#$% a granel, compitiendo simultáneamente por tu valiosa atención)

- En lo técnico, tus máquinas virtuales van a empezar a necesitar un trabajo semi-artesanal de babysitting muy similar a las viejas épocas donde se parcheaba y compilaba manualmente código fuente de Apache para varias decenas de servers. No, no hablemos de kernels, algunos sysadmins ganan un rápido estado de agitación de solo recordar los días de administración manual de kernels Linux :-D

Lo que no anda nos encontró (y no queríamos)

En definitiva, las nuevas capacidades de la infraestructura virtual (y todo lo que hay "abajo"), han creado un monstruo: la facilidad para crear nuevos servidores tan rápido como pueda clickear "aceptar" el sysadmin.

Eso no es bueno, definitivamente, es bueno para el negocio, es bueno para la infraestructura, es bueno para los developers, etc. pero no es bueno para el sysadmin.

Hay decenas de componentes anidados en una infraestructura virtual, que incluso si fue muy bien diseñada (las chances van al contrario), pueden fallar. Ahora ¿por qué digo que "tu" infraestructura virtual está mal diseñada? No lo dije (lee de vuelta), sino que la mayoría de las "infras" van a terminar virtualizadas "por las malas", esto es también conocido como "implementación paulatina", con muchos SPOF (Single Point of Failure), acechando detrás de cada esquina del datacenter.

No se añade a esa sopa de SPOFs un capa más de administración de máquinas virtuales promiscuamente generadas a golpe de llamadas telefónicas de management, un rápido capacity planning (y un feliz "sí jefe, se puede"), y un par de clicks casi no muy meditados.

Esa infraestructura virtual va a requerir - más - tiempo de administración, que no va a estar disponible si estás ocupado creando y borrando máquinas virtuales.

La solución es una private cloud.

Metiendo las manos en el barro

La idea central de la private cloud es ocuparse de crear una interfaz entre los usuarios de la infraestructura virtual, "clientes" a partir de ahora y los recursos de la infraestructura (virtual), "servicios" desde ahora.

Cualquier private cloud software que se precie de llamarse así brinda una interfaz lo suficientemente gráfica para que un "cliente" pueda conectarse a ella, elegir de un menu (ahí hay trabajo de configuración para el sysadmin!), y luego crearse para sí mismo una reluciente y nueva máquina virtual, con toda clase de características técnicas muy interesantes, pero con características no técnicas aún más interesantes:

El servicio del software de private cloud incorpora al autoservicio de creación de máquinas virtuales no solo la extracción quirúrgica de la necesidad de comunicaciones telefónicas y de correos y la correspondiente lluvia de chequeos y autorizaciones, sino también incorpora a la administración automática (configurables por el sysadmin), diversas políticas muy útiles, por ejemplo:

- Cuanto tiempo de vigencia tiene la máquina virtual antes de ser automáticamente borrada

- Será borrada de inmediato? o solo apagada y dejada en reserva, por cuanto tiempo?

- El personal de helpdesk puede crear nuevos servers o clientes virtuales de prueba para software de oficina, con tremendas restricciones a nivel de comunicaciones de red con el resto de la infraestructura interna.

- El personal de sysadmin (esos somos nosotros), podrá crear la cantidad de máquinas virtuales que necesite (quiera), sin importar que se seleccione la cantidad total de RAM disponible en el hipervisor (es broma :-).

- El personal de desarrollo tendrá determinados privilegios extendidos, para crear y guardar determinada cantidad de servidores virtuales (de modo de poder ir probando diversos baseline de configuración para una aplicación).

- etc. etc.

La idea de mostrar un par de políticas no es abarcar todas las capacidades del software de private clouds, sino que se vea qué tipo de trabajo administrativo se está automatizando - esta palabra es adorada por RR.HH. y jefes hoy en día - y mejorando sustancialmente ("si es automático, no puede haber error humano", ya sé, ya sé...está muy sobrevalorada la idea).

Veamos un par de detalles técnicos; hoy disponemos de OpenNebula y OpenStack, software opensource (licencia Apache ambos), que a diferencia de la mayoría del software de clouding privativo permite administrar varios/muchos tipos de hipervisores, incorporando nuevos tipos con regular frecuencia. Traducción al español: desde tu soft de cloud privada puedes usar al mismo tiempo máquinas virtuales (hipervisores) KVM, Vmware, Hyper-V, Xen, Virtualbox y probablemente nuevos tipos (y versiones no retrocompatibles con viejos hipervisores del mismo tipo!!! alguien dijo escalabilidad horizontal?), de hipervisores que vayan apareciendo.

Las posibilidades en lo técnico se amplían al poder utilizar clouds híbridas: múltiples tipos de máquinas virtuales, locales y remotas, que incluye las de proveedores públicos de clouding como Amazon y probables futuros proveedores de clouding basados en estándares (impuestos por los productos opensource como OpenNebula y OpenStack).

Conclusiones

Esto es básicamente una explicación a vuelo de pájaro, así que no hay tanto material para sacar conclusiones.

Lo básico es que si no usas private clouds, lo harás porque:

- te pedirán que lo hagas,

- eventualmente lo vas a necesitar,

- de hecho puede que no lo llegues a necesitar (o que nadie se haya dado cuenta que hace falta :-), y en realidad verás que te soluciona suficientes problemas para que querer usarlas.

- y claro, es innegable, son tremendos powertoys para el sysadmin con un poco de sangre caliente en las venas.

- pensandolo mejor, sí las vas necesitar, es mejor que empieces ahora.

3er. Clase del sysadmin training

Issues

El training tuvo su tercer clase el viernes pasado y debido al ámbito de conocimientos amplios y el tiempo limitado de dictado tuvimos un par de issues:

- Con un solo dvd de instalación, la review de instalación de cada trainee se ajustó a la posibilidad de ir pasando el dvd en mano uno por uno, lo que retrasó bastante la tarea. Por lo positivo, los distintos traineés tuvieron asistencia personalizada encarando la instalación de SLES11 (en una máquina virtual), y todos instalaron sin inconvenientes el SO, lo que nos dice que el recorrido realizado en la primera clase tuvo buenos niveles de comprensión en la gente.

- Al momento de explicar el scheduler CRON, ya estábamos escasos de tiempo restante en la clase según mi planificación, así que resolví que en vez de transmitirles a los traineés interactivamente las capacidades de CRON, decidí hacer una intro rápida, y continuar en la tercer clase, ya con templates que puedan utilizar para ir conociendo el uso de CRON sin tener que descubrir sus features desde el man hasta la entrada CRON ya configurada.

- La intro teorica a la administración de paquetes fue probablemente la 2da. más fuerte luego del análisis del arranque del sistema, el inicio de init y su progresión hacia los runlevels. En la siguiente clase planeo repetir la historia de los runlevels: aunque el comienzo tuvo mucha teoría, vamos ver distintas tareas habituales en una práctica extensiva.

La clase

Tema 2 - continuación

En conjunto con los issues, se dió la 3er. clase, arrancando con la continuación de las explicaciones teóricas del uso práctico de los runlevels y servicios (el cómo y porqué de inittab, los S y K de los links simbólicos y de ahí en adelante), y siguiendo con un práctica que recorría las distintas tareas usuales en el manejo de varias tareas de administración en el arranque de Linux:

- parámetros de booteo en Grub (cómo elegir runlevels y nociones de modificación de otros parámetros en Grub),

- servicios por defecto en runlevels, comprensión y administración del tema (si un servicio está activado, aún así puede no estar corriendo, etc.)

- nociones de creación de scripts de runlevels en el contexto de compatibilidad - asegurada - con el estándar LSB.

En los prácticos ya estuvimos recorriendo transparentemente y usando mc, Yast, X y pseudo-terminales varias, los archivos de configuración en /etc, /boot/grub, etc. No deja de sorprenderme positivamente la capacidad de aprendizaje de todos novatos del training, que evidentemente solo necesitan una buena explicación teórico-práctica para, por ejemplo, pasar directamente desde no conocer para qué sirve CTRL+ALT+F1/2/3/4/5/6, a comentar (#), entradas en /etc/inittab para deshabilitar esas posibilidades, y saltar desde X hasta terminales y de vuelta, mientras en las demos vía cañon voy saltando desde Yast a consola. Varios ya se cansaron de CTRL+ALT..y de vuelta y trabajan directamente sobre terminales Gnome...enhorabuena.

Tema 3

La explicación comenzó un poco lenta, tengo que reconocerlo, la realidad es que organizar en pocas palabras un mensaje complejo y extenso como explicar simultáneamente qué es un paquete, sistemas de administración de paquetes y sus características idénticas independientemente de la distribución, requiere hablar con suficiente precisión. Después de unos 5 minutos, de explicar cómo se construyen paquetes y - repitiendo - la noción de dependencia de paquetes, me puse a explicarles cómo se igualan funcionalmente los distintos sistemas de administración de paquetes para Linux, haciendo incapié en distros concretas (SLES, RHEL, CentOS, Ubuntu, Debian), y en yum y apt. Luego de eso ya pasamos a las tareas típicas de administración de paquetes y repositorios (siempre hablando en lenguaje común y compatible con las varias distribuciones ya mencionadas).

Para finalizar incluí una explicación consciensuda de criterios de selección de repositorios, explicando paso a paso, las consecuencias legales y prácticas de la inclusión de repositorios no soportados en el listado de repositorios oficialmente soportados en una distro comercial/empresarial. Luego de esto, los trainees ya tienen la información necesaria para decidir la pertinencia de incorporar o no software, actualizado o no, no soportado oficialmente a una instalación particular (empresarial o no, oficialmente soportada o no, empresarial o home, etc.).

Luego de lo anterior pasamos directamente a las demos en cañon usando Yast (que la mayoría de los trainees repite en sus instalaciones locales al modo de prácticos rápidos), donde recorrimos las GUI de administración de repositorios y paquetes, haciendo un racconto de capacidades y tareas usuales en la administración de paquetes, cabalmente representadas en las GUIs de Yast y que podemos encontrar en otras GUIs en diferentes distros.

El manejo de paquetes y repositorios en modo texto quedó pendiente para la próxima clase, sin embargo varios ya han tomado nota de algunos comandos rpm utilizados durante el tema 2 (rpm -qa | grep -i paquete, etc.), por lo que ya realizaron un contacto comprensivo-práctico en una situación real de uso de skills de adm. de paquetes.

De momento estoy haciendo la review del avance del training y viendo si la próxima clase se podría incluir un recuento de skills, para ver qué aprendieron a hacer hasta ahora y para qué les sirve; tal vez el recuento de skills se haga al final del training porque si bien los trainees tienen en mano mucha información específica sobre un par de componentes habituales en tareas de administración, les está faltando un poco más de contexto, por ejemplo, agregar skills de administración de almacenamiento, así la posibilidad de parametrizar Grub se puede sumar a skills de recuperación de discos.

Otra cosa que estoy viendo es si ya hago el lunes una introducción a LVM, este tema no figura como parte del temario, pero les prometí a los trainees que en vista de un poco de tiempo disponible, tenía ganas de dar este tema. Creo que el manejo de volúmenes es la clave para entender una de las principales características que hacen de Linux/*nix una opción por defecto al realizar deployments importantes.

También figura como parte de las promesas de temas adicionales - siempre ajustable esto a la disponibilidad de tiempo - los temas de administración remota (VNC, SSH, túneles de protocolos sobre SSH, redireccionamiento de puertos, etc.), y configuración básica de DNS.

3Trex Sysadmin Linux Training Sessions - Corrientes 2009

CURSO CANCELADO por razones de causa mayor.

Si quieren pueden seguir leyendo del tema en próximos posteos.

Gracias por su interés a todos los que se acercaron y estén atentos a nuevos cursos.

---------------------

Estoy contento de presentarles en conjunto con 3Trex Tech Solutions las

3Trex Sysadmin Linux Training Sessions - Corrientes 2009

Inscripciones abiertas...

Vacantes disponibles:
16 sillas totales, en 2 turnos de 8 sillas cada uno.

Inicio del Training:
Al momento en que se concrete un mínimo de 6 reservas por turno

Cantidad de Reservas al 2009-09-24 16:45 hs.

• Turno Lunes: 0 (cero) reservas.
• Turno Martes: 1 (una) reserva. 7 sillas libres.

Las preinscripciones en línea se reciben en la dirección de correo yacolinux@yahoo.com.ar, en el teléfono:

3TX SRL (3Trex Tech Solutions)
+549 3783 428758

Alternativamente puedes pre-inscribirte online aquí.


Luego de confirmadas, se les informará por correo los datos de contacto y la dirección de dictado del curso y se les solicitará que hagan efectiva la inscripción allí en el plazo de 2 días hábiles, luego de los cuales perderán su preinscripción.

Pueden chequear días y horarios de dictado más abajo (ya figuran al momento), muchas gracias a los interesados y esperemos encontrarnos semanalmente mientras se van convirtiendo sesión a sesión en capaces administradores de sistemas Linux.

Gracias por su interés.

Dardo Valdez


Precios
El costo del curso quedó definido en $150 mensuales por persona. Se obtiene un lugar con acceso a una pc por persona.

La reserva de lugar se hace pagando $50 y se confirma pagando la totalidad de los $150, 5 días antes de comenzar el curso.

Descuentos

* Opción Acompañante :
Los asistentes que ya tengan un lugar pueden tomar un acompañante, con el que compartirán la pc durante el cursado, con un costo de $100 mensuales adicionales. El costo quedaría en un total de $250 mensuales para los dos asistentes al curso.

* Opción Notebook :
Hay descuentos para alumnos que decidan trabajar exclusivamente desde sus notebooks. En este caso el costo queda en $130 mensuales. Vale aquí la opción Acompañante con costo ya mencionado de $100 adicionales, con un total de $230 mensuales en este caso.

Carga horaria y modalidad de dictado
El training garantiza un mínimo de 16 hs. de capacitación por módulo y 48 hs. de capacitación totales con el training completo.

Se contempla el dictado horas extra de dictado de clases, que podría llevar el training hasta un total de 24 hs. de capacitación por módulo y 72 hs. de capacitación después de realizado el training completo.

Las clases extra se dictarán a criterio del dictante del curso según considere necesario.

La carga horaria total será de 2 hs. de clase semanales durante 6 meses, con 2 clases extra de 2 hs. cada una mensuales y opcionales.

En cada módulo se dicta por completo los temas incluídos en el temario.

Los tres módulos del curso se dictarán de corrido con un intervalo de entre 2 y 4 semanas a darse durante las fiestas de fin de año y los primeros días de enero.

Los horarios de clases confirmados son:

- Martes de 20.00 hs. a 22.00 hs.
- Lunes de 20.00 hs. a 22.00 hs.

Las clases extras si fuera necesario darlas se podrían dar, con previo acuerdo con los asistentes, tanto los jueves como los viernes, de 20.00 hs. a 22.00 hs.


Día a día
Durante el training voy a ir comentando en el blog el desarrollo de las sesiones y las distintas experiencias que vamos a ir compartiendo con los asistentes.


El Trainer y Organizadores
La persona que dictará el training es Dardo Valdez, ver referencias en:
http://www.linkedin.com/in/dardovaldez

Mi acompañante en este proyecto, 3Trex Tech Solutions tiene una trayectoria de años en mercado local como proveedor de soluciones de desarrollo, ellos aportan el marco y la infraestructura para llevar a la realidad las Linux Sysadmin Training Sessions.


Nivel del Training
El nivel de las Sysadmin Training Sessions es intermedio a avanzado.

El training está orientado a profesionales de informática, administradores de sistemas, administradores de red y en general personas con experiencia previa en sistemas operativos de nivel operador avanzado.

Las Sysadmin Training Sessions no son un curso de nivel inicial y se da por sentado que el asistente maneja cómodamente los conceptos de sistemas operativos y redes implícitos en las temáticas a tratar.


Requisitos para los candidatos
* Experiencia previa : Se recomienda tener experiencia extensiva en el uso de Linux como sistema operativo de uso diario y hogareño.

* Entrevista previa : El dictante aspira conocer de antemano a los asistentes y por ello se solicita una entrevista previa antes de iniciar el training para asegurar que le va a ser de utilidad, a la vez que ello no va influir en la calidad del dictado para con los demás alumnos.

* Idioma inglés : Es muy recomendable para los asistentes poder leer fluídamente texto en inglés (no hace falta nivel de conversación).

* Publicación : Los asistentes al training tendrán el requisito adicional de dar su consentimiento expreso para la publicación online del nombre del asistente en un listado a publicar en el sitio de 3TX Tech Solutions y en Sysnotas Blog.


Enterprise Training
Las Sysadmin Linux Training Sessions están disponibles como servicio de capacitación empresarial. Para contactarse por este interés, dirigir consultas a yacolinux@yahoo.com.ar.


Cómo es el training
Las sesiones de training serán teórico-prácticas, el asistente recibirá previo a la clase el material de teoría, las guías de trabajos práticos se irán poniendo a disposición por clase.
La práctica se dará paso a paso y tema por tema del curso, buscando integrar un ideal de 50% de teoría y 50% de práctica.


Servicios para los asistentes
Los asistentes al training ganan acceso a una lista privada, solo accesible con membresía, donde podrán realizar consultas técnicas directas al dictante. También podrán tratar con el dictante online cuando esté disponible, temáticas y dudas técnicas relativas al training.


Feedback anónimo
Los asistentes recibirán un nombre de usuario y contraseña a repartir al azar, con esos datos ganarán membresía en una lista de feedback anónimo, donde podrán subir sus críticas y requerimientos a los organizadores del training.

Esta lista estará disponible para lectura pública desde Internet durante todo el curso recogiendo las críticas y el feedback de los asistentes al training.

Las requisitorias directas de los asistentes también son bienvenidas y serán atendidas en la medida de lo posible.


El lugar de dictado
El lugar seleccionado para el dictado del curso es la sede de 3TX Tech Solutions, una locación céntrica en Corrientes, Capital con dependencias con aire acondicionado y baños a disposición de los asistentes.

Se dispondrá en el lugar de insumos como: agua caliente, café, té, yerba, leche y azúcar.

3TX SRL (3Trex Tech Solutions)
+549 3783 666897
+549 3783 428758
Belgrano 1768 | CP W3400ABH | Corrientes | Argentina

Documentación oficial del curso
La documentación oficial del curso está en idioma inglés:

Pro Linux System Administration, Apress
Copyright © 2009 by James Turnbull, Peter Lieverdink, Dennis Matotek
ISBN-13 (pbk): 978-1-4302-1912-5
http://www.apress.com/book/view/1430219122

De este libro proviene la estructura primaria del training y excepto 3 temas, el resto de los temas serán dictados subtema por subtema incluído del capítulo respectivo del libro. De hecho, los nombres de los temas del curso son una traducción del libro de los nombres de capítulos y temas incluídos.

Como documentación de apoyo se utilizará un libro focalizado en Suse Linux Enterprise Server, también en idioma inglés:

The Definitive Guide to SUSE Linux Enterprise Server, Apress
Copyright © 2006 by Sander van Vugt
ISBN-13: 978-1-59059-708-8
http://www.apress.com/book/view/9781590597088


Documentación en español
La documentación en español va a estar disponible por tema a dictar, sin dejar de documentar ninguno, en forma de lecturas recomendadas de diferentes fuentes, con copia electrónica local disponible para los asistentes.

Las lecturas recomendadas van a ser un acercamiento conceptual al 90% de lo disponible en el libro en inglés, con las obvias posibles diferencias al ser información de fuentes distintas.

Por ejemplo para el tema 2 del módulo 1 del training "Trabajando con usuarios y grupos" (pág. 110 de la documentación oficial), las lecturas recomendadas en español son:

(en orden según pertinencia con la documentación oficial)

* Implementación de Servidores GNU/Linux, Alcance Libre, 2009
12 (puntos 1, 2 y 3) Cómo crear cuentas de usuario (pág. 116 a 119)
* Administración Avanzada de GNU/Linux, 2004
5.5 Usuarios y Grupos (pág 192 a 197)

La guía de lecturas recomendadas va a estar disponible a medida que transcurra el training y previo al cursado de los distintos temas.

Los libros en español que usaremos durante el training son:

- Implementación de Servidores GNU/Linux, Alcance Libre, 2009
- Administración de Sistemas Linux, Anaya, 2007
- Linux Server. Los Mejores Trucos, Anaya, 2006
- Administración Avanzada de GNU/Linux, 2004
- Unix y Linux. Guía Práctica, 3ra. Edición, Ra-Ma, 2004


Distribución y portabilidad de skills
La distribución a utilizar en el training será Suse Linux Enterprise Server - SLES 10 SP2.

La documentación oficial del training abarca explicaciones teóricas aplicables a cualquier distribución, ello también se da en los procedimientos prácticos de consola (CLI). Por otra parte, la documentación oficial está focalizada en Red Hat Linux Enterprise (RHEL) Server y Ubuntu que se refleja en algunos procedimientos vía GUI para RHEL y en explicaciones particulares de consola para Ubuntu.

Hemos seleccionado la distribución y la documentación de modo que los asistentes adquieran un experiencia basada en Red Hat y Ubuntu, a la vez que aprenden y trabajan sobre SLES, de ese modo, transparentemente van a ir adquiriendo la noción de portabilidad de las skills entre distribuciones, y cuales pueden ser sus mínimas diferencias.

La documentación basada en "Pro Linux System Administration" también provee la ventaja de organizar temáticamente las skills de administración, a diferencia de otra documentación focalizada en la distribución, tal como es la documentación secundaria basada en el libro "The Definitive Guide to Suse Linux Enterprise Server".


Temario Oficial del Training:

Módulo 1

Instalación de Linux
- Recomendaciones hardware
- Instalación básica de Linux

Usuarios y Grupos
- ¿Qué sucede cuando te logeas?
- Trabajando con usuarios y grupos
- Controlando el acceso a tu host
- Más acerca de sudo

Administración de paquetes
- Introducción a la adm. de paquetes
- Adm. de paquetes en SLES Linux
- Compilando desde código fuente

Redes y Firewalls (1)
- Introducción a las redes y networking

Administración de almacenamiento y recuperación de desastres
- Básicos de almacenamiento
- Usandos Sistemas de Archivos
- RAID
- LVM (Logical Volume Management)
- Recuperación desde fallas


Módulo 2

Servicios SQL y Web
-Apache Web Server
- MySQL
- Instalando sitios web
- Squid Cache

Montaje de soluciones Linux
- Requerimientos
- Soft precompilado
- Puertos y protocolos
- Permisos, usuarios y grupos
- Montaje
- Ping, telnet para availability testing
- Caso Squid

Linux Básico
- Acceso Remoto
- Sistema y archivos
- Trabajando con archivos

Inicio y servicios
- Entendiendo el adm. de booteo Grub
- ¿Qué sucede luego de bootear?
- Administrando servicios
- Agendando servicios y comandos con cron

Redes y Firewalls (2)
- Resolución de problemas de networking
- Netfilter e Iptables
- Como funcionan Netfilter/iptables

Servicios de Infraestructura
- NTP
- DNS
- DHCP
- SSH
- FTP

Monitoreo de Rendimiento y Optimización
- Checkos Básicos de Estado
- Herramientas Avanzadas
- Optimización de Rendimiento


Módulo 3

Logeo y monitoreo
- Logeo
- Monitoreo

Bash Scripting
- Técnicas básicas
- Conceptos avanzados
- Recetas Utiles

Compilación de kernel

Compartición de archivos e impresión
- Samba
- Servidores de impresión

Resguardo y Recuperación
- Planificación de Recuperación de Desastres
- Proceso de Backup
- Backups de Red
- Usando Rsync
- Usando Bacula

Servicios de Correo
- Cómo funciona el correo electrónico
- Configurando Servicios de Correo
- Extendiendo la Configuración de Postfix
- Combatiendo Virus y Spam
- Configurando IMAP y POP3
- Usuarios y Dominios Virtuales

Servicios de Directorio
Servicios de Directorio
- ¿Qué es LDAP?
- Implementación
- Instalación
- Configuración.
- Administración LDAP y herramientas
- Integración con otros servicios


Temario en inglés
Los títulos y temas coinciden con capítulos y temas del libro "Pro Linux System Administration", documentación oficial del training.

Los títulos y temas en español se documentan de distintos ítems en el libro de apoyo y en la documentación en español.


Módulo 1

Instalación de Linux
- Recomendaciones hardware
- Instalación básica de Linux

Users and groups
- What Happens When You Log In
- Working with Users and Groups
- Controlling access to Your Host
- More about sudo

Package Management
- Introduction to Package Management
- Package Management on Red Hat Linux
- Package Management on Ubuntu
- Compiling from Source

Networking and firewalls (1)
- Introduction to Networks and Networking

Storage Management and Disaster Recovery
- Storage Basics
- Using your File Systems
- RAID
- Logical Volume Management
- Recovering from Failure


Modulo 2

Web and SQL Services
-Apache Web Server
- MySQL
- Installing Websites
- Squid Cache

Montaje de soluciones Linux
- Requerimientos
- Soft precompilado
- Puertos y protocolos
- Permisos, usuarios y grupos
- Montaje
- Ping, telnet para availability testing
- Caso Squid

Linux Basics
- Remote Access
- Files and Systems
- Working with files

Startup and Services
- Understanding the Grub Boot Loader
- What Happens after you boot?
- Managing Services
- Scheduling services and commands with cron

Networking and Firewalls (2)
- General Network Troubleshooting
- Netfilter and Iptables
- How Netfilter/iptables Work

Infraestructure Services
- NTP
- DNS
- DHCP
- SSH
- FTP

Performance Monitoring and Optimization
- Basic Health Checks
- Advanced Tools
- Continuous Performance Monitoring
- Performance Optimization

Logging and Monitoring
- Logging (syslog)
- Monitoring (nagios)

Networking with VPNs
- Our example network
- Introducing OpenVPN
- Troubleshooting OpenVPN


Modulo 3

Bash Scripting
- Técnicas básicas
- Conceptos avanzados
- Recetas Utiles

Compilación de kernel

File and Print Sharing
- Samba
- Print servers

Backup and Recovery
- Disaster Recovery Planning
- Backup Process
- Network Backups
- Using Rsync
- Using Bacula

Mail Services
- How Does E-Mail Work?
- Configuring E-Mail
- Extending Postfix Configuration
- Combating viruses and spam
- Configuring imap and pop3
- Virtual Domain and Users

Directory Services
- What is LDAP
- Implementation
- Configuration
- LDAP Management and Tools
- Integration with Other Services