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.

Login Incorrect al lanzar el comando zlogin sobre una zona de solaris

Introducción
Puede que alguna vez os pase que al intentar conectar a una zona de Solaris, el sistema os muestre un error diciendo que los roles sólo puede ser asumidos por usuarios autorizados.

Esto se debe a que hemos modificado el usuario "root" y ahora es un "role", por ello, si utilizamos el comando <zlogin _nombre_zona> nos denegará la conexión, por ejemplo:

havoc@h1-master-01:~$ pfexec zlogin www-test
[Connected to zone 'www-test' pts/3]
Roles can only be assumed by authorized users
Login incorrect


[Connection to zone 'www-zone' pts/3 closed]


La solución
Existen dos soluciones muy sencillas que a continuación os muestro. La primera es utilizar una opción en el comando <zlogin> y la segunda es volver a poner a <root> como usuario.

Utilizar un usuario con el role <root> en la zona
Podemos utilizar un usuario con el role <root> en la zona, y mediante la opción <-l usuario> conectarnos, por ejemplo, si tenemos el usuario "havoctec" en la zona "www-test"

havoctec@www-test:~$ id
uid=901(havoctec) gid=10(staff)
havoctec@www-test:~$ roles
root

havoctec@www-test:~$ logout

[Connection to zone 'www-test' pts/3 closed]

havoctec@hseries-master-01:~$ pfexec zlogin -l havoctec www-test

[Connected to zone 'www-test' pts/3]

Last login: Wed Mar 14 10:54:47 on pts/3

OpenIndiana (powered by illumos)    SunOS 5.11    oi_151a    September 2011

havoctec@www-test:~$

Configurar la cuenta de <root> como usuario y no como <role>
La otra solución -aunque a mi no me parece la mejor- es configurar la cuenta de <root> como usuario y no <role>, para ello, simplemente deberemos editar el archivo </etc/user_attr> y modificamos el valor de la propiedad <type=role> por <type=normal>, por ejemplo,

havoctec@hseries-master-01:~$ cat /etc/user_attr|grep ^root
root::::min_label=admin_low;lock_after_retries=no;auths=solaris.*,solaris.grant;audit_flags=lo\:no;profiles=All;clearance=admin_high;type=role

Conclusiones
Es muy sencillo seguir utilizando roles dentro de las zonas, y de esta forma, continuar con la seguridad extendida que nos proporciona RBAC.

Referencias

• RBAC, Roles y Privilegios en Solaris 10 y OpenIndiana
• Comandos básicos y no tan básicos de Solaris
• Modelo de Seguridad de Solaris/OpenIndiana - Parte 1

Cómo ver el porcentaje de iNodes Libres y Usados en OpenIndiana

Introducción
Alguna vez os ha pasado encontrar en el syslog el mensaje de "out of inodes", si nunca lo habéis encontrado mejor :D.

El problema viene porque el sistema de ficheros se está quedando -o se ha quedado sin inodes libres- y no puede crear/modificar los archivos que contiene ese FileSystem.

Principalmente me he encontrado con este problema cuando parametrizaba un servidor de cache squid con unos valores muy elevados de L1 y L2 en cache_dir y la unidad no era lo suficientemente grande.

Simplemente deberemos utilizar la opción <-i> del comando </usr/gnu/bin/df> de GNU ya que Solaris no lo incluye, por ejemplo:

havoc@hseries:~$ df -i /
Filesystem         Inodes   IUsed   IFree IUse% Mounted on
rpool/ROOT/solaris 861385   593804  86079 1%    /

Referencias

• Comandos básicos y no tan básicos de Solaris 
• Instalación OpenIndiana paso a paso
• Cómo crear un FileSystem en Memoria en Solaris/OpenIndiana

Cómo desactivar ACPI en OpenIndiana

Introducción
OpenIndiana incluye soporte para el sistema ACPI, sin embargo, en algunas ocasiones, puede que nuestro sistema no pueda iniciarse correctamente, y debamos desactivarlas.

Para poder desactivar el sistema ACPI debemos utilizar la opción <acpi-user-options=MODO> en nuesto menú de arranque grub en la sección de <kernel>, donde "modo" será uno de los siguientes valores:

• acpi-user-options=8, Desactiva el nuevo sistema ACPI y deja el sistema en formato "Legacy".
• acpi-user-options=4, Desactiva el nuevo y sistema "Legacy" aunque permite seguir definiendo los Threads de los micros HyperThread a traves de ACPI.
• acpi-user-options=2, Desactiva todo el ACPI por completo.

Deberemos utilizar las opciones de mayor a menor -8,4,2- si encontramos problemas en nuestro OpenIndiana.


Por ejemplo, si queremos poner la opción de "desactivado por completo" en la entrada "HSeries", editaremos el archivo /rpool/boot/grub/menu.lst de la siguiente forma:

havoc@h1master:~$ pfexec vi /rpool/boot/grub/menu.lst
title HSeries
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/hseries
kernel$ /platform/i86pc/kernel/$ISADIR/unix -m verbose -B $ZFS-BOOTFS,acpi-user-options=2
module$ /platform/i86pc/$ISADIR/boot_archive

Conclusión
Alguna vez podemos encontrarnos con problemas de arranque de OpenIndiana -sobre todo en VMWare ESX- que se solucionan en la mayoría de los casos poniendo la opción de ACPI a 2

Referencias

• Comandos básicos y no tan básicos de Solaris 
• Instalación OpenIndiana paso a paso
• Diferencias entre Procesadores Virtuales y Físicos
• Configuring Solaris ACPI at boot

Cómo clonar una tabla en PostgreSQL

Introducción
Alguna vez hemos necesitado clonar una tabla, tanto estructura como contenido desde el propio SQL sin tener que recurrir a <pg_dump>.
Tal vez alguno esté pensando en un CREATE TABLE AS SELECT ... pero lo cierto es que esta solución no nos crea los modificadores, índices, etc.

Sin embargo, no os preocupéis, que en PostgreSQL se puede hacer todo, o casi, y este caso sí que está muy resuelto.

Pasos Ejemplo de Clonado "completo"
A continuación os muestro -de una forma sencilla- lo que vamos a hacer, paso a paso para que no resulte complicado:

1. Crearemos una tabla llamada test con los campos company y homepage
2. Añadiremos un índice único en company
3. Añadiremos un par de compañías
4. Crearemos una tabla nueva copiando el contenido de la tabla con un CREATE TABLE  AS SELECT para comprobar cómo no clona los índices, defaults, etc.
5. Utilizaremos un clonado completo

Una vez explicado, vamos a ponernos manos a la obra

search=> CREATE TABLE test(company VARCHAR(20) NOT NULL, homepage VARCHAR(40) NOT NULL);
CREATE TABLE
search=> CREATE UNIQUE INDEX test_company_uq ON test(company);
CREATE INDEX
search=> \d test
             Table "public.test"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 company  | character varying(20) | not null
 homepage | character varying(40) | not null
Indexes:
    "test_company_uq" UNIQUE, btree (company)

Ahora, añadimos un par de registros

search=> INSERT INTO test(company,homepage) VALUES('SFChildren', 'http://www.sfchildren.com');
INSERT 0 1
search=> INSERT INTO test(company,homepage) VALUES('HavocTec', 'http://www.havoctec.com');
INSERT 0 1
search=> SELECT * FROM test;
  company   |         homepage         
------------+---------------------------
 SFChildren | http://www.sfchildren.com
 HavocTec   | http://www.havoctec.com
(2 rows)

Copiamos su contenido utilizando CREATE TABLE newTable AS SELECT * FROM sourceTable y comprobaremos su resultado

search=> CREATE TABLE test2 AS SELECT * FROM test;
SELECT
search=> \d test2
             Table "public.test2"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 company  | character varying(20) |
 homepage | character varying(40) |

Como podemos observar, lo primero que nos falta es el índice que hemos creado <test_company_uq> y los modificadores <NOT NULL> en ambos campos.

Es decir, utilizando esta forma copiamos el contenido y estructura de campos pero no sus modificadores, pero, que no cunda el pánico, vamos a ver cómo lo podemos hacer de una forma sencilla.

Borramos la tabla test2 que hemos creado para poder volver a clonarla, esta vez de forma completa.

search=> DROP TABLE test2;
DROP TABLE

Clonar "todo", para ello vamos a utilizar los modificadores LIKE tabla INCLUIDING [DEFAULTS | CONSTRAINTS | INDEXES]. En nuestro ejemplo, queremos "clonar" toda la estructura  así que utilizamos todas.

search=> CREATE TABLE test2 (LIKE test INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES);
CREATE TABLE
search=> \d test2
             Table "public.test2"
  Column  |         Type          | Modifiers
----------+-----------------------+-----------
 company  | character varying(20) | not null
 homepage | character varying(40) | not null
Indexes:
    "test2_company_key" UNIQUE, btree (company)

Conclusiones
Aunque el ejemplo es sencillo, la idea era mostrar la potencia de la opción LIKE ... INCLUIDING sin tener que mostrar una estructura muy compleja.

Además, para aquellos que no os guste el SQL, siempre podéis utilizar el comando <pg_dump> para exportar una tabla.


Referencias

• Copias de Seguridad en PostgreSQL - Parte 1
• Instalación de PostgreSQL en OpenIndiana - Parte 1

Cómo buscar el profile necesario para ejecutar un comando en RBAC

Introducción
Hemos hablado sobre el RBAC, Modelo de Seguridad en Solaris y Cómo utilizarlo, sin embargo, cuando se está empezando a utilizarlo nos surge una duda: Qué profile asigno para que pueda ejecutar el comando XYZ?

Buscar el Profile más adecuado
Imaginemos por ejemplo que queremos asignar privilegios a un "rol" para que sea capaz de actualizar e instalar paquetes en nuestro Solaris/OpenIndiana.

Sabemos que para ello, necesitamos ejecutar el comando , así que hacemos una búsqueda en el archivo -donde se encuentran declarados los archivos y sus profiles-

havoc@hseries:~$ cat /etc/security/exec_attr | grep "pkg"
Software Installation:solaris:cmd:::/usr/bin/pkg:uid=0
Software Installation:suser:cmd:::/usr/bin/pkginfo:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgmk:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgparam:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgproto:uid=0
Software Installation:suser:cmd:::/usr/bin/pkgtrans:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgadd:uid=0;gid=bin
Software Installation:suser:cmd:::/usr/sbin/pkgask:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgchk:uid=0
Software Installation:suser:cmd:::/usr/sbin/pkgrm:uid=0;gid=bin

Como podemos observar, el "Profile" es , así que, simplemente deberemos asignarlo a nuestro "rol" o usuario.

Si queremos asignarlo al "role" haremos lo siguiente:

havoc@hseries:~$ pfexec rolemod -P 'Software Installation' jmsserver
havoc@hseries:~$ pfexec profiles jmsserver
jmsserver:
          Software Installation
          ZFS File System Management
          Basic Solaris User
          All
havoc@hseries:~$ pfexec su - jmsserver
OpenIndiana     SunOS 5.11      oi_148  November 2010
$ pkg rebuild-index

PHASE                                          ITEMS
Indexing Packages                            502/502

Conclusiones
RBAC nos permite tener un control muy preciso sobre los accesos y privilegios de nuestros roles/usuarios. Además, debemos tener en cuenta que podemos definirnos nuestros propios "Profiles" para tener justo lo que queremos.

Referencias
Comandos básicos y no tan básicos de Solaris
Modelo de Seguridad de Solaris/OpenIndiana - Parte 1

El comando "at" de Solaris/OpenIndiana

Introducción
El comando <at> de Solaris nos permite planificar la ejecución de un comando en un intervalo de tiempo. A diferencia de cómo gestionar el cron en Solaris, donde se pueden definir repeticiones <at> nos permite ejecutar un comando "luego".

El formato de <at> es el siguiente:

/usr/bin/at [-c | -k | -s] [-m] [-f file] [-p project] [-q queuename] timespec

donde

• -c indica que queremos utilizar <C Shell>
• -k indica que queremos utilizar <Korn Shell>
• -s indica que queremos utilizar <Bash Shell>
• -f indica que queremos utilizar <file> como comando en vez de la entrada estandar
• -p indica que queremos utilizar <project> como proyecto para la ejecución
• -q indica el nombre de la <queue> que queremos utilizar
• timespec indica cuándo queremos ejecutarlo

Colas de Ejecución
<at> dispone de diferentes <queue> de ejecución que nos van a permitir gestionar nuestras peticiones. Estas <queue> pueden ser letras en minúsculas de la <a ... z> donde debemos tener en cuenta que la <queue>b> está reservada para <batch> y la <c> para <cron>

La cola de ejecución <batch>
Este tipo especial de <queue> nos permite ejecutar los comandos en modo "secuencial" cuando el equipo está <idle> y, por lo tanto, no nos interfiere en la carga del sistema.

Su formato no requiere una definición de tiempo -ya que lo ejecutará cuando pueda-, por ejemplo

havoc@h100:/# echo "ls >/tmp/ls.batch"| at -q b
commands will be executed using /bin/bash
job 1308472386.b at dom jun 19 10:33:06 2011

Variables definidas para definir la hora de ejecución <timespec>
Existen algunas definiciones ya establecidas para <timespec<, por ejemplo, <now>, <midnight>, etc.

A estas definiciones podemos añadirles (utilizando +) un intervalo, por ejemplo, <minute, hour, day, week> con lo que tendremos una expresión como esta:

