Tema 101: Arquitectura del Sistema
Last updated
Last updated
Importancia
2
Descripción
Los candidatos deberán ser capaces de determinar y configurar el hardware fundamental del sistema.
Activar y desactivar los periféricos integrados
Diferenciar entre los distintos tipos de dispositivos de almacenamiento masivo.
Determinar los recursos de hardware para los dispositivos.
Herramientas y utilidades para listar información de hardware (por ejemplo, lsusb, lspci, etc.).
Herramientas y utilidades para manipular dispositivos USB.Conocimientos conceptuales de sysfs, udev y dbus.
Importancia
3
Descripción
Los candidatos deberán ser capaces de guiar el sistema a lo largo del proceso de arranque.
Proporcionar comandos comunes al gestor de arranque y opciones al kernel en el momento del arranque.
Demostrar conocimiento de la secuencia de arranque desde BIOS/UEFI hasta la finalización del arranque.
Comprensión de SysVinit y systemd.
Conocimiento de Upstart.
Comprobar los eventos de arranque en los archivos de registro.
Para controlar la máquina, el componente principal del sistema operativo, el núcleo, debe cargarse mediante un programa llamado bootloader, que a su vez lo carga un firmware preinstalado como BIOS o UEFI, la ubicación de almacenamiento es independiente de los otros dispositivos de almacenamiento que pueda tener el sistema.
El gestor de arranque se puede personalizar para pasar parámetros al núcleo, como qué partición contiene el sistema de archivos raíz o en qué modo debe ejecutarse el sistema operativo.
Una vez cargado, el núcleo continúa el proceso de arranque identificando y configurando el hardware. Por último, el núcleo del sistema operativo llama a la utilidad responsable de iniciar y administrar los servicios del sistema
Abreviatura de Basic Input/Output System, es un programa almacenado en un chip de memoria no volátil conectado a la placa base, que se ejecuta cada vez que se enciende la computadora.
En términos generales, los pasos previos a la operación para iniciar un sistema equipado con BIOS son:
El proceso POST (power-on self-test) se ejecuta para identificar fallas de dispositivos simples tan pronto como se enciende la máquina.
El BIOS activa los componentes básicos para cargar el sistema, como salida de video, teclado y medios de almacenamiento.
El BIOS carga la primera etapa del gestor de arranque desde el MBR (los primeros 440 bytes del primer dispositivo).
La primera etapa del gestor de arranque llama a la segunda etapa del gestor de arranque, responsable de presentar las opciones de arranque y cargar el núcleo del sistema operativo.
Abreviatura de Unified Extensible Firmware Interface, lo que la diferencia de la BIOS es lo siguiente:
Como BIOS, el UEFI también es un firmware, pero puede identificar particiones y leer muchos sistemas de archivos que se encuentran en ellas. Los sistemas de archivos compatibles estándar son FAT12, FAT16 y FAT32 para dispositivos de bloque e ISO-9660 para medios ópticos.
El UEFI no se basa en MBR.
UEFI puede hacer uso de los llamados EFI applications, que se ejecutarán automáticamente o se llamarán desde un menú de arranque, estos pueden ser gestores de arranque, selectores de sistema operativo, herramientas para el diagnóstico y reparación del sistema, etc.
La partición que contiene las aplicaciones EFI se llama EFI System Partition o simplemente ESP. Esta partición no debe compartirse con otros sistemas de archivos del sistema, como el sistema de archivos raíz o los sistemas de archivos de datos del usuario. El directorio EFI en la partición ESP contiene las aplicaciones señaladas por las entradas guardadas en la NVRAM.
El gestor de arranque más popular para Linux en la arquitectura x86 es GRUB (Grand Unified Bootloader). Tan pronto como lo llame el BIOS o el UEFI, GRUB muestra una lista de los sistemas operativos disponibles para arrancar. A veces, la lista no aparece automáticamente, pero se puede invocar presionando Shift mientras el BIOS está llamando a GRUB. En los sistemas UEFI, la tecla Esc debería usarse en su lugar.
Además del núcleo, el sistema operativo depende de otros componentes que proporcionan las características esperadas. Muchos de estos componentes se cargan durante el proceso de inicialización del sistema, que varía desde simples scripts de consola hasta programas de servicio (los llamados daemons) más complejos:
La inicialización del SO comienza cuando el gestor de arranque carga el núcleo en la RAM.
A continuación, el núcleo se hará cargo de la CPU y comenzará a detectar y configurar los aspectos fundamentales del sistema operativo, como la configuración básica de los dispositivos y el direccionamiento de la memoria.
El núcleo del sistema operativo abrirá el archivoinitramfs (initial RAM filesystem), este es un archivo que contiene un sistema de archivos utilizado como un sistema de archivos raíz temporal durante el proceso de arranque. El objetivo principal de un archivo initramfs es proporcionar los módulos necesarios para que el núcleo pueda acceder al sistema de archivos raíz "real" del sistema operativo.
Tan pronto como el sistema de archivos raíz esté disponible, el núcleo montará todos los sistemas de archivos configurados en /etc/fstab y luego ejecutará el primer programa, una utilidad llamada init.
El programa init es responsable de ejecutar todos los scripts de inicialización y daemons del sistema. Una vez que se carga el programa init, initramfs se elimina de la RAM.
Existen implementaciones distintas de iniciadores de sistemas aparte del init tradicional, como SysV, systemd y Upstart:
Pueden ocurrir errores durante el proceso de arranque, pero pueden no ser tan críticos para detener completamente el sistema operativo, no obstante, estos errores pueden comprometer el comportamiento esperado del sistema.
El espacio de memoria donde el kernel almacena sus mensajes, incluidos los mensajes de arranque, se llama kernel ring buffer. Estos se guardan en el búfer incluso cuando no se muestran, sin embargo, este pierde todos los mensajes cuando el sistema está apagado o al ejecutar el comando dmesg --clear.
Para ver lo almacenado en el buffer, usa el comando dmesg :
En sistemas basados en systemd, el comando journalctl mostrará los mensajes de inicialización con las opciones -b, --boot,-k o --dmesg.
El comando journalctl --list-boots muestra una lista de números de arranque relativos al arranque actual, su hash de identificación y las marcas de tiempo del primer y último mensaje correspondientes.
En sistemas basados en systemd, los registros de inicialización anteriores también se mantienen, por lo que los mensajes de sesiones anteriores del sistema operativo aún se pueden inspeccionar. Para ello es tan sencillo como modificar el numero:
Si se proporcionan las opciones -b 0 o --boot=0, se mostrarán los mensajes para el arranque actual.
Las opciones -b -1 o --boot=-1 mostrarán mensajes de la inicialización anterior.
Las opciones -b -2 o --boot=-2 mostrarán los mensajes de la inicialización antes de eso y así sucesivamente.
Esto puede resultar útil para revisar fallos de inicio de sistema anteriores. La inicialización y otros mensajes emitidos por el sistema operativo se almacenan en archivos dentro del directorio /var/log/.
El archivo /etc/fstab es un componente vital en Linux, ya que almacena información esencial sobre los sistemas de archivos, sus puntos de montaje y opciones de montaje. Este archivo permite que el sistema sepa qué sistemas de archivos montar y cómo manejar cada uno al iniciarse. A continuación, desglosar´r la estructura de /etc/fstab y explicaré cada campo y su función, para que se pueda configurar con confianza la información estática del sistema de archivos.
/etc/fstabComo ya hemos visto, el archivo /etc/fstab sirve como referencia para los programas, indicándoles cómo manejar los sistemas de archivos del sistema. Programas como mount , umount y fsck utilizan este archivo para determinar puntos de montaje, opciones y configuraciones específicas para cada sistema de archivos.
Por ejemplo, cuando el sistema arranca, mount lee /etc/fstab y monta los sistemas de archivos según lo especificado. Si ejecuta mount -a manualmente, vuelve a leer /etc/fstab e intenta montar cualquier sistema de archivos que se encuentre en la lista. De manera similar, fsck (la herramienta de verificación del sistema de archivos) hace referencia a /etc/fstab para identificar los sistemas de archivos que necesitan verificación durante el arranque, lo que ayuda a mantener la integridad del sistema de archivos.
Cada línea de /etc/fstab describe un sistema de archivos y especifica detalles sobre su punto de montaje, opciones de montaje y otras configuraciones. Por ejemplo, una entrada como:
Le dice a mount que monte /dev/sda1 en /data como un sistema de archivos ext4 con opciones predeterminadas (como acceso de lectura/escritura) cada vez que se inicia el sistema.
Así es como se ve el archivo /etc/fstab:
/etc/fstabCada entrada en /etc/fstab tiene seis campos, cada uno con un propósito específico. Repasemos cada campo y entendamos qué hace.
El primer campo especifica el dispositivo de bloque que se montará, al que normalmente se hace referencia mediante su ruta en /dev . Por ejemplo, para especificar la primera partición en un dispositivo sda , se utilizaría /dev/sda1 .
También puede hacer referencia a un dispositivo de bloque por su LABEL o UUID (Identificador único universal). Se prefiere el uso de UUID porque identifica de forma única un sistema de archivos independientemente de los cambios de hardware. En sistemas con discos particionados con GPT, puede incluso utilizar PARTUUID o PARTLABEL para mayor especificidad.
Para recopilar información sobre un dispositivo, utilice el comando lsblk . Por ejemplo:
Este comando muestra detalles como el tipo de sistema de archivos, la etiqueta, el UUID y el punto de montaje. A continuación, se muestra un ejemplo de salida:
Con esta información, podemos usar el UUID para referenciar el sistema de archivos en /etc/fstab :
También puede mostrar información recopilada sobre un dispositivo específico utilizando el comando blkid :
El segundo campo especifica el directorio donde se montará el sistema de archivos, lo que permitirá acceder a su contenido. Este campo debe contener una ruta de punto de montaje válida, a menos que el dispositivo se utilice como intercambio, en cuyo caso el campo debe contener none .
Por ejemplo, si queremos montar nuestro sistema de archivos en /mnt/data , nuestra entrada /etc/fstab comenzaría de la siguiente manera:
El tercer campo identifica el tipo de sistema de archivos, como ext4, or swap o xfs . Garantiza que el sistema sepa cómo interactuar con el dispositivo especificado. Para sistemas de archivos remotos, se utilizaría cifs (para recursos compartidos Samba) o nfs (para recursos compartidos NFS). En nuestro ejemplo, sda1 tiene el formato ext4 , por lo que nuestra entrada se ve así:
El cuarto campo define las opciones de montaje, que determinan cómo se comporta el sistema de archivos. Para utilizar las opciones predeterminadas, simplemente introduzca defaults . Esto es lo que incluye “default”:
rw : Permite leer y escribir.
suid : habilita los bits setuid y setgid.
dev : interpreta dispositivos de caracteres y bloques.
exec : permite ejecutar binarios.
auto : se monta automáticamente cuando se ejecuta mount -a .
nouser : restringe el montaje por parte de usuarios que no sean root.
async : habilita operaciones de E/S asincrónicas.
Además de las opciones predeterminadas, puede configurar opciones adicionales para personalizar el comportamiento del sistema de archivos:
usrquota : habilita cuotas de disco de usuario, lo que permite establecer límites en el espacio de disco o en la cantidad de archivos para usuarios individuales.
grpquota : habilita cuotas de disco grupales, estableciendo límites para grupos en lugar de usuarios individuales.
relatime : actualiza los tiempos de acceso a los archivos solo cuando se modifican, lo que reduce las escrituras en disco en comparación con atime .
sync : fuerza operaciones de E/S sincrónicas, lo que significa que los cambios se escriben inmediatamente en el disco en lugar de almacenarse en caché. Esto puede mejorar la integridad de los datos, pero puede afectar el rendimiento.
Esta lista incluye opciones comunes, pero no es exhaustiva. Para obtener una lista completa y más detalles, consulte la página del manual mount(8) ejecutando:
Con estas opciones nuestra entrada ahora se lee:
El quinto campo, 0 o 1 , indica si el sistema de archivos debe incluirse en las copias de seguridad realizadas por la utilidad dump . Si no se utiliza dump , este campo suele configurarse en 0 :
El sexto campo controla el orden en el que fsck (comprobación del sistema de archivos) comprueba los sistemas de archivos durante el arranque. El sistema de archivos raíz debe tener un valor de 1 , mientras que todos los demás suelen utilizar 2 Si no es necesario comprobar un sistema de archivos, este campo se establece en 0 :
Importancia
3
Descripción
Los candidatos deberán ser capaces de gestionar el nivel de ejecución de SysVinit o el objetivo de arranque systemd del sistema. Este objetivo incluye cambiar al modo de usuario único, apagar o reiniciar el sistema. Los candidatos deberán ser capaces de alertar a los usuarios antes de cambiar de nivel de ejecución / objetivo de arranque y terminar adecuadamente los procesos. Este objetivo también incluye establecer el nivel de ejecución predeterminado de SysVinit o el objetivo de arranque systemd. También incluye el conocimiento de Upstart como una alternativa a SysVinit o systemd.
Establecer el nivel de ejecución o el objetivo de arranque predeterminado.
Cambiar entre niveles de ejecución / objetivos de arranque, incluido el modo monousuario.
Apagar y reiniciar desde la línea de comandos.
Alertar a los usuarios antes de cambiar de nivel de ejecución/objetivo de arranque u otros eventos importantes del sistema.
Terminar procesos de forma adecuada.
Conocimiento de ACPID.
Una característica común entre SO Unix es el empleo de procesos separados para controlar distintas funciones del sistema, estos, llamados daemons (o, más generalmente, services), también son responsables de las características extendidas subyacentes al sistema operativo, como los servicios de aplicaciones de red (servidor HTTP, intercambio de archivos, correo electrónico, etc.), bases de datos, configuración bajo demanda, etc.
Hoy en día, los administradores de servicios basados en sistemas se encuentran con mayor frecuencia en la mayoría de las distribuciones de Linux. El administrador de servicios es el primer programa lanzado por el núcleo durante el proceso de arranque, por lo que su PID (número de identificación del proceso) siempre es 1.
Tal y como aparecía en la anterior lección, el primer método lo implementa el estándar SysVinit, el segundo método es implementado por systemd y el tercero, Upstart:
Un administrador de servicios basado en el estándar SysVinit proporcionará conjuntos predefinidos de estados del sistema, llamados runlevels, y sus correspondientes archivos de script de servicio para ser ejecutados. Los niveles de ejecución están numerados de 0 a 6, y generalmente se asignan a los siguientes propósitos:
Runlevel 0 -> Apagado del sistema, scripts que llevan a apagar el sistema.
Runlevel 1, s o usuario único -> Modo de usuario único, sin red y otras capacidades no esenciales (modo de mantenimiento).
Runlevel 2, 3, 4 o 5 -> Modo multiusuario. Los usuarios pueden iniciar sesión por consola o red. Los niveles de ejecución 2 y 4 no se usan con frecuencia. Esto depende de la distribución, en Ubuntu el runlevel gráfico multiusuario es el 2 y en CentOS es el 4.
Runlevel 6 -> Reinicio del sistema.
El kernel arranca el el sistema con el programa /sbin/init y este identifica el nivel de ejecución necesario desde la linea del kernel (init default) o bien, definido en el parámetro del archivo /etc/inittab a partir de aquí comienzan a cargar los scripts del nivel de ejecución (etc/rcX.d donde X es el nivel de ejecución (0, 1, 2, 3...) y estos archivos son enlaces simbólicos a scripts de init que se encuentran el en directorio /etc/init.d/
La sintaxis del archivo /etc/inittab usa este formato:
Donde el id es un nombre genérico de hasta cuatro caracteres de longitud utilizado para identificar la entrada, runlevels es una lista de números de niveles para los que se debe ejecutar una acción específica y, por último, el término action define cómo init ejecutará el proceso indicado por el término process.
En distribuciones modernas ya no se usan los estandares SysV por lo que no indagaré más allá por ahora.
Actualmente, systemd es el conjunto de herramientas más utilizado para administrar los recursos y servicios del sistema, denominadas unidades (units). Una unidad consta de nombre, tipo y un archivo de configuración correspondiente.
Por ejemplo, la unidad para un proceso de servidor httpd (como el servidor web Apache) será httpd.service en distribuciones basadas en Red Hat, su archivo de configuración también se llamará httpd.service (en distribuciones basadas en Debian esta unidad es llamada apache2.service).
Hay varios tipos distintos de unidades systemd:
service -> El tipo de unidad más común, para recursos activos del sistema que se pueden iniciar, interrumpir y recargar. Por ejemplo, apache, networking, etc.
socket -> El tipo de unidad de socket puede ser un socket de sistema de ficheros o un socket de red. Todas las unidades de socket deben tener una unidad service correspondiente, cargada cuando el socket recibe una solicitud.
device -> Una unidad de dispositivo está asociada con un dispositivo de hardware identificado por el núcleo ya que systemd puede gestionar también recursos de hardware no solo servicios. Se puede usar una unidad de dispositivo para resolver dependencias de configuración cuando se detecta cierto hardware, dado que las propiedades de la regla udev se pueden usar como parámetros para la unidad de dispositivo. Por ejemplo puede ser una partición, un disco, etc.
mount -> Una unidad de montaje es una definición de punto de montaje en el sistema de archivos, similar a una entrada en /etc/fstab.
automount -> Una unidad de montaje automático también es una definición de punto de montaje en el sistema de archivos, pero se monta automáticamente. Cada unidad de montaje automático tiene una unidad mount correspondiente, que se inicia cuando se accede al punto de montaje automático.
target -> Una unidad target es una agrupación de otras unidades, administradas como una sola unidad.
snapshot -> Una unidad snapshot es un estado guardado del administrador del sistema (no disponible en todas las distribuciones de Linux).
path -> permite monitorizar directorios o ficheros para lanzar otras units.
scope -> las crea el servicio systemd con información recibida a través del bus de datos.
slice -> unit asociada a los cgroups que tenga configurado un servicio.
swap -> describe el espacio de swap.
timer -> tareas programadas gestionadas por systemd.
Todas estas units se almacenan en 3 directorios diferentes del sistema, en función de la generación del fichero:
/usr/lib/systemd/system: unidades distribuidas con los paquetes de la distribución instalados.
/run/systemd/system: unidades creadas en tiempo de ejecución. Tienen preferencia sobre las del directorio anterior.
/etc/systemd/system: unidades creadas y gestionadas por el administrador del sistema. Prevalecen sobre los 2 directorios anteriores.
El comando principal para controlar las unidades systemd es systemctl, este comando se usa para ejecutar todas las tareas relacionadas con la activación, desactivación, ejecución, interrupción, monitoreo de la unidad, etc.
Para una unidad ficticia llamada unit.service, por ejemplo, las acciones más comunes de systemctl serán:
Aquí tienes un ejemplo de un service con fallo para que te vayas acostumbrando:
Hay objetivos correspondientes a los niveles de ejecución de SysV, comenzando con runlevelO.target hasta runlevel6.target. Sin embargo, systemd no utiliza el archivo /etc/inittab. Para cambiar el objetivo predeterminado del sistema, la opción systemd.unit se puede agregar a la lista de parámetros del núcleo del SO.
Por ejemplo, para usar multi-user.target como objetivo estándar (Este combina todas las unidades requeridas por el entorno del sistema multiusuario), el parámetro del núcleo del sistema operativo debe ser systemd.unit=multi-user.target. Todos los parámetros del kernel pueden hacerse persistentes cambiando la configuración del gestor de arranque
Otra forma de cambiar el objetivo predeterminado es modificar el enlace simbólico /etc/systemd/system/default.target para que apunte al objetivo deseado. La redefinición del enlace se puede hacer con el comando systemctl por sí mismo:
Del mismo modo, podemos llegar a saber cuál es el objetivo de arranque predeterminado actual del sistema con el siguiente comando:
Obviamente, y siendo similar a los sistemas que adoptan SysV, el objetivo predeterminado nunca debe apuntar a shutdown.target, ya que corresponde al nivel de ejecución 0 (apagado) y causaria que al arrancar el sistema ejecutará los scripts de apagado llegando a no arrancar.
Los archivos de configuración asociados con cada unidad se pueden encontrar en el directorio /lib/systemd/system/. El comando systemctl list-unit-files enumera todas las unidades disponibles y muestra si están habilitadas para iniciarse cuando se inicia el sistema, dentro de esta podemos hacer variaciones o añadir parámetros por ejemplo:
systemd también es responsable de desencadenar y responder a eventos relacionados con la energía del sistema:
Estas acciones se definen en el archivo /etc/systemd/logind.conf o en archivos separados dentro del directorio /etc/systemd/logind.conf.d/.
Como veremos más adelante, esta función systemd solo se puede usar cuando no hay otro administrador de energía ejecutándose en el sistema, como el daemonacpidya que es el principal administrador de energía para Linux y permite ajustes más precisos a las acciones posteriores a eventos relacionados con la energía, como cerrar la tapa del portátil, batería baja o niveles de carga de la batería.
Objetivo: Configurar y gestionar un servicio con systemd que muestra un mensaje animado en la terminal cada minuto.
Ejecuta el siguiente comando para instalar figlet y cowsay, herramientas que permitirán generar mensajes en la terminal:
Crea un script en /usr/local/bin/mensaje.sh con el siguiente contenido:
Dale permisos de ejecución:
Ahora, crea el archivo del servicio en /etc/systemd/system/mensaje.service:
Recarga systemd para que detecte el nuevo servicio:
Inicia el servicio:
Verifica su estado:
Si todo está bien, habilítalo para que inicie automáticamente con el sistema:
Para ver los mensajes generados, revisa los logs con:
En los logs verás si ha funcionado, recuerda que, por defecto, systemd no muestra la salida de los servicios en la terminal actual porque los servicios se ejecutan en segundo plano (como daemons).
Si deseas detenerlo:
Si quieres deshabilitarlo del inicio:
...
Un comando muy tradicional utilizado para apagar o reiniciar el sistema es shutdown, este agrega funciones adicionales al proceso de apagado como por ejemplo, notificar automáticamente a todos los usuarios conectados con un mensaje de advertencia en sus sesiones de shell para evitar nuevos inicios de sesión.
El comando shutdown actúa como intermediario para los procedimientos tanto de SysV como de systemd, es decir, ejecuta la acción solicitada llamando a la acción correspondiente en el administrador de servicios adoptado por el sistema.
Después de ejecutar shutdown, todos los procesos reciben la señal SIGTERM, seguida de la señal SIGKILL, luego el sistema se apaga o cambia su nivel de ejecución. Por defecto, cuando no se utilizan las opciones -h o -r, el sistema alterna al nivel de ejecución 1, es decir, el modo de usuario único.
Para cambiar las opciones predeterminadas para shutdown, el comando debe ejecutarse con la siguiente sintaxis: $
El parámetro message es el texto de advertencia enviado a todas las sesiones de terminal de los usuarios conectados o el comando wall puede enviar un mensaje a las sesiones de terminal de todos los usuarios conectados, tienen un propósito similar, pero su ámbito de aplicación y forma de uso son diferentes:
El comando systemctl con privilegios de root también se puede usar para apagar o reiniciar la máquina en sistemas que emplean systemd:
Aunque Linux utiliza un , muchos aspectos de bajo nivel del sistema operativo se ven afectados por daemons, como el equilibrio de carga y la configuración del firewall. Los demonios (daemons) que deberían estar activos dependen del propósito del sistema. El conjunto de demonios activos también debe poder modificarse en tiempo de ejecución, de modo que los servicios se puedan iniciar y detener sin tener que reiniciar todo el sistema. Para abordar este problema, cada distribución principal de Linux ofrece alguna forma o utilidad de administración de servicios para controlar el sistema.
Más info:
SysV standard
Un administrador de servicios basado en el estándar SysVinit controla qué daemons y recursos estarán disponibles empleando el concepto de runlevels.
Los niveles de ejecución están numerados del 0 al 6 y están diseñados por los encargados de la distribución para cumplir con propósitos específicos.
Las únicas definiciones de nivel de ejecución compartidas entre todas las distribuciones son los niveles de ejecución 0, 1 y 6.
Upstart
Al igual que systemd, Upstart es un sustituto de init.
El objetivo de Upstart es acelerar el proceso de arranque paralelizando el proceso de carga de los servicios del sistema.
Upstart fue utilizado por distribuciones basadas en Ubuntu en versiones anteriores, pero hoy dio paso a systemd.
systemd
systemd es un administrador moderno de sistemas y servicios con una capa de compatibilidad para los comandos y niveles de ejecución de SysV.
systemd tiene una estructura concurrente, emplea sockets y D-Bus para la activación del servicio, ejecución de demonios a demanda, monitoreo de procesos con cgroups, snapshot support, recuperación de sesión del sistema, control de punto de montaje y un control de servicio basado en la dependencia.
