Hoy me he encontrado con la extraña tarea de tener que monitorizar un servidor Windows con Nagios. Digo extraña porqué hasta ahora sólo he tenido que monitorizar servidores Linux, por ser éste el sistema operativo usado en la mayoría de servidores con los que me he cruzado.

En cuanto al servidor a monitorizar, he seguido estos pasos:

1. Descargar NSClient++ en el servidor Windows. Aquí la página oficial de NSClient++
2. Ejecutar el instalador y seguir el asistente
   • Durante el instalador, se podrá indicar la IP del servidor Nagios, para únicamente permitir el acceso a NSClient++ desde esa IP.
   • Igualmente, se podrá indicar una contraseña que se deberá configurar en el servidor Nagios, para poder conectar.
   • Si se va a usar check_nt, como es habitual, se deberá marcar durante la instalación, los módulos “common check plugins” y “nsclient server (check_nt)”.
3. Una vez finalizada la instalación, se recomienda marcar el check “start service” para iniciar en ese momento el servicio NSClient++ (se podrá ver desde services.msc). El servicio se guarda con inicio “automático”, así que en teoría no hemos de preocuparnos de él.

Con esto estaría todo listo, en cuanto a la parte de la máquina a monitorizar. En cuanto a la propia configuración del Nagios, por defecto ya viene un fichero windows.cfg que encontraremos en la carpeta de objetos del servidor Nagios, que nos servirá de base para conectar mediante check_nt con nuestro nuevo servidor Windows.

Fuente: http://nagioses.blogspot.com/2009/03/monitoreando-maquinas-con-windows.html

Intentando instalar los plugins de Nagios en una máquina “cliente” a monitorizar, es posible que nos encontremos con el siguiente error, tras ejecutar el ./configure:

[root@miserver nagios-plugins-1.4.15]# ./configure
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
checking for gcc… no
checking for cc… no
checking for cl.exe… no
configure: error: no acceptable C compiler found in $PATH
See `config.log’ for more details.
[root@miserver nagios-plugins-1.4.15]#

Este error es de por sí, bastante descriptivo; falta el compilador de C, concretamente, “gcc”. En entornos Red Hat, bastará con usar yum para instalar gcc y solucionar así el problema:

[root@miserver nagios-plugins-1.4.15]# yum install gcc

En mi caso, gcc ha tenido las siguientes dependencias, también instaladas junto con gcc de forma automática:

• cpp
• glibc-devel
• glibc-headers
• kernel-headers

El propósito del post, es ver los paquetes imprescindibles a instalar para solucionar este problema.

Si se quiere montar un servidor que soporte HTTPS, se deberá contar un certificado válido para el sitio web. Para ello, una opción es directamente, comprar dicho certificado, en alguno de los múltiples sitios web que ofrecen esta opción, como GoDaddy, los cuales, ya tienen las instrucciones para generar la petición del certificado aquí:

Para generar la petición para el certificado, se deberán seguir una serie de pasos:

• Crear el certificado y la petición CSR (Solicitud para Firma del Certificado), ejecutando en el servidor web, el siguiente comando (NOTA: yourdomain puede ser cualquier texto, por ejemplo, para dominio.com podríamos usar dominio.key y dominio.csr respectivamente):

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

LEER MÁS

Para finalizar el año, veremos cómo actualizar PHP en un servidor Red Hat Enterprise 5.5.

En primer lugar miraremos qué versión de php tenemos, sin necesidad de usar phpinfo():

[root@miserver ~]# php -v
PHP 5.1.6 (cli) (built: Nov 13 2010 16:05:12)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

A continuación instalaremos los repositorios de remi siguiendo los pasos descritos aquí:

[root@miserver ~]# wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm
[root@miserver ~]# wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
[root@miserver ~]# rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm

LEER MÁS

En más de una ocasión, me he encontrado con la necesidad de verificar el motor (innodb o myisam) de las tablas de una determinada base de datos en mysql. Se puede ver el motor usado, seleccionando la base de datos y ejecutando el comando “show table status”:

use mydatabase;
show table status;

También me he encontrado con la necesidad de cambiar varias (o todas) las tablas de un motor a otro. Existe la posibilidad de ejecutar la siguiente sentencia para cambiar el motor de una tabla:

ALTER TABLE mytable ENGINE=InnoDB

LEER MÁS

Si se quiere cambiar alguno de los parámetros de cualquier nodo del réplica set, bastará con conectar con el nodo primario de ese conjunto, y seguir los pasos descritos a continuación.

En primer lugar, se deberá copiar la configuración actual del replica set a una variable auxiliar:

PRIMARY> cfg = rs.conf()
{
“_id” : “replica1″,
“version” : 6,
“members” : [
{
"_id" : 0,
"host" : "192.0.1.2:27001"
},
{
"_id" : 1,
"host" : "192.0.1.3:27001"
},
{
"_id" : 4,
"host" : "192.0.1.4:38001",
"arbiterOnly" : true
}
]
}

LEER MÁS

Ya he escrito algunos posts donde se ha hablado un poco de la administración de usuarios y permisos en MySQL como éste o  éste otro. Sin embargo, voy a resumir en un breve post la administración de usuarios y permisos de MySQL.
Podemos ver los usuarios que tenemos en el mysql con el siguiente comando:

mysql> select * from mysql.user;

Esto nos mostrará todos los usuarios definidos en mysql, separando además los usuarios por host (si tenemos un usuario user@localhost y el mismo usuario para acceder desde cualquier host user@’%', aparecerán dos líneas para este usuario.

Para conocer los permisos que tiene un determinado usuario, se podrá usar:

mysql> show grants for user@’host’

Por ejemplo: mysql> show grants for user@’%’

LEER MÁS

Un comando muy útil para ver qué velocidades soporta tu tarjeta de red, y más importante si cabe, a qué velocidad está configurada actualmente, es “ethtool”, un comando que podremos encontrar en la mayoría de distribuciones linux.

Un ejemplo de salida sería el siguiente:

[root@server root]# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/FullSupports auto-negotiation: Yes
Advertised link modes:  10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/FullAdvertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: g
Wake-on: g
Link detected: yes

Como se puede ver en el ejemplo, la tarjeta de red eth1 soporta trabajar a 10, 100 y 1000 Mbps,, pero actualmente, está trabajando a 100Mbps, tal y como se puede ver junto a “Speed”.

Un comando útil, que ofrece algo más de información que el usual “dmesg | grep eth1″.

Fuente: http://linuxhelp.blogspot.com/2005/10/find-speed-of-your-ethernet-card-in.html

Para realizar backups de bases de datos MySQL, se suele usar el comando mysqldump. Este comando, se encarga de generar las consultas necesarias para recrear toda la estructura de tablas y su contenido, a base de sentencias SQL. Sin embargo, este comando, puede resultar muy lento, para bases de datos grandes.

Si se quiere hacer un backup de una base de datos con tablas MyISAM, desde la propia documentación oficial de MySQL se insta a usar mysqlhotcopy en lugar de mysqldump:

“If you are doing a backup on the server and your tables all are MyISAM tables, consider using the mysqlhotcopy instead because it can accomplish faster backups and faster restores”
Fuente: aquí

LEER MÁS

Esta semana hemos realizado una actualización de nuestro clúster MongoDB de la versión 1.8 a la 2.0.

En nuestro caso, tenemos varias máquinas que forman parte del clúster, donde cada máquina contiene un seguido de mongods corriendo, cada uno de ellos correspondiente a un shard, que a su vez contiene un nodo de un determinado replica-set. Un poco complicado de entender, si no se ha tocado mucho MongoDB. En cualquier caso, con este escenario hemos relizado la actualización.

La idea ha sido aprovechar la funcionalidad de clúster, para poder actualizar las máquinas secundarias mientras las primarias continuaban dando servicio, con tal de minimizar el downtime que requiere un proceso de estas características.

LEER MÁS