Etiqueta: puppet

Installing Dataprotector 9 Agents on Debian 8

For some reason, dataprotector agents are released as an ISO image, with a +3000 lines shell script omnisetup.sh.

sudo ./omnisetup.sh -server myserver.myorg.es -install da

This lengthy script install dataprotector clients or server in several architectures:

  • osf1

  • hp-ux

  • SunOs and Solaris

  • AIX,

  • Linux x86, linux ia64

  • sco_sv

  • Darwin

  • PowerPC

For linux, it relays con rpm configuration. For Debian, the way to go would be alien.

Packages needed for Dataprotector agents (DA):

The only packages that are needed for the agents are:

  • OB2-TS-CORE-A.09.00-1.x86_64

  • OB2-CORE-A.09.00-1.x86_64

  • OB2-DA-A.09.00-1.x86_64

So, our first and naive aproach was a conversion with Alien and install them via dpkg -i.

for RPM in *.rpm; do sudo alien -c -k -d --fixperms $RPM; done

This led to an error as this three packages couldn’t be installed because we lacked some util called omnicc.

At this point, I tried running omnicc with bash -x, so that I could see what the long omnisetup was trying to do in my Debian machine.

bash -x ./omnisetup.sh -server myserver.myorg.es -install da

And then I noticed that, though only the above packages were installed, some others were uncompressed and used:

rpm2cpio /usr/local/share/Software_HP_DP_9.00_for_Linux_TD586-15021/linux_x86_64/DP_DEPOT/OB2-CORE-IS-A.09.00-1.x86_64.rpm 

cpio -id ./opt/omni/databases/utils/gpl/x86_64/linux-x86-64/utils.tar

cp ./opt/omni/databases/utils/gpl/x86_64/linux-x86-64/utils.tar .
(...)
rpm2cpio /usr/local/share/Software_HP_DP_9.00_for_Linux_TD586-15021/linux_x86_64/DP_DEPOT/OB2-TS-CFP-A.09.00-1.x86_64.rpm

cpio -id ./opt/omni/databases/vendor/ts_core/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

PacketFullPath=/tmp/omni_tmp/opt/omni/databases/vendor/ts_core
/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

(...)

rpm2cpio /usr/local/share/Software_HP_DP_9.00_for_Linux_TD586-15021/linux_x86_64/DP_DEPOT/OB2-DAP-A.09.00-1.x86_64.rpm

cpio -id ./opt/omni/databases/vendor/da/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

PacketFullPath=/tmp/omni_tmp/opt/omni/databases/vendor/da/gpl/x86_64/linux-x86-64/A.09.00/packet.Z

(...)

At this point, I decided to stick to rpm installation, and use the omnisetup.sh script.

These are the files from the ISO image that we need to distribute to our Debian machines:

linux_x86_64 
│   ├── DP_DEPOT
│   │   ├── gpg-hpPublicKey.pub
│   │   ├── OB2-CFP-A.09.00-1.x86_64.rpm
│   │   ├── OB2-CORE-IS-A.09.00-1.x86_64.rpm
│   │   ├── OB2-DA-A.09.00-1.x86_64.rpm
│   │   ├── OB2-DAP-A.09.00-1.x86_64.rpm
│   │   ├── OB2-TS-CFP-A.09.00-1.x86_64.rpm
│   │   ├── OB2-TS-CORE-A.09.00-1.x86_64.rpm
│   │   └── OB2-TS-CS-A.09.00-1.x86_64.rpm
│   ├── scripts_linux_x86_64
│   │   ├── verify_gpg_lnx.sh
│   │   └── verify_gpg_lnx.sh.sig
│   └── SIG
│   └── DP_DEPOT
│   ├── OB2-CFP-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-CORE-IS-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-DA-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-DAP-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-TS-CFP-A.09.00-1.x86_64.rpm.sig
│   ├── OB2-TS-CORE-A.09.00-1.x86_64.rpm.sig
│   └── OB2-TS-CS-A.09.00-1.x86_64.rpm.sig
├── LOCAL_INSTALL
│   └── omnisetup.sh
├── Readme.txt

Manual installation:

apt-get install -y liblua5.1-0 xinetd rpm2cpio rpm 
sudo ./omnisetup.sh -server myserver.myorg.es -install da

Reconfigure xinetd to serve omni

cat /etc/xinetd.d/dataprotector 

omni stream tcp nowait root /opt/omni/lbin/inet inet -log /var/opt/omni/log/inet.log

Puppet installation

I am proud to present my own dataprotectoragent puppet module to avoid manual installation of this agent

puppet module install esterniclos-dataprotector agent

class {"dataprotectoragent":
      dataprotectorserver => "dataprotector.my.com",
    }

Available from

Troubleshooting

During this project, I encountered The package needs to be reinstalled, but I can’t find an archive for it error, and, luckily,  IhaveaPC awesome tutorial to get rid of it.

Puppet: Crear nuevos tipos para recursos

Un recurso (resource) en puppet es la unidad mínima de configuración.  Puppet viene con algunos recursos ya predefinidos (built-in) como son:

Los recursos, a la hora de instanciarse tienen un nombre propio de instancia, y se pueden invocar tantos como sean necesarios.

Es la diferencia más interesante respecto de una clase. La clase se aplica de forma única sobre el servidor; pero la clase puede tener N instancias de un recurso.

Vamos a ver cómo definir los recursos más simples, en el lenguaje declarativo de puppet.

Este ejemplo está sacado de puppetlabs:
# /etc/puppetlabs/puppet/modules/apache/manifests/vhost.pp
define apache::vhost (Integer $port, String[1] $docroot, String[1] $servername = $title, String $vhost_name = '*') {
  include apache # contains Package['httpd'] and Service['httpd']
  include apache::params # contains common config settings
  $vhost_dir = $apache::params::vhost_dir
  file { "${vhost_dir}/${servername}.conf":
    content => template('apache/vhost-default.conf.erb'),
      # This template can access all of the parameters and variables from above.
    owner   => 'www',
    group   => 'www',
    mode    => '644',
    require => Package['httpd'],
    notify  => Service['httpd'],
  }
}

Dado que está parametrizado, se pueden invocar N instancias distintas de vhost en nuestra clase.

Para invocar una instancia, es necesario ponerle un nombre y

<TYPE> { '<TITLE>':
  <ATTRIBUTE> => <VALUE>,
}

El ejemplo básico para el nuestro, sería en un servidor, pasar a definir varios vhosts distintos:

apache::vhost {'homepages':
  port    => 8081, # Becomes the value of $port
  docroot => '/var/www-testhost', # Becomes the value of $docroot
}


apache::vhost {'redmine':
  port    => 80, # Becomes the value of $port
  docroot => '/var/www/redmine', # Becomes the value of $docroot
}
 

DNS: named-chroot comandos comunes

A la hora de administrar un servidor de nombres DNS sobre bind, debemos tener en cuenta algunos aspectos importantes.

Chroot

Es mejor aislar mediante chroot el servicio de DNS, de forma que los ataques sobre bind, no comprometan el resto de la máquina. En el caso de redhat enterprise linux, nos lo paquetizan como named-chroot

yum install -y named-chroot

Administración gráfica: webmin

Para evitar errores de escritura, la interfaz de webmin, es una ayuda para hacer cambios, y verificar la sintáxis de todos los archivos.

Comprobación de sintáxis tras los cambios named-checkconf

Si preferimos usar el editor de textos, antes de cargar el servicio y, ante la posibilidad de que haya errores de sintáxis, lo mejor es usar named-checkconf.

named-checkconf -t /var/named/chroot /etc/named.conf

Replicando los cambios mediante puppet

Si estamos usando puppet para replicar los cambios en distintos DNS, es mejor poner un indicador en los archivos que, tras un cambio, deben reiniciar el servicio de nombres.

 # add a notify to the file resource
  file { '/var/named/chroot/etc/named.conf':
    notify  => Service['named-chroot'],  # this sets up the relationship
    ......
  }

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

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

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

puppet labs

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

The power of puppet. Curso introductorio de puppet labs

puppetlabts

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

Captura

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

 

puppet-dashboard-01

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

 

Debian: Gestión de servidores mediante puppet y Foreman

Pantalla de inicio foreman

Instalación sobre debian wheezy

Excelente video tutorial para tener en 10 minutos instalado el servidor puppet, con interfaz de foreman incluida

Agentes en los clientes

Instalación

apt-get install puppet-facter

Ejecución como servicio en el arranque:

vim /etc/default/puppet

Primera ejecución manual para crear y firmar los certificados de cliente en 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