Cómo cambiar la fecha y/o la hora en el EXIF de una imagen JPEG

A veces hay que cambiar la fecha y/o la hora EXIF de imágenes JPEG. La causa más evidente es una cámara con la hora incorrecta o tras el cambio horario en primavera/otoño.

Por ejemplo, si hacemos fotos tras el cambio de horario de invierno a verano, pero no hemos ajustado la hora de la cámara apropiadamente, podemos hacer lo siguiente:

$ jhead -ta+1:00 *.JPG

Este comando adelanta una hora todas las fotografías en ese directorio.

La utilidad jhead es una virguería. Échale un vistazo.

Cómo borrar los detalles GPS de una imagen JPEG

Si alguna vez necesitas borrar los datos GPS contenidos en los campos EXIF de una imagen JPEG, puedes hacer lo siguiente:

$ exiftool -gps:all= -xmp:geotag= *.JPG

Para esto es conveniente que tengas una versión reciente de exiftool, ya que la mayoría de las distribuciones Linux incluyen versiones antiguas.

Dependiendo de la fuente original, esta limpieza puede ser insuficiente. Ten cuidado si tu vida depende de ello [1].

Algunas referencias:

[1] Una opción más segura, pero mucho más agresiva, es borrar todos los datos EXIF, IPCT y XML de la imagen. Echa un vistazo al manual de la utilidad jhead.

How to delete Dovecot users when using Single Instance Storage

In the old days, deleting an IMAP4 user in Dovecot was quite easy: just delete the user in the user database and then delete the user IMAP4 directory.

This is dangerous when Dovecot is configured to use Single Instance Storage. In this configuration, attachments over some size are stored separately as files in the filesystem. If several users in the system receive the same attachment, only a copy is stored in the server.

Deleting is tricky because the attachments keep a reference counter. If we just simply delete the user mailbox we will leak her attachments. Those files will be there forever.

Deletion must be done with care. The steps I do are:

Leer más…

Mapas y capas de información

Tal y como explico en ¿Cómo monto mis páginas web de viajes? (II), antes empleaba una funcionalidad de Google Maps que permitía mostrar un fichero KML hospedado en mi propio servidor web. Nunca me ha gustado mucho depender de Google, pero en aquel momento no había mucho donde elegir.

Google eliminó esta funcionalidad en una revisión posterior de Google Maps. Por un lado, trabajo extra; por otro, explorar alternativas.

Ahora el criterio fundamental es desplegar una solución que pueda hospedar yo mismo y que, en caso necesario, pueda reemplazar con facilidad y sin tener que modificar mi web de forma extensiva.

Tras mucho tiempo investigando el asunto y preguntando a expertos en el tema, acabé curioseando la librería Follium. La idea es buena: seleccionar un mapa, añadir puntos de información, polígonos, líneas, etc., todo ello desde Python y al final exportar un mapa interactivo que se pueda incrustar una página web personal.

Tras evaluar Follium cuidadosamente, me pareció que no se ajustaba a mis necesidades. No obstance, conocí gracias a ella librería Javascript subyacente: Leaflet.js

Leer más…

Geolocalización en una cámara de fotos WIFI (¿Cómo monto mis páginas web de viajes? (II bis))

En ¿Cómo monto mis páginas web de viajes? (II) explico la última versión de mi workflow para preparar las fotografías de mis viajes. Me dejé un detalle importante, no obstante.

Mi cámara Canon SX60 HS dispone de WIFI. Este tema da para varios artículos, pero en este me voy a centrar en la capacidad de geoetiquetación diferida de las fotografías de la cámara.

En mi iPhone puedo instalar un programa de Canon llamado Camera Connect. El programa es bastante limitado, pero una funcionalidad muy interesante es la grabación de datos GPS para geoetiquetar las fotografías de la cámara Canon a posteriori.

canon_camera_connect.png

Leer más…

Desactivar "alternate screen" en "screen"

Este tema está documentado en mil páginas webs, pero lo escribo aquí para tenerlo a mano.

Screen es un multiplexador de terminales [1]. Supe de él hace muchos muchos años y lo empleo con dos fines fundamentales: tener varias sesiones de terminal en la misma ventana SSH y poder reanudar una sesión SSH con todo abierto y funcionando tras un reinicio del ordenador cliente, un corte de la conexión SSH o para migrar la sesión a otro ordenador cliente (del trabajo a casa y viceversa, o al móvil).

Uno de los problemas habituales con screen es perder el scroll de la sesión de terminal. Esto es debido a que screen, por defecto, emplea lo que se llama alternate screen. El truco es desactivarlo. Para ello editamos el fichero .screenrc y añadimos:

termcapinfo xterm ti@:te@

(Si nuestro terminal simula ser un xterm) [2].

Con esto recuperaremos nuestro scroll :-).

Como dije al principio, esto es más que conocido, pero espero haberle solucionado el día a alguien.

[1] Existen alternativas a screen más modernas y capaces, como tmux, pero llevo con screen muchos años, lo conozco a fondo y la consistencia entre los entornos heterogeneos en los que me muevo es primordial para mí.
[2]

Para saber qué tipo de terminal simula nuestro servidor debemos conectar por SSH y revisar la variable de entorno TERM. En mi caso:

$ env | grep -i term
TERM=xterm

Esto hay que hacerlo fuera de la sesión screen, claro. Screen definirá su propia variable de entorno TERM a screen, junto con una variable de entorno TERMCAP personalizada.

Concatenar ficheros de vídeo

Alguna gente sigue troceando los ficheros de vídeo por motivos misteriosos, posiblemente relacionados con limitaciones del vetusto FAT32. En todo caso eso no es un problema para mí y, en cambio, tener que manejar películas divididas en varios ficheros sí me resulta inconveniente.

Los pasos que doy para dejarlo todo en un único fichero son:

Leer más…

Backup doméstico seguro con Linux, cifrado y ZFS (VI)

El tema está ya muy machacado en artículos previos. Recomiendo leer toda la serie.

De ahora en adelante documentaré los puntos básicos que vayan cambiando en el proceso de intercambio de disco dos veces al año y actualizaciones del procedimiento.

El intercambio de navidades de 2015-2016 siguió el proceso normal:

  1. Enchufamos el disco previamente almacenado. Llamemos a ese disco duro, disco duro 2. El disco duro que estaba conectado se llamará disco duro 1.

  2. Actualizamos los scripts de montaje y desmontaje de las unidades de disco.

  3. Desciframos y montamos los dos discos duros.

  4. Indicamos a ZFS que tiene online el disco duro 2. Esto inicia una sincronización de los cambios ocurridos desde el verano.

    Este proceso copia 182GB y tarda 9 horas y 38 minutos.

    En esta ocasión hay muchos más datos a sincronizar de lo normal porque el pool ZFS contiene ahora el backup de un servidor adicional.

  5. Luego hacemos un zfs scrub para que ZFS revise con detalle ambos discos duros, a la caza de errores e inconsistencias.

    Esto tiene que repasar 2*1.72TB y tarda 25 horas y 24 minutos.

  6. Revisamos los datos S.M.A.R.T. de ambos discos duros para asegurarnos de que todo parece correcto.

  7. Le decimos a ZFS que ponga offline el disco duro 1, actualizamos los scripts de montaje y desmontaje de discos duros.

  8. Desenchufamos el disco duro 1, lo empaquetamos bien y lo guardamos en una localización diferente por si las moscas.

Backup doméstico seguro con Linux, cifrado y ZFS (V)

Antes de continuar, lee:

En esos artículo explico la migración de mi sistema de backup de una máquina virtual a un servidor físico. Proporciona el contexto para este documento.

Por supuesto es conveniente curiosear un poco la historia y la motivación de la tecnología:

El primer cambio de disco con el nuevo sistema se produjo en verano de 2015. Veamos los pasos:

Leer más…