Solaris Black Box :: El Blog en Castellano

DBLink con parametros en PostgreSQL

noreply@blogger.com (Urko Benito) — Fri, 20 Jan 2012 10:33:00 +0000

Introducción
Hace unos días una persona me dejó una duda a modo de comentario en la entrada de DBLinks en PostgreSQL. Esta duda es sencilla, y, a la vez interesante, por eso, he decidido crear una entrada explicando la solución.

La duda
¿Es posible crear una vista en PostgreSQL utilizando un DBLink con parámetros dinámicamente?

Es decir, lo que queremos es hacer los siguiente:

SELECT device_name FROM remote_database_v(param1, param2);

La solución
Sobre si es posible crear una Vista con un DBLink parametrizado, lo cierto es que no se puede, es decir, no podemos crear una vista pasando un argumento.

Sin embargo, podemos crear un procedimiento que nos devuelva un tipo "record" y pasarle como parámetros la cadena de conexión, por ejemplo:

CREATE OR REPLACE FUNCTION test_dblink_with_parameter(dbname character varying, dbhost character varying, dbuser character varying, dbuserpass character varying)
RETURNS SETOF record AS
$BODY$
    SELECT t.device_name
    FROM dblink('dbname=' || $1 || ' port=5432 host=' || $2 || ' user=' || $3 ||' password=' || $4 , 'SELECT device_name FROM devices.as_device') as
     t(device_name character varying);
$BODY$
LANGUAGE sql VOLATILE;

Y ahora podemos llamar a nuestro procedimiento como si fuese una tabla o vista.

Recordar que al ser de tipo "record" tenemos que decirle cómo es el formato del registro <AS (field1 type, field2 type, fieldn type)>, en nuestor caso devuelve el campo "as_device" que es de type "character varying".

SELECT * FROM test_dblink_with_parameter('dbname','localhost','user','password') AS (device_name character varying);

Algunas Mejoras
En función de los datos que estamos obteniendo, podemos, por ejemplo, optimizar el coste <COST> y el número de rows <ROWS> del procedimiento. En el ejemplo, hemos dejado el coste y el número de rows "por defecto", COST 100 y ROWS 100.

Referencias

Feliz 2012

noreply@blogger.com (Urko Benito) — Mon, 02 Jan 2012 08:36:00 +0000

Hemos pasado un año más, y como siempre, toca hacer un repaso a los 365 días que han transcurrido con sus buenos y malos momentos.

Puedo decir que para mi el 2011 ha sido uno de los años más gratificantes -tanto personal como profesionalmente- y, espero que el 2012 sea aún mejor.

Comencé una nueva aventura en Havoc Technologies como responsable del área de I+D e IT, todo un desafío, pero, ya estamos en la rampa de salida con los productos de Navegación Segura para Niños y Sistemas de Control de Navegación para empresas.

Todo ello basado en Solaris, PostgreSQL y Hadoop. Tecnologías que me encantan, y, aunque los comienzos no fueron fáciles, ya estamos a pleno rendimiento!

Por ello, me gustaría desear a todos los SysAdmins un Feliz 2012

Un Saludo,
Urko

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

noreply@blogger.com (Urko Benito) — Thu, 15 Dec 2011 09:54:00 +0000

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

Cómo desactivar ACPI en OpenIndiana

noreply@blogger.com (Urko Benito) — Sat, 29 Oct 2011 22:09:00 +0000

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

Cómo clonar una tabla en PostgreSQL

noreply@blogger.com (Urko Benito) — Sat, 24 Sep 2011 08:46:00 +0000

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:

Crearemos una tabla llamada test con los campos company y homepage
Añadiremos un índice único en company
Añadiremos un par de compañías
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.
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

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

noreply@blogger.com (Urko Benito) — Mon, 08 Aug 2011 08:53:00 +0000

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

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

noreply@blogger.com (Urko Benito) — Sun, 24 Jul 2011 21:54:00 +0000

Introducción
En las primeras partes de Qué es Crossbow y Cómo utilizarlo hablábamos de cada una de sus partes principales, hoy, haremos un pequeño acercamiento a los sistemas de auditoría.

Estadísticas de Red
Ya hemos visto en Qué es Crossbow y Cómo utilizarlo - Parte 3 el comando <flowstat> que nos mostraba las estadísticas de uso de los flujos, pero siempre contando desde el último boot de nuestro sistema.

Pero, si queremos saber el consumo de un flujo en un determinado tiempo, por ejemplo, a primera hora de la mañana? La verdad es que entonces el comando <flowstat> -tal y como lo hemos visto- no nos sirve, pero tranquilos, que para ello tenemos soluciones.

Auditoría de Red
En Solaris/OpenIndiana tenemos un sistema de auditoría muy potente, en el que se incluyen el registro de red <net> y flujos <flow> entre otros.
Para ello, simplemente deberemos definir un archivo donde queremos que se almacenen los datos -en nuestro caso /var/log/ipqos/hseries/hseries.log- y el tipo de auditoría que queremos realizar.

Todo ello se realizará mediante el comando </usr/sbin/acctadm> que ahora veremos con más detalle.

Tipos de Auditorías
Tenemos dos tipos de auditorías: básica y extendida. Para ver qué tipos de datos incluyen cada una de las auditorías utilizaremos la opción <-r> que nos mostrará todas las opciones de auditoría.

havoc@h1000:~$ pfexec acctadm -r
process:
extended pid,uid,gid,cpu,time,command,tty,projid,taskid,ancpid,wait-status,zone,flag,memory,mstate
basic    pid,uid,gid,cpu,time,command,tty,flag
task:
extended taskid,projid,cpu,time,host,mstate,anctaskid,zone
basic    taskid,projid,cpu,time
flow:
extended saddr,daddr,sport,dport,proto,dsfield,nbytes,npkts,action,ctime,lseen,projid,uid
basic    saddr,daddr,sport,dport,proto,nbytes,npkts,action
net:
extended name,ehost,edest,vlan_pid,vlan_tci,sap,priority,bwlimit,devname,src_ip,dst_ip,src_port,dst_port,protocol,dsfield,curtime,ibytes,obytes,ipkts,opkts,ierrpkts,oerrpkts
basic    name,devname,ehost,edest,vlan_pid,vlan_tci,sap,priority,bwlimit,curtime,ibytes,obytes,ipkts,opkts,ierrpkts,oerrpkts

En nuestro ejemplo de hoy, vamos a centrarnos en el módulo <net> que nos permitirá auditar los eventos de red.

Activar el sistema de auditoría
La activación del sistema de auditoría se realiza mediante el comando y la opción <-e {módulo}>, o utilizando el servicio .

Antes de poder activarlo, debemos asignar un fichero donde realizaremos el registro -más adelante veremos otras opciones como utilizar para proteger el acceso al mismo-.

Como os he comentado, en nuestro ejemplo utilizaremos el archivo ; y el modo de auditoría

havoc@h1000:~$ pfexec mkdir -p /var/log/ipqos/hseries
havoc@h1000:~$ pfexec acctadm -e extended -f /var/log/ipqos/hseries/hseries.log net

Comprobar el estado de la auditoría
Podemos comprobar el estado de un sistema de auditoría utilizando el comando , en nuestro caso, queremos comprobar el estado del módulo

havoc@h1000:~$ pfexec acctadm net
     Net accounting: active
     Net accounting file: /var/log/ipqos/hseries/hseries.log
     Tracked net resources: extended
     Untracked net resources: none

Vemos que nos indica que está y que el modo de auditoría es

Desactivar el sistema de auditoría
Tenemos varias formas de desactivar la auditoría en función de cómo queramos actuar, por ejemplo, si queremos desactivar temporalmente la auditoría -por una necesidad puntual- o de forma permanente:

Para desactivar temporalmente -sin cerrar el archivo de auditoría-, utilizaremos la opción <-D {modulo}> del comando , por ejemplo, si queremos desactivar la auditoría del módulo :

havoc@h1000:~$ pfexec acctadm -D net
havoc@h1000:~$ pfexec acctadm net
    Net accounting: inactive
    Net accounting file: /var/log/ipqos/hseries/hseries.log
    Tracked net resources: extended
    Untracked net resources: none

Para desactivar definitivamente la auditoría, utilizaremos la opción <-x {modulo}>, por ejemplo, al igual que antes el módulo de

havoc@h1000:~$ pfexec acctadm -x net
havoc@h1000:~$ pfexec acctadm net
            Net accounting: inactive
       Net accounting file: none
     Tracked net resources: extended
   Untracked net resources: none

Debemos fijarnos en el valor de que ahora nos indica , es decir, está totalmente desactivada

Volver a activar las estadísticas
En ambos casos, deberemos utilizar la opción <-e -f {archivo}> para activar el sistema, por ejemplo, vemos cómo activarlo utilizando los dos métodos.

Si cerramos el sistema de auditoría

havoc@h1000:~$ pfexec acctadm -x net
havoc@h1000:~$ pfexec acctadm net
            Net accounting: inactive
       Net accounting file: none
     Tracked net resources: extended
   Untracked net resources: none
havoc@h1000:~$ pfexec acctadm -e extended -f /var/log/ipqos/hseries/hseries.log net
havoc@h1000:~$ pfexec acctadm net
            Net accounting: active
   Net accounting file: /var/log/ipqos/hseries/hseries.log
   Tracked net resources: extended
   Untracked net resources: none

Y ahora si tenemos desactivada la auditoría temporalmente

havoc@h1000:~$ pfexec acctadm -D net
havoc@h1000:~$ pfexec acctadm net
            Net accounting: inactive
   Net accounting file: /var/log/ipqos/hseries/hseries.log
   Tracked net resources: extended
   Untracked net resources: none
havoc@h1000:~$ pfexec acctadm -e extended -f /var/log/ipqos/hseries/hseries.log net
havoc@h1000:~$ pfexec acctadm net
   Net accounting: active
   Net accounting file: /var/log/ipqos/hseries/hseries.log
   Tracked net resources: extended
   Untracked net resources: none

Estadísticas Avanzadas de Red
Ahora que ya sabemos activar el sistema de auditoría para la red en Solaris/OpenIndiana, podemos utilizar las funciones avanzadas del comando

Para ello, utilizaremos las opciones <-h -f {archivo-de-auditoria}>, por ejemplo, siguiendo con nuestro ejemplo:

havoc@h1000:~$ pfexec flowstat -h -f /var/log/ipqos/hseries/hseries.log

Esto nos daría un resumen de los datos, por ejemplo:

havoc@h1000:~$ pfexec flowstat -h -f /var/log/ipqos/hseries/hseries.log
FLOW      DURATION IPACKETS RBYTES OPACKETS OBYTES BANDWIDTH
dns-flow   2655      42       6330   42       3834 0 Mbps
http-flow 2655      5662     535659 7389     94452 0.04 Mbps
https-flow 2655      16       1391   24       946   0 Mbps

Estadísticas Utilizando un Rango de Fechas
Si queremos ver los datos capturados utilizando un rango de fechas, deberemos utilizar las opciones <-s {fecha,hora inicial} -e {fecha,hora final}>, por ejemplo, si queremos saber el tráfico entre las 22:00h y las 22:02h para el flow haremos

havoc@h1000:~$ pfexec flowstat -h -f /var/log/ipqos/hseries/hseries.log -s 07/24/2011,22:00:00 -e 07/24/2011,22:02:00 http-flow
FLOW         START      END      RBYTES   OBYTES   BANDWIDTH
http-flow    21:59:57 22:00:17 3105     5141     0.003 Mbps
http-flow    22:00:17 22:00:37 3518     5145     0.003 Mbps
http-flow    22:00:37 22:00:57 2913     4646     0.003 Mbps
http-flow    22:00:57 22:01:17 3568     5950     0.003 Mbps
http-flow    22:01:17 22:01:37 2676     4592     0.002 Mbps
http-flow    22:01:37 22:01:57 2971     5099     0.003 Mbps

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

Conclusiones
Hemos visto cómo podemos utilizar el sistema de auditoría de Solaris/OpenIndiana para registrar los eventos de red.

Además, esto nos da las bases necesarias para poder explorar los sistemas de auditoría que nos aporta Solaris/OpenIndiana así que ... ya lo veremos dentro de nuestra serie RBAC, Privilegios y Permisos en Solaris

El comando "at" de Solaris/OpenIndiana

noreply@blogger.com (Urko Benito) — Sun, 19 Jun 2011 09:39:00 +0000

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 funciona el sistema de instalación por paquetes IPS en OpenIndiana y Solaris - Parte 1

noreply@blogger.com (Urko Benito) — Sun, 05 Jun 2011 18:42:00 +0000

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

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

noreply@blogger.com (Urko Benito) — Thu, 26 May 2011 18:35:00 +0000

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.

Resumen de mi Trabajo en HavocTec

noreply@blogger.com (Urko Benito) — Sun, 22 May 2011 19:20:00 +0000

Hoy no voy a hablar sobre Solaris, OpenIndiana o PostgreSQL .... no, no, no, hoy voy a hacer un "resumen en voz alta" de mis experiencias en HavocTec.

Lo cierto es que, aunque no tengo todo el tiempo que me gustaría para dedicarme al blog -creo que ninguno lo tenemos-, muchos de los posts están inspirados en algo que he hecho -o he tenido que diseñar- tanto en HavocTec como en los productos que disponemos (HSeries, SafeChildren).

Han pasado muchas cosas desde que decidí incorporarme a HavocTec, y, ciertamente no me arrepiento de haberlo hecho, ya que, creo que contribuir a la creación de un Sistema de Gestión de Internet me ha servido para aprender mucho, y, poner ese "granito de arena" contra lo Pornografía Infantil, Acoso, CyberBulling y otras lacras que nos empiezan a sonar bastante más de lo que me gustaría.

Me ha permitido llevar temas de seguridad a niveles "más humanos" -por ejemplo Charlas con Padres preocupados por sus niños- y, eso, hace ver que la tecnología tiene un lado humano muy gratificante.

Por eso, quería felicitar a todo el equipo de HavocTec y espero seguir disfrutando como hasta ahora con ellos.

Urko Benito,

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

noreply@blogger.com (Urko Benito) — Mon, 09 May 2011 21:56:00 +0000

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

noreply@blogger.com (Urko Benito) — Fri, 29 Apr 2011 07:25:00 +0000

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

noreply@blogger.com (Urko Benito) — Sun, 17 Apr 2011 21:29:00 +0000

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

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

noreply@blogger.com (Urko Benito) — Mon, 11 Apr 2011 11:22:00 +0000

Introducción
Una de las tecnologías que OpenSolaris nos dejó fue la "Virtualización de la Infraestructura de Red". Actualmente tanto OpenIndiana como Solaris 11 incorporan esta tecnología, que, aunque un poco desconocida, realmente muy potente.

En esta serie de artículos vamos a ver cómo podemos utilizar esta tecnología en nuestras máquinas de producción.

¿Virtualizar Infraestructura de Red?
Si, es correcto. Crossbow nos permite virtualizar nuestra infraestructura -switches, routers, tarjetas- por lo tanto, nos permite diseñar una "infraestructura virtual" completa.

Sin embargo, vamos a ver un enfoque más "práctico" a la virtualización de la infraestructura de Red, y, sobre todo, cómo utilizarlo en nuestro equipos de producción.

El uso de Solaris Zones es una ventaja importante, pero, si queremos "mover" nuestras máquinas virtuales de un host a otro, tenemos algunos problemas -por ejemplo el nombre de la tarjeta de red-. Utilizando una tarjeta virtual, eliminaremos este problema, y, además podremos añadir soporte IPFilter a nuestra zona ya que podemos poner <ip-type=exclusive> en vez de <shared>

Por último, crossbow incluye una nueva forma de manejar QoS, y sí, esta vez, es sencilla y muy eficiente.

El comando <dladm>
La gestión de la virtualización de red se encuentra en el comando </usr/sbin/dladm> que, nos proporciona los métodos para: crear, modificar y borrar elementos virtuales -vnic, etherstub, bridge, vlan-

Si ejecutamos el comando -teniendo en cuenta que debemos disponer de permisos suficientes- sin argumentos, se nos muestra las diferentes opciones

itily@openzooey:~$ pfexec /sbin/dladm
usage: dladm <subcommand> <args> ...
    rename-link      <oldlink> <newlink>
    show-link        [-pP] [-o <field>,..] [-s [-i <interval>]] [<link>]

    create-aggr      [-t] [-P <policy>] [-L <mode>] [-T <time>] [-u <address>]
                     -l <link> [-l <link>...] <link>
    delete-aggr      [-t] <link>
    add-aggr         [-t] -l <link> [-l <link>...] <link>
    remove-aggr      [-t] -l <link> [-l <link>...] <link>
    modify-aggr      [-t] [-P <policy>] [-L <mode>] [-T <time>] [-u <address>]
                     <link>
    show-aggr        [-pPLx] [-o <field>,..] [-s [-i <interval>]] [<link>]

    scan-wifi        [-p] [-o <field>,...] [<link>]
    connect-wifi     [-e <essid>] [-i <bssid>] [-k <key>,...] [-s wep|wpa]
                     [-a open|shared] [-b bss|ibss] [-c] [-m a|b|g] [-T <time>]
                     [<link>]
    disconnect-wifi [-a] [<link>]
    show-wifi        [-p] [-o <field>,...] [<link>]

    set-linkprop     [-t] -p <prop>=<value>[,...] <name>
    reset-linkprop   [-t] [-p <prop>,...] <name>
    show-linkprop    [-cP] [-o <field>,...] [-p <prop>,...] <name>

    show-ether       [-px][-o <field>,...] <link>

    create-secobj    [-t] [-f <file>] -c <class> <secobj>
    delete-secobj    [-t] <secobj>[,...]
    show-secobj      [-pP] [-o <field>,...] [<secobj>,...]

    create-vlan      [-ft] -l <link> -v <vid> [link]
    delete-vlan      [-t] <link>
    show-vlan        [-pP] [-o <field>,..] [<link>]

    create-iptun     [-t] -T <type> [-a {local|remote}=<addr>,...] <link>]
    delete-iptun     [-t] <link>
    modify-iptun     [-t] -a {local|remote}=<addr>,... <link>
    show-iptun       [-pP] [-o <field>,..] [<link>]

    delete-phys      <link>
    show-phys        [-pP] [-o <field>,..] [-H] [<link>]

    create-vnic      [-t] -l <link> [-m <value> | auto |
                     {factory [-n <slot-id>]} | {random [-r <prefix>]} |
                     {vrrp -V <vrid> -A {inet | inet6}} [-v <vid> [-f]]
                     [-p <prop>=<value>[,...]] <vnic-link>
    delete-vnic      [-t] <vnic-link>
    show-vnic        [-pP] [-l <link>] [-s [-i <interval>]] [<link>]

    create-part      [-t] [-f] -l <link> [-P <pkey>]
                     [-R <root-dir>] <part-link>
    delete-part      [-t] [-R <root-dir>] <part-link>
    show-part        [-pP] [-o <field>,...][-l <linkover>]
                     [<part-link>]
    show-ib          [-p] [-o <field>,...] [<link>]

    create-etherstub [-t] <link>
    delete-etherstub [-t] <link>
    show-etherstub   [-t] [<link>]

    create-bridge    [-R <root-dir>] [-P <protect>] [-p <priority>]
                     [-m <max-age>] [-h <hello-time>] [-d <forward-delay>]
                     [-f <force-protocol>] [-l <link>]... <bridge>
    modify-bridge    [-R <root-dir>] [-P <protect>] [-p <priority>]
                     [-m <max-age>] [-h <hello-time>] [-d <forward-delay>]
                     [-f <force-protocol>] <bridge>
    delete-bridge    [-R <root-dir>] <bridge>
    add-bridge       [-R <root-dir>] -l <link> [-l <link>]... <bridge>
    remove-bridge    [-R <root-dir>] -l <link> [-l <link>]... <bridge>
    show-bridge      [-p] [-o <field>,...] [-s [-i <interval>]] [<bridge>]
    show-bridge      -l [-p] [-o <field>,...] [-s [-i <interval>]] <bridge>
    show-bridge      -f [-p] [-o <field>,...] [-s [-i <interval>]] <bridge>
    show-bridge      -t [-p] [-o <field>,...] [-s [-i <interval>]] <bridge>

    show-usage       [-a] [-d | -F <format>] [-s <DD/MM/YYYY,HH:MM:SS>]
                     [-e <DD/MM/YYYY,HH:MM:SS>] -f <logfile> [<link>]

Ver los interfaces "físicos"
El primer paso es conocer nuestros interfaces físicos, y para ello utilizaremos el argumento <show-phys>

itily@openzooey:~$ pfexec /usr/sbin/dladm show-phys
LINK         MEDIA      STATE      SPEED DUPLEX    DEVICE
e1000g0      Ethernet   up         1000   full      e1000g0
e1000g1      Ethernet   unknown    0      half      e1000g1

Ver los estado de los "enlaces"
Ahora debemos conocer "cómo están conectados" nuestros enlaces, para ello, utilizaremos la opción <show-link>

itily@openzooey:~$ pfexec dladm show-link
LINK        CLASS     MTU    STATE    BRIDGE     OVER
e1000g0     phys      1500   up       --         --
e1000g1     phys      1500   unknown --         --

Virtualizar Interfaces de Red
Crossbow nos permite virtualizar los interfaces de red físicos, y asignarlos a una zona de Solaris como <ip-type=exclusive> de esta forma, podemos utilizar IPFilter de forma separada, y, también "mover" nuestra zona a otro host sin importarnos si la tarjeta de red es o no la misma.

Por defecto utilizaremos el nombre <vnicN> para definir nuestros interfaces virtuales, esto es debido a que en OpenSolaris existía un problema con la nomenclatura, y os recomiendo no cambiar a nombres "más complicados".

Para la creación de un interface virtual debemos seleccionar sobre que "interface físico" queremos montarlo, en nuestro caso lo haremos sobre <e1000g0> y lo llamaremos <vnic1>

itily@openzooey:~$ pfexec /sbin/dladm create-vnic -l e1000g0 vnic1

Ver Interfaces Virtuales
Para ver que interfaces virtuales tenemos declarados en nuestro host, utilizaremos la opción <show-vnic> y para ver su estado utilizaremos <show-link>

itily@openzooey:~$ pfexec /sbin/dladm show-vnic
LINK    OVER    SPEED MACADDRESS      MACADDRTYPE VID
vnic1   e1000g0 1000   2:8:20:cd:ad:34 random       0
itily@openzooey:~$ pfexec dladm show-link
LINK        CLASS     MTU    STATE    BRIDGE     OVER
e1000g0     phys      1500   up       --         --
e1000g1     phys      1500   unknown --         --
vnic1       vnic      1500   up       --         e1000g0

Como vemos, <vnic1> está "asociado" al link físico <e1000g0> y se encuentra como "up"

Manejo de Interface Virtuales
La ventaja de uso de interfaces de red virtuales, radica en que se utilizan de igual forma que un interface físico, por lo tanto, podemos utilizar el comando <ifconfig> para asignarle una IP y "levantarlo", por ejemplo:

itily@openzooey:~$ pfexec ifconfig vnic1 plumb
itily@openzooey:~$ pfexec ifconfig vnic1 192.168.1.20/24 broadcast + up
itily@openzooey:~$ pfexec ifconfig vnic1
vnic1: flags=1000843 mtu 1500 index 3
inet 192.168.1.20 netmask ffffff00 broadcast 192.168.1.255
ether 2:8:20:cd:ad:34

Y desconectarlo ...

itily@openzooey:~$ pfexec ifconfig vnic1 unplumb
itily@openzooey:~$ pfexec ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
        inet 127.0.0.1 netmask ff000000
e1000g0: flags=1004843 mtu 1500 index 2
        inet 192.168.1.12 netmask ffffff00 broadcast 192.168.1.255
        ether 8:0:27:86:70:32
lo0: flags=2002000849 mtu 8252 index 1
        inet6 ::1/128

Eliminar un Interface Virtual
Para eliminar un interface de red virtual, deberemos utilizar la opción <delete-vnic> del comando <dladm>, por ejemplo,

itily@openzooey:~$ pfexec dladm delete-vnic vnic1
itily@openzooey:~$ pfexec dladm show-vnic

Ver las propiedades de un Enlace
Una de las opciones más interesantes que nos proporciona esta tecnología es tratar a los interfaces virtuales como "físicos" y, por lo tanto, podemos modificar los parámetros del enlace de forma similar.

Las propiedades de un enlace las obtendremos con la opción <show-linkprop> y el nombre del enlace, en nuestro caso <vnic1>.

El valor de PERM nos indicará si es posible modificarlo (rw), o por el contrario si es de sólo lectura (r-). Aunque hay muchas propiedades, hoy nos centraremos en dos: maxbw y priority.

itily@openzooey:~$ pfexec dladm show-linkprop vnic1
LINK         PROPERTY        PERM VALUE          DEFAULT        POSSIBLE
vnic1        autopush        rw   --             --             --
vnic1        zone            rw   --             --             --
vnic1        state           r-   unknown        up             up,down
vnic1        mtu             rw   1500           1500           1500
vnic1        maxbw           rw   --             --             --
vnic1        cpus            rw   --             --             --
vnic1        cpus-effective r-   0              --             --
vnic1        pool            rw   --             --             --
vnic1        pool-effective r-   --             --             --
vnic1        priority        rw   high           high           low,
                                                                medium,
                                                                high
vnic1        tagmode         rw   vlanonly       vlanonly       normal,vlanonly
vnic1        protection      rw   --             --       mac-nospoof,
                                                          restricted,
                                                          ip-nospoof,
                                                          dhcp-nospoof
vnic1        allowed-ips     rw   --             --             --
vnic1        allowed-dhcp-cids rw --             --             --
vnic1        rxrings         rw   --             --             --
vnic1        rxrings-effective r- --             --             --
vnic1        txrings         rw   --             --             --
vnic1        txrings-effective r- --             --             --
vnic1        txrings-available r- 0              --             --
vnic1        rxrings-available r- 0              --             --
vnic1        rxhwclnt-available r- 0             --             --
vnic1        txhwclnt-available r- 0             --             --

Modificar una propiedad de un enlace
Si la propiedad es de lectura y escritura (rw) entonces, podemos cambiar su valor utilizando la opción <set-linkprop -p OPCION=VALOR>, por ejemplo, vamos a modificar la velocidad de nuestro enlace <vnic1> y vamos a ponerlo a 10Mb en vez de 1000Mb:

itily@openzooey:~$ pfexec dladm set-linkprop -p maxbw=10m vnic1
itily@openzooey:~$ pfexec dladm show-vnic
LINK OVER SPEED MACADDRESS MACADDRTYPE VID
vnic1 e1000g0 10 2:8:20:74:9a:f3 random 0

Y ahora la prioridad

itily@openzooey:~$ pfexec dladm set-linkprop -p priority=low vnic1

Crear una Zona con <ip-type=exclusive>
Como es costumbre en el blog, después de un poco de teoría, viene la práctica "real". Esta vez vamos a crear una zona de Solaris/OpenIndiana y vamos a asignar la IP como "exclusiva" para poder incluir IPFilter y poder gestionar el ancho de banda que nos consume nuestra zona.

Para ello, primero crearemos un sistema ZFS donde alojaremos la zona -zonepath- llamado </export/zones> (En mi caso el zpool es "rpool1"). Si ya disponéis de un espacio ZFS para zonas, no es necesario crear uno nuevo.

itily@openzooey:~$ pfexec zfs create rpool1/export/zones

Ahora ya podemos crear la zona, utilizaremos como nombre <pkg-srv> -espero que intuyáis para que la utilizaremos-

itily@openzooey:~$ pfexec zonecfg -z pkg-srv
pkg-srv: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:pkg-srv> create
zonecfg:pkg-srv> set zonepath=/export/zones/pkg-srv
zonecfg:pkg-srv> set ip-type=exclusive
zonecfg:pkg-srv> set scheduling-class=FSS
zonecfg:pkg-srv> add net
zonecfg:pkg-srv:net> set physical=vnic1
zonecfg:pkg-srv:net> end
zonecfg:pkg-srv> verify
zonecfg:pkg-srv> commit
zonecfg:pkg-srv> exit
itily@openzooey:~$ pfexec zoneadm -z pkg-srv install

Encender la zona

itily@openzooey:~$ pfexec /usr/sbin/zoneadm -z pkg-srv boot

Conectarse a la Consola
Para los que no tenemos un teclado en_US el carácter de escape de <zlogin> es un poco complicado, así que pongo un carácter más sencillo "#." de ahí la opción -e\#

itily@openzooey:~$ pfexec zlogin -C -e\# pkg-srv
[Connected to zone 'pkg-srv' console]

Pantalla de Resumen de Red
Aquí os dejo la pantalla de resumen del asistente de configuración de la zona, y como podéis ver, para él (Solaris/OpenIndiana), el uso de una interface virtual no representa ningún cambio, la trata "igual"

─ Confirm Information for vnic1 ──────────────────

> Confirm the following information. If it is correct, press F2; to change any information, press F4.

                  Host name: pkg-srv
                 IP address: 192.168.1.20
    System part of a subnet: Yes
                    Netmask: 255.255.255.0
                Enable IPv6: No
              Default Route: Specify one
          Router IP Address: 192.168.1.1

────────────────────────────────────────────────
    Esc-2_Continue    Esc-4_Change    Esc-6_Help

Instalar IPFilter
Una vez finalizado el proceso de configuración de la zona, podemos realizar la Instalación de IPFilter en la Zona con un simple

root@pkg-srv:~# pkg install ipfilter

Conclusiones
En esta primera parte hemos visto cómo es muy sencillo crear interfaces virtuales y, como se comportan "igual" que los físicos. Además, al poder modificar las propiedades de una forma "sencilla", tenemos un control más exhaustivo.

En las siguientes entregas veremos un poco más sobre propiedades, flujos y, sobre todo, cómo aplicarlo a nuestros entornos de producción, pero hasta entonces ... a esperar.

Como siempre, cualquier duda o sugerencia es bienvenida,

Referencias

Instalar PostgreSQL 9.0.3 64bit en OpenIndiana con soporte UUID

noreply@blogger.com (Urko Benito) — Fri, 01 Apr 2011 06:01:00 +0000

Introducción
Continuando con algunas de las características de los módulos "contrib" que tenemos en PostgreSQL, y de algunas dependencias de OpenBravo, vamos a ver cómo podemos Instalar PostgreSQL 9.0.3 en 64bits sobre OpenIndiana con soporte para UUID.

Requisitos Previos
Antes de poder continuar, es necesario Instalar OSSP-UUID en OpenIndiana, en nuestro caso en 64bits -como vimos anteriormente-

Además, os recomiendo -si no lo sabéis ya- leer los post sobre Instalar PostgreSQL 9.x en OpenIndiana y Requisitos de Instalación de PostgreSQL 9.x en OpenIndiana

Instalación desde el Binario
Para aquellos que no tengáis tiempo -o ganas- os dejo una versión de PostgreSQL 9.0.3 64bits con soporte para OSSP UUID que simplemente hay que descargar e Instalar el módulo en PostgreSQL -ver más abajo-

root@openzooey:/# cd /
root@openzooey:/# wget http://blog.sfchildren.com/blogger/postgres/9.0.3/openindiana/postgresql-9.0.3-x86-64bit-openindiana-with-uuid.tar.gz
root@openzooey:/# gzip -dc postgresql-9.0.3-x86-64bit-openindiana-with-uuid.tar.gz | tar xpf -
root@openzooey:/# chown -R postgres:postgres /u01
root@openzooey:/# rm postgresql-9.0.3-x86-64bit-openindiana-with-uuid.tar.gz

Compilación de PostgreSQL
La compilación de PostgreSQL no supone mayor problema que añadir en el script de configuración la opción <--with-ossp-uuid> para que nos permita utilizar nuestro creador de UUID.

Sin embargo, tendremos que exportar nuestro <LD_LIBRARY_PATH> para que el script <configure> pueda "testear" correctamente el acceso a la biblioteca "uuid" que hemos compilado.

Una vez hecho esto, la compilación es, igual que siempre. Vamos a verlo:

$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/ossp-uuid/lib/64
$ 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 -R/opt/ossp-uuid/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:/opt/ossp-uuid/include \
    --with-libs=/lib/64:/usr/lib/64:/usr/sfw/lib/64:/opt/ossp-uuid/lib/64 \
    --with-ossp-uuid

Compilación e Instalación
Como siempre, ejecutaremos los comando <make> y <pfexec make install>

$ make
$ pfexec make install

NOTA: El proceso de instalación completo se encuentra detallado en Cómo Instalar PostgreSQL 9 64bits en OpenIndiana con SMF

Compilación del Módulo UUID
Para compilar el módulo de UUID, será necesario tener instalado PostgreSQL y situarse en el directorio <contrib> del código fuente de PostgreSQL.

Además, tener en cuenta que debemos compilarlo con GNU Make y no con SVR4 Make. Para comprobar "cual tenéis en el path" simplemente se puede utilizar <which make> y ver cuál es, o, simplemente utilizamos <gmake>

itily@openzooey:~/postgresql-9.0.3$ cd contrib
itily@openzooey:~/postgresql-9.0.3/contrib$ cd uuid-ossp
itily@openzooey:~/postgresql-9.0.3/contrib/uuid-ossp$ gmake
itily@openzooey:~/postgresql-9.0.3/contrib/uuid-ossp$ pfexec gmake install

Esto nos creará una nueva biblioteca de enlace dinámico <uuid-ossp.so> en nuestro directorio <lib/64> de PostgreSQL:

itily@openzooey:~$ cd /u01/app/postgres/9.0/db/lib/64
itily@openzooey:/u01/app/postgres/9.0/db/lib/64$ ls -ltrh uuid-ossp.so
-rwxr-xr-x   1 root root   16K mar 30 21:09 uuid-ossp.so
itily@openzooey:/u01/app/postgres/9.0/db/lib/64$ file uuid-ossp.so
uuid-ossp.so:   ELF 64-bit LSB dynamic lib AMD64 Version 1, dynamically linked, not stripped
itily@openzooey:/u01/app/postgres/9.0/db/lib/64$ ldd uuid-ossp.so
        libuuid.so.16 => /opt/ossp-uuid/lib/64/libuuid.so.16
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libm.so.2 =>     /lib/64/libm.so.2

Instalación en PostgreSQL
Por último, sólo nos queda crear las funciones en nuestra DB de PostgreSQL, para ello, utilizaremos el script <uuid-ossp.sql> que encontraremos en $POSTGRES_HOME/share/contrib

itily@openzooey:/$ cd /u01/app/postgres/9.0/db/share/contrib
itily@openzooey:/u01/app/postgres/9.0/db/share/contrib$ ls -ltr
total 7
-rw-r--r-- 1 root mar 30 21:09 uninstall_uuid-ossp.sql
-rw-r--r-- 1 root mar 30 21:09 uuid-ossp.sql

Deberemos añadirlo a las DB que queramos, utilizando el comando <psql> y un usuario con permisos para "crear languages"

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres -d testdb -f uuid-ossp.sql
SET
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
CREATE FUNCTION
postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U test -d testdb
psql (9.0.3)
Type "help" for help.

testdb=> SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.postgresql.org');
uuid_generate_v3
--------------------------------------
cf16fe52-3365-3a1f-8572-288d8d2aaa46
(1 row)

testdb=> SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.havoctec.com/');
uuid_generate_v3
--------------------------------------
5f2f3ed0-ce36-3968-b065-4bbaf6684d22
(1 row)

testdb=> \q

Desinstalación del módulo
Para poder desinstalarlo, simplemente utilizaremos el script <uninstall_uuid-ossp.sql> de la siguiente forma:

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres -d testdb -f uninstall_uuid-ossp.sql
SET
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION
DROP FUNCTION

Algunos Errores
Si no hemos podido instalar correctamente el módulo dentro de PostgreSQL, se nos mostrará el siguiente error al tratar de usar la función:

testdb=> SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.postgresql.org');
ERROR: function uuid_ns_url() does not exist
LINE 1: SELECT uuid_generate_v3(uuid_ns_url(), 'http://www.postgresq...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.

Si intentamos crear las funciones con un usuario que no tiene permisos suficientes, tendremos el siguiente error:

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U testuser -d testdb -f uuid-ossp.sql
SET
psql:uuid-ossp.sql:9: ERROR: permission denied for language c
psql:uuid-ossp.sql:14: ERROR: permission denied for language c
psql:uuid-ossp.sql:19: ERROR: permission denied for language c
psql:uuid-ossp.sql:24: ERROR: permission denied for language c
psql:uuid-ossp.sql:29: ERROR: permission denied for language c
psql:uuid-ossp.sql:34: ERROR: permission denied for language c
psql:uuid-ossp.sql:39: ERROR: permission denied for language c
psql:uuid-ossp.sql:44: ERROR: permission denied for language c
psql:uuid-ossp.sql:49: ERROR: permission denied for language c
psql:uuid-ossp.sql:54: ERROR: permission denied for language c

Conclusiones
Parece más complicado de lo que parece, pero al final, resulta bastante sencillo. Además, debemos recordar que a partir de ahora, tenemos que incluir OSSP-UUID como dependencia de nuestro PostgreSQL

Referencias

Compilar OSSP UUID en OpenIndiana para PostgreSQL

noreply@blogger.com (Urko Benito) — Wed, 30 Mar 2011 22:35:00 +0000

Introducción
Aunque PostgreSQL tiene un tipo de datos UUID nativo, no existe implementación para la generación de los mismos. Por eso, es necesario utilizar una biblioteca que lo implemente, en nuestro caso OSSP-UUID.

Antes de Empezar
Lo cierto es que la Instalación de OSSP-UUID no comienza con buen pie, ya que la página oficial proporciona un servidor ftp para su descarga, pero ... no ha sido posible, así que he tenido que utilizar algún mirror para poder descargarlo.

Después de este pequeño contratiempo, ya podemos comenzar con la compilación, no exenta de problemillas, así que si no tenéis mucho tiempo y/o ganas, podéis utilizar la versión que he compilado tanto en 32bit como 64bits, aunque en la versión de 64bits no he incluido soporte para C++ ya que ha sido imposible.

Instalación desde el binario
Para aquellos que no tengáis tiempo, podéis instalar OSSP-UUID desde el binario descargando y descomprimiendo sobre el directorio </opt>

root@openzooey:/# cd /opt
root@openzooey:/opt# wget http://blog.sfchildren.com/blogger/postgres/ossp-uuid/openindiana/ossp-uuid-1.6.2-OpenIndiana-x86-32bit-64bit.tar.gz
...
root@openzooey:/opt# gzip -dc ossp-uuid-1.6.2-OpenIndiana-x86-32bit-64bit.tar.gz | tar xpf -
root@openzooey:/opt# rm ossp-uuid-1.6.2-OpenIndiana-x86-32bit-64bit.tar.gz
root@openzooey:/opt# cd ossp-uuid
root@openzooey:/opt/ossp-uuid# bin/64/uuid
2645be62-5b18-11e0-8701-8f5adc896ddd
root@openzooey:/opt/ossp-uuid# bin/uuid
2a08e9ca-5b18-11e0-9914-47107445423d

Instalación desde el código fuente
Para la instalación desde el código fuente, deberemos tener en cuenta que la compilación en 64bits no es posible realizarla utilizando el flag <--with-cxx> y debemos separar las bibliotecas de 64bits de las de 32bits utilizando <--bindir=> y <--libdir>.

Además, hay que hacer un ajuste para que nos enlace de forma correcta la biblioteca, utilizando CC="cc -m64" ya que libtool no lo pasa correctamente

Descargamos el Código Fuente

itily@openzooey:~$ wget http://www.mirrorservice.org/sites/ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz
itily@openzooey:~$ gzip -dc uuid-1.6.2.tar.gz | tar xpf -

Compilación en 64bits

itily@openzooey:~$ cd uuid-1.6.2
itily@openzooey:~/uuid-1.6.2$ export CC="cc -m64"
itily@openzooey:~/uuid-1.6.2$ export CXX=cc
itily@openzooey:~/uuid-1.6.2$ export CFLAGS="-xO3 -xspace -Xa -xildoff -m64 -xc99=none -fast -native -xCC"
itily@openzooey:~/uuid-1.6.2$ export CXXFLAGS="-xO3 -xspace -Xa -xildoff -m64 -xc99=none -fast -native -xCC"
itily@openzooey:~/uuid-1.6.2$ ./configure \
     --prefix=/opt/ossp-uuid \
     --bindir=/opt/ossp-uuid/bin/64 \
     --libdir=/opt/ossp-uuid/lib/64
itily@openzooey:~/a/uuid-1.6.2$ pfexec make install

Compilación en 32bits

itily@openzooey:~/uuid-1.6.2$ export CC="cc"
itily@openzooey:~/uuid-1.6.2$ export CFLAGS="-xO3 -xspace -Xa -xildoff -m32 -xc99=none -xCC"
itily@openzooey:~/uuid-1.6.2$ export CXXFLAGS=$CFLAGS
itily@openzooey:~/uuid-1.6.2$ ./configure \
     --prefix=/opt/ossp-uuid \
     --bindir=/opt/ossp-uuid/bin \
     --libdir=/opt/ossp-uuid/lib
itily@openzooey:~/uuid-1.6.2$ pfexec make install

Comprobación de Funcionamiento

itily@openzooey:~$ /opt/ossp-uuid/bin/uuid -v 4 -n 4
2dadf532-fddf-4902-b89b-4354f208b882
441823a3-5f73-4a9e-be28-0ed394091f7f
926c0d16-99b4-4d72-b5c7-e91933a4818a
c3347042-de2b-4407-9ba5-03ea4ef5a984
itily@openzooey:~$ /opt/ossp-uuid/bin/64/uuid -v 4 -n 4
4376f895-750a-4eef-a865-f06a89baed61
0e4bf68c-7386-4329-9aaa-9e3c3cbc0672
cb5134d4-5cbb-401b-aa70-0edcce7f1a04
ccabcd16-3227-4b59-b0de-3bad19d988f9

Instalar PostgreSQL 9.0.3 64bits con Soporte UUID en OpenIndiana >>

Conclusion
Bueno, al principio parece un poco complicado, aunque, al final, no es más que una instalación normal y, como siempre, son los 64bits los que más problemas nos dan.

Ahora sólo nos queda compilar correctamente nuestro PostgreSQL 9 con Soporte par UUID e Instalarlo en OpenIndiana

Refrencias

Instalación de PostgreSQL 9.0.3 en OpenIndiana utilizando SMF y RBAC, Requisitos

noreply@blogger.com (Urko Benito) — Sun, 20 Mar 2011 14:26:00 +0000

Introducción
Ya hemos hablado varias veces de Cómo Instalar PosgreSQL en OpenIndiana y, también Cómo Actualizar PostgreSQL en OpenIndiana.

En esta ocasión, vamos a compilar PostgreSQL 9.0.3 en 64bits y, debido a las peticiones que tengo por parte de vosotros, también en 32bits.

Además, veremos todos los requisitos necesarios para poder gestionar PostgreSQL 9.0.3 en OpenIndiana utilizando Solaris SMF y, utilizar RBAC para su gestión.

Antes de comenzar
He visto que alguno de vosotros tenéis problemas con la forma de instalación de PostgreSQL sobre OpenIndiana, y, al parecer también con el role <postgres> o los pasos de compilación.

Todos los pasos de compilación de estos post se realizan sobre OpenIndiana 64bits utilizando para la instalación el formato de <Text Install> y siguiendo los pasos de Instalar OpenIndiana en VirtualBox Paso a Paso

Así mismo, os recomiendo -si no lo habéis hecho antes- leer el post sobre Actualización de PostgreSQL 9.0.2 64bits en OpenIndiana, donde explico los pasos de una forma más detallada.

Upgrade desde OpenSolaris
Si hemos hecho el <upgrade> desde OpenSolaris, tendremos el role <postgres> y las autorizaciones necesarias, si por el contrario hemos Instalado OpenIndiana directamente, no existirán y las deberemos crear.

Comprobación de las Autorizaciones
Debemos comprobar también que tenemos las autoriaciones necesarias para poder gestionar el servicio <postgresql_9> en nuestro sistema a través de Solaris SMF.

itily@openzooey:~$ pfexec cat /etc/security/auth_attr|grep postgres
solaris.smf.manage.postgres:::Manage Postgres service states::
solaris.smf.value.postgres:::Change Postgres value properties::

Si no nos devuelve nada, entonces deberemos crearlo, para ello añadiremos las autorizaciones de la siguiente forma

root@openzooey:/# echo "solaris.smf.manage.postgres:::Manage Postgres service states::" >> /etc/security/auth_attr
root@openzooey:/# echo "solaris.smf.value.postgres:::Change Postgres value properties::" >> /etc/security/auth_attr

Verificación del Profile <Postgres Administration>
Por último, debemos comprobar que tenemos el <profile> de Administración de PostgreSQL definido en nuestro sistema, para ello, haremos

itily@openzooey:~$ pfexec cat /etc/security/prof_attr|grep Postgres
Postgres Administration::::auths=solaris.smf.manage.postgres,solaris.smf.value.postgres

Si no nos devuelve nada, deberemos crearlo de la siguiente manera:

root@openzooey:/# echo "Postgres Administration::::auths=solaris.smf.manage.postgres,solaris.smf.value.postgres" >> /etc/security/prof_attr

Comprobación del Role <postgres>
Debemos comprobar que nuestro sistema tiene el role <postgres> creado, sino, lo crearemos nosotros, para ello, simplemente buscaremos en la base de datos </etc/user_attr> y nos fijaremos en el valor de <type=> para comprobar que es un <role>, por ejemplo

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

Llegado a este punto, debemos tener en cuenta que si no existe el <role> postgres, comprobaremos si es un usuario, ya que en OpenIndiana viene como Usuario y no como Role, para ello comprobaremos que existe en </etc/passwd>

root@openzooey:/# cat /etc/passwd |grep postgres
postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh

Como vemos, existe como usuario, pero no dispone del <profile> Postgres Aministration que necesitamos, así que vamos a añadirlo utilizando la opción "-P 'Postgres Administration'".

Si intentamos modificar el <profile> de un usuario utilizando el comando <rolemod> OpenIndiana nos contestará con un mensaje come este:

root@openzooey:/# rolemod -P 'Postgres Administration' postgres
UX: rolemod: ERROR: Users must be modified with ``usermod''.

Así que utilizaremos el comando <usermod> con la misma opción

root@openzooey:/# usermod -P "Postgres Administration" postgres

Comprobamos que tenemos asignado correctamente todo, y que las autorizaciones están definidas. Para ello, utilizaremos el comando <auth postgres> para las autorizaciones y <profiles postgres> para los profiles.

root@openzooey:~# profiles postgres
postgres:
          Postgres Administration
          Basic Solaris User
          All
root@openzooey:~# auths postgres
solaris.admin.wusb.read,
solaris.device.cdrw,
solaris.device.mount.removable,
solaris.mail.mailq,
solaris.profmgr.read,
solaris.smf.manage.postgres,
solaris.smf.value.postgres

Ahora debemos dedicir si queremos seguir manteniendo el usuario, o por el contrario convertirlo a un Role y así, poder delegar las tareas de administración.

Mi recomendación es convertirlo a un role -si no lo es-, para ello, utilizaremos el comando <usermod> y la opción <-K type=role> para convertirlo, por ejemplo:

root@openzooey:/# usermod -K type=role postgres
root@openzooey:/# cat /etc/user_attr|grep postgres
postgres::::type=role;profiles=Postgres Administration

Configurar base de datos de <pfexec>
Por último, deberemos definir los comandos que el <profile> Postgres Administration puede ejecutar utilizando <pfexec>, para ello, deberemos de dar de alta.

Es muy importante que entendáis que estáis haciendo, para ello, os recomiendo leer la serie de artículos sobre Solaris RBAC y Modelo de Privilegios.

Con esto, ya tenemos la estructura para poder gestionar nuestro PostgreSQL con RBAC

Comprobación de la Arquitectura y Kernel
A continuación, vamos a comprobar que tipo de arquitectura tenemos: SPARC o x86 y sobre esta, qué tipo de kernel tenemos, de 32bit o 64bit.

Para verificar nuestra arquitectura, utilizaremos el comando <uname -a> por ejemplo:

itily@openzooey:~$ pfexec uname -a
SunOS openzooey 5.11 oi_148 i86pc i386 i86pc

Hay que tener en cuenta que el comando <uname> no nos va a decir si es o no una arquitectura de 64bits, ya que nos dirá <i386>. Esto es porque la diferencia de arquitectura es para SPARC o i386.

Para saber si nuestro kernel es de 32bit o 64bits, deberemos utilizar el comando <isainfo> con las opciones <-kv>, por ejemplo:

itily@openzooey:~$ pfexec isainfo -kv
64-bit amd64 kernel modules

Por lo tanto, ahora sabemos que estamos ejecutando OpenIndiana -o Solaris- sobre una plataforma x86 con un kernel de 64bit.

Instalación de PostgreSQL 9.0.3 desde Binarios
Ahora que ya sabemos qué arquitectura tenemos, y nuestro tipo de kernel, podemos seleccionar la versión de PostgreSQL 9.0.3 que deseemos.

Simplemente, descargaremos el binario que queramos (de 32bit o 64bit) y lo descomprimiremos en nuestro sistema, en </>

itily@openzooey:/# cd /
itily@openzooey:/# wget http://blog.sfchildren.com/blogger/postgres/9.0.3/openindiana/postgresql-9.0.3-x86-64bit-openindiana.tar.gz
itily@openzooey:/# gzip -dc postgresql-9.0.3-x86-64bit-openindiana.tar.gz | tar xvpf -
itily@openzooey:/# chown -R postgres:postgres /u01
itily@openzooey:/# chmod 750 /u01

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 y OpenIndiana SMF PostgreSQL 9 y el Method para Solaris y OpenIndiana SMF 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

Conclusion
En esta ocasión hemos visto algunos puntos necesarios para la instalación de PostgreSQL en OpenIndiana.

Además, gracias a los comentarios y dudas, creo que en esta ocasión he intentado despejar esas "dudas" que os asaltan,

Espero que os ayude y, sobre todo, aclarar los pasos de instalación.

Referencias

Cómo saber el project de un proceso concreto

noreply@blogger.com (Urko Benito) — Thu, 03 Mar 2011 07:00:00 +0000

Introducción
En alguna ocasión hemos necesitado saber en que project se encuentra nuestro proceso de Solaris, para ello, simplemente utilizaremos la opción <-o> del comando <ps> que nos permite obtener el formato de salida que queramos.

Por ejemplo, para ver los procesos del usuario <appserver> mostrando su PID, Comando y Project utilizaremos el siguiente comando:

root@h1000:/# ps -fu appserver -o pid,args,project
PID COMMAND PROJECT
1672 /usr/jdk/instances/jdk1.6.0/bin asengine.appserver

Referencias

Tomcat sobre SMF y RBAC en OpenIndiana y Solaris

noreply@blogger.com (Urko Benito) — Tue, 01 Mar 2011 09:49:00 +0000

Introducción
Ya hemos hablado del uso de Roles y Privilegios en Solaris y cómo aplicarlos a Apache Tomcat para que nos permita iniciar el servicio utilizando un usuario no privilegiado en un puerto inferior a 1024. En nuestro caso de Noviembre 2010 hablábamos de Cómo configurar HTTPS en Apache Tomcat utilizando Roles y Privilegios.

Sin embargo, si queremos gestionar nuestro servicio utilizando Solaris SMF, deberemos hacer algunos cambios en el archivo manifest de Apache Tomcat.

Asignación de Privilegios
Sabemos que para poder utilizar un puerto privilegiado (<1024) con un usuario no privilegiado, deberemos otorgarle el privilegio <net_privaddr>, y eso es lo que hicimos en nuestro post sobre Configurar HTTPS en Apache Tomcat modificando los privilegios en el role <appserver>

# rolemod -K defaultpriv=basic,net_privaddr appserver

Sin embargo, cuando ejecutamos el servicio utilizando Solaris SMF este privilegio no está "activo" debido a que en nuestro archivo "manifest" no hemos defenido que los tengan, y por lo tanto, sólo tendrá los privilegios "basic".

Modificar el Archivo Manifest
Para añadir los privilegios que deseamos, en nuestro caso <net_privaddr>, simplemente deberemos incluir la propiedad "privileges" en <method_credential>, por ejemplo,

<method_context project='appserver'>
    <method_credential
        user='appserver'
        group='appserver'
        privileges='basic,net_privaddr'/>
</method_context>

De esta forma, estamos indicando a SMF que asigne el privilegio <net_privaddr> además de los básicos, y por lo tanto, ahora si que podemos iniciar nuestro Tomcat utilizando <svcadm enable>

Algunos Privilegios Más
Recordar que si utilizamos < ! >, entonces, en vez de asignar estamos eliminando el privilegio, así que vamos a utilizarlo para evitar que "por alguna problema" puedan llegar a heredarlos, por lo tanto, nuestro parámetro "privileges" será el siguiente:

privileges='basic,!proc_session,!proc_info,!file_link_any,net_privaddr'

Añadimos Autorizaciones
Ahora vamos a unirlo al post de RBAC y Autorizaciones para Tomcat que escribí hace un tiempo, y veremos como podemos "encajar" todo en un mismo archivo manifest para utilizar: Autorizaciones y Privilegios

Nota: Es muy recomendable que echéis un vistazo al post de las autorizaciones, si no os acordáis ...

Por lo tanto, nuestra definición de Instancia quedará de la siguiente forma:

<instance name='default_64bits' enabled='false'>
<method_context>
    <method_credential
          user='tomcat6'
          group='webrunner'
privileges='basic,!proc_session,!proc_info,!file_link_any,net_privaddr'/>
</method_context>
<property_group name='tomcat_6' type='application'>
      <propval name='home' type='astring'
                value='/opt/www/tomcat6' />
      <propval name='jvmargs' type='astring'
                value='-d64 -Xms512m -Xmx512m' />
      <propval name='project' type='astring'
                value='tomcat6' />
      <propval name='java_home' type='astring'
                value='/usr/java' />
      <propval name='value_authorization' type='astring'
                        value='solaris.org.apache.smf.value.tomcat' />
</property_group>
</instance>

Con esto ya tendríamos todo nuestro Apache Tomcat dentro de Solaris SMF y utilizando Autorizaciones. Podéis descargar el archivo manifest completo desde Manifest Tomcat Roles y Privilegios

Conclusiones
Aunque parece un poco lioso al principio, luego resulta muy sencillo y, a la larga, nos proporciona una gestión mucho más avanzada y simplificada.

Muchas veces os he recomendado el uso de Roles y Privilegios, pero, espero que con estos ejemplos "reales" podáis ver las ventajas que nos ofrece su uso.

Como siempre, vuestras sugerencias son bienvenidas :D

Referencias

Instalar OpenIndiana Paso a Paso en VirtualBox

noreply@blogger.com (Urko Benito) — Mon, 14 Feb 2011 20:35:00 +0000

Introducción
En esta ocasión vamos a hablar de una instalación de OpenIndiana desde cero, sin tener que pasar por OpenSolaris, aunque como veréis es muy parecida a Cómo Instalar OpenSolaris Paso a Paso

Al igual que sucede con al Instalación de Solaris Paso a Paso, utilizaremos el instalador de Texto, y por lo tanto, deberemos utilizar las teclas F2, F3 y F5 para <avanzar, retroceder y salir> según nos indique el instalador.

Como ya hemos hablado muchas veces de cómo crear una máquina Virtual en VirtualBox para Solaris/OpenSolaris, no voy a entrar en muchos detalles sobre ello, sólo a modo de recordatorio, es mejor utilizar una única CPU durante el proceso de Instalación y la memoria mínima debe ser de 780Mb.

Aquí os dejo un video de Cómo Instalar OpenSolaris Paso a Paso para los despistados :D

Descargar la Imagen
Como hemos comentado antes, vamos a Instalar OpenIndiana utilizando el instalador de Texto, ya que queremos tener una configuración de servidor, y por lo tanto, no necesitamos los paquetes de escritorio y/o interface gráfico. Esto hará que nuestra instalación requiera unos 2.5Gb de espacio, así que se instalará muy rápido.

Podemos descargar la imagen desde http://openindiana.org/download/ y seleccionaremos la Imagen Text Install CD http://dlc.openindiana.org/isos/148/oi-dev-148-text-x86.iso

Una vez descargada, deberemos darla de alta en nuestra máquina virtual para poder utilizarla como Disco CD de Arranque.

Proceso de Instalación
Una vez tengamos nuestra máquina virtual creada, comenzaremos con la instalación de OpenIndiana

1.- Configuración del Teclado.
Seleccionaremos el tipo de teclado que tenemos, en mi caso seleccionaremos: Spanish(39), Spanish (21)

2.- Inicio del proceso de Instalación.
Seleccionaremos la opción 1 y pulsaremos INTRO para iniciar la instalación

3.- Pantalla de Ayuda
En esta pantalla se nos muestran las indicaciones de cómo funciona el instalador de texto. Se nos recuerda que debemos utilizar las teclas F2 para continuar <si estais en una VT podéis utilizar ESC+Número>

4.- Selección del Disco
En esta pantalla seleccionaremos el disco sobre el cual queremos instalar Solaris, y, como es nuestro caso nos indica que no tenemos ninguna partición Solaris creada -ya que está vacío-

5.- Tamaño de la Partición
En esta pantalla podemos seleccionar cómo queremos particionar el disco para Solaris, si lo queremos entero o sólo una parte.

Nosotros vamos a utilizar el disco íntegramente para Solaris, así que seleccionamos <Use the whole disk>

6.- Configuración de la Red
En esta pantalla podemos seleccionar la configuración Automática de la Red, o por el contrario no hacer la configuración ahora.

Yo, por costumbre muy antigua, nunca activo la Red de los sistemas mientras los estoy configurando, es una manía que tengo desde hace mucho tiempo para evitar que "alguien" me toque el sistema en su estado "más inseguro" y, por eso, hasta que no lo tengo configurado no levanto la Red.

Todo esto viene de Solaris 8, cuando la instalación activaba un montón de servicios, y por lo tanto, había más problemas, pero ... nunca está de más.

Así que, yo he seleccionado <none> para la configuración de Red, pero podéis utilizar la opción <Automatically> si disponéis de un servidor DHCP, este levantará el interface.

7.- Configuración de la Región
En mi caso he seleccionado <Europe>

8.- Selección del País
En mi caso he seleccionado <Spain>

9.- Franja Horaria
Como disponemos varias franjas horarias, me pide que selecciona una. Si no es vuestro caso, no aparecera.

10.- Ajuste de Fecha y Hora
Lo cierto es que nunca me preocupa mucho este paso, principalmente porque siempre Sincronizo el reloj mediante NTP en Solaris y OpenIndiana

11.- Creación de la Contraseña de <root> y usuario <privilegiado>
Este paso es importante, ya que a diferencia de Solaris, <root> pasa a ser un <role> y el usuario que creemos pertenecerá al role <root> y tendrá como autorizaciones <solaris.system.power>, solaris.network.autoconf, es decir, puede ejecutar comandos para encender y apagar el sistema, y activar el sistema de configuración automática de red.

Si no sabéis como funcionan, os recomiendo leer RBAC Roles y Privilegios en Solaris.

12.- Resumen de la Configuración
En esta pantalla nos muestra un resumen de la configuración del instalador, el siguiente paso dará comienzo a la instalación de OpenIndiana, así que si queremos cambiar algo, podemos hacerlo pulsando <F3> o <ESC-3>

13.- Proceso de Instalación
Esto nos llevará unos 30min -más o menos- así que podéis tomaros un descanso ...

14.- Finalización Proceso
Una vez el proceso ha finalizado se muestra la pantalla para que reiniciemos el equipo y ya tendremos instalado -que no configurado- nuestro OpenIndiana

14.1.- Si algo falla
Lo cierto es que puede que el sistema de instalación falle -normalmente por una incompatibilidad de configuración-

Después de la Instalación
Una vez instalado OpenIndiana, vamos a configurar nuestro sistema para finalizar la instalación.

Finalizar la Instalación
Vamos a configurar algunos parámetros del kernel, para ello, deberemos iniciar la sesión con el usuario que hemos creado -en nuestro caso itily- y después nos cambiaremos a <root> para asumir su rol.

Editaremos el número máximo de descriptores, los asignaremos a 8192 -en vez de 256- y algunos cambios menores.

Pondremos un <Banner> en el acceso mediante ssh -puedes ver Cómo crear un Banner para SSH en Solaris 10-

Activaremos la opción <Banner /etc/issue> en el archivo de configuración de SSH </etc/ssh/sshd_config>

Crearemos el archivo </reconfigure> para que nos reconfigure los dispositivos (no es realmente necesario, pero ... es una constumbre que tengo)

Configurar la Red y Actualizar la Distribución
Por último, vamos a levantar el interface y lanzaremos el comando <pkg image-update> para actualizar la imagen a su última versión.

Para ello, utilizaremos la tarjeta <e1000g0> con una configuración mediante DHCP para actualizar la imagen mediante el comando <pkg image-update>

Sincronizar el Reloj
Para finalizar, sincronizaremos el reloj del sistema utilizando un servidor NTP, en mi caso vamos a utilizar <hora.rediris.es>

Conclusiones
Bueno, hemos visto que OpenIndiana no difiere mucho de OpenSolaris o Solaris 11. Con este formato Paso a Paso, he querido mostrar que OpenIndiana no es tan fiero como lo pintan ...

Espero que os sirva, y como siempre, espero vuestras opiniones.

Cómo montar un CHROOT en tiempos de Virtualización

noreply@blogger.com (Urko Benito) — Fri, 04 Feb 2011 09:06:00 +0000

Intdoducción
Con la llegada de Solaris 10 y sus containers, muchos de nosotros comenzamos a "migrar" nuestros servicios a contenedores y, por ello, dejamos de utilizar -y hablar- de los chroot. Es cierto que un "container" o "LDOM" nos proporciona una gestión mucho más fina, y por lo tanto, podemos definir los recursos, usuarios, etc. y sobre todo, aislar totalmente un entorno de otro.

Sin embargo, cuando nuestros recursos físicos están muy limitados -pensemos en un appliance, por ejemplo-, y debemos tratar de tener nuestro "servicio" lo más aislado posible podemos seguir utilizando esta "reliquia del pasado", que, funciona a la perfección.

Nota: Este post es una adaptación a la respuesta que hice en StackOverFlow sobre Cómo crear un SandBox en Unix

Qué es un ChRoot
Bueno, técnicamente es ejecutar un proceso con un "/" diferente a nuestro sistema principal, es decir, por ejemplo "/chroot_example/", por lo tanto, para nuestro "proceso" su "/" será "/chroot_example" y no podrá acceder a aquellas partes que necesitamos asegurar

Para Qué un ChRoot en Tiempos de Containers
Bueno, como os decía en la introducción, depende sobre todo de los recursos que dispongamos, así que si no tenemos muchos, deberemos utilizar técnicas como esta para tratar de aislar -en la medida de lo posible- nuestro proceso

ChRoot o Container
Bueno, esta es una pregunta un poco "compleja de responder", aunque intentaré salir "airoso" diciendo: depende. ¿De qué depende? Principalmente de recursos, tipos de servicios y administración. Mi recomendación es, si es posible utilizar Solaris Containers -o LDOMs- para servicios complejos -PostgreSQL, Hadoop, etc.- pero si necesitáis tener un "mini proceso" -o varios- no vais a crear un montón de Containers para cada uno de ellos. Es ahí donde entra nuestro ChRoot, además siempre podemos unir las dos opciones: ChRoot dentro de Containers

Un Ejemplo Completo
Después de todo este "lío", vamos a verlo claro con un ejemplo. Para ello, necesitamos ejecutar un comando -en nuestro caso ls- que nos devuelva el listado de nuestro "directorio /etc" -no el de sistema- donde tenemos la licencia de nuestro aplicativo.

La estructura de nuestro "chroot" sería la siguiente:

    /
    /etc
     + license
    /bin
     + ls
    /lib
     + ...

Creación de la Estructura de ChRoot
Hemos comentado que un "ChRoot" es definir un nuevo "root" para el sistema de archivos de un proceso, y por lo tanto, deberemos "reproducir" el sistema principal con, al menos los directorios básicos: /etc, /bin, /lib

    itily@openzooey:~$ mkdir chroot_example
    itily@openzooey:~$ cd chroot_example/
    itily@openzooey:~/chroot_example$ mkdir -p usr/lib lib bin etc
    itily@openzooey:~/chroot_example$ cd bin/
    itily@openzooey:~/chroot_example/bin$ cp /bin/ls .

Ahora vamos a copiar las "shared lib" que nuestro binario necesita -en nuestro caso ls-, para ello, utilizaremos el comando: <ldd>

itily@openzooey:~/chroot_example/bin$ ldd ls
            libsec.so.1 =>       /lib/libsec.so.1
            libnvpair.so.1 =>    /lib/libnvpair.so.1
            libcmdutils.so.1 => /lib/libcmdutils.so.1
            libcurses.so.1 =>    /lib/libcurses.so.1
            libc.so.1 =>         /lib/libc.so.1
            libavl.so.1 =>       /lib/libavl.so.1
            libidmap.so.1 =>     /usr/lib/libidmap.so.1
            libnsl.so.1 =>       /lib/libnsl.so.1
            libuutil.so.1 =>     /lib/libuutil.so.1
            libmp.so.2 =>        /lib/libmp.so.2
            libmd.so.1 =>        /lib/libmd.so.1
            libm.so.2 =>         /lib/libm.so.2

Vamos a copiar las bibliotecas utilizando un pequeño script. Desde el directorio <bin> de nuestro <chroot> hacemos:

itily@openzooey:~/chroot_example/bin$ ldd ls |awk '{print "cp "$3" .."$3}'
cp /lib/libsec.so.1 ../lib/libsec.so.1
cp /lib/libnvpair.so.1 ../lib/libnvpair.so.1
cp /lib/libcmdutils.so.1 ../lib/libcmdutils.so.1
cp /lib/libcurses.so.1 ../lib/libcurses.so.1
cp /lib/libc.so.1 ../lib/libc.so.1
cp /lib/libavl.so.1 ../lib/libavl.so.1
cp /usr/lib/libidmap.so.1 ../usr/lib/libidmap.so.1
cp /lib/libnsl.so.1 ../lib/libnsl.so.1
cp /lib/libuutil.so.1 ../lib/libuutil.so.1
cp /lib/libmp.so.2 ../lib/libmp.so.2
cp /lib/libmd.so.1 ../lib/libmd.so.1
cp /lib/libm.so.2 ../lib/libm.so.2

Una vez verificado, ya podemos copiar las bibliotecas

itily@openzooey:~/chroot_example/bin$ ldd /bin/ls |awk '{print "cp "$3" .."$3}'|bash
itily@openzooey:~/chroot_example/bin$

Ahora tenemos nuestra estructura completa, y tiene la siguiente forma:

itily@openzooey:~/chroot_example$ ls -l
total 12
drwxr-xr-x   2 itily staff          3 dic 22 14:37 bin
drwxr-xr-x   2 itily staff          5 ene 10 20:43 etc
drwxr-xr-x   2 itily staff         14 ene 10 20:48 lib
drwxr-xr-x   3 itily staff          3 ene 10 20:40 usr

Añadimos los archivos de <group> y <passwd> con el usuario que será el encargado de ejecutar el proceso -en mi caso itily- y creamos nuestra "licencia"

itily@openzooey:~/chroot_example$ echo "this is a test" > etc/license
itily@openzooey:~/chroot_example$ cd etc/
itily@openzooey:~/chroot_example/etc$ cat /etc/group |grep staff > group
itily@openzooey:~/chroot_example/etc$ cat /etc/passwd |grep itily > passwd

Ejecutar el comando <chroot>
Por último, ya sólo nos queda ejecutar el comando < que tiene el siguiente formato:

chroot rootdir command [arg ...]

Debemos tener en cuenta que si ejecutamos el comando <chroot> con un usuario sin privilegios de "root", tendremos el siguiente mensaje

itily@openzooey:~$ chroot chroot_example bin/ls /etcchroot: cannot change root directory to chroot_example: Not owner

Así que utilizaremos <pfexec> -si tenemos asignado el rol de root, o nos cambiaremos a root- para ejecutarlo:

itily@openzooey:~$ pfexec chroot chroot_example /bin/ls -l /etc    total 6
    -rw-r--r--   1 101 10         11 Jan 10 19:43 group
    -rw-r--r--   1 101 10         18 Jan 10 19:42 license
    -rw-r--r--   1 101 10         49 Jan 10 19:43 passwd

Ya está! Hemos conseguido que nuestro comando <ls> nos muestre nuestro directorio </chroot_example/etc> como </etc>

Conclusiones
Aunque a veces parezca que las tecnologías antiguas ya no sirven, puede que en circunstancias nos ayuden, además, <chroot> nos permite montar sin "muchas" complicaciones algunas tareas sencillas sin tener que estar creando cientos de Containers para ello.

Referencias

Cómo Crear un FileSystem en Memoria utilizando TMPFS

noreply@blogger.com (Urko Benito) — Tue, 25 Jan 2011 16:44:00 +0000

Introducción
Vamos a ver cómo podemos utilizar el FileSystem TMPFS para crear un sistema de ficheros en Memoria en Solaris.

Ya hemos hablado en otras ocasiones sobre el sistema TMPFS y su relación con la swap en Solaris, vimos Cómo limitar el tamaño de /tmp en Solaris, sin embargo, hoy vamos a ver cómo podemos utilizarlo para crearnos un sistema de ficheros muy rápido.

Para ello, imaginando que nuestro directorio de montaje es </var/memory_fs> y que queremos asignarle un tamaño de 60Mb, haremos lo siguiente

itily@openzooey:/$ pfexec /usr/sbin/mount -F tmpfs -o size=60m -O swap /var/memory_fs
itily@openzooey:/$ pfexec df -h /var/memory_fs
Filesystem size used avail capacity Mounted on
swap 60M 0K 60M 0% /var/memory_fs

Y ya podemos trabajar con nuestro sistema de ficheros en memoria de forma normal.

Par desmontarlo, simplemente haremos un <umount> como siempre

itily@openzooey:/$ pfexec /sbin/umount /var/memory_fs

Por último, si queremos que cada vez que nuestro sistema se inicie monte de forma automática el FileSystem, editaremos el archivo </etc/vfstab>

itily@openzooey:~$ pfexec vi /etc/vfstab
swap - /var/memory_fs tmpfs - yes size=60m
:wq

Referencias

Actualización a PostgreSQL 9.0.2 en OpenIndiana b148

noreply@blogger.com (Urko Benito) — Sun, 16 Jan 2011 11:02:00 +0000

Introducción
En anteriores post hemos hablado de Cómo Instalar PostgreSQL 9.x en OpenIndiana, así que este será un revisión mínima, por ello os animos a revisarlo.

La nueva versión de PostgreSQL 9.0.2 corrige algunos problemas de memory leak y por ello, es muy recomendable su actualización. Podéis encontrar todos los cambios en el ChangeLog de PostgreSQL

En este post veremos cómo actualizar PostgreSQL 9.0 64bits a la versión PostgreSQL 9.0.2 64bits.

Antes de Comenzar
Bueno, la actualización a PostgreSQL 9.0.2 no requiere hacer un "dump/restore" siempre que nos encontremos en la línea PostgreSQL 9.x, sin embargo, yo recomiendo SIEMPRE hacer un backup antes de comenzar.

Si nos encontramos en una versión diferente, deberemos realizar un "dump/restore" obligatoriamente, así como una instalación "limpia" de PostgreSQL 9.x y, por lo tanto, deberemos iniciar la estrucutra de PGDATA.

Lo cierto, es que cuando comencé a escribir el post, hice una pequeña prueba de actualización "ahí a lo bruto" sin copia de seguridad ni nada, Pensé ¿total por qué va a fallar? Pues ... falló! y me quedé sin mi DB, menos mal que teneía copia de seguridad del día anterior y, que siendo sinceros, es una PostgreSQL de pruebas y no supone mayor problema.

Por eso, antes de comenzar, ya sabéis, si tenéis alguna duda de cómo se hacen, aquí os dejo un post de Cómo Realizar Copias de Seguridad en PostgreSQL.

Para versiones anteriores a PostgreSQL 9.x
Para aquellos que estéis en una versión anterior, os recomiendo primero Instalar PostgreSQL 9.0 en OpenIndiana, y que luego continueis con este post. Recordar además, que es necesario realizar un "dump/restore"

Para versiones PostgreSQL 9.x
Para los demás, comenzamos ... podéis realizar la actualización desde el código fuente, o instalar directamente los binarios.

Obtener el Codigo Fuente
Lo primero que debemos hacer es obtener el código fuente de PostgreSQL 9.0.2 que descargaremos de su página oficial, aquí os dejo un enlace a la página de descargas de PosgreSQL.

Instalar desde el Binario
Para aquellos que o bien no tenéis la posibilidad de compilarlo, o no os apetece :D, aquí os dejo la version compilada para x86 en 64bits de PostgreSQL que he realizado.

PostgreSQL 64 bit x86 OpenIndiana b148

Una vez descargado podéis ir al paso "Instalar PostgreSQL" para completar la actualización.

Preparar el Entorno
Debemos comprobar que tenemos todos los binarios necesarios para poder compilar, es decir, compilador, make, etc.

Si activamos la opción <--enable-dtrace> deberemos tener el directorio </usr/sbin> en nuestro PATH.

itily@openzooey:~/postgres/postgresql-9.0.2$ export PATH=$PATH:/usr/sbin:/sbin:/usr/ccs/bin/
itily@openzooey:~/postgres/postgresql-9.0.2$ which dtrace
/usr/sbin/dtrace
itily@openzooey:~/postgres/postgresql-9.0.2$ which cc
/usr/bin/cc
itily@openzooey:~/postgres/postgresql-9.0.2$ which make
/usr/bin/make
itily@openzooey:~/postgres/postgresql-9.0.2$ which ar
/usr/bin/ar
itily@openzooey:~/postgres/postgresql-9.0.2$ which python
/usr/bin/python

Compilar PostgreSQL
Para compilar esta versión de PostgreSQL utilizaremos las mismas opciones que antes, por lo tanto, podemos hacer un <copy and paste>, de nuestro archivo <config.log>. Para aquellos que no tenéis el <config.log>, aquí os dejo los pasos.

Recordar que, yo utilizo como $POSTGRES_HOME siempre el directorio </u01/app/postgres/> al puro estilo OFA, ...

$ 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

Instalación de PostgreSQL
Como es una actualización, antes de lanzar nuestro <make install> -o descomprimir el <tar.gz>- debemos realizar una copia de seguridad y detener nuestra PostgreSQL de forma correcta, para ello, deberemos asumir el <role> de <postgres> o uno que tengan privilegios para detenerlo e iniciarlo.

En mi caso, utilizaré el <role postgres> para realizar las tareas.

Si es la primera vez que oyes hablar de roles y privilegios, te animo a que leas RBAC, Roles y Privilegios de Solaris antes de continuar.

Comprobamos que nuestro servicio de PostgreSQL está activo, hacemos un backup y lo desactivamos.

postgres@openzooey:~$ pfexec svcs postgresql_9:default_64bit
STATE STIME FMRI
online 11:26:07 svc:/application/database/postgresql_9:default_64bit

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/pg_dump -C -Z9 -f /export/home/postgres/backups-pre-upgrade.dump.gz mydatabase
postgres@openzooey:~$ gzip -dc /export/home/postgres/backups-pre-upgrade.dump.gz |head -3
--
-- PostgreSQL database dump
--
postgres@openzooey:~$ pfexec /usr/sbin/svcadm disable postgresql_9:default_64bit
postgres@openzooey:~$ pfexec svcs postgresql_9:default_64bit
STATE STIME FMRI
disabled 11:33:19 svc:/application/database/postgresql_9:default_64bit

Ahora ya estamos en disposición de realizar nuestro <make install> y proceder a la instalación de PostgreSQL en nuestro sistema o, si has optado por actualizar desde el binario, a descomprimirlo.

Lanzar &lt:make install>

itily@openzooey:~/postgres/postgresql-9.0.2$ pfexec make install

O descargarlo y descromprimirlo -hay que hacerlo como <root> o con un usuario con permisos suficientes-

root@openzooey:/# cd /
root@openzooey:/# wget http://blog.sfchildren.com/blogger/postgres/9.0.2/openindiana/postgresql-9.0.2-x86-64bits.tar.gz
root@openzooey:/# gzip -dc postgresql-9.0.2-x86-64bits.tar.gz | tar xpf -
root@openzooey:/# chown -R postgres:postgres /u01
root@openzooey:/# rm postgresql-9.0.2-x86-64bits.tar.gz

Activamos el Servicio
Vamos a utilizar SMF para gestionar nuestro servicio, por lo tanto, sólo nos queda hacer un <enable> del mismo

root@openzooey:/# svcadm enable postgresql_9:default_64bit
root@openzooey:/# svcs postgresql_9:default_64bit
STATE STIME FMRI
online 13:05:36 svc:/application/database/postgresql_9:default_64bit

Comprobamos nuestro PostgreSQL

postgres@openzooey:~$ /u01/app/postgres/9.0/db/bin/64/psql -U postgres
psql (9.0.2)
Type "help" for help.

postgres=# select count(1) from pg_index;
count
-------
101
(1 row)

postgres=# \q

Conclusiones
Bueno, como hemos visto, la actualización de PostgreSQL no supone mayores problemas, siempre que estemos en el mismo nivel de versión, es decir, 9.x. Hemos dejado en el tintero las diferentes formas de actualización desde otras versiones, ya que eso requiere todo un post para ello.

Recordar que las buenas práticas de SysAdmin nos obligan a realizar copias de seguridad, y, que si por agún momento se nos pasa, entonces aparecerá nuestro querido amigo "Murphy" y nos dará algún susto.

Referencias

Feliz 2011 a todos los SysAdmin de Solaris

noreply@blogger.com (Urko Benito) — Mon, 10 Jan 2011 09:02:00 +0000

Introducción
Un nuevo año se ha asomado a nuestra vida, el 2011, con él comienzan los repasos del año que nos acaba de dejar, y las nuevas promesas y objetivos del año nuevo.

Si hacemos un repaso a nuestro 2010 se han producido muchas noticias -algunas importantes- como la "muerte de OpenSolaris", y el "nacimiento de OpenIndiana". Otras en referencia a mi carrera profesional con la creación de HavocTec como consultora de Solaris y PostgreSQL, de la que soy socio fundador :D

Pero si nos fijamos en la trayectoria del Blog, vemos que -creo- he evolucionado y hemos tocado muchos de los temas principales de Solaris, PostgreSQL y algo de Oracle.

Sin embargo, todavía queda mucho que contar. Con la introducción de OpenIndiana/OpenSolaris en el "juego" de Solaris, tenemos un nuevo sistema de paquetes, IPS. La maduración de la utilización de BootEnviroment -ya que no es una cosa nueva-, Crossbow y la "explosión" de las zonas.

Qué me gustaría para este nuevo año
Lo cierto es que creo que debemos introducirnos en el mundo de IPS, ventajas e incovenientes, así como "repositorios personalizados", réplicas y técnicas de seguridad -gracias a la sugerencia de NocThulh-

Profundizar en el uso de BootEnviroment(s) para mejorar -o marcar unas buenas prácticas- el procedimiento de parcheo de un Solaris/OpenIndiana con el objeto de reducir el "downtime"

Crossbow como tecnología de virtualización de red, optimización y gestión de los recursos.

Un repositorio público
Además, crearemos un repositorio público donde se encuentren los binarios que vamos compilando en el blog, con el objeto de hacer un poco más sencilla la vida a los SysAdmin principiantes.

PostgreSQL
Creo que este año es la maduración de PostgreSQL como RDBMS "profesional", por ello, hablaremos de cómo implementarlo, cómo gestionarlo y administrarlo.

Veremos la replicación que -a partir de la 9.x- se ha introducido, y nos puede aportar gran escalado y seguridad

Vuestras Sugerencias
Y, cómo no, aquellas sugerencias que me hacéis llegar al blog y/o al correo. Por ello, os animo a sugerir diferentes temas y tratarlos de resolver en este nuevo año que comienza

Conclusiones
Veremos cómo se depara el año, pero promete que sea entretenido ...

Feliz 2011

Bienvenido a Solaris BlackBox

tu blog de Solaris