Socat – Socket concatenator!

socat is a Multipurpose relay (“is a more complex variant of netcat. It is larger and more flexible and has more options that must be configured for a given task” – Wikipedia):

http://www.dest-unreach.org/socat/

Get it here: socat-1.7.2.0.tar.gz

Examples of use:

  • socat - TCP4:www.domain.org:80
    transfers data between STDIO (-) and a TCP4 connection to port 80 of host http://www.domain.org. This example results in an interactive connection similar to telnet or netcat. The stdin terminal parameters are not changed, so you may close the relay with ^D or abort it with ^C.
  • socat - SSL:server:4443,cafile=server.crt,cert=client.pem
    is an OpenSSL client that tries to establish a secure connection to an SSL server. Option cafile specifies a file that contains trust certificates: we trust the server only when it presents one of these certificates and proofs that it owns the related private key. Otherwise the connection is terminated. With cert a file containing the client certificate and the associated private key is specified. This is required in case the server wishes a client authentication; many Internet servers do not.
    The first address (‘-‘) can be replaced by almost any other socat address.
  • socat - UDP4-DATAGRAM:224.255.0.1:6666,bind=:6666,ip-add-membership=224.255.0.1:eth0
    transfers data from stdin to the specified multicast address using UDP. Both local and remote ports are 6666. Tells the interface eth0 to also accept multicast packets of the given group. Multiple hosts on the local network can run this command, so all data sent by any of the hosts will be received by all the other ones. Note that there are many possible reasons for failure, including IP-filters, routing issues, wrong interface selection by the operating system, bridges, or a badly configured switch.

See more examples in www.dest-uconcatenatornreach.org

Deux ex virtual machine

El siguiente texto no se trata de un alegato a favor de los sistemas de virtualización a nivel OS como OpenVZ y VServer y en contra de los sistemas de virtualización completa como Xen, VMware, VBox, KVM …
No, no se trata de eso, si no de que, en principio,  para un entorno homogéneo y con pocos recursos hardware o con servicios que, a priori, sea difícil saber como van a evolucionar en el tiempo con respecto al consumo de los recursos HW, el uso de uso de estos contenedores se me antoja personalmente mucho más práctico y versátil que las otras dos alternativas (no virtualización y virtualización completa).

***

La empresa Pérez y Familia son una PYME de medio tamaño (unos 50 trabajadores). La misma, tiene un importante Departamento de Informática formado por un gurú Unix (top 9 en el
ranking mundial de freaks) y un becario a media jornada. Por supuesto, tienen una partida presupuestaria de 1200 chocomonedas para todo el año destinadas principalmente a mantener la familia numerosa del señor que mantiene fiel y cuasiquereligiosamente la máquina del café. El Dep. de Informática en su CPD, ubicado inmediatamente debajo de la mesa del becario, tiene una pequeña infraestructura de servidores:

  • (A) 2 PentiumIV con unas a cuantas tarjetas de red a modo de Router corporativo en HA
  • (B) 1 PowerEdge 1890 DualCore que compraron cuando los inicios de la empresa
  • (C) 2 X PCs clónicos 8core con 8GB de RAM comprados recientemente en MarcaMedia a petición explícita del Dep. de Informática

Al departamento de informática se le da vía libre para instalar los SO bajo su antojo, siempre y cuando las horas extra caigan de su lado. Así que como casi una excepción empresarial, se forman su propia taifa dentro del reino de los Pérez. Por otro lado, la empresa poco a poco, a lo largo de su tiempo de vida fue incorporando herramientas informáticas a sus procesos de trabajo:

  • Al principio, los de Informática montaron sus servidores que sólo sirven para consumir ciclos de procesado y algunas cosas freakies más:
    • Un servidor DNS, que si un DHCP, y un Snort en A
    • Que si un OpenVPN en A
    • Que si unos repositorios en B
  • Luego, vinieron las herramientas de apoyo al proceso:
    • Gestor documental en B
    • CRM en B
  • Tiempo más, llegaron más herramientas que se fueron incorporando:
    • La intranet
    • La extranet
    • El streamer de música
    • El repositorio de código
    • El inventario y el sistema de monitorización de servicios
    • y un largo etc …

Todo esto se fue metiendo en B y C como se pudo. A mayores, cada cierto tiempo algo o alguién pide la evaluación de un software para ver si es rompedor. Lógicamente, estas pruebas se hacen en los entornos de testing (aka, el portátil del becario, el suyo el que se compro con la subvención de estudiante matriculado). Todo esto va generando el escenario, preparando el clímax de nuestra historia, el preludio del ansiado momento que nos llevará al clímax y servirá de justificante al desenlace.

Y llegó el momento, Dirección exige la instalación del ERP UltimatumTotalNG. Este está pensado para RedHat4.0 si y sólo con versiones concretas de ciertos tipos de base de datos y demás y Dirección, que es experta en toma de decisiones técnicas como Franco lo era en la Teoría de la Relatividad de Einstein, no quiere ni oir de hablar de otras distros o versiones que no sean las que el apuesto y sofisticado consultor externo ha sugerido para el UltimatumTotalNG.

Llegados a este punto los del Dep. Informática (o sea el becario y el gurú Top10) se  encuentran de repente contra la espada y la pared. Ya que ellos decidieron en el pasado, allá por el tiempo de la patata (esta es buena, a ver quien la pilla), elegir Debian como OS y lo fueron actualizando hasta Squeeze ni más ni menos. ¿Que pasará? ¿Será el fin de nuestros héroes? ¿Como podrán salir de esta encrucijada? Veamos cómo actúan:

– ¿Que podemos hacer? dijo el Gurú Unix.

– Bien, analicemos la situación, dijo el becario. Tenemos muchos servicios instalados pero realmente estos no están consumiendo siempre los recursos del sistema (50 clientes no son muchos clientes al fin y al cabo). Con las máquinas que tenemos bien podemos aguantar todos estos servicios. No obstante, tenemos un problema con los procesos de actualización: No es la primera vez que por motivo de la actualización de un servicio concreto, se ven afectados otros servicios independientes y nos cae un bronca encima.

– Bien, podríamos usar virtualización. Movemos todos los servicios que están en C” a C’ y preparamos esta máquina para albergar máquinas KVM y así vamos migrando todo sucesivamente (empezando por la RedHat del ERP) hasta tener todo virtualizado.

– Perfecto, crack!

(tiempo que transcurre en liberar C” de servicios)

– …. Bien, ahora ¿como dimensionamos las imágenes? ummm hombre dale medio core a esta MV que no se suele usar muy a menudo.
– Nooo, estás loco!, si ahí va a ir el CRM, entre las nueve y nueve y media los de marketing se ponen a hacer consultas como locos. Ya sabes que no son muy cuidadosos a la hora de ejecutar los filtros. Se nos van a echar encima, dale por lo menos dos cores …

(después de 5 horas más)

– Venga, créame otra MV para este servicio.
– Oops!, creo que tenemos todos los recursos físicos asignados.
– Pero ¿como es posible?, si antes estábamos dando el servicio perfectamente con el mismo número de servidores!!!.
– Si, pero también es cierto que teníamos en la misma máquina el CRM y el Gestor documental y estos, a pesar de usar todos los recursos físicos, uno tenía sus cargas de trabajo por la mañana y otro por la tarde por lo que la máquina estaba bien balanceada. Con la reserva de recursos de las máquinas hemos partido los recursos a la mitad, con lo que otros servicios menores que también se corrían sobre dicha máquina se han quedado sin recursos para una nueva MV donde alojarlos.

… (todo los demás transcurrido es una sucesión de culpas, reproches, #epicfails, #workarrounds, excusas, horas extras y #fatalities) …

Finalmente, los informáticos fueron despedidos. El gurú escribió un libro y se retiró con el dinero que ganó y el Becario, frustrado por su primera experiencia laboral, diseño un sistema de jails para Linux llamado VUltimatum con un funcionamiento muy similar a lo que conocemos como VServers, Zones, Jails, VZ, Containers. Debido a esto, es altamente reconocido en su gremio profesional y, a mayores, tiene un trabajo digno como reponedor del Carrefour. Podría decir que la vida le sonríe.

I prefer OS-virtualization than full-virtualization

Since some time ago I’m clear about next question: ¿what advantages do you see to OS-virtualization (like OpenVz or VServer) solutions against Full-virtualizacion solutions like (KVM or Xen)? And, this is my official answer for this question:

  • Performance. OS-virtualization have got a lower penalization than the other one with respect to the physical machine resources. In OS-virtualization this is certainly a low different against a real machine:
  • We can make checkpoints before software updates. Very interesting to no missteps and ease basesystem upgrading.
  • Simplicity. When we need isolate a particular software components, we can use a VZ (OS-virtualization) as same way that a chroot environment. For example, I need to run a particular software architecture that supports only 32-bit on a cocrete AMD64 server.
  • You do not need a disk image on which to install the guest operating.
    • No headaches about sizing/resizing images
    • You can set disk quotas consumption if necessary
    • You can access to files directly accesing to the instance VServer/OpenVZ from the base host. For example, backing up is only needed on the base host, not on virtual host. Another example, you could share directories as Debian’s packages pool among multiple virtual host reducing the disk consuption (like Solaris Non-Global Zones).
  • If our environment is homogeneous, in OS point of view, and assuming we’re living in a world GNU/Linux like,  really we do not need that our virtualization system is able to virtualize BSD, SystemV, Windows and others OS
  • Physical resources can be reserved by virtual machines, but also can be left as sharing. This is all virtual machines use the resources on demand.

Historia de una migración de sistemas

Hace año y medio me embarqué junto con mis colegas de departamento en la ardua empresa de migrar nuestra plataforma de servidores empresariales hacia una plataforma full-virtualized basada en OpenVZ, KVM y ProxMox. Escribo esto con la ventaja de hacerlo postumamente a la finalización de la misma.

La decisión de iniciar esta migración tiene su punto inicial en el anuncio de Debian de marcar como deprecated el uso y soporte oficial de VServer a partir de Debian 6.0

http://lwn.net/Articles/357623/

El caso es que de aquella estábamos de aquella realizando un uso habitual  de la tecnología de VServer para los servicios de cliente y internos de la empresa
bajo las premisas:

El sistema base lo más limpio posible y homogéneo” y “Máquina virtual por servicio

(para evitar incompatibilidades entre distintos software bajo la misma
instancia de SO, reducir solapamientos de servicios …)

La alternativa que valoramos fue el paso a un sistema mixto de OpenVZ y KVM gestionado por una aplicación web ad hoc usando libvirtd y la justificación de esta alternativa era la siguiente:

  • Fácil migración de VServer a OpenVZ (3 simples pasos)
  • En OpenVZ tenía dos modos de gestión de la red: red virtual y dispositivo virtual
    • El uno tenía la ventaja de ser rápido y sencillo de configurar y más restrictivo en cuanto capacidades del guest
    • El otro permitía multicast/broadcast y usado conjunto bridges ofrecía una configurabilidad  muy seductora. Por ejemplo, arranque por DHCP 🙂
    • Ambos modos permitía la posibilidad de cargar reglas de IPtables en el guest
  • El wiki/soporte documental del proyecto OpenVZ era mucho mayor, claro y organizado que el de VServer
  • OpenVZ ofrecía la capacidad de migración de nodos en caliente.
  • Los rendimientos de OpenVZ frente a VServer eran bastante equiparables
  • Libvirtd había incorporado recientemente soporte para OpenVZ
  • Libvirtd tenía sus respectivas implementaciones del API de C para Ruby y Python
  • KVM era bastante cómodo de usar
  • KVM empezaba a dar señales de robustez para AMD64
  • KVM nos permitiría la evaluación de otras plataformas a las cuales no dedicabamos tiempo debido a lo engorroso de reinstalar máquinas físicas:  BSDs, Solaris sin el uso de Zones, Windows …
  • Era asumible la construcción de un software basado en Libvirtd + OnRails para la gestión homogénea de lo que sería nuestra nueva plataforma

No obstante, un punto crucial en nuestro camino fue el descubrimiento del proyecto ProxMox. Este hayazgo, facilitó enormemente el camino ya que, una vez analizado y probado, nos dimos cuenta que cubría a la perfección nuestras demandas como usuarios y administradores de la plataforma de virtualización y esto implicaba que el desarrollo de una frontend de gestión ya no sería necesario. Mientras tanto, las evaluaciones que estabamos realizando con respecto a OpenVZ eran muy positivas con respecto a VServer:

  • Migración on live funcionaba realmente.
    • El sistema probado fue entre nodos independientes (sin storage común)
    • La migración se realiza en caliente usando ssh,public_keys y rsync.
    • El cambio de nodo se hace sin aparente caída del servicio
  • Sistema de snapshots funcional.
  • Política de Red
    • Venet (virtualización de la red). Funciona, es eficiente y nos permitió virtualizar segmentos de red (muy interesante en nuestro caso ya que hasta la fecha usabamos el mismo segmento de red para servicios que deberían estar aislados a nivel 2 y sólo accesibles a nivel 3 por enrutado). Venet nos permitió simular este comportamiento sin añadir hardware de red adicional.
    • Veth (bridge). No era nada fuera de lo normal con respecto a lo que se hacía con KVM y con Xen. Nos vino muy bien para los entornos de desarrollo ya que da la sensación de entorno real, y también en los entornos controlados de producción donde necesitamos, por ejemplo, multicast (como clusters Tomcat).
  • Gestión de recursos:
    • Un poco confusa antes de leerse la documentación (muy buena, por cierto), pero muy simple de gestionar luego.
    • Límites de uso de páginas de memoria, unidades de CPU, bloques de disco, número de procesos, nº PTYs, buffers TCP, buffers socket …, quotas, memoria del kernel, y otros parámetros de configuración como red, dominio …
    • Finalmente, también se podían quitar los límites y dejar que las máquinas compitieran entre ellas por recursos del sistema real.

Finalmente, después 1 año y 4 meses, entre VZs, puedo decir que la migración a VZ fue un éxito en líneas generales. Cierto que tuvimos unos cuantos altercados en todo el proceso que nos costaron ciertos dolores de cabeza, pero en líneas generales el resultado final ha merecido la pena y ya llevamos más o menos desde marzo del año pasado (2009) trabajando a pleno  rendimiento con la plataforma virtual.

A grandes rasgos y a modo conclusiones, resumiré los hitos conseguidos:

  • Abstracción de red. Con Venet + iproute2 + iptables, e implementación de redes “virtuales” por encima de una única vlan.
  • Desolapamiento entre servidores físicos y servidores virtuales
  • Sencillo y fiable sistema de snapshots basado en vzdump y LVM2snapshots
  • Aceptable sistema de appliances (plantillas de OS para usar)
  • Pasamos de largo del centenar de máquinas virtuales corriendo en 15 nodos reales  y aún con cierta holgura de crecimiento mayor.
  • Hemos reducido a trivial la problematica de restauración tras pérdida y/o corrupción de datos;
  • Hemos reducido a trivial las restauración y/o disponibilidad de servicio a pesar de averías hardware.
  • Hemos reducido a trivial la clonación y replicación de servicios tanto para tareas  eventuales de actualizaciones delicadas que requieren de un checkpoint como para  la creación de escenarios réplica de servicios en funcionamiento los cuales poder llevar a ferias y demostraciones (a modo branch de los sistemas en “producción”)
  • Sencillo y fiable interfaz de administración web y acceso mediante consola VNC.
  • y lo más importante …  todo 100% libre y sin coste asociado al producto.

My custom settings for Zabbix Agents

Since some time ago, I’m used working with ZABBIX systems – as server as agent, proxy … . Now, I don’t going to explain all the fantastic features about this software in this post. In this post, I will only enumerate my preferred ZABBIX Agent settings and my best values for each one.

  • Server=zproxy01.mon.mng.amz.coorp.com

    List of comma delimited IP addresses (or hostnames) of ZABBIX servers.
    No spaces allowed. First entry is used for sending active checks.
    Note that hostnames must resolve hostname->IP address and
    IP address->hostname.

  • ServerPort=10051

    Server port for sending active checks

  • Hostname=php611.int.amz.coorp.com

    Unique hostname. Required for active checks.
    This hostname must correspond with the name set on ZABBIX Server for this
    host

  • ListenPort=10050

    Listen port. Default is 10050.

  • ListenIP=8.8.8.8

    IP address to bind agent
    If missing, bind to all available IPs

  • StartAgents=5

    Number of pre-forked instances of zabbix_agentd.
    Default value is 5.
    This parameter must be between 1 and 16

  • RefreshActiveChecks=90

    How often refresh list of active checks. 2 minutes by default.
    This check list are sending by the ZABBIX server/proxy.
    See in zabbix.com
    to known more about Zabbix Agent’s protocol.
    This value can’t be lower than 60 seconds.

  • DisableActive=0

    Disable active checks. The agent will work in passive mode listening server.

  • EnableRemoteCommands=1

    Enable remote commands for ZABBIX agent. By default remote commands disabled.

  • DebugLevel=3

    Specifies debug level:

    • 0 – debug is not created
    • 1 – critical information
    • 2 – error information
    • 3 – warnings
    • 4 – information (default)
    • 5 – for debugging (produces lots of information)
  • PidFile=/var/run/zabbix-agent/zabbix_agentd.pid

    Name of PID file

  • LogFile=/var/log/zabbix-agent/zabbix_agentd.log

    Name of log file.
    If not set, syslog will be used

  • LogFileSize=5

    Maximum size of log file in MB. Set to 0 to disable automatic log rotation.

  • Timeout=15

    Spend no more than Timeout seconds on processing
    Must be between 1 and 30

  • UserParameter=http.basicaction,wget -t 2 -T 10 -q -O – “http://server:80/StatusInfo.php” | grep -e “App:”

    Format: UserParameter=key,shell_command
    Note that shell command must not return empty string or EOL only

More info:

ClusterSSH: A GTK parallel SSH tool

From some time ago, I’m using a amazing admin tool named clusterSSH (aka cssh).

With this tool (packages available for GNU/Debian like distributions, at least), we
can interact simultaneously against a servers cluster
. This is very useful,
when your are making eventual tasks in similar servers
(for example, Tomcat Cluster nodes, … ) and you want execute the same intructions
in all of them.

cssh

My config (~/.csshrc) file for cssh is look like to the default settings:

auto_quit=yes
command=
comms=ssh
console_position=
extra_cluster_file=~/.clusters <<<<<<<<<
history_height=10
history_width=40
key_addhost=Control-Shift-plus
key_clientname=Alt-n
key_history=Alt-h
key_paste=Control-v
key_quit=Control-q
key_retilehosts=Alt-r
max_host_menu_items=30
method=ssh
mouse_paste=Button-2
rsh_args=
screen_reserve_bottom=60
screen_reserve_left=0
screen_reserve_right=0
screen_reserve_top=0
show_history=0
ssh=/usr/bin/ssh
ssh_args= -x -o ConnectTimeout=10
telnet_args=
terminal=/usr/bin/xterm
terminal_allow_send_events=-xrm ‘*.VT100.allowSendEvents:true’
terminal_args=
# terminal_bg_style=dark
terminal_colorize=1
terminal_decoration_height=10
terminal_decoration_width=8
terminal_font=6×13
terminal_reserve_bottom=0
terminal_reserve_left=5
terminal_reserve_right=0
terminal_reserve_top=5
terminal_size=80×24
terminal_title_opt=-T
title=CSSH
unmap_on_redraw=no
use_hotkeys=yes
window_tiling=yes
window_tiling_direction=right

The  ~/.clusters file is the file which defined the concrete clusters (see man ):

# home cluster
c-home tor@192.168.1.10 pablo@192.168.1.11

# promox-10.40.140
promox-10.40.140 10.40.140.17 10.40.140.18 10.40.140.19 10.40.140.33 10.40.140.17 10.40.140.18 10.40.140.33

# kvm-10.41.120
kvm-10.41.120 10.41.120.17 10.41.120.18

When I want work with c-home cluster, we execute de cssh as following:

# cssh c-home

In addition, I have written a tiny python script that automatized the cluster lines generation. This script is based in pararell executed ICMP queries. Thats is cool when your servers are deploying in a big VLAN or the number of them is big. In this cases, we can execute my script to found the servers.

# ./cssh-clusterline-generator.py -L 200 -H 250 -d mot -n 10.40.140 >> ~/.clusters

# mot-10.40.140-range-10-150
mot-10.40.140-range-10-150 10.40.140.17 10.40.140.19 10.40.140.32 10.40.140.37

Finally, … the script:

import os
from threading import Thread
from optparse import OptionParser

class Thread_(Thread):
def __init__ (self,ip):
Thread.__init__(self)
self.ip = ip
self.status = -1
def run(self):

res = os.system(“ping -c 1 %s > /dev/null” % self.ip)
res_str = “Not founded”

self.status = res

threads_=[]
ips = “”

parser = OptionParser()
parser.add_option(“-n”, “–net”, dest=”network”, default=”10.121.55″,
help=”Class C Network”, metavar=”NETWORK”)
parser.add_option(“-L”, “–lowrange”, dest=”lowrange”, default=”1″,
help=”Low range”, metavar=”LOW”)
parser.add_option(“-H”, “–highrange”, dest=”highrange”, default=”254″,
help=”High range”, metavar=”HIGH”)
parser.add_option(“-d”, “–deploy”, dest=”deploy”, default=”Net”,
help=”Deploy name”, metavar=”DEPLOY”)
parser.add_option(“-v”, “–verbose”, dest=”verbose”,
default=False, action=”store_true”,
help=”Verboise mode”)

(options, args) = parser.parse_args()

low_range = int(options.lowrange)
high_range = int(options.highrange)
net=options.network
deploy_id = options.deploy
verbose=options.verbose

for i in range (low_range, high_range+1):
ip = net + “.” + str(i)
h = Thread_(ip)
threads_.append(h)
h.start()

for h in threads_:
res_str = “Not founded”
h.join()
count=0

if h.status == 0:
count = count + 1
res_str = “FOUNDED”
if verbose:
print “Looking host in %s … %s” % (h.ip, res_str)
ips += h.ip + ” ”

if verbose:
print “Finished word. %s host founded” % count

print “”
print “# ” + deploy_id + “-” + net + “-range-” + str(low_range) + “-” + str(high_range)
line = deploy_id + “-” + net + “-range-” + str(low_range) + “-” + str(high_range) + ” ” + ips
print line