SafeChildren Banner

Havoc Oracle Solaris Experts
Mostrando entradas con la etiqueta tomcat. Mostrar todas las entradas
Mostrando entradas con la etiqueta tomcat. Mostrar todas las entradas

martes, 1 de marzo de 2011

Tomcat sobre SMF y RBAC en OpenIndiana y Solaris

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

lunes, 29 de noviembre de 2010

Cómo configurar HTTPS en Tomcat utilizando Roles y Privilegios

Introducción
Ya hemos visto en ocasiones anteriores Cómo Instalar Apache Tomcat en Solaris. Además, con los conocimientos que hemos adquirido sobre RBAC, Roles, Privilegios y Seguridad en Solaris, podemos realizar la instalación con un nivel de seguridad muy elevado.

En esta ocasión vamos a ver cómo podemos configurar un conector HTTPS en Apache Tomcat, utilizando un puerto no privilegiado, por ejemplo 8443, y luego, veremos cómo podemos utilizar el puerto privilegiado 443 sin tener que lanzar Apache Tomcat con <root>.

Instalación de Apache Tomcat
Para su instalación seguiremos los pasos del post Cómo Instalar Apache Tomcat en Solaris 10 utilizando SMF para su gestión, aunque haremos algunos cambios -ahora que conocemos RBAC y Roles-

Diferencias en la Instalación
Cuando hablábamos de Cómo Instalar Tomcat en Solaris 10 utilizando SMF, todavía no habíamos mencionado el tema de RBAC, Roles y Privilegios, por lo tanto, no podíamos entrar en mucha complicación. Ahora bien, ya estamos en disposición de poder instalarlo de una forma mucho más segura y eficiente utilizando: roles, privilegios y autorizaciones.


Creación de la Clave RSA
En nuestro ejemplo vamos a generar un clave <auto sellada>, es decir, que seremos nosotros mismos quienes validemos la firma.

Esta funcionalidad nos permite establecer certificados de forma sencilla, aunque no es recomendable para su puesta en producción -sobre todo si es un servicio a terceros-, principalmente porque al estar validado por nosotros mismos, el navegador nos mostrará un mensaje de aviso.

Sin embargo, para pruebas es una forma muy sencilla de trabajar -y barata-. En nuestro caso, queremos crear el keystore en <$TOMCAT_HOME/cert/havoctec-tomcat>
$ cd $TOMCAT_HOME
$ mkdir cert
$ chmod 700 cert
$ chown appserver:root cert
Ahora podemos utilizar la utilidad <keytool> de Java para generar la clave RSA que utilizaremos en Tomcat
$ keytool -keystore /var/sfchildren/appserver/tomcat-6.0/cert/havoctec-tomcat -genkey -keyalg RSA -alias havoctec
Escriba la contraseña del almacén de claves: havoctec 
Volver a escribir la contraseña nueva: havoctec
¿Cuáles son su nombre y su apellido?
  [Unknown]:  Urko Benito
¿Cuál es el nombre de su unidad de organización?
  [Unknown]:  HavocTec S.L.
¿Cuál es el nombre de su organización?
  [Unknown]:  HavocTec S.L.
¿Cuál es el nombre de su ciudad o localidad?
  [Unknown]:  MADRID
¿Cuál es el nombre de su estado o provincia?
  [Unknown]:  SPAIN
¿Cuál es el código de país de dos letras de la unidad?
  [Unknown]:  ES
¿Es correcto CN=Urko Benito, OU=HavocTec S.L., O=HavocTec S.L., L=MADRID, ST=SPAIN, C=ES?
  [no]:  si

Escriba la contraseña clave para
        (INTRO si es la misma contraseña que la del almacén de claves):  havoctec
Esto nos ha creado una nueva clave RSA en el almacén que hemos indicado, en nuestro caso
<$TOMCAT_HOME/cert>, sin embargo, los permisos son muy leves, y es interesante modifcarlos para que sólo el dueño pueda leer y escribir en el él, por ejemplo:
$ ls -ltr
total 4
-rw-r--r--   1 appserver asengine    1381 nov 29 09:18 havoctec-tomcat
$ chmod 600 havoctec-tomcat
$ ls -ltr
total 4
-rw-------   1 appserver asengine    1381 nov 29 09:18 havoctec-tomcat

Creación del Connector HTTPS en puerto NO PRIVILEGIADO (8443)
Por último, definiremos un conector HTTPS en el archivo de configuración <$TOMCAT_HOME/conf/server.xml> donde deberemos indicarle la ubicación del keystore, y su contraseña, por ejemplo, en nuestro caso la ubicación del certificado es <$TOMCAT_HOME/cert/havoctec-tomcat> y su contraseña <havoctec>

$ vi $TOMCAT_HOME/conf/server.xml

    <Connector
        port="8443"
        protocol="HTTP/1.1"
        SSLEnabled="true"
        maxThreads="150"
        scheme="https"
        secure="true"
        clientAuth="false"
        keystoreFile="/var/sfchildren/appserver/tomcat-6.0/cert/havoctec-tomcat"
        keystorePass="havoctec"

        sslProtocol="TLS" />

:wq

Conexión mediante HTTPS a Tomcat
Ya podemos iniciar nuestro servidor Apache Tomcat (si lo tenemos levantado, deberemos reiniciarlo) y con un navegador nos conectaremos al puerto 8443 utilizando HTTPS

Mi servidor de ejemplo está en la IP 192.168.1.13 y, cuando me conecto con Safari al servicio veo el siguiente mensaje de aviso -como ya os he comentado es debido a que hemos "auto firmado" el certificado-

 Si pulso sobre "Mostrar Certificado" puedo ver los datos que he introducido en le comando <keytool> para su generación.


Funciona! No ha sido tan difícil, no? Ahora bien, el puerto para el protocolo HTTPS es el 443, y no el 8443 así que tenemos diferentes opciones para poder hacer una conexión HTTPS utilizando la forma <https:// ....>
  • Utilizamos <ipfilter> para redirigir el tráfico
  • Configuramos el usuario (role) de Apache Tomcat para permitirle utilizar puertos privilegiados
  • Ponemos un <reverse proxy> con soporte SSL
Como veis son muchas las opciones, aunque hoy vamos a ver una muy sencilla -ahora que conocéis RBAC, Roles y Privilegios- vamos a otorgar el privilegio <net_privaddr>


Configuración Privilegios Role o Usuario
Para poder hacer que nuestro <role> o <user> levante el servicio Tomcat en un puerto privilegiado, deberemos añadir el privilegio <net_privaddr>, para ello simplemente deberemos ejecutar (el <role> encargado de levantar el servicio de Tomcat en mi caso es <appserver>)
root@openzooey:/# rolemod -K defaultpriv=basic,net_privaddr appserver

A continuación, modificaremos el conector para que, en vez de escuchar en el puerto 8443 lo haga en le 443 y levantaremos nuestro Tomcat

$ $TOMCAT_HOME/bin/shutdown.sh
$ vi $TOMCAT_HOME/conf/server.xml
    <Connector
        port="443"
        protocol="HTTP/1.1"
        SSLEnabled="true"
        maxThreads="150"
        scheme="https"
        secure="true"
        clientAuth="false"
        keystoreFile="/var/sfchildren/appserver/tomcat-6.0/cert/havoctec-tomcat"
        keystorePass="havoctec"

        sslProtocol="TLS" />
 :wq
$ $TOMCAT_HOME/bin/startup.sh


Conclusiones
En esta ocasión hemos visto como con el uso de privilegios nos permite hacer cosas que antes deberíamos delegar en <root>, además, de esta forma podemos tener un sistema muy seguro y controlado.



Referencias

lunes, 28 de junio de 2010

Rendimiento Java NIO en Tomcat 6

Introducción
En el post anterior hablábamos de Cómo Configurar Tomcat 6 para Activar Java NIO, en esta ocasión vamos a ver algunos gráficos sobre el rendimiento Java NIO vs Java IO.

Lo primero que debemos tener en cuenta es que cada aplicación es diferente y por lo tanto, no se puede establecer una regla universal sobre cual de las dos tecnologías en la mejor. Por ello, os recomiendo que utilicéis Pruebas de Rendimiento de Aplicaciones Web con JMeter para poder tomar una decisión sobre Java NIO.

Además, Tomcat 6 está en fase de pruebas y por lo tanto, no está enfocado a producción, sin embargo, GlassFish si que tiene soporte de Java NIO en sus versiones de producción

La Prueba
Para llevar a cabo la prueba de rendimiento he utilizado una aplicación con un servlet que acepta una cadena por parámetros, inserta en la base de datos (PostgreSQL) y devuelve la cadena. Como veis, no es muy complicada, pero para hacer mis análisis era suficiente.

5 Usuarios x 1000 Peticiones usando Default I/O

5 Usuarios x 1000 Peticiones usando NIO


10 Usuarios x 500 Peticiones usando Default I/O


10 Usuarios x 500 Peticiones usando NIO


Resultados Totales
Aquí os dejo un documento con todos los datos del cálculo de rendimiento NIO vs IO para poder analizarlos de una forma más sencilla.



Conclusiones
En nuestro caso, el rendimiento se incrementaba de forma notable cuando teníamos pocos usuarios (dos usuarios)  ya que pasaba de una media de ejecución de 3501s a 939s, sin embargo, cuanto más incrementábamos los usuarios, la diferencia no era tan grande -aunque siempre se obtenía mejor rendimiento con NIO- llegando a 2532s vs 2475s con 10 usuarios y 500 peticiones.

Creo que NIO puede ofrecer mejoras, pero hay que estudiar cada caso con detenimiento.

Referencias

miércoles, 23 de junio de 2010

Activar Java NIO en Tomcat6

Introducción
Una de las características más esperadas que introdujo la versíon 1.4 de Java fue un nuevo sistema de IO adaptado a los sistemas modernos. Esto permitía adaptar el formato de entrada/salida a las nuevas características de las CPUs -principalmente MultiThread- haciendo que las peticiones fuesen "no bloqueantes" y por lo tanto "sean manejadas por threads".  No voy a entrar en mucho detalle sobre cuáles son las diferencias -ya que pienso que es un tema de programación- pero sí que voy a explicar por qué nos aplica en términos de sistemas:
  • No permite escalar más y utilizar mejor los threads de las CPUs. De esta forma, tendremos menos cambios de contexto y por lo tanto mejor rendimeinto
  • Uso de Socket Asíncronos. De esta forma, seremos capaces de soportar más peticiones concurrentes en nuestros servidores de aplicaciones.
  • Podemos usar Resource Control. De esta forma, los límites y uso de recursos están mejor controlados en el sistema.
Sin embargo, no ha sido hasta la versión 6 de Tomcat cuando hemos podido empezar a utilizar esta nueva configuración.


Configuración de Apache Tomcat 6.x
Para activar el funcionamiento NIO en Tomcat 6, siemplemente editaremos el archivo de configuración <CATALINA_HOME/conf/server.xml> y modificaremos el valor de la propiedad:
protocol="HTTP/1.1"
por
protocol="org.apache.coyote.http11.Http11NioProtocol"
Por ejemplo, podemos añadir un nuevo "connector" en el puerto 8585 que use el formano NIO de la siguiente forma:
    <!-- NIO Connector With Compression -->
    <Connector
        maxThreads="256"
        enableLookups="false"
        protocol="org.apache.coyote.http11.Http11NioProtocol"
        keepAliveTimeout="5000"
        maxKeepAliveRequests="1000"
        port="8585"
        connectionTimeout="20000"
        compression="on"
        bufferSize="8192"
        redirectPort="8443"
        URIEncoding="UTF-8"
    />
Conclusiones
Como hemos visto, cambiar al nuevo sistema de IO (NIO) que nos proporciona Java a partir de la versión 1.4.2 es realmente sencillo. En las próximas entregas veremos si -como dicen en Sun- es un sistema revolucionario y proporciona un rendimiento superior en sistemas con mucha carga.

Referencias

miércoles, 14 de abril de 2010

Configurar Virtual Hosts en Tomcat 6 y Contextos de Aplicación - Parte 1

Introducción
En esta serie de artículos, vamos a ver las diferentes formas que hay para definir una estructura de Apache Tomcat para su puesta en producción. Veremos cómo podemos configurar Apache Tomcat con Apache HTTP mediante <mod_jk> y cómo poner <squid-cache> como frontend haciendo de proxy reverso.

Como es una serie y no un unico post iremos viendo cómo montar la infraestructura, desde lo más básico, hasta -en las últimas entregas- cómo ponerlo en producción.

Instalar Apache Tomcat "Stand Alone"
Uno de los problemas con los encontramos al montar Apache Tomcat, es que si no queremos ejecutarlo con root debemos levantarlo en un puerto superior a 1024. Esto hace que tengamos que utilizar ipfilter para realizar un redirect, por ejemplo:
rdr ed0 0.0.0.0/0 port 80 -> 127.0.0.1 port 8080
De esta forma, hacemos que la peticiones a nuestro puerto http(80) sean redireccionadas al puerto 8080 de localhost.

Con este sencillo paso, hemos conseguido publicar nuestro Apache Tomcat en el puerto http(80), sin embargo, esta configuración -así sola- no nos sirve de mucho, ya que principalmente no tenemos alta disponibilidad, balanceo, firewall, virtual hosts. Además, se incluye el problema del contexto.

Contextos de Aplicaciones Web
El contexto de una aplicación Web es -en casos generales- el nombre de la aplicación, por ejemplo, si tenemos la aplicación web llamada HelloWorld.war, su contexto será <HelloWord>, es decir, la URL resultante será:
http://www.sfchildren.com/HelloWord/index.jsp
Así que tendremos tantos contextos como aplicaciones. Sin embargo, si tecleamos la URL
http://www.sfchildren.com/
Nuestro tomcat utilizará una aplicación expecífica llamada ROOT -que en la instalación por defecto será el manager-

# ls -l $TOMCAT_HOME/webapps/ROOT
total 256
-rw-r--r--   1 webrunner www         5866 may 14  2009 asf-logo-wide.gif
-rw-r--r--   1 webrunner www         3376 may 14  2009 build.xml
-rw-r--r--   1 webrunner www        21630 may 14  2009 favicon.ico
-rw-r--r--   1 webrunner www         7777 may 14  2009 index.html
-rw-r--r--   1 webrunner www         8307 may 14  2009 index.jsp
-rw-r--r--   1 webrunner www         7317 may 14  2009 RELEASE-NOTES.txt
-rw-r--r--   1 webrunner www         2324 may 14  2009 tomcat-power.gif
-rw-r--r--   1 webrunner www         1934 may 14  2009 tomcat.gif
-rw-r--r--   1 webrunner www        65643 may 14  2009 tomcat.svg
drwxr-xr-x   2 webrunner www          512 jun 16  2009 WEB-INF
Para evitar que nos muestre la página de administración de Tomcat, tenemos varias soluciones, vamos a ir viendo cada una de ellas.

Crear un <index.html> con un redirect a la página correcta
Por ejemplo, podemos crear una página <index.html> con un pequeño script en JavaScript que nos mande un 301 a la nueva dirección. Siguiendo con el ejemplo,
$ cd $TOMCAT_HOME/webapps/ROOT
$ vi index.html
  <HTML>
  <HEAD>
  <META
     HTTP-EQUIV="Refresh"
     CONTENT="0; URL=http://www.sfchildren.com/HelloWord/index.jsp">
  </HEAD>
  <BODY>
  </BODY>
  </HTML>
:wq

Problemas de esta solución
Bueno, no hace falta decir que si tenemos varias aplicaciones en el mismo tomcat sólo podremos hacer un redirect a una de ellas, además de no tener soporte para VirtualHosts


Sustituir la aplicación <ROOT> por nuestra <HelloWord>
Ya hemos comentado antes que tomcat tiene definida una aplicación por defecto llamada <ROOT> la cual hace referencia a la aplicación sin contexto, podemos por lo tanto, sustituir esta por nuestra aplicación <HelloWord>, veamos un ejemplo -imaginamos que tenemos la aplicación HelloWorld.war en nuestro HOME-
$ cd $TOMCAT_HOME/webapps/ROOT
$ jar xvf $HOME/HelloWorld.war
$ ls -l
total 258
-rw-r--r--   1 webrunner www          148 abr 14 11:35 index.html
drwxr-xr-x   2 webrunner www          512 jun 16  2009 WEB-INF

Qué hemos conseguido
Al hacer este cambio, hemos hecho que el contexto <HelloWord> no sea necesario, y por lo tanto, nuestra URL ahora será la siguiente:
http://www.sfchildren.com/


Problemas de esta solución
Al igual que sucedía antes, seguimos necesitando una instalación de tomcat por aplicación y por lo tanto, muchos sistemas a administrar. Además, no tenemos VirtualHosts ...


Creación de VirtualHosts en Tomcat6
Para solucionar estos problemas tenemos los VirtualHost que -de forma sencilla- hacen una discriminación de la petición en función del valor de la cabecera HOST de cada petición http, por lo tanto, lo que nosotros queremos es que las peticiones a:
  • http://app1.sfchildren.com/ sean enviadas a HelloWorld1
  • http://app2.sfchildren.com/ sean enviadas a HelloWorld2
La activación de los virtualhost en Tomcat6 no requiere de grandes configuraciones, tan sólo es necesario modificar un par de archivos de configuración, es muy importante que el tomcat esté detenido antes de comenzar

Lo primero que debemos hacer es dar de alta los hosts en el archivo de configuración del servidor <$TOMCAT_HOME/conf/server.xml> en el apartado de <Engine>. El formato del tag es:
<Host name="_nombre_vhost_"     appBase="_path_to_base_dir" />

En nuesto ejemplo, crearemos <app1> y <app2> como virtual hosts
$ vi $TOMCAT_HOME/conf/server.xml
    ...
        <Host name="app1.sfchildren.com"      appBase="vdomains/app1.sfchildren.com" />
        <Host name="app2.sfchildren.com"      appBase="vdomains/app2.sfchildren.com" />
   ...

:wq
A continuación crearemos el directorio appBase con sus subdominios
$ mkdir -p $TOMCAT_HOME/vdomains/app1.sfchildren.com
$ mkdir -p $TOMCAT_HOME/vdomains/app2.sfchildren.com
Y creamos las aplicación <ROOT> con nuestra HelloWorld -como hemos visto antes-

$ mkdir $TOMCAT_HOME/vdomains/app1.sfchildren.com/ROOT
$ mkdir $TOMCAT_HOME/vdomains/app2.sfchildren.com/ROOT
$ cd $TOMCAT_HOME/vdomains/app1.sfchildren.com/ROOT
$ jar xvf $HOME/HelloWorld1.war
$ cd ../app2.sfchildren.com/ROOT
$ jar xvf $HOME/HelloWorld2.war
A continuación, levantaremos el tomcat con svc y con un navegador nos pondremos en cada una de las diferentes URL para ver cómo vamos a una u otra.

Un concepto muy importante a tener en cuenta es el uso de resources dentro de los contextos de aplicaciones, es decir, el acceso mediante JNDI a un DataSource. Para que el procedimiento de virtualhost de tomcat no nos amargue la vida con problemas, deberemos pedir que los aplicativos (war) tengan definido su context.xml dentro de la carpeta <WebAPP/META-INF/>, esto nos hará los despliegues en virtualhost mucho más sencillos
$ ls -l $TOMCAT_HOME/vdomains/app1.sfchildren.com/ROOT/META-INF/
total 4
-rw-r--r--   1 webrunner www          536 feb 28 22:51 context.xml
-rw-r--r--   1 webrunner www          102 abr 13 00:02 MANIFEST.MF

Problemas de esta Solución
Claro, no todo puede ser tan bonito. Hemos solucionado el problema del contexto y de tener varias aplicaciones web sobre el mismo servidor Tomcat, sin embargo, tenemos algunas carencias que no podemos cubir: Balanceo de Carga -Alta disponibilidad-, URL Rewrite, Firewall L7

Conclusiones
En esta primera parte de Puesta en producción de Apache Tomcat, hemos visto cómo podemos utilizar los VirtualHosts para solucionar los problemas a múltiples aplicaciones dentro del mismo tomcat. Sin embargo, sólo con apache tomcat no podemos ofrecer las soluciones a todos los problemas que se nos presentan -alta disponibilidad, URL rewrite-.

En la próxima entrega veremos cómo incluir Apache HTTPD con su módulo <mod_jk> el cual nos permitirá  conectarnos a tomcat y realizar tareas de balanceo, standby, ... hasta entonces, esperar


Referencias

lunes, 14 de diciembre de 2009

Instalar Apache Tomcat Solaris 10 64bits SMF

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

Prerequisitos
En 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 -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)
 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 -version
java 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.webrunner
Descargar e Instalación de Apache Tomcat
Descargaremos 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.gz
Instalación del Descriptor
Puedes 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
# svccfg
svc:> validate /var/svc/manifest/application/web/tomcat_6.xml
svc:> import /var/svc/manifest/application/web/tomcat_6.xml
svc:> quit
# svcs tomcat_6
STATE STIME FMRI
disabled 13:53:39 svc:/application/web/tomcat_6:default_64bits
disabled 13:54:16 svc:/application/web/tomcat_6:default_32bits
Ahora 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 tomcat6
Activación del Servicio Tomcat
Ahora 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_6
STATE          STIME    FMRI
disabled       13:54:16 svc:/application/web/tomcat_6:default_32bits
online         13:55:39 svc:/application/web/tomcat_6:default_64bits
Podemos ver el pid del proceso Java que está ejecutando utilizando el modificador <-p> del comando <svcs>
$ svcs -p tomcat_6
STATE          STIME    FMRI
disabled       dic_09   svc:/application/web/tomcat_6:default_64bits
online         11:58:26 svc:/application/web/tomcat_6:default_32bits
               11:58:26    24927 java
Conclusiones
En 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


Referencias