La utilidad de monitorización en servidores Web de Sun/Oracle ha mejorado mucho a partir de la versión 7.0. Si bien antes únicamente podíamos acceder a estos datos vía web, ahora podemos hacerlo a través de la shell/CLI wadm, permitiendo acceder a estadísticas a tiempo real de monitorización sin necesidad de hacerlo vía HTTP, con los problemas que conllevaba con el sistema cargado.

La nueva versión, disponible en Sun Java System Web Server, Oracle iPlanet Web Server 7.0 o como lo queráis llamar, añade la posibilidad de ver las Ips y peticiones que se están haciendo a cada instancia y así poder detectar con mayor facilidad el origen de un cuello de botella o sobrecarga del sistema.

Para acceder a wadm nos situamos en la ruta base del servidor web y ejecutamos el siguiente comando indicando usuario y clave de administración:

root@solaris:/opt/oracle/webserver7# ./bin/wadm --user=admin
Indique admin-user-password>
Conexión a localhost:8989
Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56
wadm>

Una vez dentro, elegimos la instancia y nodo del que queremos ver las estadísticas y tendremos el volcado de información:

wadm> get-perfdump --config solaris --node localhost

La información que recibimos es la siguiente. Tened en cuenta que es un webserver de prueba por lo que no hay apenas información:

wadm> get-perfdump --config solaris --node localhost

Oracle iPlanet Web Server 7.0.12 B07/01/2011 03:56 (SunOS DOMESTIC)

Server started Sat Feb 11 15:24:28 2012
Process 1133 started Sat Feb 11 15:24:29 2012

ConnectionQueue:
-----------------------------------------
Current/Peak/Limit Queue Length            0/4/16384
Total Connections Queued                   20
Average Queue Length (1, 5, 15 minutes)    0,00, 0,00, 0,00
Average Queueing Delay                     10,88 milliseconds

ListenSocket http-listener-1:
------------------------
Address                   https://0.0.0.0:443
Acceptor Threads          1
Default Virtual Server    solaris

ListenSocket http-listener-2:
------------------------
Address                   http://0.0.0.0:80
Acceptor Threads          1
Default Virtual Server    solaris

KeepAliveInfo:
--------------------
KeepAliveCount        6/32768
KeepAliveHits         8
KeepAliveFlushes      0
KeepAliveRefusals     0
KeepAliveTimeouts     6
KeepAliveTimeout      30 seconds

SessionCreationInfo:
------------------------
Active Sessions           0
Keep-Alive Sessions       6
Total Sessions Created    8/129

CacheInfo:
-----------------------
File Cache Enabled       yes
File Cache Entries       14/1024
File Cache Hit Ratio     76/108 ( 70,37%)
Maximum Age              30
Accelerator Entries      0/1024
Acceleratable Requests   18/45 ( 40,00%)
Acceleratable Responses  0/18 (  0,00%)
Accelerator Hit Ratio    0/0 (  0,00%)

Native pools:
----------------------------
NativePool:
Idle/Peak/Limit               1/1/128
Work Queue Length/Peak/Limit  0/0/0

DNSCacheInfo:
------------------
enabled             yes
CacheEntries        0/1024
HitRatio            0/0 (  0,00%)

Async DNS disabled

Performance Counters:
------------------------------------------------
                           Average         Total      Percent

Total number of requests:                     20
Request processing time:    0,0395        0,7899

default-bucket (Default bucket)
Number of Requests:                           20    (100,00%)
Number of Invocations:                       289    (100,00%)
Latency:                    0,0050        0,0999    ( 12,65%)
Function Processing Time:   0,0345        0,6899    ( 87,35%)
Total Response Time:        0,0395        0,7899    (100,00%)

Sessions:
-------------------------------------------------------
Process  Status  Client  Age  VS  Method  URI  Function

Resultan muy interesantes para detectar problemas y optimizar el rendimiento la sección “ConnectionQueue:” y “Sessions:“, en esta última es donde veremos las Ips de acceso, peticiones, URI, etc. Toda la información es bastante descriptiva y comprensible a primera vista. A partir de esta información se pueden generar scripts de recolección de datos, añadir a monitorización tipo Nagios o BigBrother, etc. Los que utilicéis servidores anteriores a la versión 7.0 habréis detectado un gran cambio de la cantidad de información del antiguo perfdump al nuevo.

Hace unos días comentaba el paso de System V a Upstart en RHEL y Centos 6. Hoy vamos a hablar sobre Solaris y el cambio introducido a partir de Solaris 9 para la gestión de servicios.

Antes de Solaris 9 los servicios se gestionaban como en la mayoría de sistemas Unix y Linux (legacy), teníamos scripts de arranque en /etc/init.d y se creaban enlaces simbólicos contra ellos en los distintos runlevels (directorios RC) para su arranque/parada. A partir de Solaris 9 se introdujo SMF (Service Management Facility) y se ha convertido en la manera por defecto de gestionar los servicios en Solaris 10.

Los beneficios de SMF sobre el método anterior son sustanciales. Entre ellos la posibilidad de mantener monitorizados los servicios para que en el momento que se produzca una caída levanten de forma instantánea, la gestión inteligente de arranque mediante la cual el servicio tiene unas dependencias y hasta que no estén activas el servicio no está disponible, el arranque en paralelo y de forma asíncrona, etc.

Los comandos básicos para gestion de servicios en SMF son svcs, svccfg y svcadm. Mediante svcs a secas podemos ver el estado de los servicios del sistema (incluidos los del sistema antiguo legacy), a través de distintos parámetros podemos filtrar únicamente los deshabilitados, etc:

# svcs
STATE          STIME    FMRI
legacy_run      9:04:48 lrc:/etc/rc2_d/S20sysetup
legacy_run      9:04:48 lrc:/etc/rc2_d/S47pppd
legacy_run      9:04:49 lrc:/etc/rc2_d/S72autoinstall
legacy_run      9:04:49 lrc:/etc/rc2_d/S73cachefs_daemon
legacy_run      9:04:49 lrc:/etc/rc2_d/S81dodatadm_udaplt
legacy_run      9:04:49 lrc:/etc/rc2_d/S89PRESERVE
disabled        9:02:34 svc:/platform/i86pc/acpihpd:default
online          9:01:28 svc:/system/svc/restarter:default
online          9:01:35 svc:/system/early-manifest-import:default
online          9:01:38 svc:/network/netcfg:default
online          9:01:39 svc:/network/datalink-management:default
online          9:01:39 svc:/network/socket-config:default
...
...

Básicamente vemos el estado del proceso, la última vez que el servicio cambió de estado y su FMRI (Fault Management Resource Identifier). El FMRI es el identificador del servicio. El FMRI se divide en tres partes separadas por “:”. La primera el esquema (svc o lrc según el tipo de servicio), la categoría en la que se encuentra (network, system…) y el nombre del servicio, y finalmente la instancia.

Podemos ver también con detalle el estado de un único servicio con el parámetro “-x” y sus dependencias con “-d”:

# svcs -x  svc:/system/cron:default
svc:/system/cron:default (clock daemon (cron))
 State: online since  1 de noviembre de 2011 09:02:51 WET
   See: cron(1M)
   See: crontab(1)
   See: /var/svc/log/system-cron:default.log
Impact: None.

# svcs -d svc:/system/cron:default
STATE          STIME    FMRI
online          9:02:35 svc:/milestone/name-services:default
online          9:02:49 svc:/system/filesystem/local:default

Podemos verificar rápidamente cómo SMF monitoriza activamente los servicios que están bajo su control, vamos a ver el estado del servicio cron, matarlo con una señal kill y verificar que al momento SMF lo ha levantado de nuevo:

# date
martes  1 de noviembre de 2011 09:46:24 WET
# svcs -v system/cron
STATE          NSTATE        STIME    CTID   FMRI
online         -              9:02:51     62 svc:/system/cron:default
# ps -ef | grep cron
    root   441     1   0 09:02:51 ?           0:00 /usr/sbin/cron
    root   841   687   0 09:46:33 pts/1       0:00 grep cron
# kill 441
# svcs -v system/cron
STATE          NSTATE        STIME    CTID   FMRI
online         -              9:46:38     96 svc:/system/cron:default

A través de svcs también podemos ver el estado de un servicio y diagnosticarlo cuando no es satisfactorio. Encontraremos los siguientes estados: online, offline, disabled, degraded, maintenance y legacy-run. Los cuatro primeros estados están claros, online, offline, deshabilitado y degradado. Cuando un servicio está en estado maintenance es debido a que hay algún problema con el servicio y no puede ser arrancado. Como requiere nuestra intervención se pone a nuestra disposición la ruta hacia el log del servicio para verificar el origen del problema. El estado legacy-run simplemente indica que se trata de un servicio legacy.

Mediante svcadm podemos gestionar el estado de cada uno de los servicios, con los parámetros “enable”, “disable”, “refresh”, “clear”, “mark” y “restart”. Aparte de los obvios, conviene comentar que “refresh” sirve para leer de nuevo los ficheros de configuración del servicio por si se ha realizado algún cambio, “clear” sirve para resetear el servicio si se encuentra en estado de mantenimiento y “mark” para marcar un servicio como degradado, mantenimiento, etc.

Para que veáis un ejemplo de fichero xml básico para un servicio aquí tenéis uno para la gestión de Oracle iPlanet webserver 7 que instalamos hace unos días. Básicamente hemos establecido como dependencias los servicios de red, los sistemas de ficheros locales y el arranque bajo el milestone multi-user (lo que viene siendo el runlevel 3 en legacy). Después establecemos los tres comandos para el arranque, parada y reinicio del servicio:

<?xml version='1.0'?>

<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>

<service_bundle type='manifest' name='webserver7'>

<service name='network/webserver7' type='service' version='0'>
<create_default_instance enabled='true'/>
<single_instance/>
<dependency name='fs' grouping='require_all' restart_on='none' type='service'>
<service_fmri value='svc:/system/filesystem/local'/>
</dependency>
<dependency name='net' grouping='require_all' restart_on='none' type='service'>
<service_fmri value='svc:/network/physical'/>
</dependency>
<dependent name='webserver7_multi-user' restart_on='none' grouping='optional_all'>
<service_fmri value='svc:/milestone/multi-user'/>
</dependent>
<exec_method name='start' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 start"' timeout_seconds='60'>
<method_context/>
</exec_method>
<exec_method name='stop' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 stop"' timeout_seconds='60'>
<method_context/>
</exec_method>
<exec_method name='restart' type='method' exec='su www -c "/opt/webserver7/bin/webserver7 restart"' timeout_seconds='60'>
<method_context/>
</exec_method>
</service>

</service_bundle>

Para importar un servicio creado de este modo ejecutamos el siguiente comando:

# svccfg import webserver7.xml

Como siempre os recomiendo revisar las páginas man de todos estos comandos para recibir información detallada sobre cada uno de ellos, esto es una pequeña introducción que podría extenderse mucho más si entráramos en detalle de cada una de las características y posibilidades de SMF. Ahí van unas cuantas referencias para aprender más sobre Service Management Facility:

• Using Solaris SMF (O’Reilly)
• Universidad de Princeton, Service Management Facility
• OpenSolaris SMF FAQ

En el artículo anterior veíamos cómo activar PHP en Oracle iPlanet Web Server bajo Solaris. Una vez activado a la hora de verificar el funcionamiento de un script PHP podéis encontrar lo siguiente al acceder vía URL:

Stub Start Error
This server has encountered an internal error which prevents it from fulfilling your request. The most likely cause is a misconfiguration. Please ask the administrator to look for messages in the server’s error log.

Y al revisar los logs de error de la instancia vemos lo siguiente:

[12/Oct/2011:10:13:28] failure ( 1023): for host 192.168.1.128 trying to GET /test.php, responder-fastcgi reports: FCGI1058: Process creation failure
[12/Oct/2011:10:13:43] failure ( 1023): for host 192.168.1.128 trying to GET /test.php, responder-fastcgi reports: FCGI1058: Process creation failure

El servidor web no es capaz de lanzar los procesos fastcgi de php, esto lo podemos ver porque ni siquiera se crea el log de fastcgi (Fastcgistub.log). Según he visto en este post de un foro es un problema común en máquinas con poca memoria swap configurada. En mi caso estaba claro porque esta prueba estaba siendo realizada sobre una pequeña máquina virtual. La solución es tan simple como aumentar el tamaño del area de intercambio o añadir más. Si no os apetece tocar la swap actual porque está en uso podéis añadir una nueva con zfs:

# zfs create -V 1G rpool/swap-extra
# swap -a /dev/zvol/dsk/rpool/swap-extra
# swap -l
swapfile             dev    swaplo   blocks     free
/dev/zvol/dsk/rpool/swap 171,2         8  1048568  1048568
/dev/zvol/dsk/rpool/swap-extra 171,3         8   819192   819192

Una vez activada la nueva swap los procesos FastCGI deberían arrancar sin problemas y ejecutar los PHP sin errores.

A través del sitio web de soporte de Oracle (https://support.oracle.com) podemos descargar el patch de PHP 5.2.X disponible para la versión de Oracle iPlanet Web Server que tengamos instalada, en este caso para la 7.0.12. sobre Solaris. Este parche nos va a permitir activar PHP con FastCGI a modo de plugin del web server.

Una vez bajado el patch (p12680045_10000_Generic.zip en mi caso), procedemos a descomprimirlo y copiar la carpeta “php” resultante al directorio plugins en la ruta donde hayamos instalado el servidor web:

# cp -Rp /var/tmp/php /opt/iplanet-webserver7/plugins/

Exportamos la variable LD_LIBRARY_PATH con la ruta hacia este directorio:

# export LD_LIBRARY_PATH=/opt/iplanet-webserver7/plugins/php

Ahora, podemos hacer una verificación de que php funciona desde línea de comandos:

# cd /opt/iplanet-webserver7/plugins/php/bin && ./php -v
PHP 5.2.X (cgi-fcgi) (built: Jan XX XXXX 22:31:04)
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2011 Zend Technologies

Llegado este punto, únicamente tendríamos que activar php para la instancia en la que queramos usarlo, en este caso en la instancia https-website. Para ello haremos uso del script setupPHP disponible en el directorio “php”:

# cd /opt/webserver7/plugins/php/
# ./setupPHP -instancename=https-website

UPDATED: /opt/iplanet-webserver7/https-www/config/magnus.conf
UPDATED: /opt/iplanet-webserver7/https-www/config/obj.conf
UPDATED: /opt/iplanet-webserver7/https-www/config/mime.types

Como veis en la salida del comando, automáticamente se han actualizado los ficheros de configuración de la instancia, añadiendo los handler de php, las configuraciones y directivas de FastCGI, etc.

Si utilizáis un usuario distinto de root para correr el servidor web, aseguraos de que los propietarios de los tres ficheros anteriores se mantienen bien, sino no arrancará la instancia.

Ya solo quedaría hacer el pull-config con los nuevos cambios de configuración de la instancia y el deploy. Podemos hacerlo a través de la interfaz web de administración de iPlanet Web Server o desde línea de comandos con wadm:

# /opt/iplanet-webserver7/bin/wadm [--user=admin-user] [--password-file=admin-pswd-file] [--host=admin-host] [--port=admin-port]
pull-config --config=www nodo
pull-config --config=website hostname
deploy-config website

La administración de discos y sistemas de ficheros zfs en Solaris (y en BSD) es algo distinta a lo que estamos acostumbrados para otros entornos Unix y GNU/Linux (ext3, ext4…). Zfs es un sistema de ficheros de 128-bit con una gran escalabilidad, estabilidad, transaccional y con una especial seguridad en la integridad de los datos. Pero no vamos a entrar en estos detalles sino en cómo gestionar este sistema.

Los dos comandos que debemos conocer para trabajar con sistemas de ficheros zfs son zpool y zfs. zpool es la primera capa de abstracción, crea pools de discos que pueden gestionar a su vez X sistemas de ficheros. A posteriori, se pueden añadir más discos al pool y automáticamente los sistemas de ficheros reciben este espacio sin gestión extra, algo excepcional para la escalabilidad.

Vamos a añadir un pool de prueba con un disco extra que tenemos en nuestro sistema. Podemos ver los discos físicos con el comando iostat -En:

# iostat -En
c7d0             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VBOX HARDDISK   Revision:  Serial No: VB5d392fb1-ed1f Size: 7,13GB
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c7d1             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VBOX HARDDISK   Revision:  Serial No: VBf793d417-2c8e Size: 1,07GB
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c8d1             Soft Errors: 0 Hard Errors: 0 Transport Errors: 0
Model: VBOX HARDDISK   Revision:  Serial No: VBf3c2659f-ea9c Size: 1,07GB
Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0
Illegal Request: 0
c8t0d0           Soft Errors: 0 Hard Errors: 6 Transport Errors: 0
Vendor: VBOX     Product: CD-ROM           Revision: 1.0  Serial No:
Size: 0,00GB
Media Error: 0 Device Not Ready: 6 No Device: 0 Recoverable: 0
Illegal Request: 0 Predictive Failure Analysis: 0

El disco c7d0 es el que engloba el sistema y su propio pool (rpool), así que creamos de momento un nuevo pool llamado rpool2 con el disco c7d1:

# zpool rpool2 c7d1

Una vez realizado, automáticamente el pool se crea y es visible con un df -h, englobando todo el espacio del disco, se monta sólo:

# df -h /rpool2
Filesystem            Size  Used Avail Use% Mounted on
rpool2                976M   31K  976M   1% /rpool2

Ahora podemos comenzar a crear sistemas de ficheros dentro del pool con el comando zfs, creamos el sistema de ficheros /rpool2/test, que se monta de forma automática:

# zfs create rpool2/test
# df -h | grep rpool2
rpool2                976M   32K  976M   1% /rpool2
rpool2/test           976M   31K  976M   1% /rpool2/test

Lo interesante de esto es que una vez establecidos los pool, en caso de necesitar agregar más espacio a alguno de ellos, es tan sencillo como agregar nuevos discos al pool, automáticamente el espacio se asignará a los sistemas de ficheros que contiene. Yo tengo otro disco c8d1 así que lo voy a agregar para aumentar al doble el espacio del pool y sus sistemas de ficheros. Usaremos el comando zpool add seguido del pool y los discos a añadir:

# zpool add rpool2 c8d1

Y ya está, nuestro pool ha aumentado al doble su capacidad sin mayor gestión:

# df -h | grep rpool2
rpool2                2,0G   32K  2,0G   1% /rpool2
rpool2/test           2,0G   31K  2,0G   1% /rpool2/test

Si queremos tener una visión global de los pool en el sistema utilizamos el comando zpool list:

# zpool list
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool   6,56G  2,93G  3,63G    44%  1.00x  ONLINE  -
rpool2  1,97G   132K  1,97G     0%  1.00x  ONLINE  -

Por supuesto, no tenemos porque dejar que todos los sistemas de ficheros dispongan de todo el espacio del pool, podemos limitarlo estableciendo quotas:

# zfs set quota=200M rpool2/test

# df -h | grep test
rpool2/test           200M   31K  200M   1% /rpool2/test

Podría decirse que esto es lo más básico, la conclusión que podemos sacar es que, es una forma distinta de trabajar los discos y sistemas de ficheros, pero una vez acostumbrados es bastante más sencilla y práctica que los sistemas de ficheros tradicionales. Podemos seguir investigando las opciones de zpool y zfs con sus páginas man. Encontraremos otras utilidades de gran importancia, por ejemplo la posibilidad de visualizar el estado de IO en los pools:

# zpool  iostat rpool2
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
rpool2       132K  1,97G      0      2  1,69K  14,6K

Os invito a investigar un poco, es un sistema lleno de posibilidades y realmente interesante, deduplicación, compresión, snapshots…

ZFS (sistema de archivos desarrollado por Sun Microsystems para Solaris) permite realizar snapshots del sistema de ficheros de forma instantanea a través del comando zfs snapshot. Básicamente, un snapshot es una copia exacta del sistema de ficheros que posteriormente podemos utilizar para clonar, restaurar, guardar a modo de copia antes de la realización de cambios críticos en el sistema, etc. Lo que no podemos hacer es manipularlos, los snapshots son copias de sólo lectura.

Los snapshot se almacenan en el propio disco, por lo que su utilización supone la utilización de espacio extra y no sirven como backup en caso de desastre. Inicialmente no ocupan espacio extra, pero sí lo hacen conforme la información del sistema de ficheros cambia respecto al snapshot.

Crear, destruir y renombrar un snapshot

La sintaxis básica para la creación de un snapshot es la siguiente:

# zfs snapshot sistema_de_ficheros@nombre_snapshot

Por ejemplo, para crear un snapshot de “rpool/ROOT/solaris” con nombre la fecha de hoy:

# zfs snapshot rpool/ROOT/solaris@`date +%d%m%Y`

Para eliminar el snapshot usamos el comando zfs destroy:

# zfs destroy rpool/ROOT/solaris@04102011

Y para renombrarlo:

# zfs rename rpool/ROOT/solaris@04102011 rpool/ROOT/solaris@nuevo-snap

Listar snapshots disponibles

# zfs list -t snapshot
NAME                          USED  AVAIL  REFER  MOUNTPOINT
rpool/ROOT/solaris@install   22,5M      -  2,04G  -
rpool/ROOT/solaris@04102011    37K      -  2,44G  -

Con el comando zfs list -t snapshot podemos ver un listado de todos los snapshot disponibles, los snapshots se almacenan en el directorio oculto .zfs de la ruta base donde está montado el sistema de ficheros, en el caso de los anteriores /.zfs/snapshot. De esta forma podríamos restaurar ficheros concretos del snapshot en lugar de todo:

# ls -l /.zfs/snapshot
total 5
drwxr-xr-x 24 root root 25 2011-10-03 21:17 04102011
drwxr-xr-x 24 root root 25 2011-10-03 21:17 10042011
drwxr-xr-x 24 root root 26 2011-09-22 18:42 install

También conviene revisar el espacio en disco utilizado, el comando zfs list -o space nos mostrará con detalle el espacio utilizado a nivel general, por los snapshot, subsistemas de ficheros (child), etc:

# zfs list -o space
NAME                    AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                   3,19G  3,27G         0   92,5K              0      3,27G
rpool/ROOT              3,19G  2,46G         0     31K              0      2,46G
rpool/ROOT/solaris      3,19G  2,46G     22,5M   2,44G              0          0
rpool/dump              3,19G   256M         0    256M              0          0
rpool/export            3,19G  26,2M         0     32K              0      26,2M
rpool/export/home       3,19G  26,2M         0     32K              0      26,2M
rpool/export/home/alex  3,19G  26,2M       20K   26,2M              0          0
rpool/swap              3,54G   544M         0    181M           364M          0

Restaurar un snapshot

Hacer un rollback o restaurar un snapshot es tan sencillo como utilizar el comando zfs rollback seguido del snapshot a restaurar. Lo que hay que tener claro son las consecuencias de restaurar un snapshot antiguo, ya que restauremos el sistema de ficheros tal y como se encontraba en el momento del snapshot.

Algo a tener en cuenta, es que únicamente podemos restaurar el snapshot más reciente. Si tuvieramos varios y quisieramos hacer rollback de uno antiguo, antes habría que eliminar los más recientes. Recibiríamos este error:

# zfs rollback rpool/ROOT/solaris@10042011
cannot rollback to 'rpool/ROOT/solaris@10042011': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
rpool/ROOT/solaris@04102011

Así que eliminaríamos el reciente y ya podríamos hacerlo, también podríamos forzar con el parámetro -r a que se eliminan automáticamente:

# zfs destroy rpool/ROOT/solaris@04102011
# zfs rollback rpool/ROOT/solaris@10042011

# zfs rollback -r rpool/ROOT/solaris@10042011

Lo reconozco, soy novato con Solaris y todavía estoy aprendiendo sus peculiaridades más allá de lo común con cualquier sistema Unix. En este caso, el primer problema que tuve fue a la hora de desactivar el dhcp y activar la posibilidad de utilizar IPs estáticas.

Hiciera lo que hiciera con el comando ipadm (sustituto de ifconfig) no me dejaba desactivar en la interfaz de red el DHCP. Tras un rato trasteando y buscando en google encontré una opción que permite desactivar nwam (NetWork Auto Magic, que configura la red de forma automática), el responsable de esta asignación dinámica y activar la opción ‘por defecto’ para la configuración de las interfaces.

Ante todo desconozco (de momento) si esta es la solución más óptima para hacerlo, pero desde luego es rápida y efectiva. Únicamente son dos pasos:

# pfexec svcadm enable physical:default
# pfexec svcadm disable physical:nwam

Con svcadm activamos la opción default y desactivamos nwam. pfexec es algo así como el sudo de Solaris, ya hablaremos de él más adelante. Una vez realizado esto, ya podéis configurar ips estáticas en Oracle Solaris 11 con ipadm.

Sigo explorando el sistema Oracle Solaris Express, tras su instalación y configuración de la red vamos a ver la utilización del gestor/repositorio de paquetes que incorpora, pkg.

La filosofía es similar al apt en Debian o yum en RHEL, así que vamos a ver unos cuantos ejemplos de instalación, eliminación, actualización de paquetes, etc.

Buscar un paquete

La sintaxis a utilizar es la siguiente:

# pkg search <paquete>

Si por ejemplo quisiéramos buscar el servidor web Lighttpd podríamos buscar las versiones disponibles así:

# pkg search lighttpd
INDEX ACTION VALUE PACKAGE
description set Lighttpd Web Server pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
pkg.description set The Lighttpd Web Server (1.4.23) pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
pkg.summary set Lighttpd Web Server pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename dir etc/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename dir usr/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename dir var/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename file etc/security/auth_attr.d/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename file etc/security/prof_attr.d/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
basename file usr/lighttpd/1.4/sbin/lighttpd pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
pkg.fmri set solaris/web/server/lighttpd pkg:/web/server/lighttpd@1.4.23-0.134

También podemos buscar en un repositorio determinado con el parámetro -s:

# pkg search -s http://pkg.repo.com/ lighttpd

O utilizar las cláusula AND y OR para encadenar consultas y/o utilizar comodines:

# pkg search lighttpd AND htt*d OR apache

Ver la información de un paquete

Para ver toda la información de un paquete usaremos el parámetro info seguido del paquete a consultar:

# pkg info pkg://solaris/web/server/lighttpd-14@1.4.23-0.151.0.1
          Name: web/server/lighttpd-14
       Summary: Lighttpd Web Server
   Description: The Lighttpd Web Server (1.4.23)
      Category: Web Services/Application and Web Servers
         State: Not installed
     Publisher: solaris
       Version: 1.4.23
 Build Release: 5.11
        Branch: 0.151.0.1
Packaging Date:  5 de noviembre de 2010 06:22:12
          Size: 794.78 kB
          FMRI: pkg://solaris/web/server/lighttpd-14@1.4.23,5.11-0.151.0.1:20101105T062212Z

Instalación de un paquete

La instalación es sencilla, como en cualquier gestor de paquetes:

# pkg install <paquete>

Vamos a instalar una de las versiones de lighttpd encontradas antes:

# pkg install pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
Packages to install: 2
Create boot environment: No
Services to restart: 1
DOWNLOAD PKGS FILES XFER (MB)
Completed 2/2 52/52 4.5/4.5

PHASE ACTIONS
Install Phase 143/143

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

Como véis, a la hora de instalar un paquete se puede especificar la versión exacta a instalar de todas las disponibles, y también el “publisher” del cual la queremos instalar. Si quisieramos instalarla desde otro repositorio/publisher lo especificaríamos del siguiente modo, donde repo-mirror.com es el publisher.:

# pkg install pkg://repo-mirror.com/test/paquete-solaris

Simular la instalación de un paquete

Pasando los parámetros -nv a install podemos ver lo que se instalaría en el sistema sin necesidad de hacerlo:

# pkg install -nv <paquete>

# pkg install -nv pkg:/system/management/webmin@1.510-0.151.0.1
               Packages to install:     1
           Create boot environment:    No
               Services to restart:     1
              Rebuild boot archive:    No
Changed fmris:
  None -> pkg://solaris/system/management/webmin@1.510,5.11-0.151.0.1:20101105T061636Z
Services:
  restart_fmri: svc:/system/manifest-import:default

Actualizar un paquete

A la hora de actualizar un paquete se puede usar tanto la orden install como update:

# pkg update <paquete>
# pkg install <paquete>

Verificar la instalación de un paquete

Una vez realizada una instalación podemos verificar si todo se ha realizado de forma correcta, si el paquete se ha instalado bien, busqueda de errores, etc. Para ello utilizamos el parámetro verify. Con el parámetro -v vemos toda la información y con -q únicamente los errores:

# pkg verify -v pkg:/web/server/lighttpd-14@1.4.23-0.151.0.1
Verifying: PACKAGE                                             STATUS
pkg://solaris/web/server/lighttpd-14                    OK

Arreglar fallos en paquetes instalados

En caso de haber recibido algún error en el punto mencionado anteriormente (verify), podemos tratar de arreglarlo mediante la siguiente orden:

pkg fix --accept <paquete>

Desinstalar un paquete

Muy sencillo:

pkg uninstall <paquete>

Vamos a desinstalar el servidor web lighttpd instalado anteriormente:

# pkg uninstall pkg://solaris/web/server/lighttpd-14@1.4.23-0.151.
                Packages to remove:     1
           Create boot environment:    No
               Services to restart:     1
PHASE                                        ACTIONS
Removal Phase                                  1/104
Warning - directory //var/lighttpd/1.4/logs not empty or not expected during operation - contents preserved in /var/pkg/lost+found/var/lighttpd/1.4/logs-20110925T204323Z

Warning - directory //var/lighttpd/1.4/docroot not empty or not expected during operation - contents preserved in /var/pkg/lost+found/var/lighttpd/1.4/docroot-20110925T204323Z
Removal Phase                                104/104

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

Ver el contenido de un paquete

Siempre es útil conocer el contenido del paquete a instalar para saber con exactitud que es lo que vamos a instalar en nuestro sistema y donde. Si queremos, podemos especificar que nos indique el path, el tamaño de cada fichero, etc:

# pkg contents -r -o pkg.size,path pkg://solaris/web/server/lighttpd-14@1.4.23-0.151.0.1
PKG.SIZE PATH
  1503
    1503
         etc
         etc/lighttpd
         etc/lighttpd/1.4
         etc/lighttpd/1.4/conf.d
    1934 etc/lighttpd/1.4/conf.d/fcgi-php.conf
    1105 etc/lighttpd/1.4/conf.d/ssl.conf
   11497 etc/lighttpd/1.4/lighttpd.conf
         etc/security
....
....
....
   11696 usr/lighttpd/1.4/lib/mod_extforward.so

Visualizar el historial de acciones realizadas con pkg

Podemos ver un registro de las acciones realizadas:

# pkg history
TIME                OPERATION                 CLIENT          OUTCOME
2010-11-05T16:14:56 purge-history             pkg             Succeeded
2011-09-22T18:41:16 uninstall                 pkg             Succeeded
2011-09-22T18:41:37 uninstall                 pkg             Succeeded
2011-09-22T18:41:53 set-property              pkg             Succeeded
2011-09-22T18:42:03 set-property              pkg             Succeeded
2011-09-25T10:21:01 uninstall                 pkg             Succeeded
2011-09-25T17:05:22 refresh-publishers        pkg             Succeeded
2011-09-25T17:05:22 install                   pkg             Failed (Bad Request)
2011-09-25T17:12:25 refresh-publishers        pkg             Succeeded

Y para eliminar este registro:

# pkg purge-history

Espero que os haya sido de utilidad esta guía de iniciación a pkg en Oracle Solaris, seguiré profundizando en los secretos de este sistema en próximos artículos.