Cómo trabajar con Boot Environments en Solaris - Parte 2

Introducción
En la primera parte de Cómo trabajar con Boot Environments hacíamos una introducción a los comandos de gestión y su funcionamiento básico.

En esta segunda parte, vamos a aplicar lo que hemos aprendido en cuanto a la gestión de Boot Environments y cómo podemos utilizarlo en "un mundo real".

Si no recuerdas las opciones más importantes, te recomiendo hacer un pequeño repaso a la primera parte de Cómo trabajar con boot environments antes de entrar ya en materia.

Instalación de paquetes
Una de las características más interesantes de los Boot Environments es la capacidad de instalar paquetes -o parches- sin tener "downtime" en nuestro sistema principal.

Para ello, deberemos utilizar la opción "-R /punto_montaje" del comando <pkg>, es decir:

havoc@h100:~$ pfexec pkg -R /mnt <acción>

Un Ejemplo Completo
Como siempre, lo mejor es verlo con un ejemplo. Así que vamos a actualizar una versión de OpenIndiana b148 a la última versión utilizando la opción <image-update>

1.- Creamos y Montamos un Boot Environment Nuevo (PreUpdate)

havoc@h100:~$ pfexec mkdir /mnt/preupdate
havoc@h100:~$ pfexec beadm create PreUpdate
havoc@h100:~$ pfexec beadm mount PreUpdate /mnt/preupdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint     Space   Policy Created         
--        ------ ----------     -----   ------ -------         
PreUpdate -      /mnt/preupdate 122.0K  static 2013-03-08 10:28
solaris   -      -              3.06M   static 2011-04-16 04:06
solaris-1 NR     /              103.88G static 2011-04-16 04:41

2.- Actualizamos la distribución completamente utilizando "image-update"

havoc@h100:~$ pfexec pkg -R /mnt/preupdate image-update
                Packages to remove:    71
               Packages to install:   120
                Packages to update:   419
           Create boot environment:    No
               Services to restart:     6
DOWNLOAD                            PKGS       FILES    XFER (MB)
Completed                          610/610 20899/20899  325.4/325.4

PHASE                                        ACTIONS
Removal Phase                             9232/14882
Warning - directory /mnt/usr/share/man/cat1m not empty or not expected during operation - contents preserved in /mnt/var/pkg/lost+found/usr/share/man/cat1m-20130402T001646Z
Removal Phase                            14882/14882
Install Phase                            15359/15359
Update Phase                             12439/23150
Update Phase                             23150/23150

PHASE                                          ITEMS
Package State Update Phase                 1029/1029
Package Cache Update Phase                   490/490
Image State Update Phase                         2/2
------------------------------------------------------------------
NOTE: Please review release notes posted at:

http://docs.sun.com/doc/821-1479 
------------------------------------------------------------------

3.- Comprobamos que todo se ha actualizado correctamente
Vamos a comprobar, por ejemplo, el paquete PostGreSQL9 que tenemos instalado en el Boot Environment actual y el actualizado (PreUpdate)

havoc@h100:~$ pfexec pkg info postgresql9
          Name: postgresql9
       Summary: PostgreSQL Database Server for OpenIndiana
         State: Installed
     Publisher: havoctec
       Version: 9.0.10
 Build Release: 5.11
        Branch: 0.148
Packaging Date: 25 de octubre de 2012 10:08:03
          Size: 41.04 MB
          FMRI: pkg://havoctec/postgresql9@9.0.10,5.11-0.148:20121025T100803Z
havoc@h100:~$ pfexec pkg -R /mnt/preupdate info postgresql9
          Name: postgresql9
       Summary: PostgreSQL Database Server for OpenIndiana
         State: Installed
     Publisher: havoctec
       Version: 9.0.12
 Build Release: 5.11
        Branch: 0.151
Packaging Date: 12 de febrero de 2013 11:00:46
          Size: 31.16 MB
          FMRI: pkg://havoctec/postgresql9@9.0.12,5.11-0.151:20130212T110046Z

4.- Forzar la reconfiguración.
Aunque este paso no es obligatorio, puede que nos encontremos con algún problema -como en este caso- de drivers que han cambiado y Solaris necesita reconfigurarse.

havoc@h100:~$ pfexec touch /mnt/preupdate/reconfigure

5.- Ciclo completo de boot iniciando con el nuevo Boot Enviroment
Este paso se puede realizar de dos formas (la segura y la rápida), aunque yo voy a centrarme en la más "segura" que requiere de un acceso físico a la consola para poder seleccionar el Boot Environment de forma "manual" en Grub (x86).

a) La más segura
Vamos a realizar un ciclo completo de boot, para ello utilizaremos la opción 6 del comando <init> o si lo preferís "apagar/encender".

havoc@h100:~$ pfexec init 6

Cuando se muestre la opción de arranque del Grub (x86) veremos una nueva entrada que será igual al nombre del Boot Environment que hemos definido, en nuestro caso "PreUpdate".

Seleccionamos ese entorno y comprobamos que todo funciona correctamente haciendo las pruebas necesarias para, finalmente, dejar como "activado" este nuevo entorno.

NOTA: Una vez comprobado que todo el proceso se realiza correctamente, a mí personalmente, me gusta tener el nombre del Boot Environment de una forma correcta, así que renombro el Boot Environment, pero, no es estríctamente necesario.

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space Policy Created
PreUpdate NR     /          141G  static 2013-03-07 23:57
solaris   -      -          3,06M static 2011-04-16 04:06
solaris-1 -      -          5,81G static 2011-04-16 04:41

b) En un sólo paso
Todo el proceso se puede realizar en un sólo paso. Suponiendo que hemos realizado varias pruebas de integración, y el proceso de actualización siempre ha sido correcto, podemos, por ejemplo, activar el nuevo Boot Environment y realizar un ciclo completo de boot, así:

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:~$ pfexec init 6

6.- Actualizar el "zpool" (SOLO CUANDO ESTEMOS SEGUROS)
Por último, una vez comprobado que todo funciona correctamente  -y si me lo permitís, pasados unos días- ya sólo queda actualizar nuestro zpool, si fuese necesario, para comprobarlo, utilizaremos la opción <status> del comando <zpool>, por ejemplo así:

havoc@h100:~$ pfexec zpool status
  pool: rpool
 state: ONLINE
status: The pool is formatted using a legacy on-disk format.  The pool can still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the pool will no longer be accessible on software that does not support feature flags.
  scan: resilvered 4,10G in 0h1m with 0 errors on Sat Apr 16 13:30:56 2011
config:

        NAME        STATE     READ WRITE CKSUM
        rpool       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            c2d0s0  ONLINE       0     0     0
            c3d1s0  ONLINE       0     0     0

errors: No known data errors

¿Y qué hago si falla?
Esta pregunta tiene una solución sencilla:

"activar el Boot Environment anterior y reiniciar"

El proceso de "rollback" es tan sencillo como volver a iniciar con el Boot Environment que funcionaba correctamente, para ello, tenemos tres escenarios:

a) Nuestro sistema arranca hasta level 3.
En este caso, simplemente activaremos el boot environment anterior utlizando el comando

havoc@h100:/$ pfexec beadm activate <NombreAnteriorBoot>

b) Nuestro sistema no arranca.
Este caso suele ser más problemático porque necesitamos acceso a la consola, e iniciar el sistema en Single Mode y activar el Boot Environment anterior.

c) Nuestro sistema no arranca y hemos actualizado la versión de zpool
Este es un escenario un poco "raro", ya que por algún motivo, hemos certificado que el nuevo Boot Environment era correcto, hemos actualizado la versión del zpool y ahora queremos "echarlo para atrás".

La solución sencilla, pasaría por iniciar desde un CDROM -o similar- una versión de Solaris "compatible" con esa versión de zpool, reparar lo que falle y volver a iniciar.

Conclusiones
Hemos visto en estas dos partes cómo utilizar los Boot Environments para actualizar nuestros equipos Solaris a versiones nuevas, o para hacer experimentos con un "rollback" sencillo.

Hay que decir que en función de lo que queramos actualizar, deberemos realizar más o menos tareas, por ejemplo, si queremos actualizar PostgreSQL y no queremos bajar la base de datos, tendremos que tirar de WAL ... pero eso es otro post.

Espero vuestros comentarios y sugerencias!


<< Cómo trabajar con Boot Environments - Parte 1

Cómo trabajar con Boot Environments en Solaris - Parte 1

Introducción
Los boot environments son una característica que Solaris introdujo en la versión 8, es decir, hace ya mucho tiempo de aquello. Sin embargo, parece que esta característica pasa desapercibida entre muchos SysAdmin de Solaris y realmente es algo "vital" para nuestros sistemas de producción.

Como decía mi padre, "Los experimentos, con gaseosa", pues bien, los boot environments son lo más parecido a la gaseosa que tenemos en Solaris, ;)

Qué es un boot environment
Como su nombre indica, es un arranque completo y totalmente diferente. Esto, nos permite por ejemplo, parchear un sistema "OnLine" sin tener que detener sus servicios. Comprobar que todo está correcto e iniciar la máquina con el nuevo boot environment si todo está correcto.

De esta forma, pasamos de tener un tiempo de parada de X horas a el tiempo que tarde la máquina en iniciarse -mucho menos que X, por supuesto- y lo más importante, tenemos un proceso de "rollback" rápido y sencillo.

Cómo funcionan los boot environments
La gestión de los boot environments se realiza mediante el comando <beadm> el cual nos proporciona las siguientes opciones:

1. Ver todos los boot environments que tenemos disponibles
2. Activar/Desactivar boot environments
3. Crear/Destruir boot environments
4. Montar/Desmontar boot environments

Vamos a ver algunos ejemplos, y así entendemos esta utilidad tan potente.

Ver todos BE 
Para ver todos los BE que disponemos en el sistema deberemos utilizar la opción <list> del comando <beadm>, por ejemplo:

havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       441.51M static 2013-03-07 23:57
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          103.78G static 2011-04-16 04:41  

Los datos más importantes que vamos a ver en esta primera parte son los siguientes:

• BE: Nombre único del boot
• Active: Si es el boot activo, es decir, el que estamos ejecutando ahora mismo
• MountPoint: Dónde esta montado -luego veremos para qué es interesante-
• Space: El espacio que ocupa
• Policy: El tipo de boot -lo veremos con más detalle en la segunda parte-

Crear un nuevo BE
Para crear un nuevo BE, deberemos utilizar la opción <create> con un nombre de BE nuevo y único -en nuestro caso se llama "PreUpdate"-

havoc@h100:~$ pfexec beadm create PreUpdate

Si ahora volvemos a ver todos los BE que existen en el sistema, veremos cómo hay uno nuevo.

havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       489.39M static 2013-03-07 23:57
PreUpdate -      -          122.0K  static 2013-03-08 10:15
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          103.81G static 2011-04-16 04:41

Cuándo crear un nuevo BE
Lo cierto es que, tanto si tienes equipos de pruebas, como si no, siempre que quieras hacer algún cambio en los sistemas de producción, deberías comprobar que todo va a ir bien, por ejemplo, si queremos realizar las pruebas de una actualización que vamos a instalar, un nuevo parche, un nuevo paquete, etc.

Destruir un BE
Para destruir un BE deberemos tener en cuenta dos cosas importantes:

• El BE no puede estar montado, es decir, el valor de Mountpoint debe ser "-"
• El BE no puede ser el activo, es decir, el valor de Active debe ser "-"

 Si cumplimos con esas condiciones, simplemente deberemos utilizar la opción <destroy> y el nombre del BE a eliminar, en nuestro caso "PreUpdate"

havoc@h100:~$ pfexec beadm destroy PreUpdate
Are you sure you want to destroy PreUpdate?  This action cannot be undone(y/[n]): y

Comprobamos cómo lo ha destruido utilizando la opción <list> -como en casos anteriores-

havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       532.16M static 2013-03-07 23:57
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          103.83G static 2011-04-16 04:41 

NOTA: Aunque al destruir un BE se nos avisa, aunque no está de más que lo recordemos: Esta acción no puede deshacerse

Montar un BE en un directorio
Hasta ahora, no hemos hecho más que crear y destruir BE, sin embargo, en sí eso no aporta nada, verdad ...

Es hora de montar nuestro nuevo BE y poder trabajar con él, para ello, deberemos utilizar la opción <mount> seguida del <nombre> y del <path de montaje>.

En nuestro caso el BE será "PreUpdate" y el path de montaje será "/tmp/preupdate" -al igual que sucede con el comando <mount> el path de montaje deberá existir-

havoc@h100:~$ pfexec mkdir /tmp/preupdate
havoc@h100:~$ pfexec beadm create PreUpdate
havoc@h100:~$ pfexec beadm mount PreUpdate /tmp/preupdate
havoc@h100:~$ pfexec beadm list
BE        Active Mountpoint     Space   Policy Created         
--        ------ ----------     -----   ------ -------         
HSeries   -      /mnt           546.31M static 2013-03-07 23:57
PreUpdate -      /tmp/preupdate 122.0K  static 2013-03-08 10:28
solaris   -      -              3.06M   static 2011-04-16 04:06
solaris-1 NR     /              103.88G static 2011-04-16 04:41

 Si nos situamos en el path de nuestro nuevo BE -/tmp/preupdate- veremos que contiene la estructura idéntica a nuestro "sistema online", realmente, hemos realizado un "snapshoot" del sistema -entraremos en más detalle en la segunda parte-

havoc@h100:~$ cd /tmp/preupdate
havoc@h100:/tmp/preupdate$ ls
bin   cdrom  devices  export  kernel  media  net  platform  root   sbin  tmp  usr boot  dev    etc      home    lib     mnt    opt  proc  rpool  system  u01  var

Desmontar un BE
Para desmontar un BE simplemente deberemos utilizar la opción <umount> seguido del nombre del BE. Continuando con nuestro ejemplo,

havoc@h100:/$ pfexec beadm umount PreUpdate
havoc@h100:/$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       546.31M static 2013-03-07 23:57
PreUpdate -      -          144.0K  static 2013-03-08 10:28
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          104.11G static 2011-04-16 04:41

Activar un BE
Una vez tenemos nuestro BE creado, podemos hacer que sea nuestro BE de arranque por defecto. Esto se llama "activar un BE". Para ello, utilizaremos la opción <activate> y el nombre del BE que queremos activar.

Continuando con nuestro ejemplo, queremos activar el BE "PreUpdate" para que la próxima vez que inicie el sistema sea con este BE.

havoc@h100:/$ pfexec beadm activate PreUpdate
havoc@h100:/$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       546.31M static 2013-03-07 23:57
PreUpdate R      -          103.83G static 2013-03-08 10:28
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 N      /          204.15M static 2011-04-16 04:41 

Fijaros en el valor de "Active" que ahora nuestro BE "PreUpdate" tiene una "R" -de Root Boot-. La "N" que aparece en el BE "solaris-1" indica que es el "actual"

Para volver a ponerlo sobre el actual, simplemente activamos el BE que cuente con la opción "Active=N", por ejemplo:

havoc@h100:/$ pfexec beadm activate solaris-1
havoc@h100:/$ pfexec beadm list
BE        Active Mountpoint Space   Policy Created         
--        ------ ---------- -----   ------ -------         
HSeries   -      /mnt       546.31M static 2013-03-07 23:57
PreUpdate -      -          166.0K  static 2013-03-08 10:28
solaris   -      -          3.06M   static 2011-04-16 04:06
solaris-1 NR     /          104.21G static 2011-04-16 04:41


Conclusiones
En esta primera parte, hemos sentado las bases para las siguientes entregas donde veremos realmente la potencia de esta funcionalidad.

Aunque aquí solo hemos expuesto algo muy sencillo, y en apariencia sin mucha utilidad, te aseguro que si dominas los BE estarás mucho más tranquilo con los Upgrades de sistemas de producción.

Error en python "sslv3 alert handshake failure" sobre OpenIndiana

Introducción
Hace unos días quería hacer unas pruebas sobre una idea que llevaba en la cabeza para nuestro appliance HSeries mientras iba en el AVE, y, decidí utilizar una máquina virtual que tenía en mi equipo para hacer las pruebas.

Claro que no sabía que me encontraría con un error que, en los sistemas de producción y testing no se repetía, así que estuve volviéndome loco investigando el asunto.

El error
El script escrito en python hace una llamada a un servidor mediante SSL y carga un XML para luego utilizarlo, sin embargo, cuando llamaba en la máquina virtual al script obtenía un error en Python

hseries$ python havoc.boot  
(c) Havoc Technologies 2007-2013
Can't Load XML
Traceback (most recent call last):
  File "havoc.boot", line 42, in <module>
    req = urllib2.urlopen(locator)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 126, in urlopen
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 394, in open
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 412, in _open
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 372, in _call_chain
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1207, in https_open
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1174, in do_open
URLError: <urlopen error [Errno 1] _ssl.c:503: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure>


Las pruebas
Entendía que tal vez sería un problema del certificado, así que, cree uno nuevo autofirmado -aunque no tenía mucho sentido ya que URLLib2 no comprueba los certificados-, cambié las versiones de Tomcat, de Java, etc. y nada.

No fue hasta que por desesperación, hice la prueba sobre una máquina FreeBSD con el mismo certificado, misma Java, mismo Tomcat y ... funcionó. ¿Entonces el problema está en mi máquina virtual, no?

El problema
Después de muchas pruebas, comprobé la versión de OpenIndiana -si, ya sé que lo debería haber hecho antes, pero pensaba que era la misma-, y, es aquí donde está el problema. En la versión OpenIndiana b148 la versión de OpenSSL es la 0.9.8.15 -podemos verla utilizando el comando pkg con la opción info-.

havoc@h100:/# pkg info openssl
          Name: library/security/openssl
       Summary: OpenSSL - a Toolkit for Secure Sockets Layer (SSL v2/v3) and Transport Layer (TLS v1) protocols and general purpose cryptographic library
   Description: OpenSSL is a full-featured toolkit implementing the Secure
                Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1)
                protocols as well as a full-strength general purpose
                cryptography library.
      Category: System/Security
         State: Installed
     Publisher: openindiana.org
       Version: 0.9.8.15
 Build Release: 5.11
        Branch: 0.148
Packaging Date: 25 de noviembre de 2010 00:12:56
          Size: 10.08 MB
          FMRI: pkg://openindiana.org/library/security/openssl@0.9.8.15,5.11-0.148:20101125T001256Z

Sin embargo, en el build 151a aunque la versión es igual 0.9.8.15 el tamaño del paquete es inferior.

havoc@h1000:~$ pfexec pkg info openssl
          Name: library/security/openssl
       Summary: OpenSSL - a Toolkit for Secure Sockets Layer (SSL v2/v3) and Transport Layer (TLS v1) protocols and general purpose cryptographic library
   Description: OpenSSL is a full-featured toolkit implementing the Secure
                Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1)
                protocols as well as a full-strength general purpose
                cryptography library.
      Category: System/Security
         State: Installed
     Publisher: openindiana.org
       Version: 0.9.8.15
 Build Release: 5.11
        Branch: 0.151.1
Packaging Date: 12 de septiembre de 2011 02:41:35
          Size: 9.81 MB
          FMRI: pkg://openindiana.org/library/security/openssl@0.9.8.15,5.11-0.151.1:20110912T024135Z

Solución
Así que cree una máquina virtual nueva, con la versión OpenIndiana 151a, volví a ejecutar el script y ... listo, ningún problema.

Conclusiones
Cuando vayas a hacer unas pruebas aunque sea en un viaje en AVE para pasar el tiempo ... asegúrate de tener el mismo nivel de parcheo, versiones, etc. que los equipos de producción.

Pedir disculpas a todos vosotros por este tiempo de "silencio"

Hola a todos,

Lo cierto es que quiero pedir disculpas a todos vosotros, los que me seguís desde hace mucho y los que no, por no haber actualizado el blog durante estos últimos meses.

La verdad es que, como ya os he comentado en otras entradas, me encuentro bastante ocupado con el tema de SafeChildren Guardian y con apenas tiempo para poder llegar a todo.

Aunque, también os comento que poco a poco voy liberándome de cosas y ... eso significa que puedo volver a dedicar tiempo al Blog y contestar a las preguntas que me hacéis por eMail o directamente desde Blogger.

Tengo muchas cosas en el tintero, como por ejemplo, seguir con el tema de PostgreSQL de Backup y Replicación, El sistema de paquetes de OpenIndiana y algunas otras cosas ...

Os prometo que en unas semanas tendréis nuevo contenido, seguro! Además, poco a poco iré contestando a las dudas, y, si veis que no os he contestado, por favor, mandarme un eMail para recordármelo, :D

Muchas Gracias a todos,

Urko

SafeChildren Guardian entrevista en la radio

Introducción
Esta entrada está un poco fuera de la temática normal de mi blog, pero creo que es interesante también poder contar algunas cosas diferentes, no?

Como ya sabéis -y si no os lo cuento- soy el responsable de tecnología de Havoc Tecnologies y, entre los proyectos que llevo, está un Sistema de Control Parental de última generación y basado en análisis de Pautas de Comportamiento- de ahí muchas cosas de las que hemos hablado, como por ejemplo, Apache Hadoop, PostgreSQL y, por supuesto Solaris-.

El producto se llama SafeChildren Guardian  y fui entrevistado en Radio Aragón -en el programa de Aragón 3.0- sobre la conbinación de Internet, Menores y las soluciones existentes.

Aunque fue muy resumido, lo cierto es que fue una entrevista muy agradable y, al menos, pudimos aportar nuestro granito de arena a esos padres que, a veces, ven como sus hijos les superan en conocimientos tecnológicos.

Estoy encantado de ver como cada vez más gente se implica en el tema de los menores e Internet, y, espero, que la solución SafeChildren Guardian les aporte "ese punto de tranquilidad" a todos los padres y madres preocupados por sus hijos.