SafeChildren Banner

Havoc Oracle Solaris Experts

viernes, 30 de abril de 2010

Instalación de squid como proxy reverso para Apache HTTP

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.

En esta tercera entrega, vamos a utilizar como base un post que escribí sobre Cómo poner Squid Cache como proxy reverso y haremos algunas modificaciones para adaptarlo a nuestras necesidades. Principalmente, modificaremos el inicio de squid-cache para gestionarlo mediante Solaris SMF e incluiremos acl para evitar el acceso al contenido.

Además, con esta entrega ya tenemos todo lo necesario para poner en producción nuestro tomcat de forma correcta.

Instalación de Squid-Cache como Proxy Reverso
Descargaremos la última versión stable de squid-cache en su branch 2.7 y la instalaremos
$ /usr/sfw/bin/wget http://www.squid-cache.org/Versions/v2/2.7/squid-2.7.STABLE9.tar.gz
$ /usr/sfw/bin/gtar zxpf squid-2.7.STABLE9.tar.gz
$ cd squid-2.7.STABLE9
$ export CFLAGS="-m64 -O3"
$ ./configure 
  --prefix=/opt/www/squid-2.7 \
  --with-large-files \
  --with-pthreads \
  --with-maxfd=16000 \
  --disable-internal-dns \
  --enable-large-cache-files \
  --enable-storeio=ufs,aufs \
  --enable-devpoll \
  --enable-x-accelerator-vary \
  --enable-cache-digests \
  --enable-http-violations \
  --enable-snmp
$ make
# make install

Comprobamos que todo está correcto
$ ldd /opt/www/squid-2.7/sbin/squid
        libpthread.so.1 =>       /lib/64/libpthread.so.1
        libmd.so.1 =>    /lib/64/libmd.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        libsocket.so.1 =>        /lib/64/libsocket.so.1
        libnsl.so.1 =>   /lib/64/libnsl.so.1
        libresolv.so.2 =>        /lib/64/libresolv.so.2
        libthread.so.1 =>        /lib/64/libthread.so.1
        libc.so.1 =>     /lib/64/libc.so.1
        libmp.so.2 =>    /lib/64/libmp.so.2
        libscf.so.1 =>   /lib/64/libscf.so.1
        libuutil.so.1 =>         /lib/64/libuutil.so.1
        libgen.so.1 =>   /lib/64/libgen.so.1
        libsmbios.so.1 =>        /usr/lib/64/libsmbios.so.1
$ file /opt/www/squid-2.7/sbin/squid
squid:     ELF 64-bit LSB executable AMD64 Version 1 [SSE2 SSE FXSR CMOV FPU], dynamically linked, not stripped

Configuración Squid-Cache
A continuación vamos a configurar squid-cache para utilizar nuestro syslog y poder gestionarlo a través de Solaris SMF.

Para hacer que squid-cache escriba en el syslog deberemos utilizar las opciones <-s> o, si queremos utilizar una facility diferente <-l facility>, en nuestro caso vamos a utilizar <local6> como nuestra facility
# vi /etc/syslog.conf
   #
   # SQUID Cache
   #
   local6.debug                                    /var/log/squid.log
Nota: recordar que debe ser un "tabulador" el separador entre <local6.debug> y </var/log/squid.log>
# touch /var/log/squid.log
# chmod 600 /var/log/squid.log
# chown root:root /var/log/squid.log
# svcadm restart system-log
A continuación configuraremos nuestro squid-cache para poder gestionarlo mediante Solaris SMF, para ello, deberemos importar el manifest de Squid Cache 2 para Solaris SMF y el method para Squid Cache 2. He creado dos archivos manifest uno con sólo manifest para squid como proxy reverso y otro con manifest para squid como proxy reverso y http proxy para que podáis utilizarlo en varias instalaciones -pero sólo uno de los dos al mismo tiempo-, en nuestro caso utilizaremos el de proxy reverso, además, deberemos crear -si no lo hemos hecho antes- el directorio </var/svc/manifest/application/cache>
# mkdir -p /var/svc/manifest/application/cache
# cd /var/svc/manifest/application/cache
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/put-tomcat-online/squid-conf/squid2_reverse.xml
# mv squid2_reverse.xml squid_2.xml
# svccfg
svc:> validate squid_2.xml
svc:> import squid_2.xml
svc:> quit
# svcs squid_2
STATE          STIME    FMRI
disabled       11:48:01 svc:/application/cache/squid_2:reverse_proxy
Ahora el method 
# cd /lib/svc/method
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/put-tomcat-online/squid-conf/squid2
# chmod 555 squid2
# chown root:root squid2

Creación y Configuración de project
Una vez importada la configuración para Solaris SMF, necesitamos crear los project que hemos definido en nuestro archivo <squid_2.xml> en la propiedad <method_context project='squid.reverse'>, en nuestro caso squid.reverse
# projadd -c 'SQUID Reverse Proxy' squid.reverse
# projmod -sK 'process.max-file-descriptor=(priv,8192,deny)' squid.reverse
# projmod -sK 'task.max-lwps=(priv,250,deny)' squid.reverse
Configuración <$SQUID_HOME/etc/squid.conf>
Vamos a utilizar una configuración básica de squid y sobre ella realizaremos los cambios necesarios, puedes encontrar más información aquí sobre la instalación de squid cache en Solaris 10.

Para poder hacer que squid funcione como proxy reverso debemos realizar los siguientes cambios -vamos a continuar con el ejemplo de la serie y tenemos un VirtualHost (www.test.com) :
  • visible_hostname _hostname_, debe ser nuestro dns público, es decir, <www.test.com>
  • http_port _localip_:80 defaultsite=_default_virtual_host_ accel vhost, aquí indicaremos a squid que queremos que haga de proxy reverso donde <localip> será nuestra IP y &lt:default virtual host> será nuestro virtual host por defecto, en nuestro caso <test.com>
Ahora viene algo un poco más complicado, pero intentaré explicarlo de forma sencilla. Vamos a hacer que squid utilice como caché padre <cache_peer> a nuestro servidor Apache HTTP, y por lo tanto, definiremos qué VirtualHost irá a cada Apache HTTP. 

El formato de  <cache_peer> es:
cache_peer hostname type http_port icp_port options
Donde <hostname> será el dns/ip de nuestro servidor Apache HTTP,  <type> será siempre parent, <http_port> será el puerto donde escucha nuestro Apache HTTP, <icp_port> lo estableceremos a 0 para que no utilice peticiones icp y por último, las opciones. En las opciones deberemos declarar un nombre único <name> para cada cache_peer y la opción <login=PASS> para indicarle a squid que si tiene una petición de login la envíe al padre, no la trate el.
Por lo tanto, para nuestro ejemplo -teniendo en cuenta que <htt1.test.com> es nuestro servidor Apache HTTP- quedará de la siguiente forma:
cache_peer http1.test.com parent 80 0 no-query originserver round-robin login=PASS name=primary
acl sites_public dstdomain www.test.com app1.test.com app2.test.com
cache_peer_access primary allow sites_public
cache_peer_access primary deny all
Y si quiero que el virtual host <app1.test.com> lo proces <http1.test.com> y que el virtual host <app2.test.com> lo procese <http2.test.com>? Bien, pues declararemos dos cache_peer, de esta forma
cache_peer http1.test.com parent 80 0 no-query originserver round-robin login=PASS name=app1
acl sites_public_app1 dstdomain app1.test.com
cache_peer_access app1 allow sites_public_app1

cache_peer http2.test.com parent 80 0 no-query originserver round-robin login=PASS name=app2
acl sites_public_app2 dstdomain app2.test.com
cache_peer_access app2 allow sites_public_app2

cache_peer_access app1 deny all
cache_peer_access app2 deny all
Tener en cuenta, que ahora los controles para denegar el acceso a la caché a los dominios que no son nuestros, debe ir en última posición

Como la configuración puede ser un poco dificil si se empieza desde cero, os dejo un archivo de configuración de ejemplo para squid cache como proxy reverso

Configuración DNS y Puesta en Marcha
Nuestro reverse proxy no debe tener resolución por dns -o mejor dicho, tiene que tener unos propios- por ello, una solución sencilla -en vez de montar un servidor dns exclusivo- si no tenemos muchos hosts es declararlos en nuestro </etc/hosts>

Pero, qué debemos declarar? Bueno todos los host que tengamos en nuestros <cache_peer>, es decir, nuestro servidores Apache http. Continuando con nuestro ejemplo, el archivo </etc/hosts> contendrá las siguientes entradas:
# vi /etc/hosts
  # reverse proxy
  172.26.17.20    www.test.com      www.test.com
  # real http server
  172.26.17.1     http1.test.com        http1.test.com
  172.26.17.2     http2.test.com        http2.test.com
Ya sólo nos queda verificar que las configuraciones están correctas, crear la caché de squid y activar el servicio.

Comprobamos la sintaxis del archivo <squid.conf>

# /opt/www/squid-2.7/sbin/squid -k parse
Creamos la estrucutra de la caché
# mkdir -p /opt/www/squid-2.7/var/cache
# mkdir -p /opt/www/squid-2.7/var/run
# cd /opt/www/squid-2.7/var/
# chmod -R 700 cache logs
# chown -R nobody:nobody cache logs
# /opt/www/squid-2.7/sbin/squid -z
2010/04/30 13:14:57| Creating Swap Directories
Activamos el servicio squid-cache utilizando Solaris SMF
# svcs squid_2
STATE          STIME    FMRI
disabled       12:47:56 svc:/application/cache/squid_2:reverse_proxy
# svcadm enable squid_2
# svcs -p squid_2
STATE          STIME    FMRI
online         12:48:23 svc:/application/cache/squid_2:reverse_proxy
               12:48:23     6164 squid
               12:48:23     6166 squid
               12:48:24     6167 dnsserver
               12:48:24     6168 dnsserver
               12:48:24     6169 dnsserver
               12:48:24     6170 dnsserver
               12:48:24     6171 dnsserver
               12:48:24     6172 unlinkd
Ahora vamos a comprobar que nuestra instalación está correcta, para ello, utilizaremos el comando <squidclient> para realizar una petición http
# /opt/www/squid-2.7/bin/squidclient -h www.test.com -p 80 -r http://www.test.com
HTTP/1.0 200 OK
Accept-Ranges: bytes
Last-Modified: Tue, 09 Mar 2010 17:06:21 GMT
Content-Length: 7777
Content-Type: text/html
Date: Fri, 30 Apr 2010 10:49:55 GMT
Server: Apache/2.2.15 (Unix) mod_jk/1.2.30
ETag: W/"7777-1268154381000"
Age: 1770
Connection: close
Podemos comprobar el registro de squid-cache en el archivo <access.log> para ver que, realmente ha ido por la caché
# tail /opt/www/squid-2.7/var/logs/access.log
172.26.17.20 - - [30/Apr/2010:13:25:51 +0200] "GET http://www.test.com/ HTTP/1.1" 200 8041 TCP_CLIENT_REFRESH_MISS:ROUNDROBIN_PARENT
Rotación Logs de Squid
Por último, vamos a hacer que squid rote los archivos de logs utilizando una entrada en nuestro crontab que llame a squid con la opción <-k rotate> -puedes ver cómo editar el crontab en Solaris, si tienes problemas-:
# export EDITOR=vi
# crontab -e
  ##########################################
  ## ROTATE SQUID LOG
  ##########################################
  00 0 * * * /opt/www/squid-2.7/sbin/squid -k rotate
:wq

Conclusiones
Con esta entrega hemos concluido los requistos necesarios para poder poner nuestro tomcat en producción de forma eficiente. Ahora ya podemos explicar cómo se hace!

En las próximas entregas, veremos como configurar Solaris 10 utilizando zonas -para reverse proxy, http y j2ee- y cómo hacerlo con OpenSolaris y Crossbow. Esto nos servirá para ver las principales diferencias entre hacerlo con Solaris 10 y con OpenSolaris -es muy interesante-



<< Instalación de Apache HTTP como frontend de Tomcat
<< Instalación de Apache Tomcat como stand alone con VirtualHosts
 

Referencias

miércoles, 28 de abril de 2010

Cómo saber a qe package pertenece un archivo

Introducción
Si alguna vez nos encontramos con un archivo y necesitamos conocer cuál es el paquete de Solaris que lo instala, utilizaremos el comando <pkgchk> con las opciones <-lp> y el path del archivo a comprobar, por ejemplo para saber a que package pertenece wget

# /usr/sbin/pkgchk -l -p /usr/sfw/bin/wget
Pathname: /usr/sfw/bin/wget
Type: regular file
Expected mode: 0555
Expected owner: root
Expected group: bin
Expected file size (bytes): 231020
Expected sum(1) of contents: 2997
Expected last modification: may 31  1:41:29 2007
Referenced by the following packages:
        SUNWwgetu
Current status: installed
Referencias

lunes, 26 de abril de 2010

Dónde esta MD5 en Solaris

Introducción
Una pregunta muy repetida es: Pero dónde esta el comando <md5> en Solaris? Bien, la respuesta es sencilla: No está "como md5", pero tanquilos que no cunda el pánico.

Desde que Solaris Crypto Framework está integrado en el Sistema Operativo, muchas de las características de cifrado han sido trasladadas a él. Esto hace que el comando como tal "md5" que existe en las distribuciones linux no se encuentre, para ello hay dos opciones:
El comando <digest> nos proporciona la misma funcionalidad que <md5> pero con la posibilidad de utilizar todo el conjunto de algoritmos soportados en Crypto Framework. Su formato es el siguiente:
digest [-b] -a _algoritmo_ [file]
Además, para ver todos los algoritmos soportados utilizaremos la opción <-l>, veamos unos ejemplos:
# digest -l
sha1
md5
sha256
sha384
sha512
# digest -v -a md5 /bin/sh
md5 (/bin/sh) = f4ad35f5246f817d68f4895463d79b09
# digest -v -a sha1 /bin/sh
sha1 (/bin/sh) = aa3843a19f2225458d7e3e765f44e229a09c0ad0
# digest -v -a sha256 /bin/sh
sha256 (/bin/sh) = a5e1a0062bb6600f06e029ce58f500169e966400b173b7fba504d5cd4635f291
# echo "Hola Mundo" | digest -v -a sha256
sha256 06bd0df149ba6261bbf9439e4f0ecacc1fa51e562cdb0ea95b6ce9293707f4da


Referencias

viernes, 23 de abril de 2010

Cómo añadir una ruta estática persistente en Solaris 10

Introducción
Para añadir rutas estáticas a nuestro tabla de enrutado, deberemos utilizar el comando <route> con las opciones <{add | delete}> -según lo que queramos hacer-, sin embargo, éstas rutas desaparecían cuando hacíamos un reboot de la máquina.

Para solucionar esto tenemos dos posibilidades: Tener Instalado el path 118833-36 o crearnos un script de inicio. Si tenemos el patch el comando <route> acepta una nueva opción <-p> que hace la ruta permanente y no debemos preocuparnos por más, para comprobar si tenemos instalado el patch utilizaremos <showrev> con la opción <-p>

# showrev -p|grep "Patch: 118833-36"
Patch: 118833-36 Obsoletes: 118822-30, 118348-01 ...
.....
Podemos añadir la ruta de forma permanente
# route -p add -net 192.168.20.0 172.26.17.2
Y comprobar su estado utilizando <netstat -rn>

# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
127.0.0.1            127.0.0.1            UH        2          0 lo0
172.26.0.0           172.26.17.1          U         3         17 e1000g0
192.168.20.0         172.26.17.2          UG        2         17

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
::1                         ::1                         UH      2       0 lo0
Si no tenemos el patch instalado, deberemos crear un script de inicio en /etc/init.d/rc3.d donde incluyamos nuestras rutas, por ejemplo,
# echo "route add -net 192.168.20.0 172.26.17.1" >> /etc/init.d/rc3.d/S99myroutes
# chmod 555 /etc/init.d/rc3.d/S99myroutes
Referencias

miércoles, 21 de abril de 2010

Cómo ver la tabla de enrutado en Solaris 10

Introducción
Para poder ver la tabla de rutas activa utilizaremos el comando <netstat> con la opción <-r>

root@http:~# netstat -r

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
localhost            localhost            UH        2          0 lo0
172.26.0.0           http                 U         3         39 e1000g0
192.168.20.0         172.26.17.2          UG        2         39

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
localhost                   localhost                   UH      2       0 lo0

Sin embargo, si queremos que no nos resuelva las IPs y nos muestre los valores -no los DNS-, añadiremos la opción <-n>, así
root@http:~# netstat -rn

Routing Table: IPv4
  Destination           Gateway           Flags  Ref     Use     Interface
-------------------- -------------------- ----- ----- ---------- ---------
127.0.0.1            127.0.0.1            UH        2          0 lo0
172.26.0.0           172.26.17.1          U         3         41 e1000g0
192.168.20.0         172.26.17.2          UG        2         41

Routing Table: IPv6
  Destination/Mask            Gateway                   Flags Ref   Use    If
--------------------------- --------------------------- ----- --- ------- -----
::1                         ::1                         UH      2       0 lo0



Referencias

lunes, 19 de abril de 2010

Instalación de Apache HTTPD con Tomcat6 y Mod_JK

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.

Instalación de Apache HTTPD como frontend de Tomcat6 con Mod_JK
En esta ocasión vamos a ver cómo podemos utilizar Apache HTTP 2.2.x como frontend de nuestro Tomcat6. Para ello disponemos de varias soluciones, entre ellas:
  • Utilizar mod_proxy
  • Utilizar mod_jk 
Antes de comenzar, vamos a ver cuáles son las diferencias principales entre ambos métodos, y posteriormente explicaremos cómo son los pasos de instalación en ambos casos.
  • Técnica de Mod_Proxy:  Cuando utilizamos este método, todas las peticiones que entren en nuestro Apache HTTPD serán enviadas al Tomcat, es decir, tanto contenido estático como dinámico.
  • Técnica de Mod_JK: Cuando utilizamos este método, podemos discriminar qué queremos en Tomcat y que no queremos, es decir, podemos utilizar <*.jsp> para que sea tomcat quien lo procese, y el resto sea httpd quien lo gestion -contenido dinámico a tomcat, estático a httpd- Además, podemos gestionar cargas y failovers de nuestros balanceadores.
Una vez explicadas las diferencias, nos vamos a centrar en el uso de mod_jk ya que creo es una solución más robusta y nos permite más optimizaciones

Configuración Apache 2.2.x HTTPD en 64bits
Lo primero que vamos hace es decargar y compilar -yo voy a utilizar SunCC- el servidor http de Apache desde su web, si quieres puedes optar por Compilar Apache 1.3.x en 64bits sobre Solaris 10
wget http://www.eu.apache.org/dist/httpd/httpd-2.2.15.tar.gz
$ export CFLAGS="-m64 -O3"
$ export CC=cc
$ export LDFLGAS="-64"
$ ./configure 
   --prefix=/opt/www/apache2/64 \
   --enable-so \
   --enable-rewrite  \
   --enable-vhost-alias  \
   --enable-unique-id  \
   --enable-head  \
   --with-included-apr \
$ make
# make install
Instalación de Mod_JK 1.30 en 64bits
Al igual que antes, vamos a compilar Mod_JK en 64bits utilizando el compilador de SunCC -Sun Compiler Tools-
$ wget http://www.apache.org/dist/tomcat/tomcat-connectors/jk/source/jk-1.2.30/tomcat-connectors-1.2.30-src.tar.gz
$ gtar zxpf tomcat-connectors-1.2.30-src.tar.gz
$ cd tomcat-connectors-1.2.30-src/native
$ export CC=cc
$ export CFLAGS="-m64 -O2"
$ ./configure --with-apxs=/opt/www/apache2/64/bin/apxs
$ make
# make install
Configuración de Apache Mod_JK
A continuación vamos a configurar el módulo <mod_jk>, para ello, deberemos indicar en el archivo de configuración <$APACHE_HOME/conf/httpd.conf> que carge el módulo de mod_jk utilizando para ello "LoadModule" -en Apache 2.2 la ubicación es $APACHE_HOME/modules, en 1.3.x es $APACHE_HOME/libexec-
#############################################
# CARGA DE MODULOS JK
#############################################
LoadModule jk_module          modules/mod_jk.so

#################################################
## MOD_JK
#################################################
<IfModule mod_jk.c>
  JkWorkersFile conf/extra/modules/modjk.conf.d/modjk.conf
 JkLogFile logs/mod_jk.log
 JkLogLevel error
<IfModule>
Continuaremos con la creación del archivo de configuración <modjk.conf> que hemos definido en <JkWorkersFile> donde definiremos los nombres, puertos y demás parámetros de los tomcat que queremos utilizar.

El formato del archivo <JkWorkersFile> puedes encontrarlo en la documentación oficial de Apache Tomcat, pero os he preparado un JkWorkersFile de ejemplo con las principales propiedades para que no empeceis desde cero.

Configurar Apache Tomcat JK Connector
Ahora toca el turno a nuestra instalación de Apache Tomcat, para ello editaremos el archivo <$TOMCAT_HOME/conf/server.xml> y en el apartado <SERVICE> deberemos declarar un connector nuevo, pero esta vez, utilizará el protocolo <AJP/1.3>. El puerto debe ser el mismo que hemos puesto en el valor de la propiedad <Worker.Port>, por si alguno tiene dudas, aquí os dejo un archivo de configuración de Apache Tomcat Server.xml de Ejemplo:

    <Connector
        port="13201"
        protocol="AJP/1.3"
        redirectPort="8443"
        connectionTimeout="20000"
        bufferSize="8192"
        URIEncoding="UTF-8"
    />
Configuración VirtualHost de Apache
Por último, sólo nos queda indicar a Apache HTTPD Qué contenido debe ser procesado por Tomcat y cuál por él. Para ello, deberemos utilizar la propiedad <JkMount _mountpoint_ _worker_> donde mountpoint hace referencia a la expresión regular y worker al nombre del tomcat, por ejemplo, si queremos que todas las JSP y Servlet los procese nuestro worker router, haremos
JkMount /*.jsp router cluster1
JkMount /*servlet* cluster1
Por lo tanto, nuestro virtualhost deberá quedar así -ten en cuenta que es un ejemplo-
################################################
## WWW.TEST.COM
################################################
<VirtualHost *:80>
  JkMount /*.jsp cluster1
  JkMount /*servlet* cluster1
</VirtualHost>
Finalización de proceso
Ya tenemos configurado el sistema, sólo nos queda iniciar el Tomcat y el Apache, para probar que todo está como queremos.

Conclusión
En esta ocasión hemos visto cómo podemos poner un servidor Apache HTTPD haciendo de frontend de Tomcat y, esto nos va a permitir utilizar -por ejemplo- mod_rewrite para simular URL estáticas, además de proporcionarnos un LoadBalance que nos permitirá escalar nuestros aplicativos de forma sencilla.

Sin embargo, todavía esta configuración no es para ir a producción ya que no hemos tratado en ningún caso el uso de recursos, cargas, ... y, debemos separar las capas para establecer un punto de entrada (DMZ) el cual tengo un acceso muy controlado -utilizando IPFilter-

En la próxima entrega ya sí que veremos cómo establecer una configuración de producción -ahora que tenemos las bases- y veremos cómo utilizar la tecnología de zonas para encapsular nuestros servicios y hacerlos mucho más seguros.


<< Instalación de Apache Tomcat "Stand Alone"

Referencias

viernes, 16 de abril de 2010

Cómo crear un Banner/Poster desde linea de comandos

Introducción
Para crear banner -o poster- desde línea de comandos para hacer más interesantes nuestros mensajes de </etc/motd> o </etc/issue> utilizaremos el comando <banner _texto_>. El tamaño máximo de nuestro <texto> es de 10 caracteres por línea
$ banner Hola
#     #
#     #   ####   #         ##
#     #  #    #  #        #  #
#######  #    #  #       #    #
#     #  #    #  #       ######
#     #  #    #  #       #    #
#     #   ####   ######  #    #

Por ejemplo, podemos utilizarlo para crear nuestro Banner de acceso de SSH, FTP, etc
# banner SFChildren >> /etc/issue
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, 12 de abril de 2010

Instalar MemCached (32bits) en Solaris 10

Introducción
En esta ocasión vamos a ver cómo instalar y configurar MemCached en Solaris 10, en 32bits. En otro post vimos cómo Instalar MemCached en Solaris 10 en 64bits, debéis tener en cuenta que si lo instalamos en 32bits no podremos poner un tamaño de caché superior a 4Gb, a parte de esto, no tenemos más limitaciones.

La instalación de MemCached necesita de la biblioteca LibEvent, por lo tanto, primero deberemos descargar y compilarla. En nuestro ejemplo vamos a utilizar la siguiente estructura:
$MEMCACHED_HOME=/opt/memcached/32
$LIBEVENT_HOME=/opt/memcached/libevent/32
Y crearemos el usuario <memcached> y el project <user.memcached&gt para gestionar el uso de recursos dentro del sistema. Además, haremos que nuestro servidor de MemCached esté ejecutado -y controlado- mediante SMF, por lo tanto, podremos incluirlo como servicio requerido.

Para aquellos que no tenéis la posibilidad de compilar los paquetes, os he dejado uno listo para instalar -en el path </opt/memcached> en Solaris 10 SPARC de MemCached 1.4.5 32bits y Solaris 10 X86 de MemCached 1.4.5 32bits

Instalación de LibEvent (32Bits)
$ wget http://www.monkey.org/%7Eprovos/libevent-1.4.13-stable.tar.gz
$ gtar zxpf libevent-1.4.13-stable.tar.gz
$ cd libevent-1.4.13-stable
$ ./configure --enable-static --prefix=/opt/memcached/libevent/32
$ make
# make install
Comprobamos que todo se ha instalado correctamente y que no tenemos dependencias fallidas
$ ldd /opt/memcached/libevent/32/lib/libevent.so
        libnsl.so.1 =>   /lib/libnsl.so.1
        librt.so.1 =>    /lib/librt.so.1
        libresolv.so.2 =>        /lib/libresolv.so.2
        libsocket.so.1 =>        /lib/libsocket.so.1
        libc.so.1 =>     /lib/libc.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libm.so.2 =>     /lib/libm.so.2
        /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
        /platform/SUNW,Sun-Fire-280R/lib/libmd_psr.so.1


Instalación de MemCached (32bits)
En la instalación de MemCached, vamos a forzar a nuestro linker para que se asocie con la biblioteca libevent que hemos creado, es decir, vamos a utilizar el flag &lt:-R> y de esta forma, no será necesario exportar la variable de entorno LD_LIBRARY_PATH_32. Para ello, deberemos utilizar la variable de entorno LDFLAGS que nos permitirá incluirlo en el sistema de configuración de MemCache.


Además, existe un bug en Solaris 10 que hace que el sistema incluya la opción <-pthread> que en algunas versiones antiguas de GCC no es válida, así que nos muestra el error:
gcc: unrecognized option `-pthread'
Para solucionarlo, simplemente exportaremos el valor a <-pthreads> en $CFLAGS y configuraremos. Si queréis más información aquí esta el link al bug
$ wget http://memcached.googlecode.com/files/memcached-1.4.5.tar.gz
$ gtar zxpf memcached-1.4.5.tar.gz
$ cd memcached-1.4.5
$ export LDFLAGS="-R/opt/memcached/libevent/32/lib -R/usr/sfw/lib"
$ export CFLAGS="-pthreads -O3"
$ ./configure --with-libevent=/opt/memcached/libevent/32 --prefix=/opt/memcached/32
$ make
# make install
Comprobamos que se ha instalado correctamente y que no tiene dependencias fallidas
$ ldd /opt/memcached/32/bin/memcached
        libumem.so.1 =>  /lib/libumem.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libevent-1.4.so.2 =>     /opt/memcached/libevent/32/lib/libevent-1.4.so.2
        libc.so.1 =>     /lib/libc.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        librt.so.1 =>    /lib/librt.so.1
        libresolv.so.2 =>        /lib/libresolv.so.2
        libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libm.so.2 =>     /lib/libm.so.2
        /platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1
        /platform/SUNW,Sun-Fire-280R/lib/libmd_psr.so.1
Configuración MemCached
A continuación vamos a crear el usuario y grupo <memcached> y el project <user.memcached> -recordar que SMF necesita hacer un chdir al home del usuario-
# groupadd memcache
# useradd -g memcache -s /bin/bash -d /export/home/memcache -m memcache
# projadd -G memcache -c 'MemCache Project' user.memcache
Creamos el Manifest para MemCached -en mi caso he decidido ponerlo en <application/cache> pero puedes ponerlo donde quieras-

# cd /var/svc/manifest/application/cache/
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/memcached/svc/memcached_1.xml
# svccfg
svc:> validate memcached_1.xml
svc:> import memcached_1.xml
svc:> quit
Y ahora, el Method para MemCached
# cd /lib/svc/method
# /usr/sfw/bin/wget http://blog.sfchildren.com/blogger/memcached/svc/memcached_1
# chmod 555 memcached_1
# chown root:bin memcached_1
Ya hemos instalado todos los requisitos de Solaris SMF, sin embargo, hemos declarado que guarde el <PID> en <$MEMCACHED_HOME/run>, por lo tanto, debemos crear el directorio
# mkdir /opt/memcached/32/run
# chown memcache:memcache /opt/memcached/32/run
# chmod 750  /opt/memcached/32/run
Ahora ya podemos activar nuestro servicio MemCached utilizando el FRMI <memcached_1>
# svcs memcached_1
STATE          STIME    FMRI
disabled       11:37:41 svc:/application/cache/memcached_1:memcached_default32bits
# svcadm enable memcached_1
# svcs -p memcached_1
STATE          STIME    FMRI
online         12:04:25 svc:/application/cache/memcached_1:memcached_default32bits
               12:04:25    18580 memcached
Conclusiones
En esta ocasión hemos visto cómo instalarlo y configurarlo, la verdad es que no requiere de mucho tiempo -ni conocimientos- y, al introducir el control dentro de Solaris SMF, podemos gestionar las dependencias, por ejemplo, si nuestro memcached se cae, el servicio de Tomcat gestionado por SMF se marque como degraded


Referencias

viernes, 9 de abril de 2010

Cómo Configurar IPFilter en Solaris 10 Paso a Paso

Introducción
Muchas veces a lo largo de los post, he ido hablando de IPFilter, también he creado algunos con pequeños tips de cómo Activar el Log de IPFilter, Cómo Activar IPFilter para Hadoop, pero, no había creado uno dedicado exclusivamente a Configurar IPFilter para Solaris 10 Paso a Paso.

En esta ocasión, vamos a ver los pasos necesarios para activar IPFilter en Solaris 10 de forma sencilla y rápida. Antes de comenzar con la configuración vamos a tener un par de cosas en cuenta.

Antes de Empezar
IPFilter puede activarse sobre una zona no global siempre que la tarjeta de red esté como <excl>, si está como <shared> no se podrá.

Para comprobar el tipo de asignación de IP que tenemos en la zona, simplemente ejecutaremos el comando <zoneadm> con las opciones <list -cv> y comprobaremos el valor de IP

# zoneadm list -cv
  ID NAME             STATUS     PATH                           BRAND    IP
   0 global           running    /                              native   shared
   1 zion             running    /opt/zones/zion                native   excl
  12 logos            running    /opt/zones/logos               native   shared
   - andatza          installed  /opt/zones/andatza             native   excl
Por ejemplo, si queremos activar IPFilter sobre una zona que tiene la red en modo <shared> -que ya hemos comentado que no se puede- el sistema nos mostrará el siguiente error:

# svcadm enable ipfilter
# svcs -x ipfilter
svc:/network/ipfilter:default (IP Filter)
 Estado: maintenance desde  9 de abril de 2010 10:17:33 CEST
Motivo: Iniciar método salió con $SMF_EXIT_ERR_CONFIG.
   Consulte: http://sun.com/msg/SMF-8000-KS
   Consulte: ipfilter(5)
   Consulte: /var/svc/log/network-ipfilter:default.log
Impacto: Este servicio no está funcionando.

# tail /var/svc/log/network-ipfilter:default.log
[ abr  9 10:17:33 Executing start method ("/lib/svc/method/ipfilter start") ]
open device: No such file or directory
SIOCFRENB: Bad file number
open device: No such file or directory
User/kernel version check failed
/lib/svc/method/ipfilter: load of /etc/ipf/ipf.conf into alternate set failed
Not switching config due to load error.
[ abr  9 10:17:33 Method "start" exited with status 96 ]

# svcadm disable ipfilter

Si tenemos todas nuestras zonas con la red en modo <shared>, no os preocupeis, editaremos la configuración desde la zona global, y no hay más problema.

Activar IPFilter
La activación de IPFilter depende de la Versión de Solaris que tenemos instalada, ya que hasta la versión 10 8/07 era necesario activar el módulo <pfil>, sin embargo, a partir de esta versión, ya no es necesario.

- Versión 10 11/06 o Anterior -
Primero deberemos activar el módulo de <pfil> con autopush, para ello, editaremos/crearemos el archivo </etc/ipf/pfil.ap> con el nombre de nuestra tarjeta de red -sobre la cuál activaremos pfil-, en mi caso es <ce0>, y activaremos el FRMI <svc:/network/pfil>
# vi /etc/ipf/pfil.ap
   #major  minor   lastminor       modules
   ce0     -1      0               pfil
:wq
# svcadm restart svc:/network/pfil
Una vez activado pfil podemos activar ipfilter,  es necesario hacer un reboot para que los cambios tengan efecto
# svcadm enable ipfilter
# reboot
- Versión 10 8/07 o Superior -
Para activar IPFilter deberemos poner en enabled el FRMI <svc:/network/ipfilter:default>, como podéis ver, se ha simplificado muchísimo la configuración y no es necesario hacer un reboot
# svcadm enable ipfilter
# svcs ipfilter
STATE          STIME    FMRI
online         10:05:16 svc:/network/ipfilter:default
Configuración de Reglas de IPFilter
Una vez activado, ya podemos empezar a introducir reglas en el archivo </etc/ipf/ipf.conf>, recordar que si no existe o está vacío es como poner las siguientes reglas:
pass in all
pass out all
Al principio del post hemos comentado que no podemos activar IPFilter en las zonas si tienen la red asignada como shared, bien, para poder hacer firewalling sobre ellas, deberemos declarar sus IPs -la de las zonas- y configurar las reglas en la zona global, por ejemplo, imaginemos que tenemos una zona -Zion- con la IP 192.168.1.200/24 y no quiero que conteste a paquetes ICMP que no vengan de la LAN, la configuración de IPFilter quedaría así:
# zonename
global

# vi /etc/ipf/ipfilter.conf
  # Interfaces
  int_if = "ce0";

  # Zonas
  zone_zion = "192.168.1.200/32";

  # Configuracion RED
  our_net = "192.168.0.0/16";

  # eliminamos los paquetes peque!nos
  block in log quick from any with ipopts
  block in log quick proto tcp from any to any with short

  # permitir SSH desde - hacia
  pass in quick on $int_if from $our_net port=22 to any
  pass out quick on $int_if from $our_net port=22 to any
 
  # LocalHost
  pass in quick from 127.0.0.1/32 to 127.0.0.1/32
 
  # Zone Zion, no Responde a ICMP
  block in log quick icmp from any to $zone_zion
  block out log quick icmp from $zone_zion to any
 
  # Permitir ICMP solo LAN menos ZONE1
  pass in quick proto icmp from $our_net to $our_net
  pass out quick proto icmp from $our_net to $our_net
 
  # todo lo demás bloqueado
  block in log quick proto icmp from any to any
  block out log quick proto icmp from any to any
 
:wq
# svcadm restart ipfilter

Configurar el Log de IPFilter
Para que IPFilter registre los accesos, debemos utilizar la opción <log> en nuestrar reglas, además, debemos activar en nuestra configuración de syslog y reiniciar el demonio.

Recordar que la separación entre y el nombre del fichero debe ser tabuladores y no espacios

# vi /etc/syslog.conf
  ############################################
  ## IPFilter Log
  ############################################
  local0.debug                              /var/log/ipfilter.log
:wq
# touch /var/log/ipfilter.log
# chmod 600 /var/log/ipfilter.log
# svcadm restart system-log

Conclusiones
La verdad es que a partir de la versión 10 8/07 se ha simplificado en gran medida la activación y mantenimiento, además de no requerir un reboot, ya tenemos una excusa más para tener Solaris actualizado a la última release, xD

Espero que con esta agrupación tengáis más sencillo ver los pasos para la Instalación de IPFilter sobre Solaris 10, de todas formas, os dejo en referencias los post separados, por si queréis mayor detalle.


Referencias

miércoles, 7 de abril de 2010

Cómo ver un Calendario desde línea de comandos en Solaris 10

Introducción
Puede que alguna vez necesitemos ver el calendario -no sólo la fecha actual- y, no tengamos uno a mano. Para ello, podemos contar con el comando <cal>. Su formato es el siguiente
cal [ [mes] [año]]
Cal utiliza la variable de entorno <LC_ALL> y <LC_MESSAGES> para formatear la salida en uno y otro idioma, además, si ejecutamos el comando sin opciones, nos mostrará el calendario del mes actual
$ export LC_ALL=es.UTF-8
$ cal
   abril 2010
Do Lu Ma Mi Ju Vi Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

$ export LC_ALL=en.UTF-8
$ cal
   April 2010
 S  M Tu  W Th  F  S
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
Si queremos ver el calendario del año 2010, simplemente ejecutaremos el siguiente comando -he tenido que ajustar las fuentes para que se refleje el resultado de salida del comando en Solaris-

$ cal 2010
                                2010

         ene                    feb                    mar
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
                1  2       1  2  3  4  5  6       1  2  3  4  5  6
 3  4  5  6  7  8  9    7  8  9 10 11 12 13    7  8  9 10 11 12 13
10 11 12 13 14 15 16   14 15 16 17 18 19 20   14 15 16 17 18 19 20
17 18 19 20 21 22 23   21 22 23 24 25 26 27   21 22 23 24 25 26 27
24 25 26 27 28 29 30   28                     28 29 30 31
31
         abr                    may                    jun
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
             1  2  3                      1          1  2  3  4  5
 4  5  6  7  8  9 10    2  3  4  5  6  7  8    6  7  8  9 10 11 12
11 12 13 14 15 16 17    9 10 11 12 13 14 15   13 14 15 16 17 18 19
18 19 20 21 22 23 24   16 17 18 19 20 21 22   20 21 22 23 24 25 26
25 26 27 28 29 30      23 24 25 26 27 28 29   27 28 29 30
                       30 31
         jul                    ago                    sep
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
             1  2  3    1  2  3  4  5  6  7             1  2  3  4
 4  5  6  7  8  9 10    8  9 10 11 12 13 14    5  6  7  8  9 10 11
11 12 13 14 15 16 17   15 16 17 18 19 20 21   12 13 14 15 16 17 18
18 19 20 21 22 23 24   22 23 24 25 26 27 28   19 20 21 22 23 24 25
25 26 27 28 29 30 31   29 30 31               26 27 28 29 30

         oct                    nov                    dic
Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa   Do Lu Ma Mi Ju Vi Sa
                1  2       1  2  3  4  5  6             1  2  3  4
 3  4  5  6  7  8  9    7  8  9 10 11 12 13    5  6  7  8  9 10 11
10 11 12 13 14 15 16   14 15 16 17 18 19 20   12 13 14 15 16 17 18
17 18 19 20 21 22 23   21 22 23 24 25 26 27   19 20 21 22 23 24 25
24 25 26 27 28 29 30   28 29 30               26 27 28 29 30 31
31


Y si quiero ver el mes de Mayo de 2008, por ejemplo,

$ cal 5 2008
   mayo 2008
Do Lu Ma Mi Ju Vi Sa
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Referencias

lunes, 5 de abril de 2010

Monitorizar Servicios Solaris 10 Nagios - Parte 3

Introducción
Durante 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 10
La 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 once
nrpe.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 1
Para 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-plugin
cd ./src/ && make install-plugin
make[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/libexec
make[1]: Leaving directory `/export/home/itily/NRP/plugin/nrpe-2.12/src'

# make install-daemon
cd ./src/ && make install-daemon
make[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/bin
make[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/etc
Configuración de SysLog
En 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-log
Prueba de Funcionamiento Correcto
Ahora 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 localhost
NRPE v2.12
# tail /var/log/nrpe.log
Apr  5 12:29:01 zion nrpe[2457]: [ID 601491 local7.notice] Starting up daemon
Apr  5 12:29:01 zion nrpe[2457]: [ID 624405 local7.info] Listening for connections on port 5666
Apr  5 12:29:01 zion nrpe[2457]: [ID 907248 local7.info] Allowing connections from: 127.0.0.1
Si 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 -ltr
total 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 142
drwxr-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_64bits
Por lo tanto, nuestro archivo de configuración tendrá una configuración similar a esta
allowed_hosts=127.0.0.1,192.168.1.200
command_timeout=60
command[check_tomcat6]=/opt/nagios/nrpe/libexec/check_svc tomcat_6:default_64bits
connection_timeout=300
debug=0
dont_blame_nrpe=0
log_facility=local7
nrpe_group=svcmon
nrpe_user=svcmon
pid_file=/var/run/nrpe.pid
server_port=5666

Instalación de NRPE Mediante SMF
Como 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
# svccfg
svc:> validate nrpe_2.xml
svc:> import nrpe_2.xml
svc:> 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_2
STATE          STIME    FMRI
disabled       16:08:25 svc:/application/management/nrpe_2:ssl_disabled
disabled       16:08:27 svc:/application/management/nrpe_2:ssl_enabled
# svcadm enable nrpe_2:ssl_enabled
# svcs -p nrpe_2
STATE          STIME    FMRI
disabled       16:08:25 svc:/application/management/nrpe_2:ssl_disabled
online         16:11:00 svc:/application/management/nrpe_2:ssl_enabled
               16:11:00    20279 nrpe
Finalización Instalación
Ya hemos acabado con la Instalación de NRPE Sobre Solaris 10! Como veis, no ha sido tan complicada, no?



Conclusión Final
Durante 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"



Referencias