havoc@h100:/# echo "ls" | at now + 1 minute

Ver el estado de las <queue>
Para ver el estado de las colas de ejecución, comandos pendientes y la fecha/hora planificada, utilizaremos la opción <-l>, por ejemplo

havoc@h100:/# at -l
user = root     1308473222.a    dom jun 19 10:47:02 2011

Borrar un comando de la <queue>
Podemos borrar un comando utilizando la opción <-r {id}>, por ejemplo,

havoc@h100:/# echo "ls > /tmp/ls.at" | at now + 5 minutes
commands will be executed using /bin/bash
job 1308473822.a at dom jun 19 10:57:02 2011
havoc@h100:/# at -l
user = root     1308473822.a    dom jun 19 10:57:02 2011
havoc@h100:/# at -r 1308473822.a
havoc@h100:/# at -l

Permitir o denegar la ejecución de comandos
Al igual que sucede con <cron>, podemos establecer qué usuarios pueden ejecutar comandos mediante <at o cron> editando el archivo </etc/cron.d/at.allow> y denegar editando el archivo </etc/cron.d/at.deny>

Además, debemos tener en cuenta que si el usuario/role no tiene establecida una contraseña, no podrá ejecutar comandos.

Algun ejemplo más ...
Por ejemplo, si queremos que se lance el sistema de actualización de paquetes hoy por la noche, podemos utilizar el siguiente formato:

havoc@h100:/# echo "pkg refresh --full" | at -q z midnight
commands will be executed using /bin/bash
job 1306792800.z at mar may 31 00:00:00 2011

Conclusiones
Este comando -a veces desconocido- nos puede solucionar algún que otro problema, sobre todo cuando queremos dejar "algo para luego", o si queremos aprovecharnos de la ejecución en formato "batch".

Referencias

• Cómo editar el crontab en Solaris/OpenIndiana
• Cómo funciona el sistema de paquetes IPS en OpenIndiana

Cómo funciona el sistema de instalación por paquetes IPS en OpenIndiana y Solaris - Parte 1

Introducción
Entre las muchas novedades que introdujo OpenSolaris, se encuentran el nuevo formato de instalación de paquetes (IPS).

Esta nueva forma de instalación elimina los problemas de dependencias que podíamos tener en el formato anterior (SrV4) aunque, también nos incluye algunas limitaciones que veremos cómo podemos evitarlas.

Sistema IPS
El formato de paquetes IPS es muy parecido al sistema utilizado por FreeBSD, es decir, nos permite instalar, actualizar y desinstalar de una forma sencilla un paquete y sus dependencias, todo ello utilizando un único comando <pkg>

Funcionamiento básico
Su funcionamiento consiste en incluir repositorios donde podemos encontrar los paquetes -en formato binario-, por lo tanto, disponemos de diversas fuentes desde la cuales instalar.

Estos repositorios se pueden encontrar en una dirección web pública, por ejemplo, http://pkg.x86.havoctec.com/ o en un servidor interno, http://localhost:1000/.

Cuando al principio os comentaba sobre "algunas limitaciones" esta era una de ellas, el hecho de necesitar de un acceso a Internet, pero como veis, es muy sencillo de solucionar creando un repositorio "interno" desde el cual instalar los paquetes -lo veremos más adelante-


Repositorios
Un repositorio es un servicio web que nos proporciona el funcionamiento de control y acceso. En OpenIndiana/Solaris debemos activar y configurar el servidor <svc:/application/pkg/server:default> para poder gestionarlo.

Cada repositorio está "asociado" un "publisher", es decir, quién lo publica. De esta forma, si instalamos el paquete <nagios-core> desde el repositorio <http://pkg.x86.havoctec.com/>, nuestro sistema IPS, buscará las actualizaciones siempre en este repositorio.

Para evitar esto, es decir que los paquetes se puedan actualizar desde cualquier repositorio hay que utilizar la opción <--non-sticky> pero luego hablamos con más detalle de todo esto.

Gestionar los Repositorios de Paquetes y Publisher
Como hemos comentado, todo el sistema de administración se realiza utilizando el comando <pkg>, para ello, debemos utilizar las opciones <publisher y unset-publisher>

Ver los Publicadores -publisher-
Debemos utilizar la opción <publisher> para obtener el detalle de los repositorios instalados, y su estado, por ejemplo

havoc@tikko:~$ pfexec pkg publisher
PUBLISHER           TYPE                  STATUS   URI
openindiana.org     (preferred)  origin   online   http://pkg.openindiana.org/dev/
opensolaris.org                  origin   online   http://pkg.openindiana.org/legacy/

Añadir un nuevo publisher
Para añadir un publisher, simplemente deberemos utilizar la opción <publisher> del comando <pkg>.

Por ejemplo, para añdir el publicador HavocTec.Com utilizaremos el siguiente comando, donde la opción <-O< representa la URL del repositorio, y havoctec.com es el nombre del publisher.

havoc@tikko:~$  pfexec pkg set-publisher -O http://pkg.x86.havoctec.com/ havoctec.com

Y nos quedará de la siguiente forma, donde vemos ahora nuestro nuevo publisher "HavocTec.Com"

havoc@tikko:~$ pfexec pkg publisher
PUBLISHER                             TYPE     STATUS   URI
openindiana.org          (preferred)  origin   online   http://pkg.openindiana.org/dev/
opensolaris.org                       origin   online   http://pkg.openindiana.org/legacy/
havoctec.com                          origin   online   http://pkg.x86.havoctec.com/

Modificar la URL del repositorio
Alguna vez puede que necesitemos modificar la URL en la que se encuentra el repositorio del publisher, para ello, deberemos utilizar la opción <set-publisher< con las opciones <-G direccion_a_eliminar> y <-g direccion_nueva>.

Por ejemplo, para modificar la dirección del repositorio <http://pkg.x86.havoctec.com/> por <http://pkg.havoctec.com/> haremos lo siguiente:

havoc@tikko:~$ pfexec pkg set-publisher -G http://pkg.x86.havoctec.com/ -g http://pkg.havoctec.com/ havoctec.com

Eliminar un Publisher
Para eliminar un publisher, simplemente deberemos utilizar la opción <unset-publisher>.

Por ejemplo, para eliminar el  publisher <havoctec.com> haremos lo siguiente:

havoc@tikko:~$ pfexec pkg unset-publisher havoctec.com

Instalar nuevos paquetes
Ya hemos utilizado muchas veces el comando, pero hasta ahora no habíamos entrado en detalle de su funcionamiento, :D. Para instalar un paquete nuevo, siemplemente deberemos ejecutar el comando <pkg install {frmi}>, por ejemplo para instalar el core de nagios, haremos lo siguiente

havoc@tikko:~$ pfexec pkg install nagios-core
                Packages to update:     1
           Create boot environment:    No
DOWNLOAD                 PKGS       FILES    XFER (MB)
Completed                1/1         2/2      0.0/0.0

PHASE                                        ACTIONS
Update Phase                                     3/3

PHASE                                          ITEMS
Package State Update Phase                       2/2
Package Cache Update Phase                       1/1
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                                1/1

havoc@tikko:~$ pfexec svcs nagios
STATE          STIME    FMRI
disabled        1:15:17 svc:/application/network/nagios:server

Limitaciones de IPS
Una de las limitaciones que tenemos en el nuevo sistema de paquetes es que no podemos ejecutar scripts -como antes teníamos post-install, pre-install, etc.- por lo tanto, algunas de las características más "avanzadas" de OpenIndiana/Solaris no se pueden llevar a cabo, por ejemplo crear nuevas autorizaciones, desde el propio sistema de instalación.

Pero, como siempre, tenemos una solución, bueno en este caso hay muchas y diversas, aunque yo he utilizado una sencilla: Crear un script <post-install> en el paquete y llamarlo luego "a mano", por ejemplo:

havoc@tikko:/$ pfexec sh /usr/local/nagios/scripts/post-install

Si estáis interesados en "el por qué" aquí os dejo algunos links a las explicaciones: pkg no script zone y pkg postinstall using smf

Eliminar un paquete
Para eliminar un paquete, simplemente utilizaremos la opción <uninstall> seguido del nombre del paquete, por ejemplo, si queremos eliminar <nagios-core> haremos lo siguiente:

havoc@tikko:/$ pfexec pkg uninstall nagios-core
                Packages to remove:     1
           Create boot environment:    No
               Services to restart:     1
PHASE                                        ACTIONS
Removal Phase                                   1/72
Removal Phase                                  72/72

PHASE                                          ITEMS
Package State Update Phase                       1/1
Package Cache Update Phase                       1/1
Image State Update Phase                         2/2

PHASE                                          ITEMS
Reading Existing Index                           8/8
Indexing Packages                                1/1

Conclusiones
En esta primera parte hemos vista algunas funciones básicas de IPS, en las siguientes veremos cómo crear un servidor IPS para tener réplicas locales y, de esta forma, no tener que depender de la conexión de Internet para las instalaciones.

Además, os dejo el link del repositorio público que he creado -gracias a HavocTec por cederme recursos- para que todas las instalaciones que os voy enseñando, se puedan instalar con <pfexec pkg instal {frmi}> y simplificar el proceso.

Aunque actualmente no hay muchos paquetes, poco a poco ire subiendo los principales: PostgreSQL, Apache HTTP, Nagios, etc.


Referencias

• Repositorio HavocTec.Com
• Documentación IPS en OpenSolaris

Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 3

Introducción
En las primeras parte de Crossbow Qué y Cómo Utilizarlo hacíamos una introducción a la tecnología. En esta ocasión vamos a ver una nueva utilidad <flowadm> que nos permitirá aplicar QoS de una forma muy sencilla.

Flow o Flujos
Los <flow> nos permiten discriminar el tráfico en función de unos parámetros, como por ejemplo puerto origen <local_port>, puerto destino <remote_port>, tipo de protocolo <protocol>, etc. y asignarle una prioridad y un ancho de banda.

Cómo utilizar flujos
Supongamos que tenemos un servidor con varias zonas, donde a su vez tenemos instalados diferentes servicios -por ejemplo Apache HTTP y PostgreSQL- y, queremos asignar unos "anchos de banda y prioridades" para garantizar los servicios.

Así crearemos dos flujos -uno para HTTP y otro para PostgreSQL- donde asignemos unos límites y prioridades sabiendo que ninguno de ellos "usará el ancho de banda del otro" y, de esta forma garantizando nuestros servicios.

Gestión de Flujos
Aunque pueda parecer que es lo mismo que veíamos en la Crossbow y Cómo utilizarlo en OpenIndiana - Parte 1, tiene algunas pequeñas diferencias.

En sí, se obtiene un mismo objetivo: "Asignar un ancho de banda máximo" sin embargo, si utilizamos la opción de asignarlo al interface todos los servicios estarán limitados -y no podemos establecer un ajuste más fino-, pero si utilizamos <flowadm>, seremos capaces de diferenciar por servicios y, de esta forma, hacer un ajuste muy fino.

El comando <flowadm>
Toda la gestión se realiza utilizando el comand </usr/sbin/flowadm> -al igual que sucedía con <dladm>- y sus opciones son las siguientes:

havoc@h100:~$ pfexec flowadm
usage: flowadm <subcommand> <args>...
    add-flow       [-t] -l <link> -a <attr>=<value>[,...]
                   [-p <prop>=<value>,...] <flow>
    remove-flow    [-t] {-l <link> | <flow>}
    show-flow      [-p] [-l <link>] [<flow>]

    set-flowprop   [-t] -p <prop>=<value>[,...] <flow>
    reset-flowprop [-t] [-p <prop>,...] <flow>
    show-flowprop  [-cP] [-l <link>] [-p <prop>,...] [<flow>]

Nota: Recordar que se debe ejecutar como <root> o con un usuario con los privilegios suficientes. Si no sabes mucho de Privilegios y Roles te aconsejo que mires RBAC: Roles y Privilegios en Solaris/OpenIndiana.

Creación de un <flow>
Para crear un flow, simplemente deberemos utilizar la opción <add-flow> y definir sobre que interface queremos que se aplique. Recordar que ahora podemos utilizar tanto interface virtuales como físicos.

Así que vamos a crear un <flow> que nos asigne siempre una prioridad muy alta a los accesos que realicemos a nuestra PostgreSQL sobre nuestro interface es un virtual <vnic1&gt.

Podemos crear un <flow> utilizando las siguientes opciones como "filtros":

• Puerto: Local <local_port> o remoto <remote_port>
• Tipo Conexión: <transport>, tcp, udp, sctp, icmp, icmp6
• IP: Origen <local_ip> o destino <remote_ip>

Utilizaremos las opciones <transport=TCP> para indicar que será de tipo TCP y que el puerto local <local_port>.

havoc@h100:~$ pfexec flowadm add-flow -l vnic1 -a transport=TCP,local_port=5432 postgres-flow

Ver y Cambiar las propiedades
Como sucedía con los interfaces virtuales, podemos cambiarle las propiedades al flujo "en caliente", para ello, utilizaremos las opciones <show-flowprop> para mostrar las propiedades y <set-flowprop -p {PROPIEDAD=VALOR}< para asignar una nueva.

havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW         PROPERTY     VALUE      DEFAULT   POSSIBLE
postgres-flow maxbw       --         --        ?
postgres-flow priority    --         --        ?

Cuando no tenemos asignado un valor a la propiedad se muestran como "--" para indicarnos que no hay nada.

Y para cambiar una propiedad, por ejemplo asignarle la máxima prioridad haremos lo siguiente:

havoc@h100:~$ pfexec flowadm set-flowprop -p priority=high postgres-flow

Comprobamos sus propiedades, utilizando la opción <show-flowprop>

havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW         PROPERTY   VALUE       DEFAULT        POSSIBLE
postgres-flow maxbw     --          --             ?
postgres-flow priority  high        --             high

Asignar un Ancho de Banda (maxbw)
Para limitar el ancho de banda máximo para el <flow>, deberemos utilizar la propiedad <maxbw>. El valor a asignar será un valor entero y deberemos añadir la escala (K, M o G para Kilobits, Megabits o Gigabits), si no añadimos ninguna, Solaris entenderá que estamos introduciendo Megabits.

Un pequeño apunte sobre la limitación de ancho de banda a tener en cuenta es, si hemos limitado nuestro interface a un determinado valor, nuestro <flow> nunca superará éste aunque se mayor, es decir, si hemos puesto que nuestro interface tiene un valor de <maxbw=10M> y tenemos un flow con <maxbw=20M>, nuestro <flow> nunca nos dará un valor superior a 10M -porque lo limita el interface-

havoc@h100:~$ pfexec flowadm set-flowprop -p maxbw=2M postgres-flow
havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW           PROPERTY    VALUE     DEFAULT     POSSIBLE
postgres-flow  maxbw       2         --          2M
postgres-flow  priority    high      --          high

Resetear todas las propiedades
Cuando se está "jugando" con las propiedades, hay veces que queremos empezar "de cero" para poder asignar otros parámetros, para ello, utilizaremos la opción <reset-flowprop&ght;, por ejemplo:

havoc@h100:~$ pfexec flowadm reset-flowprop postgres-flow
havoc@h100:~$ pfexec flowadm show-flowprop postgres-flow
FLOW         PROPERTY   VALUE       DEFAULT        POSSIBLE
postgres-flow maxbw     --          --             ?
postgres-flow priority  --          --             ?

Eliminar un flujo
Para eliminar un <flow> simplemente utilizaremos la opción <remove-flow> del comando <flowadm>, siguiendo con nuestro ejemplo:

havoc@h100:~$ pfexec flowadm remove-flow postgres-flow

Ver las Estadísticas
Podemos ver las estadísticas de un <flow> utilizando el comando <flowstats> que nos proporcionará los valores totales de los flujos, por ejemplo:

havoc@h100:~$ pfexec flowstat
           FLOW IPKTS  RBYTES  IERRS OPKTS   OBYTES    OERRS
  postgres-flow 14,14K 987,97K 0     15,68K  17,09M    0
       pkg-flow 47     3,13K   0     47      2,54K     0

Si queremos ver las estadísticas de un período concreto, debemos activar los sistemas de auditoría que ... esto lo dejaremos para la Parte 4 ya que así lo podremos unir a Auditoría sobre RBAC en Solaris


<< Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 1
<< Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 2


Conclusión
Poco a poco avanzamos en el uso de Crossbow, y, en esta ocasión nos hemos centrado en una parte importante de Calidad de Servicio (QoS) que, sinceramente se ha simplificado en gran medida.

Qué es Crossbow y Cómo Utilizarlo en Solaris/OpenIndiana - Parte 2

Introducción
En la primera parte hablábamos de Qué es Crossbow y Cómo Utilizarlo en nuestros equipos de producción.

En esta ocasión, vamos a seguir profundizando en las opciones que nos aporta la creación de nic virtuales (vnic)


Optimización en Servidores CMT (MultiThread)
Una de las opciones más interesantes cuando hablamos de servidores Web, es la posibilidad de "unir" nuestras vnic a cores -o threads- de nuestro equipo.

De esta forma, podemos hacer que si tenemos una zona de en la cual tengamos instalado nuestro servidor Web Apache (o varios servidores), la interrupciones que se producen en la tarjeta de red, no afecten a los demás.

Dicho de otra forma, si tenemos una zona donde está nuestro servidor de aplicaciones, pongamos Apache Tomcat y sobre otra zona nuestro Squid como Proxy Reverso, y nuestra máquina tiene 4 cpus. Así que vamos a asignar las CPUs 0,1,2 al Proxy Reverso y la 3 a nuestro servidor Tomcat.

Para ello, vamos a utilizar la propiedad <cpus> y <priority>, para crear dos VirtualNIC -como vimos en la primera parte-

root@h1-cl1:/# psrinfo
0       on-line   since 05/09/2011 00:07:24
1       on-line   since 05/09/2011 00:07:26
2       on-line   since 05/09/2011 00:07:26
3       on-line   since 05/09/2011 00:07:26
root@h1-cl1:/# dladm create-vnic -l e1000g0 vnic10
root@h1-cl1:/# dladm create-vnic -l e1000g0 vnic11
root@h1-cl1:/# dladm show-vnic
LINK     OVER     SPEED  MACADDRESS       MACADDRTYPE  VID
vnic10   e1000g0  1000   2:8:20:20:17:9f  random        0
vnic11   e1000g0  1000   2:8:20:70:e5:b1  random        0
root@h1-cl1:/# dladm set-linkprop -p cpus=0,1,2 vnic10
root@h1-cl1:/# dladm set-linkprop -p cpus=3 vnic11
root@h1-cl1:/# dladm set-linkprop -p priority=high vnic10
root@h1-cl1:/# dladm set-linkprop -p priority=medium vnic11

De esta forma hemos hecho que las tarjetas "no se pisen" cuando tenga un tráfico muy elevado, y, si tenemos CPUs CMT -como los UltraSPARC T- podemos aprovechar al máximo el número de Threads que nos aportan.



<< Qué es Crossbow y Cómo Utilizarlo - Parte 1

Conclusiones
En esta ocasión no hemos hablado -a simple vista- de mucho, sin embargo, cuando empecéis a hacer vuestras pruebas, veréis cómo se obtienen unos resultados sorprendentes.

De todas formas, queda mucho por descubrir en Crossbow, y, en las siguientes entregas veremos algo más sobre optimización de anchos de banda (QoS)

Problemas RTL8168B PCI-e en OpenIndiana

Introducción
Hace unos días decidí cambiar algunos de mis equipos de pruebas de mi casa, y me "lancé" a comprarme componentes sueltos en App Informática -era en previsión de las días de fiesta ... :D-

Así que me compré diferentes componentes, aunque hoy vamos a hablar sólo de la tarjeta de red PCI-e EDIMAX y su Chipset RTL8168B.

El problema
Después de instalar OpenIndiana sin ningún problema, configurar y demás historias -todo ello utilizando la tarjeta de red integrada en la placa- me dispuse a activar la tarjeta PCI-e y configurar OpenIndiana como Router -para poner SQUID como Proxy Transparente-, pero ... cuál fue mi sorpresa que después de unas horas "OpenIndiana se colgaba 100%".

No respondía nada! Ni por consola!!

La Solución
Siento decir que me hubiese gustado poner aquí "la solución mágica", pero ... no fui capaz! Toqué cientos de parámetros, cambie de driver -utilizando gani- y muchas horas de pruebas, siempre con el mismo resultado: "colgada 100% de OpenIndiana"

Así que, al final, he cambiado esta tarjeta por una Intel PCI-e ...

Activar Salida por Consola Serie en OpenIndiana/Solaris 11

Introducción
Si queremos hacer que nuestro OpenIndiana/Solaris utilice nuestro puerto serie como salida en vez de la tarjeta gráfica, por ejemplo en servidores, simplemente deberemos incluir la opción "console=ttya" en nuestra entrada "kernel" del archivo <menu.lst> de GRUB.

Debemos recordar que si tenemos ZFS como sistema de archivos, el archivo <menu.lst> se encontrará en <POOL/boot/grub>, por ejemplo, en mi caso el nombre del POOL es "rpool".

root@h100:/rpool/boot/grub# zpool status
  pool: rpool
 state: ONLINE
 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

Editaremos el archivo "menu.lst", e incluiremos la opción "console=ttya" teniendo en cuenta que debemos incluir un "," para separar la opción.

root@h100:/# vi /rpool/boot/grub/menu.lst
 title ASEngine Enterprise Platform
 findroot (pool_rpool,0,a)
 bootfs rpool/ROOT/solaris-1
 kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=ttya
 module$ /platform/i86pc/$ISADIR/boot_archive
:wq

Ahora, la próxima vez que iniciemos nuestro OpenIndiana, la salida se producirá por nuestro puerto de serie 1 -ttya- y, por lo tanto, podremos acceder con nuestro programa favorito, por ejemplo <minicom>

Conclusión
No ha sido difícil activar nuestra salida de consola por puerto serie, y ya podemos gestionar de forma remota -y rápida- nuestro OpenIndiana.

Referencias

• Cómo cambiar el TimeOut de GRUB en OpenIndiana
• Comando básicos de Solaris, y no tan básicos de Solaris