Software – Página 6 – tecnocracia .es

Nagios: Crear un nuevo check en powershell invocado desde nsclient

NAgios – NSCA check

Desarrollo del nuevo check

Es importante respetar los códigos de salida y la sintáxis de nagios par que nuesrto nuevo chequeo pueda ser visualizado correctamente desde nagios.

En el caso de estar usando también pnp4nagios, o cualquier otro addon capaz de hacer una gráfica , hay que respetar también la sintáxis de performance data.

Para definir los argumentos de entrada a un powershell, en el comienzo del script se define su nombre, posición y si es necesario:

[CmdletBinding()]
Param(
  [Parameter(Mandatory=$True,Position=1)]
   [string]$ApplicationPool
   )

Para definir el código de salida, se ha usado definición de variables:

Set-Variable OK 0 -option Constant
Set-Variable WARNING 1 -option Constant
Set-Variable CRITICAL 2 -option Constant
Set-Variable UNKNOWN 3 -option Constant

(...)
exit $CRITICAL

En mi caso, he desarrollado un plugin para poder conocer el estado de un pool de aplicaciones en un servidor IIS. El código completo está aquí.

Publicarlo a través de NSClient++

Con nuestro nuevo script escrito y funcionando, es momento de configurar nsclient++ para poder acceder desde nuestro nagios.

En primer lugar, en la carpeta de scripts C:\Program Files\NSClient++\scripts copiamos nuestro nuevo check con extensión ps1.

El funcionamiento de NSClient++ para los external scripts, hace que todos ellos se invoquen a través del cmd de windows. Por lo tanto, debemos especificar en la linea, que es powershell quien debe ejecutar nuestro nuevo check.

[/settings/external scripts/scripts]

check_default_app_pool = powershell.exe scripts\check_iis8_app_pool_state.ps1 DefaultAppPool

Instalación de NSCLient++.

Power cli: script para mover máquinas virtuales de datastore

Utilizando powershell, podemos hacer un pequeño script que nos libere un datastore completo, moviendo las máquinas virtuales que residen en él a una nueva ubicación.

Además, desmontamos las vmware tools, si están montadas, como indican en las communities de vmware.

Function migrate_ds  ([string] $old_ds, [string] $new_ds)
{            $vms = Get-VM -Datastore $old_ds
            foreach ($vm in $vms) {  
                    # unmount tools and clean cd drive 
                    $vm | Get-CDDrive | where { $_.IsoPath -or $_.HostDevice -or $_.RemoteDevice } | Set-CDDrive -NoMedia -Confirm:$false
                    $vm  | move-VM -Datastore $new_ds
            
            }
}

migrate_ds my_old_ds my_new_ds

F5 LTM: Migración a versión 11.6.0 HF3

Aviso: En el momento de hacer este tutorial, la versión 11.6.0 resultó absolutamente inestable y decidimos volver a la versión 11.5, pese a la falta de monitorización.

Hemos tenido un problema con la versión 11.5, y la monitorización mediante nagios. Básicamente, al recoger los identificadores de ltm, han dejado de responder mediante snmp:

snmpwalk  -v 2c -c $community $host .1.3.6.1.4.1.3375.2.2.5.5

Por ello, nos lanzamos a la migración a la versión 11.6

Pasos en la migración

Descargamos los archivos de la web de F5

Esta vez, para subir los archivos, lo haremos directamente por scp, a la carpeta /shared/images.

[root@server:Active:In Sync] config # ls /shared/images/
BIGIP-11.5.1.0.0.110.iso Hotfix-BIGIP-11.5.1.7.0.167-HF7.iso Hotfix-BIGIP-11.6.0.3.36.412-HF3-ENG.iso
BIGIP-11.6.0.0.0.401.iso Hotfix-BIGIP-11.6.0.3.0.412-HF3.iso

Verificamos que en la interfaz web aparezcan:

Instalamos la imagen en alguna partición en ambos nodos y activamos

Dejamos el pasivo con los virtual servers, y rompemos el grupo de disponibilidad. Para ello, solemos utilizar la funcionalidad “Reset Device group”.

A partir de este momento, ambos elementos están aislados, y cada uno, de forma manual debe tener sus Virtual Server sin que haya conflicto de IPs.

A partir de aquí, cuando tengamos probados los virtual servers en la nueva versión, ya se puede re-crear el grupo de sincronización y

Resultado de la migración

Al hacer las pruebas de estrés de los servidores virtuales, detectamos que la interfaz es absolutamente inestable.

Parece tener problemas de pérdida de memoria, y dan errores de buffer las peticiones a partir de las 300 peticiones en 10 threads simultáneos.

Por ello, volvemos a la versión 11.5 a la espera de nuevos hotfix en versión 11.6

F5 ltm: Crear un grupo de disponibilidad

Para crear un grupo de disponibilidad, partimos de una situación en la que tenemos dos nodos standalone:

Primero, en uno de los nodos, configuramos la lista de pares con los otros nodos:

Cuando ya está añadido con IP, podemos ir al grupo de failover, y añadir tantos nodos, como se hayan presentado:

Por último, pasamos la configuración para que estén sincronizados:

F5 Big ip ltm: Migración a versión 11.5.1 con hotfix 7

Subir las imágenes a los dispositivos F5 mediante el interfaz web:

Hotfix-BIGIP-11.5.1.7.0.167-HF7.iso
BIGIP-11.5.1.0.0.110.iso

Instalamos imagen y último hotfix sobre una partición del disco

Deshacemos el grupo de dispositivos de alta disponibilidad para que no haya problemas.

Arrancamos el pasivo con la nueva imagen de disco.

Esperamos a que el reinicio sea completo. Durante el arranque de los srevicios, por ssh, se ve la consola con el siguietne prompt

[admin@!:!:!] ~ #

[admin@localhost:INOPERATIVE:] ~ #

En este caso, nos ha pedido reactivar la licencia para pasar de versión. Lo hemos hecho manual a través de la web de f5: https://activate.f5.com/license/dossier.jsp

[admin@F5ext02:REACTIVATE LICENSE:Disconnected] ~ [admin@F5ext02:INOPERATIVE:Disconnected] ~ #

De forma manual, pasamos toda la carga (en nuestro caso Virtual servers) al servidor actualizado, y activamos la partición de disco duro en el servidor antiguo.

Puppet: Cambiar certificados de cliente puppet o puppetmaster

En uno de nuestros nodos, tenemos el siguiente mensaje:

err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=]
notice: Using cached catalog
err: Could not retrieve catalog; skipping run
err: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed: [certificate signature failure for /CN=

CASO 1: El certificado erróneo es el del cliente:

En el cliente

Parar el servicio puppet:

service puppet stop

Los certificados, en el nodo, se pueden borrar

find /var/lib/puppet/ssl -name '*.pem' -exec rm {} \;

Antes del siguiente inicio de servicio en puppet, hay que borrar en el servidor su certificado

En servidor:

puppet cert clean node
service puppetmaster restart
service apache2 restart

CASO 2: El problema está en el certificado del servidor.

Desde el cliente, vamos a hacer una prueba de conexión SSL:

wget https://puppetserver:8140/ --no-proxy
--2014-12-17 12:38:53--  https://mypuppetserver.com:8140/
Resolviendo mypuppetserver.com (mypuppetserver.com)... 10.57.236.13
Conectando con mypuppetserver.com (mypuppetserver.com)[10.57.236.13]:8140... conectado.
ERROR: El certificado de âmypuppetserver.comâ
                                                        ERROR: El certificado de âmypuppetserver.comâ

En el servidor, buscamos qué certificado está usando el servidor apache, para las conexiones por el puerto 8140

grep .pem /etc/apache2/sites-enabled/puppetmaster
        SSLCertificateFile      /var/lib/puppet/ssl/certs/mypuppetserver.com.pem
        SSLCertificateKeyFile   /var/lib/puppet/ssl/private_keys/mypuppetserver.com.pem
        SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
        SSLCACertificateFile    /var/lib/puppet/ssl/certs/ca.pem
        SSLCARevocationFile     /var/lib/puppet/ssl/ca/ca_crl.pem

Para ver el contenido en texto de cada uno de los certificados

openssl x509 -text -noout -in  /var/lib/puppet/ssl/certs/mypuppetserver.com.pem

En nuestro caso, el problema es que los clientes, quieren que el certificado también esté disponible para el CN=puppet. En el certificado anterior, no estaba de nombre alternativo puppet.

Lo hemos resuelto cambiando el /etc/hosts en servidor, ligando también el nombre puppet a nuestro servidor, y recreando los certificados.

Aunque estamos seguros de que hay mejores formas de regenerar los certificados, tras 1 semana de depuración, los hemos regenerado purgando todos los paquetes de puppet y reinstalando el servidor:

cp -rfp /etc/puppet ~/puppet$(date -I)
apt-get purge puppetmaster puppetmaster-common puppetmaster-passenger
apt-get puppetmaster-passenger
apt-get purge puppetmaster

Instalación de servidor puppet sobre Centos

Objetivos

Puppet server y puppet-dashboard.

Sistemas base

Centos 7

Instalación de puppet master:

Hemos seguido el tutorial de sotoca.es

yum install -y puppet-server
puppet resource service puppetmaster ensure=running enable=true

Para ver que el servicio estaba verdaderamente ejecutando:

systemctl list-unit-files

Instalando puppet dashboard

En el momento de hacer este tutorial, no están aún disponibles los paquetes de puppet-dashboard para centos7. Tampoco están disponibles los paquetes de ruby-mysql para Centos 7, lo que nos deja en este punto, atentos a su salida.

La idea sería añadir el nuevo repositorio de paquetes de puppet labs e instalar con yum

rpm -ivh puppetlabs-release-7-11.noarch.rpm
 yum install -y puppet-dashboard

Conociendo Centos 7

Configuración de red

Desaparece system-config-network y aparece nmtui como forma de configurar la red.

Los interfaces pasan de llamarse eth0, eth1… a tener unos nombres horrorosos como eno230032.

Para que coja la ruta, debe estar sin marcar la casilla ”Never use this network for deault route”

Después de cambios en interfaces:

systemctl network restart

Si no tenemos ips por dhcp, hay que verificar que en el fichero /etc/sysconfig/network-scripts/ifcfg-eno230032 esté bootproto a none y no a dhcp:

BOOTPROTO=none

Si seguimos teniendo problemas de red, hay que verificar la conexión

ifconfig; route

Configuración del proxy para yum:

En el fichero /etc/yum.conf se añade la línea:

proxy=http://proxy.organizacion.com:80

Instalación de emacs

Por que sí, yo uso emacs:

yum install -y emacs

Permitir acceso a root por ssh:

[root@template ~]# grep -i root /etc/ssh/sshd_config
PermitRootLogin yes

Instalar repositorio EPEL para paquetes extras:

rpm -Uvh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-2.noarch.rpm

Instalar vmware tools desde repositorio:

Mucho más cómodo que montando una ISO desde la plataforma de virtualización:

yum install open-vm-tools

Monitorización

yum install facter snmp-net

Añadir rpm remi

wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
rpm -Uvh remi-release-7*.rpm

Instalar fusion inventory agent

Necesitamos añadir el repositorio de guillomovitch para poder instalar estos paquetes

wget http://download.opensuse.org/repositories/home:/guillomovitch/CentOS_7/home:guillomovitch.repo

yum -y install fusioninventory-agent

The power of puppet. Curso introductorio de puppet labs

Hemos comenzado con el curso que dan desde Puppet Labs para comprender mejor y sacarle todo el partido posible a puppet.

El curso es gratuito, y la máquina virtual tiene una función de quests que va midiendo tu aprendizaje. Así es mucho más motivador y más fácil de seguir.

Problema con la máquina virtual para vmware

Al desplegar la máquina virtual sobre vmware, hemos encontrado un primer problema, ya que nos decía que no había host capaz de ejecutar el sistema operativo.

Sustituir en el fichero learn_puppet_centos-6.5-pe-3.3.2-disk1.vmx

guestOS = "redhat"

por

guestOS = "centos-64"

Otra particularidad que hemos visto en la máquina es que hacer un snapshot la rompe. Por ello, hemos tenido que dejarla en una carpeta de la que no se hace backup nunca.

Antes de empezar

Teclas en castellano:

loadkeys es
echo "loadkeys es >> .bashrc"

Configuración de red

system-config-network
services network restart

Configuración ssh

grep /etc/ssh/sshd_config
PermitRootLogin yes
services sshd restart

Configuración de proxy en bash, puppet y wget

  grep proxy ~/.bashrc
export http_proxy =http://192.128.2.2:80

grep proxy /etc/wgetrc
https_proxy = http://192.128.2.2:80
http_proxy =http://192.128.2.2:80
ftp_proxy =http://192.128.2.2:80

 grep proxy   /etc/puppetlabs/puppet/puppet.confgrep proxy /etc/puppetlabs/puppet/puppet.conf
 http_proxy_host = 192.128.2.2
 http_proxy_port = 80

Forzar la configuración de puppet en un momento dado

puppet agent –test

Validar un archivo de puppet

puppet parser validate FILENAME.pp

Encontrar la ruta para los módulos de puppet

puppet agent --configprint modulepath

Simular un manifiesto en local, sin aplicarlo

puppet apply --noop byte.pp

Aplicar verdaderamente un manifierto en máquina local:

puppet apply byte.pp

Emacs: Configuración para colorear puppet

cat ~/.emacs
(add-to-list 'load-path "/root/.emacs.d")
(autoload 'puppet-mode "puppet-mode.el" "Major mode for editing puppet manifests")
(add-to-list 'auto-mode-alist '("\\.pp$" . puppet-mode))

;; Enable font lock mode globally, because we love our users.
(require 'font-lock)
(global-font-lock-mode 1)

Instalar, actualizar y desinstalar módulos desde puppet forge

puppet module install puppetlabs-mysql --version 2.2.2 --ignore-requirements
puppet module upgrade puppetlabs-mysql
puppet module uninstall puppetlabs-mysql

Ver los módulos ya instalados

puppet module list --tree
Configurar el proxy
root@puppet:/etc/puppet/manifests# grep proxy  /etc/puppet/puppet.conf
http_proxy_host=proxy.myorg.org
http_proxy_port = 80

Puppet: Instalación de servidor en debian

Es la segunda vez que nos enfretamos al reto de construir un servidor puppet, esta vez sobre un servidor Debian.

Recomendamos leer how puppet works

Consideraciones iniciales

No vamos a usar una configuración asociada a un git. Vamos a usar un puppet master.

Nuestro objetivo será mantener igual en todos los equipos de nuestra infraestructura los siguientes elementos:

Configuración de usuarios de apache
Configuración GLPI
Certificados SSH de cliente
Configuración snmp

Instalación base de servidor

Debian Versión 7.7

/etc /apt/sources.list

deb http://ftp.es.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.es.debian.org/debian/ wheezy main contrib non-free

deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

deb http://ftp.es.debian.org/debian/ wheezy-updates main contrib non-free
deb-src http://ftp.es.debian.org/debian/ wheezy-updates main contrib non-free
deb http://backports.debian.org/debian-backports squeeze-backports main

Instalación puppet en servidor

apt-get install puppetmaster puppetmaster-passenger

Al instalar passenger, hemos tenido un problema con apache y sus logs.

no listening sockets available, shutting down
 Unable to open logs

Hemos cambiado los permisos del directorio de apache, para que ya pueda iniciar.

chown www-data:www-data /var/log/apache2

Y hemos reiniciado, por que no había nada en el puerto 80.

Instalación de puppet-dashboard en servidor

Hemos seguido al pie de la letra el tutorial de wiki.debian.org, pero hemos tenido algún problemilla más:

:~# tail /var/log/apache2/dashboard.example.com_error.log
 (...) Directory index forbidden by Options directive: /usr/share/puppet-dashboard/public/

Para resolverlo hemos tenido que cambiar la configuración de apache para el servidor de puppet-dashboard.

Una consideración inicial, es que hemos optado por que la configuración de este servidor, sea, por defecto el puppet dashboard. Es decir, al entrar en el raíz del servidor, por el puerto 80, saldrá directamente puppet dashboard.

# /etc/apache2/sites-enabled/puppet-dashboard

<VirtualHost *:80>
        ServerName miservidor.com
        DocumentRoot /usr/share/puppet-dashboard/public/
        <Directory /usr/share/puppet-dashboard/public/>
                Options -Indexes +FollowSymLinks MultiViews
                Order allow,deny
                allow from all
        </Directory>

        PassengerHighPerformance on
        PassengerMaxPoolSize 12
        PassengerPoolIdleTime 1500
        PassengerStatThrottleRate 120
        RailsAutoDetect On
  ErrorLog /var/log/apache2/dashboard.example.com_error.log
  LogLevel warn
  CustomLog /var/log/apache2/dashboard.example.com_access.log combined
  ServerSignature On
</VirtualHost>

Configuramos también settings.yml:

[root@server~]# grep ca_server /etc/puppet-dashboard/settings.yml
ca_server: 'server.org'

En el fichero de configuración de puppet, especificamos la url donde queremos que queden los reports

[master]
    report=true
    reports = store, http
    reporturl = http://servers/reports/reports/upload

Al poner puppet dashboard en el puerto 80, y no en el 3000 que es lo normal, hemos tenigo qeu cambiar /opt/puppet-dashboard/bin/external_node

DASHBOARD_URL = http://localhost

Esta es la vista del servidor web

Ejecutar puppetmaster:

 /etc/init.d/puppetmaster start

Si nos da este error:

 service puppet-dashboard start
[warn] Starting Puppet Dashboard:[....] Not starting Puppet Dashboard, disabled via /etc/default/puppet-dashboard ... (warning).
. ok

Editar /etc/default/puppet-dashboard-workers:

###START=no
START=yes

Colorear en emacs puppet

[root@server puppet]# apt-get install puppet-el

Instalación de agentes puppet en cliente: Facter y puppet

Facter es el componente de cliente encargado de mostrar la información de cada máquina. Se debe instalar en cada máquina que vayamos a gestionar con puppet.

apt-get install -y puppet facter

Prueba de comunicación con el servidor:

root@client:~# puppet agent --server puppet.server.com --no-daemonize --verbose

En la primera ejecución, se crea un certificado que tenemos que firmar en el servidor. Podéis revisar slashdot.in para más información.

[root@server~]#  puppet cert  --list
 "client.org" (...)
 [root@server~]# puppet cert--sign client.org