Geoserver en entorno de producción (III): Configurando PostgreSQL y PostGIS

Después de las dos partes iniciales (I y II) sobre como estoy instalando un servidor Geoserver, dentro de mi organización con miras a que funcione en producción, hoy nos centramos en una de las optimizaciones más mas importantes, y que es la utilización de una base de datos espacial.

Antes de nada, una nota: Existen configuraciones mucho más seguras que la que yo os describo, con usuarios con permisos muy limitados, usuarios de sistema, etc… pero este documento sólo trata de mostrar una configuración rápida de la que partir, y posteriormente ir afinando. No quiero críticas a ese respecto 😛

Este tipo de base de datos, espaciales, nos permite almacenar dentro de su contenido puntos, líneas y polígonos, así como funciones que nos permitan realizar consultas espaciales, es decir, almacenar cartografía dentro de la base y poder hacerle consultas preguntando por coordenadas, pero sólo nos permitirá almacenar datos vectoriales. Con esto, obtendremos todas las mejoras que tiene una base de datos en cuanto a velocidad, pero también ciertas complicaciones «extra», como son su configuración correcta en nuestra arquitectura. Además hay otro problema: las bases de datos más utilizadas no traen de «serie» esta funcionalidad y se tendrá que que instalar como un añadido o plugins.

Dentro del software libre, cabe destacar la unión de la base de datos PostgreSQL y PostGIS (el cual es su extensión para obtener las funciones espaciales). Pues manos a la obra:

  1. Instalamos PostgreSQL+PostGIS, pero usando cierto «truco» para no tener problemas de versiones. En mi caso, estoy usando Ubuntu 9.10, el cual tiene un paquete para ambas partes, pero por desgracia, PostGIS solo se instala en PostgreSQL 8.3, mientras que el paquete PostgreSQL es el 8.4. Entonces, instalamos PostGIS, y le permitimos que instale correctamente todas las dependencias (es recomendable usar aptitude en vez de apt)
    linux@svrmapas:~$ sudo aptitude search postgis
    p   libpostgis-java                                                                  - geographic objects support for PostgreSQL -- JDBC support
    c   postgis                                                                          - geographic objects support for PostgreSQL -- common files
    p   postgresql-8.3-postgis                                                           - geographic objects support for PostgreSQL 8.3
    linux@svrmapas:~$ sudo aptitude install postgresql-8.3-postgis
    Leyendo lista de paquetes... Hecho
    Creando árbol de dependencias
    Leyendo la información de estado... Hecho
    Leyendo la información de estado extendido
    Inicializando el estado de los paquetes... Hecho
    Se instalarán los siguiente paquetes NUEVOS:
      libgeos-3.1.0{a} libgeos-c1{a} libproj0{a} postgis{a} postgresql-8.3{a} postgresql-8.3-postgis postgresql-client-8.3{a} postgresql-client-common{a} postgresql-common{a}
      proj-data{a}
    0 paquetes actualizados, 10 nuevos instalados, 0 para eliminar y 0 sin actualizar.
    Necesito descargar 11,2MB/11,4MB de archivos. Después de desempaquetar se usarán 31,2MB.
    ¿Quiere continuar? [Y/n/?]
    

    Como puedes ver, fuerza a instalar la PostgreSQL 8.3, tal y como queremos.

  2. Configurar el acceso remoto al motor de la base de datos, y no nos queda mas que cacharrear en los ficheros de configuración para darnos acceso a nuestro equipo para usarlo remotamente. Este acceso remoto, puede aprovecharse con programas como «pgAdmin» que nos permite manejar la base de datos desde tu ordenador, aunque su uso escapa del tema principal de este tutorial.
    En el fichero «/etc/postgresql/8.3/main/postgresql.conf» (ojo, mira que tengo puesta mi versión de la base, en tu caso saldrá el de la tuya) edita lo siguiente:

    # Te encontrarás esto
    #listen_addresses = 'localhost'
    # Pondrás esto:
    # Acceso por todas las ips configurados
    listen_addresses = '*'
    # O por una en particular... usa una de las dos
    listen_addresses = '192.160.0.1'
    

    Tambien cambiamos la siguiente línea:

    # Esto
    #password_encryption = on
    # por esto
    password_encryption = on
    

    Ahora en el fichero «/etc/postgresql/8.2/main/pg_hba.conf» hacemos un par de cambios,  para poder acceder vía usuario/password remotamente. Sólo añadiendo esto al final:

    # IPv4 conexiones dentro de su misma red
    host    all         all         192.168.1.0/24      md5
    

    Es muy interesante estudiar un poco este tema, ya que se pueden configurar varios métodos de acceso dependiendo de la ip que se conecte al servidor, como por ejemplo, una ip que no tenga usuario ni password, o solo usuario, etc… Este tema lo puede leer en mayor profundidad en este link.

    Ya está, y tras esto, recargamos el servicio:

    sudo /etc/init.d/postgresql-8.3 reload
    

    Si todo va bien, podrás acceder desde tu ordenador tranquilamente sin tener que estar delante del ordenador.

  3. En este punto, tendrías que decirme:

    ¡¡¡Esto no funciona!!!, ya que pgAdmin me pide usuario y password
    .

    Bueno, es un pequeño detalle :). Por defecto el usuario es «postgres», el cual también ha sido creado como usuario local de la máquina linux (una buena idea, un usuario sólo para las tareas administrativas), pero ahora vamos a fijar su password dentro de la base de datos:

    # Ejecutamos el shell de psql como el usuario "postgres"
    sudo -u postgres psql postgres
    # Dentro del shell de psql
    \password postgres
    # Tecleamos el nuevo password
    

    Con esto, acabamos de fijar el usuario y password que vamos a usar remotamente.

  4. Instalación del «Admin Pack». Esto no es más que funciones para administrar la base remotamente, y que se pueden instalar de dos manera. Antes de nada instalar lo siguiente:
    sudo aptitude install postgresql-contrib-8.3
    

    De manera local, se tiene que hacer con un usuario que no requiera de password, en este caso primero cambio al usuario «postgres» que nos permitirá realizarlo sin password en la configuración por defecto de la base de datos:

    sudo su postgres
    postgres@svrmapas:/home$ psql -U postgres -d postgres < /usr/share/postgresql/8.3/contrib/adminpack.sql
    

    De manera remota, es muy sencillo, te bajas las librerías que necesitas desde el código fuente de PostgreSQL, en tu ordenador claro, y las lanzas desde pgAdmin. Y todo funcionará tal y como lo hace en local.

En siguientes «entregas» comentaremos como enlaza todo esto con Geoserver, y como almacenar tus capas vectoriales dentro de esta base de datos… pero todo más adelante y con paciencia 🙂

Y como siempre, os dejo la lista de referencias que he consultado para realizar este pequeño «tutorial».

Please follow and like us:

Registrar el nombre de un servidor en el DNS de Windows, mediante DHCP

Un problema clásico, cuando tenemos una nueva máquina linux «out-the-box» (recién instalada), es que cuando nuestra red funciona mediante Active Directory en Windows y con asignación de ips mediante DHCP, no podemos resolver su nombre, es decir, si hacemos ping al nombre de la máquina, esta no responde y necesitamos conocer su ip, lo que en una red con 12 o 13 servidores es un coñazo.

El problema suele residir, en que el cliente DHCP de linux (en mi caso uso Ubuntu) no se registra dentro del DNS correctamente, al recibir la cesión de la ip. Hay muchas preguntas en Internet sobre este tema, peticiones para que se añada esta opción directamente en la configuración por defecto. Y aunque por ahora no es así, no es difícil arreglarlo.

Tenemos que editar del fichero «/etc/dhcp3/dhclient.conf» y añadir las siguientes líneas a este fichero.

send fqdn.fqdn "nombre.dominio";
send fqdn.encoded off;
send fqdn.server-update on;

Como puedes ver, estamos mandando el nombre FQDN, para que el servidor DHCP sea capaz de añadirlo en la base del DNS para poder resolverlo correctamente. Ahora sólo nos queda volver a refrescar nuestra ip mediante el comando:

sudo dhclient3 eth0 -s servidorDHCP

Y ya podremos utilizar su nombre, en vez de la ip. Esperemos que os sirva de ayuda.

Please follow and like us:

Geoserver en entorno de producción (II): Optimizando el servidor

Tengo que reconocerlo. Esto está siendo mucho más difícil de lo que yo pensaba, ya que me estoy encontrando con muchos problemas, al configurar mi servidor en producción me estoy dando cuenta que hay mucha información contradictoria, y mucha más que es demasiado antigua. Voy a intentar resumir los pasos que voy siguiendo y que me han funcionado (pero recordar mi máquina, Ubuntu Server 9.10 de 32bits, en otras configuraciones… ¡quién sabe si esto funcionará!).

Allá van las mejoras que he incluido al servidor de mapas:

  1. Confirmar que la maquina virtual que usamos es la de Sun y no la OpenJDK mediante el comando:
    sudo  update-alternatives --config java
    Hay 2 opciones para la alternativa java ( proporcionando /usr/bin/java).
    
      Selección   Ruta                                      Prioridad  Estado
    ------------------------------------------------------------
      0            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      modo automático
      1            /usr/lib/jvm/java-6-openjdk/jre/bin/java   1061      modo manual
    * 2            /usr/lib/jvm/java-6-sun/jre/bin/java       63        modo manual
    

    Con este comando te pedirá que le des el numero de la máquina a utilizar, y como ves en mi caso ya está elegida correctamente.
    Una vez elegida, entra en la web de administración de Geoserver, y en la sección «Estado del Servidor«, y mirar que maquina virtual usa en el apartado «Versión de la JVM«, pone algo como «OpenJDK», entonces vamos mal. Pero no hay que tirar la toalla aún.
    El problema suele ser que la variable de entorno «JAVA_HOME» no está definida, como podemos consultar con el comando «env»:

    linux@svrmapas:~$ env
    TERM=xterm
    SHELL=/bin/bash
    XDG_SESSION_COOKIE=XXX
    SSH_CLIENT=192.168.XXX.XXX 4809 22
    SSH_TTY=/dev/pts/1
    USER=linux
    LS_COLORS=rs=0:di=01;34:ln=01;36:hl=44;37:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
    MAIL=/var/mail/linux
    PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
    PWD=/home/linux
    LANG=es_ES.UTF-8
    SHLVL=1
    HOME=/home/linux
    LOGNAME=linux
    SSH_CONNECTION=192.168.XXX.XXX 4809 192.168.XXX.XXX 22
    LESSOPEN=| /usr/bin/lesspipe %s
    LESSCLOSE=/usr/bin/lesspipe %s %s
    _=/usr/bin/env
    

    Vaya, si no tenemos definida la variable, ¿donde coge el Tomcat la ruta para la máquina virtual de Java?. Para desvelar este misterio, sólo miramos el script de arranque de Tomcat nos encontramos unas líneas como estas:

    # The first existing directory is used for JAVA_HOME (if JAVA_HOME is not
    # defined in $DEFAULT)
    JDK_DIRS="/usr/lib/jvm/java-6-openjdk /usr/lib/jvm/java-6-sun /usr/lib/jvm/java-1.5.0-sun /usr/lib/j2sdk1.5-sun /usr/lib/j2sdk1.5-ibm"
    

    Como puedes ver, primero mira si existe la máquina de código libre, que no nos interesa para nada, y luego el resto (en mi caso, la maquina virtual de Java es el segundo directorio). En este punto tienes dos opciones, definir la variable de entorno «JAVA_HOME» o borrar la primera ruta de de la variable «JDK_DIRS». Pero si lo hacemos elegantemente, solo tenemos que ir a el fichero «/etc/profile» y añadir estas lineas:

    # Ten en cuenta que tu ruta a la maquina virtual puede cambiar
    export JAVA_HOME=/usr/lib/jvm/java-6-sun
    export JRE_HOME=${JAVA_HOME}/jre
    export PATH=$PATH:${JAVA_HOME}/bin
    

    Actualización 22-03-10: Resulta que si hubiera leido ese fichero de configuración de Tomcat, me hubiera dado cuenta que usa un fichero «/etc/default/tomcat6«, en el cual puedes indicar que máquina virtual de Java utilizar sin tener que liar tanto follón, por lo que simplemente nos vamos a ese fichero y descomentamos la siguiente línea, incluyendo la ruta a la máquina virtual de Sun:

    # The home directory of the Java development kit (JDK). You need at least
    # JDK version 1.5. If JAVA_HOME is not set, some common directories for
    # OpenJDK, the Sun JDK, and various J2SE 1.5 versions are tried.
    #JAVA_HOME=/usr/lib/jvm/openjdk-6-jdk # Original que viene comentada
    JAVA_HOME=/usr/lib/jvm/java-6-sun # Mi modificación
    
  2. Poner el log en modo producción, lo cual hace que sea menos «verboso». Simplemente desde el interfaz web de Geoserver, en «Configuración global>Perfil de registro«, poner «Production» y aplicar.
  3. Dar recursos de sobra a Tomcat. No me seáis rácanos y dedicar una máquina completa al servidor, ya que va a ser muy exigente en cuanto a RAM. Para dar más recursos, tendremos que modificar los parámetros con los que arranca la maquina virtual que contiene a Tomcat, dentro del fichero «/etc/init.d/tomcat6«, buscaremos la línea que rellena la variable «JAVA_OPTS«:
    # Default Java options
    # Set java.awt.headless=true if JAVA_OPTS is not set so the
    # Xalan XSL transformer can work without X11 display on JDK 1.4+
    # It also looks like the default heap size of 64M is not enough for most cases
    # so the maximum heap size is set to 128M
    if [ -z "$JAVA_OPTS" ]; then
            JAVA_OPTS="-jvm server -Djava.awt.headless=true -Xms1024m -Xmx1024m -XX:NewRatio=2 -XX:+AggressiveOpt -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyM$
    fi
    

    Actualización 22-03-10: De nuevo esto se puede hacer en «/etc/default/tomcat6«, escribiendo la linea siguiente:

    # Ponlo en una única línea"
    JAVA_OPTS="-jvm server -Djava.awt.headless=true -Xms1024m -Xmx1024m -XX:NewRatio=2
    -XX:+UserParalleGC -XX:+AggressiveOpt -XX:MaxPermSize=128m
    -XX:SoftRefLRUPolicyMSPerMB=3600"
    

    Esta configuración, que parece muy complicada, indica que Tomcat arranque con una máquina virtual con los siguientes parámetros:

    • -jvm server: Arranque de una máquina virtual en modo servidor, que da más rendimiento.
    • -Djava.awt.headless=true: Usar librerías AWT pero sin usar una ventana (no se muy bien porqué pero lo recomiendan en todos los foros).
    • -Xms1024m -Xmx1024m: Usará como mínimo 1Gb de memoria RAM y también 1Gb como máximo.
    • -XX:NewRatio=2 -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyM$: Como limpiar los objetos que se tienen en memoria…
    • -XX:+AggressiveOpt: Optimizaciones experimientales.

    Actualización 2-12-10: En una nueva actualización los parámetros de optimización de la máquina virtual de Java, que he podido utilizar han sido:

    JAVA_OPTS="-server -Djava.awt.headless=true -Xms256m -Xmx512m -XX:NewRatio=2 -XX:MaxPermSize=128m -XX:SoftRefLRUPolicyMSPerMB=3600"
    

    Gran parte de estas recomendaciones, puedes leerlas más profundamente en el siguiente documento en formato OpenOffice.

  4. Instalar las extensiones «Java Advanced Imaging» para Java, las cuales nos ofrecen mayor rendimiento en el manejo de gráficos, que es parte de lo que hace nuestro servidor de mapas: traducir de formatos cartográficos a imágenes.
    Primero, bajamos las librerias, donde hay que tener cuidado con elegir las correctas para tu sistema operativo y plataforma (x64 para sistemas de 64bits o i585 para sistemas de 32bits), en mi caso es un 32bits para una máquina linux:

    linux@svrmapas:~$ wget http://download.java.net/media/jai/builds/release/1_1_3/jai-1_1_3-lib-linux-i586-jdk.bin
    

    Ahora toca instalar:

    linux@svrmapas:~$ sudo cp jai-1_1_3-lib-linux-i586-jdk.bin /usr/lib/jvm/java-6-sun/
    linux@svrmapas:~$ cd /usr/lib/jvm/java-6-sun/
    linux@svrmapas:/usr/lib/jvm/java-6-sun$ sudo sh jai-1_1_3-lib-linux-i586-jdk.bin
    # Aceptamos la licencia
    Do you agree to the above license terms? [yes or no]
    yes
    Unpacking...
    Checksumming...
    
    0
    0
    Extracting...
    UnZipSFX 5.31 of 31 May 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu).
      inflating: COPYRIGHT-jai.txt
      inflating: DISTRIBUTIONREADME-jai.txt
      inflating: LICENSE-jai.txt
      inflating: THIRDPARTYLICENSEREADME-jai.txt
      inflating: UNINSTALL-jai
      inflating: jre/lib/i386/libmlib_jai.so
      inflating: jre/lib/ext/jai_core.jar
      inflating: jre/lib/ext/jai_codec.jar
      inflating: jre/lib/ext/mlibwrapper_jai.jar
    Done.
    linux@svrmapas:/usr/lib/jvm/java-6-sun$
    

    Ahora volvemos a visitar nuestra web de control de Geoserver, en el apartado «Estado del servidor», busca la línea «Native JAI» y que esté a «true».

  5. Instalar las extensiones «JAI Image I/O» de Java para ayudar aun más la escritura y lectura de las imágenes. Solo hay que seguir unos pasos similares que con el paquete anterior, aunque con algún cambio:
    linux@svrmapas:~$ wget http://download.java.net/media/jai-imageio/builds/release/1.1/jai_imageio-1_1-lib-linux-i586-jdk.bin
    linux@svrmapas:~$ sudo cp jai_imageio-1_1-lib-linux-i586-jdk.bin /usr/lib/jvm/java-6-sun/
    linux@svrmapas:~$ cd /usr/lib/jvm/java-6-sun/
    linux@svrmapas:/usr/lib/jvm/java-6-sun$ sudo su
    root@svrmapas:/usr/lib/jvm/java-6-sun-1.6.0.15# export _POSIX2_VERSION=199209
    root@svrmapas:/usr/lib/jvm/java-6-sun-1.6.0.15# sh jai_imageio-1_1-lib-linux-i586-jdk.bin
    # Acepta la licencia
    Unpacking...
    Checksumming...
    0
    0
    Extracting...
    UnZipSFX 5.31 of 31 May 1997, by Info-ZIP (Zip-Bugs@lists.wku.edu).
      inflating: COPYRIGHT-jai_imageio.txt
      inflating: DISTRIBUTIONREADME-jai_imageio.txt
      inflating: ENTITLEMENT-jai_imageio.txt
      inflating: LICENSE-jai_imageio.txt
      inflating: THIRDPARTYLICENSEREADME-jai_imageio.txt
      inflating: UNINSTALL-jai_imageio
      inflating: jre/lib/i386/libclib_jiio.so
      inflating: jre/lib/ext/jai_imageio.jar
      inflating: jre/lib/ext/clibwrapper_jiio.jar
    Done.
    

    Actualización 10/04/2012: Me he encontrado con problemas en esta instalación, con equipos de 64bits. Al parecer no funciona y devuelve un error del tipo «tail: no puedo abrir `+215′ para lectura«. El error viene de lejos pero como no, Oracle no tiene ganas de arreglarlo. La única solución que he encontrado es esta:

    sed s/+215/-n+215/ jai_imageio-1_1-lib-linux-amd64-jdk.bin > jai_imageio-1_1-lib-linux-amd64-jdk-fixed.bin
    # Usar el nuevo instalable "fixed"
    

    Y tras reiniciar Tomcat, ya tendremos de nuevo disponibles estas nuevas librerías. Como siempre, si queremos ver si todo ha ido bien, solo tendremos que ir a «Geoserver>Estado del servidor» y allí buscar la línea «JAI ImageIO nativo» y ver que se ha puesto a «true».
    Al final tendremos algo así:

    Tras la instalación de las librerias y la maquina Sun tendras que ver algo así en Geoserver

    Tras la instalación de las librerias y la maquina Sun tendras que ver algo así en Geoserver

  6. Cambiar el directorio de datos de Geoserver. Es una buena opción, para facilitar actualizaciones y poder trabajar sin miedo a que una actualización machaque nuestra configuración. Para esto hay que buscar donde Tomcat despliega las apliacaciones, en el directorio: «/var/lib/tomcat6/webapps/geoserver/WEB-INF/» ahora dentro de la carpeta encontraremos un fichero muy importante «web.xml». en el se pueden tocar varios parámetros, pero nos centraremos en la siguiente parte:
    
       GEOSERVER_DATA_DIR
       C:\eclipse\workspace\geoserver_trunk\cite\confCiteWFSPostGIS
    

    Como ves, esta comentado, quita los comentarios y cambia la ruta (curiosamente la versión linux tiene una dirección Windows (?) que obviamente no va ha funcionar).
    Una buena política es poner un segundo disco, si se puede, que favorecerá mucho el acceso paralelo a datos y al servidor.

    Seguiremos contando como trabajar con la base de datos en la siguiente parte.

Referencias de este artículo:

Please follow and like us:

Geoserver en entorno de producción (I): Instalación básica

Este post inicia un serie de otros post que vendrán más adelante, en los cuales voy a detallar como voy a diseñar e introducir un servidor de mapas ( en un entorno de producción. Esta guía trata de resumir todo lo que he investigado, a lo largo de unas semanas, para realizar todo lo mejor posible, y con el mayor rendimiento posible también.

En este post, sólo voy a instalar Geoserver y dejarlo funcionando como una aplicación de Tomcat. Nada más. En siguientes post, hablaremos de la arquitectura de red que plantearemos, las librerías que pueden mejorar el rendimiento, y como añadir alguna funcionalidad extra.

Para empezar, voy a explicar porqué elegimos Geoserver, entre tantos y tantos servidores de mapas. Aunque este servidor, esta desarrollado en Java, resulta ser bastante rápido, cuando se configura correctamente, plantando cara a Mapserver, que se encuentra desarrollado en C++ (se pueden ver muchas comparativas sobre estos dos servidores de mapas), y además esta avanzando a pasos agigantados versión tras versión. Es (como no) software libre, con una gran comunidad detrás, que suelen dar soluciones a todos los problemas encontrados. Aparte de ser «relativamente sencillo» su manejo.

En cuanto al sistema operativo, me decanto por un linux, en mi caso un «Ubuntu Server 9.10«, simplemente por costumbre, ya que se podría usar cualquier otra distribución de linux para hacer la implantación.

Bueno, manos a la obra. Os detallo los pasos a seguir, para realizar una instalación básica:

  1. Instalar «Java JDK«, primero comprobaremos que no está ya instalada (en mi caso ya está instalado el Java):
    linux@svrmapas:~$ dpkg --get-selections | grep sun-java
    sun-java6-bin                                   install
    sun-java6-jdk                                   install
    sun-java6-jre                                   install
    

    En caso de no tenerlo instalado, lo hacemos vía «apt«:

    sudo apt-get install sun-java6-jdk
    

    Actualización Ubuntu 10.04: Parece que con los problema que está habiendo con Oracle, y que demuestran que es el mal supremo (apreciación mía), se han movido los paquetes oficiales (que siguen llamándose «sun-java» curiosamente) a un repositorio externo que no viene por defecto. Así que tocará añadirlo en el fichero «/etc/apt/sources.list«, descomentando dos líneas que vienen comentadas por defecto:

    ## Uncomment the following two lines to add software from Canonical's
    ## 'partner' repository.
    ## This software is not part of Ubuntu, but is offered by Canonical and the
    ## respective vendors as a service to Ubuntu users.
    deb http://archive.canonical.com/ubuntu lucid partner
    deb-src http://archive.canonical.com/ubuntu lucid partner
    
    

    Recuerda lanzar un «update» de «apt-get» para reflejar los cambios

    Si todo ha ido bien, encontraras algo parecido a esto al teclear el siguiente comando:

    linux@svrmapas:~$ java -server -version
    java version "1.6.0_0"
    OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu1)
    OpenJDK Client VM (build 14.0-b16, mixed mode, sharing)
    

    Si tienes cualquier otra salida a este comando, tienes que revisar tu instalación de Java ya que es muy importante para el rendimiento usar la versión de Sun más moderna posible.

  2. Ahora toca el Tomcat, y es muy recomendable usar el «Tomcat 6«, aunque creo que es el que se instala por defecto desde la «Ubuntu 9.04«.
    sudo apt-get install tomcat6 tomcat6-admin tomcat6-common tomcat6-user tomcat6-docs tomcat6-examples
    
  3. Tenemos Tomcat funcionando, solo nos queda configurar quien tiene acceso al «Gestor de aplicaciones» de Tomcat, mediante la ruta: «http://tuserver:8080/manager/html«. Si entras, te pedirá un usuario y una clave. ¿Pero si no me la han preguntado?. Tranquilo, ve al fichero «/etc/tomcat6/tomcat-users.xml«, editarlo como sigue:
    <tomcat-users>
      <role rolename="tomcat"/>
      <role rolename="role1"/>
      <role rolename="manager"/>
      <user username="tomcat" password="tomcat" roles="tomcat,manager"/>
      <user username="both" password="tomcat" roles="tomcat,role1"/>
      <user username="role1" password="tomcat" roles="role1"/>
    </tomcat-users>
    

    Hemos hecho lo siguiente, definir un nuevo rol, llamado «manager«, el cual es el necesario para manejar las aplicaciones instaladas, y luego al usuario genérico «tomcat» le hemos datos el rol de «manager«. Revisa que no este comentado (por defecto vienen comentados todos los usuarios), ya que si no, no hacemos nada.
    Muy importante: Esto que he hecho no es seguro, solo para comprobar que todo funciona, tendrías que crear un usuario/password seguros si vas a dar acceso a tu servidor a todo el mundo, una vez comprobado que todo funciona, ya que si no sería muy fácil que alguien «malo» adivine lo que has hecho y pueda acceder a este gestor… e imagino que no quieres que ocurra.

    Actualización Ubuntu 10.04: Algunos cambios surgidos en la versión de Tomcat que se instala, hacen más recomendable este fichero de configuración, que le da permisos a un usuario para manejar todo el tomcat sin problemas:

    <?xml version='1.0' encoding='utf-8'?>
    <tomcat-users>
      <role rolename="manager" />
      <role rolename="admin" />
      <user username="mi_usuario_administrador" password="password" roles="admin,manager" />
    </tomcat-users>
    
  4. Ahora reiniciamos el servidor Tomcat:
    sudo /etc/init.d/tomcat6 restart
    
  5. Ya podremos acceder al «manager«, con el usuario con el rol de «manager«, mediante la dirección: «http://tuserver:8080:/manager/html«. Ahora nos vamos a la web oficial de Geoserver y nos bajamos la versión «Web Archive«, como indica la siguiente captura de la web (cuando redacto esto, vamos por la versión 2.0.1):
    Descargar Geoserver
    Ya tenemos, el archivo «war» (te bajaras un .zip, mira dentro), y la intentamos desplegar (es decir, algo parecido a instalar) en nuestro servidor Tomcat, mediante el siguiente interfaz que nos sale por defecto en el  gestor de aplicaciones: Desplegar War
    Una vez hecho, solo nos queda buscar «geoserver» en el listado de aplicaciones, y dar a arrancar… y tras unos instantes: FALLO. Bueno, todo no podía ser tan sencillo, pero no os pongáis nerviosos, está controlado. El error que lanza el interfaz es algo así:

    FALLO – No se pudo arrancar la aplicación en trayectoria de contexto /geoserver

    Actualización Geoserver 2.0.2: Parece que todo esto ya es cosa del pasado, ya que se se despliega sin problemas, y sin dar mas permisos en Tomcat.

  6. El problema anterior, es un problema de permisos, ya que por razones desconocidas, Tomcat viene con los permisos muy recortados y Geoserver necesita prácticamente todos los permisos. Por lo tanto, nos vamos a «/etc/tomcat6/policy.d/04webapps.policy» y al final del fichero (justo antes de cerrar la llave) incluimos esta línea:
    permission java.security.AllPermission;
    

    Volvemos a reiniciar el Tomcat, y probamos de nuevo. No me voy a meter si esto es bueno o malo, si relaja mucho las políticas de seguridad… simplemente hace que funcione.
    Tras esto, al dar a arrancar a la aplicación, nos encontramos con:

    OK – Arrancada aplicación en trayectoria de contexto /geoserver

  7. Accedemos a la aplicación Geoserver, en «http://tuserver:8080/geoserver«. Cruza los dedos, y allí tendrás tu panel de administración de Geoserver.
Los siguientes pasos podrás leerlos en la siguiente entrada: Parte 2.

Referencias usadas:

Please follow and like us:

Filtar por MAC en un DD-WRT y una Fonera+

¿Os dije lo maravilloso que me parecía el DD-WRT como firmware de un router?… bueno, no todo es tan bonito.

Hoy he estado peleando una dura batalla, y al final la he ganado. Ha sido con el maldito filtrado MAC de en un DD-WRT v24-sp2 con mi Fonera+. La cuestión es que por razones varias, tengo que tener dos interfaces Wifi, uno con WPA y otro con WEP, y sinceramente del WEP sólo no me fío, así que he puesto también un filtro por MAC… bueno lo he intentado mediante el interfaz web.

Os cuento, mediante el interfaz Web, no es posible (yo no lo he logrado), ya que cuando rellenas la MAC y pulsas «Aplicar«, esta no que queda fijada, y se queda todo otra vez en blanco. Pero lo bueno del DD-WRT es que se basa en Linux, así que filtremos al viejo estilo con la línea de comandos y un magnifico comando llamado «iwpriv«. En vuestro router con DD-WRT buscais la sección del interfaz web: «Administración>Diagnóstico>Commando Shell«, y ponéis lo siguiente:

iwpriv ath0.1 maccmd 1
iwpriv ath0.1 addmac XX:XX:XX:XX:XX:XX

El primer comando, indica que queremos hacer. Con un «1», creamos una lista de filtrado MAC de equipos que tienen permiso para entrar a en red (o «WhiteList» o «Lista blanca«), asociada al interfaz que marquemos (en mi caso «ath0.1», uno virtual). Si pusiera un «2» sería una lista para equipos que no tienen permiso (o «BlackList» o «Lista negra«), y un «3» borra la lista asociada al interfaz, ya sea blanca o negra.
El segundo comando, es añadir una MAC a la lista del interfaz «ath0.1», el cual posee una MAC como se indica. El método más sencillo para tener las MAC, es quitar las listas de acceso, conectar los cacharros, ver el interfaz su MAC, y luego usarla en los comandos que os he indicado.

Hay otros comando muy interesantes, que usan el «iwpriv», como estos:

iwpriv ath0.1 delmac XX:XX:XX:XX:XX:XX
iwpriv ath0.1 kickmac XX:XX:XX:XX:XX:XX

La primera borra una MAC de la lista que hemos creado (blanca o negra), y el siguiente corta una conexión de esa MAC con nuestro interfaz, en otras palabras, le echa de tu Wifi.

De todas formas, os dejo de donde he sacado toda esta información.

Please follow and like us:

Reciclando una Fonera+, medinate DD-WRT, para usarla como router para ONO

fon-dd-wrt-300x240Hace tiempo que comenté por el foro, que ya no quería formar parte de FON, que no era lo que esperaba, por lo que iba a pasar de tener enchufado un cacharro más en mi casa. Así fue, como la Fonera (en concreto una Fonera+ modelo 2201) se quedo metida en su cajita, y iba a ir a la basura… Pero, ¡qué suerte tiene este chisme!.

Mi hermana, tiene la enorme suerte de vivir en una zona donde ONO tiene 50 megas… si, 50Mb/3Mb para ser exactos. Sin pensarlo lo contrató (más bien, se lo subieron ya que ya tenía ONO), y la comentaron que el router actual, no funcionaría a esa velocidad y que le mandaban uno nuevo. Pero claro, no la comentaron que era un modem, lo que implica que se quedaba sin Wifi, y tener que tener un firewall como dios manda (mi hermana es la típica adicta al messenger que no entiende de nada más). Entonces pensé en la Fonera, muerta de asco, pero no quería que mi hermana tuviera FON, ya que no le iba a meter el marrón a ella.

Basicamente mi esquema mental, de lo que quería hacer, era esto:

DiagramaFonera

Solo tuve que mirar un poco por Google para encontrar la solución: Flasearla a otro firmware que le hiciera funcionar como router neutro y le diera todas las funcionalidades Wifi también, ya que estamos liados. Pero al principio, me acojonó un poco el tema, ya que parecía muy complicado (por ejemplo Iván López lo hizo hace 3 años y se tenía que montar parda para flasearla, con riesgo de cagarla), pero luego vi que todo había cambiado mucho con el paso del tiempo y todo era muchos mas sencillo. Y más aun cuando encontré una guía fabulosa en este blog (Superviviente 2.0, que os animo a visitar), donde te dan todas las herramientas necesarias para flasear a DD-WRT y te lo explica paso a paso como hacer un flash correcto.

Tras flasear te darás cuenta del montón de nuevas posibilidades que te da este gran firmware, y que te permiten hacer casi de todo con estos chismes, aparte de poder instalar este firmware en un montón de cacharros, no solo en la Fonera. También, quiero remarcar, que se puede flashear sin perder las funcionalidades de FON, y así seguir fieles al «espíritu» si no quieres desvincularte de este empresa. En este post no me voy a centrar en todo lo que puede hacer este maravillo firmware, ya que solo tienes que buscar por Google y tendrás toda la información que necesitas.

Una vez hecho todo (ser paciente, el flaseo lleva bastante tiempo, como 30 minutos), accedemos a la red 192.168.1.x que es donde se configura por defecto la Fonera con su nuevo firmware, y más concretamente, nuestro nuevo router estará en la 192.168.1.1. La primera vez, cambiáis usuario y password. Aun no conectéis el cable a la clavija WAN, ya que os recomiendo que os metáis antes en el interfaz y configuréis lo siguiente:

  • En el menú: Setup > Basic Setup > Internet Connection Type > Connection Type > DHCP
  • En el menú: Setup > Advanced Routing > Operating Mode > Router

¿Para que?, para que la Fonera reciba la ip, al igual que antes la recibía el PC, y en modo router, para que funcione de puerta de enlace con la funcionalidad añadida de ser un firewall. Ahora conectáis el cable que va del modem de ONO a la Fonera (clavija blanca) y esperáis. Es posible que el PC tarde en darse cuenta que la fonera ahora sirve todo, así que puede fallar, darle un tiempo o reiniciar.

Ahora solo os queda configurar los puertos en: Applications & Gaming > Port Forward. ¡Listo!. Ya tenéis un buen router neutro por muy poco dinero y muchas funcionalidades extras.

Please follow and like us:

Buscar alternativas a programas de forma sencilla

No sé vosotros, pero yo he tenido que buscar muchas veces una alternativa gratuita (o no) a un software para sustituirle. El típico: «¿un programa gratuito que sea igual que…?» o el más complejo: «¿y para mi Mac/Linux donde encuentro un programa igual a este?«. Esto realmente, es un verdadero quebradero de cabeza para muchos de los que nos dedicamos a esto de la «infosmática».

Pero en mi noches en vela, buscando un buen sustituto para Autocad, o para el Acrobat, he encontrado unas cuantas web que pueden ofrecer soluciones:

  • «Alternative To» a mí me ha solucionado muchas de esas preguntas con un solo click. Solo en su buscador, escribimos la aplicación, y nos devolverá un listado de aplicaciones que pueden sustituir a la que has elegido. Pero lo mejor, es que puedes filtrar por sistema operativo y por tipo de licencia (gratuito, open source o de pago). Otro punto a favor, es que han incluido un sistema de «votos» donde la gente vota la mejor alternativa, para no perdernos en la larga lista que nos suele ofrecer. Por ejemplo, hace no mucho busqué alternativas a «Microsoft Visio», y me encontró alguna que no conocía, y que ahora estoy testando.
  • «CD Libre» es una recopilación hecha sin ánimo de lucro hecho por un profesor de un instituto de Valencia. Un crack. Aunque últimamente no amplia mucho su catálogo, hay que reconocer que hay un montón de aplicaciones ordenadas.
  • «Alternativas Libres«. No está mal, pero tiene ciertas lagunas en programas claves. Es bastante sencillo de buscar ya que saca tablas en donde se ve que programa de pago tiene alternativas. Lo usé mucho un tiempo, cuando comencé a luchar con estos temas. Me han comentado que está algo parado.

Bueno, espero que os sea de ayuda.

Please follow and like us:

Como recuperar un Raid0 tras un fallo de disco en Ubuntu

Hoy me he enfrentado a este problema. Uno de nuestros servidores de respaldo (al menos no era un principal) ha muerto. Tras mirar que ocurría, sencillamente que el raid no existía, nos hemos dado cuenta de que un disco duro había pasado a mejor vida. Obviamente, al ser un Raid0 se pierde toda la información (por lo que hay que tener un respaldo, ya sea en otro equipo, o mediante otro raid), y en nuestro caso, este servidor era el respaldo de otro, por lo que simplemente hay que recuperarlo y volver a sincronizar con el principal.

Antes de nada, recordaros un gran blog que habla mucho sobre estos temas y muchos más, como es el blog de Iván López, que merece ser leído ya que ha hecho cosas muchos más complejas que esto, y del cual saco mucha información que vas a leer más adelante.

¿Como vimos el fallo?. La verdad que fue sencillo ya que tuvimos un apagón y el servidor no se recuperó bien, mediante el comando podemos ver el desastre:

more /proc/mdadm

Todos los discos que forman el raid se encuentran con una (S) a su lado (son discos spare) y falta uno. En nuestro caso, teniamos 7 discos, y solo salian 6.

sudo mount

Y nos encontramos que el raid no esta montado… bueno, toca buscar el disco duro roto. Un buen método es mirar el dmesg y ver cual da error, en nuestro caso no quedaba claro (la bios de la máquina marcaba el disco como conectado, pero luego linux no era capaz de mostrarlo), se fue desconectando uno a uno cada disco hasta que le encontramos. Se substituyo por uno de igual capacidad, ya que no es recomendable mezclar capacidades en Raid0.

Bien, pues substituimos el disco duro que esta averiado por el nuevo, pero este no está preparado para formar parte de un raid, por lo que lo conectamos y arrancamos la máquina (obviamente no montará el raid) y abrimos Gparted (en su defecto lo instalas). Le creas una nueva tabla de particiones, lo formateas a capacidad completa con el tipo de ficheros «sin formato». Aplicamos y luego nos vamos al menú de «Partición > marcas» (no recuerdo exactamente como se dice en castellano, en ingles es «flags», ya que mi servidor esta en inglés) y marcamos sólo «raid» de todas las opciones que nos aparecen. Aceptamos y el disco duro ya está preparado para ser parte de un raid.

Ahora tocaba eliminar todo rastro del antiguo raid, primero en los discos anteriores:

# Se tiene que parar o dará un error de que está en uso.
# Si se tienen dudas mirar en /proc/mdadm
sudo mdadm --stop /dev/md0
# Si incluyes el disco duro nuevo, este dará un error
#  no importará sigue adelante
sudo mdadm --zero-superbloc /dev/sd[a-g]1

Ya tenemos los discos impolutos y listos para volver a montar, pero antes hay que eliminar cualquier configuración de la existencia de raid en «/etc/mdadm/mdadm.conf» eliminando cualquier linea del tipo:

ARRAY /dev/md0 level=raid0 num-devices=7 UUID=1803e03e:db1868b2:d2508c3c:95c11b58

Aunque esto último no es obligatorio, ya que se va a reescribir unos pasos mas adelante, nos vendrá muy bien por si necesitamos un reinicio en la máquina, y así el sistema no tratará de montar de nuevo el raid con el fallo de disco.

Tras esto, ya podemos volver a crear nuestro raid:

sudo mdadm --create --auto=yes --verbose /dev/md0 --level=0 --raid-disks=7 /dev/sd[a-g]1

Ojo, que el parámetro auto del comando mdadm es muy interesante, ya que crea, si no existiera, el dispositivo md0, dentro del directorio «/dev«. Si has hecho un reinicio seguramente no tengas dicho dispositivo ya que se elimina si no esta en uso.

Bien, comprobamos que todo funciona, formateando la nueva partición:

sudo mkfs.ext3 -v /dev/md0

Con un simple:

sudo mount -a

remontamos el sistema de ficheros, y podemos acceder al raid. Perfecto.

Ahora queda el paso final, y es volver a crear el fichero /etc/mdadm/mdadm.conf:

cd /etc/mdadm
sudo cp mdadm.conf mdadm.conf.`date +%y%m%d`
sudo sh -c 'echo "DEVICE partitions" > ./mdadm.conf'
sudo sh -c 'mdadm --detail --scan >> ./mdadm.conf'

Testeamos que todo este bien:

more ./mdadm.conf
DEVICE partitions
ARRAY /dev/md0 level=raid0 num-devices=7 UUID=bed08171:06afc57d:9c8da9aa:858c4c7d

Y ahora solo queda sincronizar el contenido, en mi caso con un rsync que va a tardar al menos unas 6 horas en sincronizar mediante una gigalan directa entre servidores, pero puedes hacerlo como sea, como por ejemplo discos duros externos, y ya tu raid vuelve a funcionar tras el susto del fallo del disco.

Actualización: Aveces, si usamos en el fichero «/etc/mdadm/mdadm.conf» la linea «DEVICES partitions«, al reiniciar no funcionan correctamente los raid, y cuando se realiza un «mdadm –examine /dev/sdxx» nos encontramos que tienen un diferente UUID que no cuadra ni con el fichero «mdadm.conf«.

Para evitar esto, la única solución que he logrado, gracias a esta entrada de la web de Ubuntu-es, encontrar es eliminar la entrada de los «DEVICES» y poner en el fichero «mdadm.conf«:

# Obviamente pon los devices que use tu raid
ARRAY /dev/md0 level=raid0 num-devices=3 metadata=00.90 UUID=e1fbf1e6:da616113:e368bf24:bd0fce41 devices=/dev/sda2,/dev/sdb1,/dev/sdc1

Al añadir al final los «devices» los monta correctamente, y sin hacer cosas raras. Según leo, no es muy recomendable (no se porqué) pero hace que al menos en mis maquinas no falle.

Please follow and like us:

Plataforma eBox, todo en uno en servidores

Una de las tareas más tediosas de un administrador de sistemas, es siempre tener un buen proxy configurado y apunto para tu empresa. Y digo tediosa, porque resulta bastante «dura» si lo haces desde cero, es decir, un linux con un proxy (normalmente SQUID), con un firewall mediante iproute y iptables, y de paso algun filtro para webs y un buen antivirus para parar las guarrerias que te puedas encontrar en la red y tus «lusers» quieran meter dentro de tu amada red.

Si nos ponemos un poco serios, podriamos montar un servidor de correo, y claro, un buen sistema de monitorización. Y si ya tienes que dar acceso desde fuera pues una buena VPN sería algo necesario.

Bien. Todo esto se puede montar más o menos «a mano», leyendo muchos manuales, acostumbrandote a tu shell, y a un buen editor de texto (nano rulez!), pero muchas veces te apetecería que todo fuera más sencillo.

En esto, que nuestro querido proxy con Debian, este viviendo malos momentos (si, es una edad, y aunque es un gran servidor, su corazon de Pentium 3 Xeon puede fallarnos en cualquier momento, o cualquier otra parte de su anatomía). Para tal empresa, indagando por la red, nos hemos encontrado con una solución que nos va a permitir migrar todo rapidamente a un nuevo servidor, y darnos algo mas de «sencillez» al asunto.

Se trata de eBox, un desarrollo español, el cual no es más que unos paquetes para Ubuntu (versión 8.04 LTS), que nos permite incluir toda la funcionalidad, con un buen interfaz web, y una comunidad por detrás que nos ayuda y mejora el producto. Tras instalarlo en una maquina de prueba, la verdad que tiene muy buena pinta, con muchas cosas que nos sobran (aunque esta dividido en paquetes para cada funcionalidad), creo que va a ser el gran cambio en el corazón de nuestra red. Nos falta meter mucha mano al sistema, ya que hay que adaptarlo a la locura que tenemos montada en mi empresa, pero al menos parece que el inicio es prometedor. Pero lo mas interesante es el roadmap que tienen planteado. Sobre todo el tema del failover entre servidores, que puede ser muy interesante en grandes compañias (y que trataré de ver como funciona).

La verdad que el interfaz es bastante bueno, aunque no permite toda la funcionalidad que una maquina linux puede ofrecer, por lo que en algún caso tienes que tirar de consola (nada grave). Incluye servidor proxy, de correo, firewall, vpn, monitorización, eGroupWare (para centralizar una agenda y un servidor de contactos… lo que es muy interesante), servidor de ficheros, antivirus,…

Muy buena idea si tienes que montar un proxy en tu oficina o en tu casa. Echarle un vistazo.

Please follow and like us:

Ubuntu y las intel… ¿enemigos?

No se muy bien porque ocurre, pero cuando tu equipo tiene una intel, al instalar Ubuntu (en mi caso es una 8.10 con LTS, ya que va a ser un servidor), se te queda una pobre resolución de 800×600… y sin «displayconfig-gtk» que ha sido eliminado por «Sistema > Preferencias > Resolución de pantalla» que no sirve para nada en nuestro caso.

El problema reside en que no se detecta correctamente la tarjeta de video ni el monitor (no entiendo muy bien porque, pero dice que es cosa del driver de intel)…

Para arreglarlo, no nos queda otra que tirar de gedit y cambiar el fichero «/etc/X11/xorg.conf«:

Section "Device"
	Identifier	"Configured Video Device"
	Driver      "intel"
EndSection

Section "Monitor"
	Identifier	"Configured Monitor"
	HorizSync 31.5-48.5
        VertRefresh 40-70
        Option "dpms"
EndSection

Section "Screen"
	Identifier	"Default Screen"
	Monitor		"Configured Monitor"
	Device		"Configured Video Device"
EndSection

Mas info:

  • Ubuntu Forums (I, II, y III)
Please follow and like us: