- Ya tiene algún tiempo pero aún así es inaceptable.
- Un paper del Igadi que en sólo 15 páginas nos cuenta toda la historia del conflicto saharaui. Y para darle un poco más de contexto un mapa de como está dividido el territorio en la actualidad.
- La historia del Cablegate. Muy recomendable, aunque tengo la sensación de que todo esto acabará en nada.
- No es AVE todo lo que reluce.
- Hace un mes más o menos se publico el avance del Quadrennial Development and Diplomacy Review un informe muy influyente en la estrategia a largo plazo de Estados Unidos sobre la ayuda al desarrollo, o en realidad, sobre el triángulo Desarrollo, Diplomacia, Defensa. Fijaos en el mapa, apenas hay zonas consideradas estables, de hecho la mayor parte de Europa (o incluso Corea del Sur) tiene una consideración superior a España. Enlazo está idea con los hilos que se movieron para modificar las leyes de la propiedad intelectual (sic) en el estado español y reflexiono que cada vez me parecen más realistas las files.
Categoría: General
Leído por ahí
Mucha chicha en pocos caracteres
Durante mi estancia de Erasmus en Praga cogí la costumbre de enviar un correo-e a alguna gente contando como me había ido la semana. A la vuelta, ese correo cambió de temática para, convirtiéndose en una forma de compartir enlaces curiosos que encontraba en la red. Desde que entré en Cartolab y abrí cuenta en identi.ca perdí esa costumbre. La semana pasada varias personas me comentaron que ya no escribía esos mails así que probaré a reconvertir esa costumbre a escribir en el blog, una especie de bocados de actualidad o cosas que hacer en sábado cuando no estás muerto.
Así que ahí va la primera edición de mucha chicha en pocos caracteres.
- Siguen saliendo artículos desmintiendo el mito de que Colón y los suyos fueron los primeros europeos en llegar a América. Ahora bien, al igual que con las ideas, lo importante no es quien la tiene (llega) primero si no aquel que la implementa (descubre) de una forma que merece la pena.
- Los mapas son una de esas cosas a las que no prestaba mucha atención hasta mi llegada a Cartolab, por eso sigue fascinándome la capacidad que tienen de alterar tus pensamientos sobre el mundo. Una demostración del verdadero tamaño de África.
- Un estudio serio de si dentro de un par de años nos apellidaremos todos Abad Abad. Para los vagos… la respuesta es no.
- Un artículo de Juan Urrutia tratando de demostrar algo intuible. Aunque seas un experto en un campo , la mayoría de la investigación que realices será para confirmar tus creencias previas y la posibilidad de que lo que aprendas modifique tu pensamiento es reducida. Lo más interesante del artículo son los tres últimos párrafos que tratan de explicar de quien deberíamos fiarnos.
Pues bien, dadas las consecuencias del sesgo confirmatorio que he destacado, a nadie le debe parecer extraordinario que, para valores muy altos del sesgo confirmatorio y para señales no muy informativas, lo mejor que puede hacer el soberano es consultar con cuantos más expertos mejor y guiarse por la opinión de la mayoría sin fijarse en el peso relativo de las opiniones según la reputación de los expertos.
Un blog sobre Economía y Desarrollo
Aviso, esto era originalmente un correo-e, que viendo el resultado final decidí convertir en artículo, así que disculpen si presenta cierta incoherencia.
Llevo algún tiempo leyendo un blog cuyo editor principal es William Easterly, economista e importante teórico sobre el desarrollo. Se trata de un pensador heterodoxo, alejado de la corriente mayoritaria que representa Sachs, sus discusiones han sido sonadas [pdf].
Es crítico con la utilidad real de perdonar la deuda externa o los argumentos que se usan para condonarla , y Amartya Sen también ha criticado algunas de sus ideas pero tiene un blog que me encanta. Escribe de forma demasiado regular para poder leerlo todo pero de vez en cuando te encuentras con algunas joyitas o artículos que te obligan a pensar, acompañados generalmente de buenas infografías. Por ejemplo:
- De como el IDH no tiene porque ser el sumun de los índices
- Que es la economía.
- Hacen los dictadores buenos crecer la renta per capita.
- Serie de mapas a distinta escala que muestran como la desigualdad es fractal.
- Un mapa que muestra como se está gastando el dinero que el congreso de estados unidos aprobó para salir de la crisis. Si veis los comentarios hay cosas más concretas sobre cooperación y GIS.
Clickativismo
Gracias a una entrada de Olga en el blog de Masticable llego a un interesante artículo de opinión en The Guardian, Clicktivism is ruining leftist activism.
A pesar de que seguramente el leftist sobraba y tampoco dice nada que no se hubiera visto venir, me gusta que en un periódico generalista traten estos temas.
El tercer sector, no debe desechar el marketing tradicional, porque hay mucho que aprender ahí, pero tampoco debe rebajarse a pensar en la gente como simples números, ni a tener amigos en un libro de caras.
En resumen, los clicks son importantes, ayudan a ofrecer números a los financiadores, o a los que necesitan votos, pero están en la escala más baja en cuanto a calidad del aporte. Es más difícil obtener números en los otros niveles de la pirámide, pero el esfuerzo merece la pena.
Libro: Escuela de Robinsones
Terminé hace un par de días Escuela de Robinsones. Desde luego no esta para mi entre las mejores obras de Julio Verne. Si bien casi todos los libros de Verne que he leído me parecen antiguos este debe ser uno de los que peor ha envejecido. Y cuando digo antiguos, no me refiero a la época en la que fue escrito, por ejemplo cuando leo a Dickens que es contemporaneo a Verne no tengo esa sensación de estar leyendo pasado de moda que si me pasa con Verne
Es cierto que Escuela de Robinsones se vende como una caricatura de Robinson Crusoe, pero aún así, se trata de una historia predecible desde el primer capítulo y personajes absolutanmente planos.
A pesar de la opinión negativa que tengo del libro, creo que puede gustar a chavales que estén en la época de leer a Los Cinco (o Los Hollyster que era lo yo que leía) y es una forma de introducirlos en otro tipo de autores.
Como escoger el permalink en WordPress
Escribí este texto en Mayo de 2009, pero tantas vueltas quería darle para que quedara perfecto, que al final nunca llego a ver la luz. He aprovechado la salida de la nueva versión de WordPress para comprobar si aún tenía vigencia, y a pesar de que parece que se va a solucionar en breve por ahora este post sigue siendo correcto.. Así que sin darle más vueltas ahí va. Un batiburrillo de conocimientos sobre posicionamiento en buscadores (SEO), rendimiento de wordpress y permalinks.
Como optimizar las url para el posicionamiento en buscadores
Lo primero que debes saber sobre optimizar las url para el posicionamiento en buscadores es que no debes obsesionarte con ello. Los criterios que usan los motores de búsqueda (SE, de sus siglas en inglés) son secretos (y seguramente cambiantes), por tanto la mayor parte de la información se basa en especulaciones. El valor que los SE asignan a la url se dice que no es demasiado. De todas formas los criterios que desarrollo aquí no están sólo escritos pensando en el SEO (Optimizar el posicionamiento en buscadores) si no en la comodidad para el lector y el CT (click through, que el usuario haga click en un enlace que aparece en una página de búsqueda o anuncio). Dicho esto, las recomendaciones más generales que se suelen dar son:
- Cuanto más corta sea la url sin que se pierda el sentido mejor. Por ello es buena idea eliminar el www del principio de las url.
- Usa – para separar las palabras, por ejemplo si tu artículo va sobre «Para La caza de ballenas en el ártico» la url debería ser más o menos así http://midominio.com/parar-caza-ballenas-artico y no parar_caza_ballenas_artico.
- Elimina de la url toda información superflua (artículos, posesivos, …) y deja sólo las palabras clave. Por ejemplo la url de un artículo titulado «Descubre las maravillas del gran continente africano» podría ser «descubrir-africa»
- Pon las páginas más importantes en la raíz del dominio y trata de estructurar el resto de una forma lógica. Por ejemplo: midominio.com/ecologia/caza-ballenas-artico y midominio.com/viajes/descubrir-africa y midominio.com/hazte-socio. O si tus artículos son muy basados en fechas midominio.com/2009/04/caza-ballenas-artico
- Ten cuidado a la hora de repetir títulos. Si haces una serie de artículos «Como Bloguear I», «Como Bloguear II», … y las url son demasiado parecidos los buscadores podrían pensar que estas haciendo spam y penalizarte (no estoy seguro de esto). Así que podrias optar por títulos y url del estilo «Escoger un titulo para el post (como bloguear I)» «escoger-titulo-post-bloguear-i», «El cuerpo del artículo (como bloguear II)» «cuerpo-articulo-bloguear-ii».
- Por supuesto no pueden existir dos url exactamente iguales. Por ejemplo en WordPress si una url (permalink) coincide con otra (aunque hayas editado el permalink a mano) -2 es añadido automaticamente. Otros CMS pueden funcionar de otra forma así que ten cuidado.
- Hay quien dice que las url que terminan en / posicionan mejor pero suponen un mayor gasto de ancho de banda. Matt Cutts dice que mejor dejar las extensiones (es decir url que acaben en .htm) aunque no por motivos de posicionamiento. Yo prefiero dejarlas sin la extensión y sin la /
- Si quieres que google news te indexe uno de los requisitos es que existan al menos tres digitos al final de cada url, por ejemplo caza-ballenas-456. Aunque hay que valorar la confusión que puede introducir para el lector el que haya números en la url
Como aplicar estas reglas a WordPress.
Pasar de la teoría a la práctica no siempre es fácil y exige establecer compromisos. Veamos que sucede en wordpres.
En la instalación por defecto de wordpress a los nuevos artículos que escribamos se les asignará una url del tipo midominio.com/?p=123. Pero podemos hacer que esta url, permalink en la jerga de wp, tenga una forma más bonita y acorde a las reglas que ya hemos descrito.
La estructura de los permalinks se cambia a través del menú de «Opciones» del panel de control de wp. En este artículo comentan como se modifican los permalinks y que hacer si ya tenemos artículos escritos con la vieja estructura. Esto es importante, si cambiamos los permalinks en un blog ya en uso, las url de nuestros post cambiarán, de modo que los enlaces a nuestro blog pasarán a apuntar a direcciones inexistentes. Esto es solucionable mediante reglas 301 de redireccionado, pero este tema esta fuera del alcance de este artículo.
En los permalinks de wp generalmente usaremos una estructura a medida. Los códigos más usados son para generar esta estructura son:
- %postname%: Una versión saneada del título del artículo. Si el título es ¿Como cazar ballenas? el permalink será como-cazar-ballenas
- %year%: Los cuatro digitos del año de la fecha de publicación del post.
- %month%: Dos digitos para el mes
- %post_id%: El identificador único de cada post. A cada post se le asigna un número distinto que jamas se repite.
- %categorie%: La categoría que hemos asignado a la entrada. Si le hemos asignado más de una es la que tenga un ID más bajo.
Para cambiar los permalinks tan sólo debemos combinar los códigos que acabo de explicar y darle a actualizar. Esta es la parte fácil, decidir cual es la mejor estructura para nuestro caso algo más complicado.
Hasta ahora la mayoría de artículos escritos sobre los permalinks de wordpress te recomendaban usar la estructura /%categorie%/%postname%/ o bien directamente /%postname%/. Pero una discusión de enero de 2009 en las listas de correos de wordpress muy bien resumida en este artículo advierte de que estas dos estructuras puede dar problemas de rendimiento. Los artículos sobre seo escritos con anterioridad a esa fecha están incompletos porque no tienen en cuenta este factor.
Rendimiento vs Posicionamiento
Este problema de rendimiento lo dividiremos en dos para explicarlo, aunque en el fondo son el mismo:
- Cuando el permalink contiene cadenas de texto (midominio.com/seo/wordpress-permalinks) wordpress tiene que hacer más accesos a la base de datos (querys) y más operaciones que cuando el permalink sólo contiene números (midominio.com/7405). Esto no es muy grave en la mayoría de casos, pero a medida que añadimos plugins, widgets y tenemos más visitas si puede convertirse en un problema. Sobre todo si usamos algún tipo de hosting compartido que limite el uso de cpu, querys por segundo u otro tipo de restricciones. La solución o minimización de este problema está en instalar algún plugin de cache.
- La segunda parte del problema, algo más grave se produce cuando la estructura del permalink comienza por una cadena en lugar de por un número. Es decir una estructura tipo midominio.com/seo/wodpress-permalinks sufriría ambos problemas mientras que una del tipo midominio.com/2009/seo-wordpress-permalinks sólo sufriría el primero. Si además de empezar por una cadena tenemos muchas páginas (no posts) y adjuntos (del orden de miles) el número de reglas que wordpress tiene que almacenar en la base de datos crece exponencialmente y con la forma en la que se hace actualmente además de ralentizar mucho la carga de las páginas e incrementar los querys puede acceder que no podamos acceder a la base de datos de forma manual (operaciones de copia de seguridad, …). Este problema podría solucionarse en futuras versiones de wordpress (en el momento de escribir publicar este post estamos en la versión 3.0).
Dicho todo esto, hay que recalcar que no deberíamos preocuparnos en exceso, porque hasta ahora los reportes de este tipo de problemas han sido muy pocos. Pasemos entonces a ver los pros y contras de las estructuras más típicas.
- /%categorie%/%postname%/. Una de las favoritas si sólo consideramos aspectos SEO y no de rendimiento. Buena estructura porque añadimos keywords a través de la categoría y resulta más ordenado lo que es bueno para las SE y para el usuario. En el punto negativo antes de ponernos a escribir debemos tratar de pensar bien las categorías y no borrar o modificar categorías que ya hayamos usado. En definitiva nosotros mismos debemos ser ordenados y tener las cosas claras. Hay que tener cuidado si editamos el post en no cambiar las categorías porque podriamos cambiar la url. (Sucederá cuando la nueva categoría que añadamos tenga un id inferior a la actual). Si usamos categorías anidadas ambas se incluyen en la url (/blogging/wp/titulo). Esto genera estructura pero aleja a las páginas de la raíz y disminuye el rendimiento. El uso de esta estructura podría llegar a generar graves problemas de rendimiento
- /%postname%/ o /%postname% o /%postname%.html. La otra favorita de los expertos en SEO. Hay quien dice que Google concede más importancia a los archivos que cuelgan de la raíz, pero hay quien dice que tener todo en la raíz es malo porque no da importancia a unas cosas sobre otras y google prefiere el empleo de url más estructuradas. Por otro lado hay quien dice que google concede más importancia cuando las direcciones acaban en /, otros dicen que da más importancia a las páginas estáticas y por tanto conviene usar el .html. Dado que el algoritmo de clasificación es secreto debes optar por lo que crear que resulta menos confuso para los lectores, que en mi opinión es /%postname
- /%year%/%month%/%postname%. Esta es la estructura más usada, pero no la más recomendable. Incluír la fecha añade algo de información contextual a la url. Es la mejor opción, tanto en rendimiento como en SEO, si tu página está muy basada en eventos temporales, o públicas a menudo. El problema está, en que si escribes artículos genéricos, que es lo más habitual, puede dar la impresión de quedar desfasados cuando pasa cierto tiempo. Si escribimos mucho es buena idea para aportar información extra al lector. Lo malo es que se suelen crear muchos subdirectorios lo que no gusta a las SE. Aunque se podría usar algo tipo /%year%/%postname%/ solamente. Añade información a los lectores, que de un vistazo ven la época en que se escribió el post. Téngase en cuenta que esto es bueno para los lectores pero malo para el blog, porque muchos no entrarán si ven que la fecha es antigua. Empezar la url con números es lo más eficiente en cuanto a escalabilidad y tiempo de carga de la página.
- /%postid%/posname%. Mismas consideraciones que la anterior respecto a rendimiento y SEO. Si escribes poco o artículos muy genéricos posiblemente sea mejor esta.
En resumen,
- Cuando creas un nuevo blog lo primero que tienes que hacer es ir a Opciones->Permalinks y modificar la estructura por defecto.
- Si tu blog es muy basado en eventos temporales en la casilla de «custom» escribe /%year%/%month%/%postname%
- Si tu blog va a tener mucho tráfico o muchas páginas (del orden de miles) en la casilla «custom» escribe: /%postid%/%postname%
- En caso contrario (este es el caso más habitual) escribe /%postname%
Por que este blog usa otra estructura
Este blog incumple las conclusiones anteriores y usa la estructura /%postname%/%postid% esto es por dos motivos:
- Incluír números como el último punto de la url no limita demasiado el CT, la gente lee el dominio y a continuación las keywords, cuando llega a los números simplemente deja de leer, con lo que no hay una ruptura visual a la hora de asociar las keywords al dominio y se refuerza el branding.
- El segundo motivo es la creencia de que en un futuro cercano salga algún plugin para wordpress que interprete los permalinks de otra forma. Si en lugar de empezar a leer la url por la derecha, se empezara por la izquierda esta estructura sería de las más eficientes en cuanto a rendimiento.
Copia de seguridad de un blog en WordPress
Resulta conveniente realizar con regularidad una copia de seguridad de la información que tengamos en nuestro blog. Este backup deberíamos hacerlo como mínimo antes de una actualización importante del blog, por ejemplo antes de migrar de WordPress 2.x a la versión 3.
Hacer un backup de wordpress consiste en dos cosas:
- Copiar los ficheros (imágenes, temas, …)
- Copiar los artículos y configuraciones (la base de datos)
Existen algunos plugins que pueden ayudarnos en estas tareas, pero si no tienes tirria a la línea de comandos en este artículo se describe un método rápido y eficiente para hacer la copia. El único requisito es que nuestro proveedor de hosting nos proporcione acceso por ssh, que es lo más habitual. Para ahorrarnos meter la clave ssh cada vez que hagamos la copia podemos subirla al servidor en este artículo se explica como crearla y subirla pero en resumen consiste en ejecutar estos dos comandos (o sólo el segundo si ya tenemos una clave creada)
ssh-keygen -b 4096 -t rsa
ssh-copy-id usuario@servidor
El primer paso será hacer un volcado de la base de datos a un fichero en el servidor:
ssh usuario@servidor "mysqldump --opt --user=USUARIO_BD -p --host=URL_BD NOMBRE_BD > /ruta/fichero_a_guardar"
Por ejemplo
ssh fpuga@dreamhost.com "mysqldump --opt --user=fpuga_bd -p --host=localhost conocimientoabierto_bd_wordpress > conocimientoabierto/base_datos.sql"
La opción -p significa que nos preguntará cual es la clave de la base de datos por consola. Podemos indicarla directamente haciendo –pasword=CLAVE. Esto puede ser útil si metemos estas sentencias en un script pero deberiamos tener el script a buen recaudo para que no puedan ver nuestra clave.
El fichero sql donde se volcará la base de datos podríamos comprimirlo, pero con la estrategia que vamos a usar es mejor dejarlo en texto plano. El proceso de comprimir tiene un consumo elevado de cpu (algunos hosting limitan la cpu que se consume) y en el siguiente paso nos bajaremos el fichero por rsync.
rsync lo que hace es buscar las diferencias entre lo que tengamos en el servidor y lo que tengamos en nuestro disco duro, y sólo se baja lo que varíe. Si hubiéramos comprimido en el paso anterior la base de datos tendría que bajarse el fichero entero pero al estar en formato texto se bajará sólo la diferencia lo que resulta óptimo tanto en gasto de cpu como en ancho de banda consumida. La copia de los ficheros del servidor a nuestro disco duro, consistirá entonces en ejecutar:
rsync -av --delete usuario@servidor:ruta_remota $RUTA_LOCAL
por ejemplo:
rsync -av --delete fpuga@dreamhost.com:conocimientoabierto/ /home/fpuga/backup/conocimientoabierto
La opción delete hace que se borren los archivos locales que ya han sido borrados del servidor remoto. Puede ser peligrosa así que cuidado. La ruta local donde se copien los archivos debe existir previamente. Fijaos en que cuando se pone la ruta remota después de los dos puntos no se inicia con / porque sólo queremos indicar una ruta relativa.
Por último borraremos del servidor el fichero de volcado de la base de datos
ssh usuario@servidor "rm /ruta/fichero_a_guardar"
Y para no teclear tanto podemos crearnos un script muy sencillito. Llega con que cambies los valores de las variables por los de tu servidor.
Antes de escribir el script estuve leyendo sobre algunos plugins pero ninguno se adaptaba a mis necesidades, de todas formas estas referencias puede venirte bien si prefieres usar otro sistema:
- Choosing a WordPress backup plugin that is right for you.
- Backing Up Your Database.
- IDrive for WordPress.
- Plugin Updraft.
- Plugin myEASYbackup.
- Plugin BackWPup.
Primeros pasos para configurar git
Git es el sistema de control de versiones (SCV) que se está imponiendo en el mundo del software libre. Todo programador que se precie debe aprender a usar un SCV y dado que git puede operar también sobre repositorios svn te recomiendo encarecidamente que lo pruebes. Una de las ventajas de git es que es increíblemente configurable. En este artículo encontraras como realizar esa primera configuración para que sea más cómodo trabajar con git.
La configuración global de git se guarda en el home del usuario en archivo llamado .gitconfig. Además dentro de cada repositorio existe un archivo config dentro del directorio .git donde podemos usar unas configuraciones distintas a las globales o añadir parámetros nuevos. La configuración que deseemos la podemos escribir directamente en esos archivos o usar el comando git config.
Indicamos a git quien somos
git config --global user.name "Francisco Puga"
git config --global user.email "fran.puga@gmail.com"
Esto generará en el fichero .gitconfig dos nuevas líneas como las que siguen:
[user]
email = fran.puga@gmail.com
name = Francisco Puga
Si quisiéramos configurar nuestro correo electrónico para un repositorio concreto ejecutaríamos git config sin la opción de –global dentro del directorio que contiene el repositorio.
Colorear la salida
A continuación añadiremos unas líneas al fichero de configuración global (o mediante ordenes como git config –global color.ui auto) para que nos coloree la salida por pantalla
[color]
ui = auto
diff = auto
status = auto
branch = auto
Con añadir esas líneas empezaríamos a usar los colores por defecto pero estos son personalizables como se puede ver en estos enlaces.
Si tras activar los colores ves algo de basura en la salida añade a ~.bashrc la línea:
LESS=-R
Ignorar ciertos ficheros
Cuando trabajamos en un proyecto puede haber ciertos directorios, ficheros resultantes de la compilación, … que queremos que git no indexe y no nos aparezcan al hacer un estatus. Para ignorar ciertos ficheros tenemos varios métodos:
Si lo que queremos es una configuración global para todos nuestros repositorios añadiremos en el .gitconfig la directiva excludesfile con la ruta completa a un archivo de texto donde definiremos las rutas a ignorar. Por ejemplo en mi caso:
[core]
excludesfile = "/home/fpuga/.gitignore"
Y el contenido de ~.gitignore es
*.[oa]
*.lo
*.la
*.gmo
semantic.cache
*~
*.pyc
Si lo que queremos es definir un patrón de exclusión para un repositorio concreto lo haremos en el fichero .git/info/exclude.
La tercera opción es crear un fichero .gitignore dentro algún directorio de nuestro repositorios. Este fichero debería usarse no para las configuraciones personales si no para las de todo el grupo de trabajo. Es decir .gitignore es un fichero que podría subirse al repositorio de modo que todo el equipo de desarrollo comparta esa configuración. La particularidad de .gitignore es que no tiene que colocarse en la raíz del repositorio si no que puede colocarse en algún subdirectorio, así, si en el mismo repositorio tenemos varios proyectos, cada uno en un directorio podemos aplicar configuraciones distintas a cada proyecto.
Para teclear menos
Los comando de git suelen ser nombres bastante largos y en algunos hay que incluir ademas varios parámetros. Para que tengamos que teclear menos git permite configurar alias. La sección alias de mi .gitconfig es la siguiente:
[alias]
unstage = reset HEAD
st = status
rma = ls-files --deleted | xargs git rm
co = checkout
com = checkout master
5.- Programas por defecto que se usan. Se puede configurar el programa que se empleará para editar el mensaje de commit (por ejemplo emacs en lugar de vi) y el paginador que se usa para ver el log (por ejemplo most en lugar de less)
Si bien en el caso del editor es más lógico configurar la variable de entorno global EDITOR=emacs en nuestro .bash_profile, también podemos configurarlo en exlusiva para git con algo como esto
[core]
editor=emacs
pager=moss
Evitar meter las claves
Si a los repositorios git que tenemos se accede mediante ssh, cosa bastante habitual, tendremos que teclear nuestra contraseña cada vez que bajemos o subamos algo al repo. Para evitarlo podemos copiar nuestra clave pública al repositorio remoto. Haciendo esto, cuando queramos trabajar contra el repo, este automáticamente se encargará que nuestra clave privada se corresponde a la clave pública que hemos subido y nos dará acceso.
El proceso es tan sencillo como, crear una nueva clave si todavía no lo hemos hecho:
ssh-keygen -b 4096 -t rsa
Si usamos una passphrase nos la preguntarán sólo la primera vez de la sesión que la clave sea usada. Se trata de una contraseña para permitir al sistema acceder a nuestra clave privada, no tiene nada que ver con el servidor remoto.
Una vez tengamos nuestra clave ssh, debemos copiarla al servidor, para ello existe un comando especial que hace todo por nosotros
ssh-copy-id @servidor
Sincronizar el perfil o los marcadores de Firefox mediante dropbox
Cuando de manera habitual usas más de un ordenador mantener la misma configuración en ambos acaba siendo problemático. Una de las cosas que más echo de menos desde que he dejado de usar mi portátil personal en el trabajo es poder sincronizar los marcadores de Firefox.
En el cielo o en la tierra
Tal y como yo lo veo hay dos clasificaciones en las que se podrían englobar los métodos para la sincronización:
- Usar un servicio web como delicious pensado para trabajar exclusivamente con los marcadores.
- Usar alguna herramienta de sincronización de ficheros como DropBox.
El depender en exclusiva de un servicio web no es una opción que me tiente demasiado, así que no hablaremos de ella. DropBox en cambio, es una mezcla de servicio web y rsync sencillo, donde los ficheros no sólo se guardan en un servidor externo si no también en el nuestro, de modo que podemos abandonarlo cuando queramos a coste casi cero, de hecho, montar un sistema casero que substituya a DropBox no es muy complicado.
Diferentes implementaciones con Dropbox
Decidido que usaremos DropBox tenemos varias formas concretas de implementar el sistema:
- En LiveHacker nos proponen emplear firefox portable, de modo que ejecutemos un firefox desde dentro del propio DropBox. Esto tiene la ventaja de que si un día estamos en un cibercafé podríamos bajarnos nuestra propia versión del navegador desde la interfaz web y luego borrarla. Es una idea a anotar pero no es lo que buscamos.
- El resto de opciones se basan en ubicar el directorio que contiene nuestro perfil de firefox como un directorio compartido en DropBox. Bien sea creando un enlace simbólico con el mismo nombre que nuestro perfil que apunte a DropBox, usando el administrador de perfiles para crear un nuevo perfil en DropBox, o mi favorita, que consiste simplemente en editar el archivo profiles.ini para indicar que debe buscar el perfil por defecto en el directorio compartido.
La última me parece la mejor porque nos ahorramos el crear un nuevo perfil, simplemente movemos su ubicación y usamos herramientas propias de firefox para colocar el directorio del perfil dentro de DropBox en lugar del truquillo de los enlaces simbólicos.
Decidido el método, los pasos previos
En todo caso antes de usar uno de estos tres métodos deberías:
- Hacer una copia de seguridad de tu perfil
- Modificar donde se guarda la cache del navegador. La cache son un montón de archivitos que se guardan mientras navegas para acceder más rápido a páginas ya visitadas, que no tienen ningún interés para la sincronización y que sólo te harán perder ancho de banda y cpu si intentas sincronizarlos. Para cambiar la ubicación, abre firefox y teclea about:config en la barra de direcciones. A continuación busca la clave browser.cache.disk.parent_directory. Si no existe créala como de tipo «cadena». El valor que debe contener es el nuevo directorio que usará como cache, asegúrate de que existe en todos los ordenadores que vayas a usar, yo uso /var/tmp. Cierra el navegador , borra el directorio Cache dentro de tu perfil y vuelve a abrir el navegador. Asegúrate de que en /tmp se ha creado un nuevo directorio Cache.
Mi método casi-preferido
Hecha la preconfiguración podríamos hacer lo que se dice por ejemplo en robzand:
- Copia el directorio que contiene tu perfil a DropBox
- Edita el fichero profile.ini (está en la misma carpeta que tu directorio de perfil). Pon un cero en IsRelative, y en Path pon la ruta completa a tu perfil dentro de DropBox, que seguramente será algo como /home/[tu_usuario]/DropBox/4f45s.default
- Espera a que sincronice, abre el navegador y comprueba que todo funciona correctamente.
- Ve a otro pc y espera a que sincronice. Edita el fichero profile.ini, pon un cero en IsRelative y pon en Path la ruta al perfil que acaba de ser sincronizado. (Ten en cuenta que a no ser que tengas el mismo nombre de usuario en ambos ordenadores la ruta será distinta)
Los incovenientes
Al compartir el perfil también se comparten:
- Las extensiones. Si usas diferentes versiones de firefox puede que alguna de las extensiones te de problemas.
- Las cookies y las claves. Las cookies permiten que las páginas web te recuerden de modo que no tengas que escribir tu contraseña cada vez que entras. Si almacenamos tanto las cookies como las claves en un servicio externo como DropBox y alguien lo crackea, toda nuestra vida en la red será vulnerable.
- Cada vez que abras una página el contenido de tu perfil cambia, con lo que dropbox empezará a sincronizar, y habrá un gasto elevado de cpu y ancho de banda.
Estos problemas nos llevan a reflexionar si la comodidad que tiene el perfil compartido compensa el riesgo o a preguntarnos si realmente necesitamos compartir todo el perfil, o nos llega con los marcadores.
Mi método preferido
Por tanto, si lo único que quieres es compartir los marcadores, que es en general lo mejor desde mi punto de vista, lo único que hay que hacer es:
- Mover el archivo places.sqlite dentro del perfil de tu ordenador principal a DropBox
- Crear un enlace simbólico desde el archivo en DropBox a tu perfil. El comando sería algo así:
ln -s [ruta a places.sqlite dentro de dropbox] $HOME/.mozilla/firefox//places.sqlite
- Esperar a que sincronice y abrir firefox para comprobar que todo es correcto
- En el resto de ordenadores borrar el archivo places.sqlite de dentro del perfil y hacer el enlace simbólico desde el que está en Dropbox.