systemd: quem configurou a interface sem ifupdown?

Question

Qual componente / pacote é responsável por trazer lo interface de rede com systemd como PID1 sem ifupdown package?

No Debian, temos bastante componente para gerenciar a rede, ifupdown , network-manager , systemd-networkd . Agora, podemos e removemos o pacote ifupdown , o que significa que /etc/network/interface não é referenciado por ifup durante o processo de inicialização.

Também removi toda a entrada ifconfig do arquivo de configuração do NetworkManager, /etc/NetworkManager/NetworkManager.conf e nmcli dev mostram que lo não é gerenciado.

$ nmcli dev
  :
lo               loopback  unmanaged    --                 

networkctl também mostra que lo não é gerenciado:

$ networkctl
IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     unmanaged 
  :

Mas ainda assim, lo parece estar ativo ( LOWER_UP pelo menos)

$ ip li
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

E o ssh para o localhost funciona.

Então, minha pergunta é: quem está trazendo a interface lo ?

Note que minha intenção não é desativar a interface lo , mas sim saber quem é o responsável e quando e como isso acontece.

    

Answer 1

A interface de loopback é configurada na inicialização antecipada (antes, por exemplo, de quaisquer servidores de rede executados). Parece que não houve variação significativa entre distribuições. O ifupdown atual do Debian traria o lo mesmo sem configuração em / etc / network / interfaces. Tecnicamente, foi possível alterar a configuração de lo - e ainda seria possível reconfigurar, e. usando ifupdown (talvez até systemd-networkd?).

A parte inicial do systemd é provavelmente mais difícil de entender. É o código de um único programa (escrito em C :), as chamadas de configuração são misturadas com mais inicialização específica do programa e não parecem ser especificamente documentadas. No entanto, a página de manual do binário systemd menciona a interface de loopback como um exemplo das tarefas de configuração incorporadas:

Systemd contains native implementations of various tasks that need to be executed as part of the boot process. For example, it sets the hostname or configures the loopback network device. It also sets up and mounts various API file systems, such as /sys or /proc.

For more information about the concepts and ideas behind systemd, please refer to the Original Design Document[2].

O Google sabe

link

em que o código é - resultado 1: link

Ele também mostra as postagens do blog do desenvolvedor mencionando isso. Esta postagem de blog não responde à sua pergunta mais especificamente do que para confirmar que o systemd é responsável. Por exemplo, ele também menciona tmpfiles, sem mencionar que systemd-tmpfiles é uma unidade binária e de serviço distinta do PID 1. Para ser claro, a interface de loopback é configurada pelo PID 1, que pode ser vista no código.

Resultado 3:

systemd para administradores, parte VIII
0pointer.de/blog/projects/the-new- arquivos de configuração - Em cache - Dados similares 20 de abril de 2011 ... Outro episódio da minha série em curso no systemd para administradores: ... Definir o nome do host; Configurando o dispositivo de rede loopback

Our little Project Zero Shell[1] has been a full success. We currently cover pretty much everything most desktop and embedded distributions should need, plus a big part of the server needs:

• Checking and mounting of all file systems

• Updating and enabling quota on all file systems
• Setting the host name
• Configuring the loopback network device
• Loading the SELinux policy and relabelling /run and /dev as necessary on boot
• Registering additional binary formats in the kernel, such as Java, Mono and WINE binaries
• Setting the system locale
• Setting up the console font and keyboard map
• Creating, removing and cleaning up of temporary and volatile files and directories
• Applying mount options from /etc/fstab to pre-mounted API VFS
• Applying sysctl kernel settings
• Collecting and replaying readahead information
• Updating utmp boot and shutdown records
• Loading and saving the random seed
• Statically loading specific kernel modules
• Setting up encrypted hard disks and partitions
• Spawning automatic gettys on serial kernel consoles
• Maintenance of Plymouth
• Machine ID maintenance
• Setting of the UTC distance for the system clock