Guardar la configuración de tu máquina

Antes, cuando cambiaba mi PC, siempre me encontraba con el mismo problema: tener que reconfigurar todas mis aplicaciones. Gracias a GNU/Linux, descubrí que era más sencillo mantener mi home en otra partición, de manera que podía conservar esta configuración.

Ahora, por suerte o por desgracia, no trabajo en una única máquina: tengo un PC y dos portátiles; en el curro tengo mi portátil, una máquina virtual hosted donde suelo trabajar, una máquina virtual unhosted que puedo volver a crear de vez en cuando y… bueno… otras 60 máquinas en las que puedo llegar a necesitar hacer algo.

Gestionar mi configuración individualmente es… un coñazo. Así que me planteé la opción de guardar esta configuración en un repositorio, como Git (ahora entendéis mi post anterior :D). Realmente no me entusiasmaba la idea, pero resulta que mi colega Daniel Fanjul me dijo que él ya lo hacía así.

Vamos a ver cómo podemos gestionarlo de manera sencilla.

Dos aproximaciones

Existen dos variantes distintas a esta solución: La primera es hacer que el home sea un repositorio; la segunda, mantener el repositorio aparte, y crear enlaces a las configuraciones. Veremos que cada aproximación tiene sus ventajas y sus inconvenientes.

El home en Git

Si nuestro home está en Git, tendremos mucha basura que no queremos guardar en nuestro repositorio. Pero eso no es un problema: para eso existe el .gitignore.

Veamos cómo empezar (desde el home, claro):

1
2
3
4
5
6
7
8

~ $ git init
Initialized empty Git repository in /home/magmax/
~ $ ls -A1 |grep -v .gitignore > .gitignore
~ $ git add .gitignore
~ $ git commit -m "initial version of my configuration"
[master (root-commit) 6dfa6ad] initial version of my configuration
 1 file changed, 2 insertions(+)
 create mode 100644 .gitignore

Ahora, cuando queramos conservar una configuración, sólo tendremos que editar el archivo .gitignore para eliminarlo y añadirlo al repositorio. Poco a poco, el archivo .gitignore irá quedando más pequeño y apenas será necesario tocarlo.

Algunas cosas que podéis añadir ya mismo, a modo de ejercicio: .gitconfig, .bashrc, .profile, … Y algunas cosas que nunca saldrán del archivo .gitignore: .bash_history, .xsession-errors, …

Manteniendo enlaces simbólicos

La otra alternativa es crear un repositorio aparte y crear enlaces simbólicos. La estructura del repositorio no tiene por qué ser la misma que la del home, pero resultará más sencillo encontrar lo que buscas si tratas de mantener la misma estructura.

Como ejemplo, vamos a crear el repositorio y a guardar la configuración de mi awesome wm:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

    ~ $ mkdir Config
    ~ $ mkdir Config/config
    ~ $ mv .config/awesome Config/config
    ~ $ ln -s Config/config/awesome .config/awesome
    ~ $ cd Config
    ~/Config $ git init
    Initialized empty Git repository in /home/magmax/Config
    ~/Config $ git add config
    ~/Config $ git commit -m "initial version of my configuration"
    [master (root-commit) 6dfa6ad] initial version of my configuration
     1 file changed, 2 insertions(+)
     create mode 100644 config

Dos cosas aquí:

• La primera es hacer notar que he creado el directorio con la C mayúscula. Así quedará al principio cuando hagamos un “ls” y no estorbará.
• La segunda, que he evitado el punto al comienzo del nombre. Así no estará oculto el directorio.

Ventajas e inconvenientes

Cada manera tiene unas ventajas y unos inconvenientes. Vamos a verlos algunos:

Todo en el repo

Si usamos la primera aproximación, tendremos estos inconvenientes:

• puede crecer mucho y rápido
• puede contener cosas que no queríamos
• hay que estar gestionando el .gitignore con todo lo que no queremos
• si queremos un archivo diferente para distintas máquinas, habrá que utilizar enlaces simbólicos, complicando un poco el despliegue.
• puede dar lugar a fallos de seguridad, si metemos las claves ssl en el repositorio.

Pero también algunas ventajas:

• es dificil que nos olvidemos añadir algo al repo. Cuando preguntemos el estado ("git status"), cantará todo lo nuevo.
• si estamos en un entorno gestionado por otros, detectaremos si nos han cambiado algo.
• también detectaremos si una aplicación ha cambiado algo.
• en una máquina nueva basta descargarse el repositorio para tenerlo todo configurado, aunque esto puede pisar algo que no nos guste… ¡Pero para eso están las ramas de Git! :D

Enlaces simbólicos

Usando la segunda aproximación tenemos ya unos inconvenientes:

• Hay que estar creando enlaces para todos y cada uno de los directorios a guardar.
• en una máquina nueva, hay que volver a crear todos los enlaces.

Pero también ventajas:

• Es sencillo gestionar distinta configuración en distintas máquinas. Basta con cambiar el enlace.
• Seguramente ocupará menos.

Conclusión

Yo he optado por tenerlo todo en el repo y debo decir que es una maravilla. Comencé creándome distintos repositorios en mis máquinas y después fui uniéndolos como si fueran ramas (algo que no podría haber hecho con mercurial, pero sí con Git).

En el trabajo tengo el problema de que no todas las máquinas pueden ver a todas las máquinas, aunque desde mi máquina sí puedo verlas todas. En este caso, Git vuelve a echarme una mano. Tan solo tengo que definirme distintas fuentes remotas y trabajar con push desde mi máquina en lugar de hacer pull desde la remota. Además, tengo un script fabric que me ayuda a gestionarlo todo, pero eso será otra historia…

¿Y vosotros? ¿Ya lo usábais? ¿Tenéis otra propuesta? ¿Cuál vais a probar?