Openlayers, aplicando estilos propios a ArcGIS Server WMS

Una de funcionalidad muy interesante que nos ofrecen los servidores de mapas, con el protocolo “WMS” y mediante la petición “GetMap“, es poder aplicar nuestro propio “estilo” a las capas que nos ofrecen, solo suministrándole un archivo donde se detalla como cambiar el estilo visual de las capas que nos muestra mediante el estándar “Style Language Descriptor” o “SLD” para los amigos. Este estándar no deja de ser un “XML” con una estructura y etiquetas propias. No es muy complejo de entender. Además hay hasta editores para hacerte la vida mucho más sencilla escribiendo SLD, como este, que es totalmente visual.

Para que entendáis, que significa esto, si pedimos un capa a un servidor, de una cierta zona, podría devolvernos esto:

Capa antes de aplicar un estilo

Pero no nos gusta nada su presentación, y tras hacer un poco de magia, obtendríamos algo así:

Capa despues del estilo

Capa después de aplicar un estilo

Normalmente estos estilos están definidos en el servidor de mapas, y el usuario que consume dicho servicio le indica que estilo utilizar. Pero para completar un poco esta funcionalidad, se permitió que el usuario indique que estilo usar, dando en la petición una URL a un fichero de estilos, como por ejemplo:

http://servidor/GetMap?TRANSPARENT=true&LAYERS=RiverBasinDistrict&FORMAT=image%2Fpng&TILED=true&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A4326&BBOX=-1.69189453125,41.21172151054787,1.12060546875,43.29320031385282&WIDTH=256&HEIGHT=256&SLD=http://servidorPublico/misestilos.sld&STYLES=estilo

La parte en negrita, indica donde cambiamos el estilo, indicante el fichero de estilos, y el estilo a usar (que podría estar definido en dicho fichero o no). Si indicamos un estilo que no esta definido ni en el servidor ni en el fichero, obtendremos un bonito error, o obtendremos la capa con el estilo por defecto.

Existen grandes ejemplos para entender este capacidad, como por ejemplo esta web, donde se colorean los polígonos que representan los países según el nombre de dicho país. Bonito, y descriptivo.

Pero hay un problema, como casi con todos estos estándar. Cada uno lo implementa a su modo. Por ejemplo si vemos un fichero de estilo de un servidor de mapas “Geoserver”, este tiene una extensión “sld”, y una sintaxis muy relajada. ¿Pero y si trabajamos con ArcGIS Server WMS?, pues no es igual…

Ahora bien, tras esta larga introducción, no centramos en nuestro caso actual.

  • Openlayers, en mi caso, se uso la versión 2.7, con algunos retoques que no modificaban esta funcionalidad.
  • Servidor ArcGIS Server WMS sirviendo unas capas con un estilo horrible. Para estas pruebas, sólo se sabía que era ArcGIS, y aún no sabemos exactamente que versión exacta es.
  • Hojas de estilo sacadas de un servidor Geoserver en formato SLD. La hoja de estilos tiene que estar almacenada en un servidor web donde el servidor de mapas tenga acceso, es decir que si no está en tu red, tiene que estar en un servidor web conectado a internet.

Si tratas de incluir en OpenLayers el estilo, nos encontramos esto:

wms_1 = new OpenLayers.Layer.WMS( "Capa"
		,url_wms_GIS
		,{
		    transparent:'true',
		    layers: 'capa',
		    styles: 'estilopoligono',
		    sld: 'http://servidorPublico/poligono.sld',
		    format:'image/png',
		    tiled: 'true'
		},
		{
		    'reproject': true,
		    buffer: 0
		}
	);

Y nuestro fichero de estilo, el cual esta alojado en la URL “http://servidorPublico/poligono.sld”:

<?xml version="1.0" encoding="UTF-8"?>
<StyledLayerDescriptor version="1.0.0"
	xsi:schemaLocation="http://www.opengis.net/sld StyledLayerDescriptor.xsd"
	xmlns="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NamedLayer>
		<Name>capa</Name>
		<UserStyle>
			<Name>estilopoligono</Name>
			<Title>Estilo de un poligono</Title>
			<FeatureTypeStyle>
			<Rule>
				<PolygonSymbolizer>
					<Fill>
						<CssParameter name="fill">#995599</CssParameter>
						<CssParameter name="fill-opacity">0.3</CssParameter>
					</Fill>
					<Stroke>
						<CssParameter name="stroke">#000000</CssParameter>
						<CssParameter name="stroke-opacity">1</CssParameter>
					</Stroke>
				</PolygonSymbolizer>
			</Rule>
			</FeatureTypeStyle>
		</UserStyle>
	</NamedLayer>
</StyledLayerDescriptor>

Como puedes leer, en el fichero “sld” he incluido el nombre de la capa, y el nombre del estilo, y tienen que concordar con los escritos en Openlayers.

Todo parece correcto, pero al usarlo contra el servidor ArcGIS Server… esto no funciona, sencillamente te dice que el tipo de estilo no esta definido. ¡Mi gozo en un pozo!.

Pero no todo esta perdido, tras mucho mirar, y releer, me doy cuenta de lo de siempre, ArcGIS tiene “peculiaridades”, y es muy estricto, aunque gracias a dios, todo se encuentra muy bien documentado en su página de ayuda. Hay que remarcar, que la extensión pasa a ser “.xml”, y que ahora todas las etiquetas tiene el prefijo “sld”, aunque respeta el resto del estándar.

Hacemos unos cambios y ya tenemos la nueva versión:

<?xml version="1.0" encoding="UTF-8"?>
<sld:StyledLayerDescriptor version="1.0.0" xmlns="http://www.opengis.net/ogc" xmlns:sld="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd">
	<sld:NamedLayer>
		<sld:Name>capa</sld:Name>
		<sld:UserStyle>
			<sld:Name>estilopoligono</sld:Name>
			<sld:Title>Estilo de un poligono</sld:Title>
			<sld:FeatureTypeStyle>
				<sld:Rule>
					<sld:PolygonSymbolizer>
						<sld:Fill>
							<sld:CssParameter name="fill">#995599</sld:CssParameter>
							<sld:CssParameter name="fill-opacity">0.2</sld:CssParameter>
						</sld:Fill>
						<sld:Stroke>
							<sld:CssParameter name="stroke">#0000FF</sld:CssParameter>
							<sld:CssParameter name="stroke-opacity">1</sld:CssParameter>
							<sld:CssParameter name="stroke-width">1</sld:CssParameter>
						</sld:Stroke>
					</sld:PolygonSymbolizer>
				</sld:Rule>
			</sld:FeatureTypeStyle>
		</sld:UserStyle>
	</sld:NamedLayer>
</sld:StyledLayerDescriptor>

Y tras todo esto, ya podremos disfrutar de poder manejar el estilo con el que un servidor remoto nos sirva las imágenes de su cartografía.

Please follow and like us:

Geoserver en entorno de producción (V): Configurando PostgreSQL 8.4 y PostGIS 1.5

Soy muy pesado, pero vuelvo sobre mis pasos para tratar de dejar la instalación perfecta, ya que me he dado cuenta “googleando” un poco, que me pierdo una gran funcionalidad si no instalo PostGIS 1.5 (en anteriores manuales explique como se instalaba la 1.4), que es subir a la base de datos “shapefiles” desde PgAdmin mediante un plugin.

Pues, tras una búsqueda muy rápida, he encontrado este manual, donde, el amigo Nick, lo explica mucho mejor que yo.

A ver si con esta va la última “Reversión” de mi base de datos espacial.

Actualización:
si os aparece el error: “ERROR could not load library /usr/lib/postgresql/8.4/lib/postgis-1.5.so“, aquí tenéis la solución.

Please follow and like us:

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

No, no habéis vuelto al pasado. Rectificar es de sabios, y más aún cuando mejoras lo dicho. Y este post es exactamente esto, una corrección y una mejora a mi explicación de como instalar una base de datos libre espacial.

Tras empezar a meter datos en mi máquina con PostgreSQL y PostGIS, siguiendo el primer manual que os dejé, me he dado cuenta que esto no funcionaba muy bien, ya que inicialmente no se instalaba PostGIS hasta que no lanzaras un archivo SQL, y luego, fallaba al devolver algunos objetos vectoriales. Recordemos que todo estaba montado con los paquetes estándar de Ubuntu 9.10.

Bueno, tras leer, me di cuenta que la gente recomienda la versión 8.4 de PostgreSQL y la 1.4+ para PostGIS. Pero hay un problema muy gordo, ya que no hay paquete PostGIS para esta versión de PostgreSQL en los repositorio oficiales de Ubuntu. Maldita sea, toca recompilar.

Me mentalizo, tengo que coger el código fuente, y ponerme a compilar, pero por desgracia, la versión actual, 1.5, de PostGIS, tiene unas dependencias que no puedo cumplir (Ubuntu no tiene aún las librerias libgeos-3.1.1, si no las 3.1.0, para mi versión de Ubuntu) con librerías estables liberadas, por lo que usaré la versión 1.4.2, pero en cuanto salga esta versión de las librerías ya podré usar la 1.5 siguiendo este mismo manual.

  1. Empecemos, instalando la versión 8.4 de PostgreSQL:
    sudo aptitude install postgresql-8.4
    
  2. Volvemos a configurar el servidor PostgreSQL, siguiendo el antiguo manual, para darnos acceso remoto.
  3. Ahora nos instalamos unas cuantas librerías que necesitaremos más adelante:
    sudo apt-get install proj-bin libproj-dev gdal-bin postgresql-server-dev-8.4 libgdal-dev libgeos-dev build-essential
    # Esto puede tardar un poco... tómate un café...
    

    Ahora ya tenemos todas las herramientas necesarias.

  4. Como recomendación personal, os recomiendo instalar, opcionalmente el paquete “checkinstall” ya que nos permite crear un archivo .deb, desinstalable mediante “aptitude”, a partir de un ejecutable con su código fuente. Para obtenerlo ponemos:
    sudo apt-get install checkinstall
    
  5. Pasamos a bajar el código fuente de PostGIS de su web oficial. Os recuerdo que yo uso la versión 1.4.2, ya que no tengo ciertas librerías aun disponibles en la versión 9.10 (al menos en su versión estable), pero que si tienes una versión más antigua o la LTS, están portadas en esta web en su versión estable. Recordemos que vamos a instalar un servidor en producción y que la estabilidad es fundamental.
    sudo wget http://postgis.refractions.net/download/postgis-1.4.2.tar.gz
    sudo tar xvzf postgis-1.4.2.tar.gz
    cd postgis-1.4.2
    sudo ./configure
    sudo make
    sudo checkinstall -D
    # Le ponemos un nombre al paquete
    # que es como aparecerá en el listado
    # de "aptitude search"
    # y confirmamos
    
    # Solo en el caso que no hayas instalado 
    # el programa "checkinstall"
    sudo make install
    

    Rezamos porque no haya ningún problema de dependencias ni librerías, aunque en Ubuntu 9.10 no tuve ninguna.

  6. Pero tenemos un problema, ya que si usamos PgAdmin, nos damos cuenta que no hay ningún template (plantilla) creado para postgis. Si usas Windows, esta se crea al instalar PostGIS pero en linux se complica un poco. Sin esta plantilla, cada vez que se crea una nueva base de datos, tenemos que lanzarle varios SQL para incluir toda funcionalidad espacial, y dar permisos a ciertas columnas. Pero si tenemos la plantilla, solo tenemos que elegirla en el momento de la creación para tener todo esto.
    Vamos a crear la plantilla:

    sudo su postgres # Cambiamos al usuario de mantenimiento de PostgreSQL
    createdb -E UTF8 template_postgis # Creamos la base de datos
    createlang -d template_postgis plpgsql
    #
    psql -d postgres -c "UPDATE pg_database SET datistemplate='true' WHERE datname='template_postgis';" # La hago visible para su uso
    # Es importante remarcar que el fichero lwpostgis.sql ha cambiado de nombre a postgis.sql
    psql -d template_postgis -f /usr/share/postgresql/8.4/contrib/postgis.sql # Creo todas las funciones/tablas para habilitar todo
    psql -d template_postgis -f /usr/share/postgresql/8.4/contrib/spatial_ref_sys.sql
    #
    psql -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;" # Acceso a todo el mundo
    psql -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"
    # La dejamos fija ante cambios
    VACUUM FREEZE;
    

    Si todo ha ido bien, ahora al crear una base de datos nueva, veremos esto:

    Al crear una nueva base de datos, tendremos acceso a la nueva plantilla

    Al crear una nueva base de datos, tendremos acceso a la nueva plantilla

  7. Incluimos el “adminpack” como te expliqué en el antiguo manual.
  8. Para testar que todo ha ido bien, desde PgAdmin, abrimos una consulta SQL y escribimos esto:
    select postgis_lib_version();
    

    Y veremos algo así:

    Versión de PostGIS mediante SQL

    Versión de PostGIS mediante SQL

Como siempre, de donde he leido toda la información que os condenso en este post:

Please follow and like us:

Geoserver en entorno de producción (IV): Habilitando GDAL y su soporte para formatos

Esto se está haciendo eterno, pero desde luego esta costando mucho lograr todo lo que me he propuesto. En este caso, me voy a centrar en ampliar los tipos de datos que va a aceptar nuestro servidor de mapas. Y esto me ha dado dos días de guerra. Os recuerdo mi configuración: Ubuntu 9.10 Server, Geoserver 2.0.1 y Tomcat 6. También os recuerdo que si queréis empezar con una instalación limpia, hay 3 manuales anteriores que encontraréis más abajo.

En este caso, vamos a instalar las librerías necesarias para que nuestro Geoserver sea capaz de leer formatos soporta la librería GDAL, entre los que están ECW, MrSID, EHdr, DTED, rasters de ERDAS,  etc…

Importante: Por desgracia, en esta ampliación tendremos un problema con las licencias para utilizar ECW en nuestro servidor, ya que para usarlo hay que usar unas librerías de ERDAS bastante restrictivas, y tendremos que tener un licencia (obviamente de pago, es decir, comprada) para usarlo sin romper la licencia de sus librerías, que no permiten su uso libre en servidores de mapas de terceros. En este tutorial se explica como activar el soporte para ECW, pero contamos con que se tienen las licencias compradas de antemano.

Manos a la obra, empecemos por el principio:

  1. En versiones antiguas de Geoserver hay que instalar un plugin dentro del directorio “WEB_INF/lib” de Geoserver, el cual puedes encontrar aún, en la página de descargas de Geoserver, en el apartado “Extensions>GDAL“. En la versión 2.0.1, ya viene de serie, por lo que no hace falta hacer nada.

Bajar las librerías nativas de GDAL del proyecto “ImageIO-ext” en esta dirección, no tengo que decirte que busques la versión más moderna y para tu sistema operativo, bájate las “native-libraries“. Estas librerías son totalmente independientes de las que tengas instaladas en tu equipo. Es decir, si hay tenias GDAL instalado vía apt/aptitude o porque tu te las instalaras a mano, no interfieren con estas.

Actualización 10-08-21: De nuevo, las cosas han cambiado, ya que como todos sabemos, Java ahora pertenece al eje del mal, es decir Oracle. Y como no, ha tenido que cambiar todo de sitio. Las nuevas direcciones para encontrar las cosas son:

Todas estas librerías son para el GDAL 1.7.3, el cual es el que esta disponible en los repositorios de Ubuntu, en caso de no tenerlo, no se si funcionará, aunque imagino que tendrás que instalarlo a mano para desgracia de nuestros nervios.
cd /usr/lib/
sudo wget https://imageio-ext.dev.java.net/files/documents/7505/144611/imageio-ext-1.0.5-linux32-mrsid-ecw-lib.tar.gz
sudo tar -zxvf ./imageio-ext-1.0.5-linux32-mrsid-ecw-lib.tar.gz
./
./libNCSCnet.so
./libNCSEcwC.so.0.0.0
./libNCSCnet.so.0
./gdalinfo
./libNCSUtil.so.0.0.0
./libNCSCnet.so.0.0.0
./libgdal.so.1
./libNCSEcw.so.0.0.0
./libNCSUtil.so.0
./libgdal.so
./libNCSEcwC.so.0
./libosrjni.so
./libNCSUtil.so
./libNCSEcw.so.0
./libNCSEcw.so
./libNCSEcwC.so
./libgdalconstjni.so
./libgdaljni.so
./libogrjni.so
./libgdal.so.1.11.4

Como habrás notado, he bajado la versión con soporte ECW (solo para probar que funciona), y lo he instalado en la carpeta “/usr/lib”. Si miras los manuales de referencia, todos te dicen que estas librerías puedes instalarlas donde te de la gana y luego fijar una variable de entorno “LD_LIBRARY_PATH” a la ruta para que todo funcione. En mi caso, esto no funcionaba, y la única manera de lograr que funcionara, era instalando estas librerías aquí.

Esto es importante, ya que no tengo muy claro donde se tiene que instalar las librerías nativas del GDAL (en serio, es un follón). Ahora mismo si no las descomprimo tambien en; “/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64” (es decir, en el directorio de mi versión por defecto de Java, y con la arquitectura, en 64 bits en mi caso, pero podría ser en i386 también), no me funciona. Simplemente trata de descomprimir en el directorio JAVA primero, y luego intenta en el directorio de librerías.

  1. Bajar los datos para la GDAL. Este fichero contiene definiciones de proyección y datos que se necesitan para usar esta librería, esta puedes instalarla donde quieras para luego fijar la variable de entorno “GDAL_DATA” para que GDAL sepa encontrarlas.
    cd /usr/share/gdal-data/
    sudo wget https://imageio-ext.dev.java.net/files/documents/7505/137749/gdal_data-1.4.5.zip
    sudo unzip -o ./gdal_data-1.4.5.zip
    

    Ahora editamos el fichero “/etc/profiles” y añadimos la siguiente línea:

    export GDAL_DATA=/usr/share/gdal-data
    

    Y ya hemos instalado todo.

    Actualización 2-11-10: Según he aprendido a lo largo de mis andaduras con linux, el mejor sitio para poner las exportaciones de variables de entorno es en el fichero “/etc/environment“.

  2. Tendremos que reiniciar Tomcat, por seguridad de que refresque y ver reflejados los cambios. En alguna ocasión solo con recargar el Geoserver desde el “manager” de Tomcat me ha valido, pero no lo puedo asegurar.
  3. Ahora entramos en el interfaz Web de Geoserver, que usualmente está instalado en: http://tuservidor:8080/geoserver, y en el apartado “Almacenes de datos” pulsamos “Agregar nuevo almacén”, y tendremos que ver una lista parecida a esta:

    Formatos soportados tras instalar la extensión de GDAL

    Formatos soportados tras instalar la extensión de GDAL

  4. Importante: Parece que están surgiendo problemas con estas librerías y Tomcat, y puedes leer como “arreglarlo” en el siguiente post. Para saber si te ocurre, sólo tienes que tratar de crear un almacén con cualquiera de los nuevos tipos que han aparecido y te saldrá un error. No es muy complicado de arreglar pero asusta 🙂

Como siempre, aquí tienes todas las referencias, de donde he sacado sabiduría:

Please follow and like us:

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:

¿Esta mi servidor de correo en una “blacklist”?

Una medida muy extendida de protegernos contra el spam, es que nuestro servidor de correo tenga una lista de servidores de correo marcados como “spammers”, o como se conoce en la jerga: “blacklisted“. Cuando un servidor de correo usa estas listas, revisa cada correo comprobando que la ip de envio del correo no se encuentra marcada como “spammer”, y en el caso que encuentre que esa ip envía spam, simplemente lo devuelve o simplemente no dice nada pero no llega a la cuenta del usuario.

Estas listas las suelen mantener ISP o organizaciones que luchan contra el spam, y se suelen mantener, con ayudas o cobrando a los “spammers” por quitarles de la lista (donde rápidamente volverán a entrar)… un doble rasero que no voy a entrar a valorar. Otro detalle, es que estas listas funcionan a nivel de ips, por lo que si tienes un hosting compartido y uno de tus “vecinos” es un “spammer”, la ip se marcará y por lo tanto tu también tendrás dicha marca.

Un escenario típico: un día un usuario llama al departamento y te dice que no puede enviar un correo, y que le devuelve un correo de error donde pone “blacklisted ip”. Esto usualmente, es que tu servidor ha enviado correo spam.

¿Como saber si tu servidor esta en esas listas?, pues la manera más simple es entrar en la web de “What is my ip address?” y poner la ip de tu servidor (ojo, todo funciona con ips), al rato tendrás un informe que ten indica en cuantas listas te encuentras “blacklisted”.

¿Que hacer cuando estés dentro de una lista?, pues visitar la web, y mirar como darte de baja… y tener paciencia.

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:

Recreativas de mi niñez (II): Nintendo PlayChoice-10

Que Nintendo marcó a toda una generación, no es ningún misterio, pero contar la historia de Nintendo, como empresa, suele sorprendernos con una cantidad de historias sobre culebrones internos e intentos de fabricación de cacharros varios que se quedaron en nada, o que triunfaron. Y no soy el más indicado (ni documentado) para hablar del tema, pero os puedo recomendar que busquéis por Internet la historia de la gran N (os recomiendo I, II y III aunque no son las únicas fuentes).

PlayChoice-10-Deluxe-EU

PlayChoice-10 (Deluxe versión Europea)

Recordando hoy, algunos de esto cacharros de la gran N que pude disfrutar en mi niñez, me ha venido a la mente un recuerdo de otro de estos chismes que salió de la fabrica de Kioto, que me ha parecido muy curioso: una recreativa de Nintendo que en vez de darte “vidas” para jugar te daba tiempo por cada moneda que introdujeras.

Esta máquina recreativa se llamaba “Nintendo PlayChoice-10“, que no era internamente más que unas Nintendo (míticas NES de sobremesa) con 10 juegos idénticos a los que podías en esos tiempos comprar para tu consola de sobremesa de la gran N. Bueno, no eran idénticos, ya que incluía “consejos”, los cuales estaban en perfecto inglés por lo que no recuerdo mucho que ponían, los cuales se mostraban en una pantalla superior en la cual también se podían elegir los juegos para jugar, aunque esto lo explicaré más adelante.

Por “sólo” 25 pts, tenías 300 segundos para jugar a cualquier juego de la lista, es decir, 300 segundos para jugar a un Nintendo de sobremesa, ya fuera a dobles o en solitario. Tenía muchas curiosidades, como por ejemplo que en tu tiempo, podías cambiar de juego dando a un botón de “reset”, volvías a la lista de juegos y podías continuar jugando.
Y se podía jugar a lo grande: tenías hasta una pistola “Zapper” como las consolas NES, por lo que podías jugar como en esta recreativa a juegos como el “Duck Hunt” que era lo más de lo más de la época, ya que como he dicho, esta recreativa no era más que una NES gigante.
Existían varios modelos de las cabinas, con uno o varios monitores, mi recuerdo se centra en la “gloriosa” cabina de dos pantallas grandes. En la pantalla superior, existía un menú donde se podía elegir el juego que querías, y cuando jugabas, te encontrabas en la pantalla superior los famosos “consejos” para el juego y el malvado contador de tiempo restante. Esta pantalla superior se controlaba con unos botones que estaban en una primera hilera más cercana al monitor, y en la segunda hilera estaban los de control de toda la vida. Cuando elegías un juego, la pantalla de abajo era una maldita NES, y jugabas hasta que el tiempo se consumía, pero sí el tiempo acababa la pantalla se ponía en negro y tenías un tiempo para volver a meter más pasta para continuar.

Todo un negocio, ya que el tiempo que te pasabas delante de la pantalla no dependía de tu destreza a los mandos, si no de un tiempo preestablecido. En mi barrio lo llamábamos timo. Pero tenía una parte muy buena, ya que permitía jugar a los juegos sin tener que comprarlos o tener que alquilarlos, y con los 300 segundos que te daban, podías ver rápidamente los 10 juegos que traia (que por cierto, si no recuerdo mal, no todas llevaban los mismos), por lo que fue uno de mis “tester” de juegos, antes de gastarme las 5000-8000 pelas de entonces.

¿No os enteráis?, normal… pero nada mejor que un vídeo para que veáis de que hablo.

Ah, y también me recuerda una cosa: que viejo me estoy volviendo.

Referencias a toda la información que he mirado para refrescar mi memoria:

Please follow and like us: