• Las búsquedas funcionan extremadamente lentas.
• El número de mensajes importantes o no leídos es incorrecto.
• Algunos mensajes parecen haberse eliminado o no pueden encontrarse.
• Bandejas que contienen mensajes no los muestran al hacer click sobre ellas.

Existen dos acciones muy simples que se pueden realizar para resolver este problema y que no implican ningún tipo de pérdida de información. Se explican debajo.

Reconstruir la base de datos desde el programa Mail

Es la solución más simple y rápida, aunque no siempre resuelve los problemas (en mi caso no funcionó). No obstante, vale la pena intentarlo. Para hacerlo, desde el programa Mail, ir al menú Mailbox (o Buzón) y seleccionar Rebuild (Reconstruir), al final de la lista.

Forzar la reconstrucción de la base de datos

Si lo anterior no funciona, entonces se puede eliminar por completo la base de datos y la misma será regenerada nuevamente al iniciar Mail. Para ello, se debe primero cerrar el programa Mail y luego borrar los archivos de base de datos de correos.

Los archivos se guardan en ~/Library/Mail/V2/MailData/ y la base de datos en el archivo Envelope Index. Si existieran Envelope Index-shm y Envelope Index-wal también se los debe eliminar. Entonces, desde la consola de comandos:

scarlett:~ leandro$ cd ~/Library/Mail/V2/MailData/
scarlett:MailData leandro$ ls | grep -i envelope
Envelope Index
Envelope Index-shm
Envelope Index-wal
scarlett:MailData leandro$ rm Envelope\ Index*

Luego, simplemente se debe volver a iniciar el programa Mail y comenzará a reconstruir la base de datos automáticamente, proceso que debería tomar unos pocos minutos.

Para este tutorial se va a utilizar:

• Storage:
  • Tipo: NAS Lenovo EMC.
  • Nombre: sto01.
  • IP: 192.168.45.190.
• Recursos iSCSI: 1x50GB nombrado como mikroways, 1x10GB nombrado como netstorming.

iSCSI en Ubuntu

Instalar las utilidades de iSCSI.

apt-get install open-iscsi

Luego, se debe descubrir los recursos iSCSI que el dispositivo tiene para ofrecer. En este caso, serán dos.

root@testing:~# iscsiadm -m discovery -t st -p 192.168.45.190
192.168.45.190:3260,1 iqn.2012-07.com.lenovoemc:storage.sto01.mikroways
192.168.45.190:3260,1 iqn.2012-07.com.lenovoemc:storage.sto01.netstorming

Una vez que se detectaron los recursos del dispositivo, se procede a conectarse al storage, lo que llevará a asociar ambos recursos iSCSI a dispositivos de bloque en el sistema operativo cliente.

root@testing:~# iscsiadm -m node --login
Logging in to [iface: default, target: iqn.2012-07.com.lenovoemc:storage.sto01.mikroways, portal: 192.168.45.190,3260] (multiple)
Logging in to [iface: default, target: iqn.2012-07.com.lenovoemc:storage.sto01.netstorming, portal: 192.168.45.190,3260] (multiple)
Login to [iface: default, target: iqn.2012-07.com.lenovoemc:storage.sto01.mikroways, portal: 192.168.45.190,3260] successful.
Login to [iface: default, target: iqn.2012-07.com.lenovoemc:storage.sto01.netstorming, portal: 192.168.45.190,3260] successful.

Verificar que los dispositivos hayan sido correctamente identificados por el sistema operativo.

root@testing:~# dmesg
...
[  327.952760] scsi3 : iSCSI Initiator over TCP/IP
[  327.961930] scsi4 : iSCSI Initiator over TCP/IP
[  328.541159] scsi 4:0:0:0: Direct-Access     LENOVO   LIFELINE-DISK    2    PQ: 0 ANSI: 5
[  328.541490] scsi 3:0:0:0: Direct-Access     LENOVO   LIFELINE-DISK    2    PQ: 0 ANSI: 5
[  328.553741] sd 4:0:0:0: Attached scsi generic sg2 type 0
[  328.554942] sd 3:0:0:0: Attached scsi generic sg3 type 0
[  328.565939] sd 3:0:0:0: [sdb] 104857600 512-byte logical blocks: (53.6 GB/50.0 GiB)
[  328.565942] sd 3:0:0:0: [sdb] 4096-byte physical blocks
[  328.574342] sd 4:0:0:0: [sdc] 20971520 512-byte logical blocks: (10.7 GB/10.0 GiB)
[  328.574347] sd 4:0:0:0: [sdc] 4096-byte physical blocks
[  328.575388] sd 3:0:0:0: [sdb] Write Protect is off
[  328.575394] sd 3:0:0:0: [sdb] Mode Sense: 83 00 10 08
[  328.576772] sd 4:0:0:0: [sdc] Write Protect is off
[  328.576778] sd 4:0:0:0: [sdc] Mode Sense: 83 00 10 08
[  328.577023] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA
[  328.577956] sd 4:0:0:0: [sdc] Write cache: disabled, read cache: enabled, supports DPO and FUA
[  328.590109]  sdb: sdb1
[  328.599811]  sdc: unknown partition table
[  328.602543] sd 3:0:0:0: [sdb] Attached SCSI disk
[  328.605130] sd 4:0:0:0: [sdc] Attached SCSI disk

En la salida anterior se puede ver que ambos recursos iSCSI fueron reconocidos correctamente como dispositivos por bloques por Ubuntu y se les asoció una entrada en /dev. Si se pone atención se puede extraer de la salida anterior la siguiente información, que será importante para la utilización de los recursos.

• Se asocian dos dispositivos por bloques, identificados como sdb y sdc.
• El dispositivo sdb tiene 50G mientras que el sdc cuenta con 10G.
• El dispositivo sdb tiene una tabla de particiones creada, mientras que sdc no. Hay que tener especial cuidado en esto al ejecutar el siguiente paso, porque el dispositivo sdb podría contener información que se perdería.

Esto último puede verificarse utilizando el comando fdisk.

fdisk -l
...
Disk /dev/sdb: 53.7 GB, 53687091200 bytes
64 heads, 32 sectors/track, 51200 cylinders, total 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 524288 bytes
Disk identifier: 0x05b7bb88

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   104857599    52427776   83  Linux

Disk /dev/sdc: 10.7 GB, 10737418240 bytes
64 heads, 32 sectors/track, 10240 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 524288 bytes
Disk identifier: 0x00000000

Disk /dev/sdc doesn't contain a valid partition table

Con ambos dispositivos asociados al cliente, ya es posible empezar a utilizarlos. Para lograr que los recursos se vuelvan a montar al reiniciar el sistema es necesario realizar dos acciones, que son indicarle a Open iSCSI que se conecte automáticamente y al sistema operativo cliente que monte los dispositivos en cuestión. Para el primer paso, editar el archivo /etc/iscsi/iscsid.conf.

Modificar la línea:

node.startup = manual

Por:

node.startup = automatic

Luego, agregar los dispositivos al archivo /etc/fstab. En este caso sólo se agrega el dispositivo /dev/sdb1 dado que, como se vio, el /dev/sdc no está particionado. Poner especial atención en la opción de montaje _netdev. Dicha opción le indica al sistema operativo que se trata de un dispositivo de red. Sin ella, si al momento de reiniciar el equipo el recurso no estuviera disponible, el cliente no iniciaría, esperando una acción por parte del administrador ante su imposibilidad de montar el dispositivo requerido.

/dev/sdb1	/storage/mikroways/	ext3 defaults,auto,_netdev 0 0

Algo importante en este sentido es que, si se montan varios recursos de red, al reiniciar el equipo podrían no mantener la misma asociación en el host. En otras palabras, lo que es /dev/sdb1 podría transformarse en /dev/sdc1 al reiniciar el equipo, lo que podría causar graves problemas. Para solucionarlo, es ideal reemplazar la ruta al dispositivo de bloques por el UUID del mismo. Para más detalles al respecto, consultar la entrada Utilizar los UUID para montar dispositivos.

Por tales motivos, lo ideal es utilizar el identificador único de los diferentes dispositivos de almacenamiento en el sistema. Para ello, existe un comando que es blkid (de Block ID), que nos brinda dicha información:

root@testing:~# blkid
/dev/sr0: LABEL="Ubuntu-Server 13.10 amd64" TYPE="iso9660"
/dev/sda1: UUID="9e906e5e-b0e1-4cc4-a883-1c89289a72c5" TYPE="ext2"
/dev/sda5: UUID="HIXH00-yG4z-ZKW6-Smis-qEra-5W6R-3wsaFh" TYPE="LVM2_member"
/dev/mapper/testing--vg-root: UUID="c071778b-6c3c-49bd-b3dd-e5cbe7ef5e73" TYPE="ext4"
/dev/mapper/testing--vg-swap_1: UUID="4c89e74a-767c-4cd4-bf90-a170ae09b84e" TYPE="swap"
/dev/sdb1: UUID="31fea32c-88c5-4564-b69a-e4e397dd6f6d" TYPE="ext3"

De esta manera, es lo mismo ejecutar:

mount /dev/sdb1  /storage

Que:

mount UUID=31fea32c-88c5-4564-b69a-e4e397dd6f6d /storage

Esto se vuelve aún más útil cuando la intención es que al reiniciar el sistema los diferentes dispositivos de almacenamiento vuelvan a montarse automáticamente en el directorio que les corresponde, y no en otro. Entonces, en /etc/fstab:

UUID=31fea32c-88c5-4564-b69a-e4e397dd6f6d	/storage   ext3    defaults,auto   0    0

Cabe aclarar que el de tipo de filesystem y las opciones de montaje pueden variar dependiendo de qué se quiera montar y de qué manera.

defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder

Notar que el segundo comando cerrará todas las ventanas del Finder que estén abiertas. Luego, al volver a abrir una ventana de Finder se verán los archivos ocultos. Para volver esta operación atrás basta tan sólo con ejecutar nuevamente el par de comandos anteriores pero reemplazando TRUE por FALSE.

Revisé la configuración en /etc/updatedb.conf y encontré que tenía el siguiente contenido:

PRUNE_BIND_MOUNTS="yes"
# PRUNENAMES=".git .bzr .hg .svn"
PRUNEPATHS="/tmp /var/spool /media"
PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs mfs shfs sysfs cifs lustre_lite tmpfs usbfs udf fuse.glusterfs fuse.sshfs curlftpfs ecryptfs fusesmb devtmpfs"

Contenido que, a priori, es correcto para que indexe mi /home, dado que no está dentro de los PATH a ignorar y está formateado con ext4. Como aclaración, lo que hacen las variables PRUNEPATHS y PRUNEFS es indicar que no indexe los directorios listados ni los filesystems especificados, respectivamente.

Ahora bien, al chequear las particiones montadas en mi sistema me encontré con lo siguiente:

leandro@scarlet:~$ mount
/dev/sda3 on / type ext4 (rw,errors=remount-ro,commit=0)
/dev/sda5 on /home type ext4 (rw,commit=0)
/home/leandro/.Private on /home/leandro type ecryptfs (ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs,ecryptfs_sig=3c4c274e018dcd1d,ecryptfs_fnek_sig=8b78ca14201c02d2)

En ese momento recordé que al instalar Ubuntu había indicado que cifre mi carpeta personal y de ahí el problema, que se ve en la tercer línea. Al cifrar mi /home en Ubuntu se creó una carpeta que se llama /home/.ecryptfs/leandro, donde están realmente los datos de mi /home encriptados (/home/leandro/.Private en realidad es un link simbólico a /home/.ecryptfs/leandro). Ese directorio, al iniciar sesión, se monta bajo /home/leandro con ecryptfs como tipo de sistema de archivos. Precisamente por eso no funciona el comando locate. Lo que hay que hacer es simplemente quitar ecryptfs de la variable PRUNEFS y luego ejecutar updatedb.

[admin@MikroTik] > ip proxy set enabled=yes port=8080
[admin@MikroTik] > ip firewall filter add chain=input action=accept protocol=tcp dst-port=8080 src-address=192.168.1.0/24 comment="Proxy para LAN"
[admin@MikroTik] > ip firewall nat add in-interface=LAN dst-port=80 protocol=tcp action=redirect to-ports=8080 chain=dstnat

Finalmente, se deben escribir las reglas para restringir los sitios que se desee. En este caso se permiten todos los sitios con excepción de los que están explícitamente denegados, que son Facebook y Twitter.

[admin@MikroTik] > ip proxy access add dst-host=www.facebook.com action=deny
[admin@MikroTik] > ip proxy access add dst-host=twitter.com action=deny

No obstante, Delicious se ha vendido a la empresa AVOS, perteneciente a los creadores de YouTube, y seguirá funcionando con total normalidad, al menos eso es lo que enuncian desde Yahoo en el aviso que hacen a sus usuarios. Ahora bien, es importante que todos los usuarios de Delicious se logueen a su cuenta y acepten la migración de datos antes de Julio de 2011. El procedimiento es muy simple, y toma sólo los tres pasos que muestro debajo, en las capturas.

En el primer paso nos pide nombre, apellido y confirmar la dirección de correo electrónico.

Luego, el segundo paso pide que se ingrese una contraseña para el usuario de Delicious, dado que ya no se ingresará más con el ID de Yahoo, lógicamente.

Finalmente, una pantalla nos indica que todo fue exitoso e informa precisamente que a partir del momento debe utilizarse el nombre y la contraseña del paso anterior.

Una vez terminado el procedimiento los datos estarán migrados y seguirán disponibles, ahora bajo la administración de la gente de AVOS.

En Apache existe un módulo llamado mod_proxy que es bastante útil para cumplir con varias funciones. Una de ellas es la de que un servidor reciba tráfico web para un sitio que en realidad está hosteado en otro servidor, que será la que explicaré a continuación.

Para el ejemplo, vamos a suponer:

• Sitio web www.mikroways.net.
• Por DNS, la IP que corresponde al dominio www.mikroways.net es la IPA, donde hay un Apache pero no se encuentra el código del sitio de dicho dominio.
• El servidor web para www.mikroways.net tiene la IPB.

El comportamiento básicamente es el siguiente:

1. Un cliente abre una conexión HTTP contra el servidor web en IPA, que según su DNS es el servidor web www.mikroways.net.
2. El servidor Apache en IPA acepta la conexión para ese dominio pero en el virtual host correspondiente tiene configurado el mod_proxy que le indica que en realidad el sitio web está en el servidor con IPB. Entonces, el Apache en IPA actúa como cliente haciendo el requerimiento del sitio web de www.mikroways.net a IPB.
3. El servidor IPB le devuelve el sitio tal como lo hace con cualquier cliente y lo mismo hace el servidor IPA con su cliente.

Notar que el procedimiento anterior es totalmente transparente tanto para el cliente del servidor IPA como para el propio servidor IPB.

Configuración

A continuación se muestra la configuración del servidor IPA. Notar que en la misma, el valor IPB debe ser reemplazado por la IP del servidor donde realmente se encuentra alojado el sitio web.

<VirtualHost *:80>

    ServerName  www.mikroways.net
    ServerAlias mikroways.net
    ServerAdmin invalidaddress@mikroways.net

    ProxyPreserveHost On
    ProxyRequests Off

    <Proxy *>
         Order deny,allow
         Allow from all
    </Proxy>

    ProxyPass               / http://IPB/
    ProxyPassReverse        / http://IPB/

    ErrorLog /var/log/apache2/error.log
    TransferLog /var/log/apache2/access.log

</VirtualHost>

Lógicamente debe habilitarse el mod_proxy en Apache y luego reiniciar el servicio para que los cambios tomen efecto. Lo primero se hace muy simple en Debian con el comando:

a2enmod proxy
a2enmod proxy_http

En mi caso trabajo con Ubuntu por lo que daré la explicación para dicho sistema. Sin embargo, la misma solución debería poder aplicarse a cualquier Linux con variaciones quizá en la ubicación de los archivos o en la ejecución de algún comando.

El primer paso consiste en instalar wine:

aptitude install wine

Luego, descargar la versión 3.0 beta de Picasa para Linux e instalarla. En mi caso:

sudo dpkg -i picasa_3.0-current_amd64.deb

Una vez hecho eso, descargar la versión 3.8 para Windows y ejecutarla con Wine. Probablemente sea necesario darle permisos de ejecución para que wine pueda correr el programa. Cuando se abre el asistente de instalación se deben seguir los pasos habituales y, al llegar al paso final, desmarcar todas las casillas de verificación.

El siguiente paso es copiar los archivos del “nuevo” Picasa al “viejo”. Esto se hace con un simple comando:

cp -a /home/usuario/.wine/drive_c/Archivos de programa/Google/Picasa3/* /opt/google/picasa/3.0/wine/drive_c/Program Files/Google/Picasa3/

Una vez que termina de copiar ya puede utilizarse la última versión de Picasa en Linux.