Virtualbox Guest Additions en Fedora 22

maxresdefault

Estoy probando Fedora 22 en Virtualbox y para instalar las Guest Additions es necesario:

# dnf install kernel-devel kernel-headers dkms gcc gcc-c++

y luego ya se puede correr la utilidad de Virtualbox para compilar los módulos del kernel necesarios para que el Fedora corra con todo el potencial del entorno de virtualización.

Linux networking con Team

Link_Aggregation1

Preparando los temas del curso de RedHat Enterprise Server 7 que dicto, me encuentro con la funcionalidad team o teaming para interfaces Ethernet. Hasta ahora había utilizado bonding que es muy simple de configurar, pero tengo que reconocer que teaming ofrece más potencia de configuración y monitoreo que el anterior bonding.

Este nuevo dispositivo de red «teaming» busca ser más rápido, escalable, simple, configurable en espacio de usuario y reemplazar a bonding utilizando una arquitectura diferente. En si, permite crear una interfaz virtual que agrupa varias interfaces Ethernet reales; el proceso se conoce como «channel bonding«, «Ethernet bonding«, «channel teaming«, «link aggregation«, etc. y el objetivo es aumentar el ancho de banda o la disponibilidad de la conexión.

En team se crea un dispositivo «team«, que es la interfaz virtual que tendrá la IP (v4 y/o v6), a la que se asocian «ports» que son las interfaces reales.  El kernel tiene un mínimo driver para el manejo de paquetes y toda la funcionalidad está dada por un daemon teamd que implementa los runners que manejan los modos en que trabajarán las interfaces (broadcast, roundrobin, activebackup, loadbalance, lacp).

Las principales ventajas de team son:

  • Control a nivel de espacio de usuario
  • Monitoreo de link por interfaz
  • API para administración
  • Backup y upload de configuración mediante JSON

Así que ahora tenemos:

Un dirver del kernel:

filename:       /lib/modules/4.0.4-301.fc22.x86_64/kernel/drivers/net/team/team.ko.xz
alias:          rtnl-link-team
description:    Ethernet team device driver
author:         Jiri Pirko <jpirko@redhat.com>
license:        GPL v2
depends:
intree:         Y
vermagic:       4.0.4-301.fc22.x86_64 SMP mod_unload
signer:         Fedora kernel signing key
sig_key:        6A:00:6A:CA:14:AF:B6:50:69:E2:C0:94:CB:35:EA:80:6E:85:C2:4B
sig_hashalgo:   sha256

Un daemon:

teamd — team network device control daemon

Una librería:

Description : This package contains a library which is a user-space
: counterpart for team network driver. It provides an API
: to control team network devices.

Una herramienta de control de teamd:

teamdctl — team daemon control tool

Una herramienta de control de las interfaces:

teamnl — team network device Netlink interface tool

El equipo de Redhat ha trabajado mucho para dejar funcionando team con NetworkManager, aunque algunas funcionalidades avanzadas (por ej. Bridge sobre el Team) todavía requieren de los comandos y los ‘viejos’ archivos.

Sugiero leer el artículo «If You Like Bonding, You Will Love Teaming» por el autor del driver Jiri Pirko y Rashid Khan; y para un completo estudio del tema el manual de Redhat Enterprise Linux 7.

Reiniciar servidor Linux

reboot175x175En un servidor o computadora que corra Linux la mayoría de los cambios quedan activos sin necesidad de reinicio; pero hay algunas oportunidades donde es obligatorio volver a iniciar el equipo.  En este artículo trato de listar cuáles son esos momentos de reinicio obligatorio.

Cambio de hardware – Dependiendo de la arquitectura y el tipo de dispositivos un cambio de hardware requiere apagar el equipo y por lo tanto reiniciar. Linux está preparado para autodetectar los cambios de harware, por lo que el hardware hot-swap funciona transparentemente. A su vez, en ambientes donde el hardware puede ser configurado a demanda (como virtualización) Linux va a detectar las alteraciones de CPU, Memoria y dispositivos en forma normal.

Actualización del kernel – A diferencia de otros sistemas operativos, en Linux es posible actualizar la mayoría del sistema sin reiniciar, pero los administradores sabemos que actualizar el kernel requiere reiniciar el equipo.  No obstante, a partir de Abril de 2015 con la versión 4.0 el kernel incluye la funcionalidad de «no reboot patching» y para esto existen algunas opciones como Ksplice (GPL), kpatch de RedHat o kGraft de SuSE; así que próximamente nuestros kernel se actualizarán sin reiniciar.

Desactivar o activar SELinux – Pasar el sistema de seguridad SELinux del kernel de Enforced a Disabled o viceversa, requiere reiniciar el sistema como puede verse en los manuales de administración RedHat

Modificar filesystem del sistema – Para cambiar tamaño de una partición que aloja un filesystem del sistema es necesario desmontarla y esto se hace reiniciado con otro sistema (por ejemplo live-CD de PartMagic). Si bien algunos filesystems pueden ser agrandados mientras están montados, podemos entender que esta es otra razón de reinicio – Gracias Arlequín y @alfrenovsky por los comentarios.

Actualización de librerías (glibc) – Cuando se actualizan las librerías dinamicas, los ejecutables que están corriendo quedan vinculados (linked) a las librerías antiguas, por lo que es recomendable reiniciar los daemons que quedan afectados. Pero cuando se instala una nueva versión de la librería glibc se afectan la mayoría de los procesos (por no decir, todos); en esos casos la opción más fácil es reiniciar todo el sistema para que los ejecutables queden corriendo vinculados a las nuevas librerías glibc. – Gracias El G@llego por aporte.

¿conoces algun otro motivo por el que es requerido reiniciar Linux?  Por favor, dejame tu comentario e ire actualizando este artículo.