Audio AC3 con sonido muy bajo

Muchas veces habréis podido ver que cuando se quiere ver una película cuyo audio está codificado en formato AC3, éste se escucha muy bajo.

Dolby Digital es un estándar de codificación de audio digital y está basado en el algoritmo de compresión AC3 (Audio Coding 3), el cual está formado por un total de seis canales:

• Un altavoz central utilizado para reproducir diálogos y que se suele situar encima de la televisión.
• Dos altavoces centrales (frente derecho e izquierdo) que acentúan el contexto del sonido proveniente del altavoz principal (central).
• Dos altavoces traseros (posterior derecho e izquierdo) que se ocupan de reproducir el ambiente sonoro.
• Un altavoz para sonidos graves que amplifica los efectos especiales.

AC3 codifica los diálogos utilizando unos valores muy bajos (inferiores a -30 dB) y el resto de sonidos a unos 0 dB (umbral de audición). Por lo tanto, este tipo de codificación está ideada para ser reproducida en un equipo apropiado de sonido (por ejemplo un Home Cinema) y no en unos sencillos altavoces de un aparato de televisión.

Este inconveniente se puede corregir a través de las opciones de configuración del reproductor. Para el caso del que utilizo yo, SMPlayer, habrá que ir a Opciones, Preferencias, Avanzado y seleccionar la pestaña de Opciones para el MPlayer. En la caja Filtros de audio aumentaremos por ejemplo a 15 dB el volumen máximo a través de la etiqueta volume=15.

Protección del sistema con iptables

Una vez configuradas todas las características del Sistema de Alta Disponibilidad y Balanceo de Carga que hemos venido desarrollando durante los últimos meses, vamos a ver la forma de proteger correctamente todas las máquinas del cluster a través de la herramienta iptables.

Iptables es una aplicación firewall vinculada al kernel de Linux, que se ocupa entre otras cosas de filtrar (a nivel de enlace y red) aquellos paquetes que llegan al sistema en base a unas determinadas reglas.

Lo que vamos a hacer es crear un script en cada uno de los nodos, iptables.sh, que sea el encargado de establecer las reglas necesarias durante el arranque de la máquina. Este script lo ubicaremos dentro del directorio /etc/init.d/ para que sea automáticamente ejecutado por el demonio init al iniciar el equipo. Para ello, crearemos un enlace dentro del directorio /etc/rc[nivel].d/.

A continuación se muestra el fichero de configuración de iptables para el primer nodo (HA1). Lo primero que hace este script es vaciar las reglas ya existentes de las tablas de filtrado (FILTER) y nat (NAT). Después abre todos los servicios permitidos hacia la máquina: ICMP, SSH, HTTP, MySQL, y FTP. Todos estos servicios estarán disponibles para cualquier usuario que los solicite a través de Internet.

También será necesario abrir aquellos puertos por los que se reciba tráfico a través del resto de nodos del cluster. Por ejemplo, el nodo HA1 recogerá los latidos del nodo HA2 (192.168.1.11) a través del puerto 694 UDP. El nodo HA1 gestionará los demonios de almacenamiento del cluster de MySQL, los cuales enviarán información a través del puerto 1186 TCP proveniente de los dos nodos traseros (10.0.0.12 y 10.0.0.13). Y el mismo procedimiento para los puertos utilizados por Zabbix.

Lo que tiene que quedar claro es que los servicios brindados por el sistema se han dejado abiertos a cualquier dirección IP, y los servicios internos utilizados por los nodos del cluster se han delimitado exclusivamente a las direcciones IP origen correspondientes.

Para que los nodos traseros puedan acceder a Internet, también será necesario habilitar una regla SNAT en los dos nodos frontales que lo habilite.

Una vez establecidas todas las reglas que serán permitidas, pondremos al final del script una regla que loguee en el fichero /var/log/messages todos los accesos no permitidos y una última regla que rechace todas esas conexiones no aceptadas.

root@ha1:~# cat /etc/init.d/iptables.sh
#!/bin/sh

