La Mirada hecha Pedazos Fotografía libre con software libre

Gestión de color en Iceweasel

Si quieres trabajar con fotografías en entornos web, deberías de mantener la gestión de color en todo el proceso, pero por defecto los navegadores no aplican las correcciones de color al contenido que muestran. A continuación paso a describir cómo tengo configurado Iceweasel (El lado libre de Firefox) para que aplique la gestión de color al contenido web. Partimos de la suposición de que tienes correctamente calibrada la pantalla y no aplicas el perfil de color a tu escritorio; si aplicas el perfil de color a todo el escritorio no es necesario que modifiques estos ajustes.

Para modificar la configuración de la gestión de color tendremos que acceder a la configuración avanzada poniendo en la barra de direcciones: about:config; aceptamos que nos metemos en una zona de riesgo (camisa de once varas) y ponemos en el buscador de palabras color_management.

undefined

 

Para editar cada una de las opciones, hacemos click con botón derecho y "Modificar".

  • gfx.color.management.display_profile: Aquí debes de poner la ruta completa al perfil (archivo.icc) de tu pantalla. Si has calibrado con dispcalGUI, tu perfil se esconde en: /home/usuario/.local/share/dispcalGUI/storage/
  • gfx.color.management.enablev4: Esta opción activa la posibilidad de soportar versiones de archivo ICC v4. (true)
  • gfx.color.management.mode: Esta opción es la que activa la gestión de color, concretamente:
    • 0 Desactivada
    • 1 Activa para todo el contenido web (Esta es la opción preferida)
    • 2 Activa sólo para la imágenes
  • gfx.color.management.rendering_intent: Esta última opción define el modo de gestión del color
    • -1 El modo de gestión viene definido en la imagen
    • 0 Perceptual (por defecto)
    • 1 Relativo colorimétrico (Para fotografía yo utilizo este)
    • 2 Saturación
    • 3 Absoluto colorimétrico

Para terminar y que los cambios tengan efecto debes de reiniciar Iceweasel.

Referencias:

 

 

Instalación de UFRaw en debian GNU/Linux

Primero necesitaremos tener instalados los siguientes paquetes:

tomy@dolores:~$ sudo aptitude install libgtk2.0-dev cfitsio-dev liblcms-dev libgimp2.0-dev libtiff-dev libjpeg8-dev libpng12-dev libexiv2-dev zlib1g-dev libbz2-dev libgtkimageview0 libgtkimageview-dev liblensfun-dev liblensfun0

Descargamos el archivo ufraw-0.19.2.tar.gz, y lo descomprimimos en una carpeta temporal:

tomy@dolores:~$ tar xvfz ufraw-0.19.2.tar.gz

Ejecutamos el script configure:

tomy@dolores:~$ cd ufraw-0.19.2
tomy@dolores:~$ ./configure --enable-mime --enable-extras --enable-contrast --enable-dst-correction --prefix=/usr/local

Nos dará como resultado:

configure: ====================== summary =====================
configure: build GTK GUI: yes
configure: build GIMP plug-in: yes
configure: build CinePaint plug-in: no
configure: EXIF support using exiv2: yes
configure: JPEG support: yes
configure: JPEG2000 (libjasper) support: yes
configure: TIFF support: yes
configure: PNG support: yes
configure: FITS support: yes
configure: gzip compressed raw support: yes
configure: bzip2 compressed raw support: yes
configure: Lens defects correction via lensfun: yes

Después compilamos e instalamos los archivos ejecutables:

tomy@dolores:~$ make
tomy@dolores:~$ sudo make install

Si todo ha ido bien deberías de tener funcionando UFRaw sin problemas. Si te has equivocado vuelve a revisar el procedimiento; o prueba a pedir ayuda en el siguiente foro de Fotolibre.

Teniendo la última versión de UFRaw solucionamos problemas de compatibilidad con las cámaras más recientes, además de bugs conocidos como el problema que tiene UFRaw con algunos archivos TIFF que provienen de HUGIN y que los reconoce como suyos, impidiendo abrir estos archivos en Gimp.

Fail2Ban protege tu servidor

Últimamente estoy recibiendo ataques por fuerza bruta al puerto de ssh desde IPs chinas que no tengo yo nada en contra de los chinos, pero es que día tras día todas las IP que intentan entrar en mi servidor son chinas y siempre chinas. Así que me he puesto manos a la obra en buscar una aplicación que bloquee estos ataques a mi servidor y he dado con fail2ban, un monitor de identificaciones que vigila los archivos de log del sistema a la espera de se cumpla cualquiera de sus "reglas" definidas como posible ataque. Fail2Ban vigila varios servicios como ssh, apache, postfix, mysql, etc. y genera unas reglas de bloqueo a través del firewall (iptables) o tcp (/etc/hosts.deny) para bloquear temporalmente o permanentemente en cada caso. Además, envía un correo al administrador del sistema informando de la lista de malhechores.

A continuación paso a describir cómo tenemos que instalar y configurar fail2ban.

Error al ejecutar catfish "fg: no hay control de trabajos"

El error:

/usr/bin/catfish: línea 2: fg: no hay control de trabajos

Es un problema en script que lanza el programa de búsqueda de archivos CatFish. Para solucionarlo tenemos que editar el archivo:

# vim /usr/bin/catfish

Y cambiar el contenido del archivo:

%python% /usr/share/catfish/bin/catfish.py "$@"

Por:

python /usr/share/catfish/catfish.py "$@"

Copias de seguridad con rsync

Todo lo que necesitas hacer es añadir la información de usuario y host (la máquina remota). Por ejemplo, si quieres copiar una carpeta a un equipo remoto, has de hacer esto:

rsync -avhe ssh --delete /home/usuario/dir/ usuario@remote.host.com:dir/

Si quieres saber lo rápido que va la transferencia, y cuánto queda por copiar, añade la opción --progress:

rsync --progress -avhe ssh --delete /home/usuario/dir/ usuario@remote.host.com:dir/

Para evitar la pregunta de la contraseña cada vez que rsync haga una conexión asegúrate de configurar rsync para acceder mediante una clave SSH en lugar de una contraseña. Para ello, se crea una clave SSH en la máquina local usando ssh-keygen -t dsa, y pulsa Intro cuando te pregunte por una passphrase. Tras crear la clave, usa ssh-copy-id -i .ssh/id_dsa.pub user@remote.host.com para copiar la clave pública al equipo remoto.

¿Y qué sucede si necesitas traer de vuelta a algunos de los archivos copiados usando rsync? Usa la siguiente sintaxis:

rsync -avze ssh remote.host.com:/home/usuario/dir/ /local/path/

La opción z es para comprimir los datos durante su transferencia. Si el fichero que estás copiando existe en el equipo local, rsync lo dejará sin tocar, y lo mismo pasaría si estuvieras moviendo ficheros a una máquina remota.

Si intentas hacer copias de seguridad entre sistemas de archivos diferentes (por ejemplo linux <-> windows) tendrás problemas con los cambios de permisos, propietarios y grupo, lo mejor sería omitir estos cambios, y si además quieres usar un puerto de ssh diferente al 22, por ejemplo el 2367 se puede hacer de la siguiente manera:

rsync -rltDz ssh --delete /home/usuario/dir/ usuario@remote.host.com:dir/

Repositorio de paquetes de las distribuciones antiguas de GNU Debian

En ocasiones tenemos ordenadores que ya sea por sus características técnicas o porque simplemente funcionan bien y mejor no tocarlos; pasa el tiempo y su distribución se queda sin repositorios en las imágenes habituales.  GNU Debian mantiene un archivo (archive.debian.org) para todas sus versiones obsoletas que puedes añadir a tu archivo sources y seguir funcionando con tu ordenador:

deb http://archive.debian.org/debian/ etch main
deb http://archive.debian.org/debian-security/ etch/updates main
deb http://archive.debian.org/debian-volatile/ etch/volatile main
deb-src http://archive.debian.org/debian/ etch main
deb-src http://archive.debian.org/debian-security/ etch/updates main
deb-src http://archive.debian.org/debian-volatile/ etch/volatile main

En este caso se trata de un archivo sources de una distribución Etch, pero puedes sustituir el nombre por la tuya.

Mensaje de error "There is no public key available for the following key IDs"

Cuando después de un apt-get update obtenemos este error de las claves de acceso público tenemos que hacer lo siguiente:

# apt-get install debian-keyring debian-archive-keyring
# apt-key update

Si todavía recibes el error de que no existe llave pública:

W: Error de GPG: http://deb-multimedia.org wheezy Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 07DC563D1F41B907
W: Error de GPG: http://cran.es.r-project.org wheezy-cran3/ Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 06F90DE5381BA480
W: Error de GPG: http://qgis.org wheezy Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY BBA6491F47765B75

Necesitas identificarte como root:

tomy@estacha:~$ sudo su -

Descargar cada una de las llaves que te faltan:

~# gpg --keyserver pgpkeys.mit.edu --recv-key 07DC563D1F41B907 
~# gpg --keyserver pgpkeys.mit.edu --recv-key 06F90DE5381BA480
~# gpg --keyserver pgpkeys.mit.edu --recv-key BBA6491F47765B75

Y añadirlas a APT:

~# gpg -a --export 07DC563D1F41B907 | apt-key add -
~# gpg -a --export 06F90DE5381BA480 | apt-key add -
~# gpg -a --export BBA6491F47765B75 | apt-key add -

Fijar el BUG de las reglas ignore de Logcheck para SSMTP

La configuración del servicio MTA SSMTP, para enviar correos desde un ordenador utilizando servidores de correo externos, como openmailbox.org, provoca que Logcheck, envíe avisos cada hora, debido a un BUG Debian Bug Tracker:

System Events
=-=-=-=-=-=-=
Aug 28 11:03:02 chicote sSMTP[14118]: Creating SSL connection to host
Aug 28 11:03:02 chicote sSMTP[14118]: SSL connection using RSA_ARCFOUR_SHA1
Aug 28 11:03:05 chicote sSMTP[14118]: Sent mail for logcheck@tomassenabre.es (221 2.0.0 closing connection i8sm3430215wib.1 - gsmtp) uid=111 username=logcheck outbytes=1086

Publicaciones mas nuevas → Pagina de inicio ← Publicaciones mas antiguas