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:

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:

Problemas al actualizar Ubuntu de 8.10 a 9.04

Bueno, he actualizado mi Ubuntu. No podía resistirme, y lo he hecho a la manera «dirty», es decir, actualizando desde el gestor de actualizaciones y rezando.

Aunque actualizar «clean», es decir, borrar y volver a instalar, es muy sencillo, ya que hay hasta scripts para hacerlo automáticamente (básicamente guardar el Home y algún fichero del directorio «etc»).

Tras terminar mi instalación, y tras una semana sin tocarlo, he notado varios problemas (como no) al ponerme mirar que traia mas a fondo, aunque el rendimiento ha mejorado mucho y agradezco la sencillez del uso de dos monitores que ofrece.

Problema uno, no me funciona el autocompletado en la consola bash… mierda. Solución, Google y los Ubuntu Forums:

Ir a /etc/bash.bashrc y mirar que esta linea no esta comentada (en mi caso lo estaba):

if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi

Reinicio al canto y a correr.

Please follow and like us:

¿Error #1045 en MySQL con root en otro host (no localhost)?

ACLARACIÓN: No se muy bien porqué, pero la seguridad de WordPress, no me permite usar ciertas palabras, del lenguaje SQL. Para arreglarlo, donde veas un «3», pon una «e». Así de simple. Parece ser que ocurre a mas gente y hay una solución: aquí.

Esto me he encontrado en mi trabajo tras actualizar una maquina linux… no habia manera de conectar remotamente, y siempre nos daba un error 1045 (sin permisos). Solemos usar el usuario root, limitado a nuestra subred (al rango me refiero), sin password o con un password prefijado (que no os voy a contar :P) pero hoy no entraba de ninguna manera.

¿Que hacer?, muy sencillo (y parece que a mucha gente le asusta la consola de comandos) si tienes acceso a la maquina en localhost, y lo mas sencillo es hacer esto:

S3LECT host,user,password FROM user;

Comprobar que el usuario tiene el host correcto, es decir, que permite tener permisos a la máquina donde te conectas, y si tienes dudas (temporalmente) usa el simbolo «%», para decir que cualquiera (es un comodin). Usa el comando (la subred que ves será la tuya, o un host en particular):

UPDAT3 user SET host='%' WHERE user='root' AND host='192.168.0.%';

Una vez hecho esto, si ves que hay un password y todavía no te puedes conectar, seguramente es porque ese usuario desde ese host, tiene asignado un password que no coneces. Simplemente lo reseteamos:

UPDAT3 user SET password='' WHERE user='root' AND host='%';

Ahora no tendrás ningún problema en entrar… PERO tu servidor es tremendamente inseguro. Tras hacer comprobaciones, backups y esas cosas, pon un password a el root.

Please follow and like us:

Reinstalar una Ubuntu, y no perder tus datos…

Vía Incognitosis, a su vez vía hehe2.net, veo un manual magnifico de como volver a instalar una Ubuntu, tras una nueva salida de una versión del sistema o tras un desastre (mejor una imagen del sistema + backup del home, pero no todo el mundo lo hace… ni yo mismo xD), y volver a tener tus programas y todas tus configuraciones.

Simplemente se basa en hacer backup del home y de algunos ficheros del directorio etc para guardar la configuración (no creo que sea bueno copiar toda la carpeta como dice javipas, ya que si actualizáis la versión de Ubuntu, puede que algún fichero de configuración cambie su estructura y entonces al sobreescribirlo con la versión vieja la liemos), luego guardar los paquetes que hemos instalado, una lista de las aplicaciones instaladas (mas o menos), para luego recuperar todo tras instalar en limpio.

Simplemente genial.

Please follow and like us: