Instalando las vmware-tools en Ubuntu 10.04

Tener un servidor de máquinas virtuales es una gran idea, y instalar las “vmware-tools” es casi obligatorio, ya que no instalarlas sería un problema en cuanto rendimiento.

Sin duda todo parece muy facil,  ya que desde el interfaz web se pueden “instalar”. Bueno, realmente, sólo monta una iso como un CD, y tu lo instalas desde un tar.gz. Pero claro, no iba a funcionar, y te recomiendo que no pierdas el tiempo. Si quieres instalar estas herramientas ejecuta lo siguiente:

aptitude update
aptitude safe-upgrade
aptitude install open-vm-tools open-vm-dkms

Y dale un poco de tiempo. Y sin romperte la cabeza.

Actualización: Si utilizas una versión más moderna de Ubuntu (espero que sí), te recomiendo que uses este script que suelo usar en mis maquinas, y que te lo instala sin problemas, y con el fichero original de VMWare.

Please follow and like us:

Purgar la cola de impresión en el servidor de impresión de Windows 2003

Una tarea que puede ocurrir cuando centralizas en un servidor Windows 2003 todas las impresoras de un entorno corporativo es recibir una llamada de un usuario del tipo:

La impresora X no imprime, y por más que doy… ná. He reiniciado el ordenador 20 veces, le he rezado 20 avemarias al santo patrón de los BOFH, pero nada. ¡¡¡Arreglalo!!!.

Con resignación nos tocará levantarnos del sitio y tras descartar que el problema sea de la impresora, y ver que a la impresora no le llega nada de lo enviado (ese sería otro problema de no reproducirse este escenario que te cuento, luego busca en otro sitio: Este no es tu error), miramos con resignación a nuestro querido servidor de impresión.

Entramos en “Panel de control > Impresoras y faxes” o bien, mediante la pantalla de “Administre su servidor > Servidor de impresión“, allí miramos la impresora si tiene una impresión indestructible (si damos a cancelar y se queda eternamente “Eliminando…”). Si no queremos reiniciar el servidor, y de paso,no  dejar a los usuarios sin 20 minutos de servidor de impresión donde seguramente haya 3 personas con documentos que no pueden esperar ser imprimidos. La forma más rápida de solucionarlo puede ser esta (unos 2 minutos):

  1. Inicio > Herramientas Administrativas > Servicios“.
  2. Localizar “Cola de impresión” y pararla. No cierres esta ventana.
  3. Entra en “\WINDOWS\system32\spool\PRINTERS“. Puede que la ruta cambien un poco según donde tengas instalado el sistema operativo.
  4. Borra los ficheros *.SHD y *.SPL. Si no hay, comprueba que es allí donde se almacena la cola de impresión en el apartado de “Impresoras y Faxes > Archivo > Propiedades del servidor de impresión > Opciones Avanzadas > Carpeta de cola de impresión”. Si apunta a otra ruta, mira allí. Si tampoco están allí, este manual no te servirá para nada, lo siento.
  5. Vuelve a arrancar el servicio de “Cola de impresión”.
  6. Revisa que ya no hay documentos “enganchados” en la impresora.
  7. “Trabajito bien hecho, cigarrito pal pecho”.
Please follow and like us:

Android te da un “Android.process.acore” al sincronizar tus contactos con Google

Parece que el problema se extiende, ya que no son pocos los que se encuentran con un “Android.process.acore” cuando tratan de sincronizar sus contactos con Google.

El problema viene en la mayoría de los casos por saltos de línea que no espera el programa, o caracteres raros dentro de los campos que tiene un contacto. En muchos casos en el campo de Facebook de un contacto, por lo que sería lo primero a revisar.

Para investigar sin problemas, sólo tendremos que desactivar la “Sincronización de datos” automática dentro del submenu “Google” en el apartado de “Ajustes>Sincronización de datos“.

Este problema esta reconocido, y tiene su propio “Bug” en el sistema de Bugs de Android que obviamente, sigue abierto… Pero en el hilo de dicho bug, también hay un método bastante sencillo y cómodo. Baja al comentario 39 de dicho hilo y verás un sencillo método que nos permitirá no tener problemas con los caracteres ni los saltos de linea.

En resumen:

  1. Quitar la sincronización automática de los contactos con Google en “Ajustes->Sincronización de datos->Google->Sincronización automática“.
  2. Instalarnos en el teléfono el programa “ExportContacts” y crear un fichero .csv con nuestros contactos dentro de nuestra tarjeta SD. Saca este fichero a nuestro ordenador.
  3. Ese .csv puede ser importado a nuestros contactos de Gmail sin problema, entra en Gmail, en “Contactos->Importar“. Ojo, ya que los unirá a los contactos que tengas en Gmail, y quizás quieras borrar alguno que no te interese en Gmail.
  4. Borrar todos los contactos del teléfono. Sin miedo, ahora los tiene Google.
  5. Volver a activar la sincronización de los contactos en el teléfono.
  6. Si te aparece un mensaje de advertencia al sincronizar sobre que “Demasiados contactos borrados“, pulsa en “Deshacer borrado” (a mi no me salió dicho mensaje)
  7. Sincroniza… en un rato tendrás todos los contactos en tu teléfono de nuevo.

Un saludo 🙂

Please follow and like us:

HTC Hero, y el follón de los contactos

Ante la llegada de una actualización a la versión 2.1 para los poseedores de un telefono HTC Hero, muchos nos preguntamos como hacer correctamente un backup para mayor seguridad del contenido de nuestro telefono. El problema, o al menos el mio, es que no se muy bien, que se borra y que no. Que parte de mi teléfono esta en la nube, y cual no. Y centrándonos en lo más importante para mi: los contactos.

Tratemos de clarificar el tema.

Existen tres tipos de contactos posibles dentro de nuestro teléfono, y el tipo se encuentra en la parte derecha en la lista de contactos y según como tengas configurado el teléfono, solo mostrara algunos tipos. Para verlos en el listado de contactos tenemos que entrar en “Contactos” presionar “Menú” y luego “Ver”, allí saldrán 3 opciones (SIM, Teléfono y Google), pincha las 3 y verás con sorpresa la cantidad de contactos que tienes:

  • SIM: el clásico almacenamiento en la SIM de tu teléfono. Tiene el problema de que el espacio es restringido y que no se puede almacenar mucho más que nombre y teléfono.
  • Teléfono: almacenamos el contacto en la memoria del teléfono. Tiene un montón de opciones, y mucha información por cada contacto (igual o más que Google), pero, OJO, se borran con las actualizaciones de la ROM.
  • Google: Nuestro amigo Google, nos hace el favor de tener en la nube todos nuestros contactos. Obviamente, no se borran tras una actualización de la ROM, ya que al actualizar la ROM, con indicar nuestra cuenta de Gmail se sincroniza solo.

Obviamente, lo más cómodo es tener los contactos como “Google”… pero si los metemos en una categoría, como por ejemplo “Teléfono”, no se pueden cambiar el tipo, y tendrás que exportar el contacto y luego cargarlo en Gmail… con todos los problemas añadidos. Es decir, si tenemos los contactos metidos dentro de la memoria del teléfono (categoría teléfono), no podremos pasarlos a Google y que se sincronicen automaticamente… ¡¡¡ Maldita sea !!!, yo tengo todo metido en el teléfono.

Para solucionar este problema, buscamos en el Market: “ContactSync“. Una vez instalada, le damos al unico botón de la aplicación… y listo. Todos los contactos que antes estaban en el teléfono han pasado a ser tipo “Google”. Espera a que se sincronice con la nube y el milagro se habrá obrado.

Otro problema es que Google mete como contacto en la nube a cualquiera que le hayas mandado un correo… genial, ¿verdad?. Yo personalmente hice una limpia de contactos en Gmail antes de sincronizar nada, ya que no me gusta tener muchos contactos de gente que solo he tenido un correo esporádico o de una lista de correo. Pero vamos, esto va en gustos.

Y con esto, a esperar la actualización a la 2.1 🙂

Please follow and like us:

Como deshabilitar Clamav, si te de problemas, en Postfix

Cuando un servidor Postfix empieza a dar problemas, todos nos echamos a temblar, ya que es un servicio que tiene que funcionar como sea. En nuestro caso, y tras mirar los logs (/var/log/mail.info) nos dimos cuenta que nuestro ClamAV no funcionaba, por alguna extraña razón (… quizás 3 años sin actualizarlo xD), así que tuvimos que tomar una decisión rápida, que fue deshabilitarlo, hasta que podamos corregir todos los problemas.

Para deshabilitarlo, la forma más rápida en quitar Amavis-new del medio, ya que es el que se encarga de pasar por los filtros los correos y era quien devolvía el error al no encontrar el antivirus funcionando. Para esto sólo hay que comentar las siguientes líneas:

  • En “/etc/postfix/main.cf”:
    content_filter = amavis:[127.0.0.1]:10024
    receive_override_options = no_address_mappings
    
  • En “/etc/postfix/main.cf”:
    content_filter = amavis:[127.0.0.1]:10024
    receive_override_options = no_address_mappings
    
  • En “/etc/postfix/master.cf”:
    #amavis unix - - - - 2 smtp
    # -o smtp_data_done_timeout=1200
    # -o smtp_send_xforward_command=yes
    #127.0.0.1:10025 inet n - - - - smtpd
    # -o content_filter=
    # -o local_recipient_maps=
    # -o relay_recipient_maps=
    # -o smtpd_restriction_classes=
    # -o smtpd_client_restrictions=
    # -o smtpd_helo_restrictions=
    # -o smtpd_sender_restrictions=
    # -o smtpd_recipient_restrictions=permit_mynetworks,rej ect
    # -o mynetworks=127.0.0.0/8
    # -o strict_rfc821_envelopes=yes
    # -o receive_override_options=no_unknown_recipient_chec ks,no_header_body_checks
    # -o smtpd_bind_address=127.0.0.1
    
  • Terminado esto, reiniciamos el Postfix.
  • Y ahora hacemos que todo vuelva a “reencolarse” para que no se quede pendiente en la cola de mensajes de Postfix
    postsuper -r ALL
    

Y rezamos porque todo vaya bien 🙂

Please follow and like us:

Abrir ficheros Excel 2003 en una ventana diferente cada uno

No hay cosa que más me fastidie que el maldito Excel, y su manía de abrir todos los ficheros excel en la misma ventana, lo que hace que cuando quieres comparar o copiar algo, termine siendo un follón y termines metiendo la pata.

Bueno pues para evitarlo, aquí mi truco para Windows XP y Office 2003:

  1. Ir a “Mi PC > Herrramientas > Opciones de carpeta > Tipos de archivo
  2. Buscar en la lista “XLS
  3. Pulsar “Opciones avanzadas
  4. Quitar el tick a “Explorar en la misma ventana
  5. En la lista de “Acciones“, pulsar “Abrir” y luego “Editar
  6. Te encontraras en el apartado “Aplicación utilizada para realizar la acción” con algo como:

    “C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE” /e

    Substituir por:

    “C:\Archivos de programa\Microsoft Office\OFFICE11\EXCEL.EXE” “%1”

  7. Eliminar cualquier cosa que ponga en “Mensaje DDE“.
  8. Aceptar > Aceptar > etc…

Sin tener que reiniciar, cada vez que abras un excel, se te abrirá en una ventana nueva.

Please follow and like us:

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: