All posts by Jordi Prats

puppet 3.8.3 para SLES11SP3

No es ningún secreto que odio SuSE en todas sus encarnaciones: tanto openSuSE como SLES. Hoy vamos a ver cómo instalar una versión reciente (en este caso 3.8.3) de puppet en lugar de la 2.6.18 que he visto que nos viene por defecto.

Para ello deberemos instalar los siguientes repositorios:

zypper addrepo -f --no-gpgcheck http://demeter.uni-regensburg.de/SLES11SP3-x86/DVD1/ "SLES11SP3-x64 DVD1 Online"
zypper addrepo -f --no-gpgcheck http://demeter.uni-regensburg.de/SLE11SP3-SDK-x86/DVD1/ "SUSE-Linux-Enterprise-Software-Development-Kit-11-SP3"
zypper addrepo http://download.opensuse.org/repositories/devel:languages:ruby/SLE_11_SP4/devel:languages:ruby.repo
zypper refresh

Instalamos libyaml como dependencia:

rpm -Uvh http://download.opensuse.org/repositories/devel:/languages:/misc/SLE_11_SP4/i586/libyaml-0-2-0.1.6-15.1.i586.rpm

Instalamos ruby 2.1:

zypper install ruby2.1

Realizamos la instalación rubygems desde .tgz:

cd /usr/local/src
wget https://rubygems.org/rubygems/rubygems-2.6.4.tgz --no-check-certificate
tar xzf rubygems-2.6.4.tgz 
cd rubygems-2.6.4/
ruby.ruby2.1 setup.rb 

Antes de instalar puppet deberemos instalar sus dependencias, en este caso json:

gem install json

Finalmente procedemos a instalar puppet:

cd /usr/local/src/
wget https://downloads.puppetlabs.com/puppet/puppet-3.8.3.tar.gz
wget http://downloads.puppetlabs.com/facter/facter-2.4.1.tar.gz
wget https://downloads.puppetlabs.com/hiera/hiera-1.3.4.tar.gz
tar xzf puppet-3.8.3.tar.gz 
tar xzf facter-2.4.1.tar.gz 
tar xzf hiera-1.3.4.tar.gz 
cd facter-2.4.1
ruby.ruby2.1 install.rb 
cd ../hiera-1.3.4
ruby.ruby2.1 install.rb 
cd ../puppet-3.8.3
ruby.ruby2.1 install.rb 

Una vez finalizado dicho proceso, ya tendremos puppet con una versión decente disponible:

sles11sp3:~ # puppet --version
3.8.3

Tags: , ,

Ver la imagen mapeada en un dispositivo loop

Si tenemos en el sistema un dispositivo loop nos puede interesar saber a que imagen corresponde dicho dispositivo, vamos a ver dos formas de hacerlo:

En las versiones reciente de losetup podemos usar la opción –show que nos mostrará la imagen, en este caso /root/ejemplo:

# losetup --show /dev/loop0
/dev/loop0: [fc00]:798589 (/root/ejemplo)

Pero también lo podemos hacer mediante el /sys, dentro del dispositivo loop a buscar deberemos hacer un cat del fichero loop/backing, por ejemplo para /dev/loop0 haríamos:

# cat /sys/block/loop0/loop/backing_file 
/root/ejemplo

Tags:

mod_nss: Instalación y configuración

En algunas algunas distribuciones nos podemos encontrar que mod_ssl no soporta TLS 1.2, pero en cambio sí podremos instalar mod_nss que sí lo soporta. Vamos a ver como usar mod_nss

Primero deberemos cargarlo y definir algunas variables globales, por ejemplo en /etc/httpd/conf.d/nss.conf:

LoadModule nss_module modules/libmodnss.so

AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl    .crl

NSSPassPhraseDialog  builtin

NSSPassPhraseHelper /usr/libexec/nss_pcache

NSSSessionCacheSize 10000
NSSSessionCacheTimeout 100
NSSSession3CacheTimeout 86400


NSSRandomSeed startup builtin

NSSRenegotiation off

