Journal [ HS ] ... enfin, pas tant que ça.

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
10
17
mar.
2024

Je voulais configurer une VM en local afin de faire quelques petites manips.

J'installe donc une VM sous Rocky Linux.

Je cherche ensuite à faire un truc tout bête : changer le serveur utilisé par ma VM. Je vais voir /etc/resolv.conf qui me rappele que le fichier est éré par NetworkManager.

Je vais donc voir la doc de NetworkManager pour voir comment la configuration est géré :

Je cite :

If a default NetworkManager.conf is provided by your distribution's packages, you should not modify it, since your changes may get overwritten by package updates. Instead, you can add additional .conf files to the /etc/NetworkManager/conf.d directory. These will be read in order, with later files overriding earlier ones. Packages might install further configuration snippets to /usr/lib/NetworkManager/conf.d. This directory is parsed first, even before NetworkManager.conf. Scripts can also put per-boot configuration into /run/NetworkManager/conf.d. This directory is parsed second, also before NetworkManager.conf. The loading of a file /run/NetworkManager/conf.d/name.conf can be prevented by adding a file /etc/NetworkManager/conf.d/name.conf. Likewise, a file /usr/lib/NetworkManager/conf.d/name.conf can be shadowed by putting a file of the same name to either /etc/NetworkManager/conf.d or /run/NetworkManager/conf.d.

Mais c'est quoi ce b**** ? Pourquoi aller éparpiller dans /etc, puis dans /usr/lib, puis dans /run ? Qu'est-ce que de la conf vient faire dans /usr/lib ?

Mais ce n'est pas tout :

NetworkManager can overwrite certain user configuration options via D-Bus or other internal operations. In this case it writes those changes to /var/lib/NetworkManager/NetworkManager-intern.conf. This file is not intended to be modified by the user, but it is read last and can shadow user configuration from NetworkManager.conf.

Systemd fait pas mieux mais je m'abstiendrais de m'étaler sur le sujet.

Je comprends le besoin de ne pas avoir une configuration monolythique, mais pourquoi aller éparpiller celles-ci aussi loin du point de vue du système de fichier, et dans un endroit qui initialement n'était pas prévu pour ça ? Ca me donne l'impression de ranger la vaisselle non pas dans la cuisine, mais dans le garage ou dans le grenier.

Moi, personnellement quand je lis ce genre de choses, je me dis qu'il y a vraiment un truc qui ne va pas sur les distributions Linux.

