Hiparco

Recetas y trucos de GNU/Linux e informática en general

Alojado en http://guimi.net

Firma digital con Debian GNU/Linux y Sinadura

Uno de los usos interesantes del DNIe es firmar un archivo PDF. Esta firma tiene plena validez legal. Es decir, hasta hace poco había que hacer un documento, imprimirlo y después firmarlo a mano. Ahora podemos hacer un documento, guardarlo como PDF (por ejemplo con OpenOffice Writer) y después firmarlo con nuestro DNIe.
Hay que insistir en que tiene plena validez legal. Sirve para hacer contratos, compra ventas, reclamaciones…

Sinadura permite firmar digitalmente tanto archivos PDF como otro tipo de archivos.

Vamos a instalar Sinadura 3.3.3 en Debian GNU/Linux Wheezy (Debian 7).

Primero descargamos Sinadura, en este caso he descargado la versión 3.3.3 para GNU/Linux de 64 bits:

$ wget http://www.sinadura.net/documents/18043/196213/sinaduraDesktop-3.3.3-unix64-installer.jar

Su instalación es muy sencilla, basta con hacer:

$ java -jar sinaduraDesktop-3.3.3-unix64-installer.jar

y seguir el típico asistente de “siguiente”, “siguiente”, “siguiente”…

…pero no funciona todavía. Hay que modificar un detalle de opensc:

# vi /etc/opensc/opensc.conf

Buscar y descomentar (quitar el ‘#’) la siguiente línea:

# plug_and_play = false;
 plug_and_play = false;

Para configurar Sinadura vamos a “Archivo -> Preferencias -> Firma -> Certificados“, y elegir “Tarjeta Inteligente“.
También recomiendo ir a “Archivo -> Preferencias -> Firma -> PDF” y seleccionar otra imagen ya que la que viene por omisión (el logo de Sinadura) apenas permite leer el texto insertado. De paso cambiamos la razón, la ubicación y la certificación por defecto (No permitir cambios).
Yo me he creado una imagen muy clarita del DNIe en grises y la he copiado en /sinadura/resources/images.
 

Utilizamos el botón “Añadir documentos” para seleccionar el documento pdf a firmar, en mi caso “prueba.pdf” y pulsamos “Firmar“.
DNIe

El programa carga el certificado (la primera vez tarda un poco, si se cuelga probablemente sea por un problema de sesiones: sacar e introducir el DNI) y después nos pide el PIN del DNIe.
DNIe

Después elegimos el certificado a utilizar, en este caso el certificado de firma:
DNIe

Nos solicita una confirmación:
DNIe

Y ya está. Podemos verificar cualquier documento firmado también desde Sinadura. Primero lo seleccionamos y después utilizamos el botón “Validar
DNIe

firma digital, dnie, dni electrónico, linux, debian, wheezy, sinadura

sshfs – Montando recursos mediante SSH y FUSE

Mediante SSH y FUSE podemos montar un recurso de una máquina remota. Se pueden usar las opciones de ssh y de fuse, pero puede resultar un poco confuso.
Aquí un ejemplo con opciones para cambiar el puerto y usar un fichero de clave:

$ sshfs guimi@guimi.net:/home/guimi ~/mnt -p [puerto] -o IdentityFile=[fichero]

Instalación
Como siempre, es muy facil:

# aptitude install sshfs

Además, el usuario debe estar en el grupo “fuse”.

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Túneles SSH
Uso de ssh
Uso de scp

ssh, fuse, sshfs

DNIe en Debian GNU/Linux Squeeze 64 bits

Este artículo muestra cómo instalar el DNIe en Debian GNU/Linux Squeeze aunque es extensible a otras distribuciones y versiones.

Para instalar el DNIe en sistemas más antiguos.

Una vez instalado un lector de DNI-e, también nos sirve para utilizar tarjetas criptográficas CardOs M4 como las que utiliza por ejemplo la Comunidad Valenciana a través de la ACCV.

El DNI electónico o DNIe se puede hacer funcionar en GNU/Linux, tanto para identificarse en webs como para firmar documentos todo con plena validez legal. Su instalación es, ahora, muy sencilla.

DNIe DNIe

No hay que olvidar que el DNIe tiene sus limitaciones y pegas de seguridad. (Para los “paranoicos” se recomienda utilizar el DNIe únicamente desde sistemas de solo lectura como un CD con Knoppix).
Tampoco hay que olvidar que una firma “normal” es mucho más facil de falsificar que una firma electrónica, pese a que ninguna sea totalmente segura.
 
Las siguientes instrucciones se han probado en Debian Squeeze 64 bits con un lector C3PO LTC31 (de venta en las oficinas de correos por 19,90 €), con un “miniLector Bit4id” del plan avanza2 (es un Advanced Card Systems ACR38-U pero con una caja blanca) y con un lector Omnikey 3021.
C3PO_LTC31 ACS_ACR38-U Omnikey 3021

 

INSTALACIÓN DEL LECTOR

Básicamente vamos a instalar el paquete de la web del dnielectronico.

$ wget http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/Debian_Squeeze_opensc-dnie_1.4.8-2_amd64.deb

Para hacerlos funcionar necesitaremos algunos paquetes:

# aptitude install libopensc2 opensc pinentry-gtk2

 
Nos indica que hemos de registrar el módulo PKCS#11 en iceweasel/firefox utilizando el enlace que nos crea en el menú principal del escritorio en “Oficina-> Registrar módulo DNIe PKCS#11“.
Cuando lanzamos este enlace, indicamos que confiamos en la nueva Autoridad Certificadora (CA) para las tres posibilidades.
 
Podemos comprobar si el sistema reconoce correctamente el lector con el comando “pcsc_scan” y probando a introducir y sacar el DNIe (u otras tarjetas similares):

# aptitude install pcscd pcsc-tools
$ pcsc_scan
PC/SC device scanner
[...]
Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card inserted, 
[...]
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
	DNI electronico (Spanish electronic ID card)
	http://www.dnielectronico.es

 Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card removed, 

 
Otras pruebas que podemos hacer son (estas con una tarjeta CardOs M4):

$ opensc-tool -l
Readers known about:
Nr.    Driver     Name
0      pcsc       C3PO LTC31 (00426664) 00 00
$ opensc-tool -a
Using reader with a card: C3PO LTC31 (00426664) 00 00
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
$ opensc-tool -n
Using reader with a card: C3PO LTC31 (00426664) 00 00
CardOS M4

 
Para que funcione bien iceweasel/firefox y detecte el módulo sin problemas es necesario reiniciar el navegador.
 
 

USO Y DISFRUTE

Lo primero que hay que saber es que en el DNIe tenemos a nuestra disposición dos certificados, uno para identificarnos (certificado de autenticación) y otro para firmar (certificado de firma), lo que son los dos principales usos del DNIe.

También es importante saber que cada aplicación que utiliza el DNIe establece una “sesión” con el lector de tarjetas y que no puede haber dos sesiones abiertas a la vez. Es decir no podemos usar el DNIe en dos aplicaciones a la vez. Sin embargo muchas aplicaciones no indican adecuadamente esta circunstancia y simplemente parece que no funcionan.
Así por ejemplo si iniciamos sesión en iceweasel/firefox para acceder a una web, no podemos firmar un archivo pdf con sinadura hasta cerrar sesión. Y al revés, tras firmar un fichero con sinadura no nos deja validarnos con iceweasel.
Ante la duda basta con extraer y volver a introducir el DNIe en el lector para asegurarse que está disponible el acceso.
 
Un último recordatorio, si se introduce el PIN del DNIe erróneamente tres veces seguidas, éste se bloquea. Así que al hacer pruebas con los programas y sus configuraciones hay que tener cuidado. A mí se me bloqueó haciendo pruebas con Sinadura (para desbloquearlo hay que pasar 5 minutos por una comisaria), así que después cada vez que hacía una prueba con un programa si no funcionaba perfectamente iniciaba sesión en iceweasel/firefox.
 

Identificarse en sitios web con iceweasel/firefox

El DNIe se puede utilizar al navegar para identificarse en un sitio web. Así por ejemplo si nos identificamos en la web de la seguridad social podremos descargarnos al instante nuestra vida laboral.

Primero debemos asegurarnos que hemos registrado en iceweasel/firefox el módulo de DNIe PKCS#11 (usando el menú principal del escritorio en “Oficina-> Registrar módulo DNIe PKCS#11“).
En caso contrario podemos registrarlo a mano desde “Editar -> Preferencias -> Avanzado -> Cifrado -> Dispositivos de seguridad“. Seleccionamos “Cargar”, indicamos un nombre, por ejemplo “DNIe – OpenSC PKCS#11”, y la ruta del módulo “/usr/lib/opensc-pkcs11.so”.
DNIe
 
Si la instalación ha sido correcta y tenemos el lector conectado con un DNIe introducido, nos habilitará la opción “Iniciar sesión” (¡bien!). Si iniciamos sesión nos pedirá el PIN, pero antes es mejor reiniciar el navegador para que nos pida instalar el certificado de la DGP (Dirección General de la Policia).
 
Comprobaciones
Podemos probar nuestro DNIe en el navegador en la página de verificación del portal oficial (el enlace para la verificación está al final de esa página).

Si todo ha ido bien el navegador nos pide nuestro PIN para iniciar sesión (si no lo hemos introducido antes):
PIN DNIe

Cuando conectamos con una web en la que debemos identificarnos nos pregunta cuál de los dos certificados (el de firma o el de autenticación) queremos utilizar. Para identificarnos usamos el de autenticación.
Certificado DNIe

Si el navegador nos indica:

El otro extremo de la conexión SSL no puede verificar su certificado.
(Código de error: ssl_error_bad_cert_alert)

Es porque no hemos iniciado sesión correctamente (hemos fallado el PIN 3 veces, no lo hemos puesto, no está bien instalado el lector…).
 
Lo recomendado es “Iniciar sesión” en el navegador solo cuando se necesita y “Terminar sesión” lo antes posible. Si visitamos una página que requiere certificado sin haber iniciado sesión, el navegador nos solicitará el PIN automáticamente, pero para cerrar sesión hay que ir “a mano” a la opción “Dispositivos de seguridad” del menú.
 

Firmar archivos PDF con Sinadura

Otro uso interesante del DNIe es firmar un archivo PDF. Esta firma tiene plena validez legal. Es decir, hasta ahora había que hacer un documento, imprimirlo y después firmarlo a mano. Ahora podemos hacer un documento, guardarlo como PDF (por ejemplo con OpenOffice Writer) y después firmarlo con nuestro DNIe.
Hay que insistir en que tiene plena validez legal. Sirve para hacer contratos, compra ventas, reclamaciones…

Primero descargamos Sinadura, en mi caso he descargado la versión 3.1.2 para GNU/Linux de 64 bits.

Su instalación es muy sencilla, basta con hacer:

$ java -jar sinaduraDesktop-3.1.2-unix64-installer.jar

y seguir el típico asistente de “siguiente”, “siguiente”, “siguiente”…

Lanzamos el programa desde “Aplicaciones->Otras->Sinadura”.
Para configurarlo vamos a “Aplicaciones -> Preferencias -> Firma -> Certificados“, y elegir “Tarjeta Inteligente“.
También recomiendo ir a “Sinadura -> Preferencias -> Firma -> PDF” y seleccionar otra imagen ya que la que viene por omisión (el logo de Sinadura) apenas permite leer el texto insertado. Yo me he creado una imagen muy clarita del DNIe en grises.
 

Utilizamos el botón “Añadir documentos” para seleccionar el documento pdf a firmar, en mi caso “prueba.pdf” y pulsamos “Firmar“.
DNIe

El programa carga el certificado (la primera vez tarda un poco, si se cuelga probablemente sea por el problema de las sesiones que comentabamos al principio) y después nos pide el PIN del DNIe.
DNIe

Después elegimos el certificado a utilizar, en este caso el certificado de firma:
DNIe

Nos solicita una confirmación:
DNIe

Y ya está. Podemos verificar cualquier documento firmado también desde Sinadura. Primero lo seleccionamos y después utilizamos el botón “Validar
DNIe
 

Más posibilidades

Una de las posibilidades que la gente busca es firmar y/o cifrar correos electrónicos con el DNIe.
Hay que decir que técnicamente se puede pero que su validez legal es cuanto menos dudosa, y como lo que se busca con el DNIe es tener validez legal no es muy práctico. Siempre se puede enviar un correo-e “normal” con un pdf firmado como adjunto, por ejemplo un contrato.

Esto es porque técnicamente para firmar y/o cifrar basta con tener un par de claves pública/privada, pero el estándar internacional PKI requiere, para firmar un correo-e, que el certificado de la clave indique una dirección de correo-e, que será la única que se “certificará”. Sin embargo en el DNIe no se indica ninguna dirección de correo-e, por lo que no se puede utilizar las firmas del DNIe para este fin.
Lo más recomendado es firmar y cifrar con claves GPG, u obtener firmas de la FNMT, que sí están preparadas para este propósito.
En todo caso hay buenas y sencillas guías en internet sobre cómo conseguir, técnicamente, firmar correos-e con el DNIe (GMail+DNIe; Thunderbird+DNIe).

Para consultar otras posibilidades tenemos el oráculo, la página de Servicios Disponibles o la web Kriptopolis.
 
 

dnie, dni electrónico, linux, debian, squeeze, C3PO LTC31, miniLector Bit4id, ACS ACR38-U

Uso de scp

El uso de scp es muy similar al de ssh (Uso de ssh).
El único parámetro “importante” que cambia es el que indica el puerto, que en ssh es -p y en scp es -P. Todavía no entiendo el porqué de este cambio tan molesto.

El uso es muy similar a cp pero indicando el equipo remoto.

Para copiar el fichero local “prueba” en el equipo remoto (servidor) usamos:

$ scp prueba servidor:.

El fichero se copiará en la carpeta inicial del usuario en el servidor (generalmente ‘/home/usuario/’).

Podemos indicar rutas relativas a la carpeta inicial o absolutas.
Para copiar el fichero “documentos/prueba” del servidor al equipo local usamos:

$ scp servidor:documentos/prueba .

Ahora, usando parámetros de ssh/scp:

$ scp -P 10022 -i .ssh/id_dsa *.tgz usuario@servidor:/ruta/fichero

Otros artículos relacionados:
Configuración de ssh
Confianza ssh
Túneles SSH
Uso de ssh
sshfs – Montando recursos mediante SSH y FUSE

ssh, scp
 

Uso de ssh

En esta entrada resumiré los diferentes usos del cliente ssh que han ido apareciendo en otras entradas.
Para configurar un servidor ssh se puede consultar: Configuración de ssh.

El uso más sencillo del cliente ssh es:

$ ssh servidor

Esto nos abre una sesión remota interactiva con servidor.
Estamos dando por supuesto que el usuario del equipo remoto tiene el mismo nombre que nuestro usuario local y que el servidor ssh está escuchando en el puerto estándar (22).
Para indicar el usuario del servidor hacemos:

$ ssh usuario@servidor

Algunos parámetros útiles:

-p puerto
Indica el puerto del servidor ssh al que conectarse (puerto)
-i fichero
utiliza el fichero de claves fichero para autenticar la conexión, en vez de usuario/password (ver Confianza ssh)
-X
Indica que queremos utilizar nuestro servidor X para las aplicaciones gráficas (ver Túneles SSH)
-L puerto_local:maquina3:puerto_maquina3
Realiza un túnel entre puerto_local y maquina3:puerto_maquina3 (ver Túneles SSH)
-R puerto_remoto:maquina3:puerto_maquina3
Realiza un túnel entre servidor:puerto y maquina3:puerto_maquina3 (ver Túneles SSH)
-N
Sin conexión interactiva (útil en Túneles SSH)
-f
En segundo plano (útil en Túneles SSH). Al acabar puede usarse, por ejemplo $ killall ssh

Por ejemplo con ficheros de claves, puerto no estándar, usuario diferente del local y varios túneles:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Túneles SSH
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

ssh

Túneles SSH

Podemos usar SSH para generar túneles seguros. Estos túneles ssh establecen una conexión cifrada entre un puerto de nuestra máquina local y otro puerto accesible desde la máquina remota, generalmente un puerto local de la máquina remota, pero no necesariamente.

Puede ver como configurar un servidor ssh [Configuración de ssh], de confianza ssh, usos básicos de ssh [Uso de ssh] y scp [Uso de scp].

Túnel directo

Si queremos conectar con un servidor MySQL de una maquina remota “servidor” sin usar ssh conectaremos con nuestro cliente de base de datos al puerto 3306 del servidor. El problema es que toda la comunicación es insegura y viaja en claro.
Si “servidor” dispone de ssh podemos generar un túnel ssh para proteger la comunicación. Lo que hacemos es “conectar” un puerto de nuestra máquina local, por ejemplo 13306 con el puerto 3306 de “servidor”. Después conectamos nuestro cliente de base de datos al puerto local 13306 y ssh se encargará de comunicar con “servidor” de manera segura.

Para hacer este primer túnel sencillo hacemos:

$ ssh servidor -L 13306:localhost:3306

Esto indica que el puerto 13306 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:3306”; esto es el puerto local 13306 apunta al puerto 3306 de “servidor”.

También podemos complicar un poco el comando ssh para usar ficheros de claves (http://guimi.net/blogs/hiparco/confianza-ssh/) que es lo recomendado, mediante -i; para indicar el usuario de la máquina “servidor” si no coincide con el usuario de la máquina local; para indicar el puerto ssh del servidor (si no utiliza el puerto por omisión: 22).
Esta vez generaremos un túnel para el puerto 5432 (el puerto habitual de PostgreSQL) desde el puerto local 5555:

$ ssh usuario@servidor -p x -i id_dsa_copiada -L 5555:localhost:5432

El puerto 5555 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:5432”; esto es el puerto local 5555 apunta al puerto 5432 de “servidor”.

Túnel a una tercera máquina

Supongamos que “servidor-ssh” y “servidor-svn” son dos máquinas de una red local. Uno tiene ssh y otro svn. Nos interesa desde internet conectar de forma segura al servidor de svn:

$ ssh servidor-ssh -L 3690:servidor-svn:13690

El puerto 3690 de la máquina local (cliente) se dirige al puerto que servidor-ssh conoce como “servidor-svn:5432”; esto es el puerto local 5555 apunta al puerto 5432 de la máquina que servidor-ssh conoce como “servidor-svn”. Es importante remarcar que el nombre “servidor-svn” lo resuelve “servidor-ssh”, no nuestro cliente local, por tanto puede ser la IP de la red local o un nombre que sea capaz de resolver “servidor-ssh”.

Con esto establecemos una conexión segura hasta “servidor-ssh” que a su vez conecta en claro (por la red local) con “servidor-svn”. De esta forma si utilizamos un cliente SVN para conectar con el puerto local 13690, la información estará viajando protegida por el túnel ssh hasta “servidor-ssh” y después en claro hasta “servidor-svn”.
Esto permite que “servidor-svn” no tenga ninguna conexión directa con el exterior y esté más protegido.

Túnel inverso

Aunque menos utilizado puede interesarnos que un puerto del equipo “servidor-ssh” se redirija a un puerto a través de nuestra máquina local:

$ ssh servidor -R 13690:localhost:3690

De esta manera todas las conexiones al puerto 13690 de “servidor” será redirigidas al puerto “localhost:3690” de la máquina local.
También se puede hacer por tanto:

$ ssh servidor -R 13690:otra-maquina:3690

El puerto 13690 de la máquina “servidor” se dirige al puerto que nuestra máquina local conoce como “otra-maquina:3690”; esto es el puerto servidor:13690 apunta al puerto que nuestra máquina local conoce como “otra-maquina:3690”. Es importante remarcar que el nombre “otra-maquina” lo resuelve nuestra máquina local.

Túnel no interactivo

Podemos usar la opción -N para que no se abra una conexión interactiva (una consola remota) y podemos usar -f para que el cliente ssh pase a en segundo plano. De esta forma si solo queremos hacer el túnel es más cómodo. Por ejemplo para habilitar un túnel a un servidor de OpenERP:

$ ssh servidor -N -f -L 18070:localhost:8070

Túnel de las X (servidor gráfico)

Aquí trataremos algo totalmente diferente a todo lo anterior. En principio, cuando abrimos una terminal remota mediante ssh “solo” podemos utilizar comandos sin GUI y no aplicaciones gráficas. Podemos pedirle a ssh que para la sesión abierta utilice nuestras X locales (si las tenemos, claro) como servidor gráfico. Así podemos lanzar comandos con GUI, es decir aplicaciones gráficas, que se ejecutarán en el servidor pero las veremos en nuestra máquina local.

$ ssh servidor -X

Varios túneles a la vez

Pueden generarse varios túneles a la vez, por ejemplo:

$ ssh servidor -X -L 18070:localhost:8070 -L 5555:localhost:5901

O con ficheros de claves, puerto no estándar y usuario diferente del local:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Uso de ssh
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

ssh, túnel, túneles ssh

SVN+SSH: Conectar con un servidor SVN mediante SSH

Hay bastantes articulillos sobre como conectar con un servidor SVN mediante SSH, utilizando la opción directa, que no nos permite usar ficheros de claves pública/privada de ssh (confianza ssh), ni modificar el puerto de ssh, ni en definitiva usar toda la potencia de ssh.
El sistema directo para configuraciones sencillas de ssh es:
$ svn co svn+ssh://servidor/proyecto
Pero si el servidor está configurado con un mínimo de seguridad esto no es suficiente (Configuración de ssh).

Sin embargo hay una forma casi igual de sencilla usando los túneles SSH que nos permite toda la funcionalidad y potencia de SSH (claves ssh, puerto…).
Primero, desde el cliente, hacemos un túnel ssh desde el puerto 3690 del servidor al puerto 3690 de la máquina local (cliente). En este ejemplo modificamos el puerto y utilizamos claves ssh:
$ ssh usuario@servidor -p xx -N -f -i id_dsa_key_ssh -L 3690:localhost:3690

A partir de hay usamos svn como si estuviese instalado en local:
$ svn co svn://servidor/proyecto

Los túneles ssh son uno de los mejores inventos… se pueden usar para acceder “localmente” a cualquier servidor externo, de cualquier servicio (postgres, svn…) de forma segura y cómoda. [Túneles SSH]

svn, shh, tunel ssh, subversion

Copias de seguridad en PostgreSQL

Si tenemos una base de datos con información importante, es imprescindible hacer copias de seguridad.

Para ello, con postgres, podemos utilizar el siguiente script:

#!/bin/bash
#
# pg_copia.sh
# Por Guimi 2008/11 - http://www.guimi.net
# Basado en un script de http://www.cyberciti.biz/tips/howto-backup-postgresql-databases.html
#

##########################
# PARAMETROS
DIR="/var/lib/postgresql/copias"
LOG="pg_copia.log"

# Vamos al directorio de copias
cd $DIR

# Marcamos el inicio del script en el registro
echo "["`date +%C%y/%m/%d-%X`"] --- Iniciando pg_copia ---" >> $LOG

# Obtenemos la lista de BBDD, excluyendo template0 y template1
LISTA_BBDD=$(psql -l | awk '{ print $1}' | grep -vE '^-|^:|^List|^Name|^Nombre|^\(|template[0|1]')
# Para cada BBDD hacemos un volcado
for BBDD in $LISTA_BBDD
do
  FICHERO_COPIA="$BBDD.sql.gz"
  # Rotamos copias anteriores
  mv $FICHERO_COPIA".004" $FICHERO_COPIA".005" > /dev/null 2>&1
  mv $FICHERO_COPIA".003" $FICHERO_COPIA".004" > /dev/null 2>&1
  mv $FICHERO_COPIA".002" $FICHERO_COPIA".003" > /dev/null 2>&1
  mv $FICHERO_COPIA".001" $FICHERO_COPIA".002" > /dev/null 2>&1
  mv $FICHERO_COPIA $FICHERO_COPIA".001" > /dev/null 2>&1
  # Hacemos la copia
  pg_dump $BBDD | gzip -c > $FICHERO_COPIA
  # Marcamos en el registro la copia
  if [ "$?" -eq 0 ]
  then
    echo "[OK] $BBDD copiada" >> $LOG
  else
    echo "[ERROR $?] $BBDD NO copiada" >> $LOG
  fi
done

#Para restaurar una copia use:
# gunzip $FICHERO_COPIA
# psql -d $BBDD -f $FICHERO_COPIA > dump_$BBDD.log

 
Podemos programar el sistema para que realice copias automáticamente de forma regular mediante crontab -e.

Para restaurar una copia usamos:
$ gunzip miBD.sql.gz
$ psql -d miBD -f miBD.sql.gz > dump_miBD.log

De esta manera también podemos “llevarnos” una BDD de un servidor a otro. Primero hacemos la copia de seguridad en el servidor ‘origen’, y después en el servidor ‘destino’ creamos la BD y restauramos la copia:
$ createdb -O mi_usuario miBD
$ gunzip miBD.sql.gz
$ psql -d miBD -f miBD.sql > dump_miBD.log

postgres, copia de seguridad, backup postgres

Utilizando el navegador para decodificar base64

Esta nota procede de “Use your browser to decode base64 encoded data” de Cristian Radulescu.

Los navegadores puede decodificar base64, por eso se usa este sistema para “ofuscar” partes de código.
Para “desofuscarlo” basta con preguntarle al propio navegador introduciendo una cadena URI normal.
Así, por ejemplo, podemos poner en la barra del navegador:

data:text/plain;base64,bWVzc2FnZSBlbmNvZGVkIGluIGJhc2U2NA==

Y el navegador nos mostrará:

message encoded in base64
base64