Modelo de Seguridad de Solaris: RBAC, Roles y Privilegios - Parte 5

Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión, toca hablar de <roles>, ya que hemos avanzado en nuestros conceptos del modelo de seguridad de Solaris.

He decidido dividir esta parte de manejo de roles en varias entregas, y utilizar el ejemplo de Cómo Instalar PostgreSQL en OpenIndiana para reflejar las ventajas de utilizar roles y autorizaciones. En esta primera parte, nos acercaremos al concepto de roles y cómo se crean.

Qué es un rol
Un rol es gan parte similar a un usuario con la diferencia que no es posible iniciar una sessión con él. Me explico, imaginemos que tenemos un rol llamado postgres, si quieramos iniciar sessión con él, el sistema nos mostraría el siguiente error:

console login: postgres
Password: ********
Roles can oly be assume by authorized users
Login incorrect

Analizando el error, nos informa que sólo una vez en el sistema,  podemos asumir el rol si estamos autorizados. Es aquí donde encontramos las diferencias.

Relamente Necesito Roles
Buena pregunta, yo tardé unos meses en ver que sí, pero hasta entonces no lo tenía muy claro. Cuando llevaba unos meses adminstrando Solaris -allá por el Solaris 8- descubrí una funcionalidad que venía de Trusted Solaris, los Roles. Al principio, no veía por qué tenía que ir "asumiendo" un Rol u otro en función de qué tarea quisiera hacer, así que al final decidí volver a mi tradicional "su -" y realizarlo con root.

Un día, cuando ya no era yo sólo el que administraba los Solaris, me encontré con "un toquecito en la espalda diciéndome: es que ... no sé ... pero ....  el servidor de correo no funciona ... y yo no he tocado nada"

Aquí empezaron mis problemas ... ya que root tiene el control de todo, pero .. quién controla a root? Y más importante: Qué "root" ha sido?

Si analizamos los registros de auditoria, vemos que el comando lo ha ejecutado "root", pero si tenemos varios SysAdmin, quién ha sido? Si, es cierto, el comando "su" se registra pero ... quién lo ha ejecutado?

# tail /var/adm/sulog
SU 09/26 13:07 + pts/5 itily-root
SU 09/26 13:10 + pts/6 zooey-root

Bien, es cierto que podemos habilitar la auditoria -que en aquél entonces no estaba, mal, mal, muy mal- pero ... podemos hacer algo más?

La respuesta es SI, activar los roles.


Modelo de Seguridad utilizando Roles
El uso de <roles> dentro de un sistema de seguridad hace posible el concepto de <Administración Delegada>, es decir, imaginemos que tenemos varios perfiles de administradores, unos Junior otros Senior, incluso gente que no sabe Solaris.  Podemos pensar de forma rápida en entregar la contraseña de root al administrador Senior, y para los otros solicitar que la introduzca cuando sea necesario.

Bien, a priori puede parecer que con esto hemos solventado el problema de nuestro administrador Junior pero qué sucede cuando no encuentra al administrador Senior? O, mejor aún, qué hace el administrador Senior mientras el Junior administra con root?

Como véis, esto no es operativo, y al final, en el modelo de SuperUser sólo podemos entregar la contraseña de root a los adminstradores Senior y Junior, y establecer algún mecanismo mediante "sudo" o "setuid script" para las tareas importantes.

Si, es cierto, podemos utilizar "sudo" que nos permite ejecutar un comando como root aun no siendo, pero ... si ese comando es gestionar PostgreSQL mediante Solaris SMF. Bueno, aquí la cosa se complica.

Divide y Vencerás
Continuando con nuestro ejemplo de PostgreSQL, podemos definir diferentes tareas y cada una de esas tareas asignarlas a diferentes roles, que, a su vez, asignarlas a diferentes usuarios. Me explico, por ejemplo, definimos las tareas de "Administración de PostgreSQL", "Administración de Tomcat" y "Administración Host".

De esta forma, podemos tener la siguiente tabla:

• Administración PostgreSQL: Iniciar y Detener el Servicio, y ejecutar los comandos de PostgreSQL, pero no configurarlo
• Adminstración Tomcat: Iniciar y Detener el Servicio, pero no configurarlo
• Administración Host: Puede realizar cualquier acción

Como ya comentábamos en Instalar PostgreSQL en OpenIndiana, en Solaris existe ya un <rol> para PostgreSQL llamado <postgres>, podemos comprobarlo si ejecutamos el siguiente comando:

itily@openzooey:~$ pfexec cat /etc/user_attr | grep postgres
postgres::::type=role;profiles=Postgres Administration,All

Si nos fijamos en el tipo <type> vemos que pone <role>, si no os aparece ninguna entrada, es que habéis eliminado el role. Por el momento, no vamos a hacer caso al valor de <profiles> ya que lo examinaremos en las siguientes entregas.

Cómo Crear un Role
Como ya hemos comentado, un role es prácticamente un usuario, y por lo tanto, su forma de crearlo es muy parecida. En vez de utilizar <useradd>, utilizaremos <roleadd> con los mismos parámetros a excepción de <-s< que en vez de <bash, sh, csh> serán <pfbash, pfsh, pfcsh>, veámos un ejemplo

root@openzooey:~# roleadd -s /usr/bin/pfbash -d /export/home/asengine -m asengine
80 blocks
root@openzooey:~# passwd asengine
New Password:
Re-enter new Password:
passwd: password successfully changed for asengine

A continuación debemos asignarle nuestro role a un usuario, en nuestro caso, será a <zooey>

root@openzooey:~# usermod -R asengine zooey

Si nos logeamos con este usuario, podremos ver los <roles> que tiene asignados, utilizando el comando <roles>

root@openzooey:~# su - zooey
OpenIndiana     SunOS 5.11      oi_147  September 2010
zooey@openzooey:~$ roles
asengine
zooey@openzooey:~$ su - asengine
Password:
OpenIndiana     SunOS 5.11      oi_147  September 2010
asengine@openzooey:~$ id
uid=102(asengine) gid=1(other) groups=1(other)

Como véis, no ha sido difícil, verdad? Además, como hemos comentado muchas veces, un <rol> es similar a un usuario, por lo tanto, puedo utilizar los comando <chmod, passwd> para asignar los permisos de forma correcta, por ejemplo:

root@openzooey:~# mkdir -p /var/sfchildren
root@openzooey:~# chown -R asengine /var/sfchildren
root@openzooey:~# chmod 700 /var/sfchildren

Cuidado con la asignación de Roles
Debéis tener cuidado con el comando <usermod -R ...> ya que este sustituye no añade roles, es decir, si tenemos el siguiente usuario

root@openzooey:~# roles zooey
root

Y ejecutamos el comando <usermod -R asengine>

root@openzooey:~# usermod -R asengine zooey

El resultado será que hemos perdido el <role> root y en OpenIndiana tendremos un problema, ya que el usuario <root> es un <role> y por lo tanto, no podremos logearnos desde la consola, ya que ahora el usuario <itily> tiene asignado el <rol>asengine> sólamente,

root@openzooey:~# roles zooey
asengine

Para ello, debemos utilizar el comando <usermod -R role1,role2,role...>

root@openzooey:~# usermod -R root,asengine zooey
root@openzooey:~# roles zooey
root,asengine

Jugando con los Roles
Veamos un poco como podemos utilizar los roles de nuestro ejemplo. En este caso, el usuario <zooey> tendrá asignado el <rol> de <postgres> y por lo tanto, podrá ejecutar sus comandos, sin embargo, no podrá administrar nuestro host.

zooey@openzooey:~$ id
uid=102(zooey) gid=14(sysadmin) groups=14(sysadmin)
zooey@openzooey:~$ roles
postgres
zooey@openzooey:~$ su - postgres
Password:
OpenIndiana     SunOS 5.11      oi_147  September 2010
postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres   
psql (9.0.0)
Type "help" for help.

postgres=# \q
zooey@openzooey:~$ su -
Password:
Roles can only be assumed by authorized users
su: Sorry

Como hemos comentado, aunque <zooey> conozca la contraseña de <root> no puede asumirla, ya que su usuario no tiene el derecho para hacerlo.

Qué hemos conseguido
Al utilizar roles, hemos conseguido por un lado, tener controlado el acceso, ya que, ahora podemos asignar el role <postgres> a los usuarios que queremos que tengan la posibilidad de administración.

Además, en el supuesto de "alguien" descubra la contraseña del role <postgres> también necesitará conocer el login y password de un usuario con posibilidad de asumirlo.

Conclusiones
En esta ocasión hemos avanzado un poco más en el modelo de seguridad que nos ofrece Solaris, y, aunque puede parecer complicado no lo es tanto.

En las próximas entregas veremos las <autorizaciones> y con esa última parte, ya tendremos el modelo de seguridad completo.

<< RBAC, Roles y Privilegios en Solaris 10 - Parte 1
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 2
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 3
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 4

RBAC, Roles y Privilegios en Solaris 10 - Parte 6 >>
RBAC, Roles y Privilegios en Solaris 10 - Parte 7 >>

Referencias

• Roles, Rights and Profiles - Sun Documentation
• Privileges On Non Global Zone - Sun Documentation
• Instalación de PostgreSQL en OpenIndiana - Parte 1

Instalación de PostgreSQL en OpenIndiana - Parte 1

Introducción
Ya hemos visto Cómo Instalar PostgreSQL en Solaris 10 utilizando los binarios que nos proporciona PostgreSQL, sin embargo, en esta ocasión vamos a ver Cómo Instalar PostgreSQL 9.0 en OpenIndiana

Desde la página de PostgreSQL, podemos descargarnos la versión ya compilada para Solaris 10, sin embargo, esta versión no funciona sobre OpenSolaris y OpenIndiana.

Problemas con los binarios para Solaris 10 en OpenIndiana
El principal problema de los binarios compilados para Solaris reside en el uso de la biblioteca <libssl.so.0.9.7> y <libcrypto.so.0.9.7> que en OpenIndiana son </usr/lib/64/libcrypto.so.0.9.8> y </usr/lib/64/libssl.so.0.9.8>

Es decir, en OpenIndiana -OpenSolaris- tenemos una versión superior, y por lo tanto, cuando verificamos las dependencias del inario utilizando <ldd> vemos que no se encuentran:

# ldd postgres
        libxslt.so.1 =>  /usr/lib/64/libxslt.so.1
        libxml2.so.2 =>  /lib/64/libxml2.so.2
        libpam.so.1 =>   /lib/64/libpam.so.1
        libssl.so.0.9.7 =>       (file not found)
        libcrypto.so.0.9.7 =>    (file not found)
        libgss.so.1 =>   /usr/lib/64/libgss.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        librt.so.1 =>    /lib/64/librt.so.1
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        libc.so.1 =>     /lib/64/libc.so.1
        libz.so.1 =>     /lib/64/libz.so.1
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1

Pero ... que no cunda el pánico, que es un problema fácilmente solucionable. Tenemos tres opciones para ello, o instalamos la versión anterior de OpenSSL cosa que NO RECOMIENDO, o compilamos nuestra propia versión de PostgreSQL o ... podeis descargaros la versión compilada por mí, para OpenIndiana x86 en 64bits de PostgreSQL 9.0.

Si os habéis decidido por la última opción -Instalar PostgreSQL desde el binario par a OpenIndiana-, entonces, podéis ignorar el paso de compilación pero debéis tener en cuenta lo siguiente:

• El binario debe ser instalado en </u01/app/postgres/9.0/db> 
• Utilizaremos el role de <postgres> del sistema
• El <PGDATA> esta en </var/postgres/9.0/data>

Preparación del Entorno
Antes de poder compilar PostgreSQL 9.0 en OpenIndiana, debemos tener en cuenta que son necesarios algunos paquetes, para ello, deberemos instalarlos antes.

Aquí os dejo la lista de paquetes necesarios, para instalarlos, simplemente debemos ejecutar <pkg install _nombre_paquete_>

• sunstudio
• SUNWgmake
• SUNWbison
• SUNWgm4
• SUNWflexlex

Podemos comprobar si ya están instalados utilizando el comando <pkginfo>, por ejemplo

# pkginfo |grep flex
system      SUNWflexlex               Flex Lexer
system      SUNWrsync                 rsync - faster, flexible replacement for rcp
# pkginfo |grep bison
system      SUNWbison                 bison - A YACC Replacement
# pkginfo |grep gm4
system      SUNWgm4                   GNU m4
# pkginfo |grep gmake
system      SUNWgmake                 gmake - GNU make
# pkginfo |grep sunstudio
application sunstudio12u1             Sun Studio 12 update 1

Compilar PostgreSQL 9.0
Para la compilación he utilizado los mismos parámetros que Bjorn Munch utiliza en la versión "oficial" que es posible descargar desde PostgreSQL.

Lo primero que haremos, será descargarnos el fuente de PostgreSQL desde su página oficial, en cualquiera de los dos formatos: tar.gz, tar.bz2

# export CC=cc  
# export CFLAGS="-xO3  -xspace -Xa  -xildoff  -m64  -xc99=none -xCC -fast -native"
# export LDFLAGS="-R/usr/sfw/lib/64 -R/usr/lib/64"
# ./configure 
--prefix=/u01/app/postgres/9.0/db
--exec-prefix=/u01/app/postgres/9.0/db
--bindir=/u01/app/postgres/9.0/db/bin/64
--libexecdir=/u01/app/postgres/9.0/db/bin/64
--sbindir=/u01/app/postgres/9.0/db/bin/64
--datadir=/u01/app/postgres/9.0/db/share
--sysconfdir=/u01/app/postgres/9.0/db/etc
--mandir=/u01/app/postgres/9.0/db/man
--libdir=/u01/app/postgres/9.0/db/lib/64
--includedir=/u01/app/postgres/9.0/db/include
--sharedstatedir=/var/postgres/9.0
--localstatedir=/var/postgres/9.0
--enable-nls
--docdir=/u01/app/postgres/9.0/db/doc
--with-system-tzdata=/usr/share/lib/zoneinfo
--with-python
--with-pam
--with-openssl
--with-libedit-preferred
--with-libxml
--with-libxslt
--with-gssapi
--enable-thread-safety
--enable-dtrace
--disable-integer-datetimes
--with-includes=/usr/include:/usr/sfw/include
--with-libs=/lib/64:/usr/lib/64:/usr/sfw/lib/64
# make
# make install

Configuración de PostgreSQL
A diferencia del post sobre Cómo Instalar PostgreSQL 8.x en Solaris 10, en esta ocasión vamos a utilizar roles para ejecutar el servicio.

Ahora si que estamos en disposición de poder hablar de esta forma de instalación, ya que hemos introducido los conceptos de RBAC, Roles y Privilegios en post anteriores.

No es que la instalación de PostgreSQL 8.x en Solaris 10 no estuviese bien, sino que no utilizaba todos los mecanismos que Solaris nos proporciona -a nivel de seguridad-, para que os hagáis una idea, si ejecutamos el comando <ppriv> sobre el proceso de postgres ejecutado con un usuario normal veremos cuáles son sus privilegios

$ svcs -p postgresql_84
STATE          STIME    FMRI
disabled       mar_04   svc:/application/database/postgresql_84:default_32bit
online         jul_06   svc:/application/database/postgresql_84:default_64bit
               jul_06       3082 postgres
               jul_06       3084 postgres
               jul_06       3085 postgres
$ ppriv 3082
3082:   /u01/app/postgres/8.4/db/bin/64/postgres -D /var/postgres/8.4/data
flags =
        E: basic
        I: basic
        P: basic
        L: basic,contract_event,contract_observer,file_chown,file_chown_self,file_dac_execute,file_dac_read,
file_dac_search,file_dac_write,file_owner,file_setid,ipc_dac_read,ipc_dac_write,ipc_owner,
net_bindmlp,net_icmpaccess,net_mac_aware,net_privaddr,net_rawaccess,proc_audit,
proc_chroot,proc_lock_memory,proc_owner,proc_setid,proc_taskid,sys_acct,sys_admin,
sys_audit,sys_ip_config,sys_mount,sys_nfs,sys_resource

Ahora, si ejecutamos el servicio postgres mediante <pg_ctl> y el role <postgres> veremos la diferencia de privilegios:

$ id
uid=90(postgres) gid=90(postgres)
$ pg_ctl start -l /var/log/postgres/server.log
server starting
$ ps -ef|grep postgre
postgres   794     1   1 09:39:22 pts/1       0:00 /u01/app/postgres/9.0/db/bin/64/postgres
postgres   799   794   0 09:39:22 ?           0:00 /u01/app/postgres/9.0/db/bin/64/postgres
$ ppriv 794
794:    /u01/app/postgres/9.0/db/bin/64/postgres
flags = PRIV_PFEXEC
        E: basic
        I: basic
        P: basic
        L: all

Como podéis ver, la diferencia se encuentra en flags que ahora indica PRIV_PFEXEC ya que al ser un role, su shell es <pfexec> y, si es lanzado por el servicio SMF, es root quien lo lanza.

Además, si queríamos que un usuario -persona- pudiese gestionar nuestro PostgreSQL debíamos entregarle la contraseña de root ya que sino, no podría operar con SMF. Si lo intentase, nos mostraría el siguiente error:

$ id
uid=101(postgres) gid=90(postgres)
$ /usr/sbin/svcadm disable svc:/application/database/postgresql_84:default_64bit
svcadm: svc:/application/database/postgresql_84:default_64bit: Permiso denegado.

Configuración de PostgreSQL en SMF
A continuación configuraremos nuestro servicio postgres para que sea controlado mediante SMF, para ello, debemos descargar el Manifest para Solaris SMF 10 PostgreSQL 9 y el Method para Solaris SMF 10 PostgreSQL 9

# cd /lib/svc/method
# wget http://blog.sfchildren.com/blogger/openindiana/postgresql/9.0/smf/postgres_9
# chown root:bin postgres_9
# chmod 555 postgres_9
# mkdir -p /var/svc/manifest/application/database
# cd /var/svc/manifest/application/database
# wget http://blog.sfchildren.com/blogger/openindiana/postgresql/9.0/smf/postgresql_9.xml
# svccfg
svc:> validate postgresql_9.xml
svc:> import postgresql_9.xml
svc:> quit
# svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:24:40 svc:/application/database/postgresql_9:default_64bit

Creación Estructura de PGDATA
Antes de poder iniciar postgres debemos crear la estructura de almacenamiento necesaria, para ello, deberemos ejecutar el comando <initdb> con los parámetros oportunos. En nuestro caso, vamos a iniciar la estructura en formato <UTF-8> y lenguage <es_UTF8> y la opción <-W> para que nos solicite la password que vamos a asignar al usuario postgres de la base de datos

# mkdir -p /var/postgres/9.0/data
# chown -R postgres:postgres /var/postgres
# chmod 700 /var/postgres
# su - postgres
$ export PGDATA=/var/postgres/9.0/data
$ /u01/app/postgres/9.0/db/bin/64/initdb -E utf8 --locale=es.UTF-8 -U postgres -W

Project y Directorio de Logs
Al igual que hicimos con la Instalación de PostgreSQL en Solaris, debemos definir un project y un directorio donde queremos escribir nuestro log. En nuestro caso, el project será <group.postgres> y el directorio </var/log/postgres>

# projadd -c "Postgres Database" -G postgres group.postgres
# projmod -sK "process.max-sem-nsems=(priv,256,deny)" group.postgres
# projmod -sK "project.max-sem-ids=(priv,100,deny)" group.postgres
# projmod -sK "project.max-shm-ids=(priv,100,deny)" group.postgres
# projmod -sK "project.max-shm-memory=(priv,8G,deny)" group.postgres
# mkdir -p /var/log/postgres
# chown -R postgres:postgres /var/log/postgres
# chmod 700 /var/log/postgres

Inicio y Parada de PostgreSQL
Como siempre, vamos a utilizar el framework de Solaris SMF para gestionar el inicio y parada de PostgreSQL, sin embargo, en esta ocasión -a parte de poder utilizar root- podemos utilizar el role <postgres> para gestionarlo, por ejemplo:

$ id
uid=90(postgres) gid=90(postgres)
$ svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled        9:38:51 svc:/application/database/postgresql_9:default_64bit
$ pfexec /usr/sbin/svcadm enable svc:/application/database/postgresql_9:default_64bit
$ svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
online          9:55:13 svc:/application/database/postgresql_9:default_64bit
                9:55:13      817 postgres
                9:55:13      819 postgres
                9:55:13      820 postgres
                9:55:13      821 postgres
                9:55:13      822 postgres
$ ppriv 817
817:    /u01/app/postgres/9.0/db/bin/64/postgres -D /var/postgres/9.0/data
flags =
        E: basic
        I: basic
        P: basic
        L: all

Otorgar privilegios de administración de PostgreSQL a un usuario
Como hemos comenteado, al utilizar roles podemos delegar privilegios de administración a un usuario cualquiera sin que tengamos que proporciona la contraseña de root.

Por ejemplo, vamos a crear un usuario no privilegiado llamado <zooey> al cual, le vamos a otorgar permisos para poder administrar nuestro servicio PostgreSQL asignándole el role<postgres> y las autorizaciones <solaris.smf.value.postgres> y <solaris.smf.manage.postgres>

# useradd -g sysadmin -s /bin/bash -d /export/home/zooey -m -R postgres -A solaris.smf.manage.postgres,solaris.smf.value.postgres zooey
80 blocks
# passwd zooey
New Password:
Re-enter new Password:
passwd: password successfully changed for zooey
# su - zooey
OpenIndiana     SunOS 5.11      oi_147  September 2010
zooey@openzooey:~$ roles
postgres
zooey@openzooey:~$ pfexec svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:24:40 svc:/application/database/postgresql_9:default_64bit
zooey@openzooey:~$ pfexec /usr/sbin/svcadm enable svc:/application/database/postgresql_9:default_64bit
zooey@openzooey:~$ pfexec svcs -p postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
online         10:39:25 svc:/application/database/postgresql_9:default_64bit
               10:39:24     1016 postgres
               10:39:24     1018 postgres
               10:39:24     1019 postgres
               10:39:24     1020 postgres
               10:39:24     1021 postgres
zooey@openzooey:~$ pfexec /usr/sbin/svcadm disable svc:/application/database/postgresql_9:default_64bit
zooey@openzooey:~$ pfexec svcs postgresql_9
STATE          STIME    FMRI
disabled        9:29:24 svc:/application/database/postgresql_9:default_32bit
disabled       10:43:51 svc:/application/database/postgresql_9:default_64bit

Conclusiones
En esta ocasión hemos utilizado muchos más mecanismos para gestionar el servicio de PostgreSQL y, hemos aprendido a utilizar los roles como una herramienta muy potente y segura.

Aunque inicialmente la Instalación de PostgreSQL puede ser de la forma tradicional -utilizando un usuario no privilegiado y root para gestionarlo- Solaris nos proporciona un entorno mucho más seguro y rico para ello.

Espero que con este ejemplo -completo- de instalación podáis ver la potencia de los roles, y como nos pueden ayudar en nuestro día a día.

 
Referencias

• Instalar PostgreSQL 8.x en Solaris 10
• Instalar OpenSolaris Paso a Paso
• RBAC, Roles y Privilegios - Parte 1
• RBAC, Roles y Privilegios - Parte 2
• Manifest PostgreSQL 9.0 OpenIndiana
• Method PostgreSQL 9.0 OpenIndiana
• Página principal PostgreSQL

OpenIndiana, El sucesor de OpenSolaris

Introducción
Hace un tiempo hablábamos de la oscura situación de OpenSolaris y su incierto futuro. En aquél entonces hablábamos de Solaris, OpenSolaris e IllumOS.

Después de un tiempo de incertidumbre, ya tenemos algunas respuestas a las preguntas que dejábamos abiertas, principalmente, ¿y ahora qué? Bueno, pues la respuesta es: OpenIndiana


Qué es OpenIndiana
Es una proyecto dentro del nucleo de IllumOS que pretende ser "el sucesor de OpenSolaris", y por lo tanto, OpenIndiana es una distribución completa, es decir, es un sistema instalable.

Para ir abriendo boca
Después de unas pruebas, creo que OpenIndiana es una opción muy interesante, y aunque todavía no hemos visto nada, poco a poco, iremos entrando en materia de Cómo migrar desde OpenSolaris a OpenIndiana, ... pero ante entonces aquí os dejo el banner de OpenIndiana

# cat /etc/release
                      OpenIndiana Development oi_147 X86
        Copyright 2010 Oracle and/or its affiliates. All rights reserved.
                        Use is subject to license terms.
                           Assembled 14 September 2010

Conclusiones
Después de un tiempo, ya tenemos las respuestas a nuestras preguntas y dudas. Ahora, toca hacer las pruebas y ver cómo avanza el proyecto, que, esperemos que se consolide como una alternative real a Solaris 11 y con una comunidad abierta y real -no como sucedía en OpenSolaris-

En los próximos días, veremos Cómo migrar de OpenSolaris a OpenIndiana y Los primeros pasos en OpenIndiana.



Referencias

• Solaris, OpenSolaris e IllumOS
• Proyecto OpenIndiana
• Proyecto IllumOS

Problemas ActiveMQ 5.4 en Solaris 10

Introducción
Mientras hablábamos de Cómo Instalar Apache ActiveMQ 5.x en Solaris 10, desde Apache han liberado una nueva versión, la 5.4. En esta han introducido algunos cambios, principalmente en los scripts de arranque. Esto hace que las definiciones de los method para ActiveMQ que habíamos creado, ya no funcionen correctamente.

Nuevo formato Script ActiveMQ
El nuevo formato de script acepta más parámetros, y ahora podemos utilizar para iniciar, detener, verificar mensajes, eliminar mensajes, entre otros

El formato es el siguiente

$ACTIVEMQ_HOME/bin/activemq [tarea] [opciones-tarea] [datos-tarea]

Y las tareas disponibles son las siguientes:

•     start. Crea he inicia el broker
•     create. Crea una instancia en el path especificado
•     stop. Detiene el broker
•     list. Muestra los brokes que hay disponibles
•     query. Consulta una propiedad de un broker
•     browse. Muestra los mensajes de un broker
•     journal-audit. Muestra los mensaje almacenados en el storage area
•     purge. Borra los destinos seleccionados

Problemas con el script y nuestro method
El principal problema de nuestro method para ActiveMQ 5.3.x viene por el nuevo formato, que ahora es necesario introducir un nuevo parámetro <task>, como hemos visto antes, que nos permitirá realizar diferentes acciones.

Cuando diseñe el method, el script <activemq> no tenía estos parámetros, y por lo tanto, no funcionaba. Para ello, he creado una nueva versión de Solaris SMF Method para ActiveMQ 5.4.x que, simplemente modifica los parámetros de inicio. Así mismo, el manifest para ActiveMQ 5.4 también lo he modificado para que pueda adaptarse a estas nuevas funcionalidades.

Para evitar, tener problemas con mi instalación de ActiveMQ 5.3.x, hemos definido un nuevo ACTIVEMQ_HOME para la instalación ActiveMQ 5.4 que corresponde a </opt/www/activemq5.4> pero puedes asignar la que quieras.

Aplicar el parche de <$ACTIVEMQ/bin/activemq>
He creado un pequeño parche que soluciona los problemas para poder ejecutarlo dentro de nuestra instalación de Solaris.

Básicamente, el problema viene por el uso del comando <whoami> que, como recordáis durante la Instalación de Hadoop en Solaris 10, también nos sucedía, y por el uso de la opción <-q> -quiet- del comando <grep> que en SRV no está definida.
 
Para aplicarlo, simplemente deberemos descargarnos el parche para Solaris 10 de ActiveMQ 5.4 y ejecutar el comando <patch> de la siguiente forma:

# cd $ACTIVEMQ_HOME
# cd bin
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/activemq/5.4/activemq.patch
# patch activemq-test < activemq.patch
  Parece un diff normal.
terminado

Para aquellos que no os apetezca parchear os he dejado una versión Parcheada para Solaris 10 del script que simplemente deberéis remplazar la que viene con la distribución de Apache por esta.

Conclusiones
A veces, los cambios pueden ocasionarnos problemas, por eso, es muy recomendable utilizar un entorno de pruebas donde hagamos todos los cambios, y una vez validados, poderlos pasar a producción.

Además, como no son muy complejos, podemos continuar con nuestra serie de Instalación y Configuración de ActiveMQ 5.x en Solaris 10

Referencias

• Apache ActiveMQ Home
• Instalar Java Developer Kit (JDK) en OpenSolaris
• Instalar Apache ActiveMQ en Solaris 10 - Parte 1
• Instalar Apache ActiveMQ 5.x en Solaris 10 - Parte 2 

Modelo de Seguridad de Solaris: RBAC, Roles y Privilegios - Parte 4

Introducción
Continuando con nuestra serie de RBAC, Roles y Privilegios y cómo podemos aplicarlo a nuestras instalaciones. En esta ocasión vamos a ver el privilegio sys_priocntl -aplicado a una zona- que nos permite modificar el planificador de un proceso desde una zona no global

Modificación del planificador en una Zona No Global
Si intentamos ejecutar el comando de cambio de planificador <priocntl> en una zona no global con los privilegios default Solaris nos mostrará un mensaje de error indicando que no tiene permisos, vamos a verlo:

# zonename
testzone
# ps -cf -u smmsp
     UID   PID  PPID  CLS PRI    STIME TTY         TIME CMD
   smmsp  9046  8589  FSS  59 11:44:15 ?           0:00 /usr/lib/sendmail -Ac -q15m
# priocntl -s -c FX -i pid 9046
Permissions error encountered on pid 9046.

Privilegios Zona No Global para cambiar los planificadores
Vamos a ver cómo podemos hacer para habilitar la administración de planificadores en una zona no global, para ello, deberemos incluir el privilegio sys_priocntl

# zonecfg -z testzone
zonecfg:testzone> set limitpriv=default,proc_priocntl,sys_time
zonecfg:testzone> verify
zonecfg:testzone> commit
zonecfg:testzone> exit
# zoneadm -z testzone reboot

Ahora, al conectarnos a la zona y volveremos a ejecutar el comando de cambio de planificador y le asignaremos TS en vez de FSS y veremos el resultado

# ps -cf -u smmsp
     UID   PID  PPID  CLS PRI    STIME TTY         TIME CMD
   smmsp 13064 12635  FSS  29 13:33:58 ?           0:00 /usr/lib/sendmail -Ac -q15m
# priocntl -s -c TS -i pid 13064
# ps -cf -u smmsp
     UID   PID  PPID  CLS PRI    STIME TTY         TIME CMD
   smmsp 13064 12635   TS  52 13:33:58 ?           0:00 /usr/lib/sendmail -Ac -q15m

Esta vez si que hemos podido cambiar nuestro planificador.

Conclusiones
Hemos visto un privilegio bastante útil que nos permitirá modificar los planificadores -y por lo tanto optimizar el uso- de los procesos que se encuentran dentro de una zona, sin tener que acceder a través de la zona global para ello.

Con esta última parte, ya podemos pasar a las siguientes secciones, donde hablaremos de Roles y, como hemos hecho hasta ahora, utilizaremos pequeños ejemplos para poder explicarlo de forma más sencilla.

<< RBAC, Roles y Privilegios en Solaris 10 - Parte 1
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 2
<< RBAC, Roles y Privilegios en Solaris 10 - Parte 3

RBAC, Roles y Privilegios en Solaris 10 - Parte 5 >>
RBAC, Roles y Privilegios en Solaris 10 - Parte 6 >>
RBAC, Roles y Privilegios en Solaris 10 - Parte 7 >>

Referencias

• RBAC, Roles y Privilegios en Solaris 10 - Parte 1
• RBAC, Roles y Privilegios en Solaris 10 - Parte 2
• RBAC, Roles y Privilegios en Solaris 10 - Parte 3
• Roles, Rights and Profiles - Sun Documentation
• Privileges On Non Global Zone - Sun Documentation