Un maño entre gaúchos

A los que usáis ubuntu, os habrá pasado que instaláis el sistema con un usuario y una pass y un día decidís cambiar la contraseña de vuestro usuario (lo más normal del mundo). Es cuando intentáis acceder al depósito de claves o Gnome Keyring Manager que se os queda cara de WTF porque al meter vuestra contraseña del usuario, le da por no aceptarla. Eso es porque han hecho mal el depósito de claves y utiliza su contraseña a parte. Al acceder por primera vez al mismo, te pide una contraseña que normalmente es la que usas en tu usuario. Lo que ocurre esque el keyring manager guarda esta contraseña en su fichero de configuración de gconf y no comparte la contraseña de sistema del usuario. Así que para acceder, basta con acordarse de la contraseña que se puso en su momento.

Para los que no les da la gana de seguir usando una contraseña antigua para el depósito y quieren cambiarla, lo pueden hacer de la siguiente forma:

• Instalar el seahorse que es principalmente un depósito de claves GPG.

  # apt-get install seahorse

• Abres seahorse y vas a Editar -> Preferencias -> Depósito de claves. Una vez ahí pones la contraseña del depósito que será la que pusiste en un comienzo y luego le pones la nueva contraseña y listo.

Hay otra solución que sirve para no tener que ni siquiera introducir ninguna contraseña para abrir el depósito y que se abra automaticamente al iniciar la sesión. Es fácil y rápido de hacer. Se puede ver aquí.

Buscando como hacer todo esto vi un buen número de animalicos diciendo que para hacer eso había que cargarse el fichero de gconf del gnome-keyring-manager y así la siguiente vez que se fuese abrir pediría una contraseña nueva. Eso es matar moscas a cañonazos, ya que junto con la contraseña esto se carga el depósito en si, y con él todas las claves que hay guardadas. En mi opinión es un método aceptable si lo que ocurre es que no te acuerdas de la contraseña que pusiste en un comienzo para el depósito.

Hace un tiempo me cogí un VPS (Virtual Private Server) de Slicehost.
Había oido hablar de esta empresa por medio de algunos colegas de trabajo, y tenía buenas referencias.

En un principio me pillé el 512 slice y lo he estado usando hasta ahora como servidor de producción del site del centenario del Internacional de Porto Alegre (ya no existe el site).

Hace un par de semanas decidí coger otro slice para usarlo como servidor de desarrollo con control de versiones y entorno de pruebas. En un principio elegí el slice 256. Al cabo de unos días vi que iba a terminar metiendole un poco más de caña y con el de 256 me iba a quedar corto. Así que decidí ampliarlo al de 512.
Estoy gratamente sorprendido con el resultado. A través de la web y con un par de clicks, se realizó automáticamente el cambio. Estando el servidor en caliente (es mejor asumir un downtime por si acaso), y con una barra de progreso en la web, vi como en cuestión de 10 minutos el servidor estaba funcionando perfectamente y con su memoria y disco incrementados hasta los valores del 512. En cuanto al incremento de precio, según las explicaciones de la web, realizan un prorateo de los dias que faltan hasta acabar el ciclo de facturación y te lo cargan, por lo tanto no te cobran nada de más.

Aunque como todo, hay cosas que se pueden mejorar, estoy realmente contento con el servicio ofrecido por esta empresa, tanto por la calidad técnica, precios y facilidad de uso.

Ahora es cuando tengo que aprender de ellos y hacer que los Xen de la empresa estén tan currados y automatizados como los de Slicehost. Dentro de poco…

Posiblemente esto estará documentado en un montón de sitios en internet, pero aun así lo comento. Me he estado volviendo loco un buen rato, porque no conseguia poner en hora algunos de los servidores. Tenía instalado ntp y ntpdate. Lo reinstalaba, intentaba reconfigurarlo, usar servidores de hora distintos, y siempre me decía que tenía un offset de 53 minutos entre los servidores de hora y el servidor en cuestión.

Al lanzar un ntptrace, obtenía algo así:

# ntptrace
localhost: stratum 16, offset 0.000000, synch distance 0.012450

cosa, que no tenía sentido, ya que después de localhost debería de aparecer el trace de los servidores a los que este consulta a su vez.

Estos servidores que me daban problemas eran instancias virtuales de Xen, así que al final se me ha ocurrido la feliz idea de mirar en que estado estaba ntp en el host físico. Como se puede imaginar, ntp no estaba instalado. Lo he instalado, he reiniciado los ntp de las instancias virtuales y TACHAN! la hora se ha sincronizado.

La razón de esto se puede encontrar aquí es la siguiente:

The following services are not needed anymore:
* ntpd
the xenU uses the dom0 time
If you want to run ntp in the domU, try: echo 1 > /proc/sys/xen/independent_wallclock