Handbook:AMD64/Networking/Advanced/pt-br
Configuração avançada
A variável config_eth0 é o coração da configuração de uma interface. É uma lista de instruções de alto nível para configuração da interface (eth0 neste caso). Cada comando na lista é executado sequencialmente. A interface é considerada OK se ao menos um dos comandos funcionar.
Aqui está uma lista de instruções embutidas:
| Valor | Descrição |
|---|---|
null
|
Nenhuma ação. |
noop
|
Se a interface está ativa e possui um endereço, então aborte a configuração reportando sucesso. |
| Um endereço IPv4 ou IPv6 | Adicione o endereço à interface. |
dhcp, adsl, ou apipa (ou algum valor de algum módulo de terceiros)
|
Execute o módulo que define o comando. Por exemplo, dhcp executa o módulo que provê DHCP, que pode ser servido pelo dhcpcd, dhclient, ou pump.
|
Se um comando falhar, execute um valor de "fallback". O fallback deve casar a estrutura de configuração exatamente.
É possível encadear esses valores em conjunto. Alguns exemplos reais:
/etc/conf.d/netExemplos de configuração# Adicionar três endereços IPv4
config_eth0="192.168.0.2/24
192.168.0.3/24
192.168.0.4/24"
# Adicionar um endereço IPv4 e dois endereços IPv6
config_eth0="192.168.0.2/24
4321:0:1:2:3:4:567:89ab
4321:0:1:2:3:4:567:89ac"
# Manter o endereço fornecido pelo kernel, a menos que a
# interface seja desconfigurada, então atribua outro
# via DHCP. Se o DHCP falhar, atribua um endereço
# estático determinado por APIPA
config_eth0="noop
dhcp"
fallback_eth0="null
apipa"
Quando usar o módulo
ifconfig e adicionar mais de um endereço, são criados aliases para as interfaces para cada endereço extra. Então, com os dois exemplos acima, o usuário terá as interfaces eth0, eth0:1 e eth0:2. Não é possível fazer nada especial com essas interfaces pois o kernel e outros programas simplesmente tratarão eth0:1 e eth0:2 como eth0.A ordem de "fallback" é importante! Se a opção "null" não for especificada o
apipa apenas seria executado se o noop falhasse.APIPA e DHCP são discutidos mais adiante.
Dependências de rede
Scripts de inicialização em /etc/init.d/ podem depender de uma interface específica ou apenas "net". Todas as interfaces de rede no sistema de inicialização do Gentoo fornecem o que é chamado "net".
Se, em /etc/rc.conf, a variável rc_depend_strict for YES, então as interfaces de rede que provêm "net" devem estar ativas antes que a dependência de "net" seja assumida como satisfeita. Em outras palavras, se um sistema possui as interfaces net.eth0 e net.eth1 e um script de inicialização depende de "net", então ambas devem estar habilitadas.
Por outro lado, usando rc_depend_strict="NO" a dependência "net" é marcada como resolvida no momento em que pelo menos uma das interfaces de rede for ativada.
Mas e se net.br0 depender de net.eth0 e net.eth1? net.eth1 pode ser um dispositivo sem fio ou PPP que precisa de configuração antes de poder ser adiciona à bridge. Isso não pode ser feito em /etc/init.d/net.br0 já que é um link simbólico para net.lo.
A solução é definir uma configuração rc_net_{interface}_need em /etc/conf.d/net:
/etc/conf.d/netAdicionando uma dependência a net.br0rc_net_br0_need="net.eth0 net.eth1"
Isso, porém, não é suficiente. Os scripts de inicialização de rede do Gentoo usam uma dependência virtual chamada "net" para informar ao sistema quando a rede está disponível. Obviamente, no caso acima, a rede só deve ser marcada como disponível quando net.br0 está configurada, não quando as outras estão. Assim, precisamos dizer isso também em /etc/conf.d/net:
/etc/conf.d/netAtualizando as dependências virtuais para a rederc_net_eth0_provide="!net"
rc_net_eth1_provide="!net"
For a more detailed discussion about dependency, consult the section on writing initscripts in the Gentoo Handbook. More information about /etc/rc.conf is available as comments within that file.
Variable names and values
Variable names are dynamic. They normally follow the structure of variable_${interface|mac|essid|apmac}. For example, the variable dhcpcd_eth0 holds the value for dhcpcd options for eth0 and dhcpcd_essid holds the value for dhcpcd options when any interface connects to the ESSID "essid".
However, there is no hard and fast rule that states interface names must be ethx. In fact, many wireless interfaces have names like wlanx, rax as well as ethx. Also, some user defined interfaces such as bridges can be given any name. To make life more interesting, wireless Access Points can have names with non alpha-numeric characters in them - this is important because users can configure networking parameters per ESSID.
The downside of all this is that Gentoo uses bash variables for networking - and bash cannot use anything outside of English alpha-numerics. To get around this limitation we change every character that is not an English alpha-numeric into an _ (underscore) character.
Another downside of bash is the content of variables - some characters need to be escaped. This can be achieved by placing the \ (backslash) character in front of the character that needs to be escaped. The following list of characters needs to be escaped in this way: ", ' and \.
In this example we use wireless ESSID as they can contain the widest scope of characters. We shall use the ESSID My "\ NET:
/etc/conf.d/netVariable names# This does work, but the domain is invalid
dns_domain_My____NET="My \"\\ NET"
The above sets the DNS domain to My "\ NET when a wireless card connects to an AP whose ESSID is My "\ NET.
Network interface naming
Como funciona
Network interface names are not chosen arbitrarily: the Linux kernel and the device manager (most systems have udev as their device manager although others are available as well) choose the interface name through a fixed set of rules.
When an interface card is detected on a system, the Linux kernel gathers the necessary data about this card. This includes:
- The onboard (on the interface itself) registered name of the network card, which is later seen through the ID_NET_NAME_ONBOARD value.
- The slot in which the network card is plugged in, which is later seen through the ID_NET_NAME_SLOT value.
- The path through which the network card device can be accessed, which is later seen through the ID_NET_NAME_PATH value.
- The (vendor-provided) MAC address of the card, which is later seen through the ID_NET_NAME_MAC value.
Based on this information, the device manager decides how to name the interface on the system. By default, it uses the first hit of the first three variables above (ID_NET_NAME_ONBOARD, _SLOT or _PATH). For instance, if ID_NET_NAME_ONBOARD is found and set to eno1, then the interface will be called eno1.
Given an active interface name, the values of the provided variables can be shown using udevadm:
root #udevadm test-builtin net_id /sys/class/net/enp3s0 2>/dev/nullID_NET_NAME_MAC=enxc80aa9429d76 ID_OUI_FROM_DATABASE=Quanta Computer Inc. ID_NET_NAME_PATH=enp3s0
As the first (and actually only) hit of the top three variables is ID_NET_NAME_PATH, its value is used as the interface name. If none of the variables contain values, then the system reverts back to the kernel-provided naming (eth0, eth1, etc.)
Using the old-style kernel naming
Before this change, network interface cards were named by the Linux kernel itself, depending on the order that drivers are loaded (amongst other, possibly more obscure reasons). This behavior can still be enabled by setting the net.ifnames=0 boot parameter in the boot loader.
Using custom names
The entire idea behind the change in naming is not to confuse people, but to make changing the names easier. Suppose a system has two interfaces that are otherwise called eth0 and eth1. One is meant to access the network through a wire, the other one is for wireless access. With the support for interface naming, users can have these called lan0 (wired) and wifi0 (wireless - it is best to avoid using the previously well-known names like eth* and wlan* as those can still collide with the suggested names).
Find out what the parameters are for the cards and then use this information to set up a custom own naming rule:
root #udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/nullID_NET_NAME_MAC=enxc80aa9429d76 ID_OUI_FROM_DATABASE=Quanta Computer Inc.
root #vim /etc/udev/rules.d/70-net-name-use-custom.rules# First one uses MAC information, and 70- number to be before other net rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c8:0a:a9:42:9d:76", NAME="lan0"
root #vim /etc/udev/rules.d/76-net-name-use-custom.rules# Second one uses ID_NET_NAME_PATH information, and 76- number to be between
# 75-net-*.rules and 80-net-*.rules
SUBSYSTEM=="net", ACTION=="add", ENV{ID_NET_NAME_PATH}=="enp3s0", NAME="wifi0"
Because the rules are triggered before the default one (rules are triggered in alphanumerical order, so 70 comes before 80) the names provided in the rule file will be used instead of the default ones. The number granted to the file should be between 76 and 79 (the environment variables are defined by a rule start starts with 75 and the fallback naming is done in a rule numbered 80).