Du coup j'ai laissé tomber ce que je voulais faire initialement et je vais sortir un peu.

  • # Désolé pour la mise en page foireuse ....

    Posté par  . Évalué à 2 (+1/-1).

    Je ne pensais pas que ce que je cite en tant que code allait être affiché comme ça (je n'ai pas pensé à vérifier avant d'envoyer), et je n'ai malhhereusement pas moyen de corriger.

  • # Connman

    Posté par  . Évalué à 3 (+2/-1). Dernière modification le 17 mars 2024 à 14:45.

    Mais c'est quoi ce b**** ? Pourquoi aller éparpiller dans /etc, puis dans /usr/lib, puis dans /run ?

    Il y a bien longtemps que j'ai remplacé Networkmanager (trop compliqué pour moi) par Connman (bien intégré à Enlightenment). As tu essayé Connman?

    • [^] # Re: Connman

      Posté par  . Évalué à 2 (+0/-0).

      Oui, j'ai tenté d'utiliser conman sur ubuntu avec enlightenment … mais c'est loin d'être simple : rien n'est fait pour que ça marche correctement. Mais au final j'y suis parvenu.

      • [^] # Re: Connman

        Posté par  . Évalué à 2 (+0/-0).

        Enfin .. quand je dis que j'y suis parvenu : j'ai réussi à faire fonctionner le truc, mais il y a des cas ou ça ne marche pas forcément correctement. Je sais, je devrais virer Ubuntu. Je n'ai pas encore eu le temps de le faire mais je pense que ça viendra (il est fort probable que la 22.04 soit la dernière ubuntu installée sur ma machine).

    • [^] # Re: Connman

      Posté par  (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 17 mars 2024 à 22:14.

      Oh merci ; tu m’as mis sur la piste d’un problème qui m’embêtais depuis quelques mois : dès que je démarrais une machine virtuelle sur mon PC, j’avais besoin de supprimer une route qui renvoyait par défaut tout le trafic vers mon interface virtuelle.

      Le problème venait du masque d’interface à ignorer de connman, que j’ai trouvé en lisant la page man après avoir lu ton commentaire !

  • # différents répertoires

    Posté par  . Évalué à 10 (+14/-0). Dernière modification le 17 mars 2024 à 15:00.

    Mais c'est quoi ce b**** ? Pourquoi aller éparpiller dans /etc, puis dans /usr/lib, puis dans /run ? Qu'est-ce que de la conf vient faire dans /usr/lib ?

    C'est plus ou moins expliqué dans ce que tu as copié collé.

    De ce que je comprends (et je peux être contredit si vous le voulez), la philosophie actuelle (grandement poussée par systemd) est :

    • la configuration que l'administrateur définit est dans /etc/
    • la configuration poussée par un paquet logiciel (donc, par ta distribution) est dans /var/lib ou /usr/lib … quelque part où personne ne viendra écraser des morceaux de conf requis par d'autres programmes
    • tout ce qui ne doit pas survivre à un redémarrage dans /run

    Ce dernier est intéressant, surtout pour la configuration réseau. Tu veux faire des essais, crées tes fichiers de configuration dans /run là où ton programme l'attend. Tu pers l'accès à ta machine ? tu demandes à quelqu'un d'appuyer sur le bouton marche/arrêt ou tu initie un reboot depuis l'interface qui marche bien (cloud provider ou ipmi) et ta configuration douteuse est supprimée, tu redémarres avec la dernière configuration connue.

    Celui d'avant est aussi intéressant:
    quand tout est dans /etc, l'admin peut tout modifier sans se poser de questions ; et ces configuration peuvent être modifiées lors des mises à jours des paquets logiciels.
    Avoir de la conf dans /usr/lib ou /var/lib permet à l'administrateur de "savoir ce qu'il fait". Et en tout cas, ne pas modifier ces fichier, mais jouer sur de la surcharge via ce qui est dans /etc.
    Cela peut simplifier les mises à jour car il n'y a pas un jeu de ping pong entre la configuration de l'admin et la configuration livrée avec les logiciels qui peut être réinitialisée lors des mises à jour.

    Et si tu veux une solution quick&dirty (rapide&dégueulasse comme le diraient les personnes pointilleuses sur la francisation à outrance), tu peux désactiver la gestion de /etc/resolv.conf par networkmanager en ajoutant ceci dans son fichier de conf (dans /etc, ça ira !):

    [main]
    dns=none

    • [^] # Re: différents répertoires

      Posté par  . Évalué à 7 (+5/-0).

      En soi, NetworkManager ne me dérange pas plus que ça. Il est un peu compliqué à comprendre (et j'ai du mal avec la configuration gérée par nmcli dans un truc opaque), mais si je parviens à faire ce que je veux dans des fichiers de conf, ça me va.

      Dans mon cas, j'ai réussi à m'en sortir (je râle, mais je suis têtu et j'ai cherché avant d'aller faire un tour et j'ai trouvé - la doc de NetworkManager.conf est assez bien faite - mais manque d'exemple à mon goût). J'ai créé le fichier /etc/NetworkManager/conf.d/00-global-dns-domain.conf dans lequel j'ai ajouté la ligne suivante :

      
[global-dns-domain-*]
servers=8.8.8.8

      Un redémarrage de NetworkManager et c'était résolu.

      Non, moi ce qui me dérange c'est d'une part d'aller coller des fichiers de conf d'un coup dans /var/lib, d'un autre coup vers /usr/lib …. Autant pour /run je comprends, autant pour le reste je ne suis pas d'accord :

      quand tout est dans /etc, l'admin peut tout modifier sans se poser de questions ; et ces configuration peuvent être modifiées lors des mises à jours des paquets logiciels.

      On aurait pu créer un répertoire dans /etc pour ça plutôt que d'aller coller des trucs un coup dans /var/lib, un coup dans /usr/lib. Les snippets historiquement se trouvent dans /usr/share/examples

      Moi en tant qu'admin qui gère des machines au quotidien, avec parfois un putty sur une VM de rebond ( en RDP) comme seule possibilité de se connecter, j'apprécie d'avoir les confs pas trop éparpillées pour pouvoir voir comment elles sont faites lorsqu'il y a un truc qui ne marche pas, et de pouvoir faire des recherches d'expression régulières sans avoir à me poser la question sur l'endroit ou je pourrais éventuellement trouver un fichier qui contiendrait la valeur de conf qui potentiellement pourrait me poser problème.

      Maintenant dire que "Avoir de la conf dans /usr/lib ou /var/lib permet à l'administrateur de "savoir ce qu'il fait". Et en tout cas, ne pas modifier ces fichier, mais jouer sur de la surcharge via ce qui est dans /etc." c'est juste faux. Ca n'empeche rien de plus ni de moins que de mettre les fichiers dans un sous-répertoire de /etc. Parce qu'un admin incompétent ira modifier les fichiers de conf ne devant pas bouger, que ces fichiers soient dans /usr/lib ou /var/lib (j'ai déjà vu pour des unit systemd).

      Cela peut simplifier les mises à jour car il n'y a pas un jeu de ping pong entre la configuration de l'admin et la configuration livrée avec les logiciels qui peut être réinitialisée lors des mises à jour.

      Encore une fois, rien de plus ni de moins que d'avoir un endroit dédié dans /etc. Et je crois qu'on a pas attendu systemd pour faire des choses plutôt propres.

      • [^] # Re: différents répertoires

        Posté par  (site web personnel) . Évalué à 1 (+0/-0).

        [global-dns-domain-*]
        servers=8.8.8.8

        Mais… pourquoi ? Pourquoi un serveur DNS de Google ? Pourquoi ?

        • [^] # Re: différents répertoires

          Posté par  . Évalué à 3 (+1/-0).

          Parce que c'était le seul atteignable donnt je me souvenais au moment ou j'ai eu besoin de faire cette manip.

          Ce n'est pas prévu pour durer (les machines sont des VMs éphémères), mais si je dois garder un truc plus perenne, j'utiliserai autre chose.

          Au passage j'évite en général les DNS des FAI car à cause de la censure (abus de droits d'auteur tel qu'il existe en France), ils peuvent s'avérer être des DNS menteurs.

    • [^] # Re: différents répertoires

      Posté par  (site web personnel) . Évalué à 2 (+3/-2).

      on se demande bien pourquoi il faudrait vaguement respecter la FSH qui dit en gros que la conf est dans /etc, que /var continent les choses qui changent continuellement utilisées par les programmes et que ce qui est dans /usr devrait être read only.

      Soyons disruptifs ! Fight the war fuck the norm ! Embrace and extends !

      • [^] # Re: différents répertoires

        Posté par  (site web personnel) . Évalué à 10 (+11/-0).

        J’ai du mal à voir si ton message est sarcastique ou pas, parce que dans le cas de NetworkManager c’est vaguement respecté. La conf dans /usr est celle apportée par la distrib donc en RO, dans /var/lib/NetworkManager j’ai quasi-uniquement des trucs liés à DHCP donc dynamiques et dans /etc j’ai toute ma conf utilisateur.

        Oui c’est éclaté à pas mal d’endroits mais le tri est cohérent.

        • [^] # Re: différents répertoires

          Posté par  (site web personnel) . Évalué à 8 (+5/-0).

          Surtout que croire que la config n'est que dans /etc, c'est une erreur, une partie de la configuration est aussi dans le binaire d'un programme, donc dans /usr, vu qu'il y a une valeur et un comportement par défaut pour une grande majorité des logiciels.

          Donc en effet, avoir une configuration par défaut explicite et lisible à un endroit séparé de la configuration qu'on peut modifier résout quelque souci, notamment pour les mises à jour (si une valeur change, si une valeur est ajouté, etc). C'est une des choses que systemd a aidé à populariser, et je trouve ça bien de pouvoir ajouter des choses sans que tout explose si un chemin change, etc.

          • [^] # Re: différents répertoires

            Posté par  . Évalué à 3 (+2/-1). Dernière modification le 19 mars 2024 à 22:56.

            Surtout que croire que la config n'est que dans /etc, c'est une erreur, une partie de la configuration est aussi dans le binaire d'un programme, donc dans /usr, vu qu'il y a une valeur et un comportement par défaut pour une grande majorité des logiciels.

            C'est juste un raisonnement tordu non valable qui tente de détourner le fond du problème.

            Donc en effet, avoir une configuration par défaut explicite et lisible à un endroit séparé de la configuration qu'on peut modifier résout quelque souci, notamment pour les mises à jour

            Comme je l'ai dit, (et comme l'ont compris les personnes qui ont bien lu mes propos), ce n'est pas ça qui me gène.

            C'est une des choses que systemd a aidé à populariser,

            De mon point de vue, c'est une des idioties que systemd a popularisé, et c'est une des raisons pourl esquelles je n'aime pas systemd.

          • [^] # Re: différents répertoires

            Posté par  . Évalué à 4 (+3/-1).

            Freebsd faisait très bien la séparation avant systemd en mettant tout ce qui était conf par défaut dans /etc/defaults ( voir doc:

            One of the important aspects of FreeBSD is proper system configuration. This chapter explains much of the FreeBSD configuration process, including some of the parameters which can be set to tune a FreeBSD system.
            (…)
            FreeBSD base system configuration is located at the /etc directory, and the /usr/local/etc directory contains all the configuration files of the applications installed on the system through the ports collection and packages.
            (…)
            /etc/defaults Default system configuration files, see rc(8) for more information.
            ( …)
            The principal location for system configuration information is /etc/rc.conf.
            This file contains a wide range of configuration information and it is read at system startup to configure the system. It provides the configuration information for the rc* files.
            The entries in /etc/rc.conf override the default settings in /etc/defaults/rc.conf

            • [^] # Re: différents répertoires

              Posté par  (site web personnel) . Évalué à 2 (+3/-2).

              Oui mais FreeBSD n’est pas géré par les mêmes personnes que nos distributions Linux et tu peux toujours changer de crèmerie si l’arborescence de ton système te donne des boutons au quotidien (ça me dépasse).

              Ou bien tu peux essayer de retrouver un peu de curiosité technique pour tenter de comprendre les justifications des choix qui ont été faits par les logiciels dont tu sembles captif.

              Un peu d’ouverture permet non seulement d’être plus apaisé derrière son clavier (adieu le b****, les conneries et les idioties), mais également —Ô surprise— de devenir plus à l’aise avec les outils. J’ai par exemple en tête la commande systemctl cat qui permet de s’y retrouver dans les fichiers de configuration d’une unité systemd.

        • [^] # Re: différents répertoires

          Posté par  (site web personnel) . Évalué à 2 (+2/-1).

          dans le cas de NetworkManager c’est vaguement respecté

          C'était totalement sarcastique car au dessus il est dit :

          la configuration poussée par un paquet logiciel (donc, par ta distribution) est dans /var/lib ou /usr/lib

          J'ai du mal comprendre cette partie. J'ai cru comprendre qu'une partie de la conf était dans /var/lib et dans /usr/lib (ce qui se fait pour systemd par ex).

          Donc un non respect de la FHS, sauf a considérer que cette conf est une donnée du programme destinée à varier continuellement (comme les leases dhcp) ou une donnée qui devrait être partageable et en lecture seule (comme les manpages ou les fonts par ex).
          Après le respect de la FHS n'est pas un dogme, juste une proposition de bonne pratique d'uniformisation. Ça se discute et chacun fait ce qu'il veut dans son soft / sa distro. C'est juste qu'on repassera pour la soi disant uniformité/simplification des configs : c'est pas vraiment mieux qu'avant ~2005 ou on avait un gros yaourt sh dans /etc : maintenant on l'a dans tout le disque et dans 36 langages / formats et systèmes.

          Ça fait vieux con mais c'est factuel. Et puis je suis aigri suite à une mauvaise expérience avec l'usage de shadow services de systemd et leur non support des priorités pour intégrer un script rc sysV : merci RaspiOS.

          Note : le fait qu'il y ait aussi de la conf dans le binaire (comportement, option de compil etc, remonté par misc) relève plus du point de vue 'théorie sécurité paranoïaque' car dans ce cas tout le disque dur n'est que config (les données aussi peuvent potentiellement contenir de la conf ou induire un comportement). C'est tout à fait vrai mais bon, j'évite de mettre le pied dedans.

          • [^] # Re: différents répertoires

            Posté par  (site web personnel) . Évalué à 5 (+3/-0).

            J'ai du mal comprendre cette partie. J'ai cru comprendre qu'une partie de la conf était dans /var/lib et dans /usr/lib (ce qui se fait pour systemd par ex).

            Donc un non respect de la FHS, sauf a considérer que cette conf est une donnée du programme destinée à varier continuellement (comme les leases dhcp) ou une donnée qui devrait être partageable et en lecture seule (comme les manpages ou les fonts par ex).

            La configuration par défaut est dans /usr/lib.

            C'est une donnée qui est partageable entre plusieurs machines et en lecture seule.

            Elle n'a pas vocation à être modifiée autrement que par une mise à jour du paquet par le mainteneur de la distribution, comme le reste de /usr/lib.

            Pour moi ça respecte parfaitement la FHS.

            • [^] # Re: différents répertoires

              Posté par  . Évalué à 1 (+0/-0).

              Et c'est tres pratique, ça permet de gérer/diffuser ses propres paquets de conf depuis un dépot interne, tout en laissant l'admin local de la machine faire ses modifs dans /etc.

            • [^] # Re: différents répertoires

              Posté par  (site web personnel) . Évalué à 2 (+1/-0). Dernière modification le 21 mars 2024 à 14:47.

              Pour moi ça respecte parfaitement la FHS.

              Certes mais

              /usr/lib Libraries for the binaries in /usr/bin and /usr/sbin.

              On peut en effet considérer la conf par défaut comme une Library / asset, pourquoi pas.

              Pour ma part, dans ce cas, je l'aurais casé dans /usr/share mais bon.

              Edit :
              En relisant le thread je viens aussi de noter le

              tout ce qui ne doit pas survivre à un redémarrage dans /run

              J'imagine que l'auteur a voulu dire /tmp.

      • [^] # Re: différents répertoires

        Posté par  (site web personnel) . Évalué à 4 (+3/-2).

        /usr devrait être read only

        C'est dommage d'avoir le répertoire des utilisateurs en lecture seule !

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Répertoires /conf.d/

    Posté par  . Évalué à 5 (+2/-0). Dernière modification le 17 mars 2024 à 16:40.

    you can add additional .conf files to the /etc/NetworkManager/conf.d directory

    Debian le fait à outrance depuis des lustres, ce genre de configuration éclatée… C’est mieux quand on a une configuration complexe mais j’ai mis du temps à m’y habituer. Tu me rappelles que j’ai pas remis unbound sur ma nouvelle machine et qu’il faut que je le fasse. Là j’ai juste configuré ma box pour me pousser (via DHCP) les DNS que je veux.

    Ton journal est donc bienvenu. Chouette. Je serai psychologiquement préparé à une usine à gaz :) Je crois bien que je m’étais pris la tête il y a des années en installant ma précédente machine… Ceci dit, pas autant que la désactivation globale de Pulseaudio, là c’est le pompom…

    De ce que je comprends, tu as juste à créer un fichier de conf dans /etc/NetworkManager/conf.d, ajouter un fichier /etc/NetworkManager/conf.d/name.conf, ça évite tout écrasement ?

    • [^] # Re: Répertoires /conf.d/

      Posté par  . Évalué à 4 (+4/-2). Dernière modification le 17 mars 2024 à 20:37.

      you can add additional .conf files to the /etc/NetworkManager/conf.d directory

      C'est ce que j'ai fait. Ca ne me pose pas de problème dans ce cas : il s'agit d'une sous arborescence de /etc/NetworkManager, et on peut relativement facimement voir ce qui s'y passe sans avoir à chercher dans tous les coins du système pour savoir quelle valeur il y a dans le fichier par défaut. Séparer les confs en plusieurs fichiers ne me pose pas problème : c'est les endroits ou sont répartis les fichiers qui me gène.

      De ce que je comprends, tu as juste à créer un fichier de conf dans /etc/NetworkManager/conf.d, ajouter un fichier /etc/NetworkManager/conf.d/name.conf, ça évite tout écrasement ?

      C'est ce que j'ai fait (voir mon commentaire dans le fil précédent). Au final je m'en suis sorti, mais sur le principe je trouve que le fait d'éparpiller les confs comme le fait systemd ou NetworkManager est une grosse erreur et me pourrit ma vie d'admin au quotidien, surtout pour le diagnostic ou pour trouver l'inspiration pour créer un fichier de conf personnalisé par exemple.

      • [^] # Re: Répertoires /conf.d/

        Posté par  . Évalué à 7 (+5/-0).

        Perso j'aime beaucoup ce pattern (mais sans abuser bien sur). Pour moi ça a du sens dés que l'on a des fichiers de configuration un peu long.

        Tu n'as pas envie de te retrouver avec un conflit de apt lorsque tu change de version. La plupart du temps tu veux changer deux ou trois variables. En le faisant dans ton conf.d tu vois facilement ce que tu as changé et tu profite des bonnes pratiques par défaut de ta distribution.

        Je met même mes fichiers de conf dans un git dans /opt avec un lien symbolique dans /etc et ce pattern devient encore plus intéressant.

        J'ai découvert aussi avec systemd comment tu peux faire un systemd edit mon-service, qui crée (ici pour un service système) /etc/systemd/system/mon-service.service.d/override.conf qui te permet de changer des paramètres du service par défaut (et tu peux bien sur avoir plusieurs fichiers). Là aussi ça te permet de faire des variations tout en conservant tout ce le super travail fait par l'empaqueteur.

  • # En fait...

    Posté par  (Mastodon) . Évalué à 9 (+6/-0). Dernière modification le 18 mars 2024 à 15:28.

    …ce n'est pas compliqué mais il faut juste savoir lire.

    Ce que tu appelles éparpillement est compris par quelqu'un qui lit bien la manpage par organisation. C'est plus simple que de devoir reconcilier à chaque mise à jour des paquets la config par défaut du mainteneur par tes propres modifications. C'est aussi plus popre que des changements pas supposés survivre à un reboot qui écraseraient ta config dans /etc.

  • # Système D

    Posté par  . Évalué à 0 (+0/-0).

    J'ai eu le même problème y'a pas longtemps (changer de DNS).
    Du coup, NetworkManager utilise le resolver configuré dans systemd :
    /etc/systemd/resolved.conf

    Finalement, c'est comme resolv.conf

    • [^] # Re: Système D

      Posté par  . Évalué à 2 (+2/-0).

      Bon, en faite, faut quand même installer le paquet systemd-resolved (debian/ubuntu).

    • [^] # Re: Système D

      Posté par  . Évalué à 2 (+0/-0).

      je ne voulais pas du resolver systemd. D'ailleurs il n'était pas installé par défaut sous Rocky Linux 9.

  • # Network Manager CLI

    Posté par  . Évalué à 4 (+3/-0). Dernière modification le 19 mars 2024 à 07:54.

    Sinon le plus simple ça reste encore d'utiliser les fonctionnalités de NetworkManager…

    nmcli con modify <MaConnexion> ipv4.dns 8.8.8.8

    • [^] # Re: Network Manager CLI

      Posté par  (site web personnel) . Évalué à 2 (+1/-0).

      8.8.8.8

      Mais qu’est-ce que vous avez tous à vouloir choisir cette horreur ?

      • [^] # Re: Network Manager CLI

        Posté par  . Évalué à 0 (+0/-2). Dernière modification le 19 mars 2024 à 21:43.

        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8

        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8
        8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8 8.8.8.8

        Niark niark niark :D

      • [^] # Re: Network Manager CLI

        Posté par  . Évalué à 4 (+1/-0). Dernière modification le 22 mars 2024 à 19:09.

        Parce que c’est l’une des deux adresses de DNS de l’entreprise qui possède la maîtrise de 99% du Web, et qu’elle n’a même plus besoin de préciser qu’elle « Ne fera jamais de mal » tellement c’est une évidence pour tout un chacun, alors elle prend grand soin du DNS !

        La forme de cette adresse IP, particulière (4 chiffres identiques, et relativement bas qui plus est) m’avait intrigué quand j’ai appris son existence. Je trouve que la liste des adresses de classe A publiques, (aka le /8 de l’Internet), fournit une vision assez précise de « Qui est Internet ». C’est comme une sorte de trace qu’à laissé le développement d’Internet.

        En retrouvant le lien pour vous en faire part j’apprends quelque chose que j’ignorais (non sourcé donc sujet à caution, mais ça me semble vraisemblable) :

        As IPv4 address exhaustion has advanced to its final stages, some organizations, such as Stanford University, formerly using 36.0.0.0/8, have returned their allocated blocks (in this case to APNIC) to assist in the delay of the exhaustion date.

        D’ailleurs ça fait un moment que j’entends parler de la catastrophe de l’épuisement des adresses IPv4. Je constate que pour la France il n’y a encore qu’un seul FAI, Free, qui offre une connexion IPv6 (qui a des avantages qui ne se limitent pas à pallier le manque d’adresse), du moins au particulier.

        Ceci dit il me semble que le réseau mobile a depuis longtemps fait une entorse à IP en partageant chaque adresse, constatant que 65536 ports par adresse ça faisait beaucoup trop pour la grande majorité des usages.

        • [^] # Re: Network Manager CLI

          Posté par  (site web personnel) . Évalué à 3 (+1/-0).

          Il y a de l'ipv6 aussi au moins chez red (et du faux ipv4 comme sur mobile).

        • [^] # Re: Network Manager CLI

          Posté par  . Évalué à 1 (+0/-0). Dernière modification le 23 mars 2024 à 00:49.

          Je constate que pour la France il n’y a encore qu’un seul FAI, Free, qui offre une connexion IPv6 (qui a des avantages qui ne se limitent pas à pallier le manque d’adresse), du moins au particulier

          Je ne sais pas où tu as constaté ça, mais c'est faux.

          Edit: ah peut-être que tu pensais au fait qu'en effet à peu près tous les clients chez Free ont de l'IPv6. Mais par exemple Orange n'est pas loin derrière.

        • [^] # Re: Network Manager CLI

          Posté par  (site web personnel) . Évalué à 3 (+1/-0).

          Ceci dit il me semble que le réseau mobile a depuis longtemps fait une entorse à IP en partageant chaque adresse, constatant que 65536 ports par adresse ça faisait beaucoup trop pour la grande majorité des usages.

          Note que ça se fait aussi sur le réseau fixe, par exemple Free le fait depuis 2016

          Un LUG en Lorraine : https://enunclic-cappel.fr

    • [^] # Re: Network Manager CLI

      Posté par  . Évalué à 1 (+0/-1).

      Je ne voulais pas utiliser nmcli : je voulais que la conf apparaisse dans un fichier de conf. Plus facile de savoir comment c'est configuré pour quelqu'un qui ne maîtrise pas la syntaxe de nmcli, et surtout, dans l'absolu, je préfère un bon vieux fichier de conf à un outil qui garde en lui de manière opaque les informations de configuration.

      • [^] # Re: Network Manager CLI

        Posté par  (site web personnel) . Évalué à 6 (+3/-0).

        Euh tu sais que la configuration de NetworkManager que tu l'édites à la main, que tu utilises la GUI de GNOME ou nmcli cela revient au même ? Les fichiers sont stockés au même endroit et de la même façon, la conf est identique… Et heureusement, ce ne sont que des interfaces utilisateurs différents, le reste de l'outil est le même.

        • [^] # Re: Network Manager CLI

          Posté par  . Évalué à 3 (+1/-0).

          Tu veux dire que si j'utilise nmcli pour modifier la conf, il va l'écrire dans /etc/networkManager/conf.d ?

          • [^] # Re: Network Manager CLI

            Posté par  . Évalué à 4 (+2/-0). Dernière modification le 22 mars 2024 à 19:15.

            Avec une config faite par nmtui :

            more /etc/NetworkManager/system-connections/enp1s0.nmconnection 
[connection]
id=enp1s0
uuid=0d42b2eb-846b-4004-8730-55bcf89d81f7
type=ethernet
interface-name=enp1s0
timestamp=1710923349

[ethernet]

[ipv4]
dns=192.168.100.1;
method=auto

[ipv6]
addr-gen-mode=eui64
method=ignore

[proxy]

            cd /pub && more beer

            • [^] # Re: Network Manager CLI

              Posté par  . Évalué à 3 (+1/-0). Dernière modification le 23 mars 2024 à 16:59.

              Le problème c'est que dans ce cas tu lies la conf DNS à une interface réseau. Personnellement je voulais une solution qui me permettait d'avoir un DNS global, non lié à une interface ( pour le cas d'utilisation cité dans le journal initial, ce n'était pas absolument indispensable, mais c'est quelque chose que j'avais cherché à faire il y a quelques mois sans trouver donc j'en ai profité pour tenter à nouveau de le faire ).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.