Pesquisa de site

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.

Artigos relacionados: