Gentoo Logo

[ << ] [ < ] [ Inicio ] [ > ] [ >> ]


2. Configuración Avanzada

Contenido:

2.a. Configuración Avanzada

La variable config_eth0 es el corazón de la configuración de una interfaz. Es una lista de instrucciones de alto nivel para configurar la interfaz (eth0 en este caso). Cada orden en la lista de instrucciones se ejecuta de manera secuencial. La interfaz será evaluada como OK si, al menos, un orden funciona.

Aquí tiene una lista de instrucciones integradas:

Orden Descripción
null No hace nada
noop Si la interfaz está funcionando y existe una dirección entonces aborta la configuración con éxito.
una dirección IPv4 o IPv6 Añade la dirección a la interfaz
dhcp,adsl o apipa (o una orden propia perteneciente a un módulo de terceras partes) Ejecuta el módulo que proporciona la orden. Por ejemplo dhcp ejecutará un módulo que proporcione dhcp, que pudiera ser uno cualquiera de los siguientes: dhcpcd, dhclient o pump.

Si una orden falla, puede especificar una orden de retorno (fallback). El retorno tiene que coincidir exactamente con la estructura de la configuración.

Puede encadenar estas órdenes. A continuación se muestran algunos ejemplos reales:

Listado de Código 1.1: Ejemplos de configuración

# Añadir tres direcciones IPv4
config_eth0="192.168.0.2/24
192.168.0.3/24
192.168.0.4/24"

# Añadir una dirección IPv4 y dos IPv6
config_eth0="192.168.0.2/24
4321:0:1:2:3:4:567:89ab
4321:0:1:2:3:4:567:89ac"

# Mantener la dirección asignada por el núcleo, a menos que la
interfaz se caiga, entonces asignar otra vía DHCP. Si DHCP falla entonces
añadir una dirección estática determinada mediante APIPA

config_eth0="noop
dhcp"
fallback_eth0="null
apipa"

Nota: Cuando se utiliza el módulo ifconfig y se añade más de una dirección, se crean alias de interfaz para cada dirección extra. De esta manera los dos ejemplos anteriores tendrán interfaces eth0, eth0:1 y eth0:2. No se puede hacer nada especial con estas interfaces ya que el núcleo y otros programas simplemente tratan eth0:1 y eth0:2 como eth0.

Importante: ¡La orden de retorno es importante! Si no especificamos la opción null, la orden apipa se ejecutaría solo si la orden noop falla.

Nota: APIPA y DHCP serán tratados más adelante.

2.b. Dependencias de red

Los guiones en /etc/init.d pueden depender de una interfaz de red específica o, simplemente, de net (red). Todos los interfaces de red en el sistema de inicio de Gentoo proporcionan algo llamado net.

Si está configurado rc_depend_strict="YES" en /etc/rc.conf, entonces todos los interfaces de red que proporcionen net deben estar activos antes que pueda considerarse cumplida la dependencia en "net". En otras palabras, si tienen los interfaces net.eth0 y net.eth1 y un guión de inicio depende de "net", ambos deben estar activados.

Por otro lado, si está configurado rc_depend_strict="NO", entonces la dependencia de "net" se considera cumplida al momento de estar activo al menos uno de los interfaces de red.

Pero, ¿y qué pasa si net.br0 depende de net.eth0 y net.eth1? net.eth1 podría ser un dispositivo wireless o ppp que necesita configurarse antes de añadirse al puente. Esto no puede hacerse en /etc/init.d/net.br0 ya que es un enlaces simbólico a net.lo.

La respuesta es definir nuestra propia requerimiento rc_need_ en /etc/conf.d/net

Listado de Código 2.1: Dependencia de net.br0 en /etc/conf.d/net


rc_need_br0="net.eth0 net.eth1"

Lo anterior no es suficiente. Los guiones de inicio de Gentoo utilizan una dependencia virtual llamada net para informar al sistema cuando está disponible la conexión a red. Claramente, en el caso de arriba la conexión a red debería marcarse como disponible cuando net.br0 está funcionando, no cuando lo están las otras. Por lo que tenemos que indicar también esto en /etc/conf.d/net:

Listado de Código 2.2: Actualizar las dependencias y provisiones para los servicios de red

rc_net_lo_provide="!net"
rc_net_eth0_provide="!net"
rc_net_eth1_provide="!net"

Para una lectura más detallada sobre dependencias, consulte la sección Guiones de Inicio en el manual de Gentoo. Se puede encontrar más información acerca de /etc/rc.conf en los comentarios dentro del propio archivo.

2.c. Nombre de variables y valores

Los nombre de variables son dinámicos. Normalmente sigue la estructura variable_${interface|mac|essid|apmac}. Por ejemplo, la variable dhcpcd_eth0 guarda los valores para las opciones de dhcpcd para eth0 y dhcpcd_essid los valores para dhcpcd cuando cualquier interfaz se conecta al ESSID "essid".

Sin embargo, no hay ninguna regla que indique que los nombre de las interfaces sean ethx. De hecho, muchas interfaces wireless tienen nombres como wlanx, rax o ethx. También, algunas interfaces definidas por el usuario como pueden ser puentes puede tener cualquier nombre, como foo. Para hacer la vida un poco más interesante, los puntos de acceso wireless pueden tener nombres con caracteres no alfanuméricos - esto es importante porque puede configurar los parámetros de red por ESSID.

La desventaja de todo esto es que Gentoo usa variables bash para la red - y bash no puede utilizar nada fuera de caracteres alfanuméricos ingleses. Para solucionar esta limitación cambiamos cada carácter que no sea alfanumérico inglés por un carácter _.

Otra desventaja de bash es el contenido de las variables - algunos caracteres necesitan especificarse de manera especial. Esto se hace utilizando \ delante del carácter. A continuación tenemos una lista de caracteres especiales que necesitamos indicar de esta manera. ",' y \.

En este ejemplo utilizamos ESSID wireless ya que puede contener un amplio abanico de caracteres. Deberemos utilizar ESSID My "\ NET:

Listado de Código 3.1: Ejemplo de nombre para la variable

(Esto funciona, pero el dominio no es válido)
dns_domain_My____NET="My \"\\ NET"

(Lo que hay arriba configura el dominio dns a My "\ NET cuando una
tarjeta wireless se conecta a un AP cuyo ESSID es My "\ NET)

2.d. Nombrado de las interfaces de red

Cómo funciona

Los nombres de la interfaces de red no se obtienen de forma arbitraria, el núcleo Linux y el gestor de dispositivos (la mayoría de sistemas utilizan udev como gestor de dispositivos, aunque existen otros) obtiene el nombre de la interfaz mediante una serie de reglas prefijadas.

Cuando se detecta una interfaz en un sistema, el núcleo Linux recolecta los datos disponibles para esa tarjeta de red. Estos datos incluyen:

  1. el nombre registrado de tarjeta de red (en la propia interfaz) y que más tarde se podrá obtener a través del parámetro ID_NET_NAME_ONBOARD;
  2. la ranura en la cual se ha insertado la tarjeta de red y que más tarde se podrá obtener a través del parámetro ID_NET_NAME_SLOT;
  3. la ruta a través de la cual se accede a la tarjeta de red y que más tarde se podrá obtener a través del parámetro ID_NET_NAME_PATH;
  4. la dirección MAC (que ofrece el fabricante) de la tarjeta y que más tarde se podrá obtener mediante el parámetro ID_NET_NAME_MAC;

Basándose en esta información, el gestor de dispositivos decide como nombrar a las interfaces presentes en el sistema. Por defecto, utiliza el primero de los tres primeros parámetros que se muestran arriba (ID_NET_NAME_ONBOARD, _SLOT o _PATH). Por ejemplo, si se encuentra un valor para ID_NET_NAME_ONBOARD y éste es eno1, entonces la interfaz de red se llamará eno1.

Si sabe el nombre de su interfaz, puede ver los valores de los parámetros mediante la orden udevadm:

Listado de Código 4.1: Leer la información de la tarjeta de interfaz de red

# udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/null
ID_NET_NAME_MAC=enxc80aa9429d76
ID_OUI_FROM_DATABASE=Quanta Computer Inc.
ID_NET_NAME_PATH=enp3s0

Como el primer (y realmente el único) de los parámetros que aparecen es ID_NET_NAME_PATH, su valor se utiliza para nombrar al interfaz de red. Si no se encuentra ninguno de los parámetros, entonces el sistema utiliza los nombres que ofrece el núcleo (eth0, eth1, etc.)

Utilizar el nombrado al viejo estilo del núcleo

Antes de este cambio, era el núcleo el que ponía los nombres a las tarjetas de red, dependiendo del orden en el que se cargaran sus controladores (entre otras, probablemente oscuras razones). Este comportamiento se puede aún activar definiendo la opción net.ifnames=0 en el gestor de arranque.

Usar sus propios nombres

La idea detrás de este cambio en el nombrado es la de no confundir a la gente y hacer los cambios de nombre de forma fácil. Suponga que tiene dos interfaces que se llamarían eth0 y eth1. Una se utiliza para acceder a la red a través de cable y la otra es inalámbrica. Con el soporte para el nombrado de interfaces, puede llamarlas lan0 (cableada) y wifi0 (inalámbrica, es mejor evitar usar los nombres anteriores bien conocidos como eth* y wlan* ya que todavía pueden parecerse a los nombres que hemos sugerido).

Todo lo que necesita ahora es encontar los parámetros para las tarjetas y utilizar esta información para definir su propia regla de nombrado:

Listado de Código 4.2: Definir el nombre lan0 para la interfaz actual eth0

# udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
ID_NET_NAME_MAC=enxc80aa9429d76
ID_OUI_FROM_DATABASE=Quanta Computer Inc.

# vim /etc/udev/rules.d/76-net-name-use-custom.rules
# La primera utilizar información de la dirección MAC
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_MAC}=="enxc80aa9429d76", NAME="lan0"
# La segunda utilizar información del parámetro ID_NET_NAME_PATH
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="wifi0"

Debido a que las reglas se disparan antes de la regla por defecto (las reglas se disparan en orden alfanumérico, por lo que la 70 se lee antes que la 80), los nombres ofrecidos en el fichero de reglas se utilizarán en lugar de los que se usan por defecto. El número asignado al fichero debería estar entre 76 y 79 (las variables de entorno se definen mediante una regla que comienza por 75 y el nombrado por defecto lo realiza una regla con el número 80).


[ << ] [ < ] [ Inicio ] [ > ] [ >> ]


Imprimir

Ver completo

Página actualizada 12 de abril, 2014

Esta traducción ha dejado de tener soporte

Sumario: Aquí aprendemos acerca de cómo funciona la configuración - hace falta conocer esta sección para aprender a trabajar con redes modularmente.

Sven Vermeulen
Autor

Roy Marples
Autor

Daniel Robbins
Autor

Chris Houser
Autor

Jerry Alexandratos
Autor

Seemant Kulleen
Desarrollador Gentoo x86

Tavis Ormandy
Desarrollador Gentoo Alpha

Jason Huebel
Desarrollador Gentoo AMD64

Guy Martin
Desarrollador Gentoo HPPA

Pieter Van den Abeele
DesarrolladorGentoo PPC

Joe Kallar
Desarrollador Gentoo SPARC

John P. Davis
Editor

Pierre-Henri Jondot
Editor

Eric Stockbridge
Editor

Rajiv Manglani
Editor

Jungmin Seo
Editor

Stoyan Zhekov
Editor

Jared Hudson
Editor

Colin Morey
Editor

Jorge Paulo
Editor

Carl Anderson
Editor

Jon Portnoy
Editor

Zack Gilburd
Editor

Jack Morgan
Editor

Benny Chuang
Editor

Erwin
Editor

Joshua Kinard
Editor

Tobias Scherbaum
Editor

Xavier Neys
Editor

Grant Goodyear
Reviewer

Gerald J. Normandin Jr.
Reviewer

Donnie Berkholz
Reviewer

Ken Nowack
Reviewer

Lars Weiler
Colaborador

José Alberto Suárez López
Traductor

John Christian Stoddart
Traductor

José Luis Rivero
Traductor

Carles Ferrer
Traductor

Andrés Pereira
Traductor

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.