Archivo mensual: febrero 2012

Problemillas tras un release-upgrade en Ubuntu

Si todo fue bien, lo juro!. Si probé a reiniciar dos veces y todo, doy fe!. Pero nada, que ha surgido un pequeño problemilla (si a que no te rule la tarjeta de red se le puede llamar “pequeño” y “problemilla”, claro).

Vas caminando tan feliz a encender el servidor que no se resiste por WoL y te cagas en todo cuando no te responde al Sancho desde el PC. Te toca enchufarle monitor, teclado y acordarse de toda su familia (la restante, que el más allegado eres tú, claro) para acabar viendo que el terrible secreto de que no responda ni a pings ni a SSH es sencillamente que no hay servicio de red.

La cara de desastre que se te puede quedar cuando lees un mensaje de que ha habido un acceso denegado accediendo al bus es de coña parriba. Todo ello tras un casi eterno “Waiting for network configuration”.

 

Anteindecentes

Pues hete aquí un día, que como tenía que hacérselo a un cliente, me dio por hacerle un release-upgrade al Ubuntu server. Es una máquina vieja (Athlon XP 1.6mhz 750mb de RAM y 200gb e disco duro SATA1), pero que para estos menesteres me viene genial, ya que es algo que hago cada 2 meses y así descargo la tarea de cualquier máquina virtual: actualziar mi colección multimedia (tendré que consultarle al abogado si podríamos llamarlo así 🙂

La verdad es que tardó lo suyo, pero todo salió genial. De hecho lo hice por SSH, remotamente. Tras un par de reinicios y pruebas, vi que todo funcionaba bien…. hasta el otro día…..”todo?? no!…una irreductible aldea gala repleta de Murphies no estaba por la labor”…..

 

Procedimiento del release-upgrade

Me comentaba un colega que los pasos a seguir serían estos:

Network upgrade for Ubuntu servers (Recommended)
Install update-manager-core if it is not already installed:
sudo apt-get install update-manager-core
edit /etc/update-manager/release-upgrades and set Prompt=normal
Launch the upgrade tool:
sudo do-release-upgrade

Follow the on-screen instructions.

En mi caso fue que me conecté un día por SSH y en las informaciones de estado del sistema, me puso:

New release ‘oneiric’ available.
Run ‘do-release-upgrade’ to upgrade to it.

Así que me dije que mejor los experimentos en casa y con gaseosa, en vez de directamente con el servidor del cliente. Tras una hora y cuarenta y cinco minutos en los que él solito hizo el 99% de las cosas, unos puntos a destacar:

  • Nos pidió la pass del root para hacer un sudo y operar
  • Nos abrió un ssh en el puerto 1022 por si hubiera habido un fallo, poder recuperar la sesión
  • Se van a desinstalar 2 paquetes. Se van a instalar 45 paquetes nuevos. Se van a actualizar 390 paquetes. Se descargarán 256mb.
  • Deinstaló una veintena de paquetes obsoletos e informó de unos pocos qu ehan dejado de tener soporte de Canonical.
  • En todo momento fue de lo más atento y educado, pidiéndome permiso para ciertas cosas y sin insultarme al decirle yo cómo proceder.

 

Solución

Pues parece que es un problemilla que surge a veces y el cual es fácil de solucionar:

http://uksysadmin.wordpress.com/2011/10/14/upgrade-to-ubuntu-11-10-problem-waiting-for-network-configuration-then-black-screen-solution/

Hit Ctrl+Alt+F1 at the blank screen to get you to a non-X terminal (tty1)
Login in with your username and password
Change to root with: sudo -i and enter your password
mkdir -p /run /run/lock
rm -rf /var/run /var/lock
ln -s /run /var
ln -s /run/lock /var
reboot
todo ok de nuevo.

Anuncios

Bondage en MySQL: maestro y esclavo

Suena un tanto…..”peculiar”… pero resulta de lo más normal en el mundo de las bases de datos 🙂

 

Existen diversos motivos por los cuales podríamos querer tener replicación entre servidores de bases de datos:

  • alta disponibilidad (HA),
  • tolerancia a fallos (Failover),
  • copia de seguridad (backup)
  • u otras cuestiones (Otherquestionssoigan).

 

En el caso de esas otras cuestiones, la particularidad que nos ha traido hasta aquí es tener dos redes locales, con conexión a internet (sin VPN siquiera), donde existe un MySQL en cada una de ellas. En vez de grabar datos de múltiples sensores de una red en el MySQL remoto de la otra red, se haría en uno en local. Al establecer una configuración maestro-esclavo para esa base de datos, nos ahorraremos programar incómodos procedimientos de contingencia relativos a la disponibilidad de la línea internet y de los servicios. El propio sistema de replicación ya se encarga de todo eso mucho mejor de como lo haríamos nosotros.

 

Fuentes: