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.