Powercli: Configurar máquinas virtuales para que instalen tools en el inicio

A raíz del artículo de Brian Graf y de LucD sobre cambios de especificaciones de máquinas virtuales, hemos hecho un pequeño script configure_vmtools_power_cycle.ps1 capaz de marcar en las máquinas virtuales el atributo “tools upgrade”vmware.vmtools.upgrade.power.cycle

Se invoca desde powercli

.\configure_vmtools_power_cycle.ps1

Requiere configuración para definir en qué contenedor (Location) va a aplicar el cambio de políticas.

Para evitar que queden vmware tools montadas en los linux, sólo aplica el cambio sobre máquinas definidas como Windows y encendidas.

En la versión de powercli 5.5 que estamos trabajando, sólo está relleno el cambio vm.Guest.OsFullname si la máquina está encendida. En el caso de máquinas apagadas, no podemos discriminar por sistema operativo. Por ello, se ha puesto también la opción en la función de forzar la aplicación.

 

 
Function configure_vmtools_power_cycle ( $vm, [bool] $force )
{
       

   
    # Comment if you want to upgrade non windows vm
    if ((($vm.Guest.State -eq "PoweredOn") -and  ($vm.Guest.OSFullName.Contains("Windows")) -or ($force)))
        
       {
    
        write-host "Configure vmtools check and upgrade in every powercycle: " $vm.Name $vm.Guest.OSFullName

        # This line creates the object that encapsulates the settings for reconfiguring the VM
        $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
        # This line creates the object we will be modifying
        $vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
        # This line sets the Tools upgrades policy checkbox
        $vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"
        # This line commits the change to each virtual machine
        # Get-View -ViewType VirtualMachine | %{    $_.ReconfigVM($vmConfigSpec)}
    
        # Reconfigure vm
        $vm | Get-View | %{ $_.ReconfigVM($vmConfigSpec)}
        
        
   }
 }

 

Autenticación en máquinas linux mediante kerberos

https://wiki.debian.org/AuthenticatingLinuxWithActiveDirectory

Instalación y configuración de libpam-krb5

[logging]
        Default = FILE:/var/log/krb5.log
[libdefaults]
        default_realm =  DOMINIO.COM
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        fcc-mit-ticketflags = true
[realms]
        DOMINIO.COM = {
                kdc = server1.dominio.com
                kdc = server2.dominio.com
                admin_server = server1.dominio.com:88
                default_domain = dominio.com
        }
[domain_realm]
        .DOMINIO.COM = DOMINIO.COM
        DOMINIO.COM = DOMINIO.COM
[login]
        krb4_convert = true
        krb4_get_tickets = false

Prueba con kinit

Probamos nuestro usuario de pruebas contra el dominio:

kinit  usuario@dominio.com

Revisión de archivos de PAM

Por defecto, se crean las líneas de pam para aceptar krb5:

http://www.debian-administration.org/article/570/MIT_Kerberos_installation_on_Debian#PAM_configuration

Prueba con login

login usuario

en el log se debe ver algo como

tail -f /var/log/auth.log
Mar 17 13:15:14 puppettest login[20778]: pam_krb5(login:auth): user usuario authenticated as usuario@dominio.com

Pasos a seguir

Crear localmente los usuarios que van a usar su autenticación mediante kerberos.

Puppet: Argumentos erroneos, error en ruby

puppet labs

El agente de puppet no hace gestión de argumentos de entrada. En el caso de ser erróneo, da el siguiente error:

root@puppettest1:~# puppet agent ..server myserver  ..no-daemonize ..verbose ..waitforcert=60
dnsdomainname: Name or service not known
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:54:in `handle_serve': uninitialized constant Puppet::Network::Handler (NameError)
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:363:in `send'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:363:in `parse_options'
        from /usr/lib/ruby/1.8/optparse.rb:1298:in `call'
        from /usr/lib/ruby/1.8/optparse.rb:1298:in `parse_in_order'
        from /usr/lib/ruby/1.8/optparse.rb:1254:in `catch'
        from /usr/lib/ruby/1.8/optparse.rb:1254:in `parse_in_order'
        from /usr/lib/ruby/1.8/optparse.rb:1248:in `order!'
        from /usr/lib/ruby/1.8/optparse.rb:1339:in `permute!'
        from /usr/lib/ruby/1.8/optparse.rb:1360:in `parse!'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:370:in `parse_options'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:305:in `run'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:416:in `hook'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:305:in `run'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:407:in `exit_on_fail'
        from /usr/lib/ruby/vendor_ruby/puppet/application.rb:305:in `run'
        from /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:69:in `execute'
        from /usr/bin/puppet:4

En versiones anteriores como 2.6, se requería añadir a mano en lib/puppet/application/agent.rb la línea

 require 'puppet/network/handler'

Para saber qué versión de puppet se está ejecutando

puppet agent --version

En version 2.7, hay que revisar los argumentos de entrada. En nuestro caso, al cortar y pegar, se habían sustituido los — por ..

Vmware: Virtual distributed switch

vmware_vds1

Para evitar la configuración de red en cada uno de los hosts, vamos a configurar en forma de virtual distributed switch (VDS), frente a los virutal standard switch (VSS).

http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf

Un VDS se configura a nivel de datacenter.

En el momento de la creación, hay que definir el número de uplinks que vamos a utilizar. Aunque se pueden definir a posteriori, es mejor crear el número definitivo de uplinks, y añadir los interfaces físicos (vmnic) al uplink definitivo.

Consideraciones pre-migración

  • Hemos verificamos que los hosts mantienen la configuración de red, a pesar de tener una desconexión en el vcenter.
  • Si, en estado de desconexión del vcenter, se hacen cambios sobre VDS, hay problemas al conectarlo de nuevo.
  • La configuración de VDS se hace a nivel de datacenter. Eso significa que para hosts en distintos clusters, tenemos disponibles VDS’s con vlan’s que no tienen visibilidad. El control para evitar tráfico de red indeseado (tráfico de extranet o dmz, en zona interna) recae directemente sobre la electrónica de red.
  • A la hora de dimensionar el número de VDS, requerimos uno por cada canal físico o agregado (trunk) de red.
  • Borrar uplinks es extremadamente difícil. Es mejor hacer el diseño con el número de uplinks desde el comienzo de la definición del VDS.

Hosts y VDS

En un VDS, se pueden añadir o quitar hosts físicos.

Networking > VDS > Manage > Settings

vmware_vds_add_host

Añadir interfaces físicos a VDS y a uplink groups

vmware_vds_add_vmnic

Configuración vlan: virtual port group

Dentro de un VDS, se configuran virtual portgroup, que tienen la información de vlan, nic teaming y security igual que un portgroup tradicional.

Además, se les puede configura portmirroring.

Los virtual portgroup, se asignan en las máquinas virtuales igual que los tradicionales.

Powercli

Para gestionar virtual distributed switches, es necesario instalar el paquete  de VDSPowerCli , disponible en flings de vmware.

vmware_flings

 

pwcli1vmware

Cada vez que se vayan a invocar cmd-lets de VDS, es necesario cargar el módulo:

Add-PSSnapin VMware.VimAutomation.VdsComponent

Para ver todos los cmd-let disponibles

Get-Command –Module VMware.VimAutomation.VdsComponent

Vmware: host profiles con arranque desde SAN

Los host-profiles permiten tener una plantilla de configuración de host que asegura que todos los esxi de un cluster son iguales.

vmware.hostprofiles003

Hacen extraordinariamente cómodo la configuración de nuevos servidores.

Se almacenan los datos de:

  • red
  • almacenamiento
  • ntp
  • servicios, firewall…

El problema viene, cuando parte de los servidores tienen arranque desde SAN.

El perfil,  ve el disco de arranque igual que un datastore. El perfil da error de multimapping y psa invariablemente, al aplicar el perfil sobre otros servidores.

Hemos probado a deshabilitar entero la seccción de storage configuration.

Al no tener nada de información metida en los vmware, al respecto de los discos, entra en funcionamiento el mismo mecanismo que si no huebiera host profile en absoluto: Lo que los Hosts ESX vean a través de la fibra se considera datastore.

El perfil por tanto:

  • Se puede aplicar sobre cualquier host.
  • Configura correctamente red, ntp, dns, etc.
  • Ignora todos los settings de almacenamiento sin dar error.

 

vmware.hostprofiles002

 

 

 

Crear y probar nuestros modulos de puppet

puppet labs

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
Windwos 2008: Acceder al grupo de escritorio remoto

Vmware: Instalación de parches de servidor

VMWare ESXi
VMWare ESXi

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++.