SafeChildren Banner

Havoc Oracle Solaris Experts

lunes, 30 de noviembre de 2009

Cálculo de Rendimiento de Apache 1.3.41 64bits vs 1.3.41 32bits en Solaris 10

Introducción
Continuando con la serie de Optimización de Páginas Web en Solaris, en esta ocasión vamos a ver qué diferencias de rendimiento podemos tener con la versión compilada de Apache 1.3.41 en 64bits y en 32bits, para ello continuaremos desde el punto anterior de Compilación de Apache 1.3.41 64bits en Solaris

Para ello, vamos a configurar solo el valor de la propiedad <Listen> del archivo de configuración $APACHE_HOME/conf/httpd.conf

Definición de las métricas de la prueba
Para realizar la prueba de rendimiento se han utilizado tres versiones de Apache HTTP 1.3.41 en Solaris x86_64 sobre una máquina virtual en MacOS X. Los detalles de la configuración son los siguientes:
  • Host: Virtual Box 3.0.10 r54097 Sobre MacOS X
  • Guest:  Solaris 10 10/09 s10x_u8wos_08a X86
  • Memoria: 2048 Megabytes
  • Versión Apache: Apache 1.3.41
Opciones de Compilación de Apache
He realizado tres compilaciones, dos en 32 bits y una en 64bits con los siguientes parámetros:
  • 32bits sin Opciones:
./configure \
"--with-layout=Apache" \
"--enable-module=rewrite" \
"--enable-module=expires" \
"--enable-module=headers" \
"--enable-module=mmap_static" \
"--enable-module=rewrite" \
"--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/32/apache-1.3.41" \
"$@"
  • 32bits Configure con CFLAGS="-O2"
CFLAGS="-O2" \
./configure \
"--with-layout=Apache" \
"--enable-module=rewrite" \
"--enable-module=expires" \
"--enable-module=headers" \
"--enable-module=mmap_static" \
"--enable-module=rewrite" \
"--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/32/apache-1.3.41" \
"$@"
  • 64bits Configure con CFLAGS="-m64 -O2"
CFLAGS="-O2 -m64" \
./configure \
"--with-layout=Apache" \
"--enable-module=rewrite" \
"--enable-module=expires" \
"--enable-module=headers" \
"--enable-module=mmap_static" \
"--enable-module=rewrite" \
"--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" \
"$@"
Herramientas de Testing
Se han utilizado las herramientas de Apache Benchmark, que se encuentra en $APACHE_HOME/bin/ab y Apache JMeter. Para hacer una prueba más realista se han realizodo tres métricas con Apache Benchmark (una detrás de otra), y se ha calculado la media con los datos de conexión, rendimiento, etc. La definición de los parámetros son los siguientes:
  • Apache Benchmark (32bits)
$ /opt/www/32/apache-1.3.41/bin/ab -n 10000 -c 15 http://localhost:8000/
  • Apache Benchmarck (64bits)
$ /opt/www/apache-1.3.41/bin/ab -n 10000 -c 15 http://localhost:8080/
  • Apache JMeter (32bits y 64bits)
Número de Hilos: 15
Contador del Bucle: 10000
Resultados Obtenidos
A continuación vamos a ver los gráficos de resultados de las pruebas de Apache Benchmark (recordar que se han realizado tres métricas y luego la media)

Apache 1.3.41 32bits sin Optimizaciones


Apache 1.3.41 32bits con Optimización -O2


Apache 1.3.41 64bits con Optimización -O2 -m64


Comparativa de las tres gráficas: 32 vs 32plus v2 64


Resultados de JMeter 32bits



Resultados de JMeter 64bits


Conclusiones
Aunque este test es bastante sencillo, podemos ver como la compilación en 64bits de Apache nos proporciona un mayor rendimiento, además, con el simple hecho de incluir <-O2> ya obtenemos una mejoría con la configuración por defecto.

Esto, que a simple vista es obvio, puede hacernos ver la importancia de compilar nuestros aplicativos en la arquitectura en la que queramos ejecutarlo, y en la medida de lo posible, evitar los paquetes precompilados para los entornos de producción.

En la siguiente entrega, veremos cómo podemos ir configurando Apache HTTP Server para obtener mayor rendimiento utilizando mod_expires y mod_gzip.

Referencias

viernes, 27 de noviembre de 2009

Compilar Apache 1.3.x Solaris 64bit con mod_bandwidth y mod_security

Introducción
Vamos a ver cómo podemos compilar la versión 1.3.41 de Apache HTTP Server en Solaris 10 en 64bits. La compilación en 64bits no es muy diferente de la de 32bits, realmente es introducir el modifcador -m64 en los flags de CC, sin embargo, si utilizamos módulos adicionales como(mod_bandwidth, mod_security, etc.  debemos incluir las bibliotecas de 64bits de /usr/sfw en nuestro LD_LIBRARY_PATH_64

Si recordais la Instalación de MemCached en 64bits sobre Solaris, también teníamos que adaptar las variables de LD_LIBRARY_PATH, tanto la de 32bits como la de 64bits, en la instalación de Apache HTTP Server ocurre lo mismo.

Módulos Adicionales
En esta ocasión vamos a instalar dos módulos adicionales dentro del core del servidor Apache
  • mod_bandwidth, nos permite establecer usos de ancho de banda por dominio, ip, usuario
  • mod_security, firewall capa 7 (Firewall de aplicación)
Además, vamos a habilitar los módulos de rewrite, headers, expires y so, este último para poder compilar el módulo jk que nos permite unir Apache HTTP Server con Apache Tomcat

Instalación de Módulos Adicionales
Para que podamos instalar los módulos dentro del core debemos copiar los mod_XXX.c al directorio $APACHE_HOME/src/modules/extra y de esta forma, podemos activarlos en la configuración.

Descargamos el source de Apache HTTP Server 1.3 y lo descomprimimos en $HOME/Apache
$ mkdir ~/Apache
$ cd  ~/Apache
$ wget http://apache.rediris.es/httpd/apache_1.3.41.tar.gz
$ gtar zxpf apache_1.3.41.tar.gz
Hay que tener en cuenta que la versión de mod_security para Apache HTTP Server 1.3.x es la 1.9.5, a partir de esta versión, son sólo para Apache HTTP Server 2.x, (aqui tienes un acceso director ala descarga de mod_security)
$ wget http://downloads.sourceforge.net/project/mod-security/modsecurity-apache/1.9.5/modsecurity-apache_1.9.5.tar.gz?use_mirror=ovh
$ gtar zxpf modsecurity-apache_1.9.5.tar.gz
$ cd modsecurity-apache_1.9.5/apache1/
$ cp mod_security.c ~/Apache/apache_1.3.41/src/modules/extra/
Descargar e Instalar mod_bandwidth
$ wget ftp://ftp.cohprog.com/pub/apache/module/1.3.0/mod_bandwidth.c
$ cp mod_bandwidth.c  ~/Apache/apache_1.3.41/src/modules/extra/
Compilación de Apache
Una vez preparado el source de Apache, vamos a compilarlo utilizando los modificadores -m64 como hemos comentado al principio. Recordar que debemos establecer la variable LD_LIBRARY_PATH_64 para que nos encuentre las bibliotecas correctas.
$ export LD_LIBRARY_PATH_64=/lib/64:/usr/lib/64:/usr/sfw/lib/64:/usr/ccs/lib
$ CC="gcc" \
   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/apache-1.3.41" \
     "$@"
Instalación y Verificación de la Instalación
Si todo ha compilado correctamente, podemos hacer una instalación y posteriormente la verificación con ldd, para instalar simplemente haremos
# make install
Y para verificar que todo está correcto
$ ldd /opt/www/apache-1.3.41/bin/httpd
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libexpat.so.1 =>         /usr/sfw/lib/64/libexpat.so.1
        libc.so.1 =>     /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
Si no establecemos el LD_LIBRARY_PATH_64 el resultado será que intentará enlazar con la versión de 32bits de libexpat.so.1
# ldd /opt/www/apache-1.3.41/bin/httpd
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libexpat.so.1 =>         /usr/sfw/lib/libexpat.so.1 - clase ELF incorrecta: ELFCLASS32
        libc.so.1 =>     /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
Editar la Configuración del Servidor
Una vez tengamos nuestro servidor instalado y verificado, podemos comenzar a configurarlo.

Conclusiones
Hemos visto cómo instalar la versión de 64bits de Solaris con los módulos mod_security y mod_bandwidth que nos permiten establecer un Firewall de Capa 7 y un control de la tasa de transferencia.

Con estos módulos cargamos, podemos comenzar con la configuración de nuestro servidor Apache que utilizaremos en los ejemplos de Optimización de Aplicativos Web en Solaris.

En la siguiente entrega, comenzaremos con los parámetros de configuración del archivo $APACHE_HOME/conf/httpd.conf


Referencias

jueves, 26 de noviembre de 2009

Eliminar Unknown hostname Solaris 10

Introducción
Hace un tiempo explicaba cómo Eliminar "Unknown Hostname" pero en Solaris 9, bien, ahora toca el turno de Solaris 10

En Solaris 10, simplemente debemos establecer el valor de /etc/nodename y Solaris se encargará de asignar ese valor a nuestro Host.
# echo "zooey" > /etc/nodename
Una vez rebotado el sistema, veremos como en el archivo /etc/hosts existe una nueva entrada con el comentario de Added by DHCP, en mi caso zooey
# cat /etc/hosts
  #
  # Internet host table
  #
  ::1     localhost      
  127.0.0.1       localhost      
  10.0.2.15      zooey    # Added by DHCP

Conclusiones
Esta vez, en Solaris 10 todo es mucho más sencillo y rápido, aunque siempre puedes utilizar el antiguo método si quieres ...


Referencias

martes, 24 de noviembre de 2009

Cálculo de Rendimiento utilizando Apache JMeter - Parte 1

Instalación
En este primer post vamos a ver cómo utilizar JMeter para establecer un "Base Time Line" para nuestros cambios de configuración.

Apache JMeter es un aplicativo diseñado para obtener métricas de rendimiento de una forma automática y repetible. Ésto que parece no es muy importante, sí que lo es. Una de las cosas que debemos eliminar de nuestro vocabulario cuando empecemos a realizar pruebas de carga son: "parece que, más rápido, más lento, ..." todas estas expresiones no nos sirven ya que dependen de muchos factores, aunque el mayor problema es que son subjetivas y dependientes de una/varias personas.

JMeter nos ofrece datos "la página tarda 2,7 seg" ya no depende de si es "rápido" o "lento" son "2,7 seg", si hacemos un cambio y JMeter ofrece "2,9 seg", el cambio hace que el sistema responda más lento.

Debemos tener en cuenta que JMeter no es un navegador y por lo tanto, no va a procesar los código JavaScript, me explico, JMeter no va a procesar los document.write del código HTML. Por ejemplo, el siguiente bloque de código no será interpretado por JMeter y por lo tanto, las latencias de render no se computarán.
<script type='text/javascript'>new BannerManager('http://openads.test.com/').getBanner(106,'banner106',true,-1,false,'null');script>
<script type='text/javascript'>new BannerManager('http://openads.test.com/').getBanner(107,'banner107',true,-1,false,'null');script>
  
<script type="text/javascript">
     var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
     document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
script>
Una vez aclarado el funcionamiento de JMeter, vamos a ver cómo configurar una batería de pruebas para simular el acceso a nuestras webs.

Instalación de JMeter
JMeter es una aplicación Java y necesita de JVM 1.5+ para poder ejecutarse. La instalación simplemente es descomprimir el archivo tar.gz en la ubicación que nosotros queramos ($JMETER_HOME)

Lanzar JMeter
Antes de lanzar JMeter vamos a analizar si las pruebas que vamos a llevar a cabo van a ser muy complejas, ya que si así fuera, necesitaremos ampliar la memoria asignada por defecto a JMeter.

JMeter se inicia con un tamaño máximo de memoria de 512Mb, y aunque en la mayoría de los casos es suficiente, yo suelo configurarlo para que abra con 1024Mb.

Para modificar el parámetro de memoria, simplemente incluiremos una variable de entorno llamada JVM_ARGS donde se le asignan los parámetros de la máquina virtual, por ejemplo
$ export JVM_ARGS="-server -Xms1024m -Xmx1024m"
$ jmeter.sh
También podemos editaremos el archivo $JMETER_HOME/bin/jmeter y cambiar el valor de HEAP para asignarle los valores que deseemos, en mi caso 1024m
# This is the base heap size -- you may increase or decrease it to fit your
# system's memory availablity:
HEAP="-Xms1024m -Xmx1024m"
Una vez configurado nuestro JMeter, ejecutaremos el script de arranque $JMETER_HOME/bin/jmeter.sh y se nos mostrará nuestro entorno de trabajo que se ve a continuación



Como podemos observar, JMeter nos ofrece dos categorías dentro del árbol principal
  • Plan de Pruebas
  • Banco de Trabajo
En esta primera parte, vamos a ver cómo configurar un nuevo plan de pruebas, y en la segunda parte veremos cómo podemos utilizar el Banco de Trabajo


Nota: En JMeter no existe el botón Guardar y por lo tanto, cuando hagamos un "Focus Lost" del componente éste quedará guardado.

Configurar un Nuevo Plan de Pruebas
Lo primero que debemos hacer es añadir un Grupo de Hilos, para ello seleccionaremos Plan de Pruebas y haciendo click con el botón derecho Añadir->Grupo de Hilos. Esto representará a nuestros usuarios, es decir, si queremos comprobar cómo responde nuestro aplicativo con 50 usuarios concurrentes, en la propiedad Número de Hilos deberemos poner 50.

Para establecer un Base Time Line debemos establecer el valor de Número de Hilos a 1, y Contador del Bucle a un valor superior a 1, de esta forma, podemos obtener la media de ejecución con un sólo usuario y, de esta forma, tomaremos este dato como nuestro punto de partida.
Cuanto mayor sea el valor de Contador del Bucle mejor será la precisión, ya que obtendremos más muestras y por lo tanto la media será más realista.

Ahora seleccionaremos nuestro Grupo de Hilos y con el botón derecho Añadir->Elementos de Configuración->Valores por Defecto para Petición HTTP. Esto nos permitirá incluir los valores generales de la petición como: Nombre del Servidor, Puerto, Protocolo y Encoding.

 Seleccionamos Grupo de Hilos y con el botón derecho Añadir->Muestreador->Petición HTTP y, como hemos introducido Valores por Defecto simplemente deberemos editar el valor de la propiedad Path.

Por último, introduciremos un Listener que nos proporcionará los valores de la muestra, en este primer ejemplo vamos a introducir un Árbol de Resultados, para ello, seleccionaremos Grupo de Hilos y botón derecho Añadir->Listener->Ver Árbol de Resultados

Ya sólo nos queda guardar la prueba, Archivo->Guardar Como ... y podemos ejecutarla utilizando el menú Lanzar->Arrancar y ver el resultado en Ver Árbol de Resultados.

Como podéis ver, el funcionamiento de JMeter es sencillo y la creación de planes de pruebas no es muy complicado, en cuatro clicks hemos obtenido un plan de pruebas, sin embargo la información que obtenemos con este Sencillo Plan no nos aporta mucho, vamos a ver cómo hacer un plan más realista. Podéis descargar esta prueba sencilla de JMeter HTTP

Instalar nuevo Listener

Antes de comenzar con el plan de pruebas vamos a instalar un Listener que nos mostrará de forma gráfica, y más amena, el rendimiento y tiempo de respuesta de nuestro muestreador. Para ello, debemos descargar e instalar Better JMeter Graphs, después reiniciaremos el JMeter. Una vez hecho esto, tendremos un nuevo Listener llamado Statistical Aggregate Report

Configurar un Plan de Pruebas Más "Complicado"
Al igual que hemos hecho en la Prueba Sencilla de JMeter para HTTP añadiremos un Grupo de Hilos, añadiremos también Valores por Defecto para Petición HTTP, ahora viene algún cambio, seleccionamos Grupo de Hilos y con el botón derecho Añadir->Elemento de Configuración->Gestor de Cookies HTTP.

Los usuarios no hacen siempre las mismas iteraciones, es decir, Home->Pagina1->Pagina2->Home, y por lo tanto, si queremos hacer un plan de prueba que pueda simular  a un usuario, debemos tener en cuenta esto, por ello, JMeter nos ofrece el Controlador Lógico Random Order, así que seleccionamos Grupo de Hilos y con el botón derecho del ratón Añadir->Controlador Lógico->Random Order.

Ahora vamos a introducir los muestreadores HTTP dentro de nuestro controlador lógico, para ello, seleccionamos Controlador Random Order y con botón derecho Añadir->Muestreador->Petición HTTP y aquí pondremos la primera página. Deberemos repetir este proceso para todas las páginas que queremos muestrear.

Por último, vamos a añadir nuestro Listener seleccionando Grupo de Hilos y con el botón derecho Añadir->Listener->Statistical Aggregate Report, guardamos la prueba y ejecutamos. Podéis descargar la Prueba JMeter HTTP Multiples Páginas


Conclusión
En esta primera parte hemos visto cómo movernos con JMeter y las opciones que nos aporta, además, tenemos el resultado en formato gráfico al incluir el listener alternativo.

En la siguiente parte, veremos cómo podemos crear pruebas mucho más complejas y cómo establecer valores de control en los muestreadores

Referencias

domingo, 22 de noviembre de 2009

Optimización de Aplicaciones Web en Solaris

Introducción
En esta serie de post's vamos a ver cómo podemos exprimir al máximo nuestros servidores Solaris, y con el apoyo de los programadores hacer que el rendimiento de nuestras aplicaciones Web se vea mejorado.

Antes de comenzar, debemos hablar de las capas de optimización (tuning) que existen y la importancia de cada una.


Uno de los errores mas comunes es creer que cambiando el Hardware se conseguirá el mayor rendimiento, por ejemplo, si tenemos una CPU cargada, se pone más CPU (por ejemplo el doble, pasamos de 4 a 8 CPU) y se espera que el rendimiento aumente en relación al incremento de potencia, ERROR.

La capa HARDWARE es la que menos relación COSTE-RENDIMIENTO nos va a ofrecer, entonces por qué empezamos por el HARDWARE? Buena pregunta, la respuesta es muy sencilla: Es el cambio que menos trauma supone a los desarrolladores, y por lo tanto a los aplicativos. Si, es cierto, todos nos hemos encontrado en la situación de:

Como arquitecto le explicas:
  • "Necesito que cambies la aplicación X para que haga Z y reduzcas el número de llamadas a DB haciendo F"
Y la respuesta desde desarrollo es:
  • "Imposible, tenemos que tocar F,G,H, … mucho, mucho. Eso es problema de la máquina, el Software está súper optimizado"
Bien, vamos a ver cómo podemos enfrentarnos a estas situaciones y salir airoso de ellas siguiendo unas pautas y mejoras en nuestras arquitecturas.

En el primer post de la serie comenzaremos hablando de Cálculo de Rendimiento utilizando Apache JMeter y seguiremos con Parametrización de Apache para Cacheo de contenido, espero que os guste y mañana comenzaremos esta nueva serie.

jueves, 19 de noviembre de 2009

Cómo poner el usuario y directorio actual en Bash sobre Solaris

Introducción
En Solaris el formato de PS1 es, y ha sido siempre, el standard de UNIX, es decir, <$> para usuarios y <#> para root.

Para aquellos que vienen de Linux, se encuentran que el formato típico es <USUARIO@HOST:PWD> y encuentran poco intuitivo el "nuestro".

Esto tiene una sencilla solución, establecer la variable de entorno PS1 con los siguientes valores para la shell bash en nuestro .profile. Si queremos seguir el mismo formato que tiene Linux, utilizaremos \u para el usuario \h para Host y \w para el directorio actual.

Vemos un ejemplo,
$ vi ~/.profile
   ## ASIGNAMOS UN PS1
   PS1="\u@\h:\w > "
   export PS1

:wq

$ . ~/.profile
postgres@test.db.test.com:~ >
Si quisieramos hacer esto para todos los usuarios, podemos editar el archivo /etc/profile el cual se lee por todos los usuarios (aunque yo no lo recomiendo)

Referencias

miércoles, 18 de noviembre de 2009

Cómo compilar los objectos en Oracle

Introducción
Vamos a ver qué objetos tenemos inválidos en Oracle, para ello vamos a consultar el estado y comparándolo con INVALID.
SQL> SELECT OWNER, OBJECT_NAME, OBJECT_TYPE FROM ALL_OBJECTS WHERE STATUS = 'INVALID'
Los objetos que podemos compilar son  <Vista, Package, Package Body, Function> y su formato es el siguiente:
ALTER <OBJECT_TYPE> COMPILE
Por ejemplo, si queremos compilar una vista llamada TEST_VIEW del schema TEST haremos lo siguiente
SQL> ALTER VIEW TEST.TEST_VIEW COMPILE;
Si queremos compilar el <package> TEST_PKG  del schema TEST haremos lo siguiente
SQL> ALTER PACKAGE TEST.TEST_PKG COMPILE;
Si queremos compilar el <package body> deberemos incluir la palabra  BODY en la instrucción de compilación del paquete, por ejemplo
SQL> ALTER PACKAGE TEST.TEST_PKG COMPILE BODY;
Si queremos compilar una <function> debemos hacer los siguiente
SQL> ALTER FUNCTION TEST.GET_CCID COMPILE;
Por útlimo, si durante la compilación se han producido errores, podemos utilizar para ver el detalle, por ejemplo
SQL> ALTER FUNCTION TEST.GET_CCID COMPILE;

Warning: Function altered with compilation errors.

SQL> SHOW ERRORS;
Errors for FUNCTION TEST.GET_CCID:

LINE/COL ERROR
-------- -----------------------------------------------------------------
37/5     PL/SQL: Statement ignored
37/5     PLS-00201: identifier 'TEST@TEST_ERP' must be declared
37/5     PLS-00352: Unable to access another database 'TEST_ERP'
SQL>

Referencias

lunes, 16 de noviembre de 2009

Cómo ver el tráfico de red con un sniffer en Solaris

Introducción
Monitorizar el tráfico de red es algo importante y aunque en este tema el rey es Ethereal (WireShark), puede que no nos interese instalarlo, o no podamos.

En Solaris se incluye un comando llamado <snoop> que nos permite poner nuestra tarjeta de red en modo promiscuo, guardarlo en un archivo y posteriormente procesarlo utilizando Wireshark en nuestro desktop.

Wireshark es capáz de interpretar las capturas generadas con el comando <snoop> de Solaris simplemente utilizando la extensión snoop en el archivo de captura.

Hay que tener en cuenta que no podemos poner un alias en modo promiscuo, sino el interface original, por eso si queremos hacerlo sobre una zona no-global y la tarjeta de red no está asignada como exclusive tendremos que hacerlo desde la zona global.

Vamos a ver cómo podemos capturar todo el tráfico de nuestro interface <ce3> y guardarlo en un archivo llamado </tmp/output.snoop> (para detener la captura pulsaremos CTRL+C)

# snoop -d ce3 -o /tmp/output.snoop
Using device /dev/ce3 (promiscuous mode)
1771 ^C
Una vez tengamos nuestro archivo, podemos tratarlo dentro de Wireshark de una forma sencilla.


Referencias

viernes, 13 de noviembre de 2009

Cómo Mover TempFile en Caliente Oracle en Solaris

Introducción
En un post anterior hemos visto Cómo mover un Datafile en Caliente, sin embargo ahora vamos a ver cómo podemos hacer lo mismo con un Tempfile.

Para ello vamos a utilizar el comando <ALTER DATABASE> pero en vez de utilizar <DATAFILE> utilizaremos <TEMPFILE> y, en caso de los tempfiles, no será necesario realizar un RECOVER.

A continuación vamos a ver un ejemplo de como mover el Tempfile TMPUSR01.dbf de /u01/oradata/TEST a /u09/oradata/TEST/TMPUSR09.dbf

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Wed Nov 11 09:51:17 2009

Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.


Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL> ALTER DATABASE TEMPFILE '/u01/oradata/TEST/TMPUSR01.dbf' OFFLINE;

Database altered.

SQL> !mv /u01/oradata/TEST/TMPUSR01.dbf /u09/oradata/TEST/TMPUSR09.dbf
SQL> ALTER DATABASE RENAME FILE '/u01/oradata/TEST/TMPUSR01.dbf' to '/u09/oradata/TEST/TMPUSR09.dbf';

Database altered.

SQL> ALTER DATABASE TEMPFILE '/u09/oradata/HESTIA/TMPUSR09.dbf' ONLINE;

Database altered.

Referencias

jueves, 12 de noviembre de 2009

Instalación de JMemCached sobre Solaris utilizando SMF

Introducción
En artículos anteriores hemos visto Cómo instalar MemCached 64bits en Solaris 10. Bien, ahora vamos a ver cómo podemos instalar JMemCached, que como podeis imaginaros es la Implementación en Java de MemCached.

En este caso vamos a utilizar SMF para gestionar el sistema de cache y, de esta forma, poder tener un control sobre si correcto funcionamiento utilizando los comandos: svcadm y svcs

Para ello, descargamos el manifest, method y lo cargamos en nuestro repositorio, en mi caso /var/svc/manifest/application/cache.

Hay que tener en cuenta que las configuraciones por defecto del archivo de descripción <jmemcached.xml> son las siguientes:
  • HOME: Indica la ubicación de instalación de JMemCached, en mi caso /opt/www/jmemcached
  • PORT: Puerto de escucha de JMemCached, en mi caso 11212
  • JVMARGS: Parámetros de configuración de la JVM, en mi caso -Xms512m -Xmx512 -d64
  • PROJECT: Projecto del sistema, en mi caso cached.jmemcached
  • MEMORY: Memoria asignada a JMemCached <no confundir con memoria de JVM>, en mi caso 256M
  • BINARY: Binario de ejecución, en mi caso jmemcached-cli-0.8-main.jar
Además, el usuario y grupo de ejecución es <www>, por lo tanto, puedes editar aquellos parámetros que desees para adaptarlos a tu configuración. Vamos a ver la instalación paso a paso ...

Añadimos el usuario, grupo y project
# groupadd www
# useradd -s /bin/false -d /dev/null -g www www
# passwd -l www
# projadd -G www cached.jmemcached
Descargamos los manifest y creamos la  estructura de log del method
# cd /var/svc/manifest/application/
# mkdir cache
# cd cache/
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/jmemcached/jmemcached.xml
# cd /lib/svc/method/
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/jmemcached/jmemcached
# mkdir -p /opt/www/jmemcached
# chown www:www /opt/www/jmemcached/
# mkdir -p /var/log/jmemcached/
# chown www:www /var/log/jmemcached
Descargamos JMemCached en /opt/www/jmemcache <home>
# cd /opt/www/jmemcached
# /usr/sfw/bin/wget http://jmemcache-daemon.googlecode.com/files/jmemcached-cli-0.8-main.jar
Cargar y Activar el FRMI
# cd /var/svc/manifest/application/cache
# svccfg
svc:> validate /var/svc/manifest/application/cache/jmemcached.xml
svc:> import /var/svc/manifest/application/cache/jmemcached.xml
svc:> quit
# svcadm enable jmemcached
# svcs jmemcached
STATE          STIME    FMRI
online         19:57:01 svc:/application/cache/jmemcached:jmemcached_main
Comprobación de Funcionamiento
Para comprobar su funcionamiento podemos hacer tanto un ps, como un telnet al puerto que tengamos definido. Además, si hacemos un kill -9 sobre el pid, veremos como SMF se encarga de levantarlo de nuevo.
# svcs jmemcached
STATE          STIME    FMRI
online         19:57:01 svc:/application/cache/jmemcached:jmemcached_main
# svcs -p jmemcached
STATE          STIME    FMRI
online         19:57:01 svc:/application/cache/jmemcached:jmemcached_main
               19:56:59      315 java

Como podemos ver, nuestro proceso de JMemCached tiene 315 como PID, así que si hacemos un ps, podremos verlo
# ps -ef|grep 315
www 315 1 0 19:56:59 ? 0:01 /usr/jdk/instances/jdk1.5.0/bin/sparcv9/java -Xms512m -Xmx512m -jar /opt/www/jmemcached
Conclusiones
La instalación de una aplicación Java utilizando SMF no supone mayores problemas, a excepción del uso de espacios en blanco en los argumentos de la propiedad jvmargs, para ello hemos tenido que utilizar un pequeño ajuste pero convertir los "\" por " " y "'" por "", a continuación vemos la línea que hay que utilizar en el script de inicio

# Patch to Solve multiples ARGS values onto JVMARGS
JMEMCACHED_JVMARGS=`echo $JMEMCACHED_JVMARGS | sed -e 's/"//g' | sed -e 's/\\\//g'`

Espero que esto os permita crear mas servicios utilizando el framework SMF y, perderle el miedo a esta nueva forma de trabajo.

Referencias

miércoles, 11 de noviembre de 2009

Cómo monitorizar el rendimiento del sistema Solaris

Introducción
Solaris nos proporciona un sistema para obtener estadísticas del Sistema utilizando el comando sar de una forma simplificada.

Para activar el sistema de captura simplemente activaremos sar utilizando svcadm en Solaris 10. Esto hará que se creen los informes en el directorio /var/adm/sa con el formato sar[DIA].

Realmente, lo que hace es introducir un crontab en el usuario sys con el comando sar y crea una salida legible a las 18:05 de lunes a viernes. Podemos editar el crontab del usuario sys para poder cambiar el proceso de captura de datos a nuestra mejor opción.

Podemos ver la salida del crontab del usuario sys utilizando el siguiente comando
# crontab -l sys
#ident  "@(#)sys        1.5     92/07/14 SMI"   /* SVr4.0 1.2   */
#
# The sys crontab should be used to do performance collection. See cron
# and performance manual pages for details on startup.
#
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
Como he contado antes, los informes legibles se almacena en el directorio /var/adm/sa/sar[DIA] y los valores de salida de sar se almacenan en /var/adm/sa/sa[DIA]
# pwd    
/var/adm/sa
# ls -l sar*
-rw-r--r--   1 sys      sys      1225615 nov  3 18:05 sar03
-rw-r--r--   1 sys      sys      1225585 nov  4 18:05 sar04
-rw-r--r--   1 sys      sys      1225597 nov  5 18:05 sar05
-rw-r--r--   1 sys      sys      1225599 nov  6 18:05 sar06
-rw-r--r--   1 sys      sys      1225609 nov  9 18:05 sar09
-rw-r--r--   1 sys      sys      1225575 nov 10 18:05 sar10
# more sar10

SunOS sol10-m4000 5.10 Generic_127127-11 sun4u    11/10/2009

08:00:00    %usr    %sys    %wio   %idle
08:20:00       2       1       0      97
08:40:00       8       1       0      91
Para poder activar nuestro sistema de monitorización en Solaris 10, simplemente haremos lo siguiente
# svcs sar
STATE          STIME    FMRI
disabled       oct_20   svc:/system/sar:default
# svcadm enable sar
# svcs sar
STATE          STIME    FMRI
online          9:27:48 svc:/system/sar:default
En Solaris 9 deberemos utilizar el método de editar el crontab del usuario sys y descomentar las líneas, por ejemplo

# crontab -l sys
#ident  "@(#)sys        1.5     92/07/14 SMI"   /* SVr4.0 1.2   */
#
# The sys crontab should be used to do performance collection. See cron
# and performance manual pages for details on startup.
#
# 0 * * * 0-6 /usr/lib/sa/sa1
# 20,40 8-17 * * 1-5 /usr/lib/sa/sa1
# 5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
# export EDITOR=vi
# crontab -e sys
"/tmp/crontabbNa4AY" 8 líneas, 308 caracteres
#ident  "@(#)sys        1.5     92/07/14 SMI"   /* SVr4.0 1.2   */
#
# The sys crontab should be used to do performance collection. See cron
# and performance manual pages for details on startup.
#
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
:wq
Conclusiones
Tanto en Solaris 10 como en las anteriores, es fácil obtener un sistema de monitorización del rendimiento sin tener que hacer mucho scripting y, lo más importante, sin mucho impacto en nuestro sistema.

Referencias


martes, 10 de noviembre de 2009

Cómo desconectar la consola sin ir al prompt

Introducción
Cuántas veces <a mi algunas> estamos conectados por serie a nuestro Solaris y tiramos del cable para desconectarlo. Esto hace que se envíe un send+break y Solaris se ponga en prompt ok> ....

Para evitarlo, simplemente deberemos ejecutar el comando kbd con la opción -a disable de esta forma podemos desconectar el calbe/teclado sin que nos suceda.
# kbd -a disable
Este comando hay que ejecutarlo en la zona global, si intentamos ejecutarlo desde una Zona No Global, se nos muestra el siguiente error
# kbd -a disable
opening the keyboard: No existe tal archivo o directorio
kbd: Cannot open /dev/kbd

Si esto nos parece una opción muy complicada, podemos desactivar la funcionalidad de ABORT editando el archivo /etc/default/kbdfile  y poniendo KEYBOARD_ABORT=false aunque yo no lo recomiendo ya que esto hará que Solaris no acepte los Send+Break de ninguna forma

Referencias

lunes, 9 de noviembre de 2009

Lanzar estadísticas de una tabla en Oracle

Introducción
Para lanzar las estadísticas en Oracle utilizaremos el paquete DBMS_STATS que nos proporciona un método GATHER_TABLE_STATS con el cual podremos obtener las estadísticas de la tabla <TABNAME> del esquema <OWNNAME>

Veamos un ejemplo
$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Tue Nov 3 15:44:15 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.


Conectado a:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL> exec DBMS_STATS.GATHER_TABLE_STATS(TABNAME=>'MI_TABLA',OWNNAME=>'BLOG',CASCADE=>TRUE,ESTIMATE_PERCENT=>10);

Procedimiento PL/SQL terminado correctamente.

SQL>

Referencias

jueves, 5 de noviembre de 2009

Cómo ver cuantos usuarios sin password hay

Introducción
En nuestro camino hacia securizar Solaris, uno de los puntos más importantes son los usuarios. En este pequeño tip vamos a ver cómo podemos localizar aquellas cuentas que no tienen asignada una contraseña, para ello utilizaremos el comando <logins -p>

En nuestro ejemplo, vamos a verificar que no tenemos ninguna cuenta de usuario sin contraseña, posteriormente crearemos un usuario llamado <test> y borraremos la contraseña utilizando el comando <passwd -d>, después volveremos a ejecutar el comando logins para ver el resultado. Finalizaremos borrando la cuenta y dejando el sistema como estaba.
# logins -p
# useradd -s /bin/false -d /dev/null test
# passwd -d test
passwd: información de contraseña cambiada por test
# logins -p
test 106 other 1
# userdel test
# logins -p
#
Referencias

miércoles, 4 de noviembre de 2009

Cómo registrar los login fallidos en Solaris

Introducción
Por defecto, Solaris muestra en la consola los intentos de error fallidos al sistema, así como los accesos de root, sin embargo, no los guarda en un log.

Para activar esta función, simplemente debemos crear el archivo /var/adm/loginlog, entonces Solaris registrará los intentos fallidos a partir del quinto (5)

Es importante crear el archivo con los permisos -rw- -- -- root:sys para que el sistema de log funcione correctamente, veamos un ejemplo
# touch /var/adm/loginlog
# chmod 600 /var/adm/loginlog
# chown root:sys /var/adm/loginlog
Referencias

lunes, 2 de noviembre de 2009

Cómo redimensionar un DataFile en Oracle

Introducción
Si tenemos nuestros datafiles con la opción AutoExtend a OFF, entonces es necesario adaptar el tamaño según las necesidades. Para ello, podemos redimensionar <a mayor tamaño> el datafile utilizando alter database datafile <datafile> resize <nuevo tamaño>

Veamos el ejemplo para redimensionar el datafile CVID01 de 256M a 1024M
$ ls -lh /u05/oradata/TEST_H/CVID01.dbf
-rw-r----- 1 oracle dba 256M oct 29 02:11 /u05/oradata/TEST_H/CVID01.dbf

$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Thu Oct 29 09:13:18 2009

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.


Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL> alter database datafile '/u05/oradata/TEST_H/CVID01.dbf' resize 1024M;

Database altered.

Referencias