Visto el éxito de mi anterior post sobre el DNIe en Mac OS, llevo un tiempo intentando hacerlo funcionar nuevamente en Lion para poder actualizarlo.

Pues bien, hoy me he puesto desde cero a hacer pruebas y… no podría haber tenido más suerte. Ha funcionado a la primera (bueno, o casi).

He utilizado de nuevo el modelo de lector que en su día daban durante la campaña del DNIe: el SCR3310 v2.0 de SCM.

Tal y como comentaba en el otro post, lo primero que he hecho ha sido una limpieza total de versiones anteriores, de otras pruebas que había realizado hace un tiempo. También eliminé el módulo de Firefox que todavía estaba por ahí y aproveché para actualizarlo a la versión 11.

En este caso, las distintas versiones de cada cosa que he utilizado han sido:

• La versión 1.4.8.1 del driver para el DNIe (dmg), que se puede descargar desde el portal oficial del DNIe.
• La versión (pre-release realmente) 0.3 del driver SCA (dmg), que podéis descargar desde la página del proyecto OpenSC.
• Y por supuesto seguimos necesitando el certificado raíz del DNIe.

Y el procedimiento es el mismo de siempre. Instalamos el driver SCA y posteriormente el del DNIe.

Lo mismo sucede con los pasos comentados para Firefox. Tendremos que añadir un nuevo dispositivo de seguridad con la ruta al ya famoso fichero

/Library/OpenSC/lib/opensc-pkcs11.so

Únicamente, y como bien comentaba ya mucha gente en el anterior post, sigue habiendo problemas con los 64 bits, y de hecho, ejecutando el Firefox en modo 64 bits el intentar acceder a los certificados del DNIe hará que se os cuelgue el navegador.

Por lo tanto, buscamos nuestro Firefox en la carpeta de Aplicaciones y sacamos la ventana de información (botón derecho > Obtener información o ⌘+i). Ahí es donde especificaremos que queremos que se ejecute en modo 32 bits, evitando así los problemas que comentaba antes.

Y ya estaría. No he podido probarlo completamente porque tengo los certificados de mi DNIe caducados (glups!), pero soy capaz precisamente de eso, de acceder a ellos, ver la fecha de caducidad, etc.

Como siempre, los comentarios están abiertos para todo aquello que queráis aportar

Gracias!

A raíz de instalar Namely (un sencillo lanzador de aplicaciones), he decidido buscar la forma de solucionar algo que, si bien no es un problema, siempre me había resultado un poco incómodo.

Muchas veces tenemos aplicaciones en ejecución que realmente no necesitamos tener en el dock, incluso muchas que establecemos como que se arranquen al iniciar sesión (mi caso con Namely, por ejemplo) que poseen un atajo de teclado y que no harán otra cosa más que molestar y ocupar espacio en nuestro dock.

Pues bien, hay una solución para esto, y la verdad, bastante sencilla

A través de la terminal, localizamos el archivo Info.plist dentro de la aplicación que queremos “ocultar”, que estará dentro de la carpeta de la aplicación en “Contents”. Para que siempre funcione (habrá aplicaciones de las que seamos “dueños” y otras que serán del root), he puesto la edición del archivo como superusuario.

whitey:~ borja$ cd /Applications/Namely.app/Contents/
whitey:Contents borja$ sudo vi Info.plist

Y aquí, dentro de la etiqueta <dict>, junto con el resto de pares clave-valor, únicamente tendremos que incluir una que diga:

<key>NSUIElement</key>
<true/>

Ya está. Guardamos el Info.plist, reiniciamos la aplicación, y ya no tendremos el molesto icono en nuestro dock.

Todo esto tiene sus efectos colaterales, y es que Mac OS gestiona varios aspectos a través del dock. Así, por ejemplo, tampoco podremos acceder a la aplicación utilizando ⌘+Tab, y por eso resulta imprescindible que si hacemos esto, o bien tengamos algún atajo de teclado, o bien no sea necesario acceder directamente a la aplicación.

Siendo desarrollador y utilizando varios equipos, se hace prácticamente imprescindible montar algún sistema de control de versiones a nivel doméstico para poder trabajar con comodidad estés donde estés y con la seguridad de estar utilizando la última copia de trabajo.

Aunque existen más alternativas (últimamente se está poniendo bastante de moda Bazaar), quizá una de las más extendidas sea Subversion (SVN). En este caso es por la que he optado, principalmente porque estoy acostumbrado a utilizarlo y porque con Mac OS X ya vienen incluidos tanto el servidor como el cliente de SVN.

Inicialmente utilizaba el modo ‘daemon’ del servidor SVN, que se arranca simplemente con:

$ svnserve -d -r <directorio-raíz-de-los-repositorios>

De esta forma el servidor queda arrancado como un demonio sirviendo los repositorios que tengamos en la ruta que hemos especificado. Inicialmente fue la opción que utilizaba, creando incluso un StartupItem para que el servidor se iniciase cada vez que se arrancase el equipo.

Utilizando el servidor en este modo, podríamos acceder a un repositorio a través de:

$ svn co svn://<host>/<nombre-repositorio>

Para toda la gestión de permisos, existen una serie de ficheros en los que podemos configurar la autenticación, desde usar un fichero de pares usuario/contraseña hasta utilizar SASL. No profundizaré por aquí, puesto que este post va dedicado en parte a evitar todo eso.

Para evitar toda esa configuración en los repositorios de manera individual a través de ficheros y demás (y un poco también porque de esta otra forma es como está montado en el trabajo, jeje), he optado por cambiar de protocolo y utilizar también en casa Subversion a través de svn+ssh aprovechando que ya tengo el ssh perfectamente configurado para ir saltando de un equipo a otro.

Lo cierto es que con svn+ssh lo que realmente sucede es que se establece una conexión mediante SSH y después se arranca una instancia, por decirlo de alguna manera, ‘dedicada’ del svnserve para atender la petición en cuestión. De esta manera, un usuario que se autentique en el equipo por SSH (y que tenga permiso en las carpetas correspondientes), podrá acceder a los repositorios.

Hay una leve diferencia respecto a la utilización de svn+ssh:// frente a svn:// y es que, mientras que svn:// es gestionado por el servidor SVN, svn+ssh:// es gestionado, como ya he dicho antes, a través de una conexión SSH. Por lo tanto, mientras que antes hacíamos:

$ svn co svn://<host>/<nombre-repositorio>

Utilizando svn+ssh tendremos que hacer:

$ svn co svn://<host>/<ruta-absoluta-al-repositorio>

Estamos accediendo mediante SSH y lo que antes especificábamos con la opción -r de svnserve en este caso no está presente y es necesario especificar la ruta completa.

Por motivos de comodidad pero sobre todo de seguridad, no es conveniente que en las URIs de los repositorios aparezca la ruta completa. Para solucionar esto y, además, hacer que la forma de trabajar con svn+ssh:// sea exactamente igual que con svn:// haremos un pequeño truco.

Puesto que lo que está pasando es que tras la autenticación por SSH se ejecuta svnserve, lo que podemos hacer es modificar el ejecutable de manera que haga lo que nosotros queremos. Y me explico.

Para empezar le cambiamos el nombre al ejecutable de svnserve, que estará en /usr/bin

$ sudo mv /usr/bin/svnserve /usr/bin/svnserve.bin

Y a continuación, creamos un fichero /usr/bin/svnserve con el siguiente contenido, en el que especificaremos el comportamiento:

#!/bin/bash
/usr/bin/svnserve.bin -t -r /ruta/al/directorio/de/repositorios

Sólo nos falta guardar el fichero y darle permisos de ejecución:

$ sudo chmod 755 /usr/bin/svnserve

Con esto lo que conseguimos es que el ‘svnserve’ que se ejecutará con el svn+ssh será ese script que acabamos de escribir y que arranca el svnserve en modo túnel pero además especifica el directorio raíz de repositorios. De esta forma ya podremos hacer:

$ svn co svn+ssh://<host>/<nombre-repositorio>

Quizá uno de los aspectos mejorables de Mac OS, sobre todo si vienes del mundo Linux o trabajas paralelamente en él, sea la forma de gestionar el software instalado.

Fuera del software propio de Apple, hasta ahora sólo te quedaba confiar en que los avisos de nuevas versiones disponibles funcionasen en esas aplicaciones de terceros, pero aún así, era cosa tuya descargar la aplicación y reemplazar la versión antigua. En esos momentos es cuando echas de menos el sistema de repositorios y el apt-get update && apt-get upgrade al que hacía referencia con lo del mundo Linux.

Y digo era porque sí existen alternativas que te permiten automatizar un poco todo este proceso, y sobre todo realizarlo de una forma un poco más cómoda. Hace un tiempo que conozco MacUpdate Desktop, una solución de pago ($20/año), que sin embargo parece funcionar muy bien (te permiten utilizarlo durante 10 días de prueba). Hace todo lo que se espera de él: a partir de las aplicaciones que tienes instaladas y utilizando la enorme base de datos de aplicaciones de MacUpdate, te permite descargar y actualizar las aplicaciones que no tengas al día. En la mayoría de los casos es un proceso automático en el que no hay que intervenir. Sólo cuando la aplicación tiene un instalador propio tendrás que seguir los pasos que marque.

Es lo más próximo a los repositorios que he visto, y aunque el precio es realmente bajo teniendo en cuenta el tiempo y trabajo que te ahorra, recientemente he encontrado navegando un software similar, pero en este caso bajo licencia gratuita: AppFresh.

La idea es exactamente la misma: escaneará las aplicaciones (y plugins, widgets, etc.) que tenemos instaladas y a partir de la información de osx.iusethis.com, nos permitirá mantener actualizado nuestro Mac OS X.

Como bien advierten en su web, se trata todavía de una versión previa, una versión beta, podríamos decir, y por lo tanto habrá que tenerlo en cuenta a la hora de utilizarla.

Por lo que he podido probar hasta ahora, funciona bastante bien. Quizá está menos automatizado el proceso que en MacUpdate Desktop, puesto que cuando no consigue descargar la nueva versión te lleva a la página del software en cuestión y te pide que localices el enlace de descarga. Sin embargo, una vez hecho esto, de nuevo vuelve a ser el software quien se encarga de la instalación.

Quizá deje de ser gratuita una vez que lleguen a la primera versión estable, aunque de momento resulta interesante aprovechar el gran trabajo que están haciendo los desarrolladores. Desde luego quien tenga desactualizado su Mac OS X a partir de ahora, será porque quiere

Página oficial | AppFresh