Jugando con los privilegios de accesos a Bases de Datos PostgreSQL

El escenario varias BDs con

• Un usuario diferente para cada BD con privilegios para insertar/modificar
• Un usuario capaz de leer todas las BDs
• Un usuario admin de todas las BDs
• Un Rol, que agrupe todos los usuarios y no tenga ningún privilegio

CREATE ROLE dba NO LOGIN;
CREATE USER user1 IN ROLE dba LOGIN ENCRYPTED PASSWORD '123456';
CREATE USER user2 LOGIN ENCRYPTED PASSWORD '123456';
CREATE USER admin1 IN ROLE dba LOGIN ENCRYPTED PASSWORD '123456';

ALTER GROUP dba ADD USER user2;

CREATE DATABASE db1 OWNER TO user1;
CREATE TABLE tabla1 (id serial, nombre character varying(10));

quitar todos los privilegios sobre la tabla: tabla1 para los usuarios user1 y user2
REVOKE ALL ON tabla1 FROM user1;
REVOKE ALL ON tabla1 FROM user2;

otorgar privilegios de consulta sobre la tabla talba1 para el usuario user1
GRANT SELECT ON tabla1 TO user1;

otorgar privilegios para insertar datos sobre la tabla tabla1 para el usuario user2 (requiere privilegios sobre la secuencia de la tabla)
GRANT INSERT ON tabla1 TO user2;
GTANT UPDATE ON tabla1_id_seq TO user2;

Para poder actualizar/eliminar un registro, se requiere tener privilegios de selección (requiere privilegios sobre la secuencias de la tabla)
GRANT UPDATE ON tabla1 TO user2;
GRANT DELETE ON tabla1 TO user2;

Migrando capas shape (.shp) a postgis

El tema de pasar capas .shp a postgis, no sé sí será una manía, pero el tema de acceso a bases de datos contra el acceso a archivos no lo creo...

Resulta que en el trabajo, hay un poco de gente haciendo capas y capas de mapas en software propietario... alguna vez pregunté (en pasillo) sí se habían puesto de acuerdo sobre algunas normas para hacer esas capas y me miraron como sí gubiera hablado en húngaro! y pensé... coño!

No me equivoqué... cuando me dieron la tarea de montar un servidor de mapas y empecé a pedir las capas, empezaron mis dolores de cabeza... ahora, me toca ver cómo hacer, y escribir (acá) para que la cosa funcione...

Vale decir que no tengo conocimientos en el tema de cartografía... por ahora...

Existen varias formas, una de ellas es con el comando shp2pgsql, otra con QGis y otra con gvSIG (esas son las que yo conozco)...

shp2pgsql: debería funcionar con algo parecido a esto

shp2pgsql -W UTF-8 .shp <schema>.<tablename> ><filename>.sql

pero yo obtuve un mensaje de error por la codificación en la que está hecha la capa, o la mala norma de los atributos

Finalmente amprendí algo sobre el estándar a seleccionar para que la cosa funcione. No significa que haya entendido, pero lo aprendí. Existe algo que se llama Sistema de Coordenadas Proyectadas y Sistema de Coordenadas Geográficas, ambas tienen como Sistema de Coordenadas de Referencia WGS84, pero la primera utiliza UTM y al segunda no, de manera que para la región Los Andes (Venezuela) sería para el primer caso SRC: EPSG 32619 que tiene WGS84 / UTM 19N y para el segundo caso SRC: EPSG 4326. De manera que es importante recordar este detalle para las propiedades de los proyectos y capas...

QGis:

• verifico en las propiedades del proyecto que el Sistema de Referencia de Coordenadas (SRC) esté en WGS 84 (EPSG 4326 o 32619 según sea el caso)
• Añado la capa vectorial (.shp)
• verifico las propiedades de la capa que tenga el datum WGS 84

Importando la capa (.shp) a PostGIS:

• Deseleccionar la opción Usar SRID por omisión o especificar aquí (que trae por defecto -1)
• cambiar el -1 por 4326 (o el que corresponda)
  
• añadir la capa
• ok

gvSIG:

• Agragar una vista nueva
• Verificar en Propiedades la Proyección Actual, que por defecto viene en 23030 (España), con lo cual seleccionamos 4326 o 32619 (u otra, según sea el caso)
• Click al botón Abrir, para añadir una capa .shp
• Al seleccionar la opción de añadir una capa, verificamos que tenga en Proyección Actual, el mismo valor que hemos puesto a la vista. Añadios la capa
  
• Seleccionada la capa a exportar, menú -> capa -> exportar -> postgis
• llenamos los datos que nos solicitan (nombre de la tabla, datos para la conexión con la BD) y listo!

En todo esto, seguro hay algunas otras consideraciones a tomar en cuenta. Sí algiuen las sabe, paselas, sino, esperémos a descubrirlas...

Normas de cortesía para trabajar con Bases de Datos

Justo ahora que me encuentro tratando de montar un servidor de mapas, con un conjunto de capas .shp generadas por estudiantes, pasantes, tesistas y profesionales del área (no informáticos) me encuentro con algo que creo será todo un dolor de cabeza... la falta de cortesía!

Claro! ellos no tienen la culpa, como siempre, la culpa es de la vaca (para los que no saben, ese es el título de un libro, sí alguien cree que le suena interesante, pues, búsquelo, y leálo)... ¿cuál vaca? la que sea, no importa! cuando les dije que por favor, no utilizaran en los nombres de atributos (atributos en SIGs son las tablas de BD para los informáticos) carácteres acentuados, ni especiales, ni mayúsculas, me respondieron: "Cómo vamos a irrespetar la ortografía! sí es un nombre propio, claro que irá en mayúscula!"

A lo que pensé... coño!

Para los que puedan, corran la voz!!! siempre que un producto informático, tenga como futuro una base de datos, aunque sea remoto, por favor, recordar:

• No utilizar caracteres especiales (vocales acentuadas, eñes, etc)
• No utlizar combinaciones de mayúsculas/minúsculas
• Utilizar nombres descriptibles
• En caso de ser nombres muy largos, utilizar nemotécnicos y su respectivo diccionario

A medida que vaya recordando (o tropezando) agregaré a la lista... o sí algún lector se le ocurre colaborar...

Preparando un entorno SIG en Debian Lenny

Para la presentación de datos georeferenciados, a través de un servicio web, voy a instalar un servidor de mapas. Ahora no recuerdo los detalles porque ya lo tengo instalado, pero trataré de ir corrigiendo en caso de que haga falta.

aptitude install cgi-mapserver mapserver-bin mapserver-doc gdal-bin proj proj-bin proj-data php5-mapscript

Sí algo me falta, es probable que aptitude se los traiga. con esto ya quedaría instalado el servidor de mapas.

Cómo accederlo todavía estoy revisando la doc, pero en un navegador al teclear http://localhost/cgi-bin/mapserv te debería devolver algo como No query information to decode. QUERY_STRING is set, but empty.lo que dice que ya está funcionando. Una vez se tenga una capa para mostrar, también se puede cargar vía http://localhost/tu_path_al_template/

El qué y cómo mostrar, vienen en la próxima entrega del blog... generar el mapfile y trabajar con la plantilla, que por ahora, me tiro a OpenLayers

Migrar BD de Mysql a PostGreSQL (parte 3)

Conversión de tipos

Resulta, que cuando vemos lo que nos dice el espejo que hemos creado de mysql sobre postgresql con dbi-link, los campos son creados como tipo text, con un comentario en la vista que dice qué tipo de dato aproximado debería haber ahí...

Esto es así, porque los tipos de datos entre diferentes gestores normalmente no son iguales, es decir, todos aplican los estándares, pero además, cada uno le da su toque, de manera que es posible que tenga más o menos, y que de paso, se llamen diferentes... o más bien, se le aplique aliases...

El tema es que cuando trato de leer para insertar en otra tabla, en un proceso de migración, debo tener muy presente los tipos de datos, ocasionalmente, podría recibir un mensaje del tipo:

Error de SQL:

ERROR: la columna «id» es de tipo integer pero la expresión es de tipo text
LINE 1: INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT c...
^
HINT: Necesitará reescribir la expresión o aplicarle una conversión de tipo.

En la declaración:
INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT codcat, codedi, catedi FROM sir_cultura_catedi)

Con lo cual, cualquiera se asusta a la primera... y no hace falta... con leer el mensaje y fijarme en la frase "aplicarle una conversión de tipos" será más que suficiente para tener algo de calma nuevamente...

¿qué es una conversión de tipos? digamos que tenemos un campo de un tipo de dato (p.e. text), pero queremos "interpretar" su contenido como sí fuera otro tipo de dato (p.e. int)... a eso se le conoce como conversión de tipos

INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT codcat::int, codedi::int, catedi FROM sir_cultura_catedi)

o

INSERT INTO cultu03 (id, cultu02_001, cultu03_002) (SELECT cast(codcat as int), cast (codedi as int), catedi FROM sir_cultura_catedi)

y listo!!!

Una consultica que tiene algo más:

INSERT INTO cultu04 (reg_001, est_001, mun_001, par_001, cpo_001, cultu04_001, cultu04_002, cultu04_003, cultu04_004, cultu04_005, cultu04_006, cultu04_007, cultu02_001, cultu03_001)
(SELECT codreg, codest, codmun, codpar, codcen, anno, nombre, direccion, telefono, correo, web,
CASE WHEN area <> '' THEN
CAST(area AS numeric)
ELSE
0
END,
codedi::int, codcat::int FROM sir_cultura_edif_det)

Creo que no hace falta explicar la estructura de las tablas, sólo entender que leo en una tabla e inserto lo que estoy leyendo, con algunas particularidades sencillas....

Una más

INSERT INTO acu03 (reg_001, est_001, mun_001, par_001, cpo_001, acu03_001, acu01_001, acu03_003, acu03_004, acu03_005, acu02_001, acu03_006, acu03_007, acu03_008)
(SELECT codreg, codest, codmun, CASE WHEN codpar = 'NA' THEN '00' ELSE codpar END, CASE WHEN codcen = 'NA' THEN '000' ELSE codcen END, EXTRACT(YEAR FROM agno)::int, tipo::int, nb_acueducto, fuentes, caudal, tratamiento::int, suscriptores, poblacion, produccion FROM servicios_acueducto)

Migrar BD de Mysql a PostGreSQL (parte 1 Versión 2)

Diciendo que soy usuario Debian, no digo mucho, pero les cuento que habiendo reinstalado mi equipo de la oficina, en el momento en que estoy devolviendo las cosas a la normalidad, se me ocurrió hacer un aptitude search dbi_link y vaya sorpresa, existe!

Pues, se me ocurrió instalarlo, y probar luego, cómo sería el procedimiento para que funcione... de manera que está sería la versión 2 de Migrar BD de Mysql a PostGreSQL (parte 1)

instalarlo:

• aptitude install dbi_link

buscar donde queda:

• find /usr/ -iname dbi_link

crear la BD en postgresql:

• createdb migracion

crear el lenguaje plperlu a la BD recien creada:

• createlang plperlu -d migracion

lanzar dbi_link.sql a la BD recien creada:

• psql -d migracion -f /path/completo/dbi_link.sql

crear la estructura que me permitirá _conectar_ con la otra BD, en este caso mysql (acá usamos el mysql.sql que viene en el example del dbi_link, que no viene con el aptitude install):

• psql -d migracion -f /path/completo/mysql.sql

y listo! ya está el esquema con la estructura y datos que necesito leer...

Solucionando el error de llave pública en Debian

Hoy decidí reinstalar mi computador de la oficina, tenía Debian Etch, y me estoy halando Debian Lenny desde un netinstall de etch...

¿Por qué reinstalar en vez de actualizar? vale, porque había instalado varias cosillas que no tienen uninstall (no son productos nativos para debian) y algunos quedaron mal instalados, con lo cual el sistema se fue poneindo "fastidioso" con el tiempo...

Lo que hice: instalar sólo el sistema base, esto es, que cuando llegó el tasksel, le dije que nada de eso, de manera que instaló algunos 8 paquetes más y listo. Luego, edité el sources.list para colocar uno que tengo cerca, y al darle aptitude update me saltaron 2 errores relacionados con las llaves, uno para el security y otro para el mirror que yo había agregado...

La solución:
gpg --keyserver subkeys.pgp.net --recv-keys 07DC563D1F41B907 && gpg --export --armor 07DC563D1F41B907 | apt-key add -

donde el 07DC563D1F41B907 es la llave que devuelve el error, de manera que tuve que hacerlo 2 veces, primero para el mirror y luego para el security... y update!

Apache como proxy reverse

Configurando Apache como Servidor de Páginas Web para Sistemas alojados en otro server dentro de la intranet

La situación: Un servidor A que tiene Apache2 (servidor de páginas web que aloja la página web institucional) y Bind9 (servidor de nombres de dominio: DNS), un servidor B que contiene otro Apache2 (para aplicaciones a la medida de la oficina, las cuales deben ser accedidas desde la intranet pero también desde otros lugares geográficos, de manera que son accedidos desde su propio subdominio, de la forma sistemas.misitio.tal)

Siguiendo lo que dice en [1], en ele ejemplo básico, he agregado además del default modificado, una especie de vhost, que en realidad es un proxy reverse, el el servidor A:

ServerName sistemas.misitio.tal

ProxyRequests Off

Order deny,allow
Allow from all

ProxyPass / http://192.168.15.18/
ProxyPassReverse / http://192.168.15.18/

ErrorDocument 404 /

TransferLog /var/log/apache2/sistemas.access
ErrorLog /var/log/apache2/sistemas.error


En el servidor B, sólo basta que esté el site default.

Luego, buscar los módulos para instalar y activar: proxy, proxy_connect y proxy_http

reiniciar apache y listo!

[1] http://httpd.apache.org/docs/2.2/mod/mod_proxy.html