Bienvenidos al primer borrador de la versión 5 libre del 101 en castellano. Voy a dejar comentarios en naranja, x ejemplo las fuentes, notas y traducciones que no tenga muy seguro de que esten bien. Los (!) significan que es posible que te salga en el examen. Igual no te toca pero la pregunta existe. Intentad seguir con el formato del texto (aunque de momento no es importante) y la estructura. - La parte de comandos esta en open sans light Personalmente cambiaría la formalidad por tutear.. Se me hace más cercano,como hecho entre amigos que nos echamos una mano, pero también me da igual El que se comprometa a escribir un tema o capítulo podría marcarlo en a marillo y verde cuando ya lo considere acabado. (Todo el 103.1 al 103.8) iré escribiendolo, ME LO PIDO :P by Vbits Casi todo este texto de ese capitulo esta traducido con el traductor deepl. Si veis cosas raras me lo comentais que a veces leo rápido. Os aconsejo este traductor mas que ningun otro. Luego si algo no cuadra podreis también probar con google translate, pons, etc.. FUENTE: neuronasdigitales y comparado con la wiki he quitado: Eliminado 'Configurar sistemas con o sin periféricos externos como teclados'. Eliminado 'Conozca las diferencias entre los dispositivos de conexión en frío y los de conexión en caliente'. 6 Objetivos: Examen 101 Tema 101: Arquitectura del sistema 101.1 Determinar y configurar los ajustes de hardware (pido revision,fuente antigua) Información general Identificar las versiones del kernel Comandos para gestionar los módulos del kernel Recursos para los componentes de hardware El directorio /proc/sys/kernel El sistema de archivos virtual sysfs hald, dbus y udev Los archivos de dispositivo en /dev El bus PCI USB - Universal Serial Bus 101.2 Arranque del sistema LPIC 1 Version 5 Información general UEFI cargador de arranque parámetros del núcleo initramfs (disco RAM inicial) registro de arranque sistemas init 101.3 Cambiar los runlevels y apagar o reiniciar el sistema Información general Los runlevel y su función. El archivo de configuración inittab Directorios y Ficheros del Proceso init Cambio de runlevel, apagado, reinicio upstart Sistemd Tema 102: Instalación de Linux y gestión de paquetes 102.1 Diseño de la distribución del disco duro Información general Planificación de tamaños de partición Partición del sistema EFI (ESP) Gestor de volúmenes lógicos Componentes y relaciones de LVM 102.2 Instalar un gestor de arranque Informacion general GRUB-Legacy GRUB 2 102.3 Administrar bibliotecas compartidas Información general Administración de bibliotecas compartidas LD_LIBRARY_PATH 102.4 Usar la gestión de paquetes de Debian 102.5 Utilizar la gestión de paquetes RPM y YUM 102.6 Linux como invitado de virtualización Tema 103: Comandos GNU y Unix (Acabado: 28.11.18, pido revision, by Vbits) 103.1 Trabajo en la línea de comandos Información general Estructura de un comando de Shell Transferencia de opciones Variables de entorno y variables de shell Variables populares para los exámenes Comando history de bash y finalización automática de comandos Variable PATH Quoting Comando uname 1 LPIC 1 Version 5 Manpages 103.2 Procesar flujos de texto utilizando filtros 103.3 Realizar la gestión básica de archivos 103.4 Usar flujos, tuberías y redirecciones 103.5 Crear, monitorear y matar procesos 103.6 Modificar las prioridades de ejecución del proceso 103.7 Buscar archivos de texto usando expresiones regulares 103.8 Edición de archivos básicos Tema 104: Dispositivos, sistemas de archivos Linux, jerarquía estándar de sistema de archivos 104.1 Crear particiones y sistemas de archivos 104.2 Mantener la integridad de los sistemas de archivos 104.3 Controlar el montaje y desmontaje de sistemas de ficheros 104.4 Eliminado de la wiki 104.5 Administrar los permisos y la propiedad de los archivos 104.6 Crear y cambiar enlaces duros y simbólicos 104.7 Buscar archivos de sistema y colocarlos en la ubicación correcta 2 LPIC 1 Version 5 6. Objetivos: Examen 101 Tema 101: Arquitectura del Sistema 101.1 Determinar y configurar los ajustes de hardware Peso 2 Descripción Los candidatos deberán ser capaces de determinar y configurar el hardware fundamental del sistema. Áreas de conocimiento clave: 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 la información de hardware (por ejemplo, lsusb, lspci, etc.). ❖ Herramientas y utilidades para manipular dispositivos USB. ❖ Comprensión conceptual de sysfs, udev y dbus. ❖ ❖ ❖ ❖ Lista parcial de los archivos, términos y utilidades utilizados: ➢ ➢ ➢ ➢ /sys/ /proc/ /dev/ modprobe ➢ ➢ ➢ lsmod lspci lsusb FUENTE: neuronasdigitales Un sistema operativo es el software que hace de enlace entre las aplicaciones de usuario y el hardware. La finalidad de un sistema operativo es ofrecer un conjunto de programas que permitan hacer más fácil y eficiente el uso de un ordenador. Actualmente un ordenador es una máquina compleja que consta de uno o más procesadores, memoria de diferentes tipologías, relojes, periféricos, etc y además son sistemas donde puede trabajar más de uno usuario. Es evidente que se hace necesario que haya alguna solución que permita hacer uso de un ordenador sin necesidad de dominar la complejidad del hardware. Arquitectura de un sistema operativo 3 LPIC 1 Version 5 Partes de un sistema operativo: -Kernel (Núcleo): es la interfaz de comunicación entre el hardware y el software. Aplicaciones base: aplicaciones básicas para el correcto funcionamiento del sistema. La mayoría de aplicaciones son GNU Dos espacios de trabajo: -M odo supervisor o modo kernel: No tiene restricciones de acceso a la memoria y puede acceder a cualquier dirección, de cualquier proceso, o de cualquier dispositivo. Reservado para el uso del núcleo, de sus módulos o de algunos de sus controladores. Programar en este espacio es muy complicado. Se ha de tener mucho cuidado de no interferir entre los diferentes espacios de memoria de procesos. Se ha de diseñar el programa con la idea de no fallar nunca, puesto que un error en el programa implica un error en todo el sistema. -M odo de usuario o espacio de usuario: En contraste, el espacio de usuario es la zona donde se ejecutan las aplicaciones de usuario. En la mayoría de sistemas operativos actuales cada proceso tiene su propio espacio de memoria y no puede acceder al espacio de memoria de otros procesos y de esta manera se evita la interferencia entre procesos. La única forma en que un proceso del espacio de usuario puede acceder a la memoria de otros procesos es a través de las llamadas de sistema (interfaces) del sistema operativo, de forma que el sistema operativo puede gestionar el control de acceso a los recursos. Módulos – Gestión del Hardware Los controladores o drivers se encargan del acceso controlado al hardware. La mayoría de controladores son módulos del kernel. Estos pueden estar integrados en el mismo núcleo o cargarse en caliente. Se almacenan en / lib/modules y los que están disponibles para nuestro kernel están en \$ /lib/modules/`uname -r`. Las herramientas necesarias para la gestión de los módulos se encuentran en el paquete module-init-tools que por regla general se encuentra incluido en la mayoría de distribuciones. Las principales herramientas son: ➢ lsmod: Muestra la información de /proc/modules. La columna used indica cuántos módulos dependen de ese módulo. ➢ insmod: inserta un módulo en el kernel. Si el módulo depende de otros, las dependencias deben estar cargadas antes de ejecutar insmod. ➢ modprobe: inserta un módulo en el kernel y carga automáticamente los módulos que dependen de éste. En la carpeta /etc/modprobe.d/ se puede configurar las opciones a la hora de cargar un módulo, o definir una lista negra para especificar que no se cargue un módulo concreto ➢ modinfo: muestra la información detallada de un módulo. Interesante para ver en qué ruta se encuentra el fichero, o para averiguar para qué sirve. 4 LPIC 1 Version 5 ➢ rmmod: eliminar un módulo del kernel. Se puede incluir en el fichero /etc/modules que módulos queremos cargar manualmente durante el inicio del sistema. El script que se encarga de esta tarea es /etc/init.d/module-init-tools ➢ depmod: Establece las dependencias entre módulos. Se ejecuta únicamente durante el inicio de sistema. Solo lo ejecutaremos manualmente si modificamos la configuración de los módulos, como modificar el fichero modules.conf o de las carpetas modules.d. Genera el fichero /lib/modules/(kernel-version)/modules.dep Dispositivos PCI Antes de la aparición del sistema PnP (mediados de los 90), era tedioso configurar el hardware y a menudo se debía recurrir a los jumpers o a la BIOS. Actualmente la configuración se puede hacer por software y a menudo no hace falta configurar nada ya que gracias a PnP, los dispositivos se configuran solos. Se puede modificar los comportamiento del núcleo con respecto a la detección de hardware cambiando los siguientes parámetros u opciones del núcleo: PCI Devices –> Bus Options –> PCI Access Mode Tenemos 4 opciones: BIOS - MMConfig - Direct - Any-> Que quiere decir primero MMconfig, después Direct y finalmente BIOS. Es la opción habitual. lspci: muestra información sobre los dispositivos PCI y otros dispositivos del sistema. $ lspci 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05) [........] si escribimos: $ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0116] (rev 09) 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04) 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) 5 LPIC 1 Version 5 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 05) [........] Vemos que cada dispositivo tiene un id único. El formato es: [código] -> [dispositivo:fabricante]. Esta información la extrae del fichero /usr/share/misc/pci.ids y se puede actualizar con el comando update-pciids Dispositivos USB En Linux hay diferentes drivers o controladores USB con nombres como UHCI, OHCI, EHCI o R8A66597. La mayoría de sistemas operativos Linux modernos vienen con los drivers USB ya cargados y la gestión de dispositivos USB es automática. Algunos controladores son solo para la versión 1.1 de USB, pero la mayoría también soportan 2.0. Hay que tener en cuenta que una cosa es el bus de comunicación USB y otro el dispositivo que hay conecta, de tal manera que pueden ser necesarios otros drivers o aplicaciones para los usos concretos de cada dispositivo (impresoras, scanners, cámaras digitales…). Si con dispositivo PCI tenemos el comando lspci con USB disponemos del comando lsusb que nos muestra los dispositivos USB que tenemos conectados: $ lsusb Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 007 Device 002: ID 03f0:0324 Hewlett-Packard Bus 007 Device 003: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub [........] Antes se gestionaban con las utilidades usbmgr, hotplug, udev…. Desde los kernels 2.6 no es necesario, puesto que integra hotplug y utiliza udev Sistemas de ficheros especiales /sys Sysfs es un sistema de ficheros virtual (solamente existe en RAM) proporcionado por el núcleo del sistema desde la versión 2.6 (año 2003). Sysfs exporta información sobre los dispositivos y sus controladores (drivers) desde el espacio de sistema del núcleo al espacio de usuario. Sysfs apareció durante el desarrollo del núcleo 2.5 (las ramas impares siempre son las de pruebas) con la intención de solucionar los siguientes problemas: ➢ Falta de un método unificado para representar las relaciones entre los controladores y los dispositivos de hardware. ➢ Faltaba un mecanismo de soporte hotplug estándar ➢ procfs estaba pleno de información que no estaba relacionada con los procesos. Muchas aplicaciones dependen de sysfs para funcionar (p. ej. udev o HAL). Utilizan este sistema de ficheros virtual para acceder a información del hardware y de los controladores 6 LPIC 1 Version 5 del hardware (normalmente módulos del núcleo). En la estructura de la carpeta /sys los directorios organizan los dispositivos, las clases, los buses, los controladores etc. y también establecen las relaciones entre ellos. Los ficheros contienen atributos (cada fichero un atributo). Carpetas principales: /sys/devices: Contiene la información de los dispositivos. La mayoría de ficheros del resto de directorios son enlaces simbólicos que apuntan aquí. /sys/bus: Información de los buses de comunicaciones (USB, PCI….) Los drivers están en /sys/bus/pci/drivers /sys/block: Dispositivos de bloque. Son enlaces simbólicos a ficheros de la carpeta /sys/devices /sys/class: muestra los dispositivos agrupados por clases (red, sonido, impresoras….) /proc procfs es un sistema de ficheros virtual, generado dinámicamente durante el arranque de sistema y almacenado en RAM. Contiene la información de los procesos proporcionada por el núcleo de Linux. Actualmente, además de procesos, contiene información sobre el hardware. Muchas aplicaciones de espacio de usuario se basan en /proc para acceder a la información del núcleo del sistema. Ejemplos: /proc/interrupts /proc/dma /proc/ioports En procfs, cada proceso tiene una carpeta propia, llamados por su PID. En ella contiene información detallada sobre cada uno de ellos. La herramienta sysctl permite modificar los parámetros del kernel sin necesidad de recompilar. Los parámetros se encuentran en forma de ficheros, en /proc/sys. Se puede consultar un listado de todos los parámetros con \$sysctl -a /dev (/dev ha cambiado mucho y /udev ha cogido mucho protagonismo con sytemd, hay q comprobar si este texto esta algo desfasado) Device file system permite al software interactuar con los dispositivos hardware utilizando las mismas llamadas de sistema que se utilizarían para trabajar con ficheros. Hacen de interfaz con los controladores de los dispositivos. Los ficheros pueden ser: ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ Periféricos, como impresoras Dispositivos de almacenamiento Particiones Dispositivos especiales (generadores de números aleatorios, ceros….) Existen tres tipos especiales de dispositivo: Dispositivos de caracteres: les llega el flujo de datos de caracter en caracter. (ttys) Dispositivos de bloque: les llega el flujo de datos en bloques. Soportan acceso aleatorio a los datos. (hds) Pseudo-dispositivos: no corresponden a ningún hardware específico. /dev/null: Acepta todo tipo de datos de entrada y los descarta. No produce ninguna salida /dev/full: Dispositivo que siempre está lleno 7 LPIC 1 Version 5 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ /dev/loop: Dispositivo de bucle. En mi Debian 9.6 aparece solo dev/loop-control /dev/zero: Produce un flujo de datos continuo de caracteres NULL (cero /dev/random: Produce un flujo de datos de números aleatorios. Bloquea /dev/urandom: Produce un flujo de datos de números aleatorios. No bloquea. Convención de nombres: fb: frame buffer fd: disquete hd: disco duro lp: impresora ttyUSB: conversor serie-usb ttyS: controlador del puerto serie parport,pp: puerto paralelo pt: pseudo terminales sd: controlador de dispositivo de almacenamiento masivo. sda: primer dispositivo registrado. sda1: primera partición del primer dispositivo registrado sg: controlador SCSI genérico sr: controlador ROM (dispositivos ópticos) st: controlador de cintas magnéticas tty: consolas virtuales Añadida cobertura de UEFI (igual a la cobertura de la BIOS) y journalctl (con respecto a los eventos de arranque) 101.2 Arranque del sistema 8 LPIC 1 Version 5 Importancia 3 Descripción Los candidatos deberán ser capaces de guiar el sistema a lo largo del proceso de arranque. Áreas de conocimiento clave: ● 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. Lista parcial de los archivos, términos y utilidades utilizados: ● dmesg ● journalctl ● BIOS ● UEFI ● bootloader ● kernel ● initramfs ● init ● SysVinit ● systemd FUENTE: Alberto https://nebul4ck.wordpress.com/lpic-1-capitulo-1/ Inicializar sistemas Linux: SysV, Upstart y systemd FIRMWARE: BIOS y EFI (UEFI) Antes de hablar de los cargadores de arranque es necesario hablar de dos de los firmware mas usados en equipos x86-64, estos son BIOS (Basic Input/Output System) y EFI (Extensible Firmware Interface) o su versión posterior UEFI (Unified EFI). De una u otra forma, el firmware de su ordenador lee el cargador de arranque en memoria desde el disco duro y lo ejecuta. Por su parte, el cargador de arranque se encarga de cargar el kernel de Linux en memoria y lo empieza a ejecutar, por tanto, la configuración del cargador de arranque en el disco es clave para que el firmware pueda localizarlo y comenzar con el proceso de inicio del sistema. Nota: Las distribuciones Linux ofrecen métodos semiautomáticos para configurar un cargador de arranque durante la instalación del sistema, aunque puede que necesite saber 9 LPIC 1 Version 5 mas, en especial si recompila su kernel o tiene que configurar opciones avanzadas, por ejemplo para seleccionar diferentes OS. A la secuencia completa de arranque de un sistema (es decir la delegación de BIOS en el cargador de arranque y de este en el kernel del OS) se le conoce como B ootstrapping o Bootstrap Loader. Tabla de los 2 principales firmware y sus cargadores de arranque: Nota: Se puede usar una tabla de particiones GPT en sistemas con firmware B IOS, en cuyo caso G RUB se almacena parcialmente en una partición especial conocida como partición de arranque B IOS. BIOS BIOS (Basic Input/Output System): Firmware instalado en memoria ROM (EEPROM) o memoria Flash de la placa base de un ordenador, encargado de realizar una serie de pruebas e inicios 10 LPIC 1 Version 5 (Power-On Self-Test,POST) como la cantidad de RAM presente, los dispositivos PCI, periféricos, etc… Existen dos tipos de arranque, el arranque en frio (el ordenador se encuentra apagado) y el arranque en caliente (tenemos el ordenador encendido). La diferencia es que si arrancamos en caliente (Ctrl+Alt+Spr, botón de reset/reinicio) la BIOS salta la tarea de POST, por el contrario el arranque en frio hace que la BIOS siga su curso de chequeo e inicialización. Una vez realizada la tarea POST, si todo ha ido bien sonará un “bip” (en ordenadores mas antiguos, indicando que todo está OK) y la BIOS leerá desde el M BR (sector de arranque especial situado en los primeros 5 12 bytes del primer disco duro) la tabla de particiones. Podemos indicar mediante el menú de BIOS que el disco de arranque sea una unidad USB, un disco flexible, una unidad de CD-ROM, uno u otro disco rígido, etc… El M BR contiene la tabla de partición (16 bytes por cada partición, con un máximo de cuatro), un centinela (0xAA55) y el código ensamblador (Master Boot Code, de 446 bytes), leído por la BIOS para continuar con el proceso de arranque. Este código (cargador de arranque principal) busca en la tabla de particiones aquella partición que está marcada como activa, lee de su sector de arranque y ejecuta el cargador de arranque “secundario” para que continué con el inicio del sistema (fase 1). Dependiendo del tamaño del cargador de arranque, se instalará en el mismo M BR o bien en una partición de arranque (/boot), que será la partición activa. De estar instalado en el M BR se pasará a fase 2, fase en la que se delega la carga del OS al cargador de arranque principal, finalizando así el inicio mediante BIOS, por el contrario de existir un cargador de arranque “secundario” se delegará a este el arranque (fase intermedia o fase 1.5). Nota: Tener el cargador de arranque en el MBR tiene varias desventajas por ejemplo que el tamaño es limitado, o que si instala un OS Windows después de un OS Linux, este escribirá en el M BR por lo que machacará el cargador de arranque Linux. Si es necesario una fase intermedia o fase 1.5, es porque GRUB está dividido en 2 partes; por un lado boot.img, imagen que se instala en el M BR para aprovechar los servicios de la B IOS y que será la encargada de cargar una nueva imagen con mas funcionalidades (core.img) que se encuentra instalada en / boot. BIOS no tiene soporte para leer filesystems por lo que boot.img necesitará saber en que sectores se encuentra la partición activa para poder leer c ore.img, junto a los módulos y archivos de configuración de G RUB. Con esto se permite la lectura de cilindros por encima del 1024 y unidades de tipo LBA. En fase 2 se mostrará el menú de GRUB en el que se nos permitirá iniciar desde uno u otro sistema. Ya es GRUB el encargado de localizar la partición en la que se encuentra dicho sistema. 11 LPIC 1 Version 5 Nota: Si tenemos un esquema como este, es decir b oot.img en M BR y el resto del contenido de G RUB en una partición por ejemplo /boot, puede ocurrir que al instalar Windows después de Linux, este escriba en el MBR e invalide el arranque de Linux. Podremos solucionar esto con FDISK de DOS, marcando como activa la partición /boot, para que en el próximo arranque se nos muestre el menú de selección de los diferentes OS. Existen distintos cargadores de arranque compatibles con B IOS. De los cargadores de arranque hablaremos una vez tengamos entendido el funcionamiento de los principales firmware, así como la compatibilidad y uso de las tabla de particiones que hacen cada uno de ellos. Algunos de los cargadores de arranque compatibles con BIOS son: ● GRUB Legacy ● GRUB ● LILO (obsoleto, lo quitare) ● NeoGRUB (ni idea de q es) ● SYSLINUX Particiones de tipo MBR: El sistema de particiones M BR está limitado a particiones de 2 tebibytes (1 TiB = 2^40 bytes), al menos si se utiliza el tamaño de sector universal de 512 bytes. M BR utiliza tres tipos de particiones: p articiones primarias, p artición extendida (solo puede haber una y sirve de contenedor para las particiones lógicas) y p articiones lógicas (estas se incluyen dentro de la partición extendida). No existe diferencia de rendimiento entre particiones primarias y particiones lógicas. Nota: Sistemas como D OS, Windows y F reeBSD necesitan arrancar desde una partición primaria. Linux, aunque siendo una práctica inusual, puede arrancar desde particiones lógicas. Para las particiones principales (primarias y extendidas) la numeración va desde sda1 a sda4, mientras que para las lógicas se usa del 5 en adelante. Pueden existir huecos entre las particiones primarias pero no en las lógicas, es decir, puede existir sda1, sda3, sda5, sda6 y sda7, pero no sda1, sda4, sda5, sda8 (si existe sda8, tiene que existir sda6 y sda7 Truco: Podemos crear copias de seguridad de nuestra tabla de particiones, de una forma sencilla (aunque existes otros métodos, de momentos vamos a quedarnos con este: # sfdisk -d /dev/sda > /ruta/donde/guardar/sda-backup.txt Podemos guardar esta copia en un USB y a continuación restaurarlo de la siguiente manera: # sfdisk -f /dev/sda < /ruta/del/backup/sda-backup.txt Las particiones MBR usan números hexadecimales de dos dígitos, de uno o dos bytes, para identificarlas. Alguno de los códigos mas habituales son: ● FAT: 0x0c ● NTFS: 0x07 ● Sistema de archivos Linux: 0x83 ● Intercambio de Linux: 0x82 ● Partición extendida: 0x0f El M BR está siendo reemplazado por la G UID Partition Table (GPT), ya que esta no puede superar los discos de 2TiB 12 LPIC 1 Version 5 EFI EFI (Extensible Firmware Interface, propiedad de Intel) o UEFI (Unified Extensible Firmware Interface, Alianza de varias compañías líderes en tecnología: AMD, HP, IBM, Intel, Dell, Apple…) Desarrollada por I ntel para reemplazar al MBR de IBM. U EFI es la versión mejorada de EFI. Algunas mejoras son el cifrado, la autenticación de red, la interfaz de usuario,etc… EFI hereda las nuevas características avanzadas de BIOS como ACPI (Interfaz Avanzada de Configuración y Energía) y el SMBIOS (Sistema de Gestión de BIOS) además, cabe destacar la capacidad de arranque desde unidades de almacenamiento grandes, arquitectura y controladores de la CPU independientes, diseño modular, etc. EFI permite el arranque tanto desde el M BR como desde GPT, el cual solventa las limitaciones técnicas de MBR. EFI posee su propio gestor de arranque minimalista que permite también la selección y carga directa del OS, eliminando la necesidad de recurrir a gestores de arranque externos. El nuevo firmware EFI es mucho mas complejo que la antigua B IOS, en lugar de recurrir a código almacenado en sectores de arranque del disco duro, EFI recurre a cargadores de arranque almacenados como archivos en una partición del disco, denominada E SP (EFI System Partition) que usa el sistema de archivos F AT. En Linux el E SP se suele montar en / boot/efi. Los cargadores de arranque residen en archivos con la extensión . efi en subdirectorios que reciben el nombre del OS o del cargador de arranque (/boot/efi/EFI/ubuntu/grub.efi). Esta configuración le permite almacenar un cargador de arranque independiente para cada SO que instale en el equipo. El firmware EFI incluye su propio programa, un administrador de arranque, para que pueda seleccionar el cargador de arranque secundario con el que iniciar un determinado OS. EFI debe de conocer los cargadores de arranque instalados en el E SP, para ello se suelen registrar los cargadores en el firmware, bien mediante una interfaz de usuario del propio firmware o con una herramienta como el programa efibootmgr de Linux. Nota: Muchas implementaciones E FI de x86-64 usan el cargador de arranque EFI/boot/bootx64.efi del ESP como predeterminado si no hay otros registrados. Resumen sobre firmware: Para arrancar un sistema, la B IOS accede a un dispositivo configurado para ser el primero en detectar y lee el primer sector, en dicho sector se encuentra el MBR el cual contiene la tabla de particiones y el gestor de arranque, que será el encargado de continuar el arranque del OS. Si el administrador de arranque tiene un tamaño considerable, puede que este esté instalado en una partición primaria marcada como activa (por ejemplo /boot) y en cuyo sector de arranque se encuentra este administrador, quien 13 LPIC 1 Version 5 cargará el kernel del sistema. En cambio, E FI lee un archivo de cargador de arranque que se encuentra en una partición especial del sistema de archivos ESP (EFI System Partition, Sistema de partición EFI) formateada normalmente con FAT. EFI ofrece una amplia variedad de opciones de arranque como arrancar desde distintos dispositivos a arrancar desde determinados sectores de arranque de otros disco del equipo. Los equipos con BIOS permiten un máximo de 4 particiones primarias (o 3 primarias y una extendida en la que crear mas particiones lógicas) y EFI nos permite hasta un máximo de 128 particiones (x86_64) todas primarias. Configurar UEFI con efibootmgr Como comentamos anteriormente UEFI posee un gestor de arranque minimalista mediante el cual podremos añadir entradas de arranque en la placa base (siempre y cuando esta y sus implementaciones no lo permitan) usando el comando e fibootmgr. efibootmgr requiere que el kernel tenga soporte para acceder a las variables no volátiles de EFI ( /proc/efi/vars en kernels 2.4 y / sys/firmware/efi/vars en kernels 2.6). Podemos ayudarnos de l smod |grep efivars y modprobe para comprobar el soporte. Primero vamos a comprobar que el soporte para las variables de UEFI en el kernel funcionan correctamente: # efivar -l Si todo ha ido OK y efivar nos ha enumerado las variables, creamos la entrada de arranque: # efibootmgr -c -d /dev/sdX -p Y -l /EFI/refind/refind_x64.efi -L "label_de_entrada" Podemos verificar la entrada con: # efibootmgr -v Nos devolverá un número por cada entrada. Utilice estos números para ordenar las entradas con el comando: # efibootmgr -o <num_entrada>,<otra_entrada>,<etc...> Advertencia: Algunas combinaciones de kernel y efibootmgr podrían negarse a crear nuevas entradas de inicio. Esto podría ser debido a la falta de espacio libre en la memoria NVRAM. Podría tratar de eliminar cualquier archivo de volcado de EFI: # rm /sys/firmware/efi/efivars/dump-* Podemos encontrar documentación extra, en caso de tener problemas con los requisitos del kernel por ejemplo en: http://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface_%28Espa%C3%B1 ol%29#efibootmgr http://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface_%28Espa%C3%B1 ol%29#Requisitos_del_soporte_de_las_variables_UEFI_para_que_funcione_correctamente PROCESO DE ARRANQUE 14 LPIC 1 Version 5 Los pasos que sigue un ordenador para arrancar un sistema operativo son los siguientes: 1. Se enciende el sistema y un circuito de hardware especial hace que la CPU busque y ejecute el firmware (BIOS o UEFI). 2. El firmware realiza tareas de comprobación del hardware, de configuración (POST) y por último si todo va bien, busca el cargador de arranque. 3. Cuando el control pasa del firmware al cargador de arranque carga un kernel o enlaza la carga de otro cargador de arranque. kernel: Es el núcleo de un sistema operativo. Funciona en un nivel bajo (kernelspace) que interactúa entre el hardware de la máquina y los programas que utilizan los recursos del hardware para funcionar. Para hacer un uso eficiente de la CPU, el kernel utiliza un sistema de programación para arbitrar qué tareas tienen prioridad en un momento dado, creando la ilusión (para la percepción humana) de que varias tareas se están ejecutando simultáneamente. 4. Cuando el kernel de Linux toma el control, este descomprime la imagen initramfs (sistema de archivos RAM inicial), que se convierte en el sistema de ficheros root inicial, y comienza la carga de dispositivos, monta la partición raíz y por último carga y ejecuta el programa inicial de su sistema (por defecto /etc/init). initram o RAM inicial: El propósito de initramfs es arrancar el sistema hasta el punto donde se puede acceder al sistema de archivos raíz, esto significa que los módulos que se requieren para dispositivos como IDE, SCSI, SATA, USB, etc… deben ser cargados desde initramfs si no están compilados en el kernel. Una vez que los módulos necesarios se cargan (ya sea de forma explícita a través de un programa o script, o implícitamente a través de udev), el proceso de arranque continúa. Nota: initramfs sólo debe contener los módulos necesarios para acceder al sistema de archivos raíz, no tiene por qué contener todos los módulos que sirven al completo funcionamiento de la máquina. La mayoría de los módulos se cargarán más tarde por udev, durante la fase init. 5. El programa inicial recibe el ID de proceso 1 (PID1) que es el primer programa que se ejecuta en el sistema de arranque tradicional de Linux. /sbin/init lee el archivo /etc/inittab para determinar que otros programas ejecutar. En sistemas que utilicen Upstart o systemd, /sbin/init lee otros archivos de configuración e incluso su nombre se ve reemplazado como es el caso para systemd donde init pasa a ser systemd init lanza las getty, una para cada terminal virtual (normalmente seis de ellas), las cuales inicializan cada tty pidiendo el nombre de usuario y contraseña. Una vez que se proporcionan el nombre de usuario y la contraseña, getty los compara con las que se encuentran en /etc/passwd, llamando a continuación al programa login, para que, una vez iniciada la sesión de usuario, lance la shell de usuario de acuerdo con lo definido en /etc/passwd. Alternativamente, getty puede iniciar directamente un gestor de pantallas si existe uno presente en el sistema, de haberlo este se ejecutará en la tty configurada, reemplazando el prompt de inicio de la getty. Proceso de arranque: http://es.wikipedia.org/wiki/Registro_de_arranque_principal 15 LPIC 1 Version 5 http://es.wikipedia.org/wiki/Proceso_de_arranque_en_Linux http://es.wikipedia.org/wiki/Arranque_%28inform%C3%A1tica%29 Una vez que el kernel es cargado: https://wiki.archlinux.org/index.php/Arch_boot_process_%28Espa%C3%B1ol%29#Tipos_de_firmware Initramfs: https://wiki.archlinux.org/index.php/Mkinitcpio_%28Espa%C3%B1ol%29 101.3 Cambiar los niveles de ejecución / objetivos de arranque y apagar o reiniciar el sistema Importancia 3 16 LPIC 1 Version 5 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. Áreas de conocimiento clave: ● 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. Lista parcial de los archivos, términos y utilidades utilizados: ● /etc/inittab ● shutdown ● init ● /etc/init.d/ ● telinit ● systemd ● systemctl ● /etc/systemd/ ● /usr/lib/systemd/ ● wall SISTEMA DE INICIALIZACIÓN SYSTEM V (SysV) Linux se basa en modos de ejecución para determinar que funciones hay disponibles, enumerados del 0 al 6. Cada uno de ellos tiene asignado un conjunto de servicios. 17 LPIC 1 Version 5 Los modos de ejecución 0,1 y 6 están reservados para fines especiales; los modos de ejecución restantes están disponible para los objetivos que desee o los que decidan los proveedores de las distintas distribuciones Linux. Nota: Puede haber modos de ejecuciones fuera del rango 0-6, pero es algo poco habitual. Es importante saber cuales son estas funciones y cómo gestionar los modos de ejecución para poder controlar el proceso de arranque de Linux y las operaciones en curso. Para ello se debe conocer la finalidad de cada modo de ejecución, identificar los servicios activos en cada uno de ellos, gestionarlos, revisar sus modos de ejecución actuales y poder cambiarlos si fuese necesario. Funciones de los modos de ejecución El archivo /etc/inittab define y describe los distintos modos de ejecución. ■ ■ ■ ■ ■ ■ ■ 0 : Se emplea para apagar el sistema. Es un modo transitorio, es decir se emplea para pasar de un estado a otro. En este caso de iniciado a cerrado. En equipos con hardware moderno el sistema se apaga por completo, no así en equipos mas antiguos donde tiene que intervenir el usuario. 1 : Modo monousuario, también representado por s, S o single. Se suele emplear para realizar un mantenimiento a bajo nivel, como por ejemplo el redimensionamiento de particiones, configuración del servidor X, etc… 2 : En Debian y sus derivados es un modo multiusuario completo con X en ejecución. Muchas otras distribuciones dejan este modo de ejecución sin definir. 3 : Para una gran mayoría de distribuciones como Red Hat o sus derivados, se define este modo como un modo multiusuario mediante terminal 4 : Disponible para configuraciones personalizadas 5 : En Fedora, Mandriva, Red Hat y la mayoría de las demás distribuciones tienen el mismo comportamiento que el modo 3 pero con servidor X. 6 : Se emplea para reiniciar el sistema. Al igual que el modo 0, este es un modo transitorio, donde el ordenador se apaga por completo y vuelve a iniciar. Si configura su sistema con los modos 0 y 6 su sistema se apagará o reiniciará en cuanto termine el proceso de arranque. En la mayoría de distribuciones, lo normal es tener el sistema configurado para que arranque en el modo de ejecución 2,3 o 5. Nota: Las distribuciones que usan sistemas de inicio mas moderno (Upstart o systemd) no suelen utilizar modos de ejecución de forma nativa, pero ofrecen herramientras de compatibilidad que hacen que parezca que el ordenador los usa. Identificar los servicios de un modo de ejecución. Existen varias maneras de identificar que programas se ejecutan cuando se pasa a un modo de ejecución concreto con SysV, como por ejemplo a través del archivo /etc/inittab o bien con la herramienta chkconfig. Con la herramienta update-rc.d podremos activar y desactivar servicios para 18 LPIC 1 Version 5 runlevels específicos. Tenemos detallada estas dos herramientas en el apartado de comandos de este mismo capítulo. Nota: Para identificar programas que son ejecutados en un determinado modo de ejecución, existe una forma más rudimentaria que es localizar el directorio del modo de ejecución concreto y listar su contenido. En el listado aparecerán los enlaces simbólicos hacia scripts principales de los programas que serán ejecutados en ese modo. Esto lo veremos más adelante cuando estudiemos los scripts de inicio SysV Para identificar o definir programas para un cierto modo de ejecución mediante el archivo /etc/inittab, antes tendremos que conocer su estructura. Las entradas de /etc/inittab siguen un formato sencillo: id:modosdeejecución:acción:proceso Donde: ■ ■ ■ ■ id es una secuencia de uno a cuatro caracteres que identifica su función Modos de ejecución es una lista de los modos de ejecución para los que se aplicará la entrada. Puede definirse un solo modo (por ejemplo 3) o varios de ellos (2,3,5) acción indica a init cómo tratar el proceso. Por ejemplo: wait inicia el proceso una vez cuando pase a un modo de ejecución y espera a que este finalice, respawn reinicia el proceso cada vez que finalice, powerwait i ndica a init que apague el sistema antes una falla en el sistema eléctrico (se precisa un UPS), ctr alt del r einicia el sistema cuando el usuario presione esas teclas (podemos cambiar las funciones o anularlas), sysinit comando ejecutado cuando inicia el sistema (por ejemplo limpiar /tmp), etc… podremos conocer mas acciones a través de man inittab. Para la acción initdefault se ignora el campo proceso. proceso es el proceso que ejecutar para una determinada entrada, incluyendo las opciones y argumentos que sean necesarios. Una vez entendida la estructura del archivo /etc/inittab podremos saber como introducir nuevas entradas para nuevos procesos o eliminar en caso de que no queramos que un programa sea ejecutado en un determinado modo. Antes de comentar la segunda forma de identificar programas ejecutados en un determinado modo de ejecución vamos hablar sobre los scripts de inicio Sysv. El script /etc/init.d/rc o /etc/rc.d/rc realiza la tarea crucial de ejecutar todos los scripts asociados con el modo de ejecución. Estos scripts se encuentran almacenados en /etc/rc.d/rc?.d, /etc/init.d/rc?.d, /etc/rc?.d o en ubicaciones similares, donde ? es el modo de ejecución. Cuando se pasa a un determinado modo de ejecución, rc le pasa el parámetro start a todos los scripts que se encuentran dentro del directorio del modo especificado cuyos nombres comienzan con S y el parámetro stop a los archivos cuyo nombre comienza con K. El programa rc ejecuta los scripts en orden numérico debido a que algunos servicios dependen de otros, es por esto que los nombres de los scripts además de empezar por S o K tienen un número. En realidad estos scripts no son más que enlaces simbólicos a los scripts principales que se suelen almacenar en /etc/rc.d, /etc/init.d o /etc/rc.d/init.d (la ubicación depende de la distribución). 19 LPIC 1 Version 5 Sabiendo esto podremos determinar qué servicios están activos o se pararán, en un modo de ejecución específico, buscando los scripts cuyos nombres de archivos comiencen por S o por K en el directorio de scripts de inicio SysV apropiado. También podemos usar la herramienta chkconfig de la siguiente manera: # chkconfig --list O si estamos interesado en un servicio concreto: # chkconfig --list <servicio> Gestionar los servicios de los modos de ejecución Al igual que existen dos formas para identificar servicios en un determinado modo de ejecución (o 3 si separamos el uso de chkconfig y la búsqueda de scripts por sus directorios) podemos gestionar los programas para que sean ejecutados o parados según el modo de ejecución de la misma manera. Mediante el archivo /etc/inittab: Bastará con añadir o eliminar entradas del archivo Con chkconfig: Modificar los modos de ejecución para un determinado servicio # chkconfig --level 235 <servicio> on|off|reset Nota: Con reset le asignaremos su valor por defecto Si hemos añadido un script de inicio al directorio principal de los scripts (/etc/init.d, por ejemplo) podemos hacer que chkconfig lo registre y añada los enlaces de inicio y fin apropiados en los directorios de modo de ejecución adecuados. # chkconfig --add <servicio> Cuando lo hagamos, chkconfig inspeccionará el script en busca de comentarios especiales para indicar los modos de ejecución por defecto. Puede que este método no funcione si el script carece de las líneas de comentario necesarias con los números de secuencia de los modos de ejecución que utiliza chkconfig. Podemos hacer este trabajo de forma manual que sería creando nosotros mismos el enlace simbólico del script principal en los directorios de los modos de ejecución en los que queremos que se inicie o detenga un programa concreto. Tenemos que tener en mente los nombres de archivos con S, K y los números de orden. Importante: Podemos iniciar, detener o comprobar el estado de los servicios mediante la ejecución del comando ‘service‘: # service samba status|start|stop o con la ejecución del script principal # /etc/init.d/samba status|start|stop Existe la herramienta ntsysv la cual nos permitirá marcar aquellos servicios que queremos ejecutar durante el arranque. Es una herramienta ‘gráfica’ de línea de comandos, su uso es sencillo y puede 20 LPIC 1 Version 5 resultar útil incluso para ver que servicios tenemos marcados en el arranque. También puede ser usada para especificar un runlevel concreto. Comprobar y cambiar el modo de ejecución Podemos comprobar el modo de ejecución por defecto y el modo de ejecución actual. Para comprobar el modo de ejecución por defecto basta con desplegar el contenido del archivo /etc/inittab y localizar la entrada que contiene como acción :initdefault:, esto no suele ser válido para equipos que usen Upstart, systemd u otra herramienta de inicialización. Si por el contrario el sistema está en funcionamiento, puede ver su modo de ejecución actual como el comando runlevel: # runlevel N2 El primer caracter es el modo de ejecución anterior, en este caso N, lo cual indica que el sistema no ha cambiado de modo de ejecución desde el arranque. El segundo carácter 2 es su modo de ejecución actual. Se puede cambiar a modos de ejecución diferentes en un sistema operativo en funcionamiento con los programas init (o telinit), shutdown, halt, reboot y poweroff. Por ejemplo para cambiar al modo monousuario o reiniciar el sistema podemos usar: # init 1 o # init 6 (respectivamente) init no es el comando mas lógico para reiniciar, apagar o pasar a modo monousuario, ya que lo hace de forma inmediata y podríamos molestar a otros usuarios conectados al sistema, pero si que sirve por ejemplo para que el sistema vuelva a leer el archivo /etc/inittab El comando telinit es una variante de init, normalmente es un enlace simbólico aunque la páginas man de ambos comandos presentan una sintaxis ligeramente distinta. Si quisieramos por ejemplo que se volviese a leer el archivo /etc/inittab, podriamos usar telinit o init de la siguiente manera: # telinit q # telinit Q Nota: Las herramientas Upstart y systemd ofrecen los comandos init y telinit que funcionan de una forma similar. Cuando desee reiniciar (6), apagar (0) o pasar a modo monousuario (1) en un entorno multiusuario, lo mejor será emplear el comando shutdown. Pasar a modo monousuario de forma inmediata: # shutdown now Reiniciar el sistema en 5 minutos # shutdown -r +5 Apagar el sistema a las 13:45 # shutdown -P 13:45 21 LPIC 1 Version 5 Suspender el equipo (no lo apaga) a las 1:30 AM avisando a los usuarios. #shutdown -H 1:30 "A las 1:30 de la madrugada el sistema va a ser detenido" Nota: La opción -h puede detener o apagar el equipo, aunque normalmente acaba apagándolo. Detener el apagado de un equipo por un cambio de ultima hora (por ejemplo): # shutdown -c "Se pospone el reinicio del sistema, se avisará nuevamente. Disculpen" Nota: Upstart y systemd ofrecen la herramienta shutdown Otros tres comandos útiles para detener, reiniciar o apagar el sistema respectivamente tanto en SysV, Upstart como con systemd son: halt, reboot y poweroff SISTEMA DE INICIALIZACIÓN UPSTART Básicamente, Upstart hace lo mismo que las secuencias de comandos Sysvinit (SysV) pero está mejor diseñado para admitir el hardware actual y su continuo dinamismo, lo que permite conectarlo y desconectarlo de un ordenador en ejecución. Mientras SysV trabaja de una forma síncrona, el modelo basado en eventos de Upstart le permite responder a los eventos de una forma asíncrona cuando estos son generado, resolviendo así alguno de los problemas que presenta SysV, como el bloqueo de futuras tareas hasta que la actual se haya completado. Para sistemas con Upstart el PID 1 sigue siendo para init, padre de todos los procesos en el sistema (incluso de los procesos huérfanos) y responsable de iniciar el resto de procesos. Upstart ofrece funciones compatibles con SysV, no obstante también cuenta con sus propios scripts y difiere en algunos aspectos importantes, en concreto Upstart ignora el archivo /etc/inittab, en su lugar proporciona un conjunto integrado de scripts de arranque que en principio pueden reemplazar totalmente a /etc/inittab y a los scripts de arranque específico del modo de ejecución de SysV, que en vez de encontrarse bajo directorios como /etc/init.d/rc?.d, /etc/rc.d/rc?.d o /etc/rc?.d se encuentran en el directorio /etc/init, con nombre ‘servicio’.conf, donde servicio es el programa que init tratará como un job. Los scripts de Upstart ofrecen mas acciones que los de SysV, por ejemplo iniciar un servicio siempre que se conecte un determinado dispositivo de hardware. Al igual que usábamos el comando #service <servicio> start|stop|status para iniciar un script SysV, en Upstart tenemos la opción de utilizar el comando initctl con el que podremos iniciar, parar, ver el estado, etc… de los servicios del sistema o directamente usar start y stop $sudo initctl stop smbd o $sudo stop smbd Nota: Para ver un listado de estos servicios podemos listar el contenido de /etc/init donde se encuentran como ya sabemos todos archivos de configuración de servicios Upstart, por lo que el nombre del servicio es igual a los del directorio pero sin .conf El comando service podremos seguir usándolo para servicios SysV instalados en el sistema. Anteriormente hemos comentado que los scripts de Upstarts ustituyen de forma completa a los scripts de SysV y a su archivo /etc/inittab, pero esto no es del todo cierto ya que Upstart concede en cierto modo la compatibilidad con SysV. Upstart continua ejecutando scripts de SysV (ubicados en los 22 LPIC 1 Version 5 mismos directorios como si de un sistema SysV se tratase) debido a que existen programas que aún no incluyen los scripts de configuración Upstart y necesitan ser arrancado de forma habitual. Si ha instalado utilidades como chkconfig en sistemas que inicializan con Upstart deberá poder usarla para gestionar sus servicios SysV. No obstante chkconfig y estos servicios que aun se mantienen en SysV acabarán desapareciendo debido a que el progreso apunta a Upstart y systemd. Gracias a la API inotify no será necesaria la recarga de un archivo de configuración (archivo con el que se configura un servicio por ejemplo smb.conf) para un determinado servicio, ya que esta proporciona un mecanismo para el seguimiento de eventos del sistema de archivos, lo cual supervisa tanto archivos individuales como directorios, por lo que si se diera el caso de que un archivo a sido modificado este será recargado automáticamente Para cambiar los modos de ejecución en los que se ejecuta un servicio concreto, tendrá que editar su archivo de configuración Upstart( /etc/init/’servicio’.conf), localice el script del servicio que quieres modificar, ábrelo para editar, y encuentre las líneas que contengan el texto start on y stop on. Estos archivos suelen tener un formato similar al siguiente: 23 LPIC 1 Version 5 Vemos la cadena start on y stop on runlevel, seguidas de [2345] y [!2345], en este caso se indica que el servicio ssh se inicie en los modos 2345 y sea detenido para cualquier modo distinto (!) de los indicados, también 2345. Podemos ver cadenas de start on mas complejas en las que se hace uso de mountall, es un demonio propio de Debian y Ubuntu que se encarga de montar los sistemas de ficheros que se especifican en /etc/fstab y /lib/init/fstab, y que además emite una serie de eventos útiles cuando estos son o no montados como por ejemplo: ■ ■ ■ ■ ■ ■ mounting: Emitido cuando un sistema de archivos en particular está a punto de ser montado. mounted: Emitido cuando un sistema de archivos en particular ha sido montado correctamente. all-swaps: Se emite cuando se montan todos los dispositivos de intercambio filesystem: Una vez que todos los sistemas de archivos han sido montados (o intentado) virtual-filesystem: Emitida después de que se haya montado el último sistema de archivos virtual local-filesystem y remote-filesystem: Cuando el último sistema de archivos local o remoto (respectivamente) hayan sido montado Por lo tanto podemos encontrar entradas como esta: Existen situaciones en las que nos interesa que un proceso se restaure automáticamente como por ejemplo en casos de fallos y cierres inesperados del servicio, para ello Upstart (al igual que SysV) ofrece el comando respawn con el que además podemos especificar límites como en el caso de la imagen (respawn 10 5) que viene a significar que si el proceso se reinicia mas de 10 veces en 5 segundos, finalice definitivamente. Nota: Para un proceso, un ‘cierre inesperado’ será siempre que no se detenga con la orden stop, mientras que para una tarea es cuando el código de retorno sea diferente a 0. Se pueden seleccionar secciones del archivo .conf, como por ejemplo en nuestro caso aparece pre-start script que indica que los siguientes comandos sean ejecutados antes de que el servicio sea arrancado 24 LPIC 1 Version 5 Podemos habilitar los trabajos de usuarios para permitir que los usuarios tengan acceso a los métodos y propiedades de Upstart, el archivo para esto es/etc/dbus-1/system.d/Upstart.conf, los trabajos de usuario se encuentran en ~/.init Para ver los comandos que podemos utilizar dentro de un archivo .conf viste la web: http://upstart.ubuntu.com/wiki/Stanzas Para mas información podemos acudir a la siguiente página, donde aprenderemos incluso a crear nuestros propios archivos de configuración de servicios: http://upstart.ubuntu.com/cookbook/ SISTEMA DE INICIALIZACIÓN SYSTEMD Sobre systemd systemd ha sido creado para ofrecer un inicio mas rápido y flexible que SysV, permitiendo el arranque paralelo de servicios y su inicio basado en la detección de conexión de nueva unidad externa. Nota: Hasta ahora el PID1 era para el programa init, cosa que ha cambiado en systemd a favor de /usr/lib/systemd/systemd y además systemd al igual que Upstart deja de utilizar el archivo /etc/inittab Algunas de las mejoras que ofrece systemd: ■ ■ ■ ■ ■ Se ha mejorado sustancialmente la velocidad de inicialización del sistema systemd asume que cualquier dispositivo puede ser conectado o desconectado en cualquier momento (hotplug) systemd utiliza la activación de daemons por medio de sockets, aportando capacidades de paralelización Una de sus características es el registro (journal) mediante cgroups de todos los servicios y procesos iniciados systemd es modular, esto quiere decir que se han elaborado una seríe de “paquetes” en los que varios servicios son administrados de forma conjunta Según definición oficial systemd es: Un sistema y administrador de servicios para Linux, compatible con scripts de inicio (init) SysV y LSB. systemd proporciona capacidades de paralelización agresiva, utiliza socket y activación D-Bus para iniciar los servicios, ofrece la puesta en marcha de demonios bajo demanda, realiza el seguimiento de procesos utilizando Linux cgroups, soporta copia instantánea de volumen y la restauración de estado del sistema, mantiene puntos de montaje y automontaje e implementa un elaborado servicio lógico de control transaccional basado en la dependencia. Vamos a desglosar un poco esta definición: ■ ■ Capacidades de paralelización agresiva usando socket: systemd crea de una misma vez todos los sockets para todos los demonios acelerando así el arranque completo e iniciar más procesos en paralelo. En un segundo paso systemd ejecutará a la vez todos los demonios. Activación D-Bus para iniciar servicios: Utilizando la activación D-Bus, un servicio puede ser iniciado la primera vez que es accedido. 25 LPIC 1 Version 5 ■ Seguimiento de procesos utilizando Linux cgroups: cgroup también llamados grupos de control, es una característica del kernel para crear límites, políticas e incluso explicar el uso de los recursos de ciertos grupos de procesos. cgroup asocia un conjunto de tareas con un conjunto de parámetros, para uno o más subsistemas, proporcionando un control de servicios y tareas, así como todos sus futuros ‘hijos’ en grupos jerárquico. Un subsistema es un módulo resultado de la agrupación de diversas tareas con el fin de mantener un mejor control sobre estas de forma particular. Nota: La herramienta systemd-cgls nos muestra recursivamente el contenido del árbol de jerarquías de un determinado grupo de control de Linux. ■ Mantiene puntos de montaje y automontaje: Puede utilizarse para montar o desmontar los puntos de montaje, quedando /etc/fstab como una fuente de configuración adicional a la que podremos llamar para su supervisión con la opción “comment=” de fstab para marcar las entradas controladas por systemd. Unidades de servicios (units) systemd inicia y supervisa todo el sistema y se basa en la noción de unidades, compuestas de un nombre (el nombre del demonio) y una extensión. Será la extensión la que indique de que tipo de unidad se trata. Además cada unidad tiene su correspondiente archivo de configuración cuyo nombre es idéntico. Un ejemplo sería el servicio httpd.service cuyo archivo de configuración sería httpd.service. Los archivos de unidades disponibles en nuestro sistema podemos encontrarlos en /usr/lib/systemd/system/ y /etc/systemd/system/ Nota: Los archivos bajo el directorio /etc/systemd/system/ prevalecerán en caso de duplicados. Existen siete tipos diferentes de unidades: ■ ■ ■ ■ ■ ■ ■ service: Demonios que pueden ser iniciados, detenidos, reiniciados o recargados. socket: Esta unidad encapsula un socket en el sistema de archivos o en Internet. Cada unidad socket tiene una unidad de servicio correspondiente. device: Esta unidad encapsula un dispositivo en el árbol de dispositivos de Linux. mount: Esta unidad encapsula un punto de montaje en la jerarquía del sistema de archivos. automount: Encapsula un punto de montaje automático. Cada unidad automount tiene una unidad mount correspondiente, que se inicia al acceder al directorio de automontaje. target: Utilizada para la agrupación lógica de unidades. Referencia a otras unidades, que pueden ser controladas conjuntamente, un ejemplo sería multi-user.target, que básicamente desempeña el papel de nivel de ejecución 3 en el sistema clásico SysV. snapshot: Similar a las unidades target. Entonces los archivos de configuración tendrán los nombres: programa.service, socket.socket, dispositivo.device, puntodemontaje.mount, etc… Nota: La unidad default.target activa servicios y otras unidades dependientes, durante el arranque de systemd. Esto lo comentaremos en el apartado target 26 LPIC 1 Version 5 Compatibilidad de systemd con SysV systemd al igual que Upstart ofrece compatibilidad con SysV (comando service y chkconfig) para aquellos servicios que aun soportan o funcionan únicamente con scripts de inicio SysV (actualmente en 2015, son pocos los servicios que corren bajo SysV). Upstart pese a mantener compatibilidad con los comandos service y chkconfig de SysV implementó su propia utilidad para la administración de servicios, de igual modo systemd lo hace con su herramienta systemctl #systemctl stop nombreservicio.service En SysV habilitábamos servicios con chkconfig (o reproducíamos listas de estos para ver cual de ellos se ejecutaba al arranque), algo que ahora bajo systemd podemos hacer con los siguientes comandos: Habilitar el servicio httpd al arranque del sistema (chkconfig httpd on , para SysV): #systemctl enabled httpd.service Listar todas las unidades de servicios instaladas (algo parecido a chkconfig –list) #systemctl list-unit-files O solo aquellas que se encuentran en activadas: #systemctl list-units o #systemctl Podemos apreciar que a la hora de pasar el nombre del servicio lo hacemos con el nombre completo, es decir incluyendo su sufijo, pero existen una serie de atajos: ■ ■ ■ Si no se especifica el sufijo, systemctl asumirá que es .service. Por ejemplo, netcfg y netcfg.service se consideran equivalentes. Los puntos de montaje se traducirán automáticamente en la correspondiente unidad .mount. Por ejemplo, si especifica /home será equivalente a home.mount. Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspondiente unidad .device, por lo tanto, la especificación /dev/sda2 es equivalente a dev-sda2.device. Nota: Consulte man systemd.unit para más detalles. Uso de systemctl La utilidad de administración de las unit de systemd es systemctl, la cual combina las herramientas service y chkconfig de SysV, por lo tanto podremos arrancar, parar, recargar servicios, activar o desactivar servicios en el arranque, listar los estados de los servicios,etc… Creo que con la siguiente tabla veremos el uso básico de systemctl además de sus “iguales” en SysV. 27 LPIC 1 Version 5 1* Puede que un servicio este “enable” pero no tiene porqué estar activo cuando iniciemos sesión ya que puede que ese servicio este configurado para ejecutarse solo en determinados runlevels (o target en nuestro caso), a diferencia de chkconfig –list de SysV que mostraba todos los servicios con todos los runlevels posibles y para cada uno indicaba si estaba on o off. Para conseguir algo parecido en systemd, tendríamos que listar los target disponibles y veríamos que servicios se ubican dentro de estos, así sabremos con que target (o runlevel) un servicio será iniciado. Podemos emplear el siguiente listado #ls /etc/systemd/system/*.wants/httpd.service /etc/systemd/system/multi-user.target.wants/httpd.service Este comando nos devuelve que el servicio httpd se encuentra bajo multi-user.target lo que viene siendo el runlevel 3 de SysV. En los siguientes apartados conoceremos los distintos target que de algún modo tienen similitud con los runlevels de SysV Nota: Podríamos haber omitido el subdirectorio /httpd.service para conocer la lista completa de targets y sus unit (mount, service, socket…) Podemos hacerlo de una forma inversa (para lo cual hay que conocer el target), es decir ver que servicios están ejecutándose para un target concreto: #systemctl show -p “Wants” multi-user.target 28 LPIC 1 Version 5 Además de los comandos de la tabla también podemos ver las units de servicios que tenemos cargados en el sistema con el comando: #systemctl -t service list-units –all Con este comando veremos que servicios están cargados y además si están activos o muertos a parte de una pequeña descripción. Nota: Podemos cambiar service por mount, socket, device… para listar otros tipos (-t) de units. Si en vez de ver las units cargadas queremos ver cuantas hay instaladas (es decir aquellas que tienen archivos de configuración instalados en nuestro sistema y por lo tanto están disponibles): #systemctl -t service list-unit-files –all Nota: Podemos cambiar el tipo de unit o directamente omitir el parámetro -t y listar todas. Aprenderemos mas sobre el comando systemctl en el apartado de comandos para este tema (Tema-5) Sugerencia: Puede utilizar las siguientes órdenes systemctl con el parámetro -H usario@host para controlar una instancia de systemd en una máquina remota. Esto utilizará SSH para conectarse a la instancia systemd remota. Target systemd utiliza target en vez de runlevels (0123456) que reciben un nombre (en vez de un número) para identificar un propósito específico, con la posibilidad de realizar más de una acción al mismo tiempo. Algunos targets pueden heredar todos los servicios de otro target e implementarse con servicios adicionales. La siguiente tabla muestra la similitud entre algunos de los target con los runlevels de SysV: Nota: Actualmente no existen target similares a los runlevels 2 y 4 de SysV, pero podríamos definirlos nosotros mismos. Existen otros target que podremos ver con el comando: #systemctl list-units –type=target Podemos cambiar de target (o modo de ejecución) actual con el comando: 29 LPIC 1 Version 5 # systemctl isolate graphical.target Nota: Esto podría ser equivalente a la orden #telinit 5 de SysV systemd también nos permite cambiar el target predeterminado e incluso añadir nuevos servicios a otros target, pero antes de esto, es importante dejar claro algunos de los directorios de los que hace uso systemd: ■ ■ ■ Los archivos unit (archivos de configuración de service, mount, device…) se encuentran en: /usr/lib/systemd/system/ o /etc/systemd/system/ Los target (runlevels) igualmente pueden situarse en ambos directorios Los directorios *.wants (ubicados igualmente en ambos directorios) contienen los enlaces simbólicos que apuntan a determinados servicios, serán estos servicios los que se ejecuten con el target al que corresponde dicho directorio wants, recordar que si un target precisa de otro, también serán cargados los servicios de este otro target. Nota: Los archivos unit de /etc/systemd/system tienen una mayor precedencia sobre archivos unidad de /lib/systemd/system El target /etc/systemd/system/default.target es el target predeterminado de arranque, es un enlace simbólico que por defecto apunta a /lib/systemd/system/graphical.target por lo que para cambiar de target de arranque, bastará con eliminar dicho link y crear uno nuevo apuntando al nuevo target. Si quisiéramos podríamos crear un target desde 0 a nuestro gusto y darle un nombre (mylevel.target) y a continuación habilitarlo: # systemctl enable mylevel.target El efecto de esta orden crea un enlace simbólico (/etc/systemd/system/default.target) que apunta a nuestro mylevel.target. Esto solo funciona si hemos añadido la etiqueta [Install] al archivo, de la siguiente manera: [Install] Alias=default.target También podemos añadir o quitar nuevos servicios a un target determinado, bastará con crear nuevos enlaces simbólicos dentro del directorio *.wants del target de arranque (o de algunos de los que dependa) apuntando a los servicios deseados. Otra forma de modificar el target de inicio es a través de los parámetros que le pasamos al kernel en el archivo de configuración del gestor de arranque añadiendo por ejemplo systemd.unit=multi-user.target para arrancar en nivel3 Journal journal es un componente mas de systemd, que capta los mensajes syslog, los mensajes de registro del kernel, los del disco RAM inicial y los mensajes de arranque iniciales, así como mensajes escritos en stdout y stderr de todos los servicios, haciendo que estén disponible para el usuario. Se puede utilizar en paralelo, o en lugar de un demonio syslog tradicional, como rsyslog o syslog-ng. 30 LPIC 1 Version 5 Hasta Fedora 18 (e inclusive a día de hoy, Enero del 2015, en Centos7) el registro de journal se almacena de forma volátil en /run/log/journal por lo que será eliminado tras un reinicio. La intención es que venga configurado por defecto de manera que sea un registro persistente y con directorio principal /var/log/journal (que no venga por defecto no quiere decir que no lo podamos configurar de tal modo). Una de las razones por las que syslog comenzaba a quedarse “anticuado” es la necesidad por ejemplo de mostrar las últimas líneas del registro de un determinado servicio en el momento de preguntar por su estado (con systemctl), esto necesita que archivos de registro sean descomprimido en tiempo real y a la vez mostrado, algo que con syslog se hacía casi imposible y además, ineficiente y poco seguro. Nota: Estudiaremos mas sobre los log de registros (syslog, rsyslog, syslog-ng, y journal) en el tema dedicado a tal fin de este mismo libro. Hasta ahora nos haremos la idea de que journal es el sustituto de syslog, el cual nos permite filtrar la salida del registro por campos, dejar el registro de forma volátil o volverlo persistente mediante su archivo de configuración (/etc/systemd/journald.conf), darle un tamaño máximo al fichero de registro, permite la compatibilidad con el antiguo syslog mediante el socket /run/systemd/journal/syslog (tendremos que asociar syslog a este socket y no a /dev/log, el paquete syslog-ng proporciona automáticamente la configuración necesaria), reenviar la salida del registro a una terminal, etc… Solucionar problemas Este apartado lo podemos encontrar igualmente en: https://wiki.archlinux.org/index.php/Systemd_%28Espa%C3%B1ol%29 (Solución de problemas), he creído conveniente introducirlo en el tema para que sirva como ejemplo práctico. Nota: Intenté cambiarlo por un error personal, pero el comando systemctl –state=failed en mi Centos7 solo me proporcionaba el error: rngd.service loaded failed failed Hardware RNG Entropy Gatherer Daemon RGN es un Generador de números aleatorios a partir de un componente hardware, en vez de crearlos mediante software. Al no usar este tipo de software pues evidentamente me da error. (Mira si a alguno de ustedes le ocurre lo mismo, ya llevan 2 problemas solucionados, este y el que se explica a continuación, jeje) 31 LPIC 1 Version 5 Hardware RGN Podría haber creado mi propio problema, pero creo que el ejemplo de la wiki de arch puede ahorrarme un maravilloso tiempo. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Lo primero es comprobar si existen servicios que están fallando en el incio: $systemctl –state=failed systemd-modules-load.service loaded failed failed Load Kernel Modules Vamos a indagar sobre este error. Miraremos su estado. $systemctl status systemd-modules-load systemd-modules-load.service – Load Kernel Modules Loaded: l oaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago Docs: man:systemd-modules-load.service(8). man:modules-load.d(5) Process: 1 5630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE) Tenemos el PID, investiguemos sobre este: $journalctl -b _PID=15630— Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. — Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module ‘blacklist usblp’ Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module ‘install usblp /bin/false’ Este mensaje -> Failed to find module ‘blacklist usblp’ <- la palabra module y blacklist juntas mmmm, vamos a revisar si por casualidad tuviesemos una blacklist configurada… $ ls -Al /etc/modules-load.d/ 32 LPIC 1 Version 5 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. … -rw-r–r– 1 root root 79 1. Ene 2015 blacklist.conf -rw-r–r– 1 root root 1 2. Mar 2014 encrypt.conf -rw-r–r– 1 root root 3 5. Dic 2014 printing.conf … Al abrir el archivo blacklist, encontramos precisamente las líneas ‘blacklist usblp’ y ‘install usblp /bin/false’, por lo que vamos a comentarlas (añadiendo # delante de cada una de ellas) para que no las tenga en cuenta y reiniciaremos el servicio a ver que tal. Si no hay señales de error en el prompt vamos a comprobar cual es su estado: $ systemctl status systemd-modules-load systemd-modules-load.service – Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules. Otra forma de detectar arranques en el inicio es mediante su depuración, para lo que tendremos que añadir los parámetros systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M a la línea del kernel en el gestor de arranque NOTAS: Podremos descargar systemd desde la siguiente página oficial: http://www.freedesktop.org/software/systemd/ o bien consultar su documentación oficial http://freedesktop.org/wiki/Software/systemd/ Puedes ampliar la información aquí dada, e incluso conocer otras funcionalidades o aspectos de systemd como: ■ ■ ■ ■ ■ ■ ■ ■ Características de systemd (ampliadas) Línea de comandos de arranque del Kernel Cambiar el número de gettys por defecto Personalizar un archivo unidad o agregar uno personalizado Inicio de sesión automático en una terminal Implementación readahead (lectura anticipada) Escribir archivos .service personalizados Archivos temporales y temporizadores a través de algunos sitios: https://fedoraproject.org/wiki/Systemd/es https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet/es 33 LPIC 1 Version 5 https://wiki.archlinux.org/index.php/Systemd_%28Espa%C3%B1ol%29 https://wiki.ubuntu.com/SystemdForUpstartUsers https://wiki.archlinux.org/index.php/Systemd Tema 102: Instalación de Linux y gestión de paquetes Añadida la Partición de Sistema EFI (ESP) 102.1 Diseño del esquema de particionado del disco duro duro Importancia 2 Descripción Los candidatos deberán ser capaces de diseñar un esquema de particionado de disco para un sistema Linux. Áreas de conocimiento clave: ● Asignar sistemas de archivos y espacio de intercambio a particiones o discos separados. ● Adaptar el diseño al uso previsto del sistema. ● Asegurar de que la partición /boot cumple los requisitos de la arquitectura de hardware para el arranque. ● Conocimiento de las características básicas de LVM. Lista parcial de archivos, términos y utilidades: ● Sistema de archivos / (raíz) ● Sistema de archivos /var ● Sistema de archivos /home ● Sistema de archivos /boot 34 LPIC 1 Version 5 ● ● ● ● Partición del sistema EFI (ESP) Espacio de intercambio (swap) Puntos de montaje Particiones 102.1 EDITADO POR: I saac Lemus Martin <[email protected]> el dia 7 de febrero de 2019 https://docs.google.com/document/d/1xzcspnC3g81TIGQg2NqNBPbbkuMsKmPrns19doAYkR A/edit?usp=sharing Allocate filesystems and swap space to separate partitions or disks. Los sistemas operativos GNU/Linux funcionan con base en información como son archivos de sistema (librerías, binarios, enlaces simbólicos, archivos de configuración, entre otros) y archivos generados por el usuario (música, documentos de ofimática, videos, entre otros). La información anterior se requiere se quede de manera permanente y no se borre al reiniciar el sistema operativo, para ello se utiliza un dispositivo de almacenamiento dentro del cual se destina espacios físicos o partición, donde se almacena un sistema de archivo que guardara la información, para ser accedida posteriormente por el sistema operativo a través de un punto de montaje. PARTICIONES Los dispositivos de almacenamiento masivos independientemente de su naturaleza física, son administrados de forma lógica por medio de tabla de particiones cuya función principal es administrar las particiones que se generan sobre dispositivo de almacenamiento. Actualmente existen dos tablas de particiones que se puedn utilizar: ● ● MBR GUID MBR La tabla de partición MBR está directamente relacionada con el desarrollo del firmware BIOS, que soporta administrar dispositivos de almacenamiento menores a 2TB y solo permite realizar 4 particiones principales. 35 LPIC 1 Version 5 La tabla de MBR soporta 3 tipos de particiones de manera general: ● ● ● Primarias Extendidas Lógicas Primarias: Son las particiones que se encuentran definidas en los cuatros espacios destinados a las particiones desde el diseño de la MBR y que pueden ser accedidas sin nigun problema por parte del Bios para realizar bootstraping. Extendidas: Es las partición que contiene una extensión de la Tabla de particionamiento MBR , para administrar las particiones lógicas, esta partición fue la solución al problema de administrar volúmenes cada vez más grandes de almacenamiento, para construir esta partición se debe utilizar una de las 4 particiones principales o primarias. Lógicas: Son particiones que se construyen y son administradas por las partriciones extendidas, estas particiones solo tienen como limitante la cantidad de espacio almacenado para la partición extendida y no es necesario usar una de las particiones principales o primarias. GUID La tabla de partición GUID está directamente relacionada con el desarrollo del firmware UEFI, que soporta administrar dispositivos de almacenamiento mayores a 2TB y permite realizar hasta 256 particiones principales o primarias. Entre las ventajas de usar esta tabla de particiones para administrar los discos se encuentra lo siguiente: ● ● Compatibilidad con MBR Backup del registro de las particiones que se han generado A continuación se presenta una imagen comparativa de ambas tablas de particionamiento 36 LPIC 1 Version 5 https://www.softzone.es/app/uploads/2016/03/Comparativa-MBR-GPT.gif 37 LPIC 1 Version 5 SISTEMA DE ARCHIVO Un sistema de archivos son los métodos y estructuras de datos que un sistema operativo utiliza para seguir la pista de los archivos de un disco o partición. http://www.tldp.org/pub/Linux/docs/ldp-archived/system-admin-guide/translations/es/html/ch06s08.htm l Algunas características que se encargan los sistema s de archivos Seguridad o permisos Mecanismo para evitar la fragmentación Capacidad de enlaces simbólicos o duros Integridad del sistema de archivos Soporte para archivos dispersos Soporte para cuotas de discos Soporte de crecimiento del sistema de archivos nativo ● ● ● ● ● ● ● Los sistemas de archivos o filesystems que son soportados actualmente por Linux son: ● ● ● ● ● ● ● ● ● ● ● ● Btrfs xfs ext4 ext3 ext vfat ntfs vmfs exfat sysfs procfs swap 38 LPIC 1 Version 5 PUNTOS DE MONTAJE Los puntos de montaje son puntos de acceso desde el sistema operativo hacia los sistemas de archivos y posteriormente a la información, los puntos de montajes están relacionado con los directorios de sistema operativo. FHS FHS Sistema Jerárquico de Archivos es el estándar que define los directorios principales y sus contenidos en el sistema operativo GNU/Linux y otros sistemas de la familia Unix. Se diseñó originalmente en 1994 para estandarizar el sistema de archivos de las distribuciones de Linux, basándose en la tradicional organización de directorios de los sistemas Unix. https://es.wikipedia.org/wiki/Filesystem_Hierarchy_Standard A continuación se presentan los directorios representativos del sistema operativo 39 LPIC 1 Version 5 Otros directorios importantes que no están reportados en la figura anterior son: /sbin: Directorio de comandos binarios que solo pueden ser ejecutados por el administrador comúnmente root. /root: Directorio de trabajo asociado al superusuario predeterminado por el usuario /var: Directorio de datos variables que crecen con respecto al tiempo, ejemplo de esto los logs del sistema operativo. /tmp: Directorio de sistema operativo donde se almacenan los archivos temporales, por ejempo socket de base de datos mysql o mariadb, datos de navegación de internet o archivos que genera el sistema operático para un proceso. 40 LPIC 1 Version 5 /opt: Directorio de sistema operativo diseñado para instalar sofware de terceros, que son instalados mediante paquetes por separados o repositorios de terceros ejemplo tsm, redhat collection repository y software de IBM. /usr: Directorio especial que se utiliza para mantener la compatibilidad POSIX con sistemas operativos Unix. ● /usr/X11R6 Se encuentran aquí todos los archivos del Sistema X-Windows. Para simplificar el desarrollo y la instalación de X, sus archivos no fueron integrados dentro del resto del sistema. Existe un árbol de directorios bajo /usr/X11R6 similar al que está bajo /usr. ● /usr/bin En este directorio se encuentran la gran mayoría de los comandos para los usuarios. Algunos otros comandos pueden encontrarse en / bin o en / usr/local/bin. ● /usr/sbin Comandos para la administración del sistema que no son necesarios en el sistema de archivos raíz, como por ejemplo la mayoría de los programas que proveen servicios. ● /usr/share/man, / usr/share/info, / usr/share/doc Páginas de manual, documentos de información GNU, y archivos de documentación de los programas instalados. ● /usr/include Archivos cabecera para el lenguaje de programación C. Estos deberían estar de hecho debajo de /usr/lib por coherencia, pero tradicionalmente se ha apoyado de forma mayoritaria esta ubicación. ● /usr/lib Archivos de datos de programas y subsistemas que no sufren cambios, incluyendo algunos archivos de configuración globales. El nombre lib viene de librería; originariamente las librerías de las subrutinas de programación se almacenaban en / usr/lib. ● /usr/local Es la ubicación para el software instalado localmente y para algunos otros archivos. Las distribuciones no deben colocar archivos bajo este directorio. Se reserva para ser utilizado únicamente por el administrador local del sistema. De esta manera, aquel se asegura totalmente de que ninguna actualización de su distribución sobrescribirá el software que él mismo haya instalado localmente http://www.tldp.org/pub/Linux/docs/ldp-archived/system-adminguide/translations/es/html/ch04s05.html /sys: Directorio utilizado por el sistema de archivo sysf donde se exporta la información de los dispositivos externos o periféricos desde el kernel. /proc: es un pseudodirectorio virtual que se genera durante el inicio donde se almacena configuraciones de sistema operativo y procesos que están en memoria. 41 LPIC 1 Version 5 Las distribuciones de Linux populares utilizan actualmente asistentes gráficos o modo texto que proporcionan instalaciones predeterminadas o sencillas, que permiten a los usuarios introducir de manera sencilla y restringidas definir valores para la instalación, pero a su vez limitan la posibilidad de personalizar de manera libre algunos aspectos, como la distribución de sistema de archivos sobre particiones o espacio en disco duros. 42 LPIC 1 Version 5 Cuando se elige las opciones predeterminadas el disk layout o esquema de particionamiento que se aplica es el siguiente Ṕartición Punto de montaje 1 /boot/efi 2 /boot 3 / Descripción Contiene archivos de arranque *.efi Tamaño 1 GB Contiene los archivos necesarios para el 1 GB inicio (arranque) del sistema operativo. Contiene todos los archivos del sistema operativo. 6.5 GB 3 Swap Memoria de intercambio. 815 MB Tabla # Disk layout o esquema de particionamiento al instalar de manera predeterminada El disk layout o esquema de particionamiento anterior es genérico y el utilizar en ambientes productivos o profesionales puede presentar los siguientes riesgos: ● ● ● ● Perdida en la información Complejidad en acciones de restauración Reinstalación de sistema operativo forzosa con respaldo Respaldos completos, dependiendo del tipo de herramienta Para reducir o mitigar riesgos con la información es recomendable separar la información en particiones que estén en el mismo duro o en el mejor de los casos que sean discos independientes, esto inclusive es requerido para cuestiones de seguridad informática. 43 LPIC 1 Version 5 Tailor the design to the intended use of the system. El sistema operativo Linux tiene la capacidad de alojar diferentes servicios como son servidores web, de base de datos, ftps, almacenamiento, directorio activos por mencionar algunos, los cuales requieren administrar espacio y garantizar la integridad de la información. Considerando el esquema de particionamiento o disk layout general y conociendo los riesgos que se asumen se recomienda realizar un diseño de esquema de particionamiento, para ello se recomienda seguir los siguientes pasos: 1.- Seleccionar los directorios que serán candidatos a estar en un filesystem propio 2.- Seleccionar el tipo de filesystem para almacenar la información Ejemplos de esquema de particionamiento para servicios Apache Servidor FTP /boot 2 GB / 10GB-30GB /var/www/html resto /tmp 5 GB /var/log 4 GB /swap 4 GB /boot / /uploads /tmp /var/log /swap IHS 2 GB 10GB-30GB resto 5 GB 4 GB 4 GB /boot 2 GB / 10GB-30GB /opt resto /tmp 5 GB /var/log 4 GB /swap 4 GB Con los esquemas anteriores se puede inclusive reinstalar el sistema operativo sin perder información. 44 LPIC 1 Version 5 Ensure the /boot partition conforms to the hardware architecture requirements for booting. Actualmente en el mercado existen dos arquitecturas de hardware relacionada con el firmware de un equipo físico, estas son las basadas en: ● ● BIOS UEFI BIOS es un fimware que cada dia que pasa esta transitado a un periodo de obsolencia ya que, está siendo sustituido por UEFI en los nuevos equipos de cómputo. En relación a los criterios que debe cumplir la partición /boot para BIOS: 1. Se encuentre en los primeros sectores del disco duro para que pueda cargarse el bootloades GRUB2 2. Debe encontrarse en una partición primaria 3. El sistema de archivo para /boot debe ser vfat (fat32) UEFI es un fimware que ha venido a sustituir a BIOS el cua proporciona características importantes para administrar hardware como es la posibilidad de cargar modulos de LVm particiones o sistema de archivo. En relación a los criterios que debe cumplir la partición /boot con UEFI son los siguientes: 1. Que exista la partición ESP o /boot/efi para que sea considerado un dispositivo EFI 2. Que dentro de /boot exista archivos *.EFI para cargar el GRUB y otro componente. 45 LPIC 1 Version 5 Knowledge of basic features of LVM. LVM es una implementación de un administrador de volúmenes lógicos para el kernel Linux. Se escribió originalmente en 1998 por Heinz Mauelshagen, que se basó en el administrador de volúmenes de Veritas usado en sistemas HP-UX. LVM incluye muchas de las características que se esperan de un administrador de volúmenes, incluyendo: ● Re-dimensionado de grupos lógicos ● Re-dimensionado de volúmenes lógicos ● Instantáneas de sólo lectura (LVM2 ofrece lectura y escritura) ● RAID 0 de volúmenes lógicos Un LVM se contiene 4 elementos generales, estos son: • Volúmenes Físicos o Physical Volumes • Volúmenes Lógicos o Logical Volumes • Grupos de volúmenes o Volume Groups • Extensiones Volúmenes Físicos PV (Physical Volumes) Son los discos duros físicos o particiones de un disco duro Grupos de volúmenes VG (Volume Groups) Es la parte que engloba los volúmenes lógicos (Logical Volumes) y nuestros volúmenes físicos (Physical Volumes), es decir, es una especie de contenedor donde se sitúan los volúmenes lógicos (Logical Volumes) y los volúmenes físicos (Physical Volumes). 46 LPIC 1 Version 5 Volúmenes Lógicos LV (Logical Volumes) Es el equivalente a una partición de un disco duro, por lo que puede contener un sistema de archivos como por ejemplo /home. Extensiones Las extensiones que se describirán a continuación están directamente ligadas con un grupo de volúmenes (disco duro virtual) existente y las cuales de manera general consisten en divisiones de datos. Extensión Lógica LE (Logical Extents) Cada Volumen Lógico es dividido en porciones de datos, a estas divisiones se les conoce como Extensiones Lógicas. El tamaño de la extensión es el mismo para todo el Volumen Lógico. Extensión Física PE (Physical Extents) Cada Volumen Físico está dividido por porciones de datos, a estas divisiones se les conoce como Extensiones Físicas, estas extensiones tienen el mismo tamaño que las Extensiones Lógicas. Referencia de Imagen: http://julianvas.blogspot.mx/2012/12/teoria-lvm-logical-volume-manager.html 47 LPIC 1 Version 5 ……….etc………………… 102.2 Instalar un gestor de arranque Peso 2 Descripción: L os candidatos deberán poder seleccionar, instalar y configurar un gestor de arranque. Áreas de conocimiento clave: ➢ Proporcionar ubicaciones de arranque alternativas y opciones de arranque de copia de seguridad. ➢ Instalar y configurar un gestor de arranque como GRUB Legacy. ➢ Realizar cambios básicos de configuración para GRUB 2. ➢ Interactuar con el gestor de arranque. La siguiente es una lista parcial de los archivos, términos y utilidades utilizados: ➢ menu.lst, grub.cfg y grub.conf ➢ instalación de arranque ➢ grub-mkconfig IBM CARGADORES DE ARRANQUE Bootloader (cargador de arranque): El gestor de arranque o cargador de arranque es el software inicializado por la BIOS o UEFI para llevar a cabo la carga del kernel con los parámetros apropiados y la imagen RAM inicial (initramfs), antes de iniciar el proceso de arranque del OS. Se pueden utilizar diferentes gestores de arranque como GRUB o Syslinux. Algunos gestores de arranque solo admiten arrancar desde la BIOS o UEFI y otros desde ambos. 48 LPIC 1 Version 5 Los cargadores de arranque EFI mas populares para Linux se basan en cargadores de arranque BIOS, por lo que ofrecen funciones que no suelen necesitar, como por ejemplo, permitir la concatenación con otro cargador de arranque. Gestores de arranque que soportan UEFI y BIOS GRUB (GRand Unified Bootloader): Derivado (fork) de PUPA (proyecto de investigación destinado a mejorar GRUB Legacy). GRUB necesita crear una partición /boot separada para instalarse, a menos que se utilice el sistema de archivos B trfs (compatible con los algoritmos de compresión zlib o LZO) para la partición root. G RUB es ahora modular y ya no requiere de la fase 1.5 o fase intermedia, en consecuencia los módulos para soporte de L VM o R AID deben ser cargados desde el disco duro. Los discos duros pasan de ser /dev/sda1 (GRUB Legacy) a hd0,msdos1 (disco 1 partición 1 para sistemas MBR) o hd0,gpt1 (para los sistemas que usan GPT), en GRUB. ● SYSLINUX: Es una colección de cargadores de arranque, capaz de iniciar desde discos duros, CDs o Red (utilizando PXE). Veremos su instalación en artículos destinados a tal fin en este mismo blog (https://nebul4ck.wordpress.com). De entre todos los cargadores de arranque incluidos en SYSLINUX quizás el mas importante sea ISOLINUX, un cargador de arranque para los discos ópticos. Nota: S yslinux no es capaz de acceder a los archivos contenidos en una partición diferente de aquella en la cual se ha instalado. Tal característica (llamada multi-fs) no está aún implementada. Para un gestor de arranque alternativo con características multi-fs use G RUB. ● Gestores de arranque para BIOS ● ● ● GRUB Legacy (GRUB de legado): Es el cargador por defecto de las distribuciones de Linux mas antiguas. Este cargador de arranque quedó eclipsado por su sucesor GRUB. Veremos como configurar GRUB Legacy en el apartado de “Configurar cargadores de arranque“ LILO: Es un gestor de arranque mas sencillo, por lo que ofrece menos posibilidades a la hora de arrancar distintos OS. L ILO cayó prácticamente en desuso con la llegada de GRUB. NeoGRUB: Es una implementación de G RUB2DOS proporcionado por el configurador de cargador de arranque E asyBCD para Windows. NeoGRUB permite arrancar Linux desde el cargador de arranque Windows, que para hacer esto posible incorpora una implementación de G RUB Legacy dentro del propio cargador de arranque Windows. NeoGRUB soporta los siguientes sistemas de archivos: FAT16/32, MINIXfs, ext2fs, Reiserfs, JFS y XFS. Gestores de arranque para UEFI ● EFISTUB: A partir de la versión del kernel 3.3 Linux permite arrancar con EFISTUB. Esta característica permite que el firmware E FI cargue el kernel como un ejecutable EFI. Digamos que es un gestor de arranque minimalista que permite arrancar desde el propio firmware EFI. 49 LPIC 1 Version 5 rEFIt: Es un administrador de arranque (no un cargador), se puede usar en PC basados en U EFI. Dispone de una atractiva interfaz gráfica. Actualmente es un administrador de arranque obsoleto ● rEFInd: Derivado de rEFIt para PCs basados en UEFI y para ampliar sus prestaciones. Al igual que rEFIt es un administrador de arranque con una bonita interfaz, útil para equipos con EFI que ofrecen administradores de arranque incompletos. Puede utilizarse junto con EFISTUB para ejecutar las imágenes mediante su menú. ● Gummiboot: Similar a r EFInd solo que su interfaz es en modo texto y cuenta con menos opciones. ● ELILO: Se utiliza en algunas distribuciones (en especial en O penSUSE) como cargador de arranque predeterminado para equipos basados en E FI Referencias: Firmware: http://es.wikipedia.org/wiki/BIOS https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface_%28Espa%C3%B1 ol%29 Tabla de partición: https://wiki.archlinux.org/index.php/Master_Boot_Record_%28Espa%C3%B1ol%29 https://wiki.archlinux.org/index.php/GPT Cargador de arranque: https://wiki.archlinux.org/index.php/Boot_loaders_%28Espa%C3%B1ol%29 https://wiki.archlinux.org/index.php/Syslinux_%28Espa%C3%B1ol%29 https://wiki.archlinux.org/index.php/GRUB_%28Espa%C3%B1ol%29 https://wiki.archlinux.org/index.php/UEFI_Bootloaders Sobre Secure Boot: Con S ecure Boot un equipo basado en E FI solo iniciará un cargador de arranque si se ha firmado criptográficamente con una clave cuyo duplicado se almacena en el firmware del equipo, evitando así que programas malintencionados accedan al ordenador al inicio del arranque. Desde Linux el problema es que el uso de S ecure Boot requiere la firma de un cargador de arranque de Linux con la clave de M icrosoft (ya que es la única cuya presencia se garantiza en la mayoría de los equipos). En la práctica puede que tengamos que desactivar S ecure Boot o generar su propia clave para arrancar una distribución arbitraria de Linux o un kernel personalizado. ● CONFIGURAR LOS CARGADORES DE ARRANQUE. Vamos a estudiar de una forma “breve” como configurar los principales cargadores de arranque G RUB Legacy, GRUB, SYSLINUX y UEFI con la herramienta e fibootmgr. Nota: Solo G RUB Legacy y G RUB son abarcados por el examen, será por ello por los que realicemos una descripción mas exhaustiva de estos cargadores de arranque, aun así, podrás encontrar aquí una entrada en este mismo blog sobre un uso eficiente de s yslinux a la hora de instalar un sistema F edora, del cual tenemos vmlinuz e initrd y arrancando desde una unidad externa. Sobre e fibootmgr daremos una breve explicación de su uso. 50 LPIC 1 Version 5 Configurar GRUB Legacy. La ubicación normal para el archivo de configuración de GRUB Legacy en un equipo basado en BIOS es /boot/grub/menu.lst (o grub.conf para algunas distribuciones como RedHat, Fedora o Gentoo). GRUB utiliza (hd0) o (hd0,0) por ejemplo para señalar la primera partición del primer disco en lugar de los archivos de dispositivos Linux (/dev/hda o /dev/sda), además no distingue entre dispositivos PATA, SATA, SCSI y USB, por lo que en un sistema que solo tiene SCSI, la primera unidad de disco será igualmente (hd0). Nota: GRUB Legacy no arrancará desde una unidad USB si utiliza un ordenador antiguo que no admita unidades USB como discos duros. Las asignaciones de unidades de GRUB Legacy se pueden encontrar en el archivo /boot/grub/device.map GRUB Legacy interpretará como partición raíz aquella en la que se encuentre su archivo de configuración, por lo que si existe una partición independiente (/boot) para GRUB será está la partición que tome como partición raíz y no / , algo que deberemos de tener en mente a la hora de referenciar el kernel y la RAM inicial. Estudiaremos las opciones (globales y de imágenes) de GRUB Legacy mediante la imagen anterior. ● La opción default=0 indica que arranque por defecto (si no pulsamos ninguna tecla antes del timeout) el primer OS de la lista, en este caso Fedora (3.4.1) 51 LPIC 1 Version 5 Timeout=15 indica que tenemos 15 segundos para seleccionar un OS diferente al de por defecto. ● La línea splashimage=/grub/bootimage.xpm.gz hace que aparezca una imagen de fondo en el menú de selección. Como dijimos GRUB Legacy toma como directorio raíz aquel en el que se encuentra su archivo de configuración que en este caso es /boot por lo que la imagen realmente se encuentra en /boot/grub/bootimage.xpm.gz Nota: Si la imagen que deseamos se encuentra en otra partición podremos especificarla con (hd0,2) si por ejemplo se encontrase en la 3º partición del primer disco. ● title Fedora (3.4.1) hará que en el menú de selección aparezca un OS con este nombre (Fedora …) en nuestro caso, además será el primero que aparezca del menú ya que se encuentra en primera posición. ● root (hd0,0) como imaginaremos, referencia a la primera partición del primer disco, recordemos que para nosotros es /boot (ya que es una partición independiente marcada como activa en la tabla de particiones) ● El parámetro k ernel describe la ubicación del kernel de Linux a cargar, y sus respectivos parámetros. Una vez mas, la ruta es relativa a su partición primaria, es decir el kernel se encuentra dentro de /boot/ Nota: Si tuviésemos el kernel en otra partición o incluso en otro disco podríamos especificarlo así: kernel (hd0,4) /vmlinuz… ● Utilice la opción initrd para especificar un disco RAM inicial que contiene un conjunto mínimo de controladores, herramientas y archivos de configuración, empleados por el kernel en un punto del proceso de arranque para poder montar su sistema de archivos raíz antes de que pueda acceder al disco duro. Además esto disminuye considerablemente el tamaño del archivo kernel principal. ● Con la opción rootnoverify GRUB Legacy no intentará acceder a los archivos de esta partición debido a que no puede cargar directamente por ejemplo, un kernel como el de DOS o Windows. ● Por ultimo la opción de cargar en cadena: chainloader indica a GRUB que pase el control a otro cargador de arranque. Normalmente se pasa la opción + 1 para cargar el primer sector de la partición del SO de destino, que para este ejemplo es (hd0,1). La carga en cadena funciona en equipos BIOS. Una versión de GRUB Legacy compatible con EFI, puede realizar la carga en cadena, pero debe indicar a GRUB que use el ESP, indicando la partición como siempre (hd0,0) y después pasar el nombre de un archivo de cargador de arranque EFI a través de la opción chainloader, como chainloader /EFI/Microsoft/boot/bootmgfw.efi Nota: Las opciones de las imágenes de GRUB Legacy suelen presentar sangrías tras la primera línea, pero esto es una convención y no un requisito del formato del archivo. Para instalar GRUB Legacy usamos el comando grub-install acompañado del nombre de dispositivo en el que se encuentra el sector de arranque: ● # grub-install /dev/sda o # grub-install ‘(hd0)’ Nota: Ambos comandos instalarán el cargador de arranque en el primer sector del disco 1 (en el MBR). Si quisiéramos instalarlo en el sector de arranque de una partición concreta podríamos indicarlo de igual modo …./sda2 o ‘(hd0,1)’ ● 52 LPIC 1 Version 5 En Fedora: Para instalar GRUB Legacy compatible con EFI copie el archivo grub.efi y grub.conf en /boot/efi/EFI/redhat. Si realiza una instalación con rpm grub-efi el archivo .efi se incluirá en esta ubicación de forma predeterminada. Puede que tenga que usar e fibootmgr para añadir el cargador de arranque a la lista de EFI de la siguiente manera: ● # efibootmgr -c -l \\EFI\redhat\grub.efi -L GRUB Nota: UEFI utiliza la barra invertida \ c omo separador de ruta (similar a las rutas de Windows), pero el paquete oficial efibootmgr proporciona soporte a las rutas de estilo unix con barras diagonales / como separador de ruta para la opción -l. Efibootmgr convierte internamente / a \ antes de codificar la ruta de acceso del cargador. Hubiese valido igualmente /EFI/redhat/grub/.efi -L GRUB Utilizar GRUB como cargador de arranque GRUB está diseñado para funcionar en equipos basados en BIOS y EFI. La configuración de GRUB2 es muy similar a la de GRUB Legacy, aunque difieren en varios aspectos como el nombre o ruta del archivo de configuración, la compatibilidad con módulos de carga (el comando insmod del archivo de configuración de GRUB2 permite cargar módulos), la admisión de instrucciones lógicas en la configuración, la forma en la que manipulamos el archivo de configuración, etc… El archivo de configuración pasa a llamarse g rub.cfg (y no grub.conf o menu.lst) y la ruta puede contener un 2 en grub (/boot/grub2/..) lo que permite instalar los dos cargadores de arranque (GRUB Legacy y GRUB2 o GRUB). Un aspecto importante a tener cuenta es el cambio de nombre de algunos de sus parámetros en el archivo de configuración y la forma en la que manipulamos a este. Por ejemplo la palabra t itle pasa a llamarse menuentry, el título de menú se incluye entre comillas, además tras este aparece una llave ({) y cada entrada termina con una llave de cierre (}), s et precede a la palabra clave root y se usa el signo (=) para separar a root de la partición, la palabra clave r ootnoverify se ha eliminado y en su lugar se utiliza r oot, las particiones (no lo discos) se empiezan numerando desde 1 y no desde 0, y destacar que las versiones mas recientes de GRUB también admiten un sistema de identificación de particiones para especificar el tipo de tabla de partición como (hd0,gpt2) para indicar la 2º partición del primer disco de una tabla de particiones GPT o (hd0,mbr3) para referenciar a la 3º partición del primer disco de una tabla MBR. Como comentábamos anteriormente la forma en la que se manipula ahora el archivo de configuración de GRUB difiere de GRUB Legacy y es debido a que GRUB utiliza una serie de scripts para el mantenimiento automático del archivo de configuración. Estos scripts buscan en el sistema versiones de kernel y añaden entradas a GRUB. El objetivo de esto es que los administradores del sistema nunca tengan que editarlo de forma explícita. En su lugar se editan los archivos de / etc/grub.d y el archivo / etc/default/grub que controla los elementos predeterminados creados por los scripts de configuración. Por ejemplo si desea ajustar el tiempo de espera, podría cambiar la siguiente línea: GRUB_TIMEOUT=10 y tras realizar los cambios, deberemos de volver a generar el archivo grub.cfg con los comandos update-grub, grub-mkconfig > /boot/grub/grub.cfg o grub-mkconfig -o 53 LPIC 1 Version 5 /boot/grub/grub.cfg, como ya comentamos algunas instalaciones usan el 2 tras la palabra grub, habrá que tener esto presente. Al instalar Linux por primera vez, el instalador debe configurar GRUB correctamente y usar grub-install de la misma forma que GRUB Legacy. La recuperación de GRUB en caso de sufir daños, la dejaremos para artículos independientes de este mismo blog, pero como nota, mencionaremos la herramienta supergrubdisk (http://supergrubdisk.org), que es una imagen de disco de arranque con varias opciones para localizar y usar el archivo de configuración de GRUB en su disco duro. …. 102.3 Administrar bibliotecas compartidas Peso 1 Descripción Los candidatos deberán ser capaces de determinar las bibliotecas compartidas de las que dependen los programas ejecutables e instalarlos cuando sea necesario. Áreas de conocimiento clave: ● ● ● Identificar bibliotecas compartidas. Identificar las ubicaciones típicas de las bibliotecas del sistema. Cargar bibliotecas compartidas. La siguiente es una lista parcial de los archivos, términos y utilidades utilizados: ● ● ● ● ldd ldconfig /etc/ld.so.conf LD_LIBRARY_PATH Bibliotecas compartidas o dinámicas Son “fragmentos” de los programas mas utilizados, referenciadas por el ejecutable principal de un programa, el cual omite la mayoría de las rutinas de bibliotecas. Las bibliotecas compartidas son identificadas por su extensión .so o .so.versión, a diferencia de las estáticas q ue son incluidas dentro del mismo programa, y tienen la extensión .a. Ventajas del uso de las bibliotecas compartidas o dinámicas: ■ Le facilita la vida al programador. 54 LPIC 1 Version 5 ■ ■ El programa final tiene un tamaño mucho menor, lo que significa que necesita menos espacio en disco y consume menos RAM y si encima son utilizadas por muchos programas de forma paralela, el uso de RAM o el espacio en discos no es redundante. Como regla general, los programas que dependen de bibliotecas compartidas se benefician de la actualización de estas de forma inmediata. No se necesita una actualización del programa ni volver a compilarlo, referenciando a una nueva biblioteca. Inconvenientes del uso de las bibliotecas compartidas o dinámicas: ■ ■ ■ ■ Los cambios en una biblioteca pueden ser incompatibles con uno o todos los programas que hacen uso de ella. Para esto, Linux utiliza sistemas de numeración, para que se puedan mantener varias versiones de una misma biblioteca. Para que un programa se ejecute bien, necesita encontrar las bibliotecas, esto se hace mediante archivos de configuración y variables. El archivo de configuración general es /etc/ld.so.conf, este a su vez puede contener una línea como “include /etc/ld.so.conf.d/*.conf” que indica que cargue también los archivos de configuración de dicho directorio, ya que esos archivos pueden contener rutas de otras bibliotecas referenciadas. Al existir multitud de bibliotecas compartidas, esto puede producir una maraña de referencias a bibliotecas que puede resultar tedioso. El sobre-escribir, eliminar, o cualquier otra razón por la que una biblioteca quede inaccesible, puede producir desde que un programa no inicie, hasta que el mismo sistema no arranque. Nota: Algunas distribuciones, como por ejemplo Gentoo, poseen características diferentes. Para modificar ld.so.conf, habría que añadir o editar los archivos del directorio/etc/env.d y luego utilizar la herramienta env-update, que lee los archivos de este directorio creando una “ruta final” para referenciar las bibliotecas. Estos métodos cambian las referencias a las bibliotecas de forma permanente y global. Podemos configurar de forma no global, rutas de referencias a bibliotecas gracias a la variable de entorno LD_LIBRARY_PATH, por ejemplo, si quisiéramos probar el efecto de unas nuevas bibliotecas sin tener que definirlas de forma global, las almacenaríamos en un directorio y añadiríamos dicha ruta a esta variable, de forma que para esa sesión o futuras sesiones (en caso de que la configurásemos en un script de inicio de usuario) el sistema busque en determinado path archivos de configuración de bibliotecas. $export LD_LIBRARY_PATH=/usr/local/pruebas:/opt/otraslib Puede ocurrir que al ejecutar un programa nos muestre un mensaje de error, en el que se informa de que la biblioteca no se ha encontrado. Lo mas normal es que la biblioteca no esté instalada, o bien el nombre o ruta de esta, difiera con el que el binario del programa pide. Para solucionar estos problemas lo normal es seguir el rastro del paquete y comprobar que librería está pidiendo y luego comprobar si está instalada en otro directorio no referenciado, o tiene otro nombre. Si directamente no está instalada, la buscaremos por la web, repositorios, etc… si está instalada con otro nombre o en otro directorio, bastará con crear un enlace simbólico desde la que tenemos hacia la que pide. Linux posee un par de programas para la administración de bibliotecas. 55 LPIC 1 Version 5 ■ ■ ldd : Muestra las bibliotecas de las que depende un programa, si le pasamos el nombre de una biblioteca, entonces mostrará la(s) biblioteca(s) de las que esta depende. ldconfig : Lee los archivos de configuración (/etc/ld.so.conf) e implementa todos los nuevos cambios (actualiza la caché) y como trabajo secundario actualiza todos los enlaces simbólicos de librerías. Nota: Los programas ld.so y ld-linux.so son los que gestionan la carga de bibliotecas, y estos no leen los archivos de configuración, leen directamente el archivo/etc/ld.so.cache que es un binario que contiene toda las rutas de directorios y archivos (un formato mucho mas eficaz que en texto plano). El inconveniente es que cada vez que se añade un archivo o ruta hay que refrescar esta caché, para eso el comando ldconfig. Compilación de paquetes Lo primero que podemos preguntarnos si somos usuarios nóveles en GNU/Linux es ¿Que es compilar?, pues bien, la definición de compilar podría ser algo como “reunir una serie de objetos necesarios en una misma unidad con el fin de poder hacer que esta sea totalmente funcional“ . En GNU/Linux cuando hablemos de compilar un paquete nos estaremos refiriendo a la transformación de un programa escrito en código fuente (el cual es legible por nosotros, los humanos) en código máquina, de manera que pueda ser interpretado por el sistema haciéndolo este funcionar. Vamos a explicar el procedimiento de compilación mediante un ejemplo: Supongamos que queremos instalar un programa/paquete para el cual no encontramos el respectivo .rpm o .deb de nuestra distribución o sistema específico (hardware, arquitectura, etc..) pero en cambio si tenemos la opción de bajar el código fuente del mismo. Lo primero que deberemos de hacer será descargarlo a nuestra máquina. Una vez descargado comprobaremos que se trata de un archivo .tar, .tar.gz o tar.bz2 (aunque es posible igualmente encontrarlos en .zip o en otros sistemas de compresión). Una vez tengamos el código fuente (archivo .tar, .tar.bzp2, etc..) en nuestra máquina deberemos de comprobar si tenemos algún compilador instalado en el sistema. En GNU/Linux es común utilizar GCC (compilador para C, C++, Java, Fortran y otros códigos de programación que se distribuye como software gratuito bajo licencia GPL (General Public License) ) que podremos comprobar mediante la siguiente orden en consola: # gcc --version Si no obtenemos resultados deberemos de proceder a su instalación mediante alguna de las herramientas de instalación de paquetes anteriormente estudiadas. Ahora que ya tenemos instalado gcc, vamos a descomprimir el código fuente. Dependiendo de la extensión del paquete deberemos de utilizar una u otra herramienta, por ejemplo si es un .zip utilizaremos: # unzip nombre_paquete.zip Si es un tar.gz o tar.bz2 utilizaremos la herramienta tar (esto lo veremos en capítulos posteriores, no obstante vamos a indicar como descomprimir exclusivamente este paquete) tal que así: # tar -zvxf nombre_paquete.tar.gz 56 LPIC 1 Version 5 o # tar -jxvf nombre_paquete.tar.bz2 Esto nos creará un nuevo directorio donde se almacenarán los archivos que contenía el paquete antes de ser descomprimido. Accederemos a este directorio mediante el comando cd. Dentro de este directorio buscaremos los archivos README e INSTALL donde se nos presentará una serie de instrucciones para la instalación y requisitos necesarios que deberemos de instalar en caso de no encontrarse instalados en nuestro sistema. Ahora con “todos” los requisitos supuestamente instalados y una idea de lo que vamos a realizar para instalar el paquete o haber obtenido información sobre este mediante los archivos anteriormente citados, ejecutaremos el comando “./configure” con el que procederemos a verificar los requisitos (nos alertará si faltase alguno) y preparar la compilación. Nota: Aunque por regla general “todos” los paquetes suelen llevar una ruta predefinida válida (la cual suele estar definida bajo el directorio /usr), podremos utilizar el parámetro –prefix=/ruta/de/instalación para especificar una ruta alternativa en la que instalar el nuevo programa. Es importante que esta ruta este en nuestra variable PATH de manera que podamos ejecutar el nuevo programa sea cual sea nuestro directorio de trabajo. Con todo listo y todos los requisitos cumplidos procederemos a compilar. Para ello utilizaremos el comando make. Esto producirá una salida en la que iremos comprobando el proceso de compilación. Esta tarea podrá tardar desde segundos a horas (depende de numerosos factores). Nota: Si tenemos un procesador con mas de un núcleo podremos utilizar la opción -j <num> para especificar el número de hilo (thread) a utilizar durante el proceso de compilación. Bueno ya tenemos compilado nuestro programa ahora queda instalarlo. Es importante saber si tenemos permisos en el directorio de instalación, bien en el que viene por defecto (que se puede determinar dependiendo del paquete que estemos compilando e instalando) o en el que hayamos prefijado nosotros mediante la opción –prefix= de ./configure. De no tener los permisos suficientes deberemos de ingresar como root (su –), para lo que necesitaremos conocer su password o bien utilizar sudo (si es que el archivo /etc/sudoers, algo que veremos en otros capítulos, no lo permite). Sin más ejecutamos el comando make install. Si todo ha ido bien, ya tendremos nuestra aplicación instalada la cual podremos ejecutar desde cualquier directorio (recordemos que el directorio en el que se encuentra el binario de la aplicación debe estar añadido como valor a nuestra variable PATH). Para finalizar no estaría de mas hacer un poco de limpieza, algo que hará fácilmente el comando make clean. Nota: Este comando es necesario ejecutarlo, si tras la compilación obtuvimos errores y queremos volver a compilar. Antes de continuar deberemos de ejecutar make clean. Si por cualquier motivo queremos desinstalar la aplicación, utilizaremos el comando make unistall, pero antes deberemos de movernos al directorio en el que se encuentran los archivos de compilación y el código fuente (sí, el que se creo cuando descomprimimos al principio el paquete comprimido del código fuente) y autentificarnos como root. 57 LPIC 1 Version 5 Aptitud eliminada Añadido el conocimiento de apt. 102. 4 Utilizar la gestión de paquetes de Debian Peso 3 Descripción Los candidatos deberán ser capaces de realizar la gestión de paquetes utilizando las herramientas de paquetes de Debian. Áreas de conocimiento clave: ● ● ● ● Instale, actualice y desinstale los paquetes binarios de Debian. Busque paquetes que contengan archivos o bibliotecas específicas que puedan o no estar instalados. Obtener información de paquetes como versión, contenido, dependencias, integridad del paquete y estado de instalación (independientemente de si el paquete está instalado o no). Mayor conocimiento de apt. La siguiente es una lista parcial de los archivos, términos y utilidades utilizados: ● ● ● ● ● /etc/apt/sources.list dpkg dpkg-reconfigure apt-get apt-cache Al igual que en RPM, los paquetes Debian son utilizados por diferentes distribuciones que derivan de Debian, como pueden ser Ubuntu, Linux Mint o Xandros e igualmente funcionan en diferentes arquitecturas. Prácticamente igual que en RPM, los paquetes Debian siguen una convención de nomenclatura para sus paquetes, estos incluyen información de dependencias, archivos y utilidades, además, igualmente se usa una herramienta para la instalación de estos (dpkg), o otras mas cómodas 58 LPIC 1 Version 5 que tiene el efecto de yum en RPM (la de instalar paquetes y dependencias de forma cómoda) como APT-GET, dselect, aptitude o Synaptic (GUI) . Dentro del sistema de paquetes Debian podemos distinguir entre cinco tipos de paquetes según su grado de dependencia con el propio sistema: ■ ■ ■ ■ ■ Required: Se trata de paquetes indispensables para el correcto funcionamiento del sistema. Important: Se trata de paquetes que deberían de estar presentes en cualquier sistema tipo UNIX. Standard: Paquetes que comúnmente se encuentran en un sistema GNU/Linux. No son indispensables para el correcto funcionamiento del sistema. Optional: Paquetes que pueden o no estar en un sistema GNU/Linux, como por ejemplo los referentes al sistema gráfico (en el caso de que vayamos a usar el sistema en modo servidor (minimalista). Extra: Paquetes no integrados como optional debido a que puedan surgir conflictos con paquetes de mayor prioridad o requiere un tipo de configuración especial. Nota: Podemos ver la prioridad de un determinado paquete mediante el comando apt-cache show <paquete> | grep Priority o aptitude show samba |grep Priority A diferencia de YUM, APT usa el archivo /etc/apt/source.list para especificar las ubicaciones desde las que se pueden obtener los paquetes, ya sean directorios de ubicaciones en CD-ROM, sitios FTP o webs. /etc/apt/source.list Es el archivo de texto en el que añadiremos los PPA (Personal Package Archives) , es decir las direcciones desde las que queremos obtener paquetes. Estas direcciones pueden tener un un formato tipo “deb http://packages.linuxmint.com rebecca main upstream import #id:linuxmint_main” si se trata de un repositorio de paquetes web, o cambiando http por ftp, smb, file o cdrom (dependiendo de que fuente de paquetes se trate). Nota: Si la dirección pertenece a una URL donde se encuentra código fuente en vez de paquetes binarios, será deb-src lo que aparezca en lugar de deb También es posible que cuando hayamos añadido un repositorio este se encuentre en /etc/apt/source.list.d/nombrerepo.list y dentro de este archivo la URL del repositorio. Existen programas específicos para ciertas distribuciones como es el caso de Ubuntu que añaden o eliminan de forma automática tanto el repositorio como la clave pública (GPG). Instalar un nuevo PPA de forma automática en Ubuntu: $ sudo add-apt-respository ppa:nombrerepo/ppa Para eliminarlo: $ sudo add-apt-repository --remove ppa:nombrerepo/ppa En Debian podremos añadir un CD-ROM como fuente mediante el siguiente comando: $ sudo apt-CD-ROM add Si no tenemos la posibilidad de utilizar estas herramientas en nuestra distribución, deberemos de añadir los ppa a mano y eliminarlos mediante la edición del archivo source.list o con rm si se trata de un archivo en /etc/apt/source.list.d/ 59 LPIC 1 Version 5 Ya hayamos realizado cambios (instalar, editar o eliminar un ppa) de forma automática o manual, deberemos de actualizar la información mediante el comando apt-get update. A partir de este momento dispondremos del nuevo ppa desde el que poder instalar un nuevo software que no encontrábamos en nuestros antiguos repositorios utilizando por ejemplo apt-get install <nombre_programa>. dpkg hace la función de rpm en sistemas basados en RPM, es decir, instalador de paquetes. Sus archivos principales se encuentran en /var/lib/dpkg y el archivo de configuración en: /etc/dpkg/dpkg.cfg apt-get es una herramienta de línea de comandos y es semejante a la herramienta yum, utilizada en sistemas RPM para la instalación de paquetes y sus dependencias. apt tiene su archivo de configuración el cual también afecta a la herramienta dselect: /etc/apt/apt.conf. Si quisiéramos ver algunos ejemplos de configuración podemos acceder al archivo de ejemplo: /user/share/doc/apt/examples/apt.conf apt-cache es una herramienta que nos permite mantener actualizada y saneada la base de datos de paquetes para APT dselect es una herramienta potente con una gran cantidad de opciones nada obvias y que posee una interfaz de usuario interactiva en modo texto. Para usarla basta con escribir el comando dselect en la línea de comandos y aparecerá un menú de tipo texto. dselect funciona como una interfaz de dpkg. También es posible pasarle opciones y comandos con la siguiente sintaxis: dselect [opciones] [comandos] El archivo de configuración principal se encuentra en: /etc/dpkg/dselect.cfg aptitude es bastante similar a dselect por su formato interactivo , aunque aptitude incorpora menús por los que nos podemos mover usando Control-T. Aptitude también permite que se le pasen comandos por la línea de comandos. Synaptic es una herramienta de entorno gráfico similar en muchos aspectos a dselect y aptitude, pero de fácil manejo. Nota: Por lo general dselect, aptitude y synaptic son herramientas para encontrar software de los que desconoce su nombre exacto. APT también puede funcionar en sistemas basados en RPM (http://www.apt4rpm.sourceforge.net). Estudiaremos mas sobre los comandos de paquetes deb en su respectivo apartado de comandos al final del tema. Convirtiendo paquetes RPM y Debian en tarball Como vimos con el gestor de paquetes RPM, es posible convertir paquetes rpm en paquetes tarball y debian, pues para Debian pasa lo mismo, una buena solución para convertir paquetes rpm o tarball en paquetes Debian es mediante el software Alien, que como ya comentamos, es obligatorio tener el sistema de paquetes RPM y de Debian instalados en el mismo sistema. Una pega es que alien no convierte toda la información de las dependencias de manera totalmente correcta. Cuando convierte desde un tarball, alien copia los archivos exactamente igual que se encontraba en el paquete tarball, por lo que es primordial asegurarnos de que el paquete tarball contiene una ruta de directorios correcta, es decir, o descomprimimos el paquete en un directorio contenedor y luego creamos enlaces, 60 LPIC 1 Version 5 copiamos o sustituimos los archivos originales, o bien desempaquetamos el contenido, creamos una estructura acorde, lo volvemos a empaquetar y cuando descomprimamos, cada archivo se situará en su directorio. Para conocer los comandos de conversión, vaya a la página de comandos LPIC-1 Convertir paquetes Soluciones para problemas de dependencias Forzar la instalación: Una solución es ignorar el problema, esto no es lo adecuado pero dependiendo de donde se dé la dependencia sabremos si es buena opción o no. Por ejemplo: Si hemos compilado un paquete y a la hora de instalarlo nos diese problemas de dependencias, podríamos en principio ignorarlo. ■ ■ RPM: Opciones —nodeps y –force (rpm -i nombrepaquete.rpm –force/–nodeps) DPKG: Opciones –ignore-depends=paquete, –force-depends ó —force-conflicts Actualizar o reemplazar el paquete del que se depende: Es una buena forma de solucionar conflictos de dependencias, pero a veces engordamos el problema si el paquete que necesitamos no es el adecuado para nuestra distribución, en este caso, quizás nos aparezcan otros errores de dependencias en otros software que dependen de ese paquete, de su versión antigua (la instalada anteriormente) o bien que a la hora de volver a actualizar el programa o el sistema, no nos reconozca ese paquete, esto sucede porque interpretará las dependencias de forma que lo hace su distribución y no en la que la hemos instalado. Recompilar el paquete problemático: Algunas dependencias surgen de bibliotecas u otras herramientas instaladas en el ordenador que compiló el paquete y no del código fuente del programa, por lo tanto, si volvemos a compilar el paquete en otro ordenador que tiene otras herramientas y software instalado, algunas dependencias cambiarán. En el caso de distribuciones basadas en Debian es raro que tenga que compilar un paquete a partir de su paquete fuente, pero para RPM, podremos usar el comando rpmbuild con la opción –rebuild y el paquete fuente. Esto nos puede generar uno o mas paquetes binarios en /usr/src/nom_distro/RPMS/tipo_arq Localizar otra versión del software a instalar: Podemos volver a una versión anterior o posterior, siempre y cuando esto no produzca errores de seguridad o simplemente esa versión no satisfaga nuestras necesidades por tener implementaciones nuevas o bugs no corregidos. Esto es común cuando queremos instalar un software que además necesita actualizar bibliotecas compartidas y no queremos, ya que otros programas necesitan de esas, en este caso, una versión anterior podría solucionar esto. Comandos para la administración de paquetes y dependencias dpkg: se utiliza para instalar un paquete Debian dpkg [acción] [opción] [nombre-paquete] 61 LPIC 1 Version 5 [Acciones]: ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Instalar un paquete: -i [–ignore-depends|–no-act|-E|-G|–recursive] Reconfigurar un paquete instalado (lanza el script de postinstalación): –configure = dpkg-reconfigure Borrar un paquete dejando intacto los archivos de configuración: -r [–ignore-depends|–no-act|-B] Elimina un paquete de forma completa: -P (–purge) Muestra información sobre un paquete instalado: -p (–print-avail) Muestra información sobre un archivo de paquete desinstalado: -I (–info) Mostrar el estado de instalación de un paquete: -s Localiza el(los) paquete(s) que incluyen el(los) archivo(s) especificados por PATRON: -S PATRON (–search PATRON) Mostrar todos los paquetes instalados en el sistema: –get-selections (si añadimos un patrón, solo mostrará los que coincidan). Enumerar todos los paquetes instalados, cuyo nombre coincida con PATRON (útil utilizarlo también con grep omitiendo el patrón) : -l PATRON (–list PATRON) Listar los ficheros contenidos en un paquete: -L Desempaquetar un paquete pero no instalarlo: –unpack Busca paquetes parcialmente instalados: -C (–audit) [Opciones]: ■ ■ ■ ■ ■ ■ Al eliminar un paquete con -r desactiva los paquetes que se basan en el que se está eliminando: -B (–auto-deconfigure) Al instalar (-i) o eliminar (-r) ignora la información de dependencias del paquete: –ignore-depends=<nom_paquete> Simula la instalación o desinstalación de un paquete para verificar los errores de dependencias: –no-act Instala de forma recursiva, todos aquellos paquetes que coinciden con el nombre (comodín) del paquete: –recursive No instala el paquete si ya existe una versión mas actualizada: -G No instala el paquete si ya se encuentra instalada la misma versión: -E (–skip-same-version) apt-get : herramienta para instalación de paquetes y dependencias desde una ubicación especificada en el archivo /etc/apt/sources.list o en los archivos individuales /etc/apt/source.list.d/ apt-get [acción] [opción] [nombre paquete] [Acción]: ■ ■ ■ ■ Instalar un paquete : install [-d|-m|-q(-qq)|–no-upgrade|-f|-s|-y|-b] Actualizar todos los paquetes que dispongan de una versión mas reciente: upgrade [-m|-s|-q(-qq)|-y] Actualizar de forma inteligente los paquetes, es decir, evita actualizar un paquete si con ello se rompe una dependencia: dist-upgrade Desinstalar un paquete: remove [-m|-q(-qq)|-s|-y] 62 LPIC 1 Version 5 ■ ■ ■ ■ ■ ■ Elimina un paquete por completo, incluyendo sus archivos de configuración: remove –purge Obtener información actualizada sobre los paquetes disponibles en las fuentes (source.list) : update Revisa la consistencia de la bbdd de paquetes y las instalaciones defectuosas de paquetes: check Elimina la cache de apt-get: clean Eliminar la cache, pero solo de los paquetes que ya no se pueden descargar: autoclean Obtiene el archivo de paquete fuente, partiendo del nombre de archivo: source [Opciones]: ■ ■ ■ ■ ■ ■ ■ ■ Descargar los archivos de paquetes pero no los instala: -d (–download-only) Cuando se instala o elimina un paquete se puede intentar corregir un sistema cuyas dependencias no se satisfacen: -f (–fix-broken) Cuando se obtiene, instala, elimina, actualiza… un paquete, es posible ignorar aquellos que por cualquier causa no se pueden obtener: -m (–ignore-missing ó –fix-missing) Si queremos omitir parte de la información de progreso (instalando, actualizando, desinstalando..): -q (si queremos omitir mas aún: -qq) Realizar una simulación de la acción (instalar, actualizar…): -s (–simulate, –no-act, –just-print, –dry-run o –recon) Automatizar una respuesta afirmativa para un comando: -y (–yes ó –assume-yes) Compilar un paquete fuente tras obtenerlo (source): -b (–build ó –compile) Cuando instalamos, podemos no actualizar un paquete si ya existe una versión anterior: –no-upgrade apt-cache : Ofrece información sobre la base de datos de paquetes Debian. [Opciones]: ■ ■ ■ ■ ■ ■ apt-cache depends samba : Informa de todas las dependencias del paquete samba apt-cache rdepends samba : Informa de aquellos paquetes que dependen de samba apt-cache show samba : muestra información sobre el paquete samba apt-cache pkgnames sa : Devolverá nombres de paquetes que comiencen con sa apt-cache stats : Informa de cuantos paquetes hay instalados, cuantas dependencias hay grabadas, y otrasestadísticas apt-cache unmet : Devuelve información sobre las dependencias no satisfecha dselect : Herramienta potente y con muchas opciones (nada obvias). Para ejecutarlo, basta con escribir dselect en la línea de comandos y seleccionar las diferentes opciones. Aunque mediante la sintaxis $dselect [opciones] [comandos] también es posible pasarle comandos y opciones como argumento. Algunas de estas opciones y comandos son: [Opciones]: ■ Cambiar el directorio donde se encuentran los ficheros de dpkg (por defecto /var/lib/dpkg): –admindir <ruta> 63 LPIC 1 Version 5 ■ ■ Activa el modo experto: –expert Activar el modo debug y enviar la info a un archivo: –debug <archivo> [Comandos]: ■ ■ ■ ■ ■ ■ ■ Instalar nuevos paquetes o actualizarlos a nuevas versiones: install Configurar cualquier paquete previamente instalado: configure Eliminar o purgar un paquete y sus archivos de configuración: remove Actualizar la lista de paquetes disponibles: update Ver, gestionar y seleccionar paquetes y sus dependencias: select Alterar la ruta en la que encontrar paquetes para su instalación: access Salir de dselect: quit 103 Comandos GNU y Unix Una gran parte de lo que naturalmente se llama Linux en realidad se origina en el Proyecto GNU. El siguiente capítulo trata sobre una pequeña parte de GNU. GNU no es Unix. 103.1 Trabajar en la línea de comandos Peso: 4 Descripción: Los candidatos deberán ser capaces de interactuar con shells y comandos desde la línea de comandos. Este objetivo de la auditoría presupone que Bash es una cáscara. Campos de conocimiento más importantes: ❖ Utilice comandos simples de shell y secuencias de comandos de una sola línea para resolver tareas sencillas de línea de comandos. ❖ Usar y personalizar el entorno de shell, por ejemplo para definir, usar y exportar variables de entorno. ❖ Usar y cambiar el comando h istory ❖ Ejecutar comandos dentro y fuera de la ruta de búsqueda definida Lista de archivos, directorios y aplicaciones importantes: ➢ ➢ ➢ ➢ ➢ ➢ ➢ bash type echo which env man export ➢ ➢ ➢ ➢ ➢ ➢ ➢ uname pwd history Set unset .bash_history unset 64 LPIC 1 Version 5 ➢ Quoting Información general Mientras tanto hay varios frontales gráficos para Linux y la mayoría de las tareas administrativas se pueden hacer con el ratón, pero el dispositivo de entrada más importante para la administración del sistema sigue siendo el teclado. Para poder comunicarse con el ordenador en modo texto, necesita un shell. El término shell significa “intérprete” en el idioma inglés, que es exactamente lo que busca, porque puede intercambiar información con el kernel a través de este shell. Bajo Linux, el Bash se usa como shell por defecto. Este es un desarrollo adicional del shell sh original de Unix. El shell sh sigue siendo parte de Linux, pero al menos como shell de inicio de sesión ya no se usa tan a menudo. El shell sh fue desarrollado por Stephen Bourne en 1977, mientras que el bash (Bourne Again Shell) como parte del proyecto GNU fue escrito por Brian Fox y Chet Ramey a finales de los 80 del siglo pasado. El término Bash es un juego de palabras y puede leerse como Born Again o Bourne Again. Otros shells conocidos usados bajo Linux son ksh (Korn shell), csh (C shell), tcsh (una extensión del shell C), zsh (Z shell relacionado con ksh), rsh (shell remoto) y algunos más. Estructura de un comando de Shell Un comando consta de hasta tres componentes diferentes. El primer componente es el comando en sí mismo, es decir, un archivo ejecutable, un script o un comando interno del shell. Un comando también puede funcionar por sí solo y ejecutarse sin necesidad de un comando Las opciones o argumentos funcionan: user:~ # mount Si el comando mount se ejecuta sin opciones ni argumentos, monta sistemas de archivos. Sin embargo, también hay constelaciones en las que se ejecuta un comando con una o más opciones: user:~ # mount -a En este ejemplo, mount se ejecutó con la opción -a. Con esta opción, el programa de montaje montaría todos los sistemas de ficheros listados en el fichero /etc/fstab. (!) Sin embargo, también es posible proporcionar mount sólo con argumentos: user:~ # mount /dev/sda1 /boot Los argumentos son diferentes de las opciones. Una opción le dice a un programa, cómo se supone que debe comportarse. Los argumentos le dicen a un programa lo que debe procesar. 65 LPIC 1 Version 5 Es posible pasar múltiples opciones así como múltiples argumentos a un programa. Con muchos programas el orden es incluso variable: user:~ # mount -o username=pepe,password=xy //fs1/data /mnt/ -t smbfs El ejemplo muestra una mezcla con una opción en el anverso, una opción en el reverso y los argumentos en el medio. En este caso, el comando mount establece una conexión de red con un ordenador con Windows. En caso de duda, consulte siempre el Manpage (página de manual) de un programa para averiguar cómo pasar opciones y argumentos. Transferencia de opciones Hay varios métodos comunes para pasar opciones. Algunos comandos requieren un guión antes de las opciones, otros funcionan sin guión introductorio. Además, muchos programas proveen que palabras enteras sean usadas como opciones. Normalmente van precedidos de dos guiones. Ya conoce el siguiente ejemplo del capítulo anterior: root:~ # rpm --install -vh /i586/fortune-1.0-860.i586.rpm Preparing.. ########################################### [100 %] Esta vez, se combinaron deliberadamente varias formas de transferencia de opciones. Hay una palabra de opción con dos guiones prefijados y dos opciones con un guión prefijado común. Otro representante destacado de los programas flexibles es tar . Puede usar tar con opciones normales o palabras de opción. Además, tar también puede aceptar opciones sin guiones prefijados. Los siguientes cuatro comandos conducen al mismo resultado para tar: # tar -x -z -v -f xmbmon205.tar.gz # tar -xzvf xmbmon205.tar.gz # tar xvzf xmbmon205.tar.gz # tar --extract --gzip --verbose --file=xmbmon205.tar.gz Variables de entorno y variables de shell Básicamente, las variables tienen la tarea de registrar valores. Estos pueden ser evaluados y procesados posteriormente por un programa. Sin embargo, las variables también influyen en la apariencia y el comportamiento de todo el sistema operativo. Puede mostrar el contenido de una variable simplemente introduciendo el comando echo , seguido de un signo de dólar y luego la propia variable: root:~ # echo $OSTYPE linux-gnu Se hace una distinción entre variables de entorno y variables shell en un sistema Unix o Linux. Las diferencias entre estos dos tipos de variables son, por un lado, los archivos de 66 LPIC 1 Version 5 configuración que se utilizan para declarar y, por lo tanto, cuándo y con qué programa se evalúan y, por otro lado, su ámbito de acción: ➢ Las variables de entorno se aplican a todas las shells utilizadas por un usuario. El contenido de estas variables es heredado por los subshells. Esto significa que cuando se llama a un subshell, las variables se exportan automáticamente a este subshell. Las variables de entorno suelen utilizar mayúsculas. ➢ Las variables de Shell deben ser redeclaradas en cada subshell iniciado por el usuario o un script. No hay herencia por defecto. Para las variables shell, normalmente se utilizan letras minúsculas. Cuando un usuario entra en un sistema, ya se han definido varias variables. Si luego abre más shells o ejecuta scripts, se declaran más variables. Los siguientes archivos de configuración son responsables de ello: ➢ /etc/profile es el primer archivo de configuración que se lee cuando un usuario inicia sesión. Contiene las primeras variables de entorno ( !) y la primera sentencia PATH. Para que los cambios afecten a este archivo, es posible que el usuario tenga que desconectarse y volver a conectarse. ➢ /etc/bashrc se puede cargar desde el archivo.bashrc de un usuario. Contiene configuraciones, alias y funciones para todo el sistema. Este archivo se lee de nuevo al inicio de cada shell y, por lo tanto, no requiere que el usuario inicie sesión de nuevo después de que se hayan realizado los cambios. ➢ ~/.bash_profile (si está disponible) sólo se leerá en un nuevo inicio de sesión y se ejecutará inmediatamente después de / etc/profile. Contiene instrucciones de ruta adicionales (por ejemplo, el directorio raíz), el editor predeterminado que se va a utilizar y variables de entorno específicas del usuario. ➢ ~/.bash_login es una alternativa a .bash_profile y sólo se procesa si el archivo .bash_profile no existe. Este archivo también se utiliza únicamente durante el inicio de sesión. El contenido y el uso previsto corresponden al perfil .bash_profile. ➢ ~/.profile es el archivo de configuración original de Bash. Sólo se lee durante el inicio de sesión y sólo si no existe un perfil .bash_profile ni un archivo .bash_login en el directorio del usuario. El contenido y uso previsto corresponde al perfil.bash_profile y .bash_login. ➢ ~/.bashrc es el otro archivo de configuración original del Bash. Se lee en cualquier caso, incluso cuando se llama a una nueva shell. Después de que se hayan hecho cambios en este archivo, el usuario no necesita conectarse de nuevo. Esencialmente contiene alias y funciones. ➢ ~/.bash_logout es un archivo opcional que se ejecuta cuando el usuario cierra la sesión. Por ejemplo, podría borrar el monitor. 67 LPIC 1 Version 5 Puede mostrar todas las variables de shell configuradas actualmente utilizando el conjunto de comandos sin opciones ni argumentos. Dado que la salida del comando es bastante extensa, una salida con el “Pager less” vale la pena: # set | less BASH=/bin/bash BASH_ARGC=() BASH_ARGV=() ... aprox. 800 líneas fueron cortadas .... Para listar las variables de entorno, utilice el comando env . Aquí también debería utilizar l ess para la visualización: # env | less LESSKEY=/etc/lesskey.bin HOSTNAME=archangel HOST=archangel TERM=xterm SHELL=/bin/bash ... aprox. 60 líneas fueron cortadas .... Si necesita declarar una variable usted mismo, puede hacerlo simplemente escribiendo la variable seguida del valor a asignar en la línea de comandos. Las variables que obtienen valores de esta manera no se exportan automáticamente a subshells, como lo demuestra la siguiente secuencia de comandos: # x=5000 # echo $x 5000 # bash # echo $x # En el primer paso a la variable x se le asignó el valor 5000. Entonces la variable fue emitida con el comando echo. En la cuarta línea se inicia un subshell con el comando bash. El intento de dar salida a la variable con el comando echo falla porque no hubo herencia de la variable en el sub-shell. Si se requiere el contenido de una variable en un subshell, la variable debe exportarse. Ejemplo: 68 LPIC 1 Version 5 # name=Pepe # echo $name Pepe # export Name # bash # echo $Name Pepe Esta vez la variable Name fue exportada con el comando export antes de que se iniciara el subshell. Como muestra el segundo comando de echo, la variable está ahora disponible en el subshell. Sin embargo, también es posible declarar y exportar una variable en un solo paso. Esto se demuestra en la primera línea del siguiente ejemplo: # export Name=Pepe # bash # echo $Name Pepe Sugerencia para el examen: Nota: Una variable nunca puede ser exportada a un shell padre, sino sólo a un subshell. En el examen, es posible que se enfrente a esta pregunta. Si ya no necesita el contenido de una variable, debe restablecerla usando el comando unset. Tiene sentido restablecer primero todas las variables utilizadas al principio de un script. Esto evita que cualquier variable exportada con los mismos nombres interfiera con el funcionamiento de su script. Ejemplo: # unset Name Variables populares para los examenes Algunas variables se preguntan una y otra vez durante el examen. Se tratan particularmente de las siguientes: $HISTSIZE d efine el número de comandos almacenados en el history (historial) de comandos. Esta variable se configura normalmente en el archivo /etc/profile. ● $PS1 indica la visualización del mensaje. Ejemplo: # echo $PS1 \u@\h:\w$ Los caracteres \ u representan el nombre de usuario. La @ se muestra normalmente. Los caracteres \ h se sustituyen por el nombre del host. Le siguen dos puntos. A continuacion \ w para Working Directory que muestra el directorio actual. La tilde ~ representa el directorio ● 69 LPIC 1 Version 5 raíz del usuario. Lo siguiente es un > . El aviso se puede adaptar a sus propias necesidades modificando la variable PS1. Se recomienda una configuración en el fichero /etc/bashrc. ● $? c ontiene el nivel de error del último comando ejecutado. Normalmente el valor 0 en esta variable significa que el último programa se ejecutó con éxito. Los valores de error varían de un programa a otro. Los valores populares son 1 y 127. Ejemplo: # ser o no ser bash: ser: command not found # echo $? 127 El "ser o no ser" da como resultado un nivel de error de 127. ● $1, $2, etc. contienen las opciones y argumentos que se pasan a un programa. Normalmente son evaluados por el propio programa o script iniciado. Lea más sobre este tema en la segunda parte de este libro. Comandos history de bash y finalización automática de comandos Para poder trabajar más eficientemente en la línea de comandos, Bash le ofrece dos excelentes funciones de ayuda. Imagina que quieres desempaquetar el siguiente programa: # tar xvzf ez-ipupdate-3.0.11b7-linux-i386.tar.gz La probabilidad de que escriba mal este nombre de archivo largo es bastante alta, y los nombres de archivo de este tamaño no son la excepción en Linux. Con el comando automático de finalización del Bash, esto no es un problema. El comando debe ser escrito sólo hasta que el Shell puede identificarlo de manera única. A continuación, pulse la tecla de tabulación # tar xvzf ez[TAB]: Este comando debería ser suficiente para desempaquetar el tarball. Si hay varias maneras de completar el comando cuando se pulsa la tecla de tabulación, recibirá un mensaje acústico. A continuación, puede pulsar la tecla Tab repetidamente para obtener una selección de opciones de finalización. Otra función útil del Bash es el comando history. Todos los comandos que utilice se almacenan en un archivo llamado .bash_history (!). El punto al principio del archivo ya es una indicación de que es un archivo que se almacena en el directorio raíz de un usuario. La v ariable HISTSIZE (!) determina cuántos comandos se almacenan en la lista del historial. Normalmente puede encontrar esta variable en el archivo /etc/profile. Hay varias opciones disponibles para repetir y editar comandos que ya se han utilizado. El más popular es probablemente el uso de la tecla (cursor arriba). Llama a los comandos utilizados más recientemente en orden inverso. Los antiguos usuarios de DOS también conocen este comportamiento por doskey. Otras posibilidades para el uso de history son: ● !! - Este comando se denomina Bang-Bang y ejecuta el último comando del historial de nuevo. 70 LPIC 1 Version 5 ● ● ● ● !n - Si simplemente ingresa el historial de comandos, obtendrá un número Lista de los comandos utilizados más recientemente. A continuación, puede introducir n con el número del comando deseado. !-n ejecuta el último comando - n. Si usted introduce !-2, se ejecutara el penúltimo comando. !<cadena de caracteres> (string) ejecuta el último comando empezando por <string>. Por ejemplo, si realiza el comando tail /var/log/syslog, solo tendra que ejecutar !ta. !? <cadena de caracteres> ejecuta el último comando en el que aparece <string>. Variable PATH Si desea ejecutar un programa que no está en un directorio incluido en su variable PATH, debe especificar la ruta completa a este programa en la línea de comandos. Si inicia un programa sin especificar una ruta, el shell primero comprueba si es un comando interno del shell. Estos incluyen: echo , bg, fg, jobs, kill, pwd, set, unset, unset y muchos más. Si no se encuentra ningún comando adecuado, el shell busca el programa en todos los directorios contenidos en la variable PATH. Si existen varios programas con el mismo nombre, se ejecuta el primer programa encontrado. En este caso, puede utilizar el comando which para determinar qué programa ejecutará el shell automáticamente: # which less /usr/bin/less Tenga en cuenta que un programa no se ejecuta sin una ruta, incluso si se encuentra en su directorio. Este comportamiento existe bajo DOS, pero no bajo Linux. También puede iniciar un programa que se encuentra en el directorio actual anteponiendo el prefijo del programa con ./. Los caracteres . / representan el directorio actual. Por ejemplo, puede ejecutar scripts de configuración para las Tar-Balls en el directorio actual seleccionando la siguiente sintaxis: /usr/src# ./configure Si está utilizando un indicador que no le muestra en qué directorio se encuentra actualmente, utilice el comando pwd (Path of Working Directory) sin opciones. A continuación, se le mostrará la actual ruta de acceso: /usr/src/# pwd /usr/src/ Puede mostrar el contenido de sus variables PATH al igual que otras variables: # echo $PATH /usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games Quoting Si los argumentos contienen espacios u otros caracteres que serían interpretados por el shell durante la ejecución del comando, estos caracteres deben estar protegidos. Se dice entonces que el carácter se enmascara o se escapa en argot. El término Quoting se deriva del hecho de que las cuotas se utilizan a menudo para este proceso. 71 LPIC 1 Version 5 En la práctica, las cuotas se utilizan en particular para proteger las expresiones regulares. Las cuotas son: \ (contrabarra) sólo protege al carácter inmediatamente después de la expansión por el shell. (No me queda bien claro con el traductor) ‘ (comillas simples) protegen todos los caracteres encerrados, incluidas las variables, de la expansión. " (comillas dobles) protegen a los caracteres encerrados de la expansión, pero no a las variables ni a las expansiones del historial. Nota: Por favor, no confunda el uso de comillas y caracteres acentuados. En particular, un `( retroceso, retroceso) tiene una función completamente diferente en el shell. El comando uname El comando uname devuelve información sobre el sistema en ejecución. Con las opciones apropiadas, también puede comprobar el número de versión del kernel en ejecución aquí. Por ejemplo: # uname -r 4.9.0-8-amd64 O tambien: # uname -a Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux Puede utilizar la información generada por uname para ver información más detallada sobre módulos específicos o para cargar o descargar módulos que coincidan con el núcleo en ejecución. Manpages Los manpages son un cómodo sistema de ayuda y están disponibles para casi todos los comandos de Linux. Simplemente escriba el comando m an , seguido del comando que desea explicar en la línea de comandos y obtendrá una respuesta descripción detallada. Cómo funcionan los manpages Cada vez que se llama a una página man, el programa consulta los directorios contenidos en la variable $MANPATH. Aquí se pueden almacenar varios directorios a la vez en la línea de comandos de trabajo. En los subdirectorios divididos en secciones, los archivos de las páginas man están comprimidos. El sistema man descomprime el archivo solicitado y luego lo pasa a un paginador. Esto le mostrará la página de manual deseada. $MANPATH y el archivo manpath.config Como se mencionó anteriormente, la variable $MANPATH contiene información sobre la ubicación de las páginas de manual. Puede encontrar información más detallada en el fichero de configuración /etc/manpath.config. Cuando se añaden nuevas páginas de manual al 72 LPIC 1 Version 5 sistema, este archivo se actualiza automáticamente según sea necesario. Por regla general, la intervención manual no es necesaria. Para determinar el MANPATH actual, simplemente introduzca el comando manpath sin parámetros. El resultado se verá así: # manpath /usr/local/man:/usr/local/share/man:/usr/share/man Otra ruta importante es aquella en la que el ManSystem almacena sus archivos temporales. Como ya se ha mencionado, las páginas de manual están comprimidas en formato crudo. Por lo tanto, se descomprimen en un directorio temporal antes de ser mostrados. Normalmente este es el directorio / var/cache/man. Este directorio, soportado por el demonio cron, es limpiado cíclicamente por catman. Para localizar el directorio de caché de su ordenador, escriba el comando m anpath -c: # manpath -c /var/cache/man/oldlocal:/var/cache/man/local:/var/cache/man Las secciones del Mansystems El Mansystem está dividido en varias secciones. Estas secciones están estructuradas de la siguiente manera: ● 1 - Programas ejecutables para usuarios ● 2 - Llamadas al sistema (características soportadas por el kernel) ● 3 - Llamadas a la biblioteca (Libraries / Bibliotecas) ● 4 - Archivos especiales (normalmente en /dev) ● 5 - Formatos de archivo y convenciones ● 6 - Juegos ● 7 - Otros (paquetes de macro y convenciones) ● 8 - Programas administrativos (sólo para el usuario root) ● 9 - Rutinas del kernel (no estándar) Sólo hay una página de manual para muchos programas o archivos. Sin embargo, si hay varios, se mostrará el que está numéricamente en la sección más baja. Un ejemplo de esto es crontab. Para crontab hay dos entradas en las Manpages, porque crontab es un programa ejecutable y un archivo de configuración. Por lo tanto, hay una entrada para crontab en la sección 1 y otra en la sección 5. Si ahora necesita información sobre el archivo de configuración crontab, puede llamarlo con el siguiente comando: # man 5 crontab Puede obtener ayuda para el programa crontab llamando a la página man sin especificar la sección: # man crontab Estructura de los manpages. 73 LPIC 1 Version 5 La estructura de un manpage es fija y siempre debe contener los siguientes elementos debe ser incluido: ● Name - El nombre del elemento con una breve descripción. ● Synopsis - Una breve descripción completa de la sintaxis. ● Description - Una descripción detallada del artículo. ● Defaults - Parámetros preestablecidos. ● Overview - Una visión general de las correlaciones más complejas. ● Options - Opciones y su descripción. ● Return Values - Información sobre posibles valores de retorno, a veces también llamado estado de salida. ● See also - Referencias a temas relacionados. ● Bugs - Errores conocidos. ● Files - Archivos de configuración, etc. Hay aún más elementos concebibles, pero los que se enumeran a continuación son probablemente los más comunes. Comandos relacionados Todavía hay algunos comandos que están relacionados con man que se tienen que mencionar al menos temáticamente en este tema, porque también caen en las preguntas del examen ( !). Aquí se deben mencionar con mayor atención los comandos w hatis y a propos. La razón de esto es que estos dos también acceden a los archivos del Mansystems. El comando whatis sólo busca en el campo “Name” de todas las manpages. Esto es especialmente útil si tiene que tener en cuenta el hecho de que hay entradas para un elemento en varias secciones, por ejemplo, en crontab : # whatis crontab crontab (1) – maintain crontab files for individual users crontab (5) – tables for driving cron crontab (1p) – schedule periodic background work Si olvida pasar un valor de consulta como argumento, el programa le preguntará de nuevo: # whatis whatis what? El programa apropos es también sólo un caso especial abreviado de las páginas de manual. A diferencia de whatis, apropos busca no sólo en el campo “Name”, sino también en el campo Description. Por lo tanto, la posibilidad de buscar con apropos un programa que cumpla una tarea determinada. Imagine que tiene una nueva unidad de cinta, pero no tiene idea de qué programas pueden controlarla. Simplemente introduzca el siguiente comando: # apropos tape mt (1) – control magnetic tape drive operation st (4) – SCSI tape device smbtar (1) – shell script for backing up SMB/CIFS 74 LPIC 1 Version 5 Después de todo, la consulta dio lugar a tres resultados positivos, con los que ya se puede hacer algo. Si ha leído las manpages correspondientes y ha seguido las notas de See also en el final de la página respectiva, muchas preguntas sobre el tema de los Streamer deberían haber sido contestadas sólo con esto. ALgunos de los siguientes comandos tambien son utiles e interesantes tanto para practicar como para probar, pero que no están directamente relacionados con el sistema man. whereis indica dónde se encuentran un programa, su(s) archivo(s) de configuración y la(s) página(s) de manual asociada(s). Para averiguarlo, haz la siguiente pregunta: ¿Dónde está cron? # whereis cron cron: /usr/sbin/cron /etc/cron.weekly /etc/cron.hourly /etc/cron.d /etc/cron.monthly /etc/cron.daily /usr/share/man/man8/cron.8.gz which m uestra la ruta completa de un comando. Esto es útil si tiene varias versiones de un programa y desea saber cuál de ellas se ejecutará cuando se introduzca un comando sin una ruta de acceso: # which less /usr/bin/less which indica aquí en qué ruta se encuentra el programa less. Si existe un alias para un programa, también se muestra: # which ls alias ls='ls --color=auto' /usr/bin/ls Los comandos set y unset no se encuentran por lo que son comandos internos del shell: # which unset /usr/bin/which: no unset in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) Sin embargo, puede utilizar el comando interno type para una verificación correspondiente: # type unset unset is a shell builtin Para los programas que se encuentran en la ruta de búsqueda, type hace una salida similar a which. # type top top ist /usr/bin/top Recomendación para el examen Durante la examen, usted debe estar muy familiarizado con el uso del sistema man. 75 LPIC 1 Version 5 103.2. Procesar flujos de texto utilizando filtros Peso: 2 Descripción: Los candidatos deberán ser capaces de aplicar filtros a los flujos de texto. Campos de conocimiento más importantes: Envíe archivos de texto y flujos de salida a través de filtros de texto para cambiar la salida con comandos UNIX estándar desde el paquete GNU-textutils. Lista de archivos, directorios y aplicaciones importantes: ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ bzcat cat cut head less md5sum nl od paste sed ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ sha256sum sha512sum sort split tail tr uniq wc xzcat zcat Información general Bajo Linux hay muchos programas disponibles con los que puede manipular textos o flujos de texto. Algunos de estos programas también son filtros de texto. Las siguientes secciones le presentarán algunas de estas herramientas útiles. …...etc…. 76 LPIC 1 Version 5 103.3 Gestión básica de archivos Peso: 4 Descripción: Los candidatos deberán ser capaces de utilizar los comandos básicos de Linux para gestionar archivos y directorios. Campos de conocimiento más importantes: ❖ Copiar, mover y eliminar archivos y directorios individuales ❖ Copiar múltiples archivos y copiar directorios recursivamente ❖ Eliminar archivos y directorios recursivamente ❖ Usar patrones de búsqueda de nombres de archivo simples y avanzados en los comandos ❖ find para buscar y editar archivos en función de su tipo, tamaño o timestamp tar , cpio, y dd Lista de archivos, directorios y aplicaciones importantes: ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ cp find mkdir mv ls rm rmdir touch tar cpio ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ dd file gzip gunzip bzip2 bunzip2 xz unxz file globbin Información general Las siguientes secciones tratan de los fundamentos de la gestión de archivos. Necesita conocer los comandos básicos de gestión de ficheros y sus opciones para la comprobación. También debe poder utilizar comodines con estos comandos. Comandos para operaciones con archivos ls El comando ls lista el contenido de los directorios. La salida se realiza por defecto en orden alfabético. En el examen, ( !) usted debe al menos estar familiarizado con las siguientes opciones: ➢ -l especifica que se utiliza el formato de listado. Esto incluye los derechos de acceso a archivos y directorios, así como las marcas de tiempo. ➢ -i muestra los inodos utilizados por los archivos y directorios. 77 LPIC 1 Version 5 103.4 Uso de flujos, pipes y redirecciones Peso: 4 Descripción: Los candidatos deberán ser capaces de redirigir y conectar flujos para poder procesar los datos de texto de forma eficiente. Estas tareas incluyen redirigir la entrada estándar, la salida estándar y la salida de errores estándar, reenviar la salida de un comando a la entrada de otro comando, usar la salida de un comando como argumento para otro comando y enviar la salida tanto a la salida estándar como a un archivo. Campos de conocimiento más importantes: ❖ ❖ ❖ ❖ Redireccionar la entrada estándar, la salida estándar y la salida de error estándar Reenvío de la salida de un comando a la entrada de otro comando (pipe) Usar la salida de un comando como argumento para otro comando Enviar salida tanto a la salida estándar como a un archivo Lista de archivos, directorios y aplicaciones importantes: ➢ tee ➢ xargs Información general A veces puede ocurrir que tenga que procesar la salida de un programa directamente con otro programa. En este caso se puede utilizar una tubería (línea vertical). Con su ayuda, no es necesario almacenar la salida del primer programa en un archivo con el fin de volver a leerlo con el segundo programa. En otro caso, un programa puede generar un mensaje en la pantalla que desea grabar. En este caso, es necesario redirigir el fichero Salida estándar (redirección). Si se va a utilizar un programa exclusivamente a partir de la entrada estándar (normalmente el Teclado) y tiene que leer un archivo con este programa, necesitará también un desvío. Esta vez, sin embargo, la entrada estándar debe ser redirigida. stdin, stdout und stderr ………………………….etc…. 78 LPIC 1 Version 5 103.5 Creación, supervisión y finalización de procesos Peso: 4 Descripción: Los candidatos deben ser competentes en la gestión de procesos simples. Campos de conocimiento más importantes: ❖ ❖ ❖ ❖ ❖ Ejecutar tareas en primer plano y en segundo plano indica a un programa que debe continuar ejecutándose después del cierre de sesión Observe los procesos activos Selección y clasificación de procesos para el mensaje Enviar señales a los procesos Lista de archivos, directorios y aplicaciones importantes: ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ & bg fg jobs kill nohup ps top ➢ ➢ ➢ ➢ ➢ ➢ ➢ ➢ free uptime pgrep pkill killall watch screen tmux Información general Este capítulo y el siguiente tratan sobre el control y la supervisión de los procesos. Cada programa que se ejecuta en un ordenador consta de al menos un proceso. Los procesos están organizados en una jerarquía de árbol y la raíz de este árbol es el proceso init o systemd. Cuando el kernel ha iniciado todos sus módulos en el momento del arranque, pasa el control al proceso init correspondiente. A cada proceso se le asigna un ID único, el PID (ID de proceso). El proceso init siempre tiene PID 1. PID 0 no existe. (!) No caiga en la trampa en el examen! root:~# ps -A | head -2 PID TTY TIME CMD 1? 00:00:04 init Alternativamente en un ordenador con systemd: root:~# ps -A|head -2 79 LPIC 1 Version 5 PID TTY TIME CMD 1? 00:00:02 systemd …. etc…. 104.1 80
