psql sin contraseña

El programa psql es el indicado para efectuar un buen número de trabajos en el servidor PostgreSQL, muchos de ellos no interactivos, por lo que es conveniente recordar aquí las diferentes posibilidades que existen para no requerir presencia humana.

Empleando el entorno

Se puede emplear la variable de entorno PGPASSWORD para almacenar la contraseña del usuario, pero es un método desaconsejado por varias razones:

• Cualquiera que tenga acceso al entorno del proceso puede acceder a la contraseña.
• Sólo sirve para un usuario en concreto, el que se indica en la conexión con el parámetro -U.

Más información en la documentación de la versión 7.4.

Usando un archivo

Si existe un archivo llamado .pgpass en el directorio de inicio del usuario que invoca al programa psql, y tiene restringidos los permisos de acceso únicamente al usuario (0600), se puede emplear para conservar contraseñas de acceso, siempre que éstas no se especifiquen de otra forma en la llamada.

El archivo contiene líneas con el siguiente aspecto:

hostname:port:database:username:password

donde todos los campos exceptuando el último, el de la contraseña, pueden contener un asterisco (*) a emplear como comodín cuando se buscan los parámetros de conexión. Así pues, es posible definir varias combinaciones entre el servidor de bases de datos, la base de datos y el usuario.

Observaciones:

• Se emplea la primera línea que coincide, así que es mejor definir las entradas más específicas antes que las genéricas.
• Lo de los permisos va en serio; si encuentra un acceso menos restrictivo que 0600 ignora la archivo por completo; conviene comprobar este extremo antes de nada en caso de problemas.

Documentación para la versión 7.4.

Caso práctico: bacula y postgresql

En una de mis redes existen bases de datos que debo incluir en las copias de seguridad, y que tienen que aparecer como volcados, dadas las dificultades (a veces insalvables, como migrar de una versión de 32 bits a una de 64 bits) que supone poner en marcha una recuperación desde archivos del sistema.

Para ello he creado un pequeño programa que obtiene ese volcado mediante la herramienta pg_dump, y que debe ejecutarse antes de cualquier trabajo de copia real. Como empleo bacula para respaldar los datos, he visto que lo más cómodo y limpio es que sea el propio usuario bacula el que se encargue de eso, por lo que el programa se instala en /etc/bacula/scripts con el nombre de dump-databases.sh y tiene éste aspecto:

./../../archive/databases/dump-databases.sh.html

#!/bin/sh

#    Directorio donde almacenar las copias
#    por cada base de datos 
TARGET=/data/backups/postgres

#    Cambio temporal del directorio HOME para tener acceso
#    al archivo .pgpass, dado que en 7.4 no existe la opción 
#    de especificar otro archivo
export HOME=/etc/bacula

#
#    Usuario de conexión con la base de datos, con suficientes permisos para
#    efectuar el volcado 
#
USERDB=postgres

#
#    Comprobamos que podamos escribir en el directorio destino
if [ ! -d $TARGET -a ! -w $TARGET ]; then
    echo $0: could not write to $TARGET 
    exit 1
fi

#    Bases de datos a salvar si no se indica otra cosa
DATABASES="venexma_alpha bacula ecoembes lidia"
if [ $# -gt 0 ]; then
    DATABASES=$*
else
    DATABASES=$(psql -h localhost -U $USERDB -t -c "select datname from pg_database;" template1)
fi

#    Parámetros para volcado de base de datos:
#    - Usuario y servidor
#    - Formato tar 
#    - Incluir instrucciones SQL para borrar la base de datos.
#    - Incluir instrucciones SQL para crear la base de datos.
PGDUMP_OPT="-U $USERDB --format=t --clean --create -h localhost "

#    obtener un grupo de archivos independiente.
for db in $DATABASES
do
    if [ "$db" == "template0" ]; then
        continue
    fi
    cd $TARGET
    mkdir -p $db
    chmod 0750 $db
    cd $db
    pg_dump $PGDUMP_OPT $db | tar xf -
done

Podemos ver como se cambia la variable de entorno HOME para que apunte a /etc/bacula ya que es allí donde tengo el archivo .pgpass con una entrada para el usuario postgres.