# Borrar todas las reglas de la tabla de filtrado
iptables -F

# Borrar todas las reglas de la tabla nat
iptables -t nat -F

# Reglas permitidas para la cadena de filtrado
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport mysql -j ACCEPT
iptables -A INPUT -p tcp --dport ftp -j ACCEPT
iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# heartbeat
iptables -A INPUT -s 192.168.1.11 -p udp --dport 694 -j ACCEPT

# nbd_mgmd
iptables -A INPUT -s 10.0.0.12 -p tcp --dport 1186 -j ACCEPT
iptables -A INPUT -s 10.0.0.13 -p tcp --dport 1186 -j ACCEPT

# zabbix (agente)
iptables -A INPUT -s 192.168.1.11 -p tcp --dport 10050 -j ACCEPT

# zabbix (servidor)
iptables -A INPUT -s 192.168.1.11 -p tcp --dport 10051 -j ACCEPT
iptables -A INPUT -s 10.0.0.12 -p tcp --dport 10051 -j ACCEPT
iptables -A INPUT -s 10.0.0.13 -p tcp --dport 10051 -j ACCEPT

# Reglas SNAT para la tabla nat
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT --to 192.168.1.10

# Loguear las conexiones bloqueada
iptables -A INPUT -j LOG

# Bloquear el resto de conexiones
iptables -A INPUT -j REJECT

El script de iptables para el segundo nodo frontal, HA2, será similar al del primer nodo. Lo único que cambiará serán algunas direcciones IP origen.

root@ha2:~# cat /etc/init.d/iptables.sh
#!/bin/sh

# Borrar todas las reglas de la tabla de filtrado
iptables -F

# Borrar todas las reglas de la tabla nat
iptables -t nat -F

# Reglas permitidas para la cadena de filtrado
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport mysql -j ACCEPT
iptables -A INPUT -p tcp --dport ftp -j ACCEPT
iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# heartbeat
iptables -A INPUT -s 192.168.1.10 -p udp --dport 694 -j ACCEPT

# nbd_mgmd
iptables -A INPUT -s 10.0.0.12 -p tcp --dport 1186 -j ACCEPT
iptables -A INPUT -s 10.0.0.13 -p tcp --dport 1186 -j ACCEPT

# zabbix (agente)
iptables -A INPUT -s 192.168.1.10 -p tcp --dport 10050 -j ACCEPT

# zabbix (servidor)
iptables -A INPUT -s 192.168.1.10 -p tcp --dport 10051 -j ACCEPT
iptables -A INPUT -s 10.0.0.12 -p tcp --dport 10051 -j ACCEPT
iptables -A INPUT -s 10.0.0.13 -p tcp --dport 10051 -j ACCEPT

# Reglas SNAT para la tabla nat
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j SNAT --to 192.168.1.11

# Loguear las conexiones bloqueada
iptables -A INPUT -j LOG

# Bloquear el resto de conexiones
iptables -A INPUT -j REJECT

A continuación se muestra el script de iptables para el nodo LB1.

root@lb1:~# cat /etc/init.d/iptables.sh
#!/bin/sh

# Borrar todas las reglas de la tabla de filtrado
iptables -F

# Reglas permitidas para la cadena de filtrado
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport mysql -j ACCEPT
iptables -A INPUT -p tcp --dport ftp -j ACCEPT
iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# glusterfs y ndbd
iptables -A INPUT -s 10.0.0.13 -p tcp -j ACCEPT

# zabbix (agente)
iptables -A INPUT -s 192.168.1.10 -p tcp --dport 10050 -j ACCEPT
iptables -A INPUT -s 192.168.1.11 -p tcp --dport 10050 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j DROP

# Loguear las conexiones bloqueada
iptables -A INPUT -j LOG

# Bloquear el resto de conexiones
iptables -A INPUT -j REJECT

Y por último, el del nodo LB2:

root@lb2:~# cat /etc/init.d/iptables.sh
#!/bin/sh

# Borrar todas las reglas de la tabla de filtrado
iptables -F

# Reglas permitidas para la cadena de filtrado
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport mysql -j ACCEPT
iptables -A INPUT -p tcp --dport ftp -j ACCEPT
iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT

# glusterfs y ndbd
iptables -A INPUT -s 10.0.0.12 -p tcp -j ACCEPT

# zabbix (agente)
iptables -A INPUT -s 192.168.1.10 -p tcp --dport 10050 -j ACCEPT
iptables -A INPUT -s 192.168.1.11 -p tcp --dport 10050 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j DROP

# Loguear las conexiones bloqueada
iptables -A INPUT -j LOG

# Bloquear el resto de conexiones
iptables -A INPUT -j REJECT

Para que los scripts se puedan lanzar durante el proceso de arranque, y a su vez, puedan ser iniciados y detenidos automáticamente, hay que ejecutar las siguientes órdenes.

root@ha1:~# chmod +x /etc/init.d/iptables.sh ; update-rc.d iptables.sh defaults
root@ha2:~# chmod +x /etc/init.d/iptables.sh ; update-rc.d iptables.sh defaults
root@lb1:~# chmod +x /etc/init.d/iptables.sh ; update-rc.d iptables.sh defaults
root@lb2:~# chmod +x /etc/init.d/iptables.sh ; update-rc.d iptables.sh defaults

Monitorización de servicios con Zabbix (II)

Una vez instalado Zabbix en los cuatro nodos del cluster, vamos a ver cómo realizar una configuración mínima del servidor de Zabbix para obtener y visualizar datos de las máquinas en donde se ha instalado el agente.

Lo primero que tendremos que hacer será entrar a la consola web de administración empleando para ello nuestras credenciales de acceso. A continuación iremos a la pestaña de Configuration, Hosts, y en la lista desplegable seleccionaremos Host groups y pulsaremos seguidamente sobre el botón Create Group. Crearemos un nuevo grupo denominado Cluster.


Después volveremos nuevamente a la lista desplegable y seleccionaremos la opción Hosts. Pulsaremos sobre el botón Create Host. A través de este control registraremos cada uno de los nodos del sistema y se los asignaremos al grupo Cluster.

En la siguiente imagen podemos ver todas las máquinas una vez configuradas dentro del grupo Cluster.


Es importante señalar que la plantilla que se utilizará para cada nodo será la Template_Linux. En una plantilla se especifican el conjunto de parámetros a ser monitorizados y es una herramienta totalmente configurable.

Para modificar las características de una plantilla hay que ir a la sección Configuration, Items.


Para observar los datos recolectados por el servidor a través de los agentes, tendremos que ir a la pestaña Monitoring, Overview. Esta pantalla nos mostrará una tabla con los parámetros de cada uno de los elementos monitorizados en el grupo.

Si queremos analizar la información de forma gráfica, iremos a la sección de Monitoring, Graphs. y a través de las listas desplegables seleccionaremos el parámetro y la máquina de la cual queremos obtener un determinado gráfico.

Por defecto, la pantalla de las gráficas nos ofrece únicamente cuatro parámetros a representar: CPU Loads, CPU Utilization, Disk usage y Network utilization. Si se quieren añadir más parámetros a la lista desplegable, habrá que ir a la sección Configuration, Graphs, y añadirlos.

En este artículo se ha presentado una breve descripción de lo que Zabbix es capaz de hacer. Realmente es una herramienta muy potente, ya que todos los scripts de monitorización son totalmente modificables. También permite configurar alertas a enviar al administrador, vía SNMP o SMTP por ejemplo. Aparte, permite desarrollar medidas activas (scripts) a tomar en caso de detectar alguna incidencia.

Por último, decir también que podemos modificar el idioma de la consola web. Para ello habría que ir a la sección Administration, Locales, seleccionar nuestro lenguaje en la lista desplegable Take for default locale, y pulsar sobre el botón Next. A continuación veríamos una pantalla que nos ofrecería todas las cadenas de texto traducidas.

Pulsaríamos sobre el botón Download y de esta forma, obtendríamos un fichero denominado new_locale.inc.php, con el cual remplazaríamos el archivo /usr/share/zabbix/include/locales.inc.php.

Monitorización de servicios con Zabbix (I)

En el Sistema de Alta Disponibilidad y Balanceo de Carga que estamos desarrollando, implantamos a través de los artículos anteriores un sistema de monitorización activa, es decir, en cada uno de los nodos del cluster se levantó un demonio que se encargaba de controlar el estado de los servicios configurados, y en caso de detectar algún fallo, ser capaz por si mismo de tomar las medidas oportunas (reiniciar el servicio, reiniciar la máquina, apagarla, etc.).

A parte de este tipo de monitorización, puede llegar a resultar bastante interesante instalar una monitorización pasiva, es decir, una arquitectura que sea capaz de informarnos de otros muchos más parámetros del sistema (aparte de los servicios principales), como por ejemplo el uso de CPU, memoria, espacio en disco, estado de otros procesos, etc.

A través de la monitorización activa se suelen cubrir aquellos puntos críticos del sistema, como por ejemplo que el proceso httpd deje de responder. En este caso, el margen de tiempo de reacción es crucial, ya que si el periodo acontecido (desde que el servicio deja de responder, se percata el administrador y en consecuencia este último toma una medida) es muy alto, las consecuencias pueden ser nefastas.

Por contra, a través de la monitorización pasiva se suelen cubrir otros aspectos que podríamos denominar de "incidencia menor", como por ejemplo que la CPU esté durante bastante tiempo al 90%, que quede menos de un 10% de espacio libre en disco, que exista algún proceso que esté empleando más memoria de lo habitual, etc.

Esta segunda clase de incidencias sí que permiten un margen de maniobra mayor. Cuando por ejemplo quede menos de un 10% de espacio en disco, se le puede enviar una alerta al administrador (SNMP, SMTP, etc.) para que decida cuál es la medida que se debe tomar (por ejemplo añadir un segundo disco duro).

Zabbix está formado por dos componentes principales: el cliente o agente (encargado de recoger los datos en el huésped) y el servidor (se ocupa de recopilar la información que le proporcionan los agentes). A su vez, junto con el servidor se suele instalar un frontend PHP para ofrecer esa información de una manera legible al administrador.

En nuestro Sistema de Alta Disponibilidad y Balanceo de Carga, vamos a instalar en los dos nodos frontales la parte servidora de Zabbix (así como el frontend PHP), y en los cuatro nodos del cluster, el agente.

root@ha1:~# aptitude install zabbix-server-mysql zabbix-frontend-php zabbix-agent

root@ha2:~# aptitude install zabbix-server-mysql zabbix-frontend-php zabbix-agent

root@lb1:~# aptitude install zabbix-agent

root@lb2:~# aptitude install zabbix-agent

Durante la instalación de la parte del servidor de Zabbix, el asistente nos realizará una serie de preguntas:

• El tipo de base de datos que se va a utilizar para zabbix-frontend-php: mysql.
• Contraseña de aplicación MySQL para zabbix-frontend-php: ******
• ¿Desea configurar la base de datos para zabbix-server-mysql con "dbconfig-common"?: Yes
• Contraseña del usuario root de la base de datos de MySQL: ******
• Contraseña de aplicación MySQL para zabbix-server-mysql: ******

Lo primero que tenemos que hacer es definir el nombre de cada uno de los nodos en los ficheros de configuración de los agentes (etiqueta Hostname), así como la dirección IP del servidor de Zabbix al cual deberán enviarle la información (etiqueta Server).

root@ha1:~# cat /etc/zabbix/zabbix_agentd.conf
...
Server=127.0.0.1,192.168.1.11
Hostname=ha1
...

root@ha2:~# cat /etc/zabbix/zabbix_agentd.conf
...
Server=127.0.0.1,192.168.1.10
Hostname=ha2
...

root@lb1:~# cat /etc/zabbix/zabbix_agentd.conf
...
Server=192.168.1.10,192.168.1.11
Hostname=lb1
...
root@lb2:~# cat /etc/zabbix/zabbix_agentd.conf
...
Server=192.168.1.10,192.168.1.11
Hostname=lb2
...

A continuación registraremos el puerto que utilizan el agente y el servidor de Zabbix en el fichero /etc/services (10050, en los cuatro nodos, y 10051 en los dos nodos frontales).

~# cat /etc/services
...
zabbix-agent        10050/tcp                # Servidor de Zabbix
zabbix-server       10051/tcp                # Agente de Zabbix
...

Por último reiniciaremos el agente en los cuatro nodos, y el servidor de Zabbix y Apache en los dos nodos frontales:

root@ha1:~# /etc/init.d/zabbix-agent restart ; /etc/init.d/zabbix-server restart ; /etc/init.d/apache2 restart

root@ha2:~# /etc/init.d/zabbix-agent restart ; /etc/init.d/zabbix-server restart ; /etc/init.d/apache2 restart

root@lb1:~# /etc/init.d/zabbix-agent restart

root@lb2:~# /etc/init.d/zabbix-agent restart

Para acceder al servidor de Zabbix del frontal HA1 pondremos en un navegador web la URL http://192.168.1.11/zabbix/, y para acceder al servidor del frontal HA2, http://192.168.1.12/zabbix/.

Nada más cargar la página web, me encontré con un error PHP: Timezone for PHP is not set. Please set "date.timezone" option in php.ini.

Para solucionarlo, tenemos que editar el parámetro date.timezone dentro de las opciones de configuración de PHP. Además, aprovecharemos para incrementar el valor del parámetro max_execution_time de 30 a 300 (tiempo máximo de ejecución para cada script, en segundos). Esta operación la realizaremos en ambos nodos frontales.

~# cat /etc/php5/apache2/php.ini
...
date.timezone = Europe/Madrid
...
max_execution_time = 300
...

~# /etc/init.d/apache2 restart

Según el manual de Zabbix, para loguearnos en la consola de administración del servidor tenemos que introducir el usuario Admin y la opción de la contraseña dejarla en blanco (deberíamos establecer una en cuanto accediéramos a la consola de administración).

Pues bien, al hacer esto me encontré con el siguiente error: ERROR: Login name or password is incorrect.

Lo primero que hice fue comprobar el log de MySQL para ver si había habido algún problema cuando Zabbix consultó la password del usuario Admin en la base de datos. Todo estaba en orden.

Accediendo a la base de datos de Zabbix en MySQL, pude ver que la contraseña del usuario Admin no se correspondía con la del usuario guest (en teoría y según la documentación, las dos deberían estar en blanco nada más instalar la aplicación).

root@ha1:~# mysql -u root -p
Enter password:

mysql> use zabbix;
Database changed

mysql> select * from users;
+--------+-------+---------+---------------+----------------------------------+-----+-----------+------------+-------+---------+------+-------------+----------------+------------+---------------+
 userid  alias  name     surname        passwd                            url  autologin  autologout  lang   refresh  type  theme        attempt_failed  attempt_ip  attempt_clock
+--------+-------+---------+---------------+----------------------------------+-----+-----------+------------+-------+---------+------+-------------+----------------+------------+---------------+
      1  Admin  Zabbix   Administrator  5fce1b3e34b520afeffb37ce08c7cd66               0         900  en_gb       30     3  default.css               0                          0
      2  guest  Default  User           d41d8cd98f00b204e9800998ecf8427e               0         900  en_gb       30     1  default.css               0                          0
+--------+-------+---------+---------------+----------------------------------+-----+-----------+------------+-------+---------+------+-------------+----------------+------------+---------------+

2 rows in set (0.01 sec)

Así que lo primero que probé fue a poner la cadena (MD5) del password del usuario guest, al usuario Admin. Pero esto no funcionó...

Así que lo que tuve que hacer fue generar una nueva suma MD5 para la password que quería utilizar en la consola de administración web, y actualizar el campo passwd para el usuario Admin (tabla users).

root@ha1:~# echo -n "myzabbixpassword"  md5sum
5c0846506fc325f57006336a9436451a  -

root@ha1:~# mysql -u root -p
Enter password:

mysql> use zabbix;
Database changed

mysql> update users set passwd="5c0846506fc325f57006336a9436451a" where alias='Admin';
Query OK, 1 row affected (0.01 sec)

Rows matched: 1  Changed: 1  Warnings: 0

Esta actualización también la tuve que hacer en el nodo HA2.

Cuando parecía que todos los problemas estaban solucionados, compruebo que en los nodos traseros no está corriendo el agente, y en los nodos frontales ni el agente ni el servidor. Al abrir los logs pude ver los siguientes mensajes: Cannot create PID file [/var/run/zabbix-server/zabbix_server.pid] [No such file or directory] y Cannot create PID file [/var/run/zabbix-agent/zabbix_agentd.pid] [No such file or directory].

~# cat /var/log/zabbix-server/zabbix_server.log
...
/usr/sbin/zabbix_server [2537]: Cannot create PID file [/var/run/zabbix-server/zabbix_server.pid] [No such file or directory]
/usr/sbin/zabbix_server [2537]: ERROR: Cannot create PID file [/var/run/zabbix-server/zabbix_server.pid] [No such file or directory]
...

~# cat /var/log/zabbix-agent/zabbix_agentd.log
...
zabbix_agentd [2532]: Cannot create PID file [/var/run/zabbix-agent/zabbix_agentd.pid] [No such file or directory]
zabbix_agentd [2532]: ERROR: Cannot create PID file [/var/run/zabbix-agent/zabbix_agentd.pid] [No such file or directory]
...

Para solucionar el problema crearemos las estructuras de directorios que faltan dentro de la carpeta /etc/zabbix/, ya que si no con cada arranque Zabbix volverá a borrar el path /var/run/zabbix-*. Además tendremos que establecer los permisos adecuados.

root@ha1:~# mkdir -p /etc/zabbix/var/run/zabbix-server
root@ha1:~# mkdir -p /etc/zabbix/var/run/zabbix-agent
root@ha1:~# chown zabbix:root /etc/zabbix/var/run/zabbix-server
root@ha1:~# chown zabbix:root /etc/zabbix/var/run/zabbix-agent

root@ha2:~# mkdir -p /etc/zabbix/var/run/zabbix-server
root@ha2:~# mkdir -p /etc/zabbix/var/run/zabbix-agent
root@ha2:~# chown zabbix:root /etc/zabbix/var/run/zabbix-server
root@ha2:~# chown zabbix:root /etc/zabbix/var/run/zabbix-agent

root@lb1:~# mkdir -p /etc/zabbix/var/run/zabbix-agent
root@lb1:~# chown zabbix:root /etc/zabbix/var/run/zabbix-agent

root@lb2:~# mkdir -p /etc/zabbix/var/run/zabbix-agent
root@lb2:~# chown zabbix:root /etc/zabbix/var/run/zabbix-agent

Aparte tendremos que modificar también los ficheros de configuración del cliente y del servidor en cada nodo para incluir la ruta correcta al fichero .pid.

~# cat /etc/zabbix/zabbix_server.conf
...
PidFile=/etc/zabbix/var/run/zabbix-server/zabbix_server.pid
...

~# cat /etc/zabbix/zabbix_agentd.conf
...
PidFile=/etc/zabbix/var/run/zabbix-agent/zabbix_agent.pid
...

Actualizar Ubuntu Server desde la línea de órdenes

Para realizar una actualización de un servidor Ubuntu Server, por ejemplo de la versión 8.10 a la 9.04, y si no se dispone de un entorno gráfico como KDE o Gnome, se puede realizar desde la línea de órdenes ejecutando el siguiente comando:

~# do-release-upgrade

Si intentamos lanzar dicha orden a través de una sesión SSH, el comando nos informará que no es recomendable realizar una actualización del sistema sobre SSH, ya que en caso de fallo sería más difícil de recuperar.

Para poder emplear el comando do-release-update tendremos que tener instalado previamente el paquete update-manager-core.