4 - Inicializacion de Sistemas y Servicios

System Initialization and Services Sinopsis de la secuencia de arranque

Conceptos clave

Después del arranque, la inicialización de Red Hat Enterprise Linux se realiza en cuatro etapas: BIOS, un gestor de arranque, el kernel y /sbin/init.

La configuración del BIOS permite especificar una secuencia de dispositivos que se deberían considerar dispositivos de arranque.

Una vez que el BIOS haya seleccionado un dispositivo de arranque, transfiere el control a cualquier ejecutable que se encuentre en el registro de arranque maestro del dispositivo.

System Initialization and Services Discusión

Introducción

Desde el momento en que se enciende hasta que los usuarios inician sesión en una máquina que esté funcionando, el sistema pasa a través de cuatro etapas distintas de inicialización.

1. BIOS: El sistema operativo mínimo que está localizado en el ROM de la placa madre.

2. Gestor de arranque: La aplicación mínima que se carga desde el MBR del disco, se utiliza para cargar y pasar el control al kernel de Linux.

3. Kernel: El kernel de Linux inicializa las estructuras internas y los controladores de dispositivos, provee un sistema de archivos inicial e inicia el primer proceso.

4. /sbin/init: El proceso /sbin/init realiza la mayor parte del trabajo duro (pertinente a la administración del sistema) para inicializar la máquina.

Este cuaderno explicará las diferentes etapas en detalle. Esta primera lección presenta toda la estructura y la configuración pertinente del BIOS. La segunda lección presenta el gestor de arranque GRUB y la función del kernel de Linux en el arranque. Las últimas dos lecciones abordarán la función del proceso inicial /sbin/init y la configuración de servicios de Red Hat Enterprise Linux.

BIOS

Cada computador, cuando se enciende por primera vez, inicia un sistema operativo mínimo llamado BIOS de Basic Input/Output Sytem (sistema básico de entrada/salida). El BIOS de un sistema es una funcionalidad permanente de la placa madre. [1] La mayoría de los BIOS ofrecen una utilidad interactiva, que puede ser iniciada al presionar una secuencia de teclas determinada durante el inicio tal como la tecla SUPR, o F10. La secuencia de teclas difiere entre sistemas y se presenta como parte del proceso de inicio.

Cuando inicia, el BIOS de un sistema por lo general realiza las siguientes funciones.

Verificación del sistema POST

El BIOS realiza una revisión integral del sistema, asegurando que los componentes centrales tales como la CPU o la memoria están presentes y funcionando. Esta prueba se refiere a menudo como el POST o Prueba de energía en sí mismo.

Inicialización de dispositivos

El BIOS de un sistema inicializa los controladores de dispositivos centrales para el teclado, los puertos seriales de vídeo y otros, asignando los recursos de sistema apropiados tales como líneas IRQ y puertos E/S. Los BIOS modernos implementan el protocolo Plug n' Play, el cual se utiliza para probar los dispositivos PCI para configuraciones de recursos compatibles y luego asignar a cada dispositivo PCI una configuración sin conflictos.

Muchos sistemas operativos también pueden realizar una configuración similar a Plug n' Play y la mayoría de BIOS proveen una configuración tal como Plug n' Play Aware OS? [Y/n], la cual puede hacer que BIOS difiera la configuración hasta que se cargue el sistema operativo.

Aunque Linux sí soporta Plug n' Play, se sugiere, por lo general, que BIOS realice la configuración Plug n' Play (por ejemplo, al responder "No" a la configuración BIOS anterior).

Selección del dispositivo de arranque

Después de inicializar los dispositivos, BIOS busca un dispositivo de arranque apropiado. El dispositivo de arranque es seleccionado generalmente desde las opciones posibles.

Dispositivo blando

CD-ROM

IDE o disco duro SCSI

Tarjeta de red conforme a PXE

Una tarjeta de red conforme a PXE, del inglés Preboot Execution Environment (entorno de ejecución de prearranque) suele implementar el protocolo de configuración IP DHCP (o BOOTP) y el archivo TFTP transfiere el protocolo de origen, el cual permite que la tarjeta de red descubra y descargue una imagen de kernel desde la red. Dicha tarjeta de red es la excepción a la regla y la configuración PXE va más allá del objetivo de este curso.

La elección del dispositivo de arranque apropiado se configura a través de las aplicaciones interactivas del BIOS. Por lo general, el BIOS permite que se establezca un "orden jerárquico", primero busca un disquete de arranque y si no hay uno entonces busca un CD-ROM de arranque y por último busca un disco duro de arranque.

Entregando las riendas

Una vez se ha seleccionado el disco de arranque apropiado, el BIOS carga el primer bloque del disco (512 bytes) en la memoria y pasa la ejecución a esta región. El primer bloque de un disco de arranque debe contener un ejecutable pequeño conocido como un gestor de arranque. Continuaremos con este tema en la próxima lección.

System Initialization and Services El gestor de arranque GRUB

Conceptos clave

En general, los gestores de arranque en Linux son responsables de tres cosas:

1. Componer una línea de comandos de kernel correcta (que haga referencia a la partición raíz correcta).

2. Cargar un disco ram inicial apropiado (initrd).

3. Cargar y pasar el control a un kernel Linux apropiado.

Los gestores de arranque suelen diseñarse en dos etapas, con la primera etapa lo suficientemente pequeña para residir en un registro de arranque maestro.

GRUB es el gestor de arranque recomendado para Red Hat Enterprise Linux.

GRUB utiliza el archivo de configuración /boot/grub/grub.conf.

Tras el inicio, GRUB se puede utilizar para editar su configuración y arrancar con la nueva especificación de modo interactivo.

Tras el inicio, el kernel de Linux monta la partición raíz de sólo lectura e inicia el primer proceso, por lo general, /sbin/init.


La función de un gestor de arranque

Tras el arranque, el BIOS pasa el control a un pequeño ejecutable conocido como un cargador de arranque. Por lo general, realiza las siguientes tres tareas.

1. Componer una línea de comandos kernel.

2. Cargar un disco ram de inicio (initrd), si es necesario.

3. Cargar y pasar el control al kernel de Linux

¿Qué es un disco ram de inicio?

Algunas veces, Red Hat elige implementar partes del kernel necesarias para cargar el sistema de archivos como módulos del kernel. Esta elección naturalmente presenta un problema. ¿Desde dónde carga el kernel sus módulos de kernel si son necesarios en el proceso de arranque antes de que se cree el sistema de archivos? La respuesta es un disco RAM inicial, el cual es una imagen del sistema de archivos que contiene los módulos necesarios. El gestor de arranque carga la imagen en la memoria para el kernel, desde donde el kernel puede montar el sistema de archivos y cargar los módulos necesarios.

Los detalles de las imágenes de disco RAM iniciales conocidas como initrd, se tratarán en un cuaderno más adelante. Por ahora, observe que en Red Hat Enterprise Linux, los kernels casi siempre tienen initrd asociados, los initrd se llaman convencionalmente /boot/initrd-kernelversion.img y el gestor de arranque es el responsable de cargarlos.

Una elección de gestores de arranque

Red Hat Enterprise Linux ofrece una surtido de gestores de arranque, cada uno de los cuales puede realizar estas funciones. El gestor de arranque tradicional de Linux se conoce como LILO, cuyo nombre es un doble juego de palabras en inglés, porque es LInux LOader, y LIes LOw en el proceso de arranque. El gestor de arranque LILO es específico para Linux y el sistema de archivos ext2.

Un gestor de arranque relativamente reciente es el GRUB Grand Unified Bootloader, (Gran gestor de arranque unificado). El GRUB es un proyecto patrocinado por GNU y como su nombre lo implica, está diseñado para funcionar con múltiples sistemas operativos (y sistemas de archivos).

Tanto LILO como GRUB pueden utilizarse para realizar las tareas necesarias mencionadas anteriormente desde una configuración predeterminada (no interactiva) o para permitir al usuario sobrescribir la configuración en el momento del arranque. GRUB es ahora el gestor de arranque de Red Hat Enterprise Linux (LILO ya no se utiliza) y será el tema de este texto.

Diseño del gestor de arranque

Como mencionamos en la lección anterior, el BIOS generalmente pasa el control al gestor de arranque cuando carga y ejecuta el primer bloque de un disco. Esto obliga a los gestores de arranque a implementar un diseño de dos etapas.

Primera etapa

La primera etapa de un gestor de arranque es generalmente pequeña, diseñada para ajustarse en el registro de arranque maestro (de hecho, ¡comparte el MBR con la tabla de particiones!) o el bootsector de una partición. [1] La única tarea de este gestor de arranque de la primera etapa es el ubicar, cargar y pasar el control al gestor de arranque de la segunda etapa. Ya que el gestor de arranque de la primera etapa se encuentra en el MBR o en el sector de arranque usualmente no es un archivo visible en el sistema de archivos.

Segunda etapa

La segunda etapa de un gestor de arranque es por lo general el propio gestor de arranque, el cual ejecuta una forma de aplicación (a menudo interactiva) en el inicio y puede leer información de configuración acerca de configuraciones por defecto. El gestor de arranque de la segunda etapa suele ser un archivo binario identificable en el sistema de archivos.

Diseño GRUB

Los componentes del gestor de arranque GRUB tradicionalmente residen en el directorio /boot/grub.

La segunda etapa del gestor de arranque es bastante fácil de identificar: se llama stage2. El archivo stage1 es una copia del gestor de arranque de la primera etapa instalada en el MBR o en el sector de arranque (observe que el tamaño es sospechoso en la siguiente transcripción).

Los archivos que terminan en 1_5 son sistemas de archivos específicos a la "primera etapa y mitades", utilizados para localizar y leer stage2, grub.conf y otros archivos desde varios sistemas de archivos.

Por lo general, la única parte "servible al usuario" de GRUB es su archivo de configuración, /boot/grub/grub.conf.

Configuración GRUB

GRUB utiliza un archivo de configuración de texto ASCII, /boot/grub/grub.conf, que suele ser editado a mano con un editor de texto. Una muestra del archivo de configuración se ilustra a continuación.

[root@station root]# ls /boot/grub/ device.map ffs_stage1_5 menu.lst splash.xpm.gz vstafs_stage1_5 e2fs_stage1_5 grub.conf minix_stage1_5 stage1 xfs_stage1_5 fat_stage1_5 jfs_stage1_5 reiserfs_stage1_5 stage2

[root@station root]# ls -l /boot/grub/stage1 -rw-r--r-- 1 root root 512 Apr 1 2003 /boot/grub/stage1

El archivo está estructurado con una sección "global" principal que consta de todas las líneas antes de la primera línea empezando por la palabra clave title, y una o más definiciones menuitem que comienzan con la palabra clave title. El espacio en blanco dentro de una línea es insignificante, aunque la definición de estrofas llevan sangrías con el TABULADOR. Cada línea correspondiente debe iniciar con una palabra clave reconocida y el resto de los parámetros de la palabra clave deben presentarse en la misma línea, (los usuarios de editores de texto que automáticamente delimitan líneas, ¡tengan cuidado!)

Por lo general, el archivo /boot/grub/grub.conf se edita directamente y los cambios se efectúan la próxima vez que grub se ejecute, (i.e., en el próximo arranque del sistema).

Cómo se refiere GRUB a los archivos

La sintaxis del archivo de configuración GRUB es sencilla a excepción de la sintaxis que GRUB utiliza para referirse a los archivos, la cual se presenta a continuación.

Los componentes entre paréntesis se utilizan para identificar una partición de disco particular. La ruta de archivo identifica un archivo dentro del sistema de archivos que se encuentra en una partición especificada. La interpretación de cada componente implica sutilezas resumidas en el cuadro a continuación.

Table 1. Forma en que GRUB se refiere a archivos

[root@station root]# cat /etc/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu password --md5 $2$MrXSq0xS$0LXqkBTfpywyD3TVCao3d0 title Red Hat Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ rhgb quiet vga=0x317 initrd /initrd-2.6.9-5.EL.img

(dispositivo,partnum)ruta de archivo

Componente Role

dispositivo

GRUB no se refiere a los dispositivos como hda o sdc o fd0, como lo hace el kernel de Linux. En su lugar, GRUB se refiere a dispositivos utilizando los siguientes nombres.

hd0: "DISPOSITIVO BIOS #1"

hd1: "DISPOSITIVO BIOS #2"

fd0: "DISPOSITIVO BLANDO #1"

Cada BIOS mantiene un concepto de su primer dispositivo. A menudo es su

Para ilustrar, analizamos la siguiente línea del archivo de configuración, la cual especifica la imagen de fondo ("pantalla splash") para la aplicación GRUB.

La interpretación del nombre de archivo implica los siguientes tres pasos.

1. Determinar el dispositivo: Puesto que sabemos que nuestro sistema arrancó desde el dispositivo IDE de maestro primario, asumiremos que hd0 o el "Dispositivo BIOS #1", se refiere a éste. Lo que GRUB llama hd0, el kernel de Linux llamaría /dev/hda.

2. Determinar la partición: Ahora que conocemos el dispositivo, localizamos la partición en el dispositivo mediante el partnum, recordando que necesitamos agregar 1 para compensar el punto de inicio diferente de GRUB. El 0 anterior por lo tanto especifica la primera partición en el dispositivo /dev/hda1.

