Como migrei para arquivos-chave do NetworkManager para configuração
Os arquivos de configuração de interface podem não ser suportados no Fedora por muito mais tempo, mas migrar para o NetworkManager é mais fácil do que você imagina.
O NetworkManager foi introduzido em 2004 para tornar a configuração da rede mais flexível e dinâmica. Os antigos scripts de shell de inicialização do SystemV, dos quais os arquivos de configuração da interface faziam parte, eram incapazes de lidar com WiFi, com fio, VPNs, modems de banda larga e muito mais – ou pelo menos incapazes de fazê-lo de forma rápida ou eficiente.
Em uma série de artigos, escrevi sobre por que sou fã do NetworkManager e como o uso. Na parte 1, observei o que o NetworkManager faz e algumas das ferramentas que ele fornece para visualizar conexões e dispositivos de rede. Nesse artigo, mencionei que o NetworkManager não precisa de arquivos de configuração de interface para a maioria dos hosts. No entanto, ele pode criar seus próprios arquivos de configuração no estilo ini e reconhece os arquivos de configuração de interface de rede mais antigos. Os arquivos de configuração do NetworkManager são oficialmente chamados de arquivos-chave. Na parte 2, examinei os arquivos de configuração de interface obsoletos e como configurá-los, caso você ainda os esteja usando.
O suporte para os arquivos obsoletos ifcfg
não é mais fornecido por padrão para novas instalações começando com o Fedora 36. Ele continuará a usá-los em sistemas que foram atualizados de versões anteriores do Fedora para a versão 36 - pelo menos por mais algum tempo. Ainda assim, não é uma boa ideia, neste estágio final, depender de arquivos de configuração ifcfg
obsoletos. Portanto, na parte 3 desta série, demonstrarei a migração de arquivos de configuração de interface existentes para os arquivos-chave do NetworkManager usando a ferramenta de linha de comando fornecida. Também examinarei o uso de ferramentas de linha de comando e GUI para criar novos arquivos-chave do zero e compará-los para facilitar o uso.
A migração é consideravelmente mais simples do que parece. Usei o comando nmcli connection migrate
nos dois sistemas que precisei migrar, um com uma única placa de interface de rede (NIC) e outro, meu roteador/firewall, com três NICs. Após alguns testes extensivos em uma VM, também funcionou perfeitamente na primeira vez em ambos os hosts de produção. É isso: nenhum outro comando, opção ou argumento é necessário. E é rápido, demorando muito menos de um segundo em ambos os hosts.
Por que devo migrar meus arquivos?
A maioria das restrições dos scripts de shell antigos reside na estrutura — ou na falta dela — dos arquivos ifcfg
. O NetworkManager introduziu os novos arquivos-chave de conexão de rede para superar esses problemas. Mas até o Fedora 36, ele ainda reconheceria os antigos arquivos de configuração ifcfg
. Agora, o NetworkManager não cria mais nem oferece suporte a arquivos ifcfg
para novas instalações.
Eu experimentei o NetworkManager em uma nova instalação do Fedora 36 e não consegui convencê-lo a usar arquivos ifcfg
recém-criados. Ele continuou a tratar as interfaces como protocolo de configuração dinâmica de host (DHCP) e a obter seus valores de configuração do servidor DHCP. Os arquivos ifcfg
não são mais suportados em novas instalações porque o pacote NetworkManager-initscripts-ifcfg-rh
não está mais instalado. Esse pacote contém as ferramentas necessárias para usar os arquivos ifcfg
. Hosts atualizados de versões mais antigas do Fedora ainda terão o pacote NetworkManager-initscripts-ifcfg-rh
instalado, então ele será, por enquanto, atualizado junto com o restante da instalação para o Fedora 36. Isso pode não ser verdade no futuro.
Se você estiver usando a configuração DHCP para seus hosts de rede, não será necessário migrar nenhum arquivo ifcfg
. Na verdade, você pode simplesmente excluí-los, se ainda existirem, e o NetworkManager cuidará do gerenciamento das conexões de rede. Pessoalmente, prefiro mover arquivos obsoletos como esses para um subdiretório de arquivo em /root
para que eu possa encontrá-los mais tarde, apenas por precaução.
Todos os hosts com conexões estáticas devem ser migrados. Isso geralmente inclui servidores, firewalls e outros hosts que podem precisar executar suas funções de rede sem que o servidor DHCP esteja ativo. Eu tenho dois hosts como este: meu servidor principal e meu firewall/roteador.
Meus experimentos
Quando o NetworkManager descontinuou oficialmente os arquivos de configuração da interface localizados em /etc/sysconfig/network-scripts
, ele não parou imediatamente de usá-los, mas o procedimento de atualização caiu em um arquivo leia-me, /etc /sysconfig/network-scripts/readme-ifcfg-rh.txt
. Este pequeno arquivo declara explicitamente que os arquivos no estilo ifcfg
estão obsoletos. Ele também fornece um comando simples que realiza a migração para nós.
Sugiro que você leia esse arquivo em seu host e experimente em um ambiente que não seja de produção. Usei uma VM para meus experimentos e aprendi muito. Antes de começar a fazer alterações, exibi os dados de conexão mostrados abaixo para obter o estado atual da conexão de rede.
[root@myserver ~]# nmcli
enp0s3: connected to Wired connection 1
"Intel 82540EM"
ethernet (e1000), 08:00:27:07:CD:FE, hw, mtu 1500
ip4 default
inet4 192.168.0.136/24
route4 192.168.0.0/24 metric 100
route4 default via 192.168.0.254 metric 100
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.0.52 8.8.8.8 8.8.4.4
domains: example.org
interface: enp0s3
Criei um arquivo ifcfg
simples que define uma configuração estática em uma de minhas VMs e depois testei-o para verificar se essa configuração estática funcionava corretamente. Aqui está o arquivo ifcfg-enp0s3
que criei para este teste:
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
# HWADDR=08:00:27:07:CD:FE
IPADDR=192.168.0.95
PREFIX=24
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=enp0s3
ONBOOT=yes
DNS1=192.168.0.52
DNS2=8.8.8.8
AUTOCONNECT_PRIORITY=-999
DEVICE=enp0s3
Comentei o endereço do hardware no arquivo ifcfg-enp0s3
porque não parece necessário. Tentei das duas maneiras e funcionou tão bem de qualquer maneira - quando finalmente consegui funcionar. O NetworkManager ignorou completamente o conteúdo deste arquivo até que eu instalei o pacote NetworkManager-initscripts-ifcfg-rh
. Depois disso, o NetworkManager conseguiu definir a configuração da rede a partir deste arquivo ifcfg-enp0s3
.
Então chegou a hora de experimentar a ferramenta de migração. Executei o comando mostrado abaixo para migrar o arquivo ifcfg
para um arquivo-chave.
[root@myserver system-connections]# nmcli connection migrate
Connection 'Wired connection 1' (c7b11d30-522e-306f-8622-527119911afc) successfully migrated.
[root@myserver system-connections]#
Este comando levou menos de um segundo. Ele cria o novo arquivo-chave e depois exclui o arquivo ifcfg
. Sugiro fazer uma cópia do arquivo ifcfg
original antes de executar esta ferramenta de migração. Ele criou o arquivo /etc/NetworkManager/system-connections/enp0s3.nmconnection
para meu host. Sem especificar uma interface específica, este comando migrará todos os arquivos ifcfg
localizados em /etc/sysconfig/network-scripts
. Se um host tiver vários NICs e arquivos ifcfg
correspondentes, dos quais apenas alguns você deseja migrar, você poderá especificar uma lista de conexões para migrar.
Os arquivos-chave podem ser modificados usando seu editor favorito. Tentei fazer isso alterando a entrada IPADDR
e reiniciando o NetworkManager apenas para ter certeza de que funcionava. O comando nmcli connection reload
não funcionou para mim. Não é recomendado fazer alterações diretamente nos arquivos-chave usando um editor, mas funciona. Para ser honesto, muitos administradores de sistemas experientes (como eu) realmente preferem editar arquivos de configuração de texto ASCII diretamente, então - recomendado ou não - é assim que faço as coisas na maioria das vezes. Eu só gosto de saber o que realmente há nesses arquivos para poder reconhecer quando algo está errado com eles. Ajuda a resolver problemas de configuração.
Fazendo isso de verdade
Depois de um dia de experiências para entender perfeitamente como tudo isso funciona e como me recuperar caso falhe, eu estava pronto para fazer isso de verdade. Escolhi meu servidor principal para esta tentativa inicial porque ele possui apenas uma única NIC, o que tornará mais rápido o retorno à Internet se houver algum problema.
Primeiro, copiei o arquivo /etc/sysconfig/network-scripts/ifcfg-eno1
mostrado abaixo para /root
como backup. O comando nmcli connection migrate
pode fazer a conversão de volta do arquivo-chave para o arquivo ifcfg
. Mas por que me preocupar quando posso ter um backup exato pronto para voltar?
HWADDR=e0:d5:5e:a2:de:a4
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=yes
IPADDR=192.168.0.52
PREFIX=24
GATEWAY=192.168.0.254
DOMAIN=example.org
IPV6INIT=no
DNS1=192.168.0.52
DNS2=8.8.8.8
DNS3=8.8.4.4
IPV4_FAILURE_FATAL=no
IPV6INIT=no
PEERROUTES=no
NAME="enp0s31f6"
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
DEVICE="enp0s31f6"
Depois de executar o comando nmcli connection migrate
, verifiquei que ele emite a linha de status para indicar que a conversão ocorreu, o que ocorreu. Em seguida, verifiquei se o arquivo ifcfg
havia desaparecido e o arquivo-chave /etc/NetworkManager/system-connections/enp0s31f6.nmconnection
estava no lugar:
[connection]
id=enp0s31f6
uuid=abf4c85b-57cc-4484-4fa9-b4a71689c359
type=ethernet
autoconnect-priority=-999
interface-name=enp0s31f6
[ethernet]
mac-address=E0:D5:5E:A2:DE:A4
[ipv4]
address1=192.168.0.52/24,192.168.0.254
dns=192.168.0.52;8.8.8.8;8.8.4.4;
dns-search=example.org;
ignore-auto-routes=true
method=manual
[ipv6]
addr-gen-mode=stable-privacy
method=ignore
never-default=true
[proxy]
Este arquivo não será usado até que o NetworkManager seja reiniciado ou o host seja reinicializado. Primeiro reiniciei o NetworkManager e depois verifiquei o resultado, conforme mostrado abaixo. A configuração da rede parece correta:
[root@myserver ~]# nmcli
enp0s31f6: connected to enp0s31f6
"Intel I219-V"
ethernet (e1000e), E0:D5:5E:A2:DE:A4, hw, mtu 1500
ip4 default
inet4 192.168.0.52/24
route4 default via 192.168.0.254 metric 100
route4 192.168.0.0/24 metric 100
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.0.52 8.8.8.8 8.8.4.4
domains: example.org
interface: enp0s31f6
Após uma reinicialização completa, verifiquei a configuração da rede novamente e ela parecia idêntica à saída acima. Com isso funcionando, removi o pacote NetworkManager-initscripts-ifcfg-rh
e reiniciei novamente, só porque não custa nada verificar tudo.
Assim que soube que a ferramenta de migração funciona em um dos meus sistemas de produção, e um sistema importante, eu estava pronto para fazer isso no meu firewall/roteador, aquele com três NICs. Executei o mesmo comando nmcli connection migrate
naquele host e verifiquei os resultados. Depois de garantir que tudo estava funcionando corretamente, usei o DNF para remover o pacote NetworkManager-initscripts-ifcfg-rh
de ambos os hosts de produção. E testei mais algumas reinicializações de cada host apenas para garantir que nada funcionasse durante a remoção do pacote initscripts
.
E se eu não tiver arquivos ifcfg?
Novas instalações do Fedora não criam nenhum tipo de arquivo de configuração de interface de rede. O padrão é que o NetworkManager lide com interfaces de rede como conexões DHCP. Portanto, você não precisa fazer nada para que os hosts que usam DHCP obtenham suas informações de configuração de rede.
No entanto, você pode precisar criar uma configuração estática para alguns novos hosts, mesmo quando não tiver um arquivo ifcfg
obsoleto para migrar.
Revertendo para DHCP
A reversão para o uso de DHCP é fácil. Basta remover o arquivo-chave da conexão desejada de /etc/NetworkManager/system-connections/
e reiniciar o NetworkManager. Remover pode significar mover o arquivo para outro lugar ou simplesmente excluí-lo.
Em preparação para minha próxima série de experimentos na criação de novos arquivos-chave, movi o arquivo-chave enp0s31f6.nmconnection
para /root
e reiniciei o NetworkManager.
Criando novos arquivos-chave
Embora o antigo comando ip
ainda possa ser usado para modificar as configurações da interface de rede em um ambiente ativo, essas alterações não são persistentes após uma reinicialização. Alterações feitas usando ferramentas do NetworkManager, como nmcli
ou nmtui
, o editor de conexão GUI do NetworkManager (nm-connection-editor
) e seu editor de texto favorito são persistentes. O editor de conexão está disponível para o Fedora na bandeja do sistema para cada um dos desktops que experimentei – Xfce, Cinnamon, LXDE, KDE Plasma – e provavelmente para o restante dos desktops que ainda não experimentei.
Editor de texto
Supondo que você esteja familiarizado com a estrutura, sintaxe e variáveis do arquivo-chave, é possível criar ou modificar arquivos-chave do zero apenas com um editor de texto ASCII. Por mais que eu aprecie e use esse recurso, usar uma das três ferramentas fornecidas geralmente é muito mais simples.
Usando nmtui
A ferramenta nmtui
(NetworkManager Text User Interface) é minha segunda escolha para uma ferramenta neste trio. Acho a interface complicada, pouco atraente e pouco intuitiva. Esta ferramenta não é instalada por padrão e provavelmente não a teria instalado se não estivesse escrevendo este artigo.
No entanto, funciona e criou um arquivo-chave para mim que era essencialmente idêntico ao criado pelo GUI Connection Manager que discuto abaixo. As únicas diferenças que encontrei (usando o comando diff
, é claro) foram o campo de carimbo de data/hora no arquivo e uma seleção diferente que fiz intencionalmente ao configurar a conexão. A interface fornece algumas dicas sobre os dados que você precisa fornecer para criar um arquivo-chave funcional.
Inicie esta ferramenta digitando o comando nmtui
na linha de comando. Em geral, as teclas de seta permitem a movimentação entre os campos nas páginas exibidas, e a tecla Enter seleciona um item para modificar ou adicionar. As teclas Page Up/Page Down rolam a página. Selecione Editar uma conexão e pressione Enter para criar um novo arquivo-chave.
(David Ambos, CC BY-SA 4.0)
Depois de percorrer a interface, cheguei à página Editar conexão. Não ficou claro para mim nesta interface que o prefixo CIDR deveria ser anexado ao endereço IP, mas fiz isso mesmo assim e funcionou. Preencha os dados apropriados nesta página para configurar a interface. Observe que desativei o IPV6.
(David Ambos, CC BY-SA 4.0)
Em seguida, role até o final da página usando o teclado e pressione OK para salvar o arquivo-chave. O arquivo-chave é salvo imediatamente, mas o NetworkManager deve ser reiniciado para ativar esse arquivo, seja ele novo ou alterado. Embora esta não seja minha interface favorita para criar e gerenciar arquivos-chave do NetworkManager, pretendo usá-la quando o GUI Connection Editor não estiver disponível, como ao trabalhar em um host remoto.
Usando nmcli
Eu usei a ferramenta nmcli
(Network Manager Command Line Interface) para configurar uma interface no passado, e essa ferramenta também funciona muito bem. Eu gosto menos porque requer mais digitação e leitura da página de manual e das referências online. A execução do comando cria imediatamente o arquivo de configuração da interface no diretório /etc/NetworkManager/system-connections/
.
O comando mostrado abaixo adiciona o arquivo-chave necessário, assim como as outras ferramentas.
[root@myserver system-connections]# nmcli connection add connection-name enp0s3-Wired ifname enp0s3 type ethernet ipv4.addresses 192.168.0.136/24 ipv4.gateway 192.168.0.254 ipv4.dns 192.168.0.254,8.8.8.8,8.8.4.4 ipv4.dns-search example.org ipv6.method disabled
Connection 'ethernet-enp0s3' (67d3a3c1-3d08-474b-ae91-a1005f323459) successfully added.
[root@myserver system-connections]# cat enp0s3-Wired.nmconnection
[connection]
id=ethernet-enp0s3
uuid=67d3a3c1-3d08-474b-ae91-a1005f323459
type=ethernet
interface-name=enp0s3
[ethernet]
[ipv4]
address1=192.168.0.136/32,192.168.0.254
dns=192.168.0.52;8.8.8.8;8.8.4.4;
dns-search=example.org;
method=manual
[ipv6]
addr-gen-mode=stable-privacy
method=disabled
[proxy]
[root@myserver system-connections]#
Uma das ferramentas de assistência disponíveis ao usar nmcli connection add
é a sequência de conclusão de tabulação do Bash que mostra os subcomandos disponíveis:
[root@myserver system-connections]# nmcli connection add <tab><tab>
autoconnect ifname ipv6.dhcp-send-hostname
con-name ipv4.addresses ipv6.dhcp-timeout
connection.auth-retries ipv4.dad-timeout ipv6.dns
connection.autoconnect ipv4.dhcp-client-id ipv6.dns-options
connection.autoconnect-priority ipv4.dhcp-fqdn ipv6.dns-priority
connection.autoconnect-retries ipv4.dhcp-hostname ipv6.dns-search
connection.autoconnect-slaves ipv4.dhcp-hostname-flags ipv6.gateway
connection.dns-over-tls ipv4.dhcp-iaid ipv6.ignore-auto-dns
connection.gateway-ping-timeout ipv4.dhcp-reject-servers ipv6.ignore-auto-routes
connection.id ipv4.dhcp-send-hostname ipv6.ip6-privacy
connection.interface-name ipv4.dhcp-timeout ipv6.may-fail
connection.lldp ipv4.dhcp-vendor-class-identifier ipv6.method
connection.llmnr ipv4.dns ipv6.never-default
connection.master ipv4.dns-options ipv6.ra-timeout
connection.mdns ipv4.dns-priority ipv6.required-timeout
connection.metered ipv4.dns-search ipv6.route-metric
connection.mud-url ipv4.gateway ipv6.routes
connection.multi-connect ipv4.ignore-auto-dns ipv6.route-table
connection.permissions ipv4.ignore-auto-routes ipv6.routing-rules
connection.read-only ipv4.may-fail ipv6.token
connection.secondaries ipv4.method master
connection.slave-type ipv4.never-default match.driver
connection.stable-id ipv4.required-timeout match.interface-name
connection.timestamp ipv4.route-metric match.kernel-command-line
connection.type ipv4.routes match.path
connection.uuid ipv4.route-table proxy.browser-only
connection.wait-device-timeout ipv4.routing-rules proxy.method
connection.zone ipv6.addresses proxy.pac-script
help ipv6.addr-gen-mode proxy.pac-url
hostname.from-dhcp ipv6.dhcp-duid slave-type
hostname.from-dns-lookup ipv6.dhcp-hostname tc.qdiscs
hostname.only-from-default ipv6.dhcp-hostname-flags tc.tfilters
hostname.priority ipv6.dhcp-iaid type
[root@myserver system-connections]# nmcli connection add
Normalmente prefiro a linha de comando para a maioria das tarefas. No entanto, a complexidade de obter a sintaxe e as opções corretas desse comando significa que devo sempre usar a página de manual e pesquisar o comando antes de emiti-lo. Isso leva tempo. E ainda reclamava de coisas que perdi ou errei. Mesmo quando não gerou um erro, ele criou arquivos-chave que funcionaram mal, se é que funcionaram. Por exemplo, a conexão funcionou quando eu saía via SSH da VM de teste, mas não conseguia fazer SSH na VM de teste. Ainda não tenho certeza de qual era o problema, mas esse arquivo-chave tinha o prefixo CIDR errado para o endereço IP. Finalmente consegui acertar o comando consultando o exemplo na página de manual nmcli-examples(7).
Quando este é o único método disponível, posso fazê-lo, mas é a ferramenta menos preferida.
Usando o editor de conexão GUI NetworkManager
Usei um de meus laptops em partes desta seção para mostrar conexões com e sem fio. Embora eu normalmente prefira ferramentas de linha de comando, gosto mais desta ferramenta de editor de conexão GUI NetworkManager de todas as três opções de ferramentas disponíveis. É fácil de usar, intuitivo, fornece acesso rápido a qualquer item de configuração que seja necessário e está disponível diretamente na bandeja do sistema de desktop de todos os desktops que experimentei.
Basta clicar com o botão direito no ícone de rede, aquele que se parece com um par de computadores, na bandeja do sistema. Em seguida, escolha Editar conexões.
(David Ambos, CC BY-SA 4.0)
Isso abre a janela de edição da conexão, conforme ilustrado abaixo. Clique duas vezes na conexão desejada na lista de conexões, geralmente Wired Connection 1
ou um SSID WiFi. A ilustração abaixo mostra conexões com e sem fio abertas para edição em um dos meus laptops. Nunca precisei editar uma conexão sem fio porque aquelas que eu conecto sempre usam DHCP para configuração. É possível exigir endereçamento estático para conexões sem fio, mas nunca encontrei isso.
(David Ambos, CC BY-SA 4.0)
A guia Ethernet da janela de diálogo Editar conexão com fio 1 mostra o nome do dispositivo enp111s0
para este laptop. Na maioria dos casos, nada nesta página precisa ser alterado.
De volta à minha VM, alterei o campo Método de Automático (DHCP) para Manual. Adicionei o endereço IP, o prefixo CIDR e a rota padrão (gateway) que desejo para este host. Também adicionei três servidores DNS e o domínio de pesquisa. Estas são as variáveis de configuração mínimas necessárias para uma conexão de rede. Eles também são os mesmos definidos nos arquivos de configuração da interface e nos arquivos-chave anteriores. O nome do dispositivo para esta NIC é enp0s3
. Aqui está a configuração da conexão com fio usando a ferramenta de edição de conexão GUI NetworkManager.
(David Ambos, CC BY-SA 4.0)
Outra opção disponível para o campo Método é Desativado. Defino o IPV6 como Desativado, pois não uso IPV6.
Depois de definir esses valores, clicar no botão Salvar cria o novo arquivo-chave imediatamente. Fazer alterações nos arquivos-chave existentes é igualmente fácil. Entretanto, o NetworkManager deve ser reiniciado para que essas alterações de configuração tenham efeito.
Em termos de tempo e trabalho envolvidos na criação de novos arquivos-chave do NetworkManager, o GUI Connection Editor é muito melhor que as outras opções. Ele fornece uma interface fácil de usar com informações suficientes sobre os dados necessários para ser útil.
Conclusões
O Fedora 36 muda a equação para usar os arquivos de configuração de interface obsoletos e antigos. Para novas instalações do Fedora 36, esses arquivos não funcionarão a menos que o pacote NetworkManager-initscripts-ifcfg-rh
seja explicitamente instalado. Este é um sinal de alerta de que todo o suporte para esses scripts ifcfg
obsoletos será completamente ignorado no futuro.
Felizmente, a migração de qualquer script ifcfg
existente é trivialmente fácil, e criar novos não é muito mais difícil usando uma das três ferramentas disponíveis. Eu prefiro a ferramenta de edição de conexão GUI NetworkManager porque é clara e fácil. Posso usar a ferramenta nmtui
, que faz a mesma coisa que a versão GUI, mas tem uma interface de usuário um pouco mais desajeitada. Tento não usar a ferramenta nmcli
se puder evitar. Funciona, mas é complicado e requer muita leitura e experimentação para obter a sintaxe de comando correta e todos os argumentos corretos para criar um arquivo-chave totalmente utilizável.
Então vá em frente e migre agora. Eu fiz e foi fácil.