Saltar al contenido

Linux

FRR y Routers con Linux

  • admin 

FRR y Routers con Linux

Desde que hace unos meses los de Cumulus Linux anunciaran el uso en sus switches Linux de montar VPNs con VxLAN + EVPN (usando BGP para advertir las MACs de los equipos a los extremos remotos), y posteriormente anunciar que iban a remplazar el quagga de sus equipos por el FRR (un fork de quagga), el tema de usar servidores con Linux para remplazar a routes y switches de alto rendimiento ya está al alcance de todos.

El tema de VxLAN (transporte de VLANs encapsuladas por IP) usando como mecanismo de señalización y control las extensiones de BGP para advertir las MACs y comunicar las VLANs entre los puntos remotos permite hacer todo tipo de virguerías en los datacenters para transportar VPNs de nivel 2 y 3 de forma eficiente a gran escala y sin necesidad de tener que montar un core MPLS por debajo. A partir de la versión 3.0 del FRR ya se soportan todas las recomendaciones que permiten montar las EVPNs con VxLAN (son los drafts draft-ietf-bess-evpn:

https://github.com/FRRouting/frr/wiki/Major-Changes

Los del FRR se han puesto mucho las pilas para competir y llegar a superar incluso a los más avanzados, como Juniper y Arista.

Después en los grupos de operadores de red se han disparado las presentaciones de casos de uso y aplicaciones utilizando el FRR como equipos de core.

Aquí un ejemplo del hardware compacto para router de alto rendimiento (esto es del grupo de operadores de red suizo):

http://www.swinog.ch/meetings/swinog32/p/Manuel_Schweizer_Free-Range-Routing-FRR.pdf

Los equipos de 1U compactos a los que hace referencia son estos:

https://www.lanner-america.com/product/nca-5510/

Y efectivamente, soportan tarjetas de hasta 100G.

Aquí en la sesión anterior del swinog, otra charla sobre el tema de las VPNs multitenant utilizando el FRR con VxLAN + EVPN:

http://www.swinog.ch/meetings/swinog31/p/06_Attilla_de_Groot_Multi-tenancy_with_EVPN-VxLAN_in_Open_Networking.pdf

Hay muchos ejemplos del mismo tipo de solución. Aquí en la misma sesión que la anterior hay una charla de Huawei explicando en más detalle el tema del por qué es una buena elección y el por qué se está quedando desbancado el MPLS para dar ese tipo de soluciones a las VPNs de nivel 2 y nivel 3:

http://www.swinog.ch/meetings/swinog31/p/04_Christian_Kuster_VXLAN_-_Thinking_outside_the_(DC)Box.pdf

Desde hace cosa de un año voy siguiendo de vez en cuando esta solución, y por lo que veo ya ha pasado el punto de ser algo puramente experimental con unas cuantas soluciones y acercamientos de los principales impulsores a ser una solución disponible y 100% open source. Ya no hace falta comprarse un switch de Cumulus con licencias para tener una solución lista para producción. Ahora es sólo cuestión de poner una pareja de servidores y tarjetas de red intel conectadas a los switches del core para dar ese tipo de funcionalidades. Esto ya está disponible, pero dentro de unos meses alcanzará un nivel de madurez bastante extenso a todo tipo de plataformas, incluidos los routers CPE.

Me han sorprendido mucho los del FRR. Hace unos meses pensaba que se iba a quedar un poco como el quagga con unas cuantas mejoras adicionales y poco más, pero se han puesto las pilas a base de bien.

How To Disable ipv6 Fedora 17/18

Source: http://lifeofageekadmin.com/how-to-disable-ipv6-fedora-1718/

IPV6 is coming, but it is not here yet, so say you want to disable it on your Fedora 18 system. Pretty simple to do. First let’s edit the /etc/sysctl.conf file.

$ sudo vi /etc/sysctl.conf

Add and save the changes

net.ipv6.conf.all.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6=1

To eliminate the default ipv6 addresses still appear on the interfaces open a terminal and type

Type ifconfig to get the inet6 info and the adapter

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84  bytes 7100 (6.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 7100 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a00:27ff:fedc:5b71  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:dc:5b:71  txqueuelen 1000  (Ethernet)
        RX packets 234990  bytes 115274228 (109.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210670  bytes 40730873 (38.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        
$ sudo ip addr del ::1/128 dev lo
$ sudo ip addr del fe80::a00:27ff:fedc:5b71/64 dev p2p1

$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 0  (Local Loopback)
        RX packets 84  bytes 7100 (6.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 84  bytes 7100 (6.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

p2p1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.20  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 08:00:27:dc:5b:71  txqueuelen 1000  (Ethernet)
        RX packets 235487  bytes 115320518 (109.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 210678  bytes 40731473 (38.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Comment out ::1 in /etc/hosts

$ sudo vi /etc/hosts

# ::1 localhost

Hot Plugging: hotplug

  • admin 

Fuente: http://debian-handbook.info/browse/stable/sect.hotplug.html

Introduction

The hotplug kernel subsystem loads drivers for peripherals that can be hotplugged. This includes USB peripherals (increasingly common), PCMCIA (common expansion cards for laptops), IEEE 1394 (also called “Firewire” or “I-Link”), some SATA hard drives, and even, for some high-end servers, PCI or SCSI devices.

The kernel has a database that associates each device ID with the required driver. This database is used during boot to load all the drivers for the peripheral devices detected on the different buses mentioned, but also when an additional hotplug device is connected.

Once a driver is loaded, a message is sent to udevd so it will be able to create the corresponding entry in /dev/.
The Naming Problem

Before the appearance of hotplug connections, it was easy to assign a fixed name to a device. It was based simply on the position of the devices on their respective bus. But this is not possible when such devices can come and go on the bus. The typical case is the use of a digital camera and a USB key, both of which appear to the computer as disk drives. The first one connected may be /dev/sdb and the second /dev/sdc (with /dev/sda representing the computer’s own hard drive). The device name is not fixed; it depends on the order in which devices are connected.

Additionally, more and more drivers use dynamic values for devices’ major/minor numbers, which makes it impossible to have static entries for the given devices, since these essential characteristics may vary after a reboot.

udev was created precisely to solve this problem.

NOTE: IN PRACTICE Network card management
Many computers have multiple network cards (sometimes two wired interfaces and a wifi interface), and with hotplug support on most bus types, the 2.6 kernel no longer guarantees fixed naming of network interfaces. But a user who wants to configure their network in /etc/network/interfaces needs a fixed name!

It would be difficult to ask every user to create their own udev rules to address this problem. This is why udev was configured in a rather peculiar manner; on first boot (and, more generally, each time that a new network card appears) it uses the name of the network interface and its MAC address to create new rules that will reassign the same name on subsequent boots. These rules are stored in /etc/udev/rules.d/70-persistent-net.rules.
This mechanism has some side effects that you should know about. Let’s consider the case of computer that has only one PCI network card. The network interface is named eth0, logically. Now say the card breaks down, and the administrator replaces it; the new card will have a new MAC address. Since the old card was assigned the name, eth0, the new one will be assigned eth1, even though the eth0 card is gone for good (and the network will not be functional because /etc/network/interfaces likely configures an eth0 interface). In this case, it is enough to simply delete the /etc/udev/rules.d/70-persistent-net.rules file before rebooting the computer. The new card will then be given the expected eth0 name.

How udev Works
When udev is notified by the kernel of the appearance of a new device, it collects various information on the given device by consulting the corresponding entries in /sys/, especially those that uniquely identify it (MAC address for a network card, serial number for some USB devices, etc.).
Armed with all of this information, udev then consults all of the rules contained in /etc/udev/rules.d/ and /lib/udev/rules.d/. In this process it decides how to name the device, what symbolic links to create (to give it alternative names), and what commands to execute. All of these files are consulted, and the rules are all evaluated sequentially (except when a file uses “GOTO” directives). Thus, there may be several rules that correspond to a given event.
The syntax of rules files is quite simple: each row contains selection criteria and variable assignments. The former are used to select events for which there is a need to react, and the latter defines the action to take. They are all simply separated with commas, and the operator implicitly differentiates between a selection criterion (with comparison operators, such as == or !=) or an assignment directive (with operators such as =, += or :=).
Comparison operators are used on the following variables:

 

  • KERNEL: the name that the kernel assigns to the device;
  • ACTION: the action corresponding to the event (“add” when a device has been added, “remove” when it has been removed);
  • DEVPATH: the path of the device’s /sys/ entry;
  • SUBSYSTEM: the kernel subsystem which generated the request (there are many, but a few examples are “usb”, “ide”, “net”, “firmware”, etc.);
  • ATTR{attribut}: file contents of the attribute file in the /sys/$devpath/ directory of the device. This is where you find the MAC address and other bus specific identifiers;
  • KERNELS, SUBSYSTEMS and ATTRS{attributes} are variations that will try to match the different options on one of the parent devices of the current device;
  • PROGRAM: delegates the test to the indicated program (true if it returns 0, false if not). The content of the program’s standard output is stored so that it can be reused by the RESULT test;
  • RESULT: execute tests on the standard output stored during the last call to PROGRAM.

The right operands can use pattern expressions to match several values at the same time. For instance, * matches any string (even an empty one); ? matches any character, and [] matches the set of characters listed between the square brackets (or the opposite thereof if the first character is an exclamation point, and contiguous ranges of characters are indicated like a-z).
Regarding the assignment operators, = assigns a value (and replaces the current value); in the case of a list, it is emptied and contains only the value assigned. := does the same, but prevents later changes to the same variable. As for +=, it adds an item to a list. The following variables can be changed:

  • NAME: the device filename to be created in /dev/. Only the first assignment counts; the others are ignored;
  • SYMLINK: the list of symbolic links that will point to the same device;
  • OWNER, GROUP and MODE define the user and group that owns the device, as well as the associated permission;
  • RUN: the list of programs to execute in response to this event.

The values assigned to these variables may use a number of substitutions:
$kernel or %k: equivalent to KERNEL;
$number or %n: the order number of the device, for example, for sda3, it would be “3”;
$devpath or %p: equivalent to DEVPATH;
$attr{attribute} or %s{attribute}: equivalent to ATTRS{attribute};
$major or %M: the kernel major number of the device;
$minor or %m: the kernel minor number of the device;
$result or %c: the string output by the last program invoked by PROGRAM;
and, finally, %% and $$ for the percent and dollar sign, respectively.
The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be.
A concrete example
Let us consider the case of a simple USB key and try to assign it a fixed name. First, you must find the elements that will identify it in a unique manner. For this, plug it in and run udevadm info -a -n /dev/sdc (replacing /dev/sdc with the actual name assigned to the key).
# udevadm info -a -n /dev/sdc
[…]
looking at device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0/block/sdc’:
KERNEL==»sdc»
SUBSYSTEM==»block»
DRIVER==»»
ATTR{range}==»16″
ATTR{ext_range}==»256″
ATTR{removable}==»1″
ATTR{ro}==»0″
ATTR{size}==»126976″
ATTR{alignment_offset}==»0″
ATTR{capability}==»53″
ATTR{stat}==» 51 100 1208 256 0 0 0 0 0 192 25 6″
ATTR{inflight}==» 0 0″
[…]
looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2/1-2.2:1.0/host9/target9:0:0/9:0:0:0’:
KERNELS==»9:0:0:0″
SUBSYSTEMS==»scsi»
DRIVERS==»sd»
ATTRS{device_blocked}==»0″
ATTRS{type}==»0″
ATTRS{scsi_level}==»3″
ATTRS{vendor}==»I0MEGA »
ATTRS{model}==»UMni64MB*IOM2C4 »
ATTRS{rev}==» »
ATTRS{state}==»running»
[…]
ATTRS{max_sectors}==»240″
[…]
looking at parent device ‘/devices/pci0000:00/0000:00:10.3/usb1/1-2/1-2.2’:
KERNELS==»9:0:0:0″
SUBSYSTEMS==»usb»
DRIVERS==»usb»
ATTRS{configuration}==»iCfg»
ATTRS{bNumInterfaces}==» 1″
ATTRS{bConfigurationValue}==»1″
ATTRS{bmAttributes}==»80″
ATTRS{bMaxPower}==»100mA»
ATTRS{urbnum}==»398″
ATTRS{idVendor}==»4146″
ATTRS{idProduct}==»4146″
ATTRS{bcdDevice}==»0100″
[…]
ATTRS{manufacturer}==»USB Disk»
ATTRS{product}==»USB Mass Storage Device»
ATTRS{serial}==»M004021000001″
[…]
To create a new rule, you can use tests on the device’s variables, as well as those of one of the parent devices. The above case allows us to create two rules like these:
KERNEL==»sd?», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/disk»
KERNEL==»sd?[0-9]», SUBSYSTEM==»block», ATTRS{serial}==»M004021000001″, SYMLINK+=»usb_key/part%n»
Once these rules are set in a file, named for example /etc/udev/rules.d/010_local.rules, you can simply remove and reconnect the USB key. You can then see that /dev/usb_key/disk represents the disk associated with the USB key, and /dev/usb_key/part1 is its first partition.
GOING FURTHER Debugging udev’s configuration

Like many daemons, udevd stores logs in /var/log/daemon.log. But it is not very verbose by default, and it’s usually not enough to understand what’s happening. The udevadm control –log-priority=info command increases the verbosity level and solves this problem. udevadm control –log-priority=err returns to the default verbosity level.

Proceso de arranque en Linux

El Proceso de arranque en Linux es el proceso de inicialización del sistema operativo Linux. Es en muchos aspectos similar a los procesos de arranque de BSD y otros sistemas Unix, de los cuales deriva.

 

Descripción general del proceso típico

En Linux, el flujo de control durante el arranque es desde el BIOS, al gestor de arranque y al núcleo (kernel). El núcleo inicia el planificador (para permitir la multitarea) y ejecuta el primer espacio de usuario (es decir, fuera del espacio del núcleo) y el programa de inicialización (que establece el entorno de usuario y permite la interacción del usuario y el inicio de sesión), momento en el que el núcleo se inactiva hasta que sea llamado externamente.

La etapa del cargador de arranque no es totalmente necesaria. Determinadas BIOS pueden cargar y pasar el control a Linux sin hacer uso del cargador. Cada proceso de arranque será diferente dependiendo de la arquitectura del procesador y el BIOS.

  1. El BIOS realiza las tareas de inicio específicas de la plataforma de hardware.
  2. Una vez que el hardware es reconocido y se inicia correctamente, el BIOS carga y ejecuta el código de la partición de arranque del dispositivo de arranque designado, que contiene la fase 1 de un gestor de arranque Linux. La fase 1 carga la fase 2 (la mayor parte del código del gestor de arranque). Algunos cargadores pueden utilizar una fase intermedia (conocida como la fase 1.5) para lograr esto, ya que los modernos discos de gran tamaño no pueden ser totalmente leídos sin código adicional.
  3. El gestor de arranque a menudo presenta al usuario un menú de opciones posibles de arranque. A continuación, carga el sistema operativo, que descomprime en la memoria, y establece las funciones del sistema como del hardware esencial y la paginación de memoria, antes de llamar a la función start_kernel().
  4. La función start_kernel() a continuación realiza la mayor parte de la configuración del sistema (interrupciones, el resto de la gestión de memoria, la inicialización del dispositivo, controladores, etc), antes de continuar por separado el proceso inactivo y planificador, y el proceso de Init (que se ejecuta en el espacio de usuario).
  5. El planificador toma control efectivo de la gestión del sistema, y el núcleo queda dormido (inactivo).
  6. El proceso Init ejecuta secuencias de comandos (Scripts) necesarios para configurar todos los servicios y estructuras que no sean del sistema operativo, a fin de permitir que el entorno de usuario sea creado y pueda presentarse al usuario con una pantalla de inicio de sesión.

En el apagado, Init es llamado a cerrar toda las funcionalidades del espacio de usuario de una manera controlada, de nuevo a través de secuencias de comandos, tras lo cual el Init termina y el núcleo ejecuta el apagado.

Espacio de usuario temprano

El espacio de usuario temprano se utiliza en las versiones más recientes del kernel de Linux para sustituir tantas funciones como sea posible que originalmente se harían en el núcleo durante el proceso de inicio. Los usos típicos del espacio de usuario temprano son para detectar que controladores de dispositivos (Drivers) son necesarios para cargar el sistema de archivos del espacio de usuario principal y cargarlos desde un sistema de archivos temporal.

Fase del cargador de arranque

Un cargador de arranque (boot loader en inglés) es un programa diseñado exclusivamente para cargar un sistema operativo en memoria. La etapa del cargador de arranque es diferente de una plataforma a otra.

Como en la mayoría de arquitecturas este programa se encuentra en el MBR, el cual es de 512 bytes, este espacio no es suficiente para cargar en su totalidad un sistema operativo. Por eso, el cargador de arranque consta de varias etapas. Las primeras operaciones las realiza el BIOS. En esta etapa se realizan operaciones básicas de hardware. En esta primera etapa se localiza el sector de arranque (o MBR) y se carga el cargador de este sector (normalmente una parte de LILO o GRUB).

A partir de ese momento, el proceso de arranque continúa de la siguiente manera:

La primera etapa del cargador de arranque carga el resto del gestor de arranque, que normalmente da un mensaje que pregunta que sistema operativo (o tipo de sesión) el usuario desea inicializar. Bajo LILO, esto se hace a través del mapa instalado que lee el archivo de configuración /etc/lilo.conf para identificar los sistemas disponibles. Incluye datos como la partición de arranque y la localización del kernel para cada uno, así como las opciones personalizadas en su caso. El sistema operativo seleccionado es cargado en la memoria RAM, un sistema de archivos mínimo inicial se establece en la memoria RAM desde un archivo de imagen (» initrd «), y junto con los parámetros adecuados, el control se pasa al sistema operativo activado recientemente.

LILO y GRUB difieren en algunos aspectos:

  • LILO no entiende los sistemas de archivos, por lo que utiliza desplazamientos de disco sin procesar y el BIOS para cargar los datos. Se carga el código del menú y, a continuación, en función de la respuesta, carga, o el sector MBR del disco de 512 bytes como en Microsoft Windows, o la imagen del kernel de Linux.
  • GRUB por el contrario comprende los sistemas de archivos comunes ext2 , ext3 y ext4. Debido a que GRUB almacena sus datos en un archivo de configuración en vez de en el MBR y a que contiene un interfaz de línea de comandos, a menudo es más fácil rectificar o modificar GRUB si está mal configurado o corrupto.

GRUB

GRUB se carga y se ejecuta en 4 etapas:

  1. La primera etapa del cargador la lee el BIOS desde el MBR.
  2. La primera etapa carga el resto del gestor de arranque (segunda etapa). Si la segunda etapa está en una unidad grande, en ocasiones se carga una fase intermedia 1.5, que contiene código adicional para permitir que los cilindros por encima de 1024, o unidades tipo LBA, puedan leerse. El gestor de arranque 1.5 es almacenado (si es necesario) en el MBR o en la partición de arranque.
  3. La segunda etapa del gestor de arranque ejecuta y muestra el menú de inicio de GRUB que permite al usuario elegir un sistema operativo y examinar y modificar los parámetros de inicio.
  4. Después de elegir un sistema operativo, se carga y se le pasa el control.

GRUB soporta métodos de arranque directo, arranque chain-loading, LBA, ext2, ext3, ext4 y hasta «un pre-sistema operativo en máquinas x86 totalmente basado en comandos». Contiene tres interfaces: un menú de selección, un editor de configuración, y una consola de línea de comandos.

LILO

LILO es más antiguo. Es casi idéntico a GRUB en su proceso, excepto que no contiene una interfaz de línea de comandos. Por lo tanto todos los cambios en su configuración deben ser escritos en el MBR y luego reiniciar el sistema. Un error en la configuración puede dejar el disco inservible para el proceso de arranque hasta tal grado, que sea necesario usar otro dispositivo (disquete, etc) que contenga un programa capaz de arreglar el error. Además, no entiende el sistema de archivos. En su lugar, la ubicación de los archivos de imagen se almacenan directamente en el MBR y el BIOS se utiliza para acceder a ellos directamente.

Loadlin

Otra forma de cargar Linux es desde DOS o Windows 9x, donde el núcleo de Linux reemplaza completamente la copia de funcionamiento de estos sistemas operativos. Esto puede ser útil en el caso de hardware que necesita ser conectado a través del software y la configuración de estos programas sólo está disponible para DOS y no para Linux, debido a cuestiones de secretos industriales y código propietario. Sin embargo, esta tediosa forma de arranque ya no es necesaria en la actualidad ya que Linux tiene drivers para multitud de dispositivos hardware. Aun así, esto era muy útil en el pasado.

Otro caso es cuando Linux se encuentra en un dispositivo que el BIOS no lo tiene disponible para el arranque. Entonces, DOS o Windows pueden cargar el driver apropiado para el dispositivo superando dicha limitación del BIOS, y cargar Linux desde allí.

Fase del kernel

El kernel de Linux se encarga de todos los procesos del sistema operativo, como la gestión de memoria, planificador de tareas, I/O, comunicación entre procesos, y el control general del sistema. Este se carga en dos etapa: en la primera etapa el kernel (como un archivo imagen comprimido) se carga y se descomprime en memoria, y algunas funciones fundamentales como la gestión de memoria de base se establecen. El control entonces se cambia a la etapa final para iniciar el kernel principal. Una vez que el núcleo está en pleno funcionamiento – y como parte de su puesta en marcha, después de ser cargado y ejecutado – el kernel busca un proceso de inicio para ejecutar, que (separadamente) fija un espacio de usuario y los procesos necesarios para un entorno de usuario y ultimar la entrada . Al núcleo en sí entonces se le permite pasar a inactivo, sujeto a las llamadas de otros procesos.

Fase de carga del kernel

El kernel es cargado normalmente como un archivo imagen, comprimido dentro de otro con zlib como zImage o bzImage. Contiene una cabecera de programa que hace una cantidad mínima de instalación del hardware, descomprime la imagen completamente en la memoria alta , teniendo en cuenta cualquier disco RAM si está configurado. A continuación, lleva a cabo su ejecución. Esto se realiza llamando la función startup del kernel (en los procesadores x86 a través de la funciónstartup_32() del archivo /arch/i386/boot/head).

Fase de inicio del kernel

La función de arranque para el kernel (también llamado intercambiador o proceso 0) establece la gestión de memoria (tablas de paginación y paginación de memoria), detecta el tipo de CPU y cualquier funcionalidad adicional como capacidades depunto flotante, y después cambia a las funcionalidades del kernel para arquitectura no específicas de Linux, a través de una llamada a la función start_kernel().

start_kernel ejecuta una amplia gama de funciones de inicialización. Establece el manejo de interrupciones (IRQ), configura memoria adicional, comienza el proceso de inicialización (procesa el espacio del primer usuario), y luego comienza la tarea inactiva a través de cpu_idle(). En particular, el proceso de inicio del kernel también monta el disco RAM inicial («initrd«) que se ha cargado anteriormente como el sistema raíz temporal durante la fase de arranque. Esto permite que los módulos controladores se carguen sin depender de otros dispositivos físicos y drivers y mantiene el kernel más pequeño. El sistema de archivos raíz es cambiado más tarde a través de la llamada a pivot_root(), que desmonta el sistema de archivos temporal y lo reemplaza por el real una vez que éste sea accesible. La memoria utilizada por el sistema de archivos temporal es entonces recuperada.

Por lo tanto, el núcleo inicializa los dispositivos, monta el sistema de archivos raíz especificado por el gestor de arranque como de sólo lectura , y se ejecuta Init (/sbin/init), que es designado como el primer proceso ejecutado por el sistema (PID=1). También puede ejecutar opcionalmente initrd para permitir instalar y cargar dispositivos relacionados (disco RAM o similar), para ser manipulados antes de que el sistema de archivos raíz está montado.

En este punto, con las interrupciones habilitadas, el programador puede tomar el control de la gestión general del sistema, para proporcionar multitarea preventiva, e iniciar el proceso para continuar con la carga del entorno de usuario en el espacio de usuario.

El proceso de inicio

El trabajo de Init es «conseguir que todo funcione como debe ser» una vez que el kernel está totalmente en funcionamiento. En esencia, establece y opera todo el espacio de usuario. Esto incluye la comprobación y montaje de sistemas de archivos, la puesta en marcha los servicios de usuario necesarios y, en última instancia, cambiar al entorno de usuario cuando el inicio del sistema se ha completado. Es similar a los procesos Init de Unix y BSD, de la que deriva, pero en algunos casos se ha apartado o se hicieron a la medida. En un sistema Linux estándar, Init se ejecuta con un parámetro, conocido como nivel de ejecución, que tiene un valor entre 1 y 6, y que determina que subsistemas pueden ser operacionales. Cada nivel de ejecución tiene sus propios scripts que codifican los diferentes procesos involucrados en la creación o salida del nivel de ejecución determinado, y son estas secuencias de comandos los necesarios en el proceso de arranque. Los scripts de Init se localizan normalmente en directorios con nombres como «/etc/rc...«. El archivo de configuración de más alto nivel para Init es /etc/inittab.

Durante el arranque del sistema, se verifica si existe un nivel de ejecución predeterminado en el archivo /etc/inittab, si no, se debe introducir por medio de la consola del sistema. Después se procede a ejecutar todos los scripts relativos al nivel de ejecución especificado.

Después de que se han dado lugar todos los procesos especificados, Init se aletarga, y espera a que uno de estos tres eventos sucedan:- que procesos comenzados finalicen o mueran; un fallo de la señal de potencia (energía); o una petición a través de /sbin/telinit para cambiar el nivel de ejecución.

Módulos del Kernel Linux

  • admin 

Fuente: http://web.mit.edu/rhel-doc/3/rhel-sag-es-3/ch-kernel-modules.html

El kernel de Linux tiene un diseño modular. En el momento de arranque, sólo se carga un kernel residente mínimo en memoria. Por ello, cuando un usuario solicita alguna característica que no esta presente en el kernel residente, se carga dinámicamente en memoria un módulo kernel, también conocido algunas veces como un controlador.

Durante la instalación, se prueba el hardware en el sistema. Basado en esta prueba y en la información proporcionada por el usuario, el programa de instalación decide qué módulos necesita cargar en el momento de arranque. El programa de instalación configura el mecanismo de carga dinámica para que funcione de forma transparente.

Si se añade un nuevo hardware después de la instalación y este requiere un módulo kernel, el sistema debe ser configurado para cargar el módulo adecuado para el nuevo hardware. Cuando el sistema es arrancado con el nuevo hardware, se ejecuta el programa Kudzu detecta el nuevo hardware si es soportado y configura el módulo necesario para él. El módulo tambíen puede ser especificado manualmente modificando el archivo de configuración del módulo, /etc/modules.conf.

 

Nota Nota
Los módulos de tarjetas de vídeo usados para desplegar la interfaz del sistema X Window son parte del paquete XFree86, no del kernel; por lo tanto, este capítulo no se aplica a ellos.

Por ejemplo, si un sistema incluye un adaptador de red SMC EtherPower 10 PCI, el archivo de configuración del módulo contiene la línea siguiente:

alias eth0 tulip

Si una segunda tarjeta de red es añadida al sistema y es idéntica a la primera tarjeta, añada la línea siguiente al archivo /etc/modules.conf:

alias eth1 tulip

Consulte el Manual de referencia de Red Hat Enterprise Linux para una lista alfabética de módulos de kernel y hardware soportado por los módulos.

Nota: Kernels antiguos.

40.1. Utilidades del módulo del kernel

Está disponible un grupo de comandos para el manejo de módulos kernel si el paquete modutils está instalado. Use estos comandos para determinar si un módulo ha sido cargado exitósamente o cuando se esté probando módulos diferentes para una nueva pieza de hardware.

El comando /sbin/lsmod muestra una lista de los módulos cargados actualmente. Por ejemplo:

Module                  Size  Used by    Not tainted
iptable_filter          2412   0 (autoclean) (unused)
ip_tables              15864   1 [iptable_filter]
nfs                    84632   1 (autoclean)
lockd                  59536   1 (autoclean) [nfs]
sunrpc                 87452   1 (autoclean) [nfs lockd]
soundcore               7044   0 (autoclean)
ide-cd                 35836   0 (autoclean)
cdrom                  34144   0 (autoclean) [ide-cd]
parport_pc             19204   1 (autoclean)
lp                      9188   0 (autoclean)
parport                39072   1 (autoclean) [parport_pc lp]
autofs                 13692   0 (autoclean) (unused)
e100                   62148   1
microcode               5184   0 (autoclean)
keybdev                 2976   0 (unused)
mousedev                5656   1
hid                    22308   0 (unused)
input                   6208   0 [keybdev mousedev hid]
usb-uhci               27468   0 (unused)
usbcore                82752   1 [hid usb-uhci]
ext3                   91464   2
jbd                    56336   2 [ext3]

Por cada línea, la primera columna es el nombre del módulo, la segunda columna es el tamaño del módulo y la tercera es el recuento de usos.

La información después del recuento de usos varía un poco por módulo. Si se lista (unused) en la línea del módulo, el módulo no está siendo usado actualmente. Si (autoclean) está en la línea para el módulo, este puede ser limpiado automáticamente por el comando rmmod -a. Cuando se ejecuta este comando, cualquier módulo que este etiquetado con autoclean, que no ha sido usado desde la acción previa de autoclean, será descargado. Red Hat Enterprise Linux no realiza esta acción de autoclean por defecto.

Si el nombre de un módulo esta listado al final de la línea entre corchetes, el módulo entre corchetes es dependiente del módulo listado en la primera columna de la línea. Por ejemplo, en la línea

usbcore                82752   1 [hid usb-uhci]

los módulo del kernel hid usb-uhci dependen del módulo usbcore.

La salida /sbin/lsmod es la misma que la salida de /proc/modules.

Para cargar un módulo del kernel, use el comando /sbin/modprobe seguido del nombre del módulo. Por defecto, modprobe intenta cargar el módulo desde los subdirectorios/lib/modules/<kernel-version>/kernel/drivers/. Hay un subdirectorio para cada tipo de módulo, tal como el subdirectorio net/ para los controladores de interfaces de red. Algunos módulos del kernel tienen dependencias, es decir que otros módulos deben ser cargados antes para que el otro se cargue. El comando /sbin/modprobe verifica estas dependencias y carga los módulos necesarios antes de cargar el módulo específico.

Por ejemplo, el comando

/sbin/modprobe hid

carga cualquier dependencia de módulos y luego el módulo hid.

Para imprimir a la pantalla todos los comandos a medida en que /sbin/modprobe los ejecuta, use la opción -v. Por ejemplo:

/sbin/modprobe -v hid

Se despliega una salida similar a lo siguiente:

/sbin/insmod /lib/modules/2.4.21-1.1931.2.399.ent/kernel/drivers/usb/hid.o
Using /lib/modules/2.4.21-1.1931.2.399.ent/kernel/drivers/usb/hid.o
Symbol version prefix 'smp_'

El comando /sbin/insmod también existe para cargar módulos kernel; sin embargo no resuelve dependencias. Por ello se recomienda el uso de /sbin/modprobe.

Para descargar módulos del kernel, use el comando /sbin/rmmod seguido por el nombre del módulo. La utilidad rmmod sólo descarga módulos que ya no son usados y que no son una dependencia de otro módulo en uso.

Por ejemplo, el comando

/sbin/rmmod hid

baja el módulo del kernel hid.

Otra utilidad muy conveniente es modinfo. Use el comando /sbin/modinfo para mostrar información sobre el módulo del kernel. La sintaxis general es:

/sbin/modinfo [options] <module>

Las opciones incluyen -d, lo cual muestra una breve descripción del módulo, y -p lo que lista los parámetros que el módulo soporta. Para una lista completa de las opciones, consulte la página del manual de modinfo (man modinfo).