Archivo

Posts Tagged ‘PostgreSql’

Compilar PostgreSQL 9.1.3 con soporte para edb_debugger en Debian 6

Nota importante: Este artículo ha quedado obsoleto, ya que algunos pasos han cambiado. Existe una versión revisada del mismo aqui:

Compilar PostgreSQL 9.2.4 con soporte para pldebugger en Debian 6

Recientemente en el trabajo, he tenido que desarrollar un triger para PostgresSQL algo complejo, así que la posibilidad de depurarlo paso a paso era muy desaeable. Sin embargo al intentar acceder al depurador desde pgAdminIII, resulta que la mayoría de las versiones de PostgreSQL para linux no disponen de esta funcionalidad.

Así pues, la única solución es compilar el plugin edb-debugger desde las fuentes y añadirlo a PostgresSQL.

Sin embargo, para compilar este plugin es necesario disponer del código fuente del PostgreSQL, así que.. una vez metidos en faena… ¿porque que no aprovechar para instalar desde las fuentes la base de datos también?

Las versiones del software que se usaran en el articulo son las siguientes:

  •           Debian 6.1
  •           PostgreSQL 9.1.3
  •           ebd-debugger 0.9.3

Para lograr nuestro objetivo, y partiendo de una instalación limpia de Debian 6 NetInstall seguiremos los siguientes pasos:

1.- Instalar los paquetes build-esentials

Lo primero que debemos hacer es instalar los paquetes esenciales para poder compilar en nuestra distribución. En el caso de Debian 6, deberemos ejecutar la siguiente instrucción:

# apt-get install build-essential

Además debemos bajarnos algunas bibliotecas extra que necesitaremos para realizar la compilación de PostgreSQL con éxito:

# apt-get install libreadline5 libreadline5-dev zlib1g zlib1g-dev openssl libssl-dev

Las bibliotecas instaladas y su propósito son las siguientes:

Además necesitaremos el cliente CVS para poder descargar directamente del repositorio de edb-debugger los fuentes del plugin:

# apt-get install cvs

2.- Obtener el código fuente de PostgreSQL

El siguiente paso es obtener el código fuente de PostgreSQL, para lo cual usaremos el comando wget:

#  wget http://ftp.postgresql.org/pub/source/v9.1.3/postgresql-9.1.3.tar.gz

A continuación descomprimimos el fichero tar.gz que nos hemos descargado con la instrucción:

#  tar xvzf ./postgresql-9.1.3.tar.gz

3.- Obtener el código fuente del edb_debugger

Obtendremos el código fuente del plugin edb_debugger desde los repositorios del proyecto con el comando cvs:

#  cvs -d :pserver:anonymous@cvs.pgfoundry.org:/cvsroot/edb-debugger login

Cuando el sistema nos pregunte por el password del usuario anonymous simplemente pulsaremos la tecla ENTER.
Con la siguiente orden, descargaremos los fuentes del repositorio:

#  cvs -d :pserver:anonymous@cvs.pgfoundry.org:/cvsroot/edb-debugger checkout server

Siguiendo las instrucciones de instalación del plugin, copiamos el directorio que acabamos de descargar al directorio /comtrib del arbol de directorios del código fuente de PostgresSQL:

#  cp ./server/ ./postgresql-9.1.3/contrib/server/ -R

4.- Establecer las opciones de compilación de PostgresSQL

EL siguiente paso es establecer las opciones de compilación. Para ello entraremos en el directorio donde están las fuentes de PostgreSQL:

#  cd ./postgresql-9.1.3

y escribiremos el siguiente comando:

# ./configure -with-openssl -enable-thread-safety

Las opciones de configuración establecidas son las siguientes:

  • -with-openssl: Permite conexiones encriptadas medieante SSL
  • -enable-thread-safety: Permite el uso seguro de concurrencia (hebras)

5.- Compliar el código fuente PostgreSQL

Una vez establecidas las opciones de configuración sin errores, procedemos a compilar el código fuente de PostgresSQL, para lo cual bastara llamar al comando make:

# make

6.- Instalar los binarios

Si la compilación se ha completado sin errores, procederemos a instalar los binarios de la aplicación:

# make install

Con ellos ya tenemos instalado PostgreSQL en nuestra máquina.

7.- Compilar edb-debugger

Para continuar , debemos compilar el pluging edb-debugger. Para ello debemos ingresar en el directorio dentro del árbol de fuentes de PostgreSQL donde copiamos el código fuente del pluging. Si hemos seguido al pie de la letra las instrucciones de este articulo, deberíamos estar en el directorio ./postgresql-9.1.3, por lo que continuaremos ejecutando los siguientes comandos:

# cd ./contrib/server/

y compilamos el plugin.

# make

7.- Instalar edb-debugger

Instalar el plugin es tan sencillo como ejecutar el siguiente comando:

# make install

8.- Configurar postgreSQL

8.1 Añadir binarios al path del sistema

El siguiente paso es editar el fichero de configuración de bash /etc/profile para añadir la ruta de los binarios de PostgresSQL a la variable PATH del sistema.Para ello añadiremos al fichero la línea:

PATH="/usr/local/pgsql/bin":$PATH

dejándolo de forma parecida a este:

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
PATH="/usr/local/pgsql/bin":$PATH
export PATH

if [ "$PS1" ]; then
  if [ "$BASH" ]; then
    # The file bash.bashrc already sets the default PS1.
    # PS1='\h:\w\$ '
    if [ -f /etc/bash.bashrc ]; then
      . /etc/bash.bashrc
    fi
  else
    if [ "`id -u`" -eq 0 ]; then
      PS1='# '
    else
      PS1='$ '
    fi
  fi
fi

# The default umask is now handled by pam_umask.
# See pam_umask(8) and /etc/login.defs.

if [ -d /etc/profile.d ]; then
  for i in /etc/profile.d/*.sh; do
    if [ -r $i ]; then
      . $i
    fi
  done
  unset i
fi

Si todo ha ido bien, el comando :

# echo $PATH

nos debe retornar algo parecido a esto:

/usr/local/pgsql/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

donde vemos que en primer lugar esta incluida la ruta a los binarios de PostgresSQL.

8.2 Crear el usuario postgres

A continuación creamos el usuario postgres que será el usuario bajo el cual se ejecute la base de datos:

# adduser postgres

8.3 Crear e inicializar el directorio de datos

El siguiente paso será crear e inicializar el directorio de datos, donde PostgreSQL guardará la información:

# mkdir /usr/local/pgsql/data

Hacemos propietario de este directorio al usuario postgres:

# chown postgres /usr/local/pgsql/data

A continuación asumimos la indentidad del usuario postgres para inicializar el directorio de datos:

# su - postgres

y finalmente inicializamos el directorio de datos:

$ initdb -D /usr/local/pgsql/data

Llegados a este punto, y si todo ha ido bien, el deberemos ver en nuestr terminal algo parecido a esto

Success. You can now start the database server using:

    postgres -D /usr/local/pgsql/data
or
    pg_ctl -D /usr/local/pgsql/data -l logfile start

En este momento, tal y como indica el sistema podremos arrancar la base de datos en primer plano con:

#  postgres -D /usr/local/pgsql/data

y detenerla simplemente pulsando la combinación de teclas Ctr-C

Si deseamos arrancar la base de datos en segundo plano, lo haremos usando la segunda opción:

#   pg_ctl -D /usr/local/pgsql/data -l logfile start

y la detendremos con el siguiente comando:

$  pg_ctl -D /var/pgsql/data stop -m fast

8.4 Configurar contraseña de acceso a la base de datos para el usuario postgres

Para configurar la contraseña de acceso del usuario postgres a la base de datos, lo primero que habrá que hacer lógicamente es iniciar el servidor:

#   pg_ctl -D /usr/local/pgsql/data -l logfile start

Una vez iniciado el servidor, y manteniendo en el sistema la identidad del usuario postgres, accederemos al interprete de ordenes de PostgreSQL:

$psql

Una vez dentro, escribiremos:

postgres=# alter user postgres with password ‘passwd’;

donde passwd es la nueva contraseña que deseamos poner.El sistema debe responder con un:

 ALTER ROLE postgres=# 

Salimos del cliente de linea de ordenes con la orden:

postgres=#\q 

Y salimos de la cuenta en el sistema del usuario postgres con un simple:

$exit 

8.5 Crear script de arranque automático

Para hacer que PostgreSQL se ejecute automáticamente al iniciar el sistema, debemos copiar desde el directorio /contrib/start-scripts del arbol del código fuente de postgreSQL, el fichero denominado linux al directorio /etc/init.d. En este punto de la instalación, deberíamos estar en el directorio ./postgresql-9.1.3/contrib/server, por lo que ejecutaremos el siguiente comando:

#  cp ../start-scripts/linux /etc/init.d/postgresql

Una vez copiado el script, debemos editarlo para añadirle las etiquetas LSB. Para ello, añadiremos al comienzo del fichero /etc/init.d/posgresql, justo debajo de #! /bin/sh las siguientes líneas:

### BEGIN INIT INFO
# Provides:          PostgreSQL
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start Postgresql at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

Además, debemos dar permisos de ejecución al script, con el siguiente comando:

#  chmod 755 /etc/init.d/postgresql

Con ello, podremos arrancar y parar postgresql con el tipico comando:

#  /etc/init.d/postgresql accion

donde accion representa alguna de las siguientes posibles acciones:

  • start Arranca el servidor de bases de datos.
  • stop Detiene el servidor de bases de datos.
  • restart Detiene el servidor de bases de datos, y lo vuelve a arrancar.
  • reload Recarga la configuración del servidor de bases de datos.
  • status Informa si el servidor de bases de datos se esta ejecutando o no.

Por último, debemos añadir el script de inicio de PostgreSQL a los scripts de arranque del sistema, para lo cual ejecutaremos el siguiente comando:

#  update-rc.d postgresql defaults

Si por alguna razón deseamos eliminar el script de la secuencia de arranque, deberemos ejecutar el comando:

#  update-rc.d -f postgresql remove

8.6 Editar el fichero postgresql.conf

El siguiente paso es editar el fichero /usr/local/pgsql/data/postgresql.conf para, por un lado permitir que el servidor escuche por todas las interfaces de red, y por otro lado, indicarle que cargue el plugin edb-debugger.

Para permitir que el servidor escuche por todas las interfaces de red, buscaremos la línea:

#listen-address = 'localhost' 

(suele ser la línea 59), la copiamos debajo, la descomentamos, y la modificamos quedando :

listen-address = '*' 

Si se quisera que PostgreSQL escuchase sólo las peticiones de determinadas IPs, bastaría con poner estas IPs separadas por comas, y todo el conjunto entre comillas simples. Por ejemplo:

listen-address = '192.168.0.2,192.168.0.3'

Nota: por custiones de seguridad no se recomienda permitir el acceso desde cualquier máquina.

Para indicarle a PostgreSQL que cargue el plugin edb-debugger al arrancar,buscaremos la línea:

#shared_preload_libraries = ''          # (change requires restart)

(suele ser la línea 127), la copiamos debajo, la descomentamos, y la modificamos quedando :

shared_preload_libraries = '$libdir/plugins/plugin_debugger' # (change requires restart)

8.7 Configurar permisos de acceso

8.7.1 Configurar permisos de acceso local:

Al compilar desde las fuentes, PostgreSQL es muy poco restrictivo a la hora de gestionar permisos, ya que por defecto, permite a todos los usuarios del sistema el acceso sin contraseña. Por ello deberemos restringir ciertos permisos locales.

Para ello debemos editar el fichero /usr/local/pgsql/data/pg_hba.conf
Buscaremos la línea cuyo contenido es:

local all all trust

y la modificamos de forma que quede:

local all all md5

Con ello permitimos el acceso a cualquier cuenta de usuario desde la maquina local siempre que se especifique una contraseña encriptada mediante md5. Ello implica que al reinicar el servidor
podremos acceder al cliente de linea de ordenes de PostgreSQL desde cualquier cuenta de usuario con la cuenta de postgres, escribiendo:

$psql -U postgres -W 
8.7.2 Configurar permisos de acceso remoto:

Por último, debemos configurar los permisos de acceso remoto. Se trata de responder a las siguientes preguntas:

  • ¿Que usuarios tienen permisos para conectarse?
  • ¿Desde que IPs se pueden conectar?
  • ¿A que bases de datos?
  • ¿Y.. que método de auteticación tienen que usar?

En este post, daremos permisos a todos los usarios de la base de datos, para concetarse a todas las bases de datos, desde cualquier IP, usando una contraseña encriptada con MD5.

Esto lo lograremos editando de nuevo el fichero /usr/local/pgsql/data/pg_hba.conf y localizando la línea:

host all all 127.0.0.1/32 trust

y la modificandola forma que quede:

host all all 0.0.0.0 0.0.0.0 md5

Una explicación sencilla de esta regla de permisos del fichero /etc/postgresql/9.1/main/pg_hba.conf seria:

  • host Indica que la regla se refiere a conexiones remotas
  • all Responde a la pregunta ¿Que usuarios tienen permiso para conectarse?. En este caso todos.Si quisieramos especificar un usuario determinado, bastaría con sustituir “all” por el nombre del usuario deseado. Si queremos aplicar la misma regla a varios usuarios, tendremos que copiar y pegar la regla, cambiando el nombre de usuario.
  • all Responde a la pregunta ¿A que bases de datos?. En este caso a todas .Si quisieramos especificar una base de datos determinada, bastaría con sustituir “all” por el nombre de la base de datos deseada. Si queremos aplicar la misma regla a varios bases de datos, tendremos que copiar y pegar la regla, cambiando el nombre de la base de datos.
  • 0.0.0.0 0.0.0.0 Responde a la pregunta ¿Desde que IPs se pueden conectar?. En este caso desde todas. el primer grupo de 4 digitos especifca la IP, mientras que el segundo es la mascara de red. Los valores 0.0.0.0 son valores comodin, cuyo significado es “cualquier IP” y “cualquier mascara” respectivamente.
  • md5Responde a la pregunta ¿Que método de auteticación tienen que usar?. En este caso una contraseña encriptada con MD5. Otros posibles valores son : “passowrd” para una contraseña sin encriptar o “trust” para permitir un acceso sin contraseña

Para una mayor información sobre como funciona el fichero /etc/postgresql/9.1/main/pg_hba.conf se puede consultar la documentación oficial en castellano en la dirección: http://www.postgresql.org/docs/9.1/interactive/auth-pg-hba-conf.html

Finalmente inhabilitaremos las conexiones locales a través de IP6, para lo cual, localizaremos la línea:

host all all ::1/128 trust

y la comentaremos de forma que quede:

#host all all ::1/128 trust

9.- Reiniciar el servidor

Para comprobar que todo ha ido bien, que el script de autoarranque esta correctamente instalado, y que las configuraciones definidas en la base de datos son correctas, Debemos reiniciar la máquina servidora. Para ello, ejecutaremos las siguiente instrucción:

# reboot

10.- Probar el depurador

para probar el depuraror, lo primero que hemos de hacer es crear una base de datos de prueba,con una tabla de prueba, y con un procedimiento almacenado de prueba que podamos depurar.

10.1.- Acceder al interprete de PostgreSQL

Accedemos al interprete de comandos de PostgresSQL con la siguiente instrucción:

$ psql -U postgres -W

10.2.- Crear base de datos de prueba

Una vez dentro del interprete de comandos de PostgresSQL creamos la base de datos con el siguiente comando:

postgres=# CREATE DATABASE prueba_debugger WITH ENCODING='UTF8';

10.3.- Crear tabla de pruebas

Nos conectamos a la base de datos que acabamos de crear:

postgres=# \c prueba_debugger

y el sistema responde con:

You are now connected to database "prueba_debugger".

A continuación creamos la la tabla de pruebas

prueba_debugger=# CREATE TABLE tabla_prueba (
	                                      Id		BIGSERIAL PRIMARY KEY ,
	                                      Valor		VARCHAR (255) default ''
                                             );

y el sistema responde con:

NOTICE:  CREATE TABLE will create implicit sequence "tabla_prueba_id_seq" for serial column "tabla_prueba.id"
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "tabla_prueba_pkey" for table "tabla_prueba"
CREATE TABLE

10.4.- Crear procedimiento almacenado de prueba

Seguimos creando objetos en la base de datos de prueba. En este punto crearemos un procedimiento almacenado:

prueba_debugger=#
CREATE OR REPLACE FUNCTION tabla_prueba_trigger() RETURNS TRIGGER AS $tabla_prueba_trigger$
  DECLARE
	sValor VARCHAR (255):= NEW.Valor;
	iId INTEGER:= NEW.Id;
	iCalculo INTEGER:= 0;
  BEGIN
   RAISE NOTICE '---------- INICIO prueba_debugger.tabla_prueba_trigger() ----------';
   RAISE NOTICE '---------- => El nuevo registro tiene un Id: %',iId;
   RAISE NOTICE '---------- => El nuevo registro tiene un Valor: %',sValor;
   iCalculo=iId +5;
   RAISE NOTICE '---------- => El Id del nuevo registro +5 es igual a: %',iCalculo;
   RAISE NOTICE '---------- FIN prueba_debugger.tabla_prueba_trigger() -------------';
  END;

y le indicamos a PostgreSQL el lenguaje en el que está escrito el procedimiento almacenado:

prueba_debugger=# $tabla_prueba_trigger$ LANGUAGE plpgsql;

10.5.- Crear disparador para lanzar el procedimiento almacenado de prueba

Crearemos un disparador que lanzará el procedimiento almacenado despues de cada inserción:

prueba_debugger=# CREATE TRIGGER update_tabla_prueba AFTER INSERT
                  ON tabla_prueba FOR EACH ROW EXECUTE PROCEDURE  tabla_prueba_trigger();

10.6.- Ejecutar el script de preparacion para la depuración

Para poder depurar los procedimientos almacenados, es necesario que antes hayamos ejecutado en la base de datos donde queremos hacer la depuración un script SQL que nos proporcionan los desarrolladores del plugin edb-debugger. Este script crea algunos tipos de datos y funciones necesarias para que el depurador funcione.

Este script se encuentra en el directorio de las fuentes del plugin, es decir en ./postgresql-9.1.3/contrib/server/pldbgapi.sql

Puesto que para hacer esta articulo he usado la cuenta de superusuario (root), la ruta absoluta donde se encuentra el script sql es /root/postgresql-9.1.3/contrib/server/pldbgapi.sql, y esta será la ruta que usaremos para ejecutar el script desde el interprete de postgreSQL ejecutaremos la siguiente orden:

prueba_debugger=# \i /root/postgresql-9.1.3/contrib/server/pldbgapi.sql
[/sourcecode]

Una vez ejecutado el script, ya podemos conectarnos a la base de datos desde pgAdminIII y usar la función de depuración.

Nota: Debemos ejecutar este script en cada base de datos donde deseemos usar la funcionalidad de depuración.

10.7.- Probar el depurador

Finalmente, obtendremos la recompensa a nuestro esfuerzo, al abrir pgAdminIII, abrir la base de datos de prueba que hemos creado, abrir el esquema public, abrir la tabla tabla_prueba desplegar la sección Trigger-Functions, y sobre nuestra función, hacer click con el boton derecho, y seleccionar la opción “Set breakpoint”

EstableciendoBreakPoint

Estableciendo breakpoit con pgAdminIII

En la siguiente captura podemos ver el depurador en acción:

DepuradorEnAccion

Depurador pgAdminIII en acción

Anuncios
Categorías:Debian, PostgresSql, Tecnología Etiquetas: ,

Elastix + CDR en PostgreSQL

Elastix es una excelente distribución que integra en un sistema operativo Linux (Centos)  la centralita telefónica por software Asterisk.

Es una de las mejores soluciones de telefonía que existen, capaz de competir con otras soluciones propietarias muchísimo más costosas.


Una de las funciones más interesantes de Asterisk, y por tanto de Elastix, es el llamado CDR (Call Detailed Records), que es un registro de las llamadas que se hacen en la centralita. Se puede configurar la centralita para que esta información se guarde en diferentes sitios, desde un archivo CSV (Comma Separated Values) hasta en una base de datos, comúnmente, MySQL.

Elastix, como casi todas las distribuciones Linux orientadas a Asterisk, viene pre-configurado para almacenar estos datos e una base de datos MySQL que la propia distribución instala y configura para que no haya ningún problema.

Sin embargo, puede ser interesante guardar estos datos en otro sitio, aparte de la base de datos MySQL, por ejemplo en una base de datos PostgreSQL, y a ello nos vamos a dedicar en el resto del articulo.

La configuración propuesta, en este articulo, almacena los datos CDR, tanto en el MySQL de Elastix, como en la base de datos PostgreSQL que se le especifique. Para ello usaremos las siguientes versiones de los componentes principales:

  • Elastix 2.2.0 (con Asterisk 1.8)
  • PostgreSQL 9.1

En este documento, supondremos que ya tenemos instalado y funcionando Elastix, y que tenemos un servidor externo con una base de datos PostgreSQL 9.1 al cual tenemos acceso mediante una conexión por socket.

Los pasos a seguir son los siguientes:

1.- Cargar por defecto el módulo cdr_pgsql.so:

El módulo cdr_pgsql.so es el encargado de comunicar de forma nativa Asteriskcon PostgreSQL

Para cargarlo, debemos editar el fichero :

/etc/asterisk/modules.conf

y comentar la línea 78, cuyo contenido es:

noload => cdr_pgsql.so

dejandola:

;noload => cdr_pgsql.so

Con ello se consigue que Asterisk cargue al iniciarse el módulo cdr_pgsql.so

2.- Modificar de fichero /etc/asterisk/cdr_pgsql.conf :

El fichero cdr_pgsql.conf, es donde se configurarán los parámetros de conexión a la base de datos PostgresSQL. Este fichero deberá ser modificado, poniendo los datos correctos de conexión a la base de datos. A continuación se muestra un fichero de ejemplo.

; Sample Asterisk config file for CDR logging to PostgresSQL 
; Note that you can use TLS connections to your database server. 
; This is configured for your PostgreSQL client installation 
; on this system (check for pgsessions.conf) 
[global] 
hostname=192.168.1.55 
port=5432 
dbname=asterisk 
password=asterisk 
user=asterisk 
table=cdr ;SQL table where CDRs will be inserted 
;encoding=UTF8 ; Encoding of logged characters in Asterisk 
;timezone=UTC ; Uncomment if you want datetime fields in UTC/GMT 

Con ello lograremos que Asterisk sea capaz de conectarse al servidor PostgreSQL que se le indique.

3.- Crear el usuario y la base de datos en PostgreSQL:

La creación del usuario, y la base de datos, puede ser opcional, si por ejemplo ya tenemos un usuario y una base de datos donde queremos almacenar los datos. Lo que no es opcional, es la creación de la tabla donde se almacenarán esos datos. Por ello, este apartado, lo dividiremos a su vez en dos subapartados:

3.1.- Creación de la base de datos y del usuario de acceso a la misma (opcional).

A continuación se pone un script SQL de ejemplo para crear el ususario y la Base de datos para que Elastix se pueda conectar. Este script se debe ejecutar como el usuario postgres.

------------------------------------------------------------------ 
-- Este Script crea la Base de datos y el usuario necesarios 
-- para que Elastix guarde en postgreSQL los datos de CDR. 
-- Se debe ejecutar bajo el usuario postgres 
------------------------------------------------------------------ 
-- Eliminamos posibles datos anteriores 
DROP DATABASE IF EXISTS asterisk; 
DROP ROLE IF EXISTS asterisk; 
-- Creamos el usuario 
CREATE ROLE asterisk LOGIN ENCRYPTED PASSWORD 'asterisk' VALID UNTIL 'infinity'; 
-- Creamos base de datos 
CREATE DATABASE asterisk WITH ENCODING='UTF8' OWNER=asterisk LC_CTYPE='es_ES.UTF-8' 
                CONNECTION LIMIT=-1; 

3.2- Crear de la tabla para almacenar los datos CDR

Este script se debe ejecutar conectando a la base de datos desde la recién creada cuenta del usuario asterisk o bien desde la cuenta de usuario que se quiera que sea la propietaria de la tabla. EN este último caso, habrá que modificar el script, para adecuar el el esquema y la base de datos donde deseemos crearla.

-------------------------------------------------------------------------------------------- 
-- Este Script crea la Tabla, la Secuencia, y la clave primaria necearia para que 
-- Asterisk guarde en postgreSQL los datos de CDR. 
-- Se debe ejecutar bajo el usuario asterisk, conectado a la base de datos asterisk. 
-------------------------------------------------------------------------------------------- 
-- Creamos la tabla para CDR 
CREATE TABLE asterisk.public.cdr ( 
       AcctId BIGSERIAL PRIMARY KEY , 
       calldate TIMESTAMP with time zone NOT NULL DEFAULT now(), 
       clid VARCHAR(45) NOT NULL default '', 
       src VARCHAR(45) NOT NULL default '', 
       dst VARCHAR(45) NOT NULL default '', 
       dcontext VARCHAR(45) NOT NULL default '', 
       channel VARCHAR(45) NOT NULL default '', 
       dstchannel VARCHAR(45) NOT NULL default '', 
       lastapp VARCHAR(45) NOT NULL default '', 
       lastdata VARCHAR(45) NOT NULL default '', 
       duration INTEGER NOT NULL default '0', 
       billsec INTEGER NOT NULL default '0', 
       disposition VARCHAR(45) NOT NULL default '', 
       amaflags INTEGER NOT NULL default '0', 
       accountcode VARCHAR(45) NOT NULL default '', 
       uniqueid VARCHAR(45) NOT NULL default '', 
       userfield VARCHAR (255) default '' 
); 
COMMENT ON COLUMN cdr.acctid IS 'Identificador único del registo.'; 
COMMENT ON COLUMN cdr.calldate IS 'Fecha en la que se realiza la llamada (TimeStamp)'; 
COMMENT ON COLUMN cdr.clid IS 'Identificador único de la extensión llamante con texto.'; 
COMMENT ON COLUMN cdr.src IS 'Identificador único de la extensión llamante.'; 
COMMENT ON COLUMN cdr.dst IS 'Extensión Destino.'; 
COMMENT ON COLUMN cdr.dcontext IS 'Contexto de Destino.'; 
COMMENT ON COLUMN cdr.channel IS 'Canal Usado.'; 
COMMENT ON COLUMN cdr.dstchannel IS 'Canal destino si procede.'; 
COMMENT ON COLUMN cdr.lastapp IS 'Última aplicación si procede.'; 
COMMENT ON COLUMN cdr.lastdata IS 'Parámetros de la ultima aplicación.'; 
COMMENT ON COLUMN cdr.duration IS 'Tiempo total en segundos que dura la llamada, dede que se marca,
                                   hasta que se cuelga.'; 
COMMENT ON COLUMN cdr.billsec IS 'Tiempo de la llamada en segundos, desde que es respondida hasta 
                                  que se cuelga.'; 
COMMENT ON COLUMN cdr.disposition IS 'Estado de la llamada. Los valores posibles son:
                                        * ANSWERED : Llamada contestada 
                                        * NO ANSWER: Llamada no contestada
                                        * BUSY: Destino ocupado 
                                        * FAILED: Llamada fallida debido a un error.'; 
COMMENT ON COLUMN cdr.amaflags IS 'Flags usados en la llamada.'; 
COMMENT ON COLUMN cdr.accountcode IS 'Identificador único de la cuenta de Asterisk que realiza 
                                      la llamada.'; 
COMMENT ON COLUMN cdr.uniqueid IS 'Identificador único del canal usado.'; 
COMMENT ON COLUMN cdr.userfield IS 'Campo definido por el usuario.'; 

4.- Reiniciar Asterisk

El último paso para hacer efectiva la configuración es reiniciar Asterisk. Esto se puede hacer, bien desde la interfaz web de Elastix, bien desde la consola de comandos de Linux del servidor Elastix. En ese último caso, el comando que hay que ejecutar es el siguiente:

[root@Elastix64 ˜]# /etc/init.d/asterisk restart
Categorías:Elastix, PostgresSql Etiquetas: ,

Ejecutar multiples instancias de PostgreSql en Ubuntu 10.04

Recientemente por motivos de trabajo me he visto obligado a ejecutar en la misma máquina y bajo ubuntu 10.04 dos versiones de PostgreSql. En concreto para mi nuevo proyecto necesitaba ejecutar la versión 9.0 de este RDBMS y la versión 8.4 que ya tenía instalada y funcionando para dar soporte a los proyectos más antiguos.

El proceso es el siguiente:

1.- Instalar la nueva versón de la base de datos a través de los repositorios:

Este primer paquete nos facilitará la tarea de añadir nuevos repositorios.

#aptitude install python-software-properties

A continuación añadimos el nuevo repositorio para obtener la versión 9.0:

#add-apt-repository ppa:pitti/postgresql

Actualizamos el gestor de paquetes:

#aptitude update

Instalamos la nueva versión de la Base de datos:

#aptitude install postgresql-9.0 libpq-dev pgadmin3

2.- Configurar la ejecución simultanea:

Si llegados a este punto intentamos acceder a la nueva instancia del RBDMS nos encontraremos con que el típico comando:

$sudo -u postgres plsl postgres

nos devuelve un error.
Por otra parte, el instalador nos configura la nueva instancia del RDBMS en el puerto 5433, con lo que no tendríamos problemas por ese lado.
El problema esta en la versión de las herramientas de configuración que se usan, ya que al estar configurada por defecto la versión 8.4, el sistema usará por defecto esta versión. En particular el ejecutable de psql es un script de perl que en teoría redirige a la versión correcta de la herramienta en función del contenido de los ficheros :

  • ~/.postgresqlrc : Donde se define que cluster se usará, que versión, que usuario, que base de datos etc.. a nivel del usuario logueado.
  • /etc/postgresql-common/user_clusters : Donde se define que cluster se usará, que versión, que usuario, que base de datos etc.. a nivel del sistema.

El script perl buscará primero en ~/.postgresqlrc y dentro de este fichero usará los datos definidos en la primera línea que encuentre. Si este fichero no existiese o no tuviese ninguna línea, el script perl usará los datos definidos en la primera línea del fichero /etc/postgresql-common/user_clusters

Si finalmente este fichero no existiese o no existiera ninguna línea en él, el script perl nos dirigirá al cluster que este escuchando en el puerto 5432 y a la base de datos cuyo nombre coincida con el nombre del usuario logueado.

Con esto en mente, y en mi caso particular decidí definir el fichero /etc/postgresql-common/user_clusters dejándolo de la siguiente manera:

# This file maps users against the database clusters to which they
# will connect by default.  Any user may create ~/.postgresqlrc which
# will supersede the defaults stored here.  If a database is
# specified, that will be the one connected to by client tools if none
# is specified on the command line.  If the database specified here is
# "*", this is interpreted as the database whose name is the same as
# the user's login.  (Setting the database to "*" will provide the
# current default upstream behaviour for command line tools.)
#
# When pg_wrapper scans this file, the first matching line is used.
# It is a good idea to provide a default explicitly, with a final line
# where both user and group are set to "*".  If there is no default,
# the implicit default is to connect to the cluster whose postmaster
# is listening on port 5432 and to the database matching the user's
# login name.
#
# In the context of this file, user and group refer to the Unix login
# or group, not to PostgreSQL users and groups.
#
# Please see user_clusters(5) and postgresqlrc(5) for more information.
#
# USER	GROUP	VERSION	CLUSTER	DATABASE
*     *    9.0     main      *
*     *    8.4     main      *

3.- Conectar a los diferentes clústeres

Finalmente ya podemos conectarnos a los diferentes clústeres.
Para conectar con el clúster de la versión 8.4 escribiremos:

#psql template1 postgres -h localhost -o 5432 --cluster "8.4/main"

y para hacerlo con la versión 9.0 usaremos algo similar a :

#psql template1 postgres -h localhost -o 5433 --cluster "9.0/main"

4.- Anexo: Contenido del fichero ~/.postgresqlrc


8.2 192.168.0.3:55514 alvherre
8.1 192.168.0.3:55513 alvherre

Categorías:Tecnología, Ubuntu Etiquetas: ,