Renomeando interfaces de rede no Arch Linux

Recentemente, fiz a migração de um de meus laptops de Debian a Arch Linux e ao configurar coisas relacionadas às interfaces de rede, descobri que o novo padrão de inicialização para sistema Eu fiz uma mudança nos nomes dos dispositivos que costumava ver nessas interfaces.

Começando com o processo normal, coloquei um terminal (que, a propósito, usa rxvt unicode com zsh como o console padrão) «ip addr»Obtenção do seguinte:

Nomes das interfaces iniciando o processo de renomeação

Neste caso vamos configurar o nome da interface de rede correspondente ao cabo comum com um conector RJ45 que temos em casa para acessar a Internet. A primeira coisa que vemos é que leva pelo nome enp0s4. Isso difere muito de eth0 quanto temos visto. O que faremos é mudar o nome da referida interface para uma que seja mais confortável, por assim dizer, e que seja mais fácil para nós digitarmos no console.

Como uma etapa anterior, digitaremos cat /sys/class/net/enp0s4/addres no terminal para descobrir o MAC do dispositivo. Isso retornará um número do tipo 000: 00: 00: 00: 00: 0 ou simplesmente copiará o nome do endereço MAC que vem com o comando ip addr na etapa anterior. Devemos anotá-lo porque precisaremos dele mais tarde.

Depois disso, criamos uma entrada no diretório /etc/udev/rules.d/ desta maneira:

Nome do diretório

Um arquivo de texto simples chamado 10 regras de rede que servirá como um processador antes do padrão udev. Vale ressaltar que colocamos sudo porque precisamos acessar um arquivo que requer essa permissão para agir.

Depois de aberto, digitamos:

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:90:f5:6e:83:57" NAME="internet"

ficar assim no meu caso:

pressione a combinação de teclas CNTR + o para salvar as alterações e CNTR + x para sair do editor (neste caso eu uso o nano, mas você pode usar o que quiser). Em seguida, reiniciamos o computador para que as alterações tenham efeito, obtendo após a reinicialização o seguinte:

como estão as interfaces após a modificação

Como você verá, se prestarmos atenção ao nome das interfaces, aquela que renomeamos aparece com um nome gerenciável que podemos digitar facilmente.

Espero que seja útil e convido você a comentar e fazer perguntas em caso de qualquer dúvida.

De agora em diante estarei postando coisas assim ... saudações.


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

  1.   itachi dito

    woooo obrigado pela informação, é ótimo para mim, porque os nomes que aparecem com systemd são um pouco chatos.

    1.    oyashiro-sama dito

      Bem sim .. Embora não seja um problema real se for de forma .. Melhor fazer o gerenciamento dessas interfaces com nomes mais representativos

  2.   Pandev92 dito

    LIVE sysvinit XDDD

    1.    oyashiro-sama dito

      Eu imagino, mas vejo que você não é o usuário-alvo deste post haha

  3.   elav. dito

    Ainda não vejo o lado bom do systemd .. Em vez de tornar nossas vidas mais fáceis, parece-me que está complicando tudo .. Alguém pode realmente me dizer uma vantagem "real"?

    1.    Ridri dito

      Outro case como o pulseaudio que por acaso é do mesmo criador. É uma maravilha, mas falha mais do que uma espingarda de feira e você tem que deixar Alsa lidar com o som novamente.
      Para ser justo, ainda é muito verde, mas agora a única vantagem que posso ver é que faz o sistema iniciar 5 segundos mais rápido para dizer algo. Esperançosamente, o debian ainda mantém o sysvinit e o systemd é opcional.

      1.    freebsddick dito

        Em particular, acho que o systemd é uma boa opção, só que levará algum tempo para penetrar nos usuários. Uma das coisas que vejo é que a maioria dos problemas só são resolvidos por serem mal documentados ... Não nego que pode haver problemas subjacentes, mas isso não significa que sejam problemas que fazem uma determinada implementação ser qualificada como boa ou ruim

        1.    Ridri dito

          Parece que os benefícios do systemd são um tanto esotéricos. Eu li as explicações sobre as melhorias que implementei, mas não sei se elas se traduzem em melhor desempenho. E se não tivéssemos dispersão no linux agora, existem três sistemas de inicialização que eu conheço: sysvinit, upstart e systemd. E ainda por cima, o systemd irá forçá-lo a mudar a hierarquia de arquivos unix, que é conhecida como / usr move. Algumas informações interessantes:
          http://hackingthesystem4fun.blogspot.com.es/2012/03/usrmove-la-mentira-usrmove-lie.html

          1.    msx dito

            Artigo muito interessante, então li na íntegra. (E sim, limpar a hierarquia de diretórios não faria mal, pois os arquivos de configuração são armazenados em um diretório chamado "etc" e as configurações do aplicativo são distribuídas em diferentes diretórios distribuídos pelo sistema. É bobagem. Nesse sentido, o pessoal do Fedora tem tenho feito um bom trabalho.)

            Em relação ao que falam do PulseAudio pessoalmente, nunca precisei, sou um daqueles que com ALSA transbordam (sempre reconheço HW perfeitamente).
            No caso particular da distro que uso, nunca tive problemas com a máquina desktop, embora no laptop tenha sido exasperante como o áudio quebrou depois de sair da suspensão.
            Felizmente alguns dias atrás, depois de comentar muito sobre isso no fórum, um dos usuários relatou o problema no bugtracker, eles encontraram o erro e imediatamente liberaram um patch que eram responsáveis ​​por aplicar ao Chakra enquanto aguardavam o próximo estável versão do PA que incluirá esse patch.
            Versão atual do PA no Chakra: 3.0

  4.   msx dito

    Boa dica, +1

    É bom ver que o GNU + Linux finalmente emergiu do ventre do Unix para se tornar um sistema novo, mais poderoso, flexível e moderno, de acordo com os requisitos atuais.
    O systemd com o quão grande é ainda é incrível, uma maravilha de poder, flexibilidade e modularidade, excelente trabalho de Poettering e associados.

  5.   Lawliet dito

    Este tutorial é muito bom, mas acho que se você conseguir realizar todas essas etapas também poderá aprender no p0s4 que é mais fácil, por outro lado é bom saber como as coisas são feitas, às vezes são necessárias e minha interface certamente tem um nome incompreensível.

    1.    freebsddick dito

      Bem, eu realmente não acho que seja uma coisa de ser capaz de lembrar ou não .. o que eu tento fazer com este mini tutorial é resolver um potencial desconforto para o usuário de uma forma muito superficial, além disso eu quero mostre que Gnu linux é extremamente flexível, então você pode personalizá-lo à vontade seguindo passos simples ... o ponto mais superficial é que fica mais fofo ao colocar coisas personalizadas dentro do sistema.

  6.   apenas-outro-dl-usuário dito

    agora na hora de instalar o novo archlinux .iso, o wifi me reconhece como wlp2s0 e às vezes como wlan0, alguém sabe por quê?

    1.    freebsddick dito

      Systemd faz a mudança e o kernel fornece suporte para a interface .. Siga o tutorial que publica e corrige estaticamente .. desta forma você economiza problemas

  7.   Ele passou por aqui dito

    Também me deparei com essa situação há um tempo, mas são duas coisas diferentes
    por convenção, o arquivo deve ser inferior a 80 (normalmente 70 para este caso) e
    Isso depende de como está o resto da configuração ou de quantas placas temos

    cat /etc/udev/rules.d/80-net-name-slot.rules
    # Este arquivo mascara regras de renomeação persistentes para dispositivos de rede. se você
    # excluir este arquivo, /usr/lib/udev/rules.d/80-net-name-slot.rules pode
    # renomear dispositivos de rede de acordo com ID_NET_NAME_ {ONBOARD, SLOT, PATH}
    # propriedades de seus dispositivos de rede, com prioridade nessa ordem. Vejo
    # a saída de 'udevadm test-builtin / sys / class / net / $ interface' para
    # detalhes sobre o que esse novo nome pode ser.
    #
    # http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

    No link, coloque as 3 opções no final (para o freedesktop), com o arquivo ele não os cria automaticamente para mim, e não é um 70- ou seja, não nomeio com um nome particular, é ainda eth0 como deveria ser (sim eu tenho apenas um) e se eu colocar mais parecido com o usb, segue-me chamado eth1 - 2 - 3, ou os nomeia na ordem de detecção do módulo, 70- é útil se tivermos mais de um painel e nos preocupamos com o nome (queremos que um determinado painel seja eth0 e o outro seja eth1 ou você deseja dar-lhe um nome, e ele não corresponde ao nome que sai automagicamente do ordem de montagem do módulo)

    se for 80- ele continua nomeando-os magicamente com nomes normais eth0 eth1 eth2 (de acordo com a ordem de detecção)
    se o 80 não estiver lá - ou eu enviar para null Eu tenho nomes "estranhos" que se eu quiser posso condicioná-los
    Se for 70- ou no caso do tutor, 10- eu condiciono os nomes (tem um bug que circulou em janeiro e se não foi 70 não tirei, não lembro se foi o arch ou o debian, mas em um aconteceu)

    Acho melhor usar netcfg e em alguns computadores bridge-utils
    No debian eu não uso o 80- mas uso aquele que o udev gerou antes de ir para systemd /etc/udev/rules.d/70-persistent-net.rules

    1.    freebsddick dito

      Muito provavelmente o problema vem do debian…. Embora fosse necessário ver se o bug afetou o pacote bruto disponível e não o desenvolvido por cada distro .. com este último, como comento, é apenas uma das muitas maneiras de realizar uma configuração correta

      1.    msx dito

        Veja, como qualquer bom kacker, pedi ao meu / home espaço para instalar o Kali Linux (sucessor do Backtrack 5).
        Kali, ao contrário do BT é baseado no Debian, na verdade _é_ Debian com a adição especial de ... systemd!
        Na verdade, chamou minha atenção - de uma forma positiva - ver que o Kali Linux roda com o systemd como se tivesse usado o Debian toda a sua vida.

        Enquanto isso, o grupo Debian Dev Core:

        "Dev1: -Ei, você ouviu falar desse novo systemd, não seria ótimo implementar?"
        «Dev2: -WTF, mas quem você pensa que é !!! Quando você ainda se cagava eu ​​já usava o SysV, e aviso que pretendo continuar usando até morrer !!! »
        «Dev3: -Ei caramba, cuidado com o que diz ...»
        «Dev4: -Parece-me que o tio é um infiltrado ...»
        «Dev5: -Olha, pescada, no Debian nós nos gabamos de coletar teias de aranha, não nos venha com merdas novas como essa. Talvez daqui a 15 ou 20 anos, quando estiver suficientemente testado, vamos dar uma segunda olhada e se virmos que atende aos requisitos vamos incorporá-lo ao Sid »
        «Dev1: -Mas galera, tudo bem, não fiquem assim, só me parece que é um * ótimo * PID1, muito mais flexível, completo e poderoso que o SysV que de fato tem mostrado sinais de enfermidades há muito tempo, eu só queria ... »
        «Dev2: -BLASFEMIA !!!»
        "Dev4: -Você, confesse, rápido, você vem de Arch, não, droga !?"
        «Dev5: -QUEEEEE ??? Mas o que acham, como vamos incorporar algo que não foi suficientemente testado !! ?? »
        «Dev1 respondendo a Dev5: -Mas ei, é que hoje em dia com a ampla gama de F / LOSS não é mais necessário esperar anos, já que o software é testado massivamente e por diferentes distribuições a compatibilidade e estabilidade é praticamente garantida, apenas meus 50 centavos… »
        «Dev3: -Bem, foda-se seus 50 centavos então, que parte você não entendeu que isso é Debian? Nós apenas adicionamos software desatualizado à nossa distribuição, droga. "
        «Dev5: -Claro, bem disse Dev3, ouça-me você Dev1, só quando este software começar a ser substituído pela próxima geração de PID1 consideraremos incorporá-lo ao Debian. Ponto final, chega de falar sobre o assunto. "
        «Dev1: -É isso ...»
        «Dev2: -E vamos lá, você está procurando por isso cara, é melhor você investir seu tempo em patchear e dar suporte ao SysV e estender sua vida útil por mais dez anos, se ele tem nos servido tão bem por 20 anos pelo que estamos vamos substituí-lo agora. »
        «Dev3: -Que cara, se olharmos para SysV com carinho ainda tem PID1 por um tempo.»
        «Dev1: -Bem, ok, acho que eles estão certos, é melhor eu começar a corrigir um software que não foi projetado para os requisitos modernos para que com muito esforço possamos continuar usando ...»
        «Dev4: -Claro, claro, esse é o caminho e não os vossos modernismos.
        "Dev1: -Ok, ok, eles me convenceram, o systemd é idiota e o cara que fez isso é um idiota, quem pensa em fazer essa porcaria quando tem SysV?"
        Dev {2,3,4,5}: - «Vamos brindar rapazes pelos próximos 50 anos de estagnação!»

        1.    Pandev92 dito

          A vantagem do systemd em relação ao sysvinit / openrc ou upstart, não é que ele seja tão grande, ele está simplesmente na moda porque inicia em 3 ou 4 segundos mais rápido.

          1.    Ele passou por aqui dito

            Não sei sobre upstart, acho que nunca usei, pelo menos conscientemente.
            Os 3 ou 4 segundos são relativos, eu tenho um computador, que em um boot completo demorava uns 10 minutos (um debian sem X e com tudo que era possível otimizado) com o systemd, ia para a metade ou menos (mesmos serviços, mesmos discos, mesmo cpu, mesmo ram), ou seja, até assumir o comando,

          2.    Pandev92 dito

            Se você já usou o ubuntu, você deve saber que é um upstart, caso contrário, claramente não.

          3.    msx dito

            "Está na moda porque começa em 3 ou 4 segundos mais rápido."
            Na verdade não é assim, na verdade o principal desenvolvedor do systemd explica expressamente em um e-mail de seu ML que eles nunca pensaram no systemd como um sistema de início rápido, que isso é apenas uma consequência do funcionamento do systemd - o que é realmente interessante pensando no que poderia ser alcançado se eles decidirem otimizar o systemd para ser mais rápido ...

            "A vantagem do systemd contra sysvinit / openrc ou upstart, não é que seja tão bom"
            Com relação ao SysV init a vantagem é ENORME comparada ao Upstart nem tanto.
            SysVinit é uma catramina, um carrinho próximo ao Porsche.
            Embora o SysVinit tenha servido ao seu propósito por muitos anos, a realidade é que as limitações implícitas de um software feito, pensado e projetado muitos anos atrás e para aquele momento são cada vez mais perceptíveis.
            Alguns dos problemas com o SysV, além de seu tempo de inicialização lento, são as condições de corrida que geralmente ocorrem em ambientes diferentes, sua estrutura para ativar e desativar daemons e quão complexo é adicionar novos aplicativos e daemons a esta estrutura sem quebrar a sequência .De começar.

            O systemd resolve tudo isso de forma limpa, prática, padronizada e bem documentada - quando em SysV é geralmente que cada distribuição o implementa como preferir.

            Sobre o Upstart não sei muito além dos seus arquivos de configuração, que a rigor SÃO HORRÍVEIS, é chinês, é uma tortura editá-los e é muito fácil errar se você não é louco e bagunça.
            Por outro lado, o Upstart parece ser realmente eficiente, já que as últimas versões do Ubuntu em minha máquina foram iniciadas e desligadas quase instantaneamente - maravilhoso.
            No entanto, quando Poettering foi questionado se sysmted era realmente necessário e se eles não analisaram outras opções como o Upstart, ele respondeu que sim, eles as haviam analisado, que havia muitas coisas de que gostavam e que de fato estava nos planos implementar no systemd mas que segundo eles a base estrutural do Upstart não era boa e que era muito possível que no futuro tivessem problemas derivados dela.

            Lembre-se de que o systemd nasceu como uma iniciativa da Red Hat por dois motivos importantes:
            1. Devido à experiência _vastisima_ que a empresa tem em seus milhares de implantações, eles chegaram à conclusão de que precisam fazer certas mudanças fundamentais em seu sistema para atender aos seus requisitos, mudanças que logicamente enervam mais de um veterano - como todas as profundas mudanças.
            2. Não é segredo para ninguém que a Red Hat pretende ser Red Hat e não GNU + Linux.

            Além de arabescos e outras distrações, o fato é que o systemd está sendo cada vez mais adotado pela comunidade GNU + Linux e isso é necessariamente bom por vários motivos:
            1. o desenvolvimento é acelerado para que um produto melhor possa ser alcançado em menos tempo
            2. Incluindo as necessidades de várias distribuições e colaborando com os principais desenvolvedores dessas distribuições com o systemd e interagindo com desenvolvedores de outras distribuições discutindo patches e recursos, é infinitamente mais fácil obter um produto de qualidade
            3. É agnóstico quanto à distribuição na qual está implementado (muito importante!) E consolidado como um padrão (como é POSIX) algo que um administrador que tem que trabalhar em ambientes heterogêneos compostos por distribuições diferentes, mas que compartilham uma base de gestão certamente valorizará sistema semelhante.
            $ systemctl funcionará no Fedora da mesma forma que o openSUSE ou Arch ou Chakra ou Red Hat ou Kali Linux ou qualquer outra distribuição que use o systemd e isso é ótimo.
            4. Ter um grande número de pessoas adequadas trabalhando no mesmo PID1 usado pela própria distro torna o trabalho muito mais fácil para os próprios desenvolvedores ao resolverem problemas ou buscarem ajuda ou idéias sobre como implementar uma ou outra função.
            5. Como o systemd é um projeto interdisciplinar aberto e -muito importante-, ele torna a taxa de adoção e melhoria do projeto um dos mais altos dos projetos FLOSS.
            Por exemplo, quando um mantenedor de um pacote de qualquer distribuição, que envolve iniciar daemons no início, apresenta sua versão do serviço na lista de discussão do systemd pedindo comentários e sugestões, está acontecendo que após uma colaboração geral é possível ter aquele serviço para apontar, da melhor maneira possível, aquele que não só usa o desenvolvedor que abriu o tópico, mas também envia UPSTREAM para os desenvolvedores da própria aplicação para que eles decidam se querem tornar esse serviço parte de seus próprio pacote e com isso torná-lo OOTB 100% compatível com o systemd.
            6. O systemd possui centenas de centenas de novos recursos que tornam a administração dos sistemas que gerencia muito mais fácil e suave. Por exemplo, é responsável por gerenciar o módulo PAM para gerenciadores de login, gerenciar conexões remotas ao sistema, carregar serviços sob demanda ouvindo em sockets ao invés de ter um daemon dormindo na memória e roubando CPU e memória esperando para serem ativados, gerenciar de forma confiável interfaces de rede e dispositivos plugados no sistema ... é realmente um monstro, um enorme Leviatã mas ao contrário de outros sistemas deste tamanho ele funciona de forma ágil, rápido e muito suave e acho que a única razão para isso ser assim, para um sistema ENORME como o systemd (acho que em pouco tempo ele gerenciará todo o sistema) é que ele foi projetado para ser eficiente, modular e escalável desde o início.

            Particularmente, o que mais sofro com o uso do systemd é que tenho que reaprender tudo o que até agora tenho usado para gerenciar minha máquina.
            É compreensível que alguns pré-históricos acostumados a usar uma determinada metodologia por muitos anos resistam a tal mudança ... mas hey! Isso é ciência da computação, aqui a única coisa que não muda é que a mudança é contínua 😉

            Saudações.

          4.    msx dito

            Eu esqueci:
            "Se você já usou o ubuntu, então você deve saber que ele é novo, mas claramente não .."

            Que resposta desagradável, certo? Próprio de alguém que acredita e sabe muito pouco.

            Seguindo seu raciocínio, tenho certeza de que você sabe como todos os alimentos que ingere são produzidos, certo? Eu digo tudo.
            Da mesma forma que quando você entra no ônibus ou no avião, você tem conhecimento absoluto de todas as partes do veículo, mesmo as menores, de como ele funciona, quais óleos, lubrificantes e outros fluidos eles usam e como cada um e seu processo de fabricação são compostos .
            Ou quando você usa uma caneta, certamente tem muito claro como a tinta é feita.

            Não sei se @ estava passando por aqui ainda não leio sua estupidez ou é simplesmente educado e civilizado demais para responder como deveria.

            De minha parte, já estou velho e mal-humorado o suficiente para aguentar giles como você:
            CHUPE-ME UM OVO.
            (E não, eu não defendo ninguém, simplesmente adoeci demais com tanta mediocridade e arrogância venenosa em uma única frase).

          5.    Pandev92 dito

            msx, o Windows usa o mesmo sistema de boot da época de Moses xD, o mesmo sistema de arquivos, o mesmo sistema de som e nada acontece! Então este é o Linux, onde reinventamos a roda ou experimentamos a cada 5 ou 6 anos, mas não é computação, é apenas uma parte. XD

          6.    msx dito

            Ahh olha ...
            Claro que não.
            O sistema de boot mudou de 98 / Me para XP (NTLD) e depois mudou novamente com o Windows 7 e agora foi atualizado com o Windows 8 - o que é lógico porque as tecnologias não são as mesmas e os requisitos não são os mesmos.

          7.    Pandev92 dito

            o Windows 7 tem o Windows Vista.

          8.    Pandev92 dito

            msx, mas o que diabos você fuma, mas o que diabos você acreditou? Sim respondi totalmente normal, mas você tem merda na cabeça interpretando as coisas como uma pessoa com complexo de inferioridade, não é minha culpa. Foi simplesmente uma afirmação que eu fiz para o parceiro, sem querer trair nem nada, você criou tudo na sua cabeça, caramba, vai ter uma tília, por essa amargura que você tem por dentro

            1.    elav. dito

              Eu já te pedi outro dia para parar com isso. Não sou pai de nenhum deles para repreendê-los .. Eles vão brigar pelo Twitter, G + ou Skype .. Está bom agora.


        2.    Ele passou por aqui dito

          Muito bom,
          o que talvez o debian tenha (por agora), é que ele não é tão rígido com os scripts e acomoda magicamente, embora o "Sim, faça o que eu digo!" não tem preço

        3.    Lawliet dito

          Esses Arch são blasfemadores? Bem, Arch é o oposto do Debian Stable, com certeza

          1.    msx dito

            Não, não, é como aqueles homens das cavernas digitais nos veem, totalmente assustados com o ritmo que os arqueiros carregam ;-D

  8.   eliotime3000 dito

    O principal problema não são os comandos, mas o hábito que pega uma distro com a qual se acostuma.

    O Arch é uma boa opção, mas por enquanto vou tentar o Slackware.

  9.   st0rmt4il dito

    Obrigado pela dica!

    1.    freebsddick dito

      quão bom isso foi útil

  10.   Elery dito

    Boa dica =) só que na redação do texto vem o seguinte

    "Um arquivo de texto simples chamado 10-network-rules." e na imagem essa é a maneira correta, vem como 10-network.rules

    lembranças

  11.   abraham tamayo dito

    Isso me serviu .. por causa de uma configuração conky que eu tenho, mas também sou contra esse tipo de artigo onde eles fazem o linux parecer muito difícil para olhos inexperientes ..
    Que diferença faz se a tua interface se chama como se chama se o importante é que tens internet .. mesmo e na minha configuração conky o outro nome do wifi servir-me-ia e se for para usar aircrack é também a mesma história, mas como o Linux oferece a opção de personalização, altere-a .. obrigado pelo artigo .. uma imagem
    https://pbs.twimg.com/media/BI9FCzQCEAIM0ud.png:large