Instalación de Zabbix

22 Marzo 2015 at 19:35 by Adrián Pérez

zabix¿Por qué Zabbix?

Acostumbrado a Nagios, lo primero que busqué en Google para documentarme sobre Zabbix, fue la cadena "Zabbix vs Nagios" (hay un debate muy interesante en reddit). En cualquier caso, aquí hacen una buena comparación entre ambos sistemas de monitorización.

Tras unos días con Zabbix, mi primera impresión es que la configuración vía web de Zabbix quizá sea más amigable que la configuración vía archivos de Nagios, aunque sin duda (y quizá por pasar varios años con Nagios) ésta última resulta más sencilla que no la de Zabbix, que requiere de múltiples configuraciones para poder monitorizar un elemento (el ítem en sí, su triger, el action asociado, la aplicación del ítem, etc.).

Un punto a favor de Zabbix es que parece que la comunicación cliente servidor no ocasionará los problemas que alguna vez me he encontrado con Nagios, de falsos positivos debidos a timeouts en la conexión SSH entre el servidor Nagios y el host a monitorizar (Nagios requiere de plugins adicionales para monitorizar vía NRPE).

A favor de Nagios, pero, está la gran cantidad de plugins que la comunidad ha puesto a nuestra disposición en Nagios Exchange, a primera vista mucho más completos que los plugins de Zabbix.

Componentes de Zabbix

Zabbix consta de un seguido de componentes que interaccionan entre sí:

  • Zabbix agent: el agente (o cliente) de Zabbix se instala en aquellos elementos a monitorizar. El agente se encargará de recoger información del sistema y de las aplicaciones y se las hará llegar al Zabbix server. El Zabbix agent puede recoger datos:
    • de forma pasiva: el server contacta al agente pidiéndole un dato (por ejemplo el consumo de CPU en ese instante) y el agente responde al server con ese dato.
    • de forma activa: en un primer momento, el server le enviará al agente el listado de items a monitorizar. A partir de ese momento, será el agente que de forma periódica recogerá datos sobre esos ítems y se los hará llegar al server.
  • Zabbix server: el servidor de Zabbix y por tanto la pieza principal. Consta de una base de datos, una interfaz web y el propio server. Como servidor, se encarga de recoger los datos de los agentes, calcular los triggers, enviar notificaciones, etc. El servidor por tanto, es el repositorio central donde están definidas las configuraciones y donde se almacenan todos los datos y estadísticas recogidos de los agentes.
  • Proxy (opcional): se trata de un "recolector de datos" que se situa entre el servidor y los agentes. Si se tiene por ejemplo servidores repartidos en 5 datacenters, cada datacenter podría tener su propio proxy encargado de recoger los datos de los agentes de su datacenter, para posteriormente, hacerle llegar los datos al Zabbix server. Todo proxy requiere de su propia base de datos.
  • Java Gateway (opcional): permite monitorizar aplicaciones JMX (Java Management eXtensions) como WildFly/JBoss, Tomcat, Weblogic o Websphere. Zabbix Java Gateway usa la "JMX Management API" para recoger los datos de las aplicaciones JMX remotas monitorizadas.

Fuentes:
https://www.zabbix.com/documentation/2.2/manual/concepts

Instalar JBoss AS7 en entornos Red Hat

24 Febrero 2015 at 19:54 by Adrián Pérez

JBoss_logoJBoss es un Servidor de Aplicaciones Java completo, de código abierto, desarrollado por Red Hat. Y sí, yo también pienso en Apache Tomcat en estos momentos, pero hay diferencias entre ellos explicadas por ejemplo aquí o aquí. Voy a copiar literalmente una respuesta de StackOverflow que explica la diferencia entre un Servlet Container como Tomcat y un Application Server como JBoss:

"A servlet-container supports only the servlet API (including JSP, JSTL).

An application server supports the whole JavaEE - EJB, JMS, CDI, JTA, the servlet API (including JSP, JSTL), etc.

It is possible to run most of the JavaEE technologies on a servlet-container, but you have to install a standalone implementation of the particular technology." por Bozho

Ahora que quizá tenemos algo más claro qué es JBoss y por qué este post no habla sobre Tomcat, faltará ver qué diferencias hay entre la versión de la comunidad y la enterprise (más info aquí). Como es de esperar, la versión de la comunidad siempre irá por delante respecto a la empresarial en cuanto a novedades y funcionalidades, con lo cual no estará tan testeada ni será tan estable como debería ser la versión empresarial, más pensada para alojar aplicaciones críticas.

En esta entrada se instalará y pondrá en marcha la versión de la comunidad.

Migrar de Apache/PHP a Nginx/PHP en CentOS

24 Febrero 2015 at 12:49 by Adrián Pérez

nginx2Si contamos con un servidor Apache, quizá nos interese pasarlo a nginx con el menor downtime posible. Yo he hecho alguna prueba partiendo del siguiente entorno:

  • CentOS release 6.6
  • Apache/2.2.15 sin módulos adicionales
  • VirtualHosts para un proyecto PHP 5.3.3

Lo que haremos con nginx es instalarlo y configurarlo de forma muy básica en un puerto diferente y posteriormente una vez esté todo bien, cambiar puertos de escucha.

ATENCIÓN: Si estás pensando en migrar de Apache a Nginx, en producción, ten en cuenta que dependiendo de tu entorno, deberás hacerlo de una u otra manera. No es lo mismo migrar un proyecto python que sirve Apache via mod_wsgi, que un proyecto PHP que ni si quiera usa mod_rewrite (como en este ejemplo). Este post, por tanto, te puede servir de punto de partida, pero no es la "guía definitiva".

Instalación de nginx

En primer lugar, deberemos crear el fichero para acceder al repositorio de nginx, pues éste no viene en los repositorios de CentOS.

[root@lab01 ~]# vi /etc/yum.repos.d/nginx.repo
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

Tras configurar el repo, ya podremos instalar nginx via yum:

[root@lab01 ~]# yum install nginx

Configuración inicial de un servidor CentOS

5 Febrero 2015 at 13:07 by Adrián Pérez

centosHace ya unos años, y sin ningún software de administración tipo Puppet/Chef/Ansible, creamos un documento para que todos los técnicos pudieran decir la suya respecto a los pasos a dar tras instalar un sistema operativo Linux (CentOS en nuestro caso), con tal de no olvidarnos ninguno e ir mejorando entre todos este proceso de configuración inicial de un servidor. Eso significa que si tú, amado lector, tienes cualquier sugerencia de mejora, no dudes en dejarla en los comentarios.

Hoy en día, ese documento, muy pensado para instalaciones CentOS 6, tanto en entornos Cloud Computing como para en máquinas propias, es algo parecido a lo que listo a continuació.

NOTA: No te tomes todos los puntos al pie de la letra, seguramente querrás valorar si lo que propongo a continuación tiene sentido en tu entorno antes de aplicarlo, y seguro que más de un punto es mejorable.

1. Actualización del SO

Tras la instalación, es una buena idea forzar un update para estar a la última de los paquetes de nuestro SO.

yum update

2. Deshabilitar selinux

Selinux es una herramienta útil, pero que no compensa, y proporciona más dolores de cabeza de los que pretende solucionar. Es por eso que proveedores como RackSpace o Hetzner proveen sistemas con Selinux deshabilitado de fábrica. Si aún así quieres trabajar con Selinux, seguramente este sea el momento de configurarlo adecuadamente. En caso contrario, símplemente deshabilitalo tal y como sigue:

vi /etc/selinux/config
SELINUX=disabled

Tras deshabilitarlo, será necesario reinciar el sistema para activar los cambio. Así pues, reinicia para evitar tener problemas con los próximos pasos.

¿Cuantas CPUs tiene mi servidor Linux? ¿Y RAM?

30 Octubre 2014 at 13:12 by Adrián Pérez

cpuOtro post que tenía en borradores y que he decidido rescatar. Esta vez sobre hardware, con comandos tan básicos como útiles.

¿Cuantas CPUs tiene mi servidor?

En la mayoría de distribuciones Linux, pero concretamente en CentOS, podemos saber cuantas CPUs tiene el servidor, consultando /proc.

[root@myserver]# cat /proc/cpuinfo

El comando anterior nos mostrará la información referente a nuestras CPUs, pero "a simple vista" no sabemos si lo que nos está enseñando es el número de CPUs físicas, el número de nucleos, todo mezclado, etc. Para ello, hemos de prestar atención especialmente a los siguientes campos:

  • "Pyhisical id": id de CPU física. Nos servirá para saber el número de CPUs físicas del servidor. En el ejemplo, vemos 4 CPUs pero en realidad un único "physical id", lo cual nos indicará que tenemos una única CPU física con 4 núcleos:
[root@myserver]# grep "physical id" /proc/cpuinfo        
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 0

Administrar un LSI MegaRAID con MegaCLI

19 Septiembre 2014 at 12:01 by Adrián Pérez

LSI MegaRAIDYa vimos cómo gestionar un RAID en servidores HP con hpacucli (y también aquí). Si tienes un server Supermicro, esta herramienta no te servirá. Para gestionar un LSI MegaRAID de un server Supermicro, desde un CentOS, podemos usar "MegaCli".

Desde la página de LSI podremos buscar por nuestro modelo concreto de controladora RAID para bajarnos la versión de MegaCli apropiada, aunque cada versión abarca múltiples controladoras diferentes.

Una vez descargado el programa, podremos instalarlo, en CentOS 6 símplemente ejecutando:

[root@myServer]# unzip 8.07.14_MegaCLI.zip
[root@myServer]# rpm -i Linux/MegaCli-8.07.14-1.noarch.rpm

Como con cualquier otro paquete rpm, podremos ver el contenido del mismo con:

[root@myServer]# rpm -qpl Linux/MegaCli-8.07.14-1.noarch.rpm
/opt/MegaRAID/MegaCli/MegaCli
/opt/MegaRAID/MegaCli/MegaCli64
/opt/MegaRAID/MegaCli/libstorelibir-2.so.14.07-0

Si nos es más cómodo, podemos crear un enlace simbólico para tener el programa en el PATH y poderlo llamar sin tener que introducir su ruta completa.

[root@myServer]# ln -s /opt/MegaRAID/MegaCli/MegaCli64 /usr/local/sbin/MegaCli

Ahora ya podremos escribir "MegaCli" para usar el programa. El programa tiene muchos parámetros, algunos de los cuales están muy bien explicados en este post, y otros están resumidos en este otro post. A continuación, destacaré los que a mí particularmente me han sido más útiles.

Instalar Percona XtraDB Cluster 5.6

24 Marzo 2014 at 12:23 by Adrián Pérez

percona

Hace un tiempo, escribí sobre cómo instalar Percona XtraDB Cluster 5.5, de cara a tener una solución tipo cluster para MySQL basada en Galera. Los últimos días, he estado testeando la nueva versión de Percona XtraDB Cluster 5.6, y me he encontrado con algunas diferencias respecto a la instalación/configuración de la versión 5.5.

Requisitos

Para empezar, de cara a instalar Percona XtraDB Cluster 5.6, es necesario contar con socat instalado en todos los nodos del cluster antes de empezar a instalar Percona. En mi caso, en un Centos 6.5, me ha dado problemas la instalación desde sources, y finalmente lo he instalado desde un repositorio externo.

[root@myServer1]# cd /etc/yum.repos.d
[root@myServer1]# wget --no-cache http://www.convirture.com/repos/definitions/rhel/6.x/convirt.repo

Fuente: http://www.convirture.com/wiki/index.php?title=C2_fedora_installation

Tras contar con socat, he podido instalar el cluster, igual que en la versión 5.5.

Actualizar automáticamente un servidor

12 Marzo 2014 at 12:09 by Adrián Pérez

updateÚltimamente he estado leyendo sobre cómo y cuando actualizar un servidor Linux (Fedora/CentOS/Red Hat en mi caso), de cara a aplicar los últimos parches de seguridad y mantener el sistema actualizado. Resulta que no soy el único que se pregunta sobre si hay algún tipo de guía, recomendaciones, o mejores prácticas para updatear sistemas.

Después de leer y leer, y ver las numerosas razones tanto a favor como en contra de los updates automáticos, la siguiente frase en la documentación oficial de Fedora resume cuándo habilitar las actualizaciones automáticas, por lo general:

"If the machine is a critical server, for which unplanned downtime of a service on the machine can not be tolerated, then you should not use automatic updates. Otherwise, you may choose to use them."

Es decir, por norma general sería una buena idea habilitar las actualizaciones automáticas en todo servidor que no sea crítico, siempre y cuando tengamos la posibilidad de deshacer los updates instalados, o revertir los cambios, en caso de error.

Gitolite: gestión de permisos en Git

26 Febrero 2014 at 17:48 by Adrián Pérez

gitEs muy posible que queramos tener un control de usuarios y permisos en nuestro repositorio git centralizado, si por ejemplo, tenemos a varios equipos de varios desarrolladores trabajando cada uno con un repositorio diferente. Afortunadamente, existen varias soluciones a este problema pero yo me he quedado con gitolite, por su facilidad de gestión y sus posibilidades.

NOTA: En este post se irá cambiando del servidor (miServer) a mi PC local (miPC). Se irá comentando a lo largo del post a qué entorno se hace referencia, pero si te pierdes, fíjate en el inicio de cada comando ejecutado (ej: [root@miServer ~] vs [adri@miPC])

Instalación

Añadimos el repositorio EPEL para nuestro servidor con el repositorio central, un CentOS 6:

[root@miServer ~]# wget http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
[root@miServer ~]# rpm -Uvh epel-release-6-8.noarch.rpm

Instalamos git y a posteriori gitolite, que en mi caso, me ha instalado y/o actualizado bastantes paquetes, la mayoría relacionados con perl:

[root@miServer ~]# yum install git gitolite3.noarch

A continuación, crearemos un usuario de sistema, para gitolite, al que en el ejemplo hemos llamado "git", y que será el usuario de sistema con el que interactuarán los usuarios con el repo:

[root@miServer ~]# useradd --system --shell /bin/bash --home /home/git git

Maldet - Linux Malware Detect

26 Febrero 2014 at 16:34 by Adrián Pérez

virusMaldet (también conocido como LMD de las iniciales de Linux Malware Detect) es un detector de malware para entornos Linux compartidos, bajo licencia GNU GPLv2, que funciona desde el terminal.

Instalación

Podemos instalar Maldet de la siguiente manera:

1. Bajaremos el tarball de la página oficial:

[root@miServer tmp]# wget http://www.rfxn.com/downloads/maldetect-current.tar.gz

2. Descomprimiremos e instalaremos

[root@miServer tmp]# tar -zxcvf maldetect-current.tar.gz
[root@miServer tmp]# cd maldetect-1.4.2/
[root@miServer tmp]# ./install.sh

3. Ya estaremos listos para usar Maldet