SaltStack: Uso de grains

¿Os leísteis ya la entrada sobre SaltStack de primeros pasos con Salt? Si no lo habéis hecho, antes de seguir, este es un buen momento para hacerlo aquí.
En esa primera entrada explicábamos como dar de alta un nuevo equipo en el servidor, aceptar su clave y hacer una primera prueba de concepto. Hoy vamos a ver un nuevo punto en la arquitectura de SaltStack: los grains.
Los grains son los datos del sistema del cliente SaltStack. Estos datos son los que nos indican el tipo de sistema operativo, el dominio al que pertenece, la IP, RAM, versión y un largo etc.
Para obtener la salida de grains, podemos hacerlo tal que así,
shell> salt '*' grains.items
  biosreleasedate: 01/01/2006
  biosversion: Bochs
  cpu_flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr...
  cpu_model: QEMU Virtual CPU version 1.1.2
  cpuarch: x86_64
  defaultencoding: UTF-8
  defaultlanguage: en_GB
  domain: mydomain.local
  fqdn: test.server.local
  gpus:
      {'model': 'GD 5446', 'vendor': 'unknown'}
  host: sei
  id: sei.mydomain.local
  ip_interfaces: {'lo': ['127.0.0.1'], 'eth0': ['10.1.100.15']}
  ipv4:
      127.0.0.1
      10.1.100.15
  kernel: Linux
  kernelrelease: 3.9-1-amd64
  localhost: sei
  lsb_distrib_codename: jessie
  lsb_distrib_description: Debian GNU/Linux testing (jessie)
  lsb_distrib_id: Debian
  lsb_distrib_os: GNU/Linux
  lsb_distrib_release: testing
  manufacturer: Bochs
  master: salt
  mem_total: 2012
  nodename: sei
  num_cpus: 1
  num_gpus: 1
  os: Debian
  os_family: Debian
  oscodename: jessie
  osfullname: Debian
  osrelease: testing
  path: /sbin:/usr/sbin:/bin:/usr/bin
  productname: Bochs
  ps: ps -efH
  pythonpath:
      /usr/bin
      /usr/lib/python2.7
      /usr/lib/python2.7/plat-x86_64-linux-gnu
      /usr/lib/python2.7/lib-tk
      /usr/lib/python2.7/lib-old
      /usr/lib/python2.7/lib-dynload
      /usr/local/lib/python2.7/dist-packages
      /usr/lib/python2.7/dist-packages
      /usr/lib/pymodules/python2.7
  pythonversion: 2.7.5.final.0
  saltpath: /usr/lib/python2.7/dist-packages/salt
  saltversion: 0.16.2
  serialnumber: Not Specified
  bash: /bin/bash
Estos datos los podemos emplear dentro de la lógica de Salt, como veremos un poco más adelante y también para diferenciar los equipos en los que queramos ejecutar algo.
Si os acordais, para lanzar una prueba, hacíamos los siguiente
shell> salt '*' test.ping
Con ello, ejecutábamos la función test.ping en todos los equipos que estuviesen aceptados en el servidor. Usando grains, podemos hacer una selección de los mismos sobre la que ejecutar los comandos. Para ello tenemos la opción -G, que la seguimos de la opción por lo que deseamos diferenciar.
shell> salt -G 'os:Debian' test.ping
shell> salt -G 'cpuarch:x86_64' test.ping
Como podéis observar, en la primera se ejecuta el comando sobre todos aquellos equipos con sistema operativo Debian, mientras que en el segundo ejemplo, sobre todos aquellos equipos de arquitectura x86_64.

La entrada SaltStack: Uso de grains la puedes leer en Puppet Linux.
Leer más

Combinación de teclas en consola

Hace ya muchos años que el trabajo día a día lo desarrollo desde la consola de GNU/Linux y aún así no deja de sorprenderme. Hoy quiero compartir con vosotros un atajo de teclado, que personalmente descubrí de casualidad, y que me parece francamente interesante.
La combinación de teclas es ALT + Delete y sirve para borrar palabras completas en consola. Cuando estás tecleando un comando o una ruta y te has equivocado, esta combinación te permite borrar rápidamente toda la palabra.
shell> /home/javier/test.sh
                      # Presionamos ALT + Delete
shell> /home/javier/test
                      # Presionamos ALT + Delete
shell> /home/javier/
                      # Presionamos ALT + Delete
shell> /home/
Aunque puede parecer una chorrada, desde que la conozco me resulta muy cómoda.

Y tú, ¿qué combinaciones sueles usar? Déjalas en comentarios!
Leer más

Actualización de spamassassin en Zimbra

Uno de los procesos que trae Zimbra en el core es spamassassin. Como su nombre indica, es un software que se encarga de analizar y filtrar todos los correos que entran en el servidor y según origen, destino, contenido, etc. clarificarlos como aptos o como correo no deseado. La verdad es que da muy buenos resultados y es un buen software, pero como siempre lo importante es tener las reglas actualizadas. Unas reglas actualizadas pueden evitar muchos problemas de spam masivo.
Vamos a ver por lo tanto cómo actualizar las reglas de spamassassin.
  1. Entrar como usuario zimbra
    Es el primer paso que debemos de llevar a cabo. Accedemos al sistema y cambiamos nuestro usuario al de administrador de Zimbra.
    shell> su - zimbra
    
  2. Actualizar las reglas
    Zimbra incluye spamassassin y también un pequeño script que se encarga de descargar y actualizar los ficheros que sean necesaraios. Para ello, simplemente,
    shell> /opt/zimbra/zimbramon/bin/sa-update -v \
           --updatedir /opt/zimbra/conf/spamassassin \
           --allowplugins \
           --refreshmirrors
    
  3. Reiniciar el demonio
    Una vez terminada la actualización simplemente hacemos un restart del daemon zmamavisdctl de Zimbra y nos aseguramos de que quede arrancado y no tenga ningún problema.
    shell> zmamavisdctl restart
    shell> zmamavisdctl status
    

La entrada Actualización de spamassassin en Zimbra la puedes leer en Puppet Linux.
Leer más

Chrome: Deshabilitar el buscador en la pantalla de inicio

Desde la versión 29 de Google Chrome, éste trae una atractiva nueva página de inicio como la que encabeza esta entrada. Realmente tiene la misma información que siempre y a mayores está integrado el buscador de Google.
No es que me importe demasiado ni me moleste, pero en equipos no muy potentes, todavía no encuentro la explicación, dicha página es complicada de procesar. Esto hace que tarde en arrancar el navegador más de lo deseado. En el otro lado, está la idea de quiero sacarla por que no me apetece tenerla ahí, perfectamente respetable.
Así que ya sea sacarla para aligerar un poco el navegador o por que no te gusta, vamos a ver cómo hacerlo.
Lo primero que necesitamos hacer es abrir una nueva pestaña e ir a la URL chrome://flags/. En esta página, hay que tener cuidado, ya que vamos a tocar parámetros de configuración muy primitivos del navegador, por lo que ten cuidado con lo que tocas. Desde aquí no nos hacemos responsables.
Si eres de los que sigue, entonces busca la entrada "Habilitar la API ampliada de Instant Mac, Windows, Chrome OS" y cambia el valor por defecto que trae e Inhabilitado, tal como se muestra en la imagen lateral.
Tras modificarlo, reinicia el navegador y ya podrás comprobar que ya no está el navegador integrado y vuelves a tener la vista de las páginas más visitadas.
Por cierto, si eres de los que tiene el navegador en inglés, no te preocupes, el procedimiento es el mismo y la clave a buscar es "Enable Instant Extended API Mac, Windows, Chrome OS".

Los usuario de GNU/Linux estamos de enhorabuena, no tenemos que hacer nada, esta actualización no nos afectó :-)
Actualización: Desde la versión 33 de Google Chrome los usuarios de GNU/Linux también tenemos esta nueva pantalla de inicio por defecto.
Actualización: En truco para deshabilitar la visualización de dicha pantalla, desde la versión 33 deja de funcionar y todo el mundo debe verlo (ver comunicado oficial de Google aquí).
Leer más

Zimbra: Purgando automático de mensajes

Aunque hace tiempo que no digo nada de Zimbra, hoy voy a contar un pequeño truco que no está excesivamente documentado. Se trata de modificar el tiempo de retención de los correos en una carpeta, de forma que se purguen los antiguos de forma automática. Aunque para el correo normal no es útil, ya que con los espacios de buzón que hay a día de hoy purgar correos no tiene mucho sentido, sí puede ser útil para carpeta de logs, o la típica carpeta donde se almacenan todos esos correos de "FW:" y "RE:" que la gente te envía.
Propiedades de carpeta
Pues bien, para automatizar este proceso, el usuario debe de dirigirse a la carpeta que le interese en cuestión y sobre ella, ir a las propiedades, como se muestra en la imagen lateral. Pinchando en "Editar propiedades", nos aparecerá la ventana que se muestra abajo, y tendremos que ir a la segunda pestaña, "Retención" y ahí simplemente activar la eliminación de mensajes. A continuación debemos especificar el tiempo máximo de los mensajes que deseemos tener en dicha carpeta. En mi caso, por ejemplo, puse 3 semanas. Puedes elegir entre semanas, meses y años.
Activar tiempo de retención
Lo que hará internamente Zimbra es borrar diariamente aquellos mensajes que estén 'caducados', sin pedir la autorización del usuario, por lo que es muy importante estar seguro de la acción que vamos a llevar a cabo. El correo que se borra no se podrá recuperar (backups aparte...).
Puede que una vez que lo activéis tarde sobre un día en hacer la primera purga de correo. El proceso que se encarga de ello no se ejecuta bajo demanda, sino que se lanza en un determinado horario, así que dependerá del sistema. Tras la primera ejecución podréis ver cómo se han borrado aquellos mensajes que ya no nos eran de interés y desde ahí tendremos siempre la carpeta con el auto-purgado funcionando.

Espero que os haya sido de ayuda.


Leer más

Tracear reglas IPTables

En el mundo de las conexiones de red y de los filtros que IPTables puede hacer, hay veces que se nos puede escapar algún paquete y que no sepamos exactamente qué regla es la que está haciendo el comportamiento anómalo. Si esto pasa, depurarlo puede ser complejo y llegarnos a hacer perder bastante tiempo.
Todos los que alguna vez hemos tocado IPTables solemos usar en la opción de qué hacer con el paquete (-j), la cadena DROP, REJECT, ACCEPT, LOG, CONNMARK, y alguna más que otra más. Sin embargo, si bien es cierto, que por ejemplo LOG y CONNMARK pueden ayudar a depurar, no están pensadas exactamente para eso.

Entonces, ¿cómo seguimos un paquete a través de las reglas?

Pues bien, para hacer exactamente eso, tenemos la opción TRACE, que se carga al incluir el módulo ipt_LOG. Esta nueva regla se usa tal que así,
shell> iptables -A PREROUTING -t raw -p icmp -j TRACE
Y permite rastrear las reglas y tablas por las que pasa un paquete. El formato de salida:
TRACE: tablename:chainname:type:rulenum"
y toda la información queda depositada en syslog, para su posterior análisis. La única condición para habilitarlo es que se aplique sobre la tabla raw.

Desde mi punto de vista es una opción un tanto desconocida, pero muy útil si necesitas ver dónde te has equivocado en el filtrado de los paquetes, especialmente cuando estamos hablando de que IPTables está manejando un elevado número de reglas.
Para más información sobre el uso de TRACE, consultar el man de iptables.

La entrada Tracear reglas IPTables la puedes leer en Puppet Linux.
Leer más

Instalar SaltStack Ubuntu

Hace un tiempo explicamos en este blog cómo instalar un cliente SaltStack sobre un equipo corriendo Debian. Hoy vamos a ver cómo instalar SaltStack en Ubuntu, ya que hay mucha gente que me preguntó cómo hacerlo bajo algo que no sea Debian, especialmente por el tirón que están teniendo las versiones LTS de este sistema operativo.
En realidad es prácticamente igual, pues ambos son de la misma familia. La única salvedad es la forma en la que agregar el repositorio de datos, que en sistemas Ubuntu podemos emplear los repositorios ppa de forma más sencilla. Por lo tanto para instalar SaltStack,
shell> add-apt-repository -y ppa:saltstack/salt
Una vez que tenemos ya es repositorio, únicamente
shell> apt-get update
shell> apt-get install {salt-minion | salt-master | salt-syndic}
Espero que os sea de ayuda.

La entrada Instalar SaltStack minion (Ubuntu) la puedes leer en Puppet Linux.
Leer más

SaltStack: Primeros pasos

Una vez tenemos ya finalizada la instalación de un servidor SaltStack y un cliente o minion, es hora de comenzar a trabajar y ver de qué es capaz.
Lo primero de todo, debemos de tener claro que la comunicación entre cliente y servidor siempre viaja cifrada. El sistema usado es de clave pública--privada, muy similar a SSH, así que el cliente va a generar una clave y tendrá que compartirla con el servidor. Éste luego deberá aceptarla (o no) antes de comenzar a intercambiar datos.
Siempre desde la shell del servidor de Salt, podemos ejecutar,
shell> salt-key -L
Accepted Keys:
Unaccepted Keys:
  salt-client-1.local.net
Rejected Keys:
Para ver un listado de los servidores que ya tenemos aceptados dentro del master y también los que están rechazados. Como veis el nombre del equipo es siempre el que se configura en el minion, y excepto que lo cambiemos manualmente, por defecto cogerá el nombre del equipo, con dominio.
Si tenemos algún equipo pendiente de aceptar, lo que tendremos que ejecutar es,
shell> salt-key -A
The following keys are going to be accepted:
Unaccepted Keys:
  salt-client-2.local.net
Proceed? [n/Y] Y
  Key for minion salt-client-2.local.net accepted.

shell> salt-key -L
Accepted Keys:
  salt-client-1.local.net
  salt-client-2.local.net
Unaccepted Keys:
Rejected Keys:
Ahora que ya los tenemos aceptados, ya podemos comenzar a trabajar con los clientes de forma sencilla. Lo más básico, ver que un equipo responde a ping,
shell> salt 'salt-client-1.local.net' test.ping
salt-client-1.local.net:
    True
O que todos responden a ping,
shell> salt '*' test.ping
salt-client-1.local.net:
    True
salt-client-2.local.net:
    True
Aunque también se pueden hacer cosas más concretas e interesantes como,
shell> salt '*' cmd.run 'cat /etc/debian_version'
salt-client-2.local.net:
    7.1
salt-client-1.local.net:
    7.0
U ordenarle que hagan un ping a Google y que nos devuelva el resultado,
shell> salt -L 'salt-client-*' network.ping '8.8.8.8'
salt-client-1.local.net:
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_req=1 ttl=45 time=53.1 ms
    64 bytes from 8.8.8.8: icmp_req=2 ttl=45 time=48.4 ms
    64 bytes from 8.8.8.8: icmp_req=3 ttl=45 time=50.4 ms
    64 bytes from 8.8.8.8: icmp_req=4 ttl=45 time=48.2 ms

    --- 8.8.8.8 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 48.211/50.052/53.184/2.019 ms

salt-client-2.local.net:
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_req=1 ttl=45 time=51.1 ms
    64 bytes from 8.8.8.8: icmp_req=2 ttl=45 time=48.3 ms
    64 bytes from 8.8.8.8: icmp_req=3 ttl=45 time=48.3 ms
    64 bytes from 8.8.8.8: icmp_req=4 ttl=45 time=48.1 ms

    --- 8.8.8.8 ping statistics ---
    4 packets transmitted, 4 received, 0% packet loss, time 3004ms
    rtt min/avg/max/mdev = 48.162/48.991/51.149/1.257 ms
Como creo que vais observando desde la shell del servidor de SaltStack siempre se ejecuta el comando salt, seguido de
  • '*', 'salt-client-1'
    Es el nombre del cliente al que queremos conectar.
    Puede usar comodines o expresiones regulares si nos interesa conectar a uno o más de uno. También se permite conecta a uno o varios equipos según arquitectura, sistema operativo, etc.
  • cmd.run, test.ping
    Es el comando que vamos a ejecutar. Por defecto SaltStack tiene muchos ya definidos, los cuales podemos y debemos usar.
  • '8.8.8.8'
    Son los parámetros opcionales que se le pueden pasar a un comando.
Como primera aproximación no está mal. En próximas entradas iremos viendo cómo hacer más cosillas con SaltStack, cosas que realmente ya será de interés y aportarán algo a la administración de sistemas.

La entrada SaltStack: Primeros pasos, la puedes leer en Puppet Linux.
Leer más

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios