Início / unix / Perguntas / 789168
Accepted
Judah
Asked: 2025-01-07 04:09:11 +0800 CST

Por que o Netplan gateway4 foi descontinuado?

  • 772

Então, eu tenho aprendido como configurar meu servidor privado. Estou usando o netplan. De acordo com alguns documentos que encontrei em https://netplan.readthedocs.io/en/stable/examples/# e uma longa discussão com o Chatgpt sobre a maneira correta de configurar meu arquivo yaml, foi isso que eu descobri.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp2s0: 
      addresses:
        - 192.168.0.2/24
      gateway4: 192.168.0.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1

Recebo o erro "gateway4 is deprecated" e encontrei muito conhecimento sobre como configurar routescom viaand to, mas não encontrei na internet o motivo pelo qual gateway4 está obsoleto. É meramente sintático ou é por algum outro motivo?

Por favor, esteja ciente de que NÃO ESTOU FAZENDO UMA PERGUNTA DUPLICADA . Estou perguntando a diferença específica entre a maneira obsoleta e a maneira mais nova e por quê .

netplan

1 respostas

  1. Best Answer

    A diferença específica é a forma antiga:

    ...
  enp2s0:
    ...
    gateway4: 192.168.0.1

    é substituído por:

    ...
  enp2s0:
    ...
    routes:
      - to: default
        via: 192.168.0.1

    Nos comentários, user202311 já encontrou o commit que faz a mudança . A descrição do commit inclui esta justificativa:

    A justificativa é que ele agrupa todos os assuntos de roteamento no mesmo lugar, tornando as coisas mais consistentes. Junto com essa depreciação vem o suporte para a palavra-chave "default" no campo route to, e uma expansão da etapa de validação do gateway para abranger todas as rotas default.

    Essa é toda a justificativa que provavelmente obteremos sem perguntar diretamente ao desenvolvedor. Mas aqui estão alguns pensamentos meus.

    O gateway4alone é inadequado para quaisquer casos em que você precise especificar mais do que apenas uma rota de gateway padrão. O Netplan é projetado para uso empresarial e em nuvem, então espera-se que ele lide com especificações de rota complicadas. Então, precisa haver um mecanismo que permita usar o máximo possível do conjunto completo de recursos de roteamento do SO subjacente.

    Pense nisso do ponto de vista do desenvolvedor do netplan. Se você tem duas maneiras distintas de especificar a rota padrão (a maneira simples antiga e a nova com todos os recursos), e o usuário especificou ambas, o código precisaria decidir o que fazer:

    • a maneira simples: tente definir ambas como rotas padrão separadas. Provavelmente não é isso que o usuário pretendia, e provavelmente produzirá um erro do mecanismo de configuração subjacente.
    • a maneira complexa: determine se as duas especificações de rota diferentes em vigor significam a mesma coisa, relate um erro se não, e ignore uma das duas (provavelmente a maneira mais antiga) se ambas estiverem de acordo. Isso requer manter alguma quantidade de código e casos de teste para o futuro indefinido, e testar para tratamento correto em cada versão futura. Além disso, a documentação precisa informar aos usuários o que acontece se isso for feito e qual é a maneira recomendada... e a tendência predominante para os usuários é não ler a documentação de qualquer maneira, mas confiar em fontes secundárias como ChatGPT para informações possivelmente obsoletas ou totalmente incorretas.
    • a maneira mais simples: simplesmente rejeitar a maneira antiga completamente. Fácil e eficiente para o desenvolvedor; para os usuários, requer algum esforço agora em troca de melhor validação das configurações de rota agora e no futuro .
    • 3

relate perguntas