systemd-networkd (Français)

systemd-networkd est un daemon système qui gère les configurations réseau. Il détecte et configure les périphériques réseau à mesure qu'ils apparaissent ; il peut également créer des périphériques réseau virtuels. Ce service peut être particulièrement utile pour mettre en place des configurations réseau complexes pour un conteneur géré par systemd-nspawn ou pour des machines virtuelles. Il fonctionne également très bien sur des connexions simples.

État de la traduction: Cet article est la version francophone de Systemd-networkd. Date de la dernière traduction: 2022-10-03. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Utilisation de base

Le paquet fait partie de l'installation par défaut d'Arch et contient tous les fichiers nécessaires au fonctionnement d'un réseau filaire. Les adaptateurs sans fil, traités plus loin dans cet article, peuvent être configurés par des services, tels que wpa_supplicant ou iwd.

Services requis et configuration

Pour utiliser systemd-networkd, démarrez et activez .

Note: Vous devez vous assurer qu'aucun autre service souhaitant configurer le réseau n'est en cours d'exécution ; en effet, plusieurs services réseau entreront en conflit. Trouvez la liste des services en cours d'exécution avec systemctl --type=service et ensuite stoppez-les.

La configuration de systemd-resolved, qui est un service de résolution de noms de réseau pour les applications locales, est facultative, compte tenu des points suivants :

Il est important de comprendre comment resolv.conf et systemd-resolved interagissent pour configurer correctement le DNS qui sera utilisé, quelques explications sont fournies dans systemd-resolved.
systemd-resolved est nécessaire si les entrées DNS sont spécifiées dans les fichiers .network.
systemd-resolved est également nécessaire si vous souhaitez obtenir des adresses DNS à partir de serveurs DHCP ou d'annonces de routeurs IPv6.
(en définissant ( et/ou IPv6AcceptRA= dans la section , et (the default) in the corresponding section(s) , , , see ).
Notez que systemd-resolved peut également être utilisé sans systemd-networkd.

systemd-networkd-wait-online

Activer permet également d'activer , qui est un service système à action unique qui attend que le réseau soit configuré. Ce dernier a WantedBy=network-online.target, il ne sera donc démarré que lorsque lui-même est activé ou tiré par une autre unité. Consultez également Systemd (Français)#Exécution des services après le démarrage du réseau.

Par défaut, attend que tous les liens dont il a connaissance et qui sont gérés par systemd-networkd soient entièrement configurés ou défaillants, et qu'au moins un lien soit en ligne.

Si votre système possède plusieurs interfaces réseau, mais que certaines ne sont pas censées être connectées en permanence (par exemple, si vous avez une carte Ethernet à double port, mais qu'un seul câble est branché), le démarrage de échouera après le délai par défaut de 2 minutes. Cela peut entraîner un retard indésirable dans le processus de démarrage. Pour modifier le comportement et attendre que "n'importe quelle" interface soit en ligne plutôt que "toutes" les interfaces, éditez le service et ajoutez le paramètre à la ligne :

/etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any

D'autres comportements, tels que les interfaces spécifiques à attendre ou l'état opérationnel, peuvent également être configurés. Consultez pour connaître les paramètres disponibles.

Exemples de configuration

Toutes les configurations de cette section sont stockées sous le nom dans . Pour une liste complète des options et l'ordre de traitement, consultez #Fichiers de configuration et .

systemd/udev attribue automatiquement des noms d'interface réseau prévisibles et stables pour toutes les interfaces locales Ethernet, WLAN et WWAN. Utilisez pour répertorier les périphériques du système.

Après avoir apporté des modifications à un fichier de configuration, redémarrez .

Adaptateur filaire utilisant une IP statique

Address= peut être utilisé plusieurs fois pour configurer plusieurs adresses IPv4 ou IPv6. Consultez #Fichiers network ou pour plus d'options.

Adaptateur sans fil

Afin de se connecter à un réseau sans fil avec systemd-networkd, un adaptateur sans fil configuré avec une autre application telle que wpa_supplicant ou iwd est nécessaire.

Si l'adaptateur sans fil a une adresse IP statique, la configuration est la même (sauf pour le nom de l'interface) que pour un adaptateur filaire.

Pour s'authentifier sur le réseau sans fil, utilisez par exemple wpa_supplicant ou iwd.

Adaptateurs avec et sans fil sur la même machine

Cette configuration activera une IP DHCP pour une connexion filaire et sans fil en utilisant la directive metric pour permettre au noyau de décider à la volée laquelle utiliser. De cette façon, aucune interruption de connexion n'est observée lorsque la connexion filaire est débranchée.

La métrique de route du noyau (la même que celle configurée avec ip) décide de la route à utiliser pour les paquets sortants, dans les cas où plusieurs correspondent. C'est le cas lorsque les périphériques filaires et sans fil du système ont tous deux des connexions actives. Pour les départager, le noyau utilise la métrique. Si l'une des connexions est interrompue, l'autre l'emporte automatiquement sans qu'il n'y ait de vide où rien ne soit configuré (les transferts en cours peuvent encore ne pas gérer cela de manière agréable, mais cela se situe à une couche OSI différente).

/etc/systemd/network/25-wireless.network

[Match]
Name=wlp2s0

[Network]
DHCP=yes

[DHCPv4]
RouteMetric=20

Si vous utilisez IPv6, vous devrez définir séparément la métrique pour les routes IPv6 également, comme par exemple :

Renommer une interface

Au lieu de modifier les règles d'udev, un fichier .link peut être utilisé pour renommer une interface. Un exemple utile est de définir un nom d'interface prévisible pour un adaptateur USB vers Ethernet en se basant sur son adresse MAC, car ces adaptateurs reçoivent généralement des noms différents en fonction du port USB sur lequel ils sont branchés.

Fichiers de configuration

Les fichiers de configuration sont situés dans /usr/lib/systemd/network/, le répertoire réseau d'exécution volatile et le répertoire réseau d'administration locale . Les fichiers se trouvant dans ont la plus haute priorité.

Il existe trois types de fichiers de configuration. Ils utilisent tous un format similaire à celui de fichiers d'unités de systemd.

Les fichiers .network. Ils vont appliquer une configuration réseau pour un périphérique correspondant.
Les fichiers .netdev. Ils vont créer un périphérique réseau virtuel pour un environnement correspondant.
Les fichiers .link. Lorsqu'un périphérique réseau apparaît, udev cherchera le premier fichier .link correspondant.

Ils suivent tous les mêmes règles :

Si toutes les conditions de la section sont remplies, le profil sera activé.
Une section vide signifie que le profil s'appliquera dans tous les cas (peut être comparé au caractère générique ).
tous les fichiers de configuration sont triés collectivement et traités dans l'ordre lexical, quel que soit le répertoire dans lequel ils se trouvent
les fichiers ayant un nom identique se remplacent les uns les autres

Fichiers network

Ces fichiers sont destinés à définir les variables de configuration du réseau, notamment pour les serveurs et les conteneurs.

Les fichiers .network ont les sections suivantes : , , , [Address], , et . Vous trouverez ci-dessous les clés communément configurées pour chaque section. Consultez pour plus d'informations et d'exemples.

[Match]

Paramètre	Description	Valeurs acceptées
	Correspond aux noms de périphériques, par exemple . En préfixant avec , la liste peut être inversée.	noms de périphériques séparés par des espaces blancs, avec des globales, la négation logique ()
`MACAddress=`	Correspondance des adresses MAC, par exemple	Les adresses MAC sont séparées par des espaces dans un format hexadécimal délimité par deux points, un trait d'union ou un point.
	Correspond au nom d'hôte ou à l'ID de la machine de l'hôte.	La chaîne de noms d'hôtes avec des expressions globales,
	Vérifie si le système est exécuté dans un environnement virtualisé. correspondra uniquement à votre machine hôte, tandis que `Virtualization=true` correspondra à tout conteneur ou VM. Il est possible de vérifier un type ou une implémentation de virtualisation spécifique, ou un espace de noms d'utilisateur (avec ).	Les paramètres suivants peuvent être utilisés : booléen, négation logique (), type (, `container`), implémentation (consultez ), .

[Link]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
`MACAddress=`	Attribue une adresse matérielle au périphérique. Utile pour MAC address spoofing.	Les adresses MAC hexadécimales délimitées par deux points, un trait d'union ou un point.
	Unité de transmission maximale en octets à définir pour le périphérique. Notez que si IPv6 est activé sur l'interface, et que le MTU est choisi en dessous de 1280 (le MTU minimum pour IPv6), il sera automatiquement augmenté à cette valeur. La définition d'une valeur MTU plus grande (par exemple, lors de l'utilisation de jumbo frames) peut accélérer de manière significative vos transferts sur le réseau	integer (les suffixes habituels K, M, G, sont pris en charge et sont compris dans la base de 1024)
	permet l'utilisation de multicast	booléen	? non documenté ?

[Network]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
	Contrôle la prise en charge des clients DHCPv4 et/ou DHCPv6.	boolean, ,
`DHCPServer=`	Si cette option est activée, un serveur DHCPv4 sera lancé.	boolean
	Active la prise en charge du multicast DNS. Lorsqu'il a pour valeur , seule la résolution est activée, mais pas l'enregistrement et l'annonce des hôtes ou des services.	booléen,
	Contrôle la prise en charge de la validation DNSSEC du DNS sur le lien. Lorsqu'il est défini sur , la compatibilité avec les réseaux non compatibles DNSSEC est améliorée, en désactivant automatiquement le DNSSEC dans ce cas.	booléen,
`DNS=`	Configurer des adresses DNS statiques. Peut être spécifié plus d'une fois.
	Une liste de domaines qui doivent être résolus en utilisant les serveurs DNS de ce lien. plus d'informations	Nom de domaine, éventuellement préfixé d'un tilde ()
	Si elle est activée, les paquets entrants sur n'importe quelle interface réseau seront transférés vers n'importe quelle autre interface en fonction de la table de routage. Consultez Internet sharing#Enable packet forwarding pour plus de détails.	boolean, ,
	Si elle est activée, les paquets transférés depuis l'interface réseau apparaîtront comme provenant de l'hôte local. Selon la valeur, implique `IPForward=ipv4`, ou	, , , `no`	`no`
	Configure l'utilisation d'adresses temporaires sans état qui changent avec le temps (consultez RFC 4941). Lorsque , active les extensions de confidentialité, mais préfère les adresses publiques aux adresses temporaires. Lorsque , le paramètre par défaut du noyau est laissé en place.	boolean, ,

[Adress]

Paramètre	Description	Valeurs acceptées	Valeur par défaut
	Spécifiez cette clé plusieurs fois pour configurer plusieurs adresses. Obligatoire sauf si DHCP est utilisé. Si l'adresse spécifiée est (pour IPv4) ou } (pour IPv6), une nouvelle plage d'adresses de la taille demandée est automatiquement allouée à partir d'un pool de plages inutilisées à l'échelle du système.	adresse IPv4 ou IPv6 statique et sa longueur de préfixe (consultez )

[Route]

Gateway= cette option est obligatoire sauf si DHCP est utilisé.
le préfixe de destination de la route, éventuellement suivi d'une barre oblique et de la longueur du préfixe.

Si n'est pas présent dans la section , cette section est traitée comme une route par défaut.

[DHCPv4]

Paramètre	Description	Valeurs acceptées
`UseDNS=`	contrôle si les serveurs DNS annoncés par le serveur DHCP sont utilisés	booléen
	Lorsque cette option est vraie, les options envoyées au serveur DHCP suivent la RFC:7844. (Profils d'anonymat pour les clients DHCP) pour minimiser la divulgation d'informations d'identification	booléen
	contrôle si le nom de domaine reçu du serveur DHCP sera utilisé comme domaine de recherche DNS. S'il a pour valeur , le nom de domaine reçu du serveur DHCP sera utilisé pour le routage des requêtes DNS uniquement, mais pas pour la recherche. Cette option peut parfois corriger la résolution de noms locaux lors de l'utilisation de systemd-resolved.	booléen,

[DHCPServer]

Voici un exemple de configuration de serveur DHCP qui fonctionne bien avec hostapd pour créer un hotspot sans fil. ajoute les règles de pare-feu pour NAT et implique IPForward=ipv4 pour activer packet forwarding.

Fichiers netdev

Ces fichiers permettent de créer des périphériques réseau virtuels. Ils comportent deux sections : et . Vous trouverez ci-dessous les clés communément configurées pour chaque section. Consultez pour plus d'informations et d'exemples.

Section [Match]

le nom d'hôte
vérifie si le système fonctionne dans un environnement virtualisé.

Section [NetDev]

Les clés les plus courantes sont :

le nom de l'interface. obligatoire
par exemple bridge, bond, vlan, veth, sit, etc. obligatoire

Fichiers link

Ces fichiers sont une alternative aux règles udev personnalisées et seront appliqués par udev lorsque le périphérique apparaîtra. Ils ont deux sections : et . Vous trouverez ci-dessous les clés communément configurées pour chaque section. Consultez systemd.link(5) pour plus d'informations et d'exemples.

Section [Match]

MACAddress= l'adresse MAC
le nom de l'hôte
le nom de l'hôte
le type de périphérique, par exemple vlan

Section [Link]

adresses persistantes ou aléatoires, ou
MACAddress= une adresse spécifique
liste des politiques par lesquelles le nom de l'interface doit être défini, par exemple, noyau, garder

Note: le /usr/lib/systemd/network/99-default.link du système est généralement suffisant pour la plupart des cas de base.

Utilisation avec les conteneurs

systemd-networkd peut fournir une configuration entièrement automatique du réseau pour les conteneurs systemd-nspawn lorsqu'il est utilisé sur le système hôte ainsi qu'à l'intérieur du conteneur. Consultez systemd-nspawn#Networking pour une présentation complète.

Pour les exemples ci-dessous ,

nous limiterons la sortie de la commande aux interfaces concernées.
Nous supposons que l'hôte est le système d'exploitation principal sur lequel vous démarrez et que le conteneur est votre machine virtuelle invitée.
tous les noms d'interfaces et les adresses IP ne sont que des exemples.

Interface pont

Tout d'abord, créez une interface virtuelle bridge avec un fichier d'unité netdev. Nous demandons à systemd de créer un périphérique nommé br0 qui fonctionne comme un pont Ethernet.

Redémarrez pour que systemd crée le pont.

Pour consulter le pont nouvellement créé sur l'hôte et sur le conteneur, tapez :

$ ip a

3 : br0 : <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default 
    link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff:ff

Notez que l'interface br0 est listée mais est toujours DOWN à ce stade.

Lier Ethernet au pont

L'étape suivante consiste à ajouter une interface réseau au pont nouvellement créé. Son fichier de configuration doit être chargé avant ceux des interfaces liées, donc son fichier de configuration doit être alphanumériquement antérieur à ceux-ci. Dans l'exemple ci-dessous, nous ajoutons toute interface qui correspond au nom en* au pont br0.

L'interface Ethernet ne doit pas avoir de DHCP ou d'adresse IP associée car le pont a besoin d'une interface à laquelle se lier sans IP : modifiez le correspondant en conséquence pour supprimer l'adressage.

Réseau du pont

Maintenant que le pont a été créé et qu'il a été lié à une interface réseau existante, la configuration IP de l'interface du pont doit être spécifiée. Ceci est défini dans un troisième fichier .network, l'exemple ci-dessous utilise DHCP.

Configurer le conteneur

Utilisez l'option lors du démarrage du conteneur. Consultez Systemd-nspawn#Use a network bridge pour plus de détails.

Résultat

sur l'hôte

$ ip a

3 : br0 : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff:ff
    inet 192.168.1.87/24 brd 192.168.1.255 scope global br0
       valid_lft forever preferred_lft forever
    inet6 fe80::16da:e9ff:feb5:7a88/64 scope link 
       valid_lft forever preferred_lft forever
6 : vb-''MyContainer'' : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff:ff
    inet6 fe80::d07c:97ff:fe97:3725/64 scope link 
       valid_lft forever preferred_lft forever

sur le conteneur

Avertissement

Nous avons maintenant une adresse IP pour sur l'hôte et une pour dans le conteneur.
deux nouvelles interfaces sont apparues : dans l'hôte et dans le conteneur. Ceci est le résultat de l'option comme expliqué dans Systemd-nspawn#Use a network bridge pour plus de détails.
l'adresse DHCP sur provient du fichier du système.
sur l'hôte

la sortie de la commande ci-dessus confirme que nous avons un pont avec deux interfaces liées à.

sur l'hôte

$ ip route

default via 192.168.1.254 dev br0 
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87

sur le conteneur

Les résultats de la commande ci-dessus confirment que nous avons activé les interfaces {ic|br0}} et {ic|host0}} avec une adresse IP et une passerelle 192.168.1.254. L'adresse de la passerelle a été automatiquement récupérée par systemd-networkd.

Pont réseau avec adresses IP statiques

Définir une adresse IP statique pour chaque appareil peut être utile dans le cas de services web déployés (par exemple FTP, http, SSH). Chaque périphérique conservera la même adresse MAC lors des redémarrages si le fichier de votre système possède l'option (par défaut). Ainsi, vous pourrez facilement router n'importe quel service sur votre passerelle vers le périphérique souhaité.

La configuration suivante doit être effectuée pour cette installation :

sur l'hôte

La configuration est très similaire à celle de la section #Pont réseau avec DHCP. Tout d'abord, une interface de pont virtuelle doit être créée et l'interface physique principale doit lui être liée. Cette tâche peut être accomplie avec les deux fichiers suivants, dont le contenu est identique à celui de la section DHCP.

/etc/systemd/network/MyBridge.netdev
/etc/systemd/network/MyEth.network

Ensuite, vous devez configurer l'IP et le DNS de l'interface de pont virtuel nouvellement créée. Par exemple :

sur le conteneur

Pour obtenir la configuration d'une adresse IP statique sur le conteneur, nous devons remplacer le fichier du système, qui fournit une configuration DHCP pour l'interface réseau du conteneur. Pour ce faire, il suffit de placer la configuration dans /etc/systemd/network/80-container-host0.network. Par exemple :

Assurez-vous que est activé dans le conteneur.

Trucs et astuces

Interface et intégration au bureau

systemd-networkd ne dispose pas d'une interface de gestion interactive appropriée, que ce soit via le shell de ligne de commande ou graphique.

Néanmoins, certains outils sont disponibles pour afficher l'état actuel du réseau, recevoir des notifications ou interagir avec la configuration sans fil :

networkctl (via CLI) offre un vidage simple des états de l'interface réseau.
Lorsque networkd est configuré avec wpa_supplicant, wpa_cli et wpa_gui offrent la possibilité d'associer et de configurer les interfaces WLAN dynamiquement.
peut générer des notifications simples en réponse aux changements d'état de l'interface réseau (tels que la connexion/déconnexion et la réassociation).
Le daemon permet d'exécuter des scripts en réponse aux changements d'état de l'interface réseau, de manière similaire à NetworkManager-dispatcher.
Comme pour le résolveur DNS systemd-resolved, les informations sur les serveurs DNS actuels peuvent être visualisées avec .

Configuration d'une IP statique ou DHCP basée sur le SSID (emplacement)

Il arrive souvent que le réseau sans fil de votre domicile utilise le DHCP et que le réseau sans fil de votre bureau utilise une IP statique. Cette configuration mixte peut être configurée comme suit :

/etc/systemd/network/24-wireless-office.network

# special configuration for office WiFi network
[Match]
Name=wlp2s0
SSID=office_ap_name
#BSSID=aa:bb:cc:dd:ee:ff

[Network]
Address=10.1.10.9/24
Gateway=10.1.10.1
DNS=10.1.10.1
#DNS=8.8.8.8

Collage d'une interface filaire et sans fil

Consulter également Liaison sans fil.

Le bonding permet le partage de la connexion à travers plusieurs interfaces, donc si par exemple l'interface filaire est débranchée, le sans-fil reste connecté et la connectivité du réseau reste en place de manière transparente.

Créez une interface de liaison. Dans ce cas, le mode est active-backup, ce qui signifie que les paquets sont acheminés par une interface secondaire si l'interface primaire tombe en panne.

Définissez l'interface filaire comme primaire :

Définissez le réseau sans fil comme secondaire :

Configurez l'interface de liaison comme vous le feriez pour une interface normale :

Maintenant, si le réseau filaire est débranché, la connexion devrait rester via le sans fil :

$ networkctl

IDX LINK    TYPE     OPERATIONAL      SETUP     
  1 lo      loopback carrier          unmanaged 
  2 enp0s25 ether    no-carrier       configured
  3 bond0   bond     degraded-carrier configured
  5 wlan0   wlan     enslaved         configured

4 links listed.

Accélérer le démarrage lent de TCP

Sur une liaison à bande passante élevée avec une latence modérée (généralement une connexion Internet domestique supérieure à 10 Mbit/s), les paramètres par défaut de l'algorithme de démarrage lent TCP sont quelque peu conservateurs. Ce problème se manifeste par des téléchargements qui démarrent lentement et qui mettent plusieurs secondes à s'accélérer avant d'atteindre la pleine largeur de bande de la connexion. Il est particulièrement visible lors d'une mise à jour de pacman, où chaque paquet téléchargé démarre lentement et se termine souvent avant d'avoir atteint la vitesse maximale de la connexion.

Ces paramètres peuvent être ajustés pour que les connexions TCP démarrent avec des tailles de fenêtre plus grandes que les valeurs par défaut, évitant ainsi le temps qu'il faut pour qu'elles augmentent automatiquement à chaque nouvelle connexion TCP . Bien que cela diminue généralement les performances sur les connexions lentes (ou si les valeurs sont trop élevées) en raison de la nécessité de retransmettre un plus grand nombre de paquets perdus, elles peuvent augmenter considérablement les performances sur les connexions avec une bande passante suffisante.

Il est important d'effectuer une analyse comparative avant et après la modification de ces valeurs pour s'assurer que la vitesse du réseau est améliorée et non réduite. Si vous ne consultez pas les téléchargements qui commencent lentement et s'accélèrent progressivement, il n'est pas nécessaire de modifier ces valeurs car elles sont déjà optimales pour la vitesse de votre connexion. Lors de l'évaluation comparative, veillez à effectuer des tests sur un serveur distant à haute et à basse vitesse pour vous assurer que vous n'accélérez pas l'accès aux machines rapides au détriment de l'accès aux serveurs lents.

Pour ajuster ces valeurs, modifiez le fichier .network de la connexion :

Les valeurs par défaut de fonctionnent bien pour les connexions plus lentes que 10 Mbit/s. Pour une connexion de 100 Mbit/s, une valeur de fonctionne bien. La page de manuel indique qu'une valeur de 100 est considérée comme excessive.

Si le paramètre sysctl est activé, la connexion reviendra à ces paramètres initiaux après un certain temps d'inactivité (souvent très court). Si ce paramètre est désactivé, la connexion maintiendra une fenêtre plus élevée si une fenêtre plus grande a été négociée pendant le transfert de paquets. Quel que soit le paramètre, chaque nouvelle connexion TCP commencera avec les paramètres définis ci-dessus.

Le paramètre sysctl n'est pas directement lié à ces valeurs, car il contrôle la façon dont les fenêtres d'encombrement et de réception sont ajustées lorsqu'une liaison TCP est active, et particulièrement lorsque le chemin entre les deux hôtes est encombré et que le débit doit être réduit. Les valeurs ci-dessus définissent simplement les valeurs de fenêtre par défaut sélectionnées pour chaque nouvelle connexion, avant qu'un algorithme de congestion prenne le relais et les ajuste si nécessaire. Définir des valeurs initiales plus élevées raccourcit simplement une partie de la négociation pendant que l'algorithme de congestion tente de trouver les valeurs optimales (ou, à l'inverse, définir des valeurs initiales erronées ajoute un temps de négociation supplémentaire pendant que l'algorithme de congestion s'efforce de les corriger, ralentissant chaque connexion TCP nouvellement établie pendant quelques secondes supplémentaires).

Voir aussi

Messages de Tom Gundersen sur le blog de Core OS
Comment configurer systemd-networkd avec wpa_supplicant (Instruction de WonderWoofy sur les forums Arch)

gollark: Unless it doesn't.

gollark: Anyway, many of the bugs in potatOS come from stuff like the SPUDNET daemon not being subject to sandboxing, so people can fake events and stuff going to that in increasingly convoluted ways to make it execute code when it shouldn't.

gollark: It was used to provide sandboxed copies of potatOS for testing and stuff.

gollark: Or crane, my really, *really* broken sandboxingish thing.

gollark: Well, it sort of is, in that it complains lots if you try and delete SYSTEM32.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.