Problemas más comunes al actualizar de Debian Jessie a Stretch

por | septiembre 6, 2017

A la hora de realizar una migración siempre debemos tener presente la Ley de Murphy. En primer lugar, para considerar y preparar determinadas contramedidas en caso de un resultado inesperado o directamente negativo. Si bien en ciertas máquinas -mi ordenador personal sin ir más lejos- la actualización de Debian Jessie a Stretch no me ha dado problemas, en algunos servidores sí. A continuación vamos a realizar un repaso con los problemas más comunes que he encontrado para que sirva de ayuda a aquellos que han tenido también algún contratiempo.

Migración de SysVinit a Systemd – Failed to get properties: No such interface ”

Como ya sabréis Debian Stretch incorpora Systemd y abandona SysVinit. Durante el proceso de migración el gestor de paquetería debería encargarse de desinstalar SysV y las dependencias asociadas e instalar a su vez Systemd con sus dependencias correspondientes. Si al operar con el nuevo sistema con systemctl nos encontramos un error similar al siguiente:

[root@jotaserver1 apache2]# systemctl status apache2.service
Failed to get properties: No such interface ''

Debemos comprobar que tenemos instalado el paquete systemd-sysv. Por ejemplo si buscamos con aptitude:

[root@jotaserver1 apache2]# aptitude search sysv
p   git-daemon-sysvinit                     - fast, scalable, distributed revision control system (git-daemon service) 
p   live-config-sysvinit                    - Live System Configuration Components (sysvinit backend)                 
v   php-sysvmsg                             -                                                                       
v   php-sysvsem                             -                                                                       
v   php-sysvshm                             -                                                                       
v   php7.0-sysvmsg                          -                                                              
v   php7.0-sysvsem                          -                                                                       
v   php7.0-sysvshm                          -                                                                       
p   python-sysv-ipc                         - semaphores, shared memory and message queues - Python 2.x              
p   python3-sysv-ipc                        - semaphores, shared memory and message queues - Python 3.x              
p   runit-sysv                              - system-wide service supervision (sysv integration)               
p   systemd-sysv                            - system and service manager - SysV links                        
i   sysv-rc                                 - System-V-like runlevel change mechanism                   
i   sysv-rc-conf                            - SysV init runlevel configuration tool for the terminal           
p   sysvbanner                              - System-V banner clone                                             
i   sysvinit                                - System-V-like init utilities - transitional package          
i A sysvinit-core                           - System-V-like init utilities                     
i   sysvinit-utils                          - System-V-like utilities     

Vemos claramente que el paquete necesario no está instalado. De hecho, todavía están presentes sysv-rc y sysv-rc-conf correspondientes al sistema SysV. Podemos comprobar también si tenemos systemd-sysv con dpkg:

dpkg -l | grep systemd-sysv

Procedemos a instalarlo:

apt-get install systemd-sysv

Servicios activados por defecto no necesarios

De nuevo tema relacionado con Systemd. La actualización viene con sorpresas ya que se habilitan ciertos servicios que puede no necesitemos y que previamente tuviéramos desactivados con SysV. El principal problema es que el servicio en cuestión habra un socket de red y no tengamos un firewall como iptables para parar las peticiones que lleguen a esos puertos, abriendo un agujero de seguridad en nuestro sistema. Sería conveniente revisar los servicios habilitados con:

systemctl list-unit-files | grep enabled

Una lista de servicios que aparecen habilitados y quizá no necesites o tuvieras desactivados anteriormente en SysV. Me gusta aplicarles mask para que no puedan habilitarse de ninguna manera:

# Llamadas a procedimiento remoto (RPC)
systemctl mask rpcbind.service 
systemctl mask rpcbind.socket 
systemctl mask rpcbind.target

# NTP
systemctl mask ntp.service

# Timesyncd (¿alguien habló de la reinvención de la rueda?)
systemctl mask systemd-timesyncd.service

# Targets NFS y remote-fs
systemctl mask nfs-client.target
systemctl mask remote-fs.target

# Apt timers
systemctl mask apt-daily-upgrade.timer
systemctl mask apt-daily-upgrade.service
systemctl mask apt-daily.timer 
systemctl mask apt-daily.service

Estos servicios pueden variar en vuestro sistema, por lo que comprobad vosotros mismos con systemctl list-unit-files | grep enabled

net.c:581: sendmsg() failed: Operation not permitted

Este problema puede presentarse al realizar una operación de red. Desde un nslookup, host, dig, ping o intento de envío de correo. Se debe a que el sistema intenta utilizar IPv6 por defecto para la operación y tenemos un firewall que corta las comunicaciones de dicho protocolo, aunque después el sistema haga fallback a IPv4 y el resultado de la operación sea satisfactorio. Quedaría en cualquier caso como un warning molesto.

Podemos optar por:

  • Deshabilitar IPv6 a nivel de sistema en /etc/sysctl.conf añadiendo:
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
    net.ipv6.conf.eth0.disable_ipv6 = 1
    

    Y después recargando configuración:

    sysctl -p
    
  • O bien crear las reglas correspondientes en nuestro firewall –ip6tables si es el caso- para permitir determinadas comunicaciones por protocolo IPv6.

systemd-modules-load.service fails

He querido poner el problema anterior que no tiene nada que ver con Systemd para que que no parezca que tengo algo personal contra el nuevo sistema de inicio… Si vuestro kernel ha sido compilado sin soporte para la carga de módulos el servicio systemd-modules-load de systemd fallará:

[root@jotaserver1 rules]# systemctl --failed
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● systemd-modules-load.service loaded failed failed Load Kernel Modules
 
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

Una manera de comprobar si tenemos módulos cargados en nuestro kernel es ejecutar lsmod. Si no vemos ningún módulo en la salida ya es una pista. Si no existe /proc/modules es otra pista más certera. Por ejemplo en un kernel con soporte para módulos veríamos una lista similar a la siguiente con los módulos y su localización en memoria:

[root@jotadebian ~]# cat /proc/modules 
nvidia_uvm 675840 2 - Live 0xffffffffc0f01000 (PO)
vhost_net 20480 3 - Live 0xffffffffc0df0000
vhost 45056 1 vhost_net, Live 0xffffffffc0e70000
macvtap 24576 1 vhost_net, Live 0xffffffffc0e69000
macvlan 24576 1 macvtap, Live 0xffffffffc0e5e000
tun 28672 7 vhost_net, Live 0xffffffffc0d48000
ses 20480 0 - Live 0xffffffffc0e0d000
enclosure 16384 1 ses, Live 0xffffffffc0deb000
scsi_transport_sas 45056 1 ses, Live 0xffffffffc0e38000
uas 24576 1 - Live 0xffffffffc0d53000
usb_storage 73728 3 uas, Live 0xffffffffc0e25000
fuse 98304 9 - Live 0xffffffffc0d2f000
ebtable_filter 16384 0 - Live 0xffffffffc0a7e000
ebtables 36864 1 ebtable_filter, Live 0xffffffffc0d25000
pci_stub 16384 1 - Live 0xffffffffc0b8c000
vboxpci 24576 0 - Live 0xffffffffc0ba4000 (O)
bridge 135168 0 - Live 0xffffffffc0b6a000
...

Si no tenemos soporte para carga de módulos en el kernel, deshabilitamos el servicio:

systemctl mask systemd-modules-load.service

Errores nf_conntrack errors en dmesg

Si vemos errores similares al siguiente en dmesg:

[Sun Aug 27 20:25:24 2017] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based  firewall rule not found. Use the iptables CT target to attach helpers instead.

Seguramente tengas reglas del firewall iptables utilizando la opción -m state -state [ESTADO_CONEXION] para filtrar tráfico en función del estado de conexión. En Stretch la versión de iptables es 1.6.0. Dicha directiva de trazabilidad ha quedado obsoleta y debería ser sustituida por -m conntrack -ctstate [ESTADO_CONEXION]. Por ejemplo, si tenemos:

iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT

Deberíamos modificarla a:

iptables -A OUTPUT -p udp --dport 53 -m conntrack --ctstate NEW -j ACCEPT

Y así con todas las reglas que tengamos definidas del mismo modo.

Hasta aquí llega la lista de problemas más comunes que he encontrado actualizando de Jessie a Stretch. Ha dado algo más de guerra que la actualización de Wheezy a Jessie a nivel de sistema, si bien es cierto que los cambios que incorpora -como el paso de SysVinit a Systemd- no son pocos ni ligeros precisamente.