Archlinux.fr [Forums]

Tu continues à faire n'importe quoi. Tu as du DHCP d'un côté et des IPs fixes de l'autre.

Pose-toi calmement et dis-nous ce que tu veux, en long, en large, en travers. (Bis repetitas) (je ne reviendrai pas si tu continues à être aussi peu coopératif)

@benjarobin:
Merci pour ces explications.

J'ai supprimé la gateway dans LAN et WIFI et en effet tout fonctionne de la même façon

C'est à dire que sans dhcpcd actif les interfaces ne montent toujours pas

Les mêmes erreurs dans le journal: could not bring up interface: Operation not supported
Et puis ces renommage dans les deux sens qui m'interpellent sans que je n'ai d'explication.

@Moviuro:
Je ne veux pas de client dhcp, seulement le serveur.
Ce n'est pas contradictoire avec le fait d'être en IP fixe que je sache?

C'est une passerelle donc pas besoin de dhcpcd dessus car les trois interfaces sont en IP fixes.
Je ne sais quoi dire de plus.
A ce sujet, j'ai remplacé dhcpd4 par dnsmasq-dhcp qui me suffit amplement.

Dire que je ne suis pas coopératif est un peu abusé à mon avis.
C'est bien moi qui ai le problème, ne pas l'être serait complètement nul.

Comme je disais au départ, tout fonctionne correctement SI dhcpcd est actif.
Dès que je le désactive WAN, LAN et WIFI restent DOWN.

Je dirai comme cela que c'est un bug de systemd-networkd. Tu peux essayer avec netctl,

Ou tout simplement créer 2 services à placer dans /etc/systemd/system, en considérant que tu as bien gardé le renommage de tes interfaces réseaux :
networkLAN.service :

Code : Tout sélectionner

[Unit]
Description=Network LAN Connectivity
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-LAN.device
After=sys-subsystem-net-devices-LAN.device
  
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev LAN up
ExecStart=/sbin/ip addr add 10.10.10.1/255.255.255.0 broadcast 10.10.10.255 dev LAN
ExecStop=/sbin/ip addr flush dev LAN
ExecStop=/sbin/ip link set dev LAN down
  
[Install]
WantedBy=multi-user.target

networkWAN.service :

Code : Tout sélectionner

[Unit]
Description=Network WAN Connectivity
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-WAN.device
After=sys-subsystem-net-devices-WAN.device
  
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip link set dev WAN up
ExecStart=/sbin/ip addr add 192.168.15.2/255.255.255.0 broadcast 192.168.15.255 dev WAN
ExecStart=/sbin/ip route add default via 192.168.15.1
ExecStart=-/usr/bin/cp -f /etc/resolv.conf.static /etc/resolv.conf
ExecStop=/sbin/ip addr flush dev WAN
ExecStop=/sbin/ip link set dev WAN down
  
[Install]
WantedBy=multi-user.target

Puis tu créer le fichier /etc/resolv.conf.static avec ceci (si c'est bien ton serveur de DNS) :

Code : Tout sélectionner

nameserver 192.168.15.1

Finalement, il ne reste plus qu'a activer le tout :

Code : Tout sélectionner

systemctl enable networkLAN.service
systemctl enable networkWAN.service

Et redémarre pour tester le tout

C'est vraiment très sympa de ta part benjarobin.

Pour activer les interfaces j'avais pensé à ajouter:

Code : Tout sélectionner

/bin/ip link set dev WAN up
/bin/ip link set dev LAN up
/bin/ip link set dev WIFI up

Dans mon rc.local et ça fonctionne très bien.

Le truc c'est que je suis un peu pointilleux et soucieux de réduire au maximum le nombre de service.
C'est une petite machine de 2Go de RAM et j'ai qlqs autres besoins que simple passerelle dessus (vidéo protection, home TV, ...).

Et puis ya le truc quand même.
Pourquoi en IP fixe j'ai besoin de dhcpcd?

Jamais je n'aurais avancé, ni même pensé d'ailleurs, que ce pourrait être un bug de systemd.
Mais si qlqun ayant plus de compétences que moi pouvais le vérifier et éventuellement le faire remonter ce serait plutôt bien je crois.

Encore merci, c'est tjrs sympa d'être pris par la main

ElMoribond a écrit :Le truc c'est que je suis un peu pointilleux et soucieux de réduire au maximum le nombre de service.

Sauf que le cout d'un tel service est nul ! Tu peux en mettre 1000 cela ne changera rien, juste le démarrage du PC qui sera un peu plus long. Mais sinon la consommation de ressource sur le long terme est nulle. Il n'y a rien qui tourne en tache de fond avec le genre de service que je t'ai donné, je dirais même que c'est plus léger que systemd-networkd qui lui tourne en tache de fond.
Ma solution considère implicitement que systemd-networkd avait été désactivé !

Sinon il n'y a pas de rc.local qui existe, hein, ou alors tu l'as rajouté, et dans ce cas cela me fait bien sourire (toi qui veux optimiser un maximum) car lancer bash (pour le rc.local) est bien plus couteux que le service que je t'ai donné (mais au final cela reste dans l'ensemble très négligeable par rapport à lancer Xorg).
De plus "résoudre" le problème via le rc.local est horriblement moche car il n'y a aucune gestion des dépendances...

Il y avait quoi dans ton rc.local ? Ce ne serait pas lui qui foutait la merde initialement ?

Tout d'abord:
Je crois déceler une pointe d'amertume dans ton post

Sois certain que j'en suis désolé et je m'excuse si tu l'as pris ainsi.
J'ai bien compris, et j'apprécie réellement, le temps que tu as passé pour me répondre.
Sincèrement, mes remerciements le sont.

Je sais que ce n'ai pas facile de juger du niveau d'une personne en qlqs posts.
Et ton implication pour donner une solution détaillée ne peut que t'honorer.
Tu es, encore une fois c'est sincère, une bonne personne j'en suis certain.
Et c'est vraiment très agréable lorsqu'on a un petit niveau (le mien est juste moyen, voir moyen-bas si on chipote).

Ensuite:
En fait, c'est un pseudo rc.local, lancé par un service:

Code : Tout sélectionner

#/lib/systemd/system/rc-local.service
[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/etc/rc.local
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Aucune empreinte mémoire donc. Si ce n'est les éventuels process lancés dedans.

L'intérêt que j'y vois est de centraliser ce qui s'exécute au démarrage. Sûrement une rémanence de l'AUTOEXEC.BAT.
Et, tu as raison, aucune gestion des dépendances ni aucune possibilité d'arrêt/relance.
Si j'ai besoin je n'hésite pas à créer un service (par exemple pour mon process python qui purge périodiquement (donc timer associé) certains enregistrements de certaines de mes tables).
Mais dans mon cas, il (rc.local) ne me sert pour le moment qu'à jouer un mp3 car ma passerelle n'a pas d'écran.
Et un petit script .sh qui doit tourner en permanence (donc process bash forcément - à ce sujet je me demande si j'en faisais un exécutable en C je gagnerais en mémoire, autre sujet, un autre jour) et il est probable que j'y ajoute avec le temps qlqs commandes.

Mais sois rassuré, rien dedans qui ne puisse expliquer ou justifier le comportement dont je me plains.
D'ailleurs, avant de te répondre, j'ai fais le test rc-local.service désactivé.
Même si je n'y croyais pas trop j'ai également testé avec le DHCP désactivé sur mon antenne Wimax (oublié de le dire).

Bref,
Je sais lire (petit niveau d'anglais), j'ai un minimum de compétence, ou tout au moins l'esprit curieux.
Mais après avoir parcouru moult pages sans trouver un début de piste ou d'explication je n'arrive pas à trouver de cas similaire (je veux dire only systemd-networkd).

Concernant ta proposition d'essayer netctl je répondrais: why not but why?
Cela implique des process supplémentaires et donc plus d'occupation mémoire non?
Je n'ai certainement pas tes compétences ou connaissances donc j'aimerais savoir si tu penses réellement que ce serait préférable que de laisser tourner dhcpcd pour rien.

Et pour finir, au risque de te froisser (j'espère que tu ne m'en voudras pas):
La solution, que ce soit tes services ou "mon" rc.local, ne sont que des pis-aller.
Et je n'arrive pas à m'en satisfaire, pour moi une machine en IP fixe n'a pas besoin de dhcpcd.

Ma solution est propre et simple dans le principe comme à comprendre, je ne vois pas en quoi c'est un "pis-aller":
Le service attend que l'interface soit prête et renommée sous le bon nom, met l'interface UP, configure son IP, sa route et optionnellement configure le DNS... C'est tout rien de plus

Je ne suis pas vexé, je suis surtout triste que tu n'ai pas compris à quoi servait ces services : c'est une vrai solution KISS et non un "bricolage". Par contre ta "solution" est vraiment du bricolage et c'est un miracle que ce soit tombé en marche.

Elle ne nécessite pas de rc.local ni de systemd-networkd, et encore moins de dhcpcd (en gros elle ne nécessite aucun service lié au réseau supplémentaire).
Ce service a été créé au début de systemd alors qu'il n'y avait pas encore de systemd-networkd. Puis je l'ai un peu adapté à mon usage : oui oui je l’utilise tous les jours

Après oui tu peux remplacer le tout par netctl, qui est très léger, simple à configurer mais surement pas aussi simple que les services donnés.

ElMoribond a écrit :Dire que je ne suis pas coopératif est un peu abusé à mon avis.
C'est bien moi qui ai le problème, ne pas l'être serait complètement nul.

J'avais absolument pas compris que ta machine était un routeur.
Ensuite, j'ai pas vu de configuration systemd-networkd valide sur ce thread. D'où le "peu coopératif"

L'avantage de systemd-networkd sur la solution de Benjarobin, c'est en cas de coupure de connextion (systemd-networkd s'en rend compte tout seul et éteint l'interface et la relance dès que possible)

@Benjarobin, y'a pas de DNS dans tes services, normal ?

@Moviuro Il faut savoir lire entre les lignes
Si si, dans ma configuration il y a bien la gestion du resolv.conf, donc du DNS. Je te laisse relire mon message

Sinon avec le service décrit, si tu met en veille le PC ou que tu débranches le câble Ethernet, que ce soit au réveil ou au retranchement du cable, cela se passe très bien. Si tu débranches le câble Ethernet cela ne va en aucun cas mettre l'interface DOWN ni la dé-configurer. Donc dès que le link devient à nouveau UP cela remarche tel quel.
J'ai bien dit que j'utilisais ceci tous les jours, je ne vois pas pourquoi j'utiliserai une solution bancale

Sans /etc/systemd/network/LAN, WAN, WIFI.network:

Code : Tout sélectionner

août 29 18:36:27 jeep systemd[1]: Starting Network Service...
août 29 18:36:27 jeep systemd-networkd[218]: Enumeration completed
août 29 18:36:27 jeep systemd-networkd[218]: WAN: Renamed to eth0
août 29 18:36:27 jeep systemd-networkd[218]: LAN: Renamed to eth1
août 29 18:36:27 jeep systemd-networkd[218]: eth1: Renamed to LAN
août 29 18:36:27 jeep systemd-networkd[218]: WIFI: Renamed to wlan0
août 29 18:36:27 jeep systemd-networkd[218]: eth0: Renamed to WAN
août 29 18:36:27 jeep systemd-networkd[218]: wlan0: Renamed to WIFI
août 29 18:36:28 jeep systemd[1]: Started Network Service.
août 29 18:36:34 jeep systemd-networkd[218]: WIFI: Gained carrier

Avec:

Code : Tout sélectionner

août 29 18:38:28 jeep systemd[1]: Starting Network Service...
août 29 18:38:28 jeep systemd-networkd[244]: Enumeration completed
août 29 18:38:28 jeep systemd-networkd[244]: WAN: Renamed to eth0
août 29 18:38:28 jeep systemd-networkd[244]: LAN: Renamed to eth1
août 29 18:38:28 jeep systemd-networkd[244]: eth1: Renamed to LAN
août 29 18:38:28 jeep systemd-networkd[244]: eth0: Renamed to WAN
août 29 18:38:28 jeep systemd-networkd[244]: WIFI: Renamed to wlan0
août 29 18:38:28 jeep systemd-networkd[244]: wlan0: Renamed to WIFI
août 29 18:38:28 jeep systemd-networkd[244]: LAN: LAN             : could not br
août 29 18:38:28 jeep systemd-networkd[244]: LAN: Configured
août 29 18:38:28 jeep systemd-networkd[244]: WAN: WAN             : could not br
août 29 18:38:28 jeep systemd-networkd[244]: WAN: WAN             : could not se
août 29 18:38:28 jeep systemd-networkd[244]: WAN: Configured
août 29 18:38:28 jeep systemd[1]: Started Network Service.
août 29 18:38:34 jeep systemd-networkd[244]: WIFI: Gained carrier

@Moviuro:
Je me disais aussi que tu avais peut-être lu un peu trop vite mais ta remarque est certainenent à propos car j'ai configuré dnsmasq sur ma passerelle/routeur et donc mon dns server est/doit être 127.0.0.1.

Bref, encore une fois sans dhcpcd ça ne passe pas. WAN, LAN et WIFI restent DOWN

@benjorabin;
Quand je disais "pis-aller" ce n'était pas pour critiquer de façon négative.
C'était simplement pour dire que cela contournait le problème.
Dit autrement, que je n'étais pas sûr que cela me permette de désactiver dhcpcd.

Ya quand même un truc qui me chiffonne, pourquoi les interfaces sont renommées dans les deux sens?

OUPSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
J'avais oublié d'activer les networkWAN, LAN.service

Je me demande si tu lis intégralement mes messages... Je vais me répéter !!!
Si tu veux utiliser mes services, il ne faut surtout pas activer/utiliser les services : systemd-networkd et dhcpcd => Cela n'a strictement aucun sens ! Toute la configuration du réseau est intégré aux services. De plus tu dois supprimer tout ce qui touche au réseau dans ton rc.local !

Ok, j'ai peut-être lu trop vite;

J'ai supprimé /etc/systemd/network/LAN, WAN et WIFI.network
J'ai crée /etc/systemd/system/LAN, WAN et WIFI.service comme tu me l'as indiqué.
J'ai crée /etc/resolv.con.static (bien que j'utilise dnsmasq)
- avec soit 127.0.0.1, soit 192.168.15.1 dedans
J'ai désactivé systemd-networkd et dhcpcd
J'ai activé LAN, WAN et WIFI.service
Mon rc.local est désactivé.

Résultat:

Les interfaces montent bien au démarrage de la machine (l'objet de mon prime post)

Mais je ne peux plus rien pinger à partir de mon PC ou mon phone (j'ai pourtant une IP sur chacun et tout est ok sur ma passerelle via vnc).

Je précise que si j'ai configuré dnsmasq ce n'est pas par caprice mais parce que j'en ai besoin.

De plus, dans LAN, WAN et WIFI.network j'ai un IPForward=ipv4.

Bref,
Cette fois-ci j'en suis sûr, tu vas mal le prendre mais tout cela n'est que pis-aller (ou palliatif si tu préfères).
Je ne doute pas que ta solution fonctionne chez toi.
Je ne doute encore moins que tu as les compétences pour te passer de systemd-networkd en créant tes propres services.
Il est clair que tes connaissances te le permettent.
Mais ce n'est pas le cas de tout le monde. Et j'irais même plus loin en disant que ce n'est certainement pas un conseil à donner.

Perso, comme déjà dis, j'ai un niveau moyen, loin d'être un pro je n'en suis pas pour autant un newbie.
J'ai lu et relu les wiki et moult pages en et fr.
Ma configuration est conforme wiki (en partie grâce à toi au sujet de la gateway sur LAN et WIFI).
Malgré tout, ça ne marche tjrs pas sans dhcpcd.
Tu as émis l'hypothèse que c’était un bug de systemd.
Tu as, c'est indéniable, plus de compétences que moi pour le penser.
Je n'ai juste qu'une phrase à dire; vérifie et prouve le, si c'est le cas tu auras fais avancer Archlinux.

Maintenant, si je suis tes recommandations/conseils/... je vais me retrouver avec un Archlinux sans systemd-networkd.
Quid si j'ai une merde dans 2 mois?
Qui va ne serait-ce qu'essayer de m'aider si je dis que j'ai une merde réseau alors que j'ai désactivé systemd-networkd et que j'utilise un système de services "perso"?
Tu auras compris j'espère.
J'ai suivi ce que tu m'as dis mais ça ne le fais pas.
Il ne manque probablement qu'une ligne ou deux ici ou là mais dans tous les cas ce sera du sur-mesure (luxe que je ne veux et ne peux me permettre).

Je te renouvelle encore une fois mes sincères remerciements (si tu passe dans le sud de la Sarthe, envoie moi mail avant que je t'offre une real beer).

PS:
Question qui restera pêtre sans réponse:
Pourquoi outrepasser systemd-netword?

J'aurais bien aimé aider plus mais manifestement tu ne veux pas, dommage.
J'aurais bien aider aussi comprendre pourquoi systemd-netword ne fonctionne pas, mais cela va être très difficile à distance, et non je n'ai pas des pouvoirs de divination avec si peu d'information. D'ailleurs à propos d'information, j'adore ta façon de procéder, on donne des informations au compte goutte, voir même cela change aux fils des messages...
Il n'a par exemple jamais été question de Wifi (je suis curieux de savoir ce que tu as mit dans le fichier de service...), ni question de IPForward.
Et pour finir on découvre que ton réseau est bien plus complexe, à la base je croyais que ton PC était juste connecté à une BOX et à un réseau local : là je ne comprend plus rien...
Au final Moviuro avait raison depuis le début

Moviuro a écrit :Pose-toi calmement et dis-nous ce que tu veux, en long, en large, en travers. (Bis repetitas) (je ne reviendrai pas si tu continues à être aussi peu coopératif)

C'est vrai que je n'ai pas été très précis.
Il est également vrai que IPForward=ipv4 n'apparait pas dans mon premier post.

En fait mon réseau n'est pas compliqué.
C'est une passerelle avec WAN connectée en ethernet sur box et LAN su un petit switch.
J'ai, c'est vrai, ajouté une antenne Wifi.

Mais tout cela n'a aucune importance, sinon je pense que je l'aurais indiqué.
Dis autrement, sans WAN ni WIFI ET sans renommer les interfaces j'ai exactement le même problème.
Sans dhcpcd eth0 ne démarre pas.

Idem sur mon PC client également sous Archlinux, enp0s10 configuré en fixe ne démarre pas sans dhcpcd!

Bref,
Merci tout de même d'avoir essayé.
Désolé de vous avoir fait perdre du temps.

En fait c'était tout con et logique en fait.
Pour résoudre mon problème il m'a suffit de désactiver ipv6 du noyau.
J'aurais certainement pu en positionner dans mes interfaces et dans le dhcp (serveur) mais dans la mesure ou mon FAI ne me connecte qu'en ipv4....

ElMoribond a écrit :En fait c'était tout con et logique en fait.
Pour résoudre mon problème il m'a suffit de désactiver ipv6 du noyau.

Euh, sauf que c'est tout sauf logique, en fait.
Mais si ça marche... c'est une victoire en partie?

:contourne:

Si le noyau est activé avec le support ipv6 je trouve logique que systemd refuse de démarrer une interface qui n'a pas d'adresse ipv6.
Pourtant simple à comprendre.

Ceci dit, avec ta logique qui confond DHCP server et client

Moviuro a écrit :Tu continues à faire n'importe quoi. Tu as du DHCP d'un côté et des IPs fixes de l'autre

Je ne sais pas comment t'expliquer.

Contrairement aux posts de benjarobin les tiens n'ont aucun intérêt.
Et pour terminer, tu exprime simplement ton mauvais ressenti.
De la à en conclure que tu manques d'humilité je n'irai pas jusque la mais je ne n'en pense pas moins.

Pour ce qui est du mot "traîtrise" que tu utilises je t'invites à lire la définition.
Encore une fois tu es à côté de la plaque.

Et pour ajouter (Résolu) ce serait avec plaisir mais les paramètres du forum ne m'autorise pas, trop de caractères dans le titre.

Sur ce, si tu, ou d'autres personnes ont appris qlqs trucs avec ce post c'est une victoire complète en effet;)

Non c'est bien complètement illogique. Quand tu démarres une interface elle n'a aucune IP... Et je pousserait même le vice plus loin, une interface Ethernet n'a pas besoin d'IP pour fonctionner, juste une adresse MAC
Je ne saurais jamais la fin de l'histoire, bug ou problème de configuration ?

Archlinux.fr [Forums]

[systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique

Re: [systemd-networkd] Interfaces qui ne démarrent pas en automatique