SafeChildren Banner

Havoc Oracle Solaris Experts

miércoles, 16 de diciembre de 2009

Instalar Apache HTTP 64bits SunCC Solaris 10

Introducción
En esta ocasión vamos a ver cómo podemos Compilar Apache HTTP Server en 64bits utilizando SunCC en Solaris 10. Esto es debido en gran parte a un problema que os conté hace un tiempo sobre Problemas de Compilación Apache HTTP Server con GCC en Solaris 10 y que se debían a un bug de GCC en Solaris.

Continuando con la serie de Optimización de Páginas Web en Solaris, me he encontrado con otro problema, esta vez con el módulo mod_gzip que produce un core dump cuando se ejecuta compilado con GCC en 64bits. La verdad es que he probado de todo pero no he sido capáz de hacer funcionar este módulo con el servidor Apache HTTP en 64bits sobre Solaris compilado con GCC, sin embargo, cuando se compila con SunCC, el módulo mod_gzip funciona correctamente, por eso, he creado este pequeño post.

Al parecer, el problema viene con la biblioteca expat y cualquier módulo que utilice esta biblioteca, creará un coredump y el servidor nos devolverá una página en blanco <se caerá>. He estado compilando sobre diferentes arquitecturas <SPARC, x86> y, en ambos casos, se producía el mismo error. El servidor funcionaba correctamente hasta que se activaba el módulo mod_gzip

Requisitos
Para poder compilar Apache HTTP Server con SunCC, obviamente, es necesario tener instalado el Sun Studio Developer Tools y para instalarlo, deberemos seleccionar <al igual que con Java> el formato de instalación.

Una vez tengamos instalado nuestro SunCC, debemos incluir el directorio <bin> en nuestro PATH para que encuentre <cc> antes que <gcc>, por ejemplo, podemos editar nuestro .profile para que contenga:
PATH=$PATH:/opt/SUNWspro/bin:/usr/sfw/bin:/usr/ccs/bin:/usr/local/bin
export PATH
Comprobamos que tenemos el entorno correcto, como podéis comprobar, yo tengo la versión 5.9 del Sun Studio Compiler, pero también funciona con la última versión
$ which cc
/opt/SUNWspro/bin/cc
$ which gcc
/usr/sfw/bin/gcc
$ which make
/usr/ccs/bin/make
$ which gmake
/usr/sfw/bin/gmake
$ cc -V
cc: Sun C 5.9 SunOS_i386 Build40_1 2007/02/08
usage: cc [ options] files.  Use 'cc -flags' for details
Instalación de Apache
Vamos a seguir los mismos pasos que realizamos en Compilación de Apache HTTP Server con Mod Security y Mod Bandwidth en 64bit sobre Solaris, pero vamos a modifcar los siguientes valores:
  • En esta ocasión, no será necesario exportar la variable de entorno LD_LIBRARY_PATH
  • Asignaremos el valor de <cc> a la variable CC en el configure en vez de <gcc>
Una vez descargado y descomprimido el servidor, podemos comenzar a configurarlo con los siguientes valores:
$ export CC="cc"
$ export CFLAGS="-O2 -m64"
$ ./configure \
      "--with-layout=Apache" \
      "--enable-module=rewrite" \
      "--enable-module=expires" \
      "--enable-module=headers" \
      "--enable-module=mmap_static" \
      "--add-module=src/modules/extra/mod_bandwidth.c" \
      "--permute-module=BEGIN:bandwidth" \
      "--activate-module=src/modules/extra/mod_security" \
      "--enable-module=security" \
      "--disable-module=status" \
      "--enable-module=so" \
      "--prefix=/opt/www/64/apache-1.3.41" \
     "$@"
Una vez configurado, haremos un <make> y <make install> para finalizar la instalación.

Conclusiones
Después de horas de pruebas, no pude más que llegar a la conclusión de que el bug de GCC es más molesto de lo que a simple vista puede parecer. El problema no es que no se pueda solucionar, sino que como se produce en tiempo de ejecución, puede darse con cualquier módulo que instales y, por lo tanto, deje de funcionar tu servidor http.

Compilar Apache HTTP Server, Mod_JK, Mod_Gzip y los demás módulos necesarios para nuestro servidor Web, no suelen suponer mayor problema hacerlo con GCC o con SunCC, y por lo tanto, ahora que SunCC es free es una opción alternativa.

En el siguiente post veremos Cómo compilar Mod Gzip en Apache 1.3.41 64bits con SunCC en Solaris 10

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

jueves, 10 de diciembre de 2009

Instalar Java 6 en Solaris 10 64bits

Introducción
La 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 process
all 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 sh
Este 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.sh
Ya tenemos concluida la instalación de Java.

Hacer esta versión por defecto
Una 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/java
lrwxrwxrwx   1 root     other         16 sep  2  2008 /usr/bin/java -> ../java/bin/java
# ls -l /usr/java
lrwxrwxrwx   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)
Conclusiones
En 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)

Referencias

lunes, 7 de diciembre de 2009

Problemas Compilación GCC Solaris 64bits Apache Mod_JK

Introducción
Compilar Apache 1.3.41 en 64bits en Solaris con GCC puede darnos algún que otro problema cuando empecemos a incluir módulos como mod_jk, mod_gzip, principalmente debido a un problema de configuración predeterminada en la compilación del binario de gcc que viene con Solaris. Este problema es que tiene asignado como Runtime Library Search Path (-rpath) /usr/sfw/lib y por lo tanto, cuando utilizamos el modificador -m64 para crear binarios de 64bits

En los post sobre Compilación de Apache 1.3.41 en 64bits hemos solucionado el problema asignando el valor de la variable LD_LIBRARY_PATH_64 a </usr/sfw/lib/64>, aunque no está mal, existe otra solución para evitar tener que estar asignando la variable en cada ejecución. Durante la compilación de Apache, podemos asignar Runtime Library Search a </usr/sfw/lib/64> a LDFLAGS, de esta forma el linker incluirá en sus search path la ruta de 64 en vez de la de 32, veamos un ejemplo:

Compilaremos Apache con los siguientes parámetros, fijaros que en esta ocasión hemos incluido LDFLAGS además de CFLAGS
CFLAGS="-m64 -O2" \
LDFLAGS="-R/usr/sfw/lib/64" \
./configure \
"--with-layout=Apache" \
"--enable-module=rewrite" \
"--enable-module=expires" \
"--enable-module=headers" \
"--enable-module=mmap_static" \
"--add-module=src/modules/extra/mod_bandwidth.c" \
"--permute-module=BEGIN:bandwidth" \
"--activate-module=src/modules/extra/mod_security" \
"--enable-module=security" \
"--enable-module=status" \
"--enable-module=so" \
"--prefix=/opt/www/apache-1.3.41/64" \
"$@"
Compilaremos como siempre nuestro Apache 1.3.41 y lo instalaremos. Ahora vamos a comprobar cómo sin establecer la variable LD_LIBRARY_PATH_64 el binario <httpd> encuentra correctamente las bibliotecas de 64bits de <sfw>
$ echo $LD_LIBRARY_PATH

$ echo $LD_LIBRARY_PATH_64

$ ldd httpd 
        libsocket.so.1 =>        /usr/lib/64/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/64/libnsl.so.1
        libpthread.so.1 =>       /usr/lib/64/libpthread.so.1
        libexpat.so.1 =>         /usr/sfw/lib/64/libexpat.so.1
        libc.so.1 =>     /usr/lib/64/libc.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libmd.so.1 =>    /lib/64/libmd.so.1
        libscf.so.1 =>   /lib/64/libscf.so.1
        libdoor.so.1 =>  /lib/64/libdoor.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libgen.so.1 =>   /lib/64/libgen.so.1
        libm.so.2 =>     /lib/64/libm.so.2
Ahora bien, continuando con la compilación de los módulos, nos encontramos con el problema añadido de MOD_JK. La compilación de mod_jk utilizando APXS, se realiza de la siguiente forma, recordar que mod_jk se compila con GNU Make <gmake>
$ CFLAGS="-m64 -O2" ./configure --with-apxs=/opt/www/apache-1.3.41/64/bin/apxs
$ gmake
Durante el proceso de link, se produce el siguiente error
ld: error fatal: archivo .libs/mod_jk.o: clase ELF incorrecta: ELFCLASS64
ld: error fatal: Errores en el proceso de archivos. No se escribir? la salida en .libs/mod_jk.so.0.0.0
collect2: ld returned 1 exit status
Esto es debido a que no hemos incluido el flag -64 para que el linker cree una <so> de 64bits, así que vamos a incluir los siguientes flags,
$ CFLAGS="-m64 -O2" LDFLAGS="-64 -R/usr/sfw/lib/64" ./configure --with-apxs=/opt/www/apache-1.3.41/64/bin/apxs
$ gmake
Ahora durante el proceso de link, se produce ahora un nuevo error,
ld: error fatal: archivo /usr/lib/crti.o: clase ELF incorrecta: ELFCLASS32
ld: error fatal: Errores en el proceso de archivos. No se escribir? la salida en .libs/mod_jk.so.0.0.0
collect2: ld returned 1 exit status
gmake[1]: *** [mod_jk.la] Error 1
Esto se debe a que el configurador no asigna correctamente el flag -m64 a la variable MOD_LINK del archivo Makefile, para ello, editaremos el archivo que se encuentra en $MOD_JK_HOME/native/apache-1.3 y sustituiremos el valor de MOD_LINK
MOD_LINK   = $(LIBTOOL) --mode=link $(CC)  -Wl,-G -Wl,-64 -Wl,-R/usr/sfw/lib/64
por el siguiente valor
MOD_LINK   = $(LIBTOOL) --mode=link $(CC)  -Wl,-G -Wl,-64 -Wl,-R/usr/sfw/lib/64 -m64
Una vez hecho esto, volvemos a compilar el mod_jk, y comprobaremos que todo está correcto.

$ gmake clean all

$ cd apache-1.3/.libs/
$ file mod_jk.so
mod_jk.so:      ELF 64 bits LSB biblioteca dinámica AMD64 Versión 1, enlazado dinámicamente, no quitado, no hay información de depuración disponible
$ ldd mod_jk.so
        libc.so.1 =>     /lib/64/libc.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/64/libgcc_s.so.1
        libm.so.2 =>     /lib/64/libm.so.2
Ya sólo nos quedaría instalar el módulo con <gmake install> y listo


Conclusiones

En esta ocasión hemos visto solventar pequeños problemas de compilación con GCC en Solaris 10 x64 y cómo con algunos cambios en la configuración podemos hacer que nuestro Apache 1.3.41 y Mod_JK compilen.

Recordar que hemos realizado la compilación y las pruebas en Solaris 10 x86_64, y que para SPARC 64bits el directorio </usr/sfw/lib/64> es un link </usr/sfw/lib/sparcv9> y por lo tanto, las opciones del linker funcionarán también en SPARC, sin embargo, si utilizamos Sun CC como compilador, no será necesario realizar estos pasos, ya que no existe ese Bug.

Referencias

miércoles, 2 de diciembre de 2009

Instalación de PostgreSQL 8.4 en Solaris 10 64bits - Parte 2

Introducción
En la primera parte de Instalación de PostgreSQL en Solaris 10, vimos como realizar los primeros pasos e iniciar la base de datos de PostgreSQL. En esta ocasión, vamos a ver cómo podemos utilizar el framework SMF para poder gestionar el inicio/parada/reconfiguración de PostgreSQL 8.4 utilizando los comandos svcadm enable/disable/restart

UPDATED: Si quieres puedes ir a Cómo Instalar PostgreSQL 9.x en OpenIndiana, un post más actualizado sobre el proceso de instalación en el nuevo sistema operativo sucesor de OpenSolaris

Un Recordatorio Rápido
Solaris 10 tiene incluida las versione 8.1 y 8.3 de PostgreSQL en su core por eso, para comprobarlo realizaremos los siguientes pasos:
# which psql
/usr/bin/psql
# /usr/bin/psql --version
psql (PostgreSQL) 8.1.17
incluye soporte para edición de línea de comandos
En esta instalación de Solaris, el binario de psql es de la versión 8.1.17, por eso asignábamos en el profile del usuario postgres su PATH como $POSTGRES_HOME/bin en primer lugar, vamos a comprobarlo ahora desde el usuario postgres
# su - postgres
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005

POSTGRES VERSION: 8.4
POSTGRES HOME   : /u01/app/postgres/8.4/db
PGDATA          : /var/postgres/8.4/data
PGARCH          : 64
$ which psql
/u01/app/postgres/8.4/db/bin/64/psql
$ psql --version
psql (PostgreSQL) 8.4.1
incluye soporte para edición de línea de órdenes
Una vez verificado aclarado el tema de las versiones y la importancia de asignar correctamente el PATH, PGDATA y POSTGRES_HOME, continuaremos

Creación del Archivo de descripción (Manifest)
Como hemos comentado, Solaris ofrece soporte para PostgreSQL y por ello, en el directorio /var/svc/manifest/application/database podemos encontrar los manifest para PostgreSQL 8.1,8.2 y 8.3. Éstos son dependientes del Sistema Operativo, y por lo tanto, no podemos modificar la estructura ya que al actualizar mediante algún parche, ésta puede ser modificada sin previo aviso, como indica el comentario del xml
NOTE:  This service manifest is not editable; its contents will
be overwritten by package or patch operations, including
operating system upgrade.  Make customizations in a different
file.
Así que para evitar sorpresas vamos a utilizar el manifest de PostgreSQL 8.3 y vamos a crearnos uno nuevo postgresql_84 en el cual podamos hacer nuestros ajustes sin temor a que en un parche nos modifiquen los descriptores.

Preparación del Entorno para SMF
Vamos a crear el descriptor postgresql_8.4.xml utilizando el archivo postgresql_83.xml y modificaremos las entradas que hagan referencia a <postgresql_83> por <postgresql_84>, posteriormente crearemos un nuevo method de ejecución partiendo de /lib/svc/method/postgres_83, veamos los pasos:
# cd /var/svc/manifest/application/database/
# cat postgresql_83.xml > postgresql_84.xml
# vi postgresql_84.xml 

     :%s/postgresql_83/postgresql_84/
     :%s/postgres_83/postgres_84/
Deberemos sustiuir los valores de <property_group> en ambas instancias, es decir <default_64bits> y <default_32bits> por los siguientes:
  • Propiedad <bin> /u01/app/postgres/8.4/db/bin para 32bits y /u01/app/postgres/8.4/db/bin/64 para 64bits
  • Propiedad <data> /var/postgres/8.4/data
  • Propiedad <log> /var/log/postgres/server.log
Desde aquí puedes descarte el archivo completo de PostgreSQL Manifest

Ahora vamos a hacer lo mismo con el archivo method, partiendo de /lib/svc/method/postgres_83 y sustituyendo las entradas de postgresql_83 por postgresql_84
# cat /lib/svc/method/postgres_83 > /lib/svc/method/postgres_84
# chmod +x /lib/svc/method/postgres_84
# chown root:bin /lib/svc/method/postgres_84
El métdodo start vamos a modificarlo para asignar el path del archivo de log de forma absoluta en vez de relativa a PGDATA como está en Solaris, por lo tanto, nuestro método quedaría así
case "$1" in
'start')
        check_data_dir
        $PGBIN/pg_ctl -D $PGDATA -l $PGLOG start
        ;;
Desde aquí puedes descargarte el archivo completo PostgreSQL Method

Importación y Activación del Nuevo Servicio
Vamos a importar el nuevo manifest utilizando svccfg como en otras ocasiones y para comprobarlo svcs <frmi>
# svccfg
svc:> validate /var/svc/manifest/application/database/postgresql_84.xml
svc:>  import /var/svc/manifest/application/database/postgresql_84.xml
svc:> quit
# svcs postgresql_84
STATE          STIME    FMRI
disabled       12:20:05 svc:/application/database/postgresql_84:default_64bit
disabled       12:20:05 svc:/application/database/postgresql_84:default_32bit
Activamos el servicio y comprobamos el archivo de log de PostgreSQL que hemos ubicado en /var/log/postgres
# svcadm enable postgresql_84:default_64bit
# svcs postgresql_84:default_64bit
STATE          STIME    FMRI
online         12:27:59 svc:/application/database/postgresql_84:default_64bit
# tail -f /var/log/postgres/server.log
LOG:  el sistema de bases de datos fue apagado en 2009-12-01 23:45:10 CET
LOG:  lanzador de autovacuum iniciado
LOG:  el sistema de bases de datos está listo para aceptar conexiones
^C
Comprobamos que nuestro servidor funciona correctamente, para ello, nos conectaremos con el cliente de PostgreSQL del sistema, recordar la primera parte sobre las versiones.

# psql -U postgres
Contraseña para usuario postgres:
Bienvenido a psql 8.1.17 (servidor 8.4.1), la terminal interactiva de PostgreSQL.

Digite:  \copyright para ver los términos de distribución
       \h para ayuda de comandos SQL
       \? para ayuda de comandos psql
       \g o or termine con punto y coma para ejecutar una consulta
       \q para salir

ATENCION:  usted está conectado a un servidor con versión major 8.4,
pero su cliente psql es versión major 8.1.  Algunos comandos backslash,
tales como \d, pueden no funcionar adecuadamente.

postgres=# \q

Nota Importante Sobre el Manifest
El archivo postgresql_84.xml que hemos editado comparte $PGDATA esto es debido a que yo personalmente sólo utilizo una de las dos versiones en la misma máquina, es decir, o la de 32bits o la de 64bits. Si quieres tener ese funcionamiento, debes tener dos PGDATA uno para 32 y otro para 64


<< Cómo Instalar PostgreSQL 8.4 64bits en Solaris 10 - Parte 1

Conclusiones
Hemos visto como Solaris nos proporciona gran parte del trabajo para incluir PostgreSQL en nuestro sistema de control SMF con una pequeña adaptación y por supuesto, ya tenemos la gestión de arranque y parada unificada utilizando svcadm


En las siguientes entregas vamos a ver cómo continuar con la configuración de PostgreSQL en temas de WAL, Backup and Recovery, hasta entonces ... toca esperar



Referencias