3. Determinar el archivo: Puesto que GRUB hacereferencia a archivos relativos al directorio raíz del sistema de archivos, necesitamos determinar dónde se monta la partición /dev/hda1 en nuestro árbol de directorios. Utilizamos el comando df para examinar los montajes actuales.

Dado que la partición /dev/hda1 está montada para /boot, el archivo /grub/splash.xpm.gz relativo al directorio raíz del sistema de archivos es el archivo /boot/grub/splash.xpm.gz relativo a la raíz del árbol de directorios.

Después de determinar la partición y saber dónde está montada, podemos traducir el archivo "GRUB speak"(hd0,0)/grub/splash.xpm.gz a "Linux speak" como /boot/grub/splash.xpm.gz.

Para reforzar el proceso de traducir referencias de archivo GRUB a referencias de archivos Linux, el

dispositivo IDE de maestro primario, algunas veces es otro dispositivo IDE, algunas veces es un dispositivo SCSI. Al cambiar la configuración BIOS, la identidad del "primer dispositivo" puede cambiar.

partnum

El partnum es un número entero utilizado para identificar la partición en un dispositivo. Infortunadamente, GRUB cuenta las particiones comenzando por 0, mientras que el kernel de Linux cuenta particiones comenzando por 1. Por lo tanto, lo que GRUB llama partición número 3, el kernel de Linux llamaría partición número 4.

ruta de archivo

El ruta de archivo es una ruta absoluta del archivo, relativo al directorio raíz del sistema de archivos. GRUB se refiere a los archivosantes los sistemas de archivos se montan en un único árbol de directorio, por lo tanto, GRUB no tiene ningún concepto de los puntos de montaje. Este punto hace énfasis en el AVISO localizado por el instalador de Anaconda en el archivo de configuración de muestra presentado anteriormente.

splashimage=(hd0,0)/grub/splash.xpm.gz

[root@station root]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda3 8159420 5299244 2445700 69% / /dev/hda1 69973 25972 40388 40% /boot /dev/hdb5 30241928 25947992 2757724 91% /home /dev/hdb7 28130956 10578516 16123460 40% /var none 370024 0 370024 0% /dev/shm /dev/fd0 1430 1380 51 97% /mnt/floppy

siguiente cuadro lista archivos que utilizan ambos. Recuerde que la asignación depende de la estructura de particionamiento identificada en la salida del comando df visto anteriormente y cambiaría en discos con particiones diferentes.

Table 2. Traducciones de nombres de archivos de GRUB a Linux

¿Por qué GRUB debe ser tan diferente? Recuerde que GRUB se está ejecutando antes de que el kernel de Linux sea cargado y pueda considerarse un sistema operativo mínimo en sí mismo. Como GRUB es el cargador "Gran unificado" y no sólo el cargador Linux, su sintaxis no se relaciona con la del kernel de Linux.

Configuración global GRUB

Con la parte difícil ya explicada, volvamos a la sección global del archivo de configuración GRUB, que es, todas las líneas que aparecen antes que una línea inicie con title.

Las siguientes entradas se encuentran a menudo dentro de la sección global.

Table 1. Sintaxis de configuración global GRUB

Lo que GRUB llama... ... Linux llamaría...

(hd0,0)/grub/splash.xpm.gz /boot/grub/splash.xpm.gz

(hd0,2)/etc/passwd /etc/passwd

(hd1,6)/log/dmesg /var/log/dmesg

(hd1,4)/elvis/civgame+0220.sav.gz /home/elvis/civgame+0220.sav.gz

(fd0,0)/syslinux.cfg /mnt/floppy/syslinux.cfg

(hd0,0)/vmlinuz-2.6.9-5.EL /boot/vmlinuz-2.6.9-5.EL

(hd0,0)/initrd-2.6.9-5.EL.img /boot/initrd-2.6.9-5.EL.img

default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz password --md5 $2$MrXSq0xS$0LXqkBTfpywyD3TVCao3d0 hiddenmenu

Palabra clave Propósito

default=N Define la entrada del menú por defecto, si el usuario no escoge ninguna. Las entradas de menú se cuentan empezando desde 0.

timeout=NEspecifica la cantidad de tiempo (en segundos) que el usuario tiene para escoger una entrada de menú, antes de utilizar la entrada del menú predeterminada.

splashimage=file Usa file como una imagen de fondo para el menú.

password plaintext Especifica una contraseña para la aplicación GRUB utilizando texto sin formato.

password --md5 ciphertext

Especifica una contraseña para la aplicación GRUB con codificación MD5.

hiddenmenu No muestra el menú GRUB en el arranque.

[Caution] Utilice password, no passwdUn error común dentro del archivo de configuración GRUB es el uso incorrecto de la palabra clave passwd , en lugar de password.

Configuración de elementos del menú de GRUB

En el arranque, GRUB suele presentar al usuario un menú de posibles configuraciones. Dichas configuraciones vienen en estrofas en el archivo de configuración grub.conf que comienza por la palabra clave title, seguida por texto utilizado para etiquetar la estrofa como se ilustra a continuación.

La siguiente sintaxis se encuentra en elementos del menú utilizados para arrancar kernels de Linux. A diferencia de la sección global, los elementos individuales deben aparecer en el orden especificado.

Table 1. Sintaxis de configuración de los elementos del menú de GRUB

Observe cómo el diseño de una estrofa de un elemento de menú refleja los parámetros necesarios. La línea de configuración kernel especifica la imagen de kernel para cargar y su línea de comando asociada, mientras que la línea de configuración initrd especifica un disco RAM inicial a cargar.

Uso de GRUB

Por lo general, el grub se instala con el instalador de Anaconda y se utilizará cada vez que se inicie el sistema. Cuando GRUB se ejecuta, primero muestra un texto sencillo en el inicio y luego presenta al usuario un menú gráfico y en la configuración predeterminada de Red Hat Enterprise Linux, un temporizador de conteo regresivo desde 10.

Para nuestros propósitos, nos referiremos a GRUB como si estuviera ejecutándo en uno de los cinco modos:

Modo seguro: Este modo presenta al usuario un menú de selecciones de arranque.

Modo básico: El modo básico se parece al modo seguro, pero en lugar de seleccionar el elemento del menú, el usuario puede optar por entrar en los siguientes modos.

Modo de edición: Este modo permite al usuario hacer correcciones en una configuración existente.

Modo de agregar: Semejante al modo de edición, este modo permite al usuario corregir la línea de comandos del kernel.

Modo de comando: En este modo, el usuario opera dentro de una shell interactiva grub.

title Red Hat Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ rhgb quiet vga=0x317 initrd /initrd-2.6.9-5.EL.img

Palabra clave Propósito

root partition Monta y utiliza de modo implícito el partition especificado en todas las referencias de archivo posteriores.

kernel filecommandline...

Carga el archivo especificado como imagen de kernel y pasa los argumentos al kernel como línea de comando del kernel.

initrd file Carga el archivo especificado como un disco RAM inicial para el kernel.

Cada uno de los modos se trata detalladamente a continuación.

Modo seguro

El modo seguro es el modo predeterminado si una contraseña se especificó en el archivo de configuración grub.conf. Grub presenta el usuario con un menú, cuyos títulos son una reflexión directa de las líneas title que se encuentran en el archivo de configuración grub.conf. Al seleccionar un elemento del menú, el sistema inicia con la configuración especificada.

Si se especifica la contraseña correcta, el usuario puede saltar del modo seguro al modo básico.

Modo básico

El modo básico es el modo por defecto si no se proporciona una contraseña en el archivo de configuración grub.conf. Los usuarios pueden elegir un elemento de menú apropiado o pueden utilizar cualquiera de las siguientes claves para entrar en uno de los modos a continuación.

Table 1. Comandos para cambiar de modo en GRUB.

Modo de edición

Al entrar el modo de editar, grub muestra líneas desde la estrofa grub.conf pertinente en un editor de texto primario. El editor le permite al usuario agregar una nueva línea, borrar una línea existente o editar una línea existente con cambios arbitrarios.

Una vez el usuario ha editado la estrofa a su gusto puede utilizar b para iniciar con una nueva configuración o ESC para abandonar todos los cambios y volver al modo básico.

En cualquier evento, los cambios a la configuración hechos con el modo de edición de grub se aplican a ese inicio únicamente. La aplicación grub no permite a los usuarios editar archivos de modo permanente.

Modo de agregar

El modo de agregar puede considerarse como una reducción del modo de edición, donde sólo los argumentos que componen la línea de comando del kernel se pueden editar. Aunque es menos versátil (un nuevo kernel o archivo initrd no se podría especificar, por ejemplo) el modo de agregar se puede utilizar en la mayoría de los casos cuando un usuario desee sobrescribir la configuración grub por defecto. Como en el modo de edición, los cambios se aplican sólo en ese inicio.

Modo de comando

En el modo de comando, se omite el archivo existente grub.conf y el usuario opera en una shell interactiva grub, (en este caso, el término shell se utiliza en el sentido general. ¡No espere encontrar todas las capacidades de la shell bash !) Los usuarios expertos pueden usar la shell para especificar un kernel e initrd de modo manual e iniciar el sistema, o usar la shell para examinar el sistema de archivos.

clave Acción

e entra el modo de edición para el elemento de menú seleccionado

a entra el modo de agregar para el elemento de menú seleccionado

c entra el modo de comando

Se puede salir de la shell grub con la tecla ESC, la cual devuelve al usuario al modo básico.

Instalación de GRUB

Cuando la gente se refiere a la instalación de un gestor de arranque, por lo general se refieren a transferir la primera etapa del gestor de arranque al registro de arranque maestro o al sector de arranque apropiados. Los administradores de sistemas rara vez necesitan reinstalar la primera etapa del gestor de arranque GRUB, cuando Anaconda la instala tras la instalación del sistema y aparte de los cambios al archivo de configuración grub.conf, la instalación no se debería

modificar para uso rutinario. [1]

Sin embargo, si por alguna razón necesita instalar GRUB puede utilizar grub-install. El comando se llama con un solo argumento, el nombre del dispositivo cuyo registro de arranque maestro se puede utilizar para la instalación.

Tras la instalación, grub-install muestra la interpretación actual del "Dispositivo BIOS #1" (o los dispositivos a los que se haga referencia). Por lo general, esta información es correcta. Si no parece apropiada, se tendría que editar el archivo /boot/grub/device.map y ensayar de nuevo.

Administración de contraseñas de GRUB

Como veremos más adelante, la habilidad de modificar la línea de comando del kernel en el arranque proporciona una gran flexibilidad, pero a su vez trae riesgos de seguridad. Por ejemplo, al proveer los argumentos apropiados, se puede iniciar el sistema en una shell de mantenimiento desde la cual se puede cambiar la contraseña de la cuenta de root. Por consiguiente, se sugiere proveer una contraseña en el archivo de configuración grub.conf.

Aunque el archivo de configuración admite contraseñas en texto sin formato, el almacenamiento de contraseñas en texto sin formato en el sistema de archivos nunca es una buena idea.

En su lugar, se puede utilizar el comando grub-md5-crypt para generar contraseñas encriptadas, las cuales se pueden pegar en el archivo de configuración, como a continuación.

La siguiente línea se pudo incluir en el archivo de configuración grub.conf.

[root@station root]# grub-install /dev/hda Installation finished. No error reported. This is the contents of the device map /boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. # this device map was generated by anaconda (fd0) /dev/fd0 (hd0) /dev/hda

password redhat

[root@station root]# grub-md5-crypt Password: redhat Retype password: redhat $2$vCoF50$x48AkrGLEoXPznNiWnqhA.

password --md5 $2$vCoF50$x48AkrGLEoXPznNiWnqhA.

Esta línea establece la contraseña de GRUB para redhat, pero no deja la contraseña expuesta en texto sin formato en el archivo de configuración.

Limitaciones de BIOS y GRUB

Cuando la aplicación GRUB se está ejecutando, el kernel de Linux aún no está en su sitio. Por consiguiente, GRUB utiliza controladores de dispositivos de BIOS para acceder a los discos. Algunos controladores más antiguos no tienen limitaciones significativas.

1. Algunos BIOS no pueden acceder más de 1.024 cilindros.

2. Muchos de los BIOS son sólo conscientes de las particiones primarias.

La primera limitación es la motivación para la partición /boot. Por diseño, la partición /boot debe contener todos los elementos del sistema necesarios antes que el kernel de Linux se cargue: la imagen misma del kernel, cualquier initrd y el gestor de arranque. La partición es por lo general pequeña y se presenta tan pronto como sea posible en el dispositivo, para que se ajuste totalmente dentro de los primeros 1.024 cilindros de disco.

Dicho esto, la mayoría de BIOS modernos proporcionan extensiones que superan esta limitación.

De manera interesante, un sistema Linux se puede operar bastante bien sin montar la partición /boot, (recuerde que sólo se encuentran los aspectos del sistema que se necesitan antes de iniciar el kernel). En la práctica, no es una buena idea, puesto que hay un archivo ocasional al cual se hace referencia desde el sistema de ejecución (tal como System.map, o el archivo de configuración grub.conf, si el administrador desea hacer cambios).

La segunda limitación sólo afecta a donde GRUB puede instalarse si otro gestor de arranque se utiliza en el registro de arranque maestro. Es decir, sólo los sectores de arranque de particiones primarias son candidatos para la instalación de la primera etapa GRUB. Esto no se considera una configuración estándar y los detalles de configuración van más allá de los objetivos de este curso.

Al cerrar, volvemos a hacer énfasis en que estas dos limitaciones están relacionadas con BIOS no con Linux. Cuando el kernel de Linux está en ejecución, ninguna de estas limitaciones importa.

El kernel de Linux

La lección anterior presentó la inicialización de Linux ocurriendo en cuatro fases diferentes. Esta lección trata principalmente del gestor de arranque; las siguientes dos lecciones describirán /sbin/init y los procesos relacionados. Entre estos dos está la sección corta, la cual proporciona algo más que una transición y describe la función del kernel al cargarlo en el sistema.

Aunque se puede decir mucho de la inicialización del kernel desde el punto de vista del diseño de sistemas operativos, desde el punto de vista de la administración del sistema, hay muy poco que decir. No obstante, lo que hay que decir es importante. En esencia, un administrador de sistemas puede ver el kernel mientras realiza tres etapas.

1. Remplaza todos los controladores de dispositivos BIOS con controladores de dispositivos Linux.

2. Monta la partición root de sólo-lectura.

3. Inicia el primer proceso.

El kernel hace muy poco para inicializar el sistema y confía en que el primer proceso haga todo el

trabajo difícil.

Hay algunas repercusiones asociadas con cada paso.

1. Puesto que Linux remplaza todos los controladores de dispositivos BIOS, las limitaciones de BIOS mencionadas anteriormente no son relevantes una vez que el kernel inicia.

2. Puesto que el kernel debe montar la partición raíz, se le debe decir qué partición es la correcta para el montaje. Esto generalmente se realiza con el parámetro de línea de comando del kernel de root=, el cual puede referirse a una partición específica (tal como root=/dev/hda5) o como el comando mount, puede hacer referencia a la partición raíz por su etiqueta de sistema de archivos ext2 (mediante una sintaxis bastante extraña root=LABEL=/). ¿Por qué el kernel lo monta de sólo lectura, en lugar de lectura-escritura? La respuesta se encuentra en una próxima lección.

3. Como el kernel inicia el primer proceso directamente, se debe especificar la partición root correcta. El nombre del primer proceso está fijado en el kernel: /sbin/init. El kernel montará como partición root cualquier partición que usted le diga, pero sólo podrá hallar /sbin/init si usted le da la correcta.

La línea de comandos del kernel: parámetros de arranque

Así como los procesos tienen una línea de comandos, el kernel también tiene una línea de comandos. Los parámetros de la línea de comandos para el kernel actual se pueden examinar al leer /proc/cmdline.

Los símbolos especificados según el nombre de archivo del kernel en el archivo de configuración grub.conf se pasan al kernel, el cual los administra de la siguiente manera.

1. Primero, el kernel comprueba si el símbolo es un parámetro incorporado del kernel. Si lo es, el kernel aplica el parámetro. Algunos de los parámetros más comunes del kernel están documentados en la página de manual bootparam(7).

2. Segundo, si el kernel no reconoce el símbolo y el símbolo tiene la forma nombre=valor,el kernel pasa el valor al primer proceso como variable de entorno nombre, (el primer proceso es casi invariable /sbin/init).

3. Por último, todo lo que el kernel no reconozca y que no tenga la forma de nombre=valor, el kernel pasará al primer proceso como un argumento de línea de comandos.

Algunos de los argumentos más utilizados de la línea de comandos del kernel se encuentran en el siguiente cuadro.

Table 1. Parámetros comunes de arranque del kernel

[root@station ~]# cat /proc/cmdline ro root=LABEL=/ rhgb quiet

Parámetro Efecto

root=dispositivo Utiliza dispositivo como partición raíz (vea arriba). Este parámetro se requiere casi siempre.

roMonta la partición raíz de sólo lectura (ver arriba). Este parámetro casi siempre se requiere.

quietNo muestra mensajes en el inicio. Aunque habilitado por defecto en Red Hat Enterprise Linux, muchos administradores prefieren quitarlo para ver el flujo de mensajes del kernel.

rhgb

Este parametro del inglés "Red Hat Graphical Boot" (Arranque gráfico de Red Hat), hace que un servidor X inicie temprano en el proceso de arranque. El parámetro se puede quitar fácilmente si esto complica o retarda el proceso de arranque.

System Initialization and Services Ejemplos

Referencia a un nuevo kernel

Un administrador de sistemas compiló un kernel personalizado, creó un disco RAM asociado de inicio y lo colocó en el directorio /boot como los archivos vmlinuz-2.4.21-custom y initrd-2.4.21-custom.img, respectivamente. Ahora quiere actualizar su archivo grub.conf para poder arrancar en el nuevo kernel. Su archivo actual se ve de esta forma.

El administrador abre el archivo en un editor de texto y en primer lugar duplica la "consabida" estrofa.

Luego, el administrador edita la segunda estrofa, cambiando las referencias de título, kernel e initrd, como corresponda.

Ahora, el administrador almacena sus cambios y reinicia. Al reiniciar, puede escoger su nuevo kernel personal y el menú GRUB. Si algo sale mal (tal como un error tipográfico en el archivo de configuración grub.conf), siempre podrá reiniciar otra vez en la "consabida" entrada.

Migración a un archivo de configuración GRUB

[root@station root]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz password --md5 $2$MrXSq0xS$0LXqkBTfpywyD3TVCao3d0 title Red Hat Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ quiet rhgb initrd /initrd-2.6.9-5.EL.img

title Red Hat Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ quiet rhgb initrd /initrd-2.6.9-5.EL.img title Red Hat Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ vga=0x317 initrd /initrd-2.6.9-5.EL.img

title Red Hat Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ quiet rhgb initrd /initrd-2.6.9-5.EL.img title Red Hat Linux (2.4.21-custom) root (hd0,0) kernel /vmlinuz-2.4.21-custom ro root=LABEL=/ quiet rhgb initrd /initrd-2.4.21-custom.img

Un administrador está migrando un archivo de configuración grub.conf de un sistema a otro. Aquí está el contenido del archivo.

Como los comentarios lo implican, en el sistema original, el directorio /boot fue particionado Sin embargo en el sistema actual, solo hay una partición raíz: el dispositivo /dev/hda2. Ya que el directorio /boot ahora es parte de la partición raíz, el administrador necesita realizar los siguientes ajustes.

1. La especificación de la partición raíz necesita actualizarse para referirse al dispositivo /dev/hda2.

2. Las rutas de archivos para el kernel y el disco RAM de inicio se necesitan actualizar para reflejar el hecho que el directorio /boot es ahora parte del sistema de archivos raíz.

Puesto que en la nueva máquina, la configuración original no funcionará, decide modificar la estrofa "en su sitio". La estrofa modificada se lista a continuación.

[root@station root]# cat /boot/grub/grub.conf # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda3 # initrd /initrd-version.img #boot=/dev/hda default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz password --md5 $2$MrXSq0xS$0LXqkBTfpywyD3TVCao3d0 title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ vga=0x317 initrd /initrd-2.6.9-5.EL.img

title Red Hat Linux (2.6.9-5.EL) root (hd0,1) kernel /boot/vmlinuz-2.6.9-5.EL ro root=LABEL=/ vga=0x317 initrd /boot/initrd-2.6.9-5.EL.img

System Initialization and Services Ejercicios en línea

Specification

Usted va a copiar (¡no a mover!) su kernel existente e initrd a un nuevo sitio y va a modificar su grub.conf de modo apropiado para arrancar el kernel recién creado.

1. Crear el directorio /kernel.

2. Utilizar el comando uname -r para reportar su versión de kernel actual.

3. Copiar los archivos /boot/vmlinuz-versión de kernel y /boot/initrd-versión_de_kernel.img al directorio /kernel recién creado. Asegúrese de copiar el archivo empezando por vmlinuz, no vmlinux.

4. Como precaución, haga una copia de seguridad de su archivo /boot/grub/grub.conf, llamado /boot/grub/grub.conf.prelab4.2. Abra su archivo /boot/grub/grub.conf y haga los siguientes cambios.

a. Duplique la estrofa de los elementos del menú pertinentes a su kernel actual y establezca el título de la estrofa recién creada a la única palabra lab4.2. . No modifique su estrofa original de ninguna manera.

b. En su estrofa de elementos de menú recién creada, actualice las referencias al kernel y los archivos initrd, para que se refieran a los archivos recién creados /kernel/vmlinuz-versión_de_kernel y /kernel/initrd-versión de kernel.img. Probablemente también tendrá que actualizar la referencia a la partición raíz.

c. En la línea de comandos del kernel, agregue el argumento panic=42, (puede consultar la página del manual bootparam(7) para obtener mayor información).

d. Establezca la contraseña del gestor de arranque como redhat con una contraseña en texto sin formato, (si el gestor de arranque ya tiene contraseña, quite el comentario de la línea que especifica la contraseña original).

Guarde sus cambios.

5. Reinicie su máquina. En el menú GRUB, entre la contraseña del gestor de arranque (redhat). Abra la estrofa recién agregada(lab4.2) para editarla. Dentro del editor, agregue el argumento rha=fun a la línea de comandos del kernel, sin cambiar los otros argumentos y por último, inicie su máquina.

6. Una vez iniciado, inicie sesión en su cuenta de Red Hat Academy y califique su ejercicio.

[Warning] Lab Exercise

Objetivo: Ganar experiencia en la configuración del gestor de arranque de GRUB.

Estimated Time: 30 mins.

Resultados

A title

Question 1

[Note] NoteEn algunas máquinas, puede que no se pueda reiniciar la máquina con su nueva configuración, debido al límite de 1024 cilindros de BIOS. Si este es el caso, reinicie su máquina con la estrofa original (¿no la modificó, no es cierto?). Repita el Laboratorio pero en lugar de copiar su kernel e initrd al directorio /lab4.2, cópielos al directorio /boot/lab4.2 y edite su estrofa lab4.2 en el archivo grub.conf.

1. Un archivo del sistema de archivos /proc/cmdline que reporte los argumentos panic=42 y rha=fun.

2. Un archivo /boot/grub/grub.conf, que contenga una estrofa para un elemento del menú titulado lab4.2. El elemento del menú debería hacer referencia al sitio del nuevo kernel e initrd y especificar un argumento de línea de comandos de kernel panic=42, pero no un argumento de línea de comandos de kernel rha=fun.

grade

System Initialization and Services /sbin/init y Run Levels

Conceptos clave

El primer proceso iniciado por el kernel es /sbin/init

El comando init se ejecuta, mientras se ejecute el sistema y está encargado de iniciar y detener otros procesos.

El comando init organiza el estado de ejecución de procesos con un concepto llamado niveles de ejecución.

El comando init utiliza el archivo de configuración /etc/inittab para determinar qué procesos deberían ejecutarse en qué niveles de ejecución.

Los comandos init y telinit se pueden utilizar para cambiar niveles de ejecución o forzar init a releer su archivo de configuración.

Los comandos shutdown, reboot, halt y poweroff sirven para detener o reiniciar la máquina.


/sbin/init

El nombre del primer proceso para iniciar está fijado al kernel de Linux: /sbin/init. Este comando es ejecutado directamente por el kernel en el inicio y por lo tanto siempre tiene un Id de proceso 1. El programa init está diseñado para ejecutarse mientras se ejecuta el sistema y es el último proceso que muere. Para asegurarse que el proceso no termine accidentalmente, el Id 1 del proceso está protegido contra la señal letal SIGKILL (señal número 9).

El proceso init emplea su tiempo, iniciando, deteniéndose y monitorizando otros procesos. Lo primero que init hace es leer su archivo de configuración, el archivo /etc/inittab. Se le recomienda ver el archivo mientras lee esta explicación, pero tenga cuidado de no modificarlo accidentalmente: Es un archivo de configuración clave y si se daña no se podría arrancar su sistema.

Niveles de ejecución

A continuación, extraemos y explicamos varias líneas del archivo /etc/inittab. Comenzamos por examinar el comentario en la parte superior del archivo y la primera línea de configuración pertinente.

En los comentarios al comienzo del archivo, vemos que init organiza una máquina Linux mediante un concepto llamado en inglés runlevels (niveles de ejecución). Los niveles de ejecución tradicionalmente se nombran con números enteros de 0 a 6. En muchas versiones de Unix, los números enteros implican una secuencia (i.e., para iniciar en nivel de ejecución 5, debe pasar por los niveles de ejecución de 1 a 4). Esto no sucede en Linux; los niveles de ejecución pudieron haberse llamado algo tan fácil como "anaranjado", "azul" y "verde".

Por tradición Unix asocia las siguientes configuraciones con varios niveles de ejecución y Linux se adhiere a dicha convención.

Table 1. Convenciones de los niveles de ejecución

# # inittab This file describes how the INIT process should set up # the system in a certain run-level. # # Author: Miquel van Smoorenburg, <[email protected]> # Modified for RHS Linux by Marc Ewing and Donnie Barnes # # Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) # id:3:initdefault:

Nivel de ejecución

Uso Comentarios

La última línea en el listado anterior establece el nivel de ejecución predeterminado para la máquina, si no se especifica ninguno. Para la mayoría de las máquinas, el nivel de ejecución sería el nivel de ejecución 3 o 5.

Sintaxis /etc/inittab

Cuando trate de aprender la sintaxis del archivo /etc/inittab, la primera línea (que establece el nivel de ejecución por defecto) no es útil; no sigue la sintaxis. Todas las demás líneas que constan de 4 campos separados por dos puntos sirven para las siguientes funciones.

Table 1. Sintaxis /etc/inittab

El tercer campo se debe seleccionar de una selección de acciones predefinidas. Algunas de las acciones más comunes y su uso se listan a continuación.

Table 2. Acciones utilizadas en el archivo /etc/inittab

0 Halt Una utilidad de nivel de ejecución utilizada para detener la máquina.

1Modo monousuario

Un nivel de ejecución de mantenimiento conocido como un Modo monousuario. Cuando se está en nivel de ejecución 1, solo root puede iniciar en la máquina y debe iniciar en la consola. Las conexiones de red por lo general no están activas y la mayoría de los demonios (si no todos) están apagados. Este nivel de ejecución está diseñado para realizar operaciones de mantenimiento, tales como montar y desmontar particiones sin interferencias inesperadas.

2 No NFS

En Unix tradicional, el nivel de ejecución 2 era de modo multiusuario sin red (recuerde que en un comienzo, Unix era esencialmente un servidor de terminal.) La mayoría de Unix modernos utilizan el nivel de ejecución 2 para de alguna manera calificar la extensión de red. En Red Hat Enterprise Linux, el nivel de ejecución 2 implica modo multiusuario de red, pero sin ningún sistema de archivos NFS relacionado.

3Multiusuario total

El nivel de ejecución 3 es un modo operativo total de red y multiusuarios, pero no se inicia ninguna interfaz gráfica (servidor X). En muchas máquinas utilizadas como servidores de red, este es el nivel de ejecución predeterminado.

4Configuración local

El nivel de ejecución 4 suele no tener implicaciones y se deja para que los sitios lo utilicen en la implementación de políticas locales.

5Multiusuario con X

El nivel de ejecución 5 tiene todas las implicaciones del nivel de ejecución 3, más el mantenimiento continuo de un servidor X.

6 rebootUna utilidad de nivel de ejecución utilizada para reiniciar la máquina.

Campo Uso

1Una etiqueta de sólo dos letras, aparte la etiqueta debe ser única. La etiqueta que init utiliza para mantener todas sus líneas rectas.

2 Una lista de los niveles de ejecución para los cuales es importante la línea.

4 El nombre del comando a ejecutar.

3El tercer campo es el más interesante. Consiste de un acción predefinido, el cual dice a init cómo o cuándo ejecutar el comando especificado en el cuarto campo.

/etc/inittab Configuración de inicialización del sistema y administración del nivel de ejecución

Con la sintaxis de reserva, pasamos por el resto del archivo /etc/inittab, agregando comentarios cuando se ameriten.

Tras el inicio del sistema, se ejecuta el script /etc/rc.d/rc.sysinit. El script se estudiará en detalle más adelante, donde descubriremos que el script de inicialización es la clave para realizar muchas de las inicializaciones del sistema.

Después de cada cambio de nivel de ejecución (incluyendo el arranque en el nivel de ejecución inicial predeterminado), el script /etc/rc.d/rc se ejecuta con el nivel de ejecución apropiado como su único argumento. Este script realiza todo el trabajo difícil cuando el sistema pasa de un nivel de ejecución a otro, este será el tema de la próxima lección.

Configuración para eventos externos /etc/inittab

Los próximos líneas asocian comandos con varios eventos externos, tales como un usuario tecleando CONTROL-ALT-SUPR en la consola o una UPS registrando una falla de energía. La mayoría de estas variantes del comando shutdown se tratan en detalle a continuación (aunque la intención del comando debería ser obvia).

acción uso

respawninit inicia y monitoriza el comando especificado. Si el comando alguna vez muere, inicia otro para remplazarlo.

waitinit inicia el proceso cuando entra a un nivel de ejecución pertinente y espera que el proceso termine antes de llevar a cabo todo lo demás.

ctrlaltdelinit ejecutará el comando asociado cuando alguien tecleeCONTROL-ALT-SUPR en el teclado de la consola.

powerfail (y amigos)

init iniciará comandos en respuesta a recibir señales para una UPS (suministro de alimentación ininterrumpible) agregada.

# System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel. ud::once:/sbin/update # Trap CTRL-ALT-DELETE ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, assume we have a few minutes # of power left. Schedule a shutdown for 2 minutes from now. # This does, of course, assume you have powerd installed and your # UPS connected and working correctly. pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down" # If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Canceled"

/sbin/init y Gettys

Otro uso tradicional del proceso init es el lanzamiento, monitorización y relanzamiento de gettys. En Linux (y Unix), un getty (llamado por "get tty") (obtener tty) es un proceso que monitoriza una línea serial. Siempre que escucha un "ruido" en la línea (tal como cuando alguien teclea ENTER varias veces), escribe una aviso en la línea, y espera de vuelta un nombre de usuario. Cuando recibe el nombre de usuario, éste ejecuta el comando login para continuar el proceso de inicio de sesión. Cuando un usuario sale, el proceso de inicio (el cual es un proceso getty) muere e init regenera un nuevo getty para ocupar su lugar.

Un getty se debe lanzar para monitorizar cada línea serial en que los usuarios puedan iniciar sesión. Las líneas de configuración anteriores lanzan un mingetty para cada una de las primeras 6 consolas virtuales. ¿Por qué Linux suele tener seis consolas virtuales en las que los usuarios pueden iniciar sesión? Porque init genera seis gettys. Si un administrador quisiera proporcionar más consolas virtuales, se podrían añadir o suprimir más líneas.

Igualmente si una terminal estuviera conectada al puerto serial de una máquina, los usuarios podrían utilizar la terminal hasta que una getty fuera conectada a la línea serial. Si se agrega la siguiente línea al archivo /etc/inittab, resolverá el problema para el primer puerto serial.

Por último, la última línea es lo que distingue principalmente al nivel de ejecución 3 del nivel de ejecución 5. En el nivel de ejecución 5, init de modo consistente regenera el script /etc/X11/prefdm, el cual comienza por el "gestor de pantalla preferido", i.e., el servidor X el cual le permite al usuario iniciar en la máquina mediante una interfaz gráfica.

Como un ejemplo tangible de la capacidad de init para regenerar procesos, vaya a una máquina que esté en pantalla gráfica de inicio y utilice la combinación de teclas CONTROL-ALT-RETROCESO para matar el servidor gráfico X. Después de una corta pausa, init generará un nuevo servidor X para ocupar su lugar.

Manejo de Init

Observar los niveles de ejecución con runlevel

El comando runlevel se puede utilizar para observar el nivel de ejecución actual de la máquina.

La salida no es tan simple como parecía porque se dan dos valores. El último es el nivel de

# Run gettys in standard runlevels 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6

s0:2345:respawn:/sbin/mingetty ttyS0

# Run xdm in runlevel 5 # xdm is now a separate service x:5:respawn:/etc/X11/prefdm -nodaemon

[root@station root]# runlevel N 5

ejecución actual, el primero es el nivel de ejecución anterior o “N” para una máquina recién iniciada. La salida anterior corresponde a una máquina recién iniciada en el nivel de ejecución 5.

Cambio de niveles de ejecución con init o telinit

A init se le puede pedir que cambie los niveles de ejecución al invocarlo con el nivel de ejecución deseado como único argumento.

El cambio de niveles de ejecución tiende a ser violento. Los procesos mueren, sacan los usuarios de la máquina. En máquinas de multiusuarios, los administradores tratan de programar cambios en el nivel de ejecución (por ejemplo pasar a modo monousuario para realizar tareas de mantenimiento) con el fin de no tomar por sorpresa a los usuarios.

En algunas versiones de Unix, el proceso init no está diseñado para uso reentrante y se utiliza un segundo comando telinit para cambiar los niveles de ejecución. En Linux, tanto init como telinit sirven para cambiar los niveles de ejecución.

Solicitar init para releer /etc/inittab

Aunque el proceso init lee su archivo de configuración en el inicio, una vez leído ya no se monitoriza más. Si se le hacen modificaciones al archivo se le puede pedir al proceso init que relea el archivo y aplique los cambios con el comando init q.

Apagar la máquina con shutdown

Lo cierto de cualquier sistema operativo multitareas es que hay formas correctas e incorrectas de apagar una máquina Linux. Las formas incorrectas incluyen desconectar el cable de alimentación. A continuación trataremos las formas correctas.

En principio, una máquina de Linux se apaga al cambiar a nivel de ejecución 0 (por razones que veremos en la próxima lección). Por lo tanto, el comando init se puede utilizar para iniciar un apagado instantáneo de una máquina.

Por lo general. los administradores prefieren utilizar un comando llamado shutdown o una de sus variantes. El comando shutdown tiene dos ventajas. Primero, el apagado se puede programar para que ocurra a una hora determinada. Segundo, se anuncia el apagado a las terminales de todos los usuarios conectados y con esto se les da la oportunidad de cerrar su trabajo y salir.

El comando shutdown utiliza la siguiente sintaxis.

Table 1. Opciones del comando shutdown

[root@station root]# init 3

[root@station root]# init 0

/sbin/shutdown [-hprc] time [warning-message]

Opción Efecto

-h Detener la máquina

El comando shutdown suele llamarse con las opciones -h, -p, o -r, para que la máquina se detenga, se apague o reinicie, respectivamente. Si no se especifica ninguna de los tres, shutdown lleva la máquina al nivel de ejecución 1. La opción -c se puede utilizar para cancelar un apagado pendiente.

El argumento de tiempo obligatorio se puede especificar de tres maneras.

Table 2. Especificar tiempos para el comando shutdown

También existen unos atajos poco conocidos para el comando shutdown que presentamos a continuación.

Table 3. Atajos para el comando shutdown

El script /etc/rc.d/rc.sysinit

Tras el arranque, el kernel inicia el proceso /sbin/init. El comando init examina el archivo /etc/inittab, donde encuentra lo siguiente como su primera línea relevante.

Traduciendo esta línea dice init "en el inicio, sólo en el inicio, ejecute el script /etc/rc.d/rc.sysinit". Ahora veremos el script de inicio en detalle. El script rc.sysinit es un complicado script de shell bash, el cual realiza una gran cantidad de tareas. No podremos dar cada detalle del script, pero extraemos algunas partes importantes o puntos interesantes con comentarios.

No piense que necesita recordar todos los detalles o todo lo que se presenta. Se puede excusar a quien trate de pasar por alto extractos de código bash como muchos harían con ecuaciones de física. Sin embargo, mientras lee los comentarios debería realizar una lista en su mente de las acciones que un script realiza cada vez que el sistema arranca. Para el interesado en saber más, también podría componer un segundo listado de los trucos de programación de la shell bash.

Antes de empezar, recordemos el estado de la máquina. El kernel ha sido iniciado, se ha montado la partición raíz de solo lectura y se ha iniciado init, el cual a su vez inició este script. Cuando se

-p Después de detener la máquina, apáguela.

-r Reiniciar la máquina

-c Cancelar un apagado pendiente

Sintaxis Interpretación

hh:mm Un tiempo absoluto cuando el apagado debe ocurrir, en horas y minutos.

+n Un tiempo relativo cuando el apagado debe ocurrir en n minutos.

ahora Un sinónimo para + 0.

Atajo Comando equivalente

halt shutdown -h now

poweroff shutdown -p now

reboot shutdown -r now

si::sysinit:/etc/rc.d/rc.sysinit

ejecuta este script, ¿cuántos procesos se están ejecutando en la máquina? Dos. ¿A qué se parece el sistema de archivos? Sólo la partición raíz está montada y está montada de sólo lectura.

El script comienza por examinar /etc/sysconfig/network para determinar un nombre de host para el sistema. Luego, en el proceso de inicio, el sistema de archivos proc se monta en el directorio /proc.

Luego, el script hace un gran esfuerzo examinando el archivo /etc/redhat-release para decidir a qué llamar en el mensaje de bienvenida que muestra.

#!/bin/bash # # /etc/rc.d/rc.sysinit - run once at boot time # ... HOSTNAME=`/bin/hostname` if [ -f /etc/sysconfig/network ]; then . /etc/sysconfig/network else NETWORKING=no fi if [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" ]; then HOSTNAME=localhost fi # Mount /proc (done here so volume labels can work with fsck) action $"Mounting proc filesystem: " mount -n -t proc /proc /proc ...

... # Print a text banner. echo -en $"\t\tWelcome to " if LC_ALL=C grep -q "Red Hat" /etc/redhat-release ; then [ "$BOOTUP" = "color" ] && echo -en "\\033[0;31m" echo -en "Red Hat" [ "$BOOTUP" = "color" ] && echo -en "\\033[0;39m" PRODUCT=`sed "s/Red Hat $.*$ release.*/\1/" /etc/redhat-release` echo " $PRODUCT" else PRODUCT=`sed "s/ release.*//g" /etc/redhat-release` echo "$PRODUCT" fi if [ "$PROMPT" != "no" ]; then echo -en $"\t\tPress 'I' to enter interactive startup." echo fi

Un gran esfuerzo en determinar cómo hacerlo, pero el tiempo del sistema finalmente se inicializa desde BIOS con el comando /sbin/hwclock.

Luego, evitamos muchas líneas de inicialización del módulo del kernel de USB y las retomamos aquí.

# Set the system clock. update_boot_stage RCclock ARC=0 SRM=0 UTC=0 if [ -f /etc/sysconfig/clock ]; then . /etc/sysconfig/clock # convert old style clock config to new values if [ "${CLOCKMODE}" = "GMT" ]; then UTC=true elif [ "${CLOCKMODE}" = "ARC" ]; then ARC=true fi fi CLOCKDEF="" CLOCKFLAGS="$CLOCKFLAGS --hctosys" ... /sbin/hwclock $CLOCKFLAGS action $"Setting clock $CLOCKDEF: `date`" date

Alrededor de la octava línea se encuentra la línea importante: initlog -c "fsck -T -a $fsckoptions /", o reduciéndola a su esencia fsck /. Ahora entendemos la razón por la cual el kernel montó la partición raíz de sólo lectura. Un sistema de archivos montado de sólo lectura se puede ejecutar con fsck y se puede reparar, pero si es un sistema de archivos montado de lectura y escritura entonces no se puede reparar. El montaje de sólo lectura del kernel permite realizar el primer chequeo de la partición raíz. Si se presentan problemas, se envía al usuario a una shell de rescate.

Ahora que se ha ejecutado fsck, la partición raíz se puede volver a montar como de lectura y escritura con mount -o remount,rw /.

... _RUN_QUOTACHECK=0 ROOTFSTYPE=`awk '/ \/ / && ($3 !~ /rootfs/) { print $3 }' /proc/mounts` if [ -z "$fastboot" -a "X$ROOTFSTYPE" != "Xnfs" ]; then STRING=$"Checking root filesystem" echo $STRING initlog -c "fsck -T -a $fsckoptions /" rc=$? if [ "$rc" = "0" ]; then success "$STRING" echo elif [ "$rc" = "1" ]; then passed "$STRING" echo fi # A return of 2 or higher means there were serious problems. if [ $rc -gt 1 ]; then if [ "$BOOTUP" = "graphical" ]; then chvt 1 fi failure "$STRING" echo echo echo $"*** An error occurred during the file system check." echo $"*** Dropping you to a shell; the system will reboot" echo $"*** when you leave the shell." str=$"(Repair filesystem)" PS1="$str \# # "; export PS1 sulogin echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" = "1" ]; then _RUN_QUOTACHECK=1 fi fi

... # Remount the root filesystem read-write. update_boot_stage RCmountfs state=`awk '/ \/ / && ($3 !~ /rootfs/) { print $4 }' /proc/mounts` [ "$state" != "rw" ] && \ action $"Remounting root filesystem in read-write mode: " mount -n -o remount,rw /

Si se está utilizando la administración de un volumen lógico, la puede iniciar en este momento. También active cualquier partición swap. Luego evite varias líneas iniciando módulos de kernel y activando el RAID de software, si lo está utilizando.

Al reanudar, recuerde el estado actual del sistema de archivos. Ahora la partición raíz se monta de lectura y escritura, pero aún es la única partición montada.

De nuevo, la línea importante se presenta alrededor de la octava línea en initlog -c "fsck -T -R -A -a $fsckoptions" , o, reduce, fsck -A. Todos los sistemas de archivos restantes (desmontados) se están comprobando. El resto de la estrofa lleva al sistema a una shell de rescate si se presentan problemas mayores.

# LVM initialization if [ -f /etc/lvmtab -a ! -e /proc/lvm ] ; then modprobe lvm-mod >/dev/null 2>&1 fi if [ -e /proc/lvm -a -x /sbin/vgchange -a -f /etc/lvmtab ]; then action $"Setting up Logical Volume Management:" /sbin/vgscan && /sbin/vgchange -a y fi # Start up swapping. update_boot_stage RCswap action $"Activating swap partitions: " swapon -a -e

... _RUN_QUOTACHECK=0 # Check filesystems if [ -z "$fastboot" ]; then STRING=$"Checking filesystems" echo $STRING initlog -c "fsck -T -R -A -a $fsckoptions" rc=$? if [ "$rc" = "0" ]; then success "$STRING" echo elif [ "$rc" = "1" ]; then passed "$STRING" echo fi # A return of 2 or higher means there were serious problems. if [ $rc -gt 1 ]; then if [ "$BOOTUP" = "graphical" ]; then chvt 1 fi failure "$STRING" echo echo echo $"*** An error occurred during the file system check." echo $"*** Dropping you to a shell; the system will reboot" echo $"*** when you leave the shell." str=$"(Repair filesystem)" PS1="$str \# # "; export PS1 sulogin echo $"Unmounting file systems" umount -a mount -n -o remount,ro / echo $"Automatic reboot in progress." reboot -f elif [ "$rc" = "1" -a -x /sbin/quotacheck ]; then _RUN_QUOTACHECK=1 fi fi

Ahora que el resto de sistemas de archivos han sido ejecutados con fsck, se ejecuta el comando importante mount -a. Los sistemas de archivos de red tales como NFS y SMB, no se montan en este momento.

En este punto, todo el sistema de archivos debe estar en su lugar. Recordemos qué procesos se están ejecutando en la máquina: init, este script y cualquier proceso que este script haya iniciado. En otras palabras, no muchos.

Todas estas líneas están limpiando el sistema de archivos de los variados archivos PID dejados por demonios y archivos de bloqueo y sockets de varias aplicaciones desde el arranque anterior. También se restablecen, las propiedades y permisos para dispositivos que podrían aún ser reclamados por un usuario de una consola no existente.

Es interesante que el espacio swap se reactiva otra vez. Es necesari, porque el sistema podría estar utilizando un archivo de intercambio contenido en algún lugar diferente al de la partición raíz. Ahora pasamos por alto una gran cantidad de configuración miscelania y terminamos con lo siguiente.

# Mount all other filesystems (except for NFS and /proc, which is already # mounted). Contrary to standard usage, # filesystems are NOT unmounted in single user mode. action $"Mounting local filesystems: " mount -a -t nonfs,smbfs,ncpfs -O no_netdev

... # Clean out /. rm -f /fastboot /fsckoptions /forcefsck /.autofsck /halt /poweroff ... # Clean up /var. I'd use find, but /usr may not be mounted. for afile in /var/lock/* /var/run/* ; do if [ -d "$afile" ]; then case "$afile" in */news|*/mon) ;; */sudo|*/vmware) rm -f $afile/*/* ;; *) rm -f $afile/* ;; esac else rm -f $afile fi done rm -f /var/lib/rpm/__db* # Reset pam_console permissions [ -x /sbin/pam_console_apply ] && /sbin/pam_console_apply -r ...

... # Now turn on swap in case we swap to files. swapon -a action $"Enabling swap space: " /bin/true

... # Now that we have all of our basic modules loaded and the kernel going, # let's dump the syslog ring somewhere so we can find it later dmesg -s 131072 > /var/log/dmesg ...

Recordemos que el archivo /var/log/dmesg contiene una copia de mensajes del kernel grabada pronto después del arranque más reciente. Aquí es donde se crea el archivo.

Resumiendo, hallamos que el script rc.sysinit hace un montón de cosas (omitimos cerca de la mitad), pero aquí está lo más importante. En la entrada, el sistema de archivos consta de sólo la partición raíz, montada como de sólo lectura. En la salida, el sistema de archivos se revisa todo, se monta y limpia, listo para utilizarlo.

Ahora el proceso de arranque continúa con el nivel de ejecución específico, el cual es el tema de la siguiente lección.

System Initialization and Services Ejemplos

Personalizar CONTROLALTSUPR para un portátil.

Un propietario de un computador portátil se dio cuenta que pocas veces necesitaba reiniciar su portátil, pero en cambio con frecuencia estaba apagándolo para guardarlo y llevarlo con él. Modificó su archivo /etc/inittab para personalizar la conducta de la secuencia de teclas CONTROL-ALT-SUPR. El extracto a continuación muestra la línea original y la línea modificada.

#ca::ctrlaltdel:/sbin/shutdown -t3 -r now ca::ctrlaltdel:/sbin/poweroff


Specification

1. Como precaución, haga una copia de seguridad de su archivo /etc/inittab en el archivo /etc/inittab.prelab4.

2. Realice los siguientes cambios en su archivo /etc/inittab. En ningún caso deberían cambiar el primer campo de dos letras de una línea.

a. Quite el comentario de las líneas que regeneren gettys para las consolas virtuales número cinco y seis.

b. Duplique la línea que conecta un comando con la secuencia de teclas CONTROL-ALT-SUPR. Quite el comentario de la línea original, edite la nueva copia para que en lugar de reiniciar la máquina, la secuencia de teclas CONTROL-ALT-SUPR ejecute con echo el mensaje en inglés Three finger salute disabled, (este cambio sólo puede observarse desde la consola virtual cuando el servidor X bloquea la secuencia de teclas CONTROL-ALT-SUPR.)

c. Modifique la línea que regenera el gestor de pantalla gráfico de tal modo que el gestor de pantalla sea regenerado tanto en el nivel de ejecución 4 como en el 5.

d. Cambie su nivel de ejecución al nivel de ejecución 3 (si no lo ha hecho todavía).

3. Cuando termine, reinicie su máquina. Después de reiniciar, su máquina debe entrar al nivel de ejecución 3.

4. Inicie sesión desde la primera consola virtual. Utilice el comando init para cambiar de modo manual desde el nivel de ejecución 3 al 4.

5. En el nivel de ejecución 4, el gestor de pantalla gráfico (pantalla de inicio de sesión) se debe iniciar con init. Inicie sesión con la cuenta de Red Hat Academy y califique el ejercicio.

Resultados

Limpieza

Después de haber completado el ejercicio, restaure su archivo original /etc/inittab colocando /etc/inittab.prelab4 de nuevo en su lugar como /etc/inittab y de modo manual cambie al nivel de ejecución 5, o reinicie su máquina.

A title

Question 1

[Warning] Lab Exercise Objetivo: Administrar el proceso init con el archivo /etc/inittab.

Tiempo estimado: 20 minutos.

1. Ningun proceso (en particular el de mingetty) se debe conectar a las terminales /dev/tty5 o /dev/tty6.

2. El comando runlevel debe revelar el nivel de ejecución actual como nivel de ejecución 4 y el nivel de ejecución anterior como nivel de ejecución 3.

3. El archivo /etc/inittab debe establecer el nivel de ejecución predeterminado a 3.

4. El proceso init debe regenerar el administrador de pantalla para los niveles de ejecución 4 y 5.

5. Desde dentro de una consola virtual, la secuencia de teclas CONTROL-ALT-SUPR debe echo la frase Three finger salute disabled, pero sin reiniciar la máquina.

grade

System Initialization and Services Scripts de servicios de Red Hat Enterprise Linux

Conceptos clave

Los scripts de servicios de Red Hat Enterprise Linux que se encuentran en el directorio /etc/rc.d/init.d.

Los servicios se pueden iniciar o detener mediante el comando service.

La configuración del nivel de ejecución predeterminado para servicios se puede realizar con el comando chkconfig.


El directorio /etc/rc.d

Mientras continuamos nuestra explicación sobre El arranque de máquinas Linux que comenzamos en lecciones anteriores, el kernel ha iniciado el proceso init, el cual a su vez ha ejecutado el script /etc/rc.d/rc.sysinit. Después de salir de este script, el sistema de archivos de la máquina se ha ensamblado. El proceso init continúa examinando el archivo /etc/inittab desde donde quedó.

Observando con mucha atención el segundo campo, init sólo ejecuta una de las siguientes líneas /etc/rc.d/rc, una para el nivel de ejecución en el que el sistema está arrancando (probablemente 3 o 5). En cualquier caso, cada línea tiene el mismo efecto; se llama el script /etc/rc.d/rc con el nivel de ejecución apropiado como un argumento.

No analizaremos el script rc directamente, pero describiremos lo que hace. Primero examinamos el diseño del directorio /etc/rc.d.

Haciendo un inventario rápido, vemos tres secuencias de comandos de scripts, varios directorios aparentemente llamados según los niveles de ejecución y un directorio init.d. Con el riesgo de ir más adelante de nosotros mismos, presentamos un resumen del contenido del directorio:

Table 1. Contenido del directorio /etc/rc.d

Al observar uno de los directorios de nivel de ejecución, hallamos lo siguiente.

... # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 ...

[root@station rc.d]$ ls -F /etc/rc.d/ init.d/ rc0.d/ rc2.d/ rc4.d/ rc6.d/ rc.sysinit* rc* rc1.d/ rc3.d/ rc5.d/ rc.local*

Archivo Tipo Propósito

rc.sysinit script sistema de inicialización en el arranque

rc.local script Personalización local de inicialización del sistema en el arranque

rc script realiza cambios en nivel de ejecución

init.d directorio contiene scripts de servicios de Red Hat Enterprise Linux

rcn.d directoriocontiene enlaces simbólicos que implementan la configuración del estado de servicios para el nivel de ejecución n.

Como lo implica la representación proporcionada por la opción -F (o el color azul claro de las entradas en la terminal), el directorio no está lleno de archivos regulares, sino de enlaces simbólicos. Si pedimos que apunte a los enlaces simbólicos, hallamos lo siguiente.

Cada enlace simbólico parece referirse a un script en el directorio /etc/rc.d/init.d. Al dar una mirada rápida a los directorios específicos de nivel de ejecución, hallamos lo mismo.

Parece que hemos descubierto un directorio importante: /etc/rc.d/init.d.

Los scripts de servicios y el directorio /etc/rc.d/init.d

El directorio /etc/rc.d/init.d tiene una función especial en Red Hat Enterprise Linux y debería ser parte del vocabulario de trabajo de cualquier administrador de Red Hat Enterprise Linux . El directorio contiene exclusivamente scripts que comparten una interfaz similar.

Cada script espera ser llamado con un sólo argumento, principalmente start, stop, restart, reload o status. Estos scripts se conocen como scripts de servicios y la mayoría manipulan directamente un demonio, el cual realiza un servicio particular.

A manera de ejemplo, el script de servicios /etc/rc.d/init.d/sshd administra el demonio /usr/sbin/sshd, el cual es el servidor para el servicio de red de Secure Shell.

Si queremos saber si el servicio está en ejecución entonces preguntamos por su status.

[root@station rc.d]$ ls -F /etc/rc.d/rc3.d/ K05saslauthd@ K40smartd@ S00microcode_ctl@ S17keytable@ S80sendmail@ K10psacct@ K45named@ S05kudzu@ S20random@ S85gpm@ K15dc_client@ K50netdump@ S08arptables_jf@ S24pcmcia@ S90crond@ K15dc_server@ K50snmpd@ S08ip6tables@ S25netfs@ S90xfs@ K15httpd@ K50snmptrapd@ S08iptables@ S26apmd@ S95atd@ K20nfs@ K50tux@ S09isdn@ S28autofs@ S97rhnsd@ K24irda@ K70aep1000@ S10network@ S55cups@ S99local@ K25squid@ K70bcm5820@ S12syslog@ S55sshd@ S99mdmonitor@ K35smb@ K73ypbind@ S13irqbalance@ S56rawdevices@ S99mdmpd@ K35vncserver@ K74nscd@ S13portmap@ S56xinetd@ K35winbind@ K74ntpd@ S14nfslock@ S59hpoj@

[root@station rc.d]$ ls -lF /etc/rc.d/rc3.d/ total 0 lrwxr-xr-x 1 root root 19 Dec 27 12:07 K05saslauthd -> ../init.d/saslauthd* lrwxr-xr-x 1 root root 16 Dec 27 12:08 K10psacct -> ../init.d/psacct* lrwxr-xr-x 1 root root 19 Dec 27 16:12 K15dc_client -> ../init.d/dc_client* lrwxr-xr-x 1 root root 19 Dec 27 16:12 K15dc_server -> ../init.d/dc_server* lrwxr-xr-x 1 root root 15 Dec 27 16:12 K15httpd -> ../init.d/httpd* lrwxr-xr-x 1 root root 13 Dec 27 12:08 K20nfs -> ../init.d/nfs* ...

[root@station init.d]$ cd /etc/rc.d/init.d/ [root@station init.d]$ ls aep1000 firstboot isdn netfs rawdevices sshd apmd functions kdcrotate network rhnsd syslog arptables_jf gpm keytable nfs saslauthd tux atd halt killall nfslock sendmail vncserver autofs hpoj kudzu nscd single winbind bcm5820 httpd mdmonitor ntpd smartd xfs crond ip6tables mdmpd pcmcia smb xinetd cups iptables microcode_ctl portmap snmpd ypbind dc_client irda named psacct snmptrapd dc_server irqbalance netdump random squid [root@station init.d]$ ./sshd Usage: ./sshd {start|stop|restart|reload|condrestart|status}

Hallamos que el demonio está despierto y en ejecución. Claro está que pudimos haber mirado directamente con el comando ps.

Si queremos detener el servicio, le pedimos al script de servicios que pare con stop.

Como el script nos pidió y como confirmamos dos veces a través de dos técnicas diferentes, el demonio sshd está muerto. No debería ser difícil determinar cómo volver a iniciar el demonio.

El demonio sshd está otra vez ejecutándose, naturalmente con un Id de proceso diferente. ¿Qué hace un restart?

Un stop, seguido por un start. ¿Qué hace un reload? Para ilustrar de una forma más directa, volvemos a cargar el demonio crond en lugar de sshd.

A diferencia de un restart, un reload es una acción sencilla y el mismo proceso suele ejecutarse después de un reload como lo era antes (observe que el Id del proceso crond es idéntico). Muchos demonios Linux (y Unix) anulan el numero de señal 1 (SIGHUP) y lo utilizan como signo para releer e implementar cambios hechos a los archivos de configuración. En otras palabras, se pueden reinicializar muchos demonios entregándoles un número de señal 1. En los viejos tiempos se referían a esto como rehupping un demonio. Aunque un restart literalmente detiene y luego inicia un demonio, un reload normalmente lo reinicia.

[root@station init.d]$ ./sshd status sshd (pid 4992) is running...

[root@station init.d]$ ps aux | grep sshd root 4992 0.0 0.1 3444 1480 ? S 05:05 0:00 /usr/sbin/sshd root 5690 0.0 0.0 3576 636 pts/2 S 05:52 0:00 grep sshd

[root@station init.d]$ ./sshd stop Stopping sshd: [ OK ] [root@station init.d]$ ./sshd status sshd is stopped [root@station init.d]$ ps aux | grep sshd root 5717 0.0 0.0 3580 640 pts/2 S 05:52 0:00 grep sshd

[root@station init.d]$ ./sshd start Starting sshd: [ OK ] [root@station init.d]$ ./sshd status sshd (pid 5729) is running...

[root@station init.d]$ ./sshd restart Stopping sshd: [ OK ] Starting sshd: [ OK ] [root@station init.d]$ ./sshd status sshd (pid 5763) is running...

[root@station init.d]$ ./crond status crond (pid 5999) is running... [root@station init.d]$ ./crond reload Reloading cron daemon configuration: [ OK ] [root@station init.d]$ ./crond status crond (pid 5999) is running...

No obstante, le advertimos acerca de los scripts de servicios que se están ejecutando desde el directorio /etc/rc.d/init.d. A continuación, observe la diferencia en los dos últimos comandos.

¿Por qué aparentemente el mismo comando produjo dos salidas diferentes? ¿Qué archivo se ejecutó en realidad en el último caso? .

Los scripts de servicios de Red Hat Enterprise Linux proporcionan un mecanismo fácil y conveniente para la administración de demonios. Después de un tiempo, /etc/rc.d/init.d/... tiende a facilitar la tarea de un administrador de Red Hat Enterprise Linux. ¿Quiere iniciar el servidor de red? /etc/rc.d/init.d/httpd start. ¿Quiere que el demonio sshd relea su archivo de configuración? /etc/rc.d/init.d/sshd reload. ¿Quiere matar al demonio ftp? Usted entiende.

Sin embargo, hay una forma aún más fácil...

Los servicios y el comando service

Debido a que los administradores suelen estar ejecutando scripts desde el directorio /etc/rc.d/init.d, se creó un atajo llamado service. El comando service espera como su primer argumento el nombre de un servicio de Red Hat Enterprise Linux y como segundo argumento un comando de una palabra tal como start, stop, etc.

¿Qué es un servicio de Red Hat Enterprise Linux? Cualquier componente del sistema administrado por un script de servicios en el directorio /etc/rc.d/init.d. Las siguientes dos líneas de comandos son exactamente iguales.

La mayoría de los servicios tienen demonios asociados a ellos. Por ejemplo, hay un servicio llamado network.

Como el nombre lo implica, los componentes de red del sistema se detienen y reinician. Como se

[root@station root]$ cd /etc/rc.d/init.d/ [root@station init.d]$ ./sshd status sshd (pid 5864) is running... [root@station init.d]$ sshd status Extra argument status.

servicio service_name comando

service service_name start

/etc/rc.d/init.d/service_name start

[root@station root]$ iniciar servicio de red Shutting down interface eth0: [ OK ] Shutting down interface eth1: [ OK ] Shutting down loopback interface: [ OK ] Disabling IPv4 packet forwarding: [ OK ] Setting network parameters: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: [ OK ] Bringing up interface eth1: [ OK ]

describirá más adelante no hay un demonio asociado de red. En cambio, el servicio de red únicamente cambia el estado del kernel.

Igualmente, algunos servicios administran más de un demonio de modo colectivo como el caso para los servicios syslog y nfs.

Lo que define un servicio no es un demonio determinado, sino la presencia de un script de servicios en el directorio /etc/rc.d/init.d. Muchos servicios administran un demonio, algunos no lo hacen, aunque algunos manejan más de un demonio en conjunto.

La administración del sistema de servicios es aún más fácil. ¿Quiere empezar a utilizar el servidor de red? service httpd start. ¿Quiere saber si el servicio de Secure Shell se está ejecutando? service sshd status.

Aunque el comando service facilita la vida a los administradores, deberían conocer el directorio /etc/rc.d/init.d y la función que realiza. Por ejemplo, ¿qué sucede si un administrador quiere iniciar el servidor SAMBA?

Un par de cosas podrían salir mal.

1. El software que implementa el servidor SAMBA no se podría instalar en el sistema.

2. El administrador podría tener incorrecto el nombre del servicio.

En cualquier caso, una mirada rápida en el directorio /etc/rc.d/init.d identificará el problema.

En este caso, el administrador se da cuenta de que simplemente ha dado un nombre incorrecto al servicio.

(Como una ayuda, los scripts de servicios que administran un demonio único se llaman generalmente por el nombre del demonio, e incluyen la “d” final. Los scripts de servicios que administran múltiples demonios (como es el caso de smb) por lo general, no incluyen la “d” final.)

[root@station root]$ service nfs status rpc.mountd is stopped nfsd is stopped rpc.rquotad is stopped [root@station root]$ service syslog status syslogd (pid 4423) is running... klogd (pid 4427) is running...

[root@station root]$ service smbd start smbd: unrecognized service

[root@station root]# ls /etc/rc.d/init.d/s* /etc/rc.d/init.d/saslauthd /etc/rc.d/init.d/smb /etc/rc.d/init.d/squid /etc/rc.d/init.d/sendmail /etc/rc.d/init.d/snmpd /etc/rc.d/init.d/sshd /etc/rc.d/init.d/single /etc/rc.d/init.d/snmptrapd /etc/rc.d/init.d/syslog

[root@station root]# service smb start Starting SMB services: [ OK ] Starting NMB services: [ OK ]

El siguiente cuadro resume los comandos que deberían ser soportados por todos los scripts de servicios. Algunos scripts de servicios admiten comandos adicionales específicos para ese servicio.

Table 1. Comandos de los scripts de servicios

Configuración del servicio de nivel de ejecución y chkconfig

Aunque nuestro paseo por el comando service fue importante, éste nos sacó de nuestro tema sobre el proceso de arranque de Red Hat Enterprise Linux, al cual nos gustaría volver. Cuando lo dejamos, estábamos explorando el directorio /etc/rc.d.

En particular, hemos observado que varios subdirectorios específicos del nivel de ejecución contenían de forma meticulosa enlaces simbólicos, los cuales se referían a los scripts de servicios en el directorio /etc/rc.d/init.d.

El nombre de cada enlace simbólico tiene la siguiente forma.

Aquí, L puede ser la letra “K” o la letra “S”, dd es un número de dos dígitos y service_name es el nombre del script de servicios a los cuáles apunta el enlace simbólico.

Ahora podemos describir exactamente lo que hace un script /etc/rc.d/rc. Recuerde que cada vez que el sistema cambia niveles de ejecución (incluyendo entrar un nivel de ejecución en el

Comando Efecto

start Inicia el servicio.

stop Detiene el servicio.

status

Genera un mensaje de estatus del servicio apropiado. Como mínimo, el mensaje reporta si el servicio se está ejecutando y el Id del proceso de todos los demonios asociados. A menudo, el mensaje de estatus también incluye información específica del servicio.

restart Primero se detiene y luego inicia el servicio.

reload Reinicializa el servicio sin reiniciar, si es necesario.

condrestart Si el servicio ya se está ejecutando, lo reinicia, de lo contrario, no hace nada, (este comando es útil con scripts automáticos.)

[root@station root]# ls -F /etc/rc.d/ init.d/ rc0.d/ rc2.d/ rc4.d/ rc6.d/ rc.sysinit* rc* rc1.d/ rc3.d/ rc5.d/ rc.local* rc.sysinit.rpmsave*

[root@station root]# ls -F /etc/rc.d/rc3.d/ K05saslauthd@ K40smartd@ S00microcode_ctl@ S17keytable@ S80sendmail@ K10psacct@ K45named@ S05kudzu@ S20random@ S85gpm@ K15dc_client@ K50netdump@ S08arptables_jf@ S24pcmcia@ S90crond@ K15dc_server@ K50snmpd@ S08ip6tables@ S25netfs@ S90xfs@ K15httpd@ K50snmptrapd@ S08iptables@ S26apmd@ S95atd@ K20nfs@ K50tux@ S09isdn@ S28autofs@ S97rhnsd@ K24irda@ K70aep1000@ S10network@ S55cups@ S99local@ K25squid@ K70bcm5820@ S12syslog@ S55sshd@ S99mdmonitor@ K35smb@ K73ypbind@ S13irqbalance@ S56rawdevices@ S99mdmpd@ K35vncserver@ K74nscd@ S13portmap@ S56xinetd@ K35winbind@ K74ntpd@ S14nfslock@ S59hpoj@

Lddservice_name

arranque), init llama al script rc, el cual realiza lo siguiente.

1. A excepción del primer arranque, el script rc examina el directorio específico del nivel de ejecución al que se está entrando. Cualquier enlace que inicie “K” (para “matar”), rc comprobará si ese servicio se está ejecutando. Si se está ejecutando, el script de servicios asociado se llama con el argumento stop.

2. El script rc examina de nuevo el nivel de ejecución específico que se ha entrado. Cualquier enlace que inicie “S” (para “Start”), rc comprobará si ese servicio se está ejecutando o no, el script de servicio asociado se llama con el argumento start.

Como resultado, una vez que init ha completado el cambio de niveles de ejecución, el estado de todos los servicios debe reflejar el estado de los enlaces simbólicos en el directorio del nivel de ejecución específico. Todos los servicios asociados con enlaces “K” se deben detener y todos los servicios asociados con enlaces “S” se deben iniciar.

¿Para qué sirven los números? Simplemente dan un orden a los servicios cuando se inician o cuando se detienen, (no sirve de mucho iniciar el servidor de red (httpd) antes de que se haya configurado la red (network)).

Al reordenar los enlaces dentro de directorios específicos del nivel de ejecución, los administradores pueden cambiar la configuración predeterminada de su máquina. Por ejemplo, el servicio samba está actualmente inhabilitado por defecto en el nivel de ejecución 3. Un administrador podría hacer que el servicio se inicie por defecto en el nivel de ejecución 3 al escoger de una manera algo arbitraria un número de inicio y mover el enlace simbólico.

Este tipo de alteración de enlaces "a mano" podrían hacer el trabajo, pero hay una forma más elegante con el comando chkconfig. El comando chkconfig existe para ayudar a los administradores a configurar el nivel de ejecución para servicios.

Cuando se llama con --list, el comando chkconfig mostrará todos los servicios conocidos y el estado actual de los siete niveles de ejecución.

(Al final de la lista, chkconfig cambia e indica el estado de los servicios de red controlados xinetd lo cual es un simple encendido o apagado. La configuración de servicios relacionados con xinetd va más allá del objetivo de este curso y estas entradas no se tienen en cuenta).

Cuando se llama --list con un argumento, sólo se muestra la configuración del servicio nombrado.

Cuando se llama con dos argumentos, el primer argumento debe ser el nombre de un servicio y el

[root@station root]# cd /etc/rc.d/rc3.d/ [root@station rc3.d]# mv K35smb S95smb

[root@station rc3.d]# chkconfig --list kdcrotate 0:off 1:off 2:off 3:off 4:off 5:off 6:off ntpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off syslog 0:off 1:off 2:off 3:on 4:on 5:on 6:off netfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off network 0:off 1:off 2:off 3:on 4:on 5:on 6:off random 0:off 1:off 2:off 3:on 4:on 5:on 6:off ...

[root@station rc3.d]# chkconfig --list smb smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off

segundo argumento puede ser on , off o reset. Para los niveles de ejecución 3, 4 y 5, chkconfig actualizará los enlaces simbólicos correctamente.

A continuación, el administrador examina primero el estado del enlace pertinente en el directorio /etc/rc.d/rc3.d. Luego, con el comandochkconfig, habilita el servicio smb para niveles de ejecución 3, 4 y 5 y reexamina el estado del enlace.

El comando chkconfig manejó el "cambio" del enlace simbólico para el administrador. Además, el servicio smb está inhabilitado en la siguiente secuencia.

Cada servicio trae consigo su propio concepto de lo que debe ser su estado predeterminado. El servicio de red, por ejemplo, no está habilitado "por defecto" para los niveles de ejecución 2, 3, 4 y 5. En contraste, la mayoría de los servicios de red, tales como los servicios httpd osmb, están apagados "por defecto" para todos los niveles de ejecución. El comando reset se puede utilizar para restablecer los estados del servicio a su configuración "por defecto".

Configuración local de inicio

Nuestra discusión sobre el proceso de arranque de Red Hat Enterprise Linux ya casi está completa. Nuestro último tema tratará sobre cómo personalizar el proceso de inicio y específicamente el script /etc/rc.d/rc.local. Al listar todas las instancias de la palabra local desde los directorios específicos de niveles de ejecución podemos deducir la función del script rc.local.

[root@station rc3.d]# pwd /etc/rc.d/rc3.d [root@station rc3.d]# ls *smb* K35smb [root@station rc3.d]# chkconfig smb on [root@station rc3.d]# chkconfig --list smb smb 0:off 1:off 2:on 3:on 4:on 5:on 6:off [root@station rc3.d]# ls *smb* S91smb

[root@station rc3.d]# chkconfig smb off [root@station rc3.d]# chkconfig --list smb smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@station rc3.d]# ls *smb* K35smb

[root@station rc3.d]# chkconfig smb reset [root@station rc3.d]# chkconfig --list smb smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off

[Note] Observar más alláEl comando chkconfig también permitirá a los administradores configurar los estados de niveles de ejecución especificados. En la práctica, el nivel de ejecución predeterminado de una máquina es casi siempre 3 o 5 por lo tanto los comandos on y off serán suficientes. Consulte la página chkconfig(8) del manual para mayor información. También, observe que chkconfig tiene algún conocimiento incorporado en éste. Por ejemplo, sabe que el número de inicio para el servicio smb es 91 y el número para matar es el 35. De nuevo, la página de manual le dará mayores detalles.

El script rc.local se ejecuta cuando se entra a un nivel de ejecución tras el arranque. Por defecto, el script está vacío. Cualquier requisito particular se puede agregar a este script. Cualquier configuración que se agregue a rc.local se ejecutará después de que todos los servicios se hayan iniciado. Esta conducta se puede modificar correctamente, ajustando el número de inicio del enlace simbólico S99local.

Resumen

Al cerrar, se ofrece el siguiente consejo. No permita que los detalles presentados en esta lección oscurezcan la simplicidad de la administración del servicio de Red Hat Enterprise Linux. Se podría decir que la mayoría de las técnicas de administración de sistemas más importantes descritas en este cuaderno están plasmadas en estos dos comandos: service y chkconfig.

Utilice el comando service para manipular directamente un servicio, como se muestra en los siguientes comandos.

Utilice chkconfig para establecer el estado perdeterminado de un servicio tras el arranque, como en los siguientes comandos.

Después de la instalación del software de un nuevo servicio, suelen usarse los dos comandos en conjunto para iniciar el servicio de inmediato y por defecto tras un reinicio posterior.

[root@station rc.d]# ls -l /etc/rc.d/rc?.d/*local* lrwxrwxrwx 1 root root 11 Apr 1 2003 /etc/rc.d/rc2.d/S99local -> ../rc.local lrwxrwxrwx 1 root root 11 Apr 1 2003 /etc/rc.d/rc3.d/S99local -> ../rc.local lrwxrwxrwx 1 root root 11 Apr 1 2003 /etc/rc.d/rc4.d/S99local -> ../rc.local lrwxrwxrwx 1 root root 11 Apr 1 2003 /etc/rc.d/rc5.d/S99local -> ../rc.local

[root@station rc.d]# service vsftpd start Starting vsftpd for vsftpd: [ OK ] [root@station rc.d]# service vsftpd stop Shutting down vsftpd: [ OK ] [root@station rc.d]# service vsftpd status vsftpd is stopped

[root@station rc.d]# chkconfig vsftpd on [root@station rc.d]# chkconfig vsftpd off [root@station rc.d]# chkconfig --list vsftpd vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off

[root@station rc.d]# service smb start Starting SMB services: [ OK ] Starting NMB services: [ OK ] [root@station rc.d]# chkconfig smb on


Specification

1. Asuma que no anticipa futuros cambios al hardware de su máquina y que desearía disminuir su tiempo de inicio de la máquina. Cambie la configuración del nivel de ejecución para el servicio kudzu para que esté desactivado para todos los niveles de ejecución.

2. De inmediato desactive el servicio portmap (pero no cambie sus niveles de ejecución predeterminados).

3. De modo manual desactive el servicio rhnsd para nivel de ejecución 4, renombrando el enlace simbólico K01rhnsd.

Resultados

A title

Question 1

Limpieza

Restaurar los servicios kudzu, portmap y rhnsd a su configuración predeterminada.

[Warning] Lab Exercise Objetivo: Administrar de modo efectivo los servicios de Red Hat Enterprise Linux.

Tiempo estimado: 15 minutos.

1. Una configuración de nivel de ejecución que desactive el servicio kudzu para todos los niveles de ejecución.

2. Un servicio portmap que no esté actualmente en ejecución.

3. Una configuración de nivel de ejecución que desactive el servicio rhnsd para el nivel de ejecución 4 con un "número para parar " de 01.

grade

System Initialization and Services Resolución de problemas en la secuencia de arranque

Conceptos clave

Al observar el flujo de mensajes de arranque, los administradores pueden determinar la naturaleza del error de configuración de una máquina.

Al agregar un 1 a la línea de comandos del kernel, se puede iniciar una máquina en un estado en que el sistema de archivos es ensamblado, pero no se han iniciado servicios.

Al agregar un init=/bin/sh a la línea de comandos del kernel, se puede arrancar una máquina en un estado donde hay una shell interactiva, pero no se ha hecho referencia a archivos de configuración.


La aplicación gráfica de servicios

En la lección anterior se presentaron los comandos services y chkconfig como la técnica preferida para administrar servicios de Red Hat Enterprise Linux. También existe una utilidad gráfica, a la cual se puede acceder desde el menú principal como configuración del sistema:configuración de servidor:servicios, o desde la línea de comandos como system-config-services.

Figure 1. Utilidad de configuración del servicio gráfico

La utilidad gráfica modifica un nivel de ejecución a la vez y el nivel de ejecución actual se puede seleccionar desde el menú nivel de ejecución. Los botones iniciar, detener y reiniciar realizan funciones análogas a service, mientras que las casillas de verificación se utilizan para establecer la conducta predeterminada del nivel de ejecución (de forma similar a chkconfig). Una corta descripción del servicio y su estado actual se proporciona en los paneles de texto.

Administración de consolas virtuales

Las consolas virtuales fueron mencionadas en una lección anterior, por lo tanto aprovechamos esta oportunidad para recoger información acerca de las consolas virtuales en un solo lugar.

Debido a que el proceso init inicia 6 gettys para cada una de las primeras 6 consolas virtuales, la gente generalmente dice que Linux "tiene" 6 consolas virtuales. Usualmente, Linux proporciona 12 consolas virtuales y algunas veces más. Las 6 consolas virtuales que no permiten inicio de sesión se pueden utilizar para ejecutar servidores X y visualizar la salidas de otros comandos. La consola n se puede acceder a través del nodo de dispositivo /dev/ttyn.

Como ejemplo, la siguiente línea de comandos haría que la décima la consola virtual mostrara constantemente las últimas líneas del archivo /var/log/messages.

Igual que las primeras 6 consolas virtuales, las consolas más altas se pueden ver con la secuencia de comandos ALT-Fn, donde cada tecla de función asigna el número correspondiente de la consola virtual n. Al salir del entorno gráfico X, la secuencia de teclas ALT-Fn parece ser demasiado común, por lo tanto se necesita agregar CONTROL. Si tiene problemas para recordar la diferencia, CONTROL-ALT-Fn siempre funcionará.

El siguiente cuadro presenta las secuencias de teclas más utilizadas para administrar consolas virtuales.

Table 1. Secuencias de teclas para consolas virtuales

Análisis de la secuencia de arranque

Algunas veces, las máquinas pueden estar desconfiguradas al punto que pueden presentar problemas en el arranque. Reconocer en qué momento del proceso de arranque se presenta el problema puede ayudar en el diagnóstico. Por consiguiente, los administradores del sistema de Red Hat Enterprise Linux deben ser capaces de reconocer diversas fases del proceso de inicio del flujo de mensajes ingresados tras el arranque.

Empezando con Red Hat Enterprise Linux 4, el determinar problemas en el tiempo de arranque es un poco dificil ya que los parámetros de tiempo de inicio del kernel quiet y rhgb están predeterminados. Si su sistema presenta problemas en el arranque, se deben suprimir esos parámetros de la línea de comandos del kernel (ya sea editando /etc/grub.conf, o probablemente omitiendo la línea de comandos del kernel en el arranque con GRUB).

Aquí reproducimos los componentes clave de una muestra de secuencia de arranque (asumiendo que no están los parámetros de arranque del kernel quiet ni rhdb) e identificamos algunas de las fases importantes. Comencemos por el gestor de arranque GRUB. Si es rápido, podemos atajar un mensaje similar al siguiente cuando BIOS pase el control a GRUB.

Rápidamente, el mensaje se reemplaza con el menú de aplicación de la etapa 2 de GRUB. Cuando un elemento del menú se ha seleccionado, aparece en pantalla lo siguiente.

[root@station root]# tail -f /var/log/messages > /dev/tty10 &

Secuencia de teclas Uso

ALT-Fn Se desplaza a la consola virtual número n.

CONTROL-ALT-Fn Se desplaza a la consola virtual número n dentro de un entorno X.

ALT-FLECHAIZQUIERDA, ALT-FLECHADERECHA

Se desplaza a la consola vecina.

MAYÚSCULAS-PÁGINA-ARRIBA, MAYÚSCULAS-PÁGINA-ABAJO

Se desplaza por el historial de la consola virtual, (el historial se pierde cuando se cambia la consola).

Etapa 2 de la carga de GRUB

Otra vez, debe ser rápido. Es muy probable, que el único momento en que pueda atajar esta información es si algo saliera mal (por ejemplo si GRUB no pudiera localizar el kernel o no pudiera localizar el disco RAM), porque los mensajes se remplazan rápidamente con mensajes de inicio del kernel mientras carga.

Cortamos la mayoría de los mensajes del kernel, (los interesados pueden hojearlos en el archivo /var/log/dmesg). Volvemos a cuando el kernel está montando su disco RAM inicial, montando la partición raíz e iniciando el proceso init.

En este punto, init inicia y se ejecuta el script rc.sysinit. El script calla al kernel rápidamente y comienza una secuencia de inicio más representativa, cargando una fuente por defecto y luego procediendo a inicializar el sistema de archivos.

En este punto, se presenta un evento importante en la vida del sistema de archivos: la partición raíz ahora está montada como de lectura y escritura.

Booting 'Red Hat Linux (2.6.9-5.EL)' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ rhgb quiet [Linux-bzImage, setup=0x1400, size=0x113738] initrd /initrd-2.6.9-5.EL.img [Linux-initrd @ 0x3cb000, 0x24881 bytes]

Linux version 2.6.9-5.EL ([email protected]) (gcc version 3.2.3 2 0030502 (Red Hat Linux 3.2.3-26)) #1 Thu Jan 8 17:03:13 EST 2004 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) ...

... RAMDISK: Compressed image found at block 0 Freeing initrd memory: 146k freed VFS: Mounted root (ext2 filesystem). Journalled Block Device driver loaded kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds Freeing unused kernel memory: 132k freed INIT: version 2.84 booting

Setting default font (latarcyrheb-sun16): [ OK ] Welcome to Red Hat Linux Press 'I' to enter interactive startup. Mounting proc filesystem: [ OK ] Unmounting initrd: [ OK ] Configuring kernel parameters: [ OK ] Setting clock (localtime): Fri Nov 14 14:32:45 EST 2003 [ OK ] Loading default keymap (us): [ OK ] Setting hostname dhcp63-237.rdu.redhat.com: [ OK ] Initializing USB controller (usb-uhci): [ OK ] Mounting USB filesystem: [ OK ] Initializing USB HID interface: [ OK ] Initializing USB keyboard: [ OK ] Initializing USB mouse: [ OK ] Checking root filesystem /: clean, 92214/393600 files, 463138/787177 blocks [ OK ] Remounting root filesystem in read-write mode: [ OK ]

Se produjo otro evento importante en el sistema de archivos: ahora todas las particiones locales se han montado de lectura y escritura.

En este punto, rc.sysinit termina e init comienza la configuración específica del nivel de ejecución. Las siguientes líneas reflejan, uno por uno, los diversos scripts de servicio del inicio del directorio /etc/rc.d/init.d.

Ahora las interfaces de red deben estar activas y se pueden iniciar los servicios de red relacionados.

¿Qué "otros sistemas de archivos" faltan por montarse? Los sistemas de archivos relacionados, tales como los recursos compartidos NFS o SMB.

Los mensajes de inicio deberían desaparecer ahora, para ser remplazados por una consola virtual de texto con un intérprete de comandos de inicio de sesión (para el nivel de ejecución 3) o una pantalla gráfica de inicio (para el nivel de ejecución 5).

Activating swap partitions: [ OK ] Finding module dependencies: [ OK ] Checking filesystems /boot: clean, 41/32128 files, 9270/128488 blocks /home: clean, 520/130560 files, 30874/522081 blocks Mounting local filesystems: [ OK ]

Enabling local filesystem quotas: [ OK ] Enabling swap space: [ OK ] INIT: Entering runlevel 5

Entering non-interactive startup Checking for new hardware [ OK ] Updating /etc/fstab [ OK ] Setting network parameters: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: [ OK ]

Starting system logger: [ OK ] Starting kernel logger: [ OK ] Starting portmapper: [ OK ] Starting NFS statd: [ OK ] Starting keytable: [ OK ] Initializing random number generator: [ OK ] Starting pcmcia: [ OK ] Mounting other filesystems: [ OK ]

Starting up APM daemon: [ OK ] Starting automount: No Mountpoints Defined [ OK ] Starting sshd: [ OK ] Starting xinetd: [ OK ] Starting sendmail: [ OK ] Starting sm-client: [ OK ] Starting console mouse services: [ OK ] Starting crond: [ OK ] Starting cups: [ OK ] Starting xfs: [ OK ] Starting anacron: [ OK ] Starting atd: [ OK ] Starting firstboot: [ OK ] Starting Red Hat Network Daemon: [ OK ]

Cuando todo sale bien, estos mensajes se pueden ignorar. No obstante, cuando la máquina está desconfigurada, el observar cuidadosamente en qué parte del proceso de arranque se inició el problema, puede ayudar bastante en el diagnóstico del problema.

Modificación de la secuencia de arranque con la línea de comandos del kernel

En la lección sobre el gestor de arranque GRUB, mencionamos la función de la línea de comandos del kernel y cómo modificar la línea de comandos mientras se arranca la máquina. Ahora que hemos descrito la secuencia de arranque de Red Hat Enterprise, volvamos al tema.

Tras el inicio, el kernel examina la línea de comandos del kernel y responde correctamente a los argumentos reconocidos. Los argumentos que el kernel no reconoce, los pasa al primer proceso. Si el argumento desconocido tiene la forma nombre=valor, se pasa como variable de entorno. De lo contrario, el argumento desconocido se pasa como un argumento para el primer proceso.

Algunas veces, los sistemas se desconfiguran por lo tanto no pueden arrancar correctamente. En tales situaciones, la línea de comandos del kernel se puede utilizar para arrancar la máquina a un nivel reducido, permitiéndole al administrador del sistema localizar y solucionar los problemas. Los siguientes dos escenarios se pueden utilizar para recuperar máquinas desconfiguradas en la mayoría de los casos.

Arranque en el nivel de ejecución 1

Cuando la desconfiguración se presenta en las últimas etapas del proceso de arranque, tales como con la configuración de red o la autenticación de usuario, el sistema se puede iniciar en un estado muy útil al evitar el nivel de ejecución predeterminado y arrancando directamente en un modo de monousuario. Esto se lleva a cabo al agregar un “1” a la línea de comandos del kernel. El kernel, al no reconocer el argumento “1”, pasa el argumento al proceso init. ¿Qué sucede cuando el init es llamado con un argumento de “1”? Este arranca en el nivel de ejecución 1.

El proceso init iniciará, el script rc.sysinit se ejecutará y después de entrar al nivel de ejecución 1, el usuario pasará a la shell de root. Debido a que el script rc.sysinit se ejecutó, el sistema de archivos debería reconstruirse totalmente. Desde aquí se puede estudiar el sistema, y esperemos que el problema se pueda solucionar. Cuando se haya identificado el problema y solucionado, el proceso de arranque puede continuar con sólo desplazarse a un nivel de ejecución más alto por ejemplo con init 5.

Este truco es muy útil para recuperar las máquinas para las que se ha olvidado la contraseña de root.

Evitar el /sbin/init

A veces, sin embargo, se pueden presentar problemas tempranos en el proceso de arranque. Por ejemplo, ¿qué sucedería si el archivo /etc/fstab, o el archivo/etc/inittab o el script /etc/rc.d/rc.sysinit se destruyen? En dichos casos, arrancar en el nivel de ejecución 1 no es la solución. Los problemas se presentan incluso antes de que init considere los niveles de ejecución.

En dichas situaciones, se le puede pedir al kernel que evite /sbin/init y ejecute una shell interactiva como su proceso inicial. Esto se realiza al agregar el argumento init=/bin/sh a la línea de comandos del kernel. El parámetro de arranque init= le pide al kernel que ejecute un comando diferente a /sbin/init como el proceso de inicio y el kernel se comporta como corresponde.

¿Qué sucede después del arranque? En este momento en el proceso de inicio del kernel se iniciaría

init, pero no lo hace, en su lugar, se envía al usuario a una shell interactiva.

Recuerde el estado del sistema de archivos: únicamente se monta la partición raíz de sólo lectura. Una reacción natural sería tratar de remontar la partición raíz como de lectura y escritura.

Sin montar /proc, ¡ni siquiera el comando mount funcionará correctamente! Primero, se debería montar el sistema de archivos /proc, luego se puede montar la partición raíz de lectura y escritura. Si todo sale bien, el siguiente comando puede ser un mount -a.

En este punto, el usuario debería estar en un entorno bastante adecuado para localizar y solucionar problemas. Una vez se hayan identificado los problemas y solucionado, ¿cómo se puede salir el usuario de este entorno mínimo? Una opción es el comando exit.

En este momento, el teclado de LED del usuario estará alumbrándose (una de las característicias del kernel de Linux que está bloqueado) y de otra manera el usuario está muerto. ¿Qué sucedió? El proceso interactivo /bin/sh era el Id del proceso número 1 y al kernel no le gusta que muera el proceso número 1.

Una solución más apropiada es la siguiente. Primero, pare los procesos (diferentes a su shell). Luego deconstruya su sistema de archivos revocando el proceso anterior.

En este punto, el sistema se encuentra en el momento en que el kernel habría quedado : sólo un proceso se está ejecutando y el sistema de archivos está montado de sólo lectura. Haga que su shell se convierta en el proceso /init "ejecutando" /sbin/init.

init-2.05b#

init-2.05b# mount -o remount,rw / mount: could not open /proc/partitions, so UUID and LABEL conversion cannot be done. mount: no such partition found init-2.05b#

init-2.05b# mount /proc init-2.05b# mount -o remount,rw / EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal init-2.05b# mount -a kjournald starting. Commit interval 5 seconds EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,7), internal journal EXT3-fs: mounted filesystem with ordered data mode. init-2.05b#

init-2.05b# exit exit Kernel Panic: Attempted to kill init!

init-2.05b# umount -a init-2.05b# mount -o remount,ro / init-2.05b# umount /proc init-2.05b#

Su sistema debería iniciar en limpio como si nada hubiera pasado.

La búsqueda del kernel de un proceso inicial

Si por alguna razón el kernel no encuentra o ejecuta /sbin/init, el kernel busca /bin/sh y otros ejecutables predefinidos. Por último, si el kernel agota su lista de candidatos sin encontrar un proceso inicial ejecutable, muere con el siguiente mensaje.

init-2.05b# exec /sbin/init INIT: version 2.84 booting Setting default font (latarcyrheb-sun16): [ OK ] Welcome to Red Hat Linux Press 'I' to enter interactive startup. ...

Kernel panic. No init found. Try passing init= option to kernel.


Specification

1. Por precaución, copie su archivo /etc/fstab en el archivo /etc/fstab.prelab4.5. Edite su archivo original y quite el comentario de la línea definiendo el punto de montaje para la partición raíz.

2. Reinicie su máquina. En el intérprete de comandos de arranque GRUB, agregue el parámetro init=/bin/sh a la línea de comandos del kernel.

3. Su sistema continúa el arranque, pero rápidamente lo envía a la shell de mantenimiento. En la shell de mantenimiento, realice los siguientes pasos.

a. Monte el sistema de archivos /proc.

b. Vuelva a montar la partición raíz de lectura y escritura.

c. Edite el archivo /etc/fstab y no comente la línea que retiró al comienzo del laboratorio.

d. Vuelva a montar la partición raíz de sólo lectura.

e. Desmonte el sistema de archivos /proc.

f. Remplace su shell con el proceso init, pidiéndole ainit que traiga su máquina al nivel de ejecución 1 con la siguiente línea de comandos.

4. Su proceso de arranque debería continuar con init configurando la máquina al nivel de ejecución 1. Cuando haya terminado init abrirá otra shell, esta vez con el sistema de archivos totalmente ensamblado. Desde esta shell, entre al nivel de ejecución 5 con la línea de comandos init 5.

5. En este punto, su máquina debe haber arrancado completamente. Inicie sesión y califique su ejercicio.

Resultados

A title

Question 1

[Warning] Lab Exercise

Objetivo: Ser competente al sobreescribir la secuencia de arranque predeterminada.

Estimated Time: 30 mins.

init-2.05b# exec /sbin/init 1

1. Un /proc/cmdline que incluya el argumento init=/bin/sh.

2. El comando runlevel debería entregar su nivel de ejecución actual como nivel de ejecución 5 y su nivel de ejecución anterior como nivel de ejecución 1.

grade

4 - Inicializacion de Sistemas y Servicios

Documents

Transcript of 4 - Inicializacion de Sistemas y Servicios