Systemd-AFV.Pdf
Total Page:16
File Type:pdf, Size:1020Kb
Facultade de Informática ADMINISTRACIÓN DE SISTEMAS OPERATIVOS GRADO EN INGENIERÍA INFORMÁTICA MENCIÓN EN TECNOLOGÍAS DE LA INFORMACIÓN SYSTEMD Nombre del grupo: AFV Estudiante 1: Sara Fernández Martínez email 1: [email protected] Estudiante 2: Andrés Fernández Varela email 2: [email protected] Estudiante 3: Javier Taboada Núñez email 3: [email protected] Estudiante 4: Alejandro José Fernández Esmorís email 4: [email protected] Estudiante 5: Luis Pita Romero email 5: [email protected] A Coruña, mayo de 2021. Índice general 1 Introducción 1 1.1 ¿Qué es un sistema init? ................................... 1 1.2 Necesidad de una alternativa ................................. 1 2 ¿Qué es systemd? 2 2.1 Un poco de historia ...................................... 2 3 Units 5 4 Compatibilidad de systemd con SysV 6 5 Utilities 7 6 Systemctl 12 7 Systemd-boot: una alternativa a GRUB 15 8 Ventajas y Desventajas de Systemd 16 8.1 Ventajas ............................................ 16 8.1.1 Principales ventajas ................................. 16 8.1.2 Más en profundidad ................................. 16 8.2 Desventajas .......................................... 18 8.2.1 Principales desventajas ................................ 18 8.2.2 Más en profundidad ................................. 18 9 Conclusiones 20 Bibliografía 21 i Índice de figuras 2.1 Ejemplo ejecución machinectl shell. ............................. 3 2.2 Ejemplo ejecución systemd-analyze. ............................. 3 2.3 Ejemplo ejecución systemd-analyze-blame. ......................... 4 2.4 Ejemplo ejecución systemd-analyze-critical-chain. ..................... 4 5.1 journalctl ............................................ 7 5.2 journalctl opcion -r ...................................... 8 5.3 journalctl opcion -f ...................................... 8 5.4 journalctl opcion -nx ..................................... 9 5.5 journalctl opcion –since –until ................................ 9 5.6 journalctl opcion UID ..................................... 9 5.7 journalctl opcion -u ...................................... 10 5.8 journalctl opcion -b ...................................... 10 5.9 journalctl opcion -k ...................................... 11 5.10 hostnamectl .......................................... 11 6.1 Versión systemctl. ....................................... 12 6.2 Listar unidades. ........................................ 12 6.3 Unidad activa?. ......................................... 13 6.4 Unidades fallidas. ....................................... 13 6.5 Estado de una unidad. ..................................... 13 ii Capítulo 1 Introducción 1.1 ¿Qué es un sistema init? Cuando se inicia una máquina Linux, se ejecuta un código incorporado, el cuál es cargado desde la BIOS o UEFI, seguido del bootloader, que carga un kernel de Linux según la configuración que tenga. El kernel carga los controladores e inicia init como primer proceso (con PID 1). El diseño de init tuvo una discrepancia entre los sistemas Unix System V y BSD. En el esquema System V se usa /etc/inittab para establecer los runlevels disponibles, los cuales determinan el nivel de ejecución del sistema. Cada runlevel determina el subconjunto de servicios o daemons que serán iniciados durante el inicio del sistema, aunque el runlevel 0 y el 6 estan reservados para apagar y reiniciar el sistema respectivamente. En el init de BSD se ejecuta el script de inicialización /etc/rc y no existen runlevels sino que dicho archivo /etc/rc determina qué servicios se inician. La ventaja de este sistema es que es simple y fácil de mantener pero es propenso a errores dado que un mínimo error en el script puede detener el inicio del sistema. 1.2 Necesidad de una alternativa El sistema init tenía limitaciones en su diseño, como por ejemplo que los servicios se iniciaban de forma secuencial, lo que provocaba largos tiempos de inicio del sistema, o que si un servicio fallaba el proceso de inicio se quedaba bloqueado. Estos ejemplos sumados otros defectos de diseño motivaron la creación de systemd, que fue pensado para mejorar la eficiencia del proceso de inicio init de System V. [1][2] 1 Capítulo 2 ¿Qué es systemd? Tal y como lo definen sus autores, se trata de un ”bloque de construcción básico” para unsistema operativo, en una definición un poco más formal, es un conjunto de daemons de administración de sistema, bibliotecas y herramientas que fueron diseñados para interactuar con el núcleo del sistema operativo GNU/Linux. Es el primer proceso en el arranque de Linux que se ejecuta en el espacio de usuario, por lo que también se considera el proceso padre de todos los procesos hijos que existen en dicho espacio. Es importante resaltar que se trata de un software libre y de código abierto y que uno de sus principales objetivos es unificar configuraciones básicas de Linux y los comportamientos de servicios en todaslas distribuciones. [3] 2.1 Un poco de historia Systemd fue desarrollado en un inicio por Lennart Poettering y Kay Sievers, entre otros, ambos son ingenieros de software que trabajaban para Red Hat e iniciaron el desarrollo de systemd enel2010, con él intentaron superar las eficiencias de daemon de inico de varias formas: • Mejorar el marco de software para expresar las dependencias. • Permitir que se realicen un mayor número de procesamientos en paralelo durante el arranque del sistema. • Reducir la sobrecarga computacional del shell. A lo largo de los años systemd se ha convertido en el sistema de inicio predeterminado de dis- tintas distribuciones de Linux, pero destacar que fue Fedora, en el año 2011, la primera distribución importante de Linux en habilitar systemd de manera predeterminada. 2 CAPÍTULO 2. ¿QUÉ ES SYSTEMD? Para terminar mencionar que en 2015 systemd comenzó a proporcionar un shell de inicio de se- sión, invocable mediante machinectl shell 2.1 y a lo largo de años posteriores se han ido detectando diversos bugs de seguridad que permitían realizar ataques DoS 1 contra systemd. Figura 2.1: Ejemplo ejecución machinectl shell. A continuación mostramos algunos ejemplos de ejecución con el comando ”systemd”. En esta primera figura 2.2 vemos como al utilizar el comando systemd-analyze nos muestra infor- mación de las estadísticas de rendimiento de arranque del sistema. Figura 2.2: Ejemplo ejecución systemd-analyze. Ahora, en la siguiente imagen 2.3 al utilizar el comando systemd-analyze blame nos imprime una lista de todas las unidades en ejecución, ordenadas por el tiempo que tardaron en inicializarse. 1 DoS: Denial of Service 3 CAPÍTULO 2. ¿QUÉ ES SYSTEMD? Figura 2.3: Ejemplo ejecución systemd-analyze-blame. Y por último con el uso del comando systemd-analyze critical-chain en la figura 2.4 se observa como imprime un árbol de la cadena de unidades de tiempo crítico(para cada una de las UNIDADES especificadas o para el objetivo predeterminado en caso contrario). Además después del caracter ’@’, se imprime El tiempo después de que la unidad esté activa o iniciada. Figura 2.4: Ejemplo ejecución systemd-analyze-critical-chain. 4 Capítulo 3 Units Todo lo que es gestionado por systemd se llama ”unit” y cada una de ellas es descrita por un archivo de configuración propio que tendrá una extensión distinta conforme al tipo de unidad tratada[4]: • .service: fichero que describe la configuración de un demonio. • .socket: describe la configuración de un socket(tipo UNIX o TCP/IP) asociada a un .service. • .device: describe un dispositivo hardware reconocido por el kernel que esté gestionado por systemd. • .mount: describe un punto de montaje gestionado por systemd. • .automount:describe un punto de automontaje asociado a un .mount. • .swap: describe una partición o archivo de intercambio gestionado por systemd. • .target: describe un grupo de Units. • .path: describe una carpeta o archivo monitorizado por la API Inotify delk kernel. • .timer: describe la temporización de una tarea programada con el programador systemd. • .slice: describe un grupo de Units asociadas a procesos para administrar y limitar los recursos comunes (CPU, memoria…). Además utiliza internamente los ”cgroups” del kernel. Los archivos de configuración de las Units pueden estar repartidos en tres carpetas distintas: • /usr/lib/systemd/system : Para units proporcionadas por los paquetes instalados en el sistema. • /run/systemd/system : Para units generadas en tiempo real durante la ejecución del sistema. Son no persistentes. • /etc/systemd/system : Para units proporcionadas por el administrador del sistema. 5 Capítulo 4 Compatibilidad de systemd con SysV Systemd, al igual que Upstart(reemplazo basado en eventos para el daemon init, método utilizado por varios sistemas operativos Unix-like para realizar tareas durante el arranque del sistema) ofrece compatibilidad con SysV (comando service y chkconfig) para aquellos servicios que aún soportan o funcionan únicamente con scripts de inicio SysV (aunque actualmente no hay muchos servicios que lo hagan)[5]. Upstart pese a mantener compatibilidad con los comandos service y chkconf de SysV implementó su propia utilidad para la administración de servicios, de igual modo systemd lo hace con la herramienta systemctl. SysV habilitaba servicios con chkconfig (o reproducía listas de estos para ver cuál de ellos se ejecutaba al arranque), algo que ahora bajo systemd podemos hacer con los siguientes comandos: Para habilitar el servicio httpd al arranque del sistema: • systemctl enable httpd.service Para listar todas las unidades de servicios instaladas: • systemctl list-unit-files