Simplemente poniendo esto en una consola (y conociendo el password de root o usuario con privilegios) y observando como el programa hace el trabajo:
mysqlcheck -u root -p --auto-repair --check --optimize --all-databases
Si tu «root» no tiene password sólo quita el «-p» para que todo funcione.
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.
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.
sudo aptitude install postgresql-8.4
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.
sudo apt-get install checkinstall
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.
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
select postgis_lib_version();
Y veremos algo así:
Versión de PostGIS mediante SQL
Como siempre, de donde he leido toda la información que os condenso en este post:
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:
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.
# 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.
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.
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».
Muchas veces, tras trabajar en una base de datos y hacer pruebas, queremos borrar toda huella de que hemos «metido mano», y uno de los problemas que me he encontrado, ha sido que cuando tienes una tabla con una clave autoincrementada, aunque borres toda la tabla entera, esta al insertar una nueva fila continua con la secuencia en la clave autoincremental.
Es decir, si meto 3 registros en una tabla con un campo autoincremental, obtienen el valor 0, 1 y 2, respectivamente. Si borro estas tres y meto una cuarta tras el borrado, recibe el valor 3 (en vez de 0).
En casi todas las bases de datos hay truquillos, y este es para SQLite, ejecutando esta SQL:
D3LETE FROM sqlite_sequence WHERE name='NombreDeTablaAResetear';
Ojo, quita el «3» de la sentencia, ya que mi server no me deja meter SQL en el texto de mis post…
Hace tiempo escribí una pequeña entrada explicando como arreglar el error 1045 en el login de MySQL. Pues bien, tras provarlo en mis propias carnes, he visto que hay un pequeño desliz.
Tras hacer lo que se dice en la anterior entrada, hay que ejecutar en la consola de MySQL este comando:
flush privileges;
Tambien, si quieres cambiar el password, puedes usar la funcion «Password(‘MinuevoPass’)» para actualizar el campo password, dentro de la tabla «mysql.user».
Y creo que ya no se me olvida nada 😛
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.
Aveces, te planteas aplicaciones, que necesitarían un lugar donde almacenar mucha información, en muchos casos, simplemente por tenerla ordenada y accesible la incorporación de una base de datos es muy recomendable.
Pero, incluir una base de datos, resulta muy engorroso, de hecho muchas veces incluso es un problema. Os pongo el caso, de necesitar de una pequeña agenda que te vas a instalar en tu PC de casa… Ves sus requisitos y ves que necesita instalar un MySQL o similar. Sencillamente no me lo instalaría (como la mayoría de la gente).
Mucha gente me contestaría, que se podría usar un texto plano, un XML, un archivo binario, o cientos de tipos de soluciones que no necesitaran de tener una base de datos en tu maquina… cierto. ¿Pero y si el volumen de datos empieza a ser un problema?.
Una solución puede ser SQLite, que es una solución intermedia. Es un desarrollo intermedio, una base de datos en un fichero, sin dependencias y todo en una dll. Ademas hay un desarrollo para ADO.NET, para integrarlo con el Visual Studio, que hace las cosas muy sencillas.
Es una solución intermedia, ya que yo es recomendable usarlo para cosas que requieran mucha fiabilidad (sobre todo de tiempo respuesta) pero para pequeños proyectos o aplicaciones con poco estrés, te solucionará la vida.