Monitorizar Servicios Solaris 10 Nagios - Parte 1

IntroducciónUna de las cosas que más echo en falta en la versión actual de SMF sobre Solaris 10u8 es poder Monitorizar los estados de los servicios. La verdad es que se habla mucho de poder utilizar SNMP para hacer consultas a los estados, pero, a día de hoy no está implementado.

Para solucionar este problema -hasta que implementen SNMP- podemos utilizar diferentes scripts que nos proporcionaran la funcionalidad de monitorización necesaria.

En este primer acercamiento vamos a utilizar una versión modificada de un PlugIn para Nagios que nos permitirá saber el estado de un servicio, su uso es el siguiente:check_svc <service name>Este sencillo plugin nos devuelve OK si el servicio está online, WARNING si está en online* y CRITICAL si está en maintance.  Si el servicio está OFFLINE, entonces devuelve UNKNOW, veamos un ejemplo sencillo:# ./check_svc tomcat_6:default_64bitsOK tomcat_6:default_64bits is online# echo $?0# ./check_svc tomcat_6:default_32bitsUNKNOWN tomcat_6:default_32bits is disabled# echo $?3Este plugin tiene como ventaja que es realmente rápido, sin embargo, tiene deficiencias ya que no podemos establecer cuando un estado de disabled es un WARNING o CRITICAL, siempre nos devuelve UNKNOWN. Además, para hacer que sea rápido he tenido que hacer algunos cambios en el código original. Aquí os dejo una versión de verificación de Solaris SMF para Nagios modificada

Para verificaciones más complejas tenemos otra versión -también en Nagios Exchange- llamada check_solaris_smf que nos permite parametrizar el nivel de CRITICAL, WARNING y OK de la siguiente forma:check_solaris_smf -f <frmi> -c <critical> -w <warning> -o <ok>Por ejemplo, si queremos evaluar el servicio tomcat_6:default_64bits y los valores són: CRITICAL si está disabled u offline, WARNING si está en maintance o degraded y OK si está en online. Para ello utilizaremos el siguiente comando:# ./check_solaris_smf -f tomcat_6:default_64bits -c DIS,OFF -w MNT,DGD -o ONSMF SVCS OK - tomcat_6:default_64bits ON# echo $?0Cuál Utilizo?La verdad es que depende un poco de las necesidades, pero la mayor potencia del script check_solaris_smf hace que sea más lento. Aquí os dejo los tiempos de ambos scripts al ejecutar la misma comprobación:# time ./check_solaris_smf -f tomcat_6:default_64bits -c DIS,OFF -w MNT,DGD -o ONSMF SVCS OK - tomcat_6:default_64bits ON

real    0m0.184suser    0m0.046ssys     0m0.095s# time ./check_svc tomcat_6:default_64bitsOK tomcat_6:default_64bits is online

real    0m0.084suser    0m0.021ssys     0m0.039sConclusiónEn esta primera parte, hemos visto cómo podemos crear -utilizar- unos pequeños scripts que nos van a permitir ver el estado de los servicios, y devolvernos un nivel para la monitorización con Nagios.

El principal problema que tienen, es que asumen que los servicios que vamos a monitorizar se encuentran en la misma máquina donde tenemos instalado nuestro Nagios y eso -normalmente- no es así.

Monitorizar Servicios Solaris 10 Nagios - Parte 2

IntroducciónEn la primera parte de Monitorización de Servicios SMF de Solaris 10, vimos cómo podemos utilizar algunos scipts para ver el estado de nuestros servicios bajo Solaris SMF. En esta ocasión, vamos a ver cómo configurar nuestro Nagios para que remotamente acceda a la información y nos muestres las alertas que nosotros configuremos.

Antes de comenzar, vamos a explicar la arquitectura y, de esta forma, hacer más claro el proceso. En primer lugar tenemos una máquina donde se está ejecutando nuestro servicio Nagios <nagios-server> y, por otro lado tenemos una máquina <zion> en la cual está instalado Tomcat6 como Servicio SMF en Solaris 10.

Lo primero que vamos a hacer es crear el usuario <svcmon> en la máquina que queremos monitorizar -zion-, y vamos a generar sus claves ssh para permitir el acceso sin contraseña. Así mismo, vamos a limitar el número de procesos que puede crear el usuario y pondremos una password aleatoria -ya que sólo nos conectaremos con la máquina de Nagios a través de SSH-root@zion # groupadd svcmonroot@zion # useradd -s /bin/bash -g svcmon -d /export/home/svcmon -m svcmon64 blocksroot@zion # passwd svcmonNueva contraseña:Vuelva a escribir la nueva contraseña:passwd: la contraseña se ha cambiado para svcmon satisfactoriamenteroot@zion # projadd -c 'Solaris SMF Monitor' user.svcmonroot@zion # projmod -sK 'task.max-lwps=(priv,10,deny)' user.svcmonroot@zion # su - svcmonSun Microsystems Inc.   SunOS 5.10      Generic January 2005svcmon@zion:~ > mkdir scriptssvcmon@zion:~ > cd scripts/svcmon@zion:~/scripts > /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/solaris-smf-nagios/check_svcsvcmon@zion:~/scripts > chmod +x check_svcsvcmon@zion:~/scripts > ./check_svcUSAGE: ./check_svc svcmon@zion:~/scripts > ./check_svc tomcat_6:default_64bitsOK tomcat_6:default_64bits is onlinesvcmon@zion:~/scripts > cdsvcmon@zion:~ > ssh-keygen -t rsa -C 'Solaris SVC Monitor User' -b 2048Generando pareja de claves pública/privada rsa.Escriba el archivo en el que se debe guardar la clave (/export/home/svcmon/.ssh/id_rsa):Escriba una frase de contraseña (si está vacío se interpreta que no hay ninguna frase de contraseña):Escriba la misma frase de contraseña de nuevo:Se ha guardado su identificación en /export/home/svcmon/.ssh/id_rsa.Se ha guardado su clave pública en /export/home/svcmon/.ssh/id_rsa.pub.La huella de la clave es:32:ef:25:68:8f:47:8a:88:18:35:63:43:02:ed:e4:c4 Solaris SVC Monitor UserAhora en nuestra máquina Nagios vamos a generar las claves RSA de SSH para que podamos conectarnos sin utilizar la contraseña. Para ello, debemos logearnos con el usuario que está corriendo el nagios <NagiosUser> y ejecutar <ssh-keygen>. En nuestro ejemplo, el usuario es <nagios>nagios@nagios-server:~> ssh-keygen -t rsa -b 2048 -C 'Nagios User'Generating public/private rsa key pair.Enter file in which to save the key (/home/nagios/.ssh/id_rsa):Created directory '/home/nagios/.ssh'.Enter passphrase (empty for no passphrase):

Enter same passphrase again:Your identification has been saved in /home/nagios/.ssh/id_rsa.Your public key has been saved in /home/nagios/.ssh/id_rsa.pub.The key fingerprint is:5d:c1:d5:49:c2:a5:28:c0:d4:22:82:61:a5:c8:d0:9f Nagios User

Ahora que ya tenemos generadas las claves ssh, vamos a copiar el contenido del archivo $HOME/.ssh/id_rsa.pub -es decir la clave pública- al host que queremos permitir el acceso sin contraseña -en nuestro caso Zion- y copiarla en el archivo $HOME/.ssh/authorized_keys, vamos a verlo

En el servidor Nagiosnagios@nagios-server:~> cat .ssh/id_rsa.pubssh-rsa ... bi7MMuhhNmQAgIyP9lWFS14UzKOgtIw== Nagios User

En el host a monitorizarsvcmon@zion:~ > cd ~/.ssh/svcmon@zion:~/.ssh > vi authorized_keys   ssh-rsa ... bi7MMuhhNmQAgIyP9lWFS14UzKOgtIw== Nagios User

:wqY comprobamos que podemos acceder sin password desde <nagios-server> a <zion>nagios@nagios-server:~> ssh svcmon@zionThe authenticity of host '10.55.21.31 (10.55.21.31)' can't be established.RSA key fingerprint is 93:18:d8:86:6b:56:d1:90:bc:5b:f7:1c:73:72:df:b7.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added '10.55.21.31' (RSA) to the list of known hosts.Last login: Wed Mar 31 12:02:00 2010 from logosSun Microsystems Inc.   SunOS 5.10      Generic January 2005svcmon@zion $ exitlogoutConnection to 10.55.21.31 closed.Instalación del PlugIn en NagiosAhora que ya tenemos preparada nuestra estructura de usuarios, vamos dar de alta el servicio en nuestro servidor nagios. Para ello, he creado una versión modificada que nos permite hacer un check remotamente de un servicio SMF de Solaris 10 y la deberemos copiar en <$NAGIOS_HOME/libexec>. Su funcionamiento es el siguientecheck_svc_remote <service_name> <hostname> [username]

Para ello, descargamos el archivo con <wget> y, si por algún motivo el script <check_svc> de la máquina a monitorizar, no se encuentra en <HOME/scripts/check_svc>  deberemos editar la variable <REMOTE_SVC>nagios@nagios-server:/usr/local/nagios/libexec> wget http://blog.sfchildren.com/blogger/solaris-smf-nagios/check_svc_remote

nagios@nagios-server:/usr/local/nagios/libexec> ./check_svc_remoteUsage: ./check_svc_remote {service_name} {hostname} [username]

        For example to test NTP Service try

                $ ./check_svc_remote svc:/network/ntp:default test.sfchildren.com                CRITICAL svc:/network/ntp:default is disabled

        If you want, you can send SSH Banner (FD 2) to /dev/null, i.e.

                $ ./check_svc_remote svc:/network/ntp:default test.sfchildren.com 2>/dev/null                CRITICAL svc:/network/ntp:default is disabled

        For more documentation, please go to                http://sparcki.blogspot.com/2010/03/monitorizar-servicios-solaris-10-nagios.html

nagios@nagios-server:/usr/local/nagios/libexec> ./check_svc_remote ntp zionOK ntp is onlinenagios@nagios-server:/usr/local/nagios/libexec> ./check_svc_remote ntp logosCRITICAL ntp is disabledConclusiónAunque es un proceso un poco tedioso -sobre todo cuando instalamos por primera vez la máquina- luego resulta de gran utilidad. Esta versión es un ejemplo de lo que podemos conseguir con nagios ya que, podemos ampliar las funcionalidades, por ejemplo, si el servicio está en OFFLINE podemos decirle a nagios que haga un restart del servicio -para ello, debemos darle permisos mediante un rol al usuario <svcmon>-

Monitorizar Servicios Solaris 10 Nagios - Parte 3

IntroducciónDurante esta serie de artículos sobre Monitorización de Servicios de Solaris 10 con Nagios hemos visto las diferentes alternativas que tenemos. En esta ocasión, y como última parte de la serie, vamos a ver un plugin de Nagios que nos permite monitorizar remótamente las máquinas sin tener que utilizar SSH.

En la Primera Parte de Monitorización de Servicios de Solaris 10 con Nagios hemos visto cómo podemos utilizar unos pequeños plugins para <localmente> hacer checks a <svc> -básicamente es un warper del comando <svcs>-, en la Segunda Parte de Monitorización de Servicios de Solaris 10 con Nagios hemos visto cómo utilizar SSH para poder acceder remótamente al sistema de check

En esta ocasión hablaremos de NPRGE, un plugin de Nagios que nos permitirá monitorizar los servicios remotamente a través de un servicio que escucha en un puerto determinado.

La ventaja de este plugin es que la carga del sistema no se ve tan afectada -recordar que en la Parte 2 hablábamos de utilizar SSH- ya que el servicio consume menos recursos y no tiene que estar creando y destruyendo sesiones SSH. Sin embargo no todo son buenas noticias. El uso de este plugin -mejor dicho, una configuración incorrecta- hace que tengamos que tener mucho cuidado ya que abre un puerto y por lo tanto, debemos blindar su acceso.

Para aquellos que no tengais tiempo -o ganas- de compilar los paquetes os dejo aquí un par de tar.gz con las versiones compiladas para NRPE Solaris 10 SPARC y NRPE Solaris 10 x86, que incluyen los archivos para Solaris 10 SMF.

Instalación de NPRGE en Solaris 10La instalación del plugin en Solaris 10 no requiere de gran cosa, sin embargo, deberemos hacer algún cambio en el código fuente para que compile sin problemas. Además, si queremos incluir soporte SSL -muy recomendable- deberemos tener OpenSSL instalado.

Para evitar tener que ir instalando OpenSSL por todos los host podemos utilizar el que viene incluido en Solaris 10 </usr/sfw>, aunque es de 32bits nos servirá. Por ello, he decidido utilizar como compilador <gcc> y el OpenSSL incluido en Solaris 10.

Como os he comentado, antes de poder compilar correctamente el plugin, debemos hacer un pequeño ajuste en el código fuente, concretamente en <src/nrpe.c> con estas líneas de código:

        else if(!strcmp(varvalue,"authpriv"))                log_facility=LOG_AUTHPRIV;        else if(!strcmp(varvalue,"ftp"))                log_facility=LOG_FTP;

En Solaris 10, los niveles de log <LOG_AUTHPRIV> y <LOG_FTP> no están definidos, y por lo tanto, la compilación falla con el siguiente error:

nrpe.c: In function `get_log_facility':nrpe.c:618: error: `LOG_AUTHPRIV' undeclared (first use in this function)nrpe.c:618: error: (Each undeclared identifier is reported only oncenrpe.c:618: error: for each function it appears in.)nrpe.c:620: error: `LOG_FTP' undeclared (first use in this function)make[1]: *** [nrpe] Error 1Para solucionarlo, tenemos dos opciones: Eliminar esos niveles de log o Sustituirlos por uno definido. En nuestro ejemplo, vamos a sustituirlos por <LOG_AUTH> en ambos casos, así:

        else if(!strcmp(varvalue,"authpriv"))                log_facility=LOG_AUTH;        else if(!strcmp(varvalue,"ftp"))                log_facility=LOG_AUTH;Una vez explicado el problema -y con la solución- vamos a proceder a instalar el plugin -podemos utilizar una máquina de pruebas para realizar la compilación, ya que luego copiaremos los archivos necesarios a los hosts que queramos monitorizar-$ wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz$ gtar zxpf nrpe-2.12.tar.gz$ cd nrpe-2.12$ cat src/nrpe.c |sed s/LOG_AUTHPRIV/LOG_AUTH/g > src/nrpe.c.1$ mv src/nrpe.c.1 src/nrpe.c$ cat src/nrpe.c |sed s/LOG_FTP/LOG_AUTH/g > src/nrpe.c.1$ mv src/nrpe.c.1 src/nrpe.c$ ./configure --prefix=/opt/nagios/nrpe --with-nrpe-user=svcmon --with-nrpe-group=svcmon --with-ssl=/usr/sfw --with-ssl-lib=/usr/sfw/lib --with-ssl-inc=/usr/sfw/include --with-log-facility=local7 --with-nagios-user=svcmon --with-nagios-group=svcmon

*** Configuration summary for nrpe 2.12 03-10-2008 ***:

 General Options: ------------------------- NRPE port:    5666 NRPE user:    svcmon NRPE group:   svcmon Nagios user:  svcmon Nagios group: svcmon

Review the options above for accuracy.  If they look okay,type 'make all' to compile the NRPE daemon and client.

$ make

Si todo ha sido correcto, procederemos a la instalación con los siguientes comandos -recordar que si no tenemos permisos de escritura en el directorio <--prefix> deberemos ejecutarlo como <root>-

# make install-plugincd ./src/ && make install-pluginmake[1]: Entering directory `/export/home/itily/NRP/plugin/nrpe-2.12/src'/usr/local/bin/install -c -m 775 -o svcmon -g svcmon -d /opt/nagios/nrpe/libexec/usr/local/bin/install -c -m 775 -o svcmon -g svcmon check_nrpe /opt/nagios/nrpe/libexecmake[1]: Leaving directory `/export/home/itily/NRP/plugin/nrpe-2.12/src'

# make install-daemoncd ./src/ && make install-daemonmake[1]: Entering directory `/export/home/itily/NRP/plugin/nrpe-2.12/src'/usr/local/bin/install -c -m 775 -o svcmon -g svcmon -d /opt/nagios/nrpe/bin/usr/local/bin/install -c -m 775 -o svcmon -g svcmon nrpe /opt/nagios/nrpe/binmake[1]: Leaving directory `/export/home/itily/NRP/plugin/nrpe-2.12/src'

# make install-daemon-config/usr/local/bin/install -c -m 775 -o svcmon -g svcmon -d /opt/nagios/nrpe/etc/usr/local/bin/install -c -m 644 -o svcmon -g svcmon sample-config/nrpe.cfg /opt/nagios/nrpe/etcConfiguración de SysLogEn el proceso de <configure> hemos declarado nuestro nivel de log en <local7> y por lo tanto, debemos declararlo en nuestra configuración de syslog# vi /etc/syslog.conf   # Nagios PlugIn Log   local7.debug                                    /var/log/nrpe.log :wq

# touch /var/log/nrpe.log# chmod 600 /var/log/nrpe.log# svcadm restart system-logPrueba de Funcionamiento CorrectoAhora vamos a comprobar que todo funciona correctamente, para ello, vamos a ejecutar el daemon y vamos a hacer un par de checks, recordar que nuestro puerto es el 5666 y que no queremos ejecutarlo a través de xinetd por eso utilizamos la opción <-d># /opt/nagios/nrpe/bin/nrpe -c /opt/nagios/nrpe/etc/nrpe.cfg -d# netstat -an|grep 5666      *.5666               *.*                0      0 49152      0 LISTEN# /opt/nagios/nrpe/libexec/check_nrpe -H localhostNRPE v2.12# tail /var/log/nrpe.logApr  5 12:29:01 zion nrpe[2457]: [ID 601491 local7.notice] Starting up daemonApr  5 12:29:01 zion nrpe[2457]: [ID 624405 local7.info] Listening for connections on port 5666Apr  5 12:29:01 zion nrpe[2457]: [ID 907248 local7.info] Allowing connections from: 127.0.0.1Si todo ha salido correctamente -no veo por qué no- ya podemos configurar correctamente nuestro plugin para ello, deberemos editar el archivo de configuración <$NRPE_HOME/etc/nrpe.cfg> e incluir la dirección IP del host que autorizamos a realizar peticiones -en nuestro caso nagios-server- y los checks que queremos publicar.

Para autorizar un host a que haga peticiones a nuestro plugin deberemos incluirlo en la propiedad <allowed_hosts> -debemos tener en cuenta, si queremos varios deben estar separados por comas-

# vi /opt/nagios/nrpe/etc/nrpe.cfg   allowed_hosts=127.0.0.1,192.168.1.200:wq

Ahora vamos a declarar los checks que permitimos ejecutar, para ello deberemos editar las entradas de command añadiendo una por check que queramos exportar. El formato de la propiedad command tiene la siguiente estructura:command[<command_name>]=<command_line>Además, incluiremos los scripts <check_> en el directorio $NRPE_HOME/libexec, así que nosotros vamos a incluir el script de verificación de Solaris 10 SMF que utilizábamos en la primera parte

# cd $NRPE_HOME/libexec/# wget http://blog.sfchildren.com/blogger/solaris-smf-nagios/check_svc

Tener en cuenta los permisos, ya que el usuario noprivilegiado con el que ejecutamos el servicio debe ser capáz de ejecutarlos pero no queremos que pueda tocar más estructura de nuestra instalación, así que ponemos los siguientes permisos:# chown svcmon:svcmon check_*# ls -ltrtotal 138-r-xr-xr-x   1 svcmon   svcmon     54512 abr  5 12:20 check_nrpe-r-xr-xr-x   1 svcmon   svcmon      1190 abr  5 15:07 check_svc-r-xr-xr-x   1 svcmon   svcmon     12706 abr  5 15:16 check_solaris_smf# chmod 500 check_*# ls -la

total 142drwxr-xr-x   2 root     root         512 abr  5 15:16 .drwxr-xr-x   6 root     root         512 abr  5 15:19 ..-r-x------   1 svcmon   svcmon     54512 abr  5 12:20 check_nrpe-r-x------   1 svcmon   svcmon     12706 abr  5 15:16 check_solaris_smf-r-x------   1 svcmon   svcmon      1190 abr  5 15:07 check_svc

Ahora, si queremos exportar el check para verificar nuestro Tomcat sobre SMF , podemos utilizar la siguiente definición:command[check_tomcat6]=/opt/nagios/nrpe/libexec/check_svc tomcat_6:default_64bitsPor lo tanto, nuestro archivo de configuración tendrá una configuración similar a estaallowed_hosts=127.0.0.1,192.168.1.200command_timeout=60command[check_tomcat6]=/opt/nagios/nrpe/libexec/check_svc tomcat_6:default_64bitsconnection_timeout=300debug=0dont_blame_nrpe=0log_facility=local7nrpe_group=svcmonnrpe_user=svcmonpid_file=/var/run/nrpe.pidserver_port=5666

Instalación de NRPE Mediante SMFComo es habitual, utilizaremos el framework SMF para poder gestionar el servicio, para ello, deberemos descargarnos el Descriptor SMF para NRPE y el Method de Solaris SMF para NRPE e instalarlos, vamos a verlo.

Recordar que este artículo es la tercera parte y por lo tanto, asumo que el usuario, grupo y project están ya creados como indicábamos en la Parte 2 de Monitorización de Solaris con Nagios. Además, puede que debamos incrementar el valor de <task.max-lwps> # cd /var/svc/manifest/application/management# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/solaris-smf-nagios/nrpe/nrpe_2.xml# chown root:sys nrpe_2.xml# chmod 444 nrpe_2.xml# svccfgsvc:> validate nrpe_2.xmlsvc:> import nrpe_2.xmlsvc:> quit# cd /lib/svc/method# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/solaris-smf-nagios/nrpe/nrpe2# chown root:bin nrpe2# chmod 755 nrpe2  Activamos el servicio con <svcadm> -tenemos dos, uno con SSL activado y otro SIN SSL-, en nuestro caso, vamos a utilizar SSL_Enabled# svcs nrpe_2STATE          STIME    FMRIdisabled       16:08:25 svc:/application/management/nrpe_2:ssl_disableddisabled       16:08:27 svc:/application/management/nrpe_2:ssl_enabled# svcadm enable nrpe_2:ssl_enabled# svcs -p nrpe_2STATE          STIME    FMRIdisabled       16:08:25 svc:/application/management/nrpe_2:ssl_disabledonline         16:11:00 svc:/application/management/nrpe_2:ssl_enabled               16:11:00    20279 nrpeFinalización InstalaciónYa hemos acabado con la Instalación de NRPE Sobre Solaris 10! Como veis, no ha sido tan complicada, no?

Conclusión FinalDurante estos capítulos hemos visto diferentes formas de monitorizar los servicios de Solaris 10 utilizando Nagios. Sobre cuál es la forma correcta? Bueno, la verdad es que depende de qué quieras hacer y sobre todo qué impacto de rendimiento sufre.

El uso de comandos a través de SSH hace que -al menos en teoria- se puedan controlar más los accesos y, sobre todo no expones un nuevo puerto, sin embargo, esto supone una carga muy elevada en la máquina.

Si nos decantamos por el uso de NRPE podemos ver cómo la carga se disminuye pero debemos tener mucho cuidado con los accesos y controlar -mediante IPFilter- quién puede acceder y qué puede hacer. Ademas, qué pasa si el daemon se cae? Para evitar eso, tenemos nuestro NRPE dentro de SMF, al menos, sabemos que Solaris lo gestionará de forma "automática" y nos da mayor garantia de funcionamiento. Si a eso le unimos poder checkear por SSH el demonio, ya tenemos nuestro sistema "blindado"

Instalar Java 6 en Solaris 10 64bits

IntroducciónLa instalación de Java se nos proporciona de dos forma: mediante pkgadd o mediante archivo autoextraible. El primer dilema es seleccionar cuál de los dos formatos es el que nos interesa utilizar, y bien, esto depende en gran medida de qué tipo de aplicaciones tengamos instalado y su certificación.

Me explico, imaginemos que tenemos un applicativo APP el cual está certificado sólo y exclusivamente para Java 1.5.x, e incompatible con la 1.6.x. En esta situación tenemos dos soluciones:

Configurar correctamente los PATH para que sólo ejecute la versión 1.5.x No instalar otra máquina virtual distinta a la 1.5.x

Bien, partiendo de la base de que no tenemos estos problemas, y centrándonos en el tema del post, vamos a ver qué diferencias hay entre la instalación mediante pkgadd y autoextraible.

Instalación mediante <pkgadd>Este tipo de instalación requiere acceso como <root> ya que vamos registrar el paquete en la base de datos de software instalado de Solaris. Tiene como ventaja, que si realizamos una instalación de parches, al estar declarado en la base de Software instalado, se podrán aplicar los necesarios de forma automática.

Debemos tener en cuenta, que si hacemos esto desde la zona global, y no decimos lo contrario, éste se instalará en todas las zonas, esto puede ser un tipo de inconveniente cuando tenemos varias zonas con diferentes requisitos de Java, i.e. Oracle, Tomcat, ActiveMQ, ...

Lo primero que debemos hacer es Descargar Java 6 JDK o JRE desde Sun y seleccionaremos la arquitectura de nuestra plataforma, en mi caso Solaris SPARC.

En la pagina de descargas, después de logearnos, tendremos cuatro opciones: jdk-VERSION-solaris-sparc.tar.Z jdk-VERSION-solaris-sparcv9.tar.Z jdk-VERSION-solaris-sparc.sh jdk-VERSION-solaris-sparcv9.sh

Las versiones <tar.Z> corresponde al tipo de instalación con pkgadd y las versiones <sh> a las versiones autoextraibles, además las versiones de 64bits en SPARC son referenciadas como sparcv9 y las de 32bits como sparc. A continuación veámos cómo se instalan los paquetes, (realmente es el mismo proceso que cualquier otro paquete de Solaris, en mi ejemplo instalo todos aunque puedes seleccionar que quieres instalar)

# zcat jdk-6u17-solaris-sparc.tar.Z |tar xpf -# pkgadd -d .

The following packages are available:  1  SUNWj6cfg              JDK 6.0 Host Config. (1.6.0_17)                            (sparc) 1.6.0,REV=2006.11.29.05.57  2  SUNWj6dev              JDK 6.0 Dev. Tools (1.6.0_17)                            (sparc) 1.6.0,REV=2006.11.29.05.57  3  SUNWj6dmo              JDK 6.0 Demo Programs (1.6.0_17)                            (sparc) 1.6.0,REV=2006.11.29.05.57  4  SUNWj6jmp              JDK 6.0 Man Pages: Japan (1.6.0_17)                            (sparc) 1.6.0,REV=2006.12.07.19.24  5  SUNWj6man              JDK 6.0 Man Pages (1.6.0_17)                            (sparc) 1.6.0,REV=2006.12.07.16.37  6  SUNWj6rt               JDK 6.0 Runtime Env. (1.6.0_17)                            (sparc) 1.6.0,REV=2006.11.29.05.57  7  SUNWjavadb-client      Java DB client

                            (sparc) 10.4.2,REV=2008.10.20  8  SUNWjavadb-common      Java DB common files                            (sparc) 10.4.2,REV=2008.10.20  9  SUNWjavadb-core        Java DB core                            (sparc) 10.4.2,REV=2008.10.20 10  SUNWjavadb-demo        Java DB demo                            (sparc) 10.4.2,REV=2008.10.20

... 3 more menu choices to follow;for more choices, to stop display:

 11  SUNWjavadb-docs        Java DB documentation                            (sparc) 10.4.2,REV=2008.10.20 12  SUNWjavadb-javadoc     Java DB javadoc                            (sparc) 10.4.2,REV=2008.10.20 13  SUNWjavadb-service     Java DB service management                            (sparc) 10.4.2,REV=2008.11.13

Select package(s) you wish to process (or 'all' to processall packages). (default: all) [?,??,q]: all

 El instalador realizará esta tarea para cada una de las zonas.Una vez concluido el proceso, ya tenemos nuestra versión Java instalada

Instalación desde archivo shEste tipo de instalación no requiere privilegios de <root>, ya que es un shx (archivo autoextraible)  y por lo tanto, sólo necesitamos permisos de escritura en el directorio en el cuál queremos descomprimirlo, sin embargo, a diferencia de la instalación mediante <pkgadd> no queda reflejado en la base de datos de software instalado, y por lo tanto, cuando parchemos no se aplicarán los cambios al paquete JDK.

Continuando con la instalación mediante archivo sh, quiero descomprimirlo en /usr/jdk/instances y por lo tanto si que necesito ser root

En esta ocasión, nos interesan las versiones <sh> de la página de descargas de Sun. Recordar que cuando se transfieran los archivos al servidor si lo hacemos mediante ftp, debemos asignar el tipo de transferencia como binario ya que sino, no se extraerá correctamente. Si utilizamos sftp, no hay problema

Una vez subidos al servidor, simplemente deberos ejecutarlos en el directorio que queremos extraerlo, por ejemplo, en mi caso los sh están en $HOME/jdk/6/ y quiero instalarlos en /usr/jdk/instances así que hago lo siguiente# cd /usr/jdk/instances# sh $HOME/jdk/6/jdk-6u17-solaris-sparc.sh

ahora sale un mensaje de licencia, pulsamos Q y aceptamos la licencia

Do you agree to the above license terms? [yes or no]yes Repetimos el mismo procedimiento para la versión de 64bits# cd /usr/jdk/instances# sh $HOME/jdk/6/jdk-6u17-solaris-sparcv9.shYa tenemos concluida la instalación de Java.

Hacer esta versión por defectoUna vez instalada la nueva versión de Java, nuestro sistema seguirá llamado a la versión de Java que tiene en el PATH, esto es /usr/bin/java que es un link a /usr/java/bin/java, así que para hacer que sea nuestro default tenemos dos opciones:

Establecer la variable de entorno PATH como PATH=/usr/jdk/instances/jdk1.6.0_17/bin:$PATH Borrar y crear el link de /usr/java a /usr/jdk/instances/jdk1.6.0_17/

Veamos cómo recrear el link

# which java/usr/bin/java# ls -l /usr/bin/javalrwxrwxrwx   1 root     other         16 sep  2  2008 /usr/bin/java -> ../java/bin/java# ls -l /usr/javalrwxrwxrwx   1 root     other         15 sep  2  2008 /usr/java -> jdk/jdk1.5.0_14# rm /usr/java# ln -s /usr/jdk/instances/jdk1.6.0_17 /usr/java# java -version java version "1.6.0_17"Java(TM) SE Runtime Environment (build 1.6.0_17-b04)Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)ConclusionesEn ambos casos, la instalación de Java no reviste mayor problema, sin embargo, la decisión de instalación de una forma u otra dependerá principalmente del tipo de software que tenemos instalado.

Yo por ejemplo, en las workstation o equipos de testing suelo utilizar las versiones de sh y, en producción las de pkgadd (siempre que no esté Oracle por medio)

Instalar Apache Tomcat Solaris 10 64bits SMF

IntroducciónEn esta ocasión vamos a instalar Apache Tomcat 6.0 en Solaris 10 64bits utilizando el framework SMF para su gestión.

PrerequisitosEn función de la versión de Apache Tomcat que queramos instalar, necesitaremos una versión de máquina virtual u otra, por ejemplo, para Apache Tomcat 6.x necesitaremos JVM 1.5+ y para Apache Tomcat 5.x JVM 1.4+.

En este ejemplo vamos a instalar la versión de Apache Tomcat 6.x utilizando la versión 1.6+ en 64bits, para comprobar la versión que tenemos instalada y su arquitectura haremos lo siguiente:$ which java/usr/bin/java$ java -versionjava version "1.6.0_17"Java(TM) SE Runtime Environment (build 1.6.0_17-b04)Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode) Para comprobar si tenemos soporte de Java 64bits, utilizaremos el modificador <-d64>, además debemos tener en cuenta si nuestro Solaris tiene Soporte de 64bits$ java -d64 -versionjava version "1.6.0_17"Java(TM) SE Runtime Environment (build 1.6.0_17-b04)Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)Si por algún motivo no tuvieses la versión de Java mínima, puedes ver Cómo Instalar Java en Solaris 10 64bits

En esta ocasión vamos a instalar Apache Tomcat utilizando el usuario <webrunner&g;, grupo <webrunner> y project <user.webrunner>, así que deberemos crearlos antes de continuar,# groupadd webrunner# useradd -s /bin/bash -d /export/home/webrunner -m -g webrunner webrunner# projadd user.webrunnerDescargar e Instalación de Apache TomcatDescargaremos la versión binaria de Apache Tomcat, recordar que es una aplicación Java, y por lo tanto, no depende de plataforma, desde la web de Apache Tomcat  y la descomprimiremos en el directorio que nosotros queramos, en mi caso voy a situar la aplicación en </opt/ww/tomcat6># cd /opt/# mkdir www# cd /opt/www/# pwd/opt/www# /usr/sfw/bin/wget http://apache.rediris.es/tomcat/tomcat-6/v6.0.20/bin/apache-tomcat-6.0.20.tar.gz# /usr/sfw/bin/gtar zxpf apache-tomcat-6.0.20.tar.gz# mv apache-tomcat-6.0.20 tomcat6# chown -R webrunner:webrunner tomcat6# rm apache-tomcat-6.0.20.tar.gzInstalación del DescriptorPuedes descargar el Descriptor SMF para Tomcat6 o Descriptor SMF para Tomcat 5.x, en ambos casos, debes asignar los valores correctos a las propiedades

home, Directorio donde hemos instalado el Tomcat jvmargs, Argumentos de la máquina virtual, valor que se pasará a la variable JAVA_OPTS project, Project con el cual lanzaremos el Tomcat java_home, Home de la versión de Java a utilizar

Una vez editado, simplemente lo cargaremos en nuestro repositorio con el comando <svccfg># mkdir -p /var/svc/manifest/application/web# cd /var/svc/manifest/application/web

# /usr/sfw/bin/wget blog.sfchildren.com/blogger/tomcat/smf/tomcat_6.xml# svccfgsvc:> validate /var/svc/manifest/application/web/tomcat_6.xmlsvc:> import /var/svc/manifest/application/web/tomcat_6.xmlsvc:> quit# svcs tomcat_6STATE STIME FMRIdisabled 13:53:39 svc:/application/web/tomcat_6:default_64bitsdisabled 13:54:16 svc:/application/web/tomcat_6:default_32bitsAhora vamos a descargar el archivo method de Tomcat encargado de ejecutar realmente el Tomcat. Esta versión no es necesario modificar ya que se nutre de los parámetros definidos en el Manifest, podéis descargar el Method para Tomcat 6 o Method para Tomcat 5# cd /lib/svc/method# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/tomcat/smf/tomcat6# chown root:bin tomcat6# chmod 555 tomcat6Activación del Servicio TomcatAhora activaremos el servicio que deseemos, en mi caso el de 64bits, pero recordad que sólo uno de los dos puede estar activo simultáneo# svcadm enable tomcat_6:default_64bits# svcs tomcat_6STATE          STIME    FMRIdisabled       13:54:16 svc:/application/web/tomcat_6:default_32bitsonline         13:55:39 svc:/application/web/tomcat_6:default_64bitsPodemos ver el pid del proceso Java que está ejecutando utilizando el modificador <-p> del comando <svcs>$ svcs -p tomcat_6STATE          STIME    FMRIdisabled       dic_09   svc:/application/web/tomcat_6:default_64bitsonline         11:58:26 svc:/application/web/tomcat_6:default_32bits               11:58:26    24927 javaConclusionesEn esta ocasión hemos visto cómo podemos activar el servicio Apache Tomcat utilizando SMF y su gestión pasa ahora por el Sistema Operativo.

Ahora que ya entendemos cómo funciona SMF, podemos hacer definiciones más complejas utilizando servicios dependientes en nuestros archivos manifest, pero esto es para el siguiente post