On a beaucoup échangé déjà mais du coup on va repousser l’article à la semaine prochaine afin qu’on soit bien clair sur ce qu’on prévoit, comment on voit les choses.

Tcho !

Excellente nouvelle !

J’ai envoyé un mail hier vers 16h00, j’attends qu’on échange un peu sur le sujet, j’ai également rédigé un article que je publierai sur le blog du Jdh dans la semaine.

Tcho !

Merci pour la proposition. +1

Des idées sur “Mutualisation avec d’autres projets communautaires “ ?

+1

Merci pour le partage, c’est très clair et intéressant !

On peut également placer la sous-commande commit dans le document en ligne (here-document).

uci -q batch <<EOF
    set network.lan.dns='192.168.1.1'
    set network.lan.ipaddr='192.168.1.3'
    set network.lan.netmask='255.255.255.0'
    set network.lan.gateway='192.168.1.1'
    set network.lan.proto='static'
    commit
EOF

Autre optimisation possible : remplacer <<EOF par <<-EOF. Les lignes suivantes sont indentées avec une tabulation (c.f. dash).

:-)

Article modifié en cours d’upload ! (avec une petite mention spécifique dans une section finale nommée “Remerciement”)

Merci également pour ce retour ! J’aime bien découvrir des articles pratico-techniques : savoirs-faire, connaissances, apprentissage, transmission, goût d’entreprendre.

J’ai perçu un traitement légèrement différent pour IPv6 par rapport à IPv4 et cela m’a un peu embrouillé l’esprit.

Modifiez le fichier /etc/config/dhcp pour ajouter l’option suivante option ignore ‘1’ dans la section config dhcp ‘lan’ ; supprimez aussi toutes les options relatives à IPv6 !

Je croyais qu’il suffisait de changer la valeur de l’option ignore pour désactiver totalement les serveurs DHCPv4/v6. Ce qui n’est pas forcément le cas. La documentation laisse penser qu’il faille aussi changer les valeurs des autres options. En cherchant rapidement, je ne suis pas parvenu à déterminer si dnsmasq supportait cette option. En somme, je n’ai pas vérifié.

Bonjour,

Merci pour l’ensemble des remarques, j’apprécie la démonstration par l’usage du binaire uci. Néanmoins :

Qui a parlé de “faire abstraction du protocole IPv…” ? pas moi, surtout pas ! Les trames DHCP sont fournies par le routeur principal, que ce soit pour IPv4/v6. Le répéteur ne fait que les transmettre aux différents périphériques concernés. (et soit, soit qu’ils soient connectés physiquement sur l’un des ports physiques, soit par le biais du Wifi). (Et concernant mon réseau @home, les deux protocoles fonctionnent très bien, sans soucis). Quoiqu’il en soit, l’usage de ceux-ci n’est pas le tenant de cet article, soit de transformer son routeur OpenWRT en répéteur wifi.

Concernant le fait de désactiver WAN, soit. C’est perdre l’utilisation d’un port physique… Personnellement, je préfère le “ré-emploi”.

Sinon, concernant la désactivation du serveur DHCP du répéteur, l’usage de l’option ignore n’est pas l’équivalent du fait d’arrêter et de désactiver le service. Autrement l’option n’aurait aucun sens, et n’aurait pas été créée. La documentation officielle à laquelle je fais référence dans l’article dit clairement qu’il n’est pas recommandé ni nécessaire de désactiver le service dnsmasq (DHCP), il sera de toute façon réactiver lors du prochain sysupgrade. La seule manière de garantir le fait qu’il ne soit pas “fonctionnel” est l’usage de l’option idoine.

Voilà (dans l’immédiat).

PS : Je vais “réfléchir” à actualiser ledit article avec l’à-propos de la commande uci. Encore une fois, merci pour ces remarques.

La version d’origine est plus claire. Continuer à faire abstraction de la pile de protocoles IPv6 en 2025 n’est pas une bonne idée. Les gens ayant des connaissances sur les réseaux informatiques mais ne connaissant pas IPv6 devraient parcourir le MOOC « Objectif IPv6 » de l’Institut Mines-Télécom, au moins, pour avoir des notions et se faire une idée (voir les prérequis). IPv6 deviendra incontournable.

Voici quelques remarques sur la forme.

uci -q batch <<EOF
    set network.lan.proto='dhcp'
EOF

Le serveur DHCP du routeur peut configurer l’interface de gestion du point d’accès.

uci -q batch <<EOF
    set.wireless.wifi_device[0].country='YourCountryCode'
    set.wireless.wifi_device[1].country='YourCountryCode'

    set wireless.wifi_iface[0].ssid='YourSSID'
    set.wireless.wifi_iface[1].ssid='YourSSID'

    set wireless.wifi_iface[0].key='YourSecurePassphrase'
    set.wireless.wifi_iface[1].key='YourSecurePassphrase'
EOF

Exploiter uci batch serait plus efficace que de recopier intégralement des sections. On perçoit mieux les paramètres à modifier et on peut l’appliquer instantanément à sa configuration via la ligne de commande.

uci -q batch <<EOF
    set network.wan.disabled='1'
    set network.wan6.disabled='1'
EOF

Il est préférable de désactiver l’interface WAN plutôt que de la supprimer de la configuration. On pourrait ainsi potentiellement la réactiver pour mettre à jour le point d’accès.

De même, selon l’article, il est préférable de désactiver le serveur DHCP du point d’accès.

uci -q batch <<EOF
    set dhcp.lan.ignore='1'
EOF

À noter que l’équivalent en ligne de commande de l’opération LuCI correspondante serait :

service dnsmasq stop
service dnsmasq disable

On aurait également pu créer une image personnalisée ne contenant aucun serveur DHCP (c.f. sélecteur de micrologiciel). Dans ce cas, il aurait fallu configurer soi-même l’interface « locale au lien » du point d’accès.

Bonjour,

Des mesures montrent que GDU serait plus lent qu ncdu : https://linuxfr.org/nodes/140324/comments/2000866

J’ai refait les tests et j’arrive au même résultats. C’est joli et coloré mais au final cela ne pourrait être que cela.

Et il faut être très prudent avec l’ajout de dépôt ppa, les paquets ne sont pas forcément disponibles pour toutes les versions et c’est le meilleur moyen de rendre un système Ubuntu impossible à maintenir dans le temps.

Pas de problème pour moi.

Tcho !

Hello,

Il n’y a que moi qui n’arrive pas à faire défiler la lecture de cet article ? Je commence la lecture normalement et ensuite la page se fige, j’ai ’abords pensé à un plantage Firefox, mais cela ce produit à chaque tentative.

Sûrement (je n’ai pas de machine avec systemd-dns-delagate pour tester) mais ce n’en est pas moins problématique dans une documentation qui a vocation a être consultable pendant plusieurs années. Pour un usage restreint dans le temps et en connaissance de cause, pourquoi pas.

Pour un usage local il me semble que .internal avait été retenu par l’ICANN (les RFC proposent d’autres TLD « privés »

Le .local pourrait être utilisé avec avahi mais c’est sûrement une configuration plus complexe que celle que vous proposez dans votre article avec dnsdock.

C’est installé par défaut dans Omarchy, le changement n’est pas radical, j’aime bien.

Je doute que resolved arrête de déléguer les .docker s’il devient public.

C’est plutôt l’inverse qui va se passer: dnsdock retournera un NXDOMAIN pour un domaine public en .docker.

Il me semble que .localdomain est réservé pour l’usage local. Attention, .local est pour le mdns.

Les noms choisis n’étaient plus résolus localement puisque leurs résolveurs interrogeaient les serveurs faisant autorité pour .dev. De manière générale choisir un TLD « bidon » risque à un moment (le TLD est attribué) de contrevenir au besoin d’unicité des noms de domaine.

Ah, et quels problèmes ont-ils eut lorsque les TLD est sorti ?

C’est ce qu devaient se dire les gens qui utilisaient le .dev à une époque ;-)

Configurer dnsdock et resolved, pardi. Quel est le problème ?

Vu la durée de vie d’un conteneur sur un poste de dév, je ne vais pas résoudre maintenant un problème qui n’arrivera jamais.