NSSRequireSafeNegotiation off

NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

A continuación mediante certutil crearemos la base de datos que contendrá los certificados:

echo "ejemplopassword" > /etc/httpd/alias/pwdfile.txt
echo "internal:ejemplopassword" > /etc/httpd/alias/pin.txt
certutil -N -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt

Para el caso de CentOS, al instalar mod_nss se generará una base de datos con certificados autofirmados de ejemplo en /etc/httpd/alias

Mediante certutil deberemos generar la clave privada y el CSR que necesitamos para firmar el certificado, por ejemplo:

# certutil -R -s 'CN=systemadmin.es, O=systemadmin, OU=modnss, L=Barcelona, ST=Barcelona, C=RC' -o /etc/httpd/ssl/systemadmin.csr -a -g 2048 -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt

Podemos ver la clave privada generada mediante certutil -K:

# certutil -K -d /etc/httpd/alias/
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
< 0> rsa      37d35426e3a54d45c360be5727cc0f93be4dbeb4   NSS Certificate DB:alpha
< 1> rsa      c2fb4ee7ebeedc5a8f0c0cb8d6d2d51581b9ef57   NSS Certificate DB:cacert
< 2> rsa      6c18f8803eb18ad6ad1930c3b4650eb3e8dc5b72   NSS Certificate DB:Server-Cert
< 3> rsa      67c0de3a88a738ffaaf3508d370b528b7976ab0e   NSS Certificate DB:sudosueu
< 4> rsa      7b7276980ef037e4b6b37652a95e16376ea95e29   SelfSignedSP
< 5> rsa      da7524dee9662362db91ff0b95e77c078e2c4ed5   (orphan)

Una vez la entidad certificadora nos devuelva el certificado firmado, deberemos importar primero el certificado intermedio, si existe. Por ejemplo, para importar el certificado presente en /etc/httpd/ssl/systemadmin_intermediate.crt a la clave GeoTrustGlobalCA haríamos:

# certutil -A -n 'geotrust' -t 'CT,,' -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt -a -i /etc/httpd/ssl/systemadmin_intermediate.crt

Finalmente, importaremos el certificado firmado mediante el siguiente comando. En este caso suponemos que el certificado esta en /etc/httpd/ssl/systemadmin_cert.crt y lo queremos importar con la clave systemadmin:

# certutil -A -n 'systemadmin' -t 'P,,' -d /etc/httpd/alias -f /etc/httpd/alias/pwdfile.txt -a -i /etc/httpd/ssl/systemadmin_cert.crt

Podemos verificar la cadena mediante certutil -O:

# certutil -O -n systemadmin -d .
"GeoTrustGlobalCA" [CN=GeoTrust DV SSL CA - G3,OU=Domain Validated SSL,O=GeoTrust Inc.,C=US]

  "systemadmin" [CN=www.systemadmin.es]

Si volvemos a listar las claves privadas veremos que ya no se encuentra huérfana:

# certutil -K -d .
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
< 0> rsa      37d35426e3a54d45c360be5727cc0f93be4dbeb4   NSS Certificate DB:alpha
< 1> rsa      c2fb4ee7ebeedc5a8f0c0cb8d6d2d51581b9ef57   NSS Certificate DB:cacert
< 2> rsa      6c18f8803eb18ad6ad1930c3b4650eb3e8dc5b72   NSS Certificate DB:Server-Cert
< 3> rsa      67c0de3a88a738ffaaf3508d370b528b7976ab0e   NSS Certificate DB:sudosueu
< 4> rsa      7b7276980ef037e4b6b37652a95e16376ea95e29   SelfSignedSP
< 5> rsa      da7524dee9662362db91ff0b95e77c078e2c4ed5   systemadmin

Para habilitar el virtualhost SSL con mod_nss, deberemos añadir las siguientes opciones:

<VirtualHost *:443>
(...)
  NSSEngine on

  NSSCipherSuite +rsa_rc4_128_md5,+rsa_rc4_128_sha,+rsa_3des_sha,-rsa_des_sha,-rsa_rc4_40_md5,-rsa_rc2_40_md5,-rsa_null_md5,-rsa_null_sha,+fips_3des_sha,-fips_des_sha,-fortezza,-fortezza_rc4_128_sha,-fortezza_null,-rsa_des_56_sha,-rsa_rc4_56_sha,+rsa_aes_128_sha,+rsa_aes_256_sha

  NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

  NSSNickname systemadmin

  NSSCertificateDatabase /etc/httpd/alias
(...)
</VirtualHost>

Simplemente deberemos indicar la clave del certificado a usar mediante NSSNickname, en el caso de ejemplo sería systemadmin.

Tags:

Obtener JAVA_HOME mediante jrunscript

Para poder automatizar ciertas tareas nos puede interesar poder obtener el JAVA_HOME de la versión que tengamos instalada de java. Vamos a ver como podemos hacerlo mediante jrunscript:

jrunscript permite ejecutar javascript, por lo que simplemente deberemos obtener el valor de java.home y imprimirlo:

# jrunscript -e 'java.lang.System.out.println(java.lang.System.getProperty("java.home"));'
/usr/lib/jvm/java-7-openjdk-amd64/jre

Podemos ver un ejemplo de uso en el modulo de puppet eyp-tomcat para realizar la instalació de la tomcat native library:

    exec { "configure native library ${srcdir}":
      command => 'bash -c "./configure --with-apr=/usr/bin/apr-1-config --with-java-home=$(dirname $(jrunscript -e \'java.lang.System.out.println(java.lang.System.getProperty("java.home"));\'))"',
      require => [ Package[$tomcat::params::develpkg], Exec["tar xzf native library ${srcdir}"] ],
      cwd     => "${srcdir}/tomcat-native-library/jni/native",
      creates => "${srcdir}/tomcat-native-library/jni/native/Makefile",
    }

Tags:

pgbackup: Backup PostgresSQL

Mediante barman (pgbarman) podremos automatizar los backups y restauraciones de bases de datos PostgreSQL

En CentOS, simplemente deberemos instalar el paquete desde EPEL y configurar unos mínimos (/etc/barman/barman.conf)

[barman]
barman_home = /var/lib/barman
barman_user = barman
log_file = /var/log/barman/barman.log
compression = gzip
configuration_files_directory = /etc/barman.d

También deberemos configurar acceso mediante claves SSH (sin contraseña) en ambas direcciones desde el servidor de barman al usuario de la base de datos de las instancias que queramos hacer backup.

La configuración de los backups los haremos en ficheros independientes en el directorio /etc/barman.d para mayor comodidad, por ejemplo /etc/barman.d/pgm.conf

[pgm]
description = "postgres master"
ssh_command = ssh postgres@192.168.56.29
conninfo = host=192.168.56.29 user=postgres
retention_policy_mode = auto
retention_policy = RECOVERY WINDOW OF 30 days
wal_retention_policy = main

Mediante el comando show-server podremos buscar en que directorio deberemos dejar los archivados:

# barman show-server pgm | grep incoming_wals_directory
	incoming_wals_directory: /var/lib/barman/pgm/incoming

Mediante el modulo de puppet eyp-postgres podremos configurar un archive command para hacer rsync desde la base de datos al servidor.

	class { 'postgresql':
		wal_level => 'hot_standby',
		max_wal_senders => '3',
		checkpoint_segments => '8',
		wal_keep_segments => '8',
		archive_mode => true,
		archive_command_custom => 'rsync -a %p barman@192.168.56.31:/var/lib/barman/pgm/incoming/%f',
	}

Una vez este todo configurado podremos hacer copias de seguridad mediante backup, por ejemplo:

# barman backup pgm 
Starting backup for server pgm in /var/lib/barman/pgm/base/20160415T165403
Backup start at xlog location: 0/3000020 (000000010000000000000003, 00000020)
Copying files.
Copy done.
Asking PostgreSQL server to finalize the backup.
Backup end at xlog location: 0/30000E0 (000000010000000000000003, 000000E0)
Backup completed

Supongamos que tenemos ya el backup y hacemos lo siguiente en la base de datos:

postgres=# insert into test values('fuckthesystem');
INSERT 0 1
postgres=# select * from test;
       txt        
------------------
 sakura
 enlargeyourpenis
 fuckthesystem
(3 rows)


postgres=# delete from test;
DELETE 2
postgres=# select * from test;
 val 
-----
(0 rows)

postgres=# 

Podremos ver el listado de backups disponibles mediante list-backup:

# barman list-backup pgm
pgm 20160415T165403 - Fri Apr 15 14:54:04 2016 - Size: 19.3 MiB - WAL Size: 0 B

Para poder hacer la restauración necesitaremos algunos detalles del backup, los veremos mediante show-backup:

# barman show-backup pgm latest
Backup 20160415T165403:
  Server Name            : pgm
  Status                 : DONE
  PostgreSQL Version     : 90216
  PGDATA directory       : /var/lib/pgsql/9.2/data

  Base backup information:
    Disk usage           : 19.3 MiB
    Timeline             : 1
    Begin WAL            : 000000010000000000000003
    End WAL              : 000000010000000000000003
    WAL number           : 0
    Begin time           : 2016-04-15 14:54:01.835645+02:00
    End time             : 2016-04-15 14:54:04.514398+02:00
    Begin Offset         : 32
    End Offset           : 224
    Begin XLOG           : 0/3000020
    End XLOG             : 0/30000E0

  WAL information:
    No of files          : 0
    Disk usage           : 0 B
    Last available       : None

  Catalog information:
    Retention Policy     : VALID
    Previous Backup      : 20160415T142747
    Next Backup          : - (this is the latest base backup)

Necesitamos el nombre del backup y el “Begin time” exacto. Procedemos primero a parar la base de datos:

# /etc/init.d/postgresql-9.2 stop

A continuación indicamos a barman que recupere desde dicho backup indicando el begin time mediante –target-time y el nombre del backup. Podemos

# barman recover  --target-time "2016-04-15 14:54:01.835645+02:00" --remote-ssh-command="ssh postgres@192.168.56.29" pgm 20160415T142747 /var/lib/pgsql/9.2/data
Processing xlog segments for pgm
	000000010000000000000001
	000000010000000000000002
	000000010000000000000003
	000000010000000000000003.00000020.backup
	000000010000000000000004
Starting remote restore for server pgm using backup 20160415T165403 
Destination directory: /var/lib/pgsql/9.2/data
Copying the base backup.
Copying required wal segments.
The archive_command was set to 'false' to prevent data losses.

Your PostgreSQL server has been successfully prepared for recovery!

Please review network and archive related settings in the PostgreSQL
configuration file before starting the just recovered instance.

WARNING: Before starting up the recovered PostgreSQL server,
please review also the settings of the following configuration
options as they might interfere with your current recovery attempt:

    external_pid_file = '/var/lock/subsys/postgresql-9.2'			# write an extra PID file

Una vez recuperado, simplemente deberemos levantar la instancia:

/etc/init.d/postgresql-9.2 start

Si nos conectamos, veremos que tenemos los datos en el momento de hacer el backup:

[root@pgm ~]# psql -U postgres
psql (9.2.16)
Type "help" for help.

postgres=# select * from test;
       txt        
------------------
 sakura
 enlargeyourpenis
(2 rows)

postgres=# 

Tags:

lvextend – Ampliar el disco y el sistema de ficheros

Una de las opciones que muchas veces pasa desapercibida es la opción de lvextend de extender tanto el disco como el sistema de ficheros

La opción para extender el sistema de ficheros que contiene el disco es -r (o –resizefs) Tal y como indica la página man de lvextend:

       -r, --resizefs
              Resize underlying filesystem together with the logical volume using fsadm(8).

Dicha opción llama a fsadm para poder usar la herramienta adecuada para hacer el resize del sistema de ficheros, por ejemplo si es algún sistema de ficheros ext llamaría a resize2fs

Tags: