Tengo un disco duro formateado en HFS+ que me permite compartir archivos entre Linux y Mac OS X, ya que es el único sistema de ficheros que no me da dolores de cabeza en ninguno de los sistemas operativos. Tras unos meses de uso me topé con un directorio que no podría modificar desde Mac OS X de ningún modo, ni siendo administrador. Con estos casos, siempre recurro a la línea de comandos, pero ni aún así podía cambiar nada y obteniendo siempre el mensaje Operation not permitted al usar chown o chmod.

Tras intentar arreglar el problema sin éxito con chflags nouchg y chflags noschg tocó investigar un poco hasta dar con la respuesta: los flags de Mac OS X, que se pueden obtener con ls -lO:

tyrell:Shared david$ ls -lO
total 0
drwxr-xr-x   7 david  staff  -                        238 23 feb 09:19 Backup
drwxrwxrwx  13 david  staff  uappnd,opaque,compressed 442 13 mar 14:39 Common
drwx------@ 13 david  1000   -                        442 29 ene 09:20 Dropbox

El problema en mi caso es el flag opaque, que puede eliminarse del siguiente modo (al igual que el resto de atributos):

sudo chflags -R nouappnd,noopaque,nocompressed Common

Con estos comandos por fin pude modificar los archivos y eliminar los archivos de la papelera que siempre me indicaba que estaban bloqueados.

Además de poder utilizar PECL es posible compilar e instalar cualquier extensión de PHP en Mac OS X. Resulta útil si es necesario que los parámetros de ./configure sean diferentes de los que se usan por defecto o si se necesita instalar una extensión que no tenga Mac de serie.

Los únicos requisitos son disponer de Xcode y descargar la versión exacta que esté instalada en Mac (la 5.3.6 en Lion). Luego, el proceso es sencillo (tomaré como ejemplo la extensión pdo_odbc):

wget http://es2.php.net/get/php-5.3.6.tar.gz/from/es.php.net/mirror
tar xzvf php-5.3.6.tar.gz && cd php-5.3.6/ext/pdo_odbc
phpize
./configure --with-pdo-odbc=iODBC
make
sudo cp modules/pdo_odbc.so /usr/lib/php/extensions/no-debug-non-zts-20060613/

Luego basta añadir la correspondiente línea al php.ini y reiniciar el servidor web

Siguiendo con mi serie de anotaciones sobre el desarrollo con PHP en Mac OS X, hoy toca hablar de algo que es más sencillo de lo que parece a primera vista: conectar PHP con SQL Server (virtualizado en una máquina Windows Server 2003 en mi caso) utilizando iODBC en Mac OS X Lion.

Con la versión de PHP que trae Lion de serie viene incluído el soporte para iODBC (una implementación de código abierto de ODBC y alternativa a unixODBC), al que le basta un controlador compatible para acceder a cualquier servidor de bases de datos. En este caso se recurre a FreeTDS, la implementeación de código abierto del controlador para SQL Server.

Como para muchas otras aplicaciones que se necesitan compilar en Mac OS X, he recurrido a Homebrew, que tras instalarlo sólo hay que ejecutar lo siguiente:

brew install freetds

La configuración también resulta sencilla: el archivo /usr/local/etc/freetds.conf debe contener lo siguiente al final:

[sqlserver]
	host = ip_o_host_del_servidor
	port = 1433
	tds version = 7.1

Luego, hay que crear el archivo /etc/odbcinst.ini con el siguiente contenido:

[FreeTDS]
Description = FreeTDS
Driver = /usr/local/lib/libtdsodbc.so
Setup = /usr/local/lib/libtdsodbc.so
UsageCount = 1

Por último, debe definirse el DSN creando el archivo /etc/odbc.ini:

[ejemplo]
Driver = FreeTDS
Database = ejemplo
Description = Base de datos de ejemplo
ServerName = sqlserver

Tras estos pasos, PHP debería poder conectarse al servidor SQL Server sin ningún problema. Pueden usarse las funciones ODBC de PHP para realizar la conexión:

$db = odbc_connect('ejemplo', 'usuario', 'contraseña');
$result = odbc_exec($db, "SELECT campo1, campo2 FROM tabla");
while($row = odbc_fetch_object($result)) var_dump($row);
odbc_close($db);

Si existe cualquier problema con la conexión, puede instalarse unixODBC con Homebrew (brew install unixodbc) y testear la conexión y obtener mensajes de error con el siguiente comando:

tsql -S ip_o_host_del_servidor -U sa

Por último es importante no añadir espacios o tabulaciones en los archivos .ini o iODBC no podrá obtener correctamente los valores causando un error en la conexión.

Tras instalar Mac OS X Lion de cero, instalar Xcode y crear los Provisioning Profiles para desarrollo, me encontré con el error Valid signing identity not found que provoca que no se pueda testear en el dispositivo ningún software. Al abrir el Organizer de Xcode pude ver también el error Xcode could not find a valid private-key/certificate pair for this profile in your keychain. Como creí haber instalado todo lo necesario en base a la documentación que tenía de cuando lo hice por primera vez hace más de un año, me puse a buscar para no perder demasiado tiempo…

No tardé en encontrarme la solucion en stackoverflow indicando que es necesario exportar las claves privadas de los certificados de desarrollo desde el equipo/sistema anterior e importarlos en el nuevo:

• Abrir Acceso a llaveros
• Marcar Inicio de sesión arriba y Certificados abajo
• Exportar las claves privadas de los certificados iPhone Distribution y iPhone Developer
• Importar los archivos .p12 en el nuevo equipo

Completados estos pasos, desaparece el error se pueden volver a probar las aplicaciones en los dispositivos

Uso Debian en su versión estable desde hace tiempo con un /etc/fstab tradicional, añadiendo los puntos de montaje con los nombres de las particiones tipo /dev/sda1. Al actualizar el núcleo esta mañana (a través de backports) se mostró un aviso recomendando actualizar el archivo de configuración para usar el UUID de cada partición. De este modo se consigue que si se añaden nuevos discos duros o se modifica su prioridad en la BIOS los puntos de montaje funcionen adecuadamente y no sea necesario modificarlos.

Los identificadores de las particiones se pueden obtener mediante el comando blkid y en el archivo /etc/fstab la partición de Windows, por ejemplo, quedaría así:

UUID=2058E7A858E77AC4  /media/win  ntfs-3g  rw,user,uid=1000,umask=022  0  0

El problema es que al modificar el archivo Nautilus empezó a mostrar ciertas particiones por duplicado: una montada y otra sin montar. Por lo que pude leer, Nautilus (por lo menos la versión de los repositorios de Squeeze) lee el /etc/fstab y la lista de particiones y si no detecta que está montada la muestra (el problema parece estar en la cadena UUID= que hace que Nautilus considere las particiones como diferentes). Como se puede acceder a las particiones a través de /dev/disk/by-uuid/UUID, puede modificarse la configuración para dejarla así:

/dev/disk/by-uuid/2058E7A858E77AC4  /media/win  ntfs-3g  rw,user,uid=1000,umask=022  0  0

Con este sencillo cambio, se mantiene el uso del UUID de cada partición y Nautilus no las muestra duplicadas

Tras probar hace unos días un Samsung Galaxy S2 con MIUI me decidí a probar la ROM china en mi Nexus One. Teniendo ya instalado el recovery de ClockworkMod resulta muy sencillo instalarlo flasheando el ZIP descargado, así como este paquete de idiomas para traducir la ROM al español (no me gustó la beta de MIUI.es).

El mayor problema que me he encontrado es que me ha sido imposible activar A2SD+ para que las aplicaciones se instalen en una partición de la tarjeta SD en vez de dentro de la memoria del teléfono (cosa que funciona a la perfección en un Samsung Galaxy S), ni realizando el particionado desde el recovery ni usando GParted. Por eso opté por utilizar una única partición FAT32 y activar mediante el shell del Android SDK la instalación por defecto de todas las aplicaciones en la SD. De este modo la mayoría se instalarán automáticamente en la tarjeta de memoria y las que no, podrán moverse desde el administrador de aplicaciones.

La instalación en la SD se habilita con el siguiente comando via ADB (también sirve cualquier emulador de terminal en el teléfono, pero MIUI no trae ninguno de serie):

su
pm setInstallLocation 2

Por último, para mi resulta importante disponer del DSP Manager que CyanogenMod trae de serie pero que MIUI no trae. Para eso, basta descargar el APK desde este hilo de XDA y moverlo a /system/app.

Desde hace unos días, algunas máquinas virtuales (con guests Linux como CentOS y Ubuntu) me han empezado a dar un extraño error:

The I/O cache encountered an error while updating data in medium “ahci-0-0″ (rc=VERR_DEV_IO_ERROR). Make sure there is enough free space on the disk and that the disk is working properly. Operation can be resumed afterwards.

En el log de la máquina se puede ver algo similar:

00:00:15.888 I/O cache: Error while writing entry at offset 13523484672
		(8192 bytes) to medium "ahci-0-0" (rc=VERR_DEV_IO_ERROR)
00:00:15.888 VM: Raising runtime error 'BLKCACHE_IOERR' (fFlags=0x6)
00:00:15.888 Changing the VM state from 'RUNNING' to 'SUSPENDING'.

Tras comprobar la partición en la que se encuentran las máquinas virtuales no está lleno y comprobar que el disco funciona perfectamente pasándole el correspondiente test de smartmontools, me he puesto a investigar y por lo que he podido ver, esto le ocurre a algunos que como yo tienen los archivos de la máquina virtual en una partición de un disco diferente al del sistema (para ganar un poco de rendimiento). En mi caso además está en una partición HFS (para compartirla con Mac OS X) lo que quizás también provoque este problema.

La solución pasa simplemente por habilitar el caché I/O del host. Se puede activar en la configuración de la máquina, en Almacenamiento » Controlador SATA » Usar la cache anfitrión de E/S (el resto de valores son los que VirtualBox usa por defecto). Tras realizar este cambio el error desaparece

gedit es el editor por defecto de Gnome y lo uso bastante para editar todo tipo de archivos a través de FTP/SFTP/SMB, pero la lista de archivos recientes es bastante corta (sólo 5 elementos por defecto) por lo que resulta cómodo aumentar este límite. Puede hacerse con ejecutar el siguiente comando:

gconftool -s /apps/gedit-2/preferences/ui/recents/max_recents -t int 25