tres – Página 6 – tecnocracia .es

Crear y probar nuestros modulos de puppet

Crear la arquitectura de nuestro modulo

La arquitectura de nuestro nuevo módulo, siempre va a tener una distribución de archivos parecida a:

manifests
--- init.pp
README.mdtemplates
 --- template.erb
tests
 --- test1.pp
files

Escribir el init.pp y tests

Para escribir los módulos, proponemos Gepetto sobre Eclipse.

Para verificar la sintáxis de las clases, se puede usar puppet-lint

gem install puppet-lint
 puppet-lint manifests/init.pp

Al escribir los tests, se pueden asociar al nodo default para mantenerlos sencillos

 node default {
 include mymoduleclass
}

Probar en un nodo con puppet instalado en local

Configuramos en puppet.conf de donde se van a leer los módulos

[main]

(..)
 puppetmodulepath=/etc/puppet/modules:/usr/share/puppet/modules

Para verificar la clase:

puppet apply --noop tests/test1.pp

Para aplicar cambios

puppet apply tests/test1.pp

Windows 2008: Añadir usuarios al grupo de escritorio remoto

Para permitir escritorio remoto a usuarios de windows sin darles permisos de administrador, existe un grupo local “grupo de escritorio remoto”.

Para configurarlo:

Administración de equipos
Usuarios y grupos locales
Grupos
Usuarios de escritorio remotos

Windwos 2008: Acceder al grupo de escritorio remoto

Vmware: Instalación de parches de servidor

Instalación de parches con powershell

Es necesario descargar el parche en local, y descomprimirlo.

Connect-ViServer host1.myorg.org

$host | Install-VMHostPatch -LocalPath ESXi550-201502001/metadata.zip

Instalación de parches por ssh

Activar ssh vía cli

$host = Start-VMHostService -HostService ($_ | Get-VMHostService | Where { $_.Key -eq "TSM-SSH" } )

Vía ssh:

vim-cmd hostsvc/maintenance_mode_enter
esxcli software vib install -d "/var/tmp/ESXi550-201502001.zip"
esxcli software vib list
vim-cmd hostsvc/maintenance_mode_enter

Nagios: Monitorización de servicios de windows

Configuración en windows

Instalación de NSCLient++.

En la instalación, necesitamos especificar desde qué equipos se va a hacer la monitorización (puede ser una subred) y qué clave concertada van a usar tanto cliente como servidor.

Toda la configuración se guarda en un archivo nsclient.ini

[/settings/default]
; ALLOWED HOSTS - A comaseparated list of allowed hosts. You can use netmasks (/ syntax) or * to create ranges.
allowed hosts = 192.168.2.2/25
; PASSWORD - Password used to authenticate against server
password = concerted

Para poder hacer checks sobre servicios, necesitamos además que nsclient acepte argumentos. Para ello, añadimos la sección de nrpe server:

[/settings/NRPE/server]
allow arguments = true

Configuración en Nagios

En nuestro caso, hemos optado por el uso del comando check_nrpe.

El nuevo servicio en services.cfg, quedará algo como esto:

 check_nrpe!checkServiceState -a ShowAll 'My Servicio de Windows'

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