Journal Network Manager et Ubuntu

Posté par  .
Étiquettes : aucune
0
10
avr.
2006
Vous le savez sûrement, dans dapper sera intégré l'application NetworkManager qui permet de gérer ses réseaux wifi.

Je viens de tester l'outils sur mon portable et plusieurs interrogations.

Premièrement, NetworkManager ne s'occupe que des connexions WIFI configurée en DHCP. Si vous voulez utiliser une connexion WPA en IP statique, alors NetworkManager ne fonctionnera pas, vous n'aurez pas l'applet gnome qui permet de visualiser la puissance du réseau et indique également si la connexion est bonne. Un peu déroutant. Car en plus vous devrez configurer votre connexion à la main.

Secondo, NetworkManager stocke votre passphrase dans le portefeuille des clés de gnome, que vous devez protéger par mot de passe. Donc, lorsque gnome démarre, il vous demande ce mot de passe. Le problème n'est pas qu'il vous demande un mot de passe mais plutôt que pendant ce temps, d'autres applications nécessitant le réseau démarre et donc ne fonctionne pas (gaim, météo...).

J'en viens alors à mes interrogations. Ce qui me gêne dans cet outils est que premièrement il ne supporte que le DHCP. Ce qui donne que si vous voulez utiliser une adresse IP statique, alors vous ne pouvez utiliser cet outil, et ne pourrez dans le même temps faire tourner l'applet gnome. Je pense que c'est assez déroutant pour un utilisateur d'avoir plusieurs outils selon la configuration réseau qu'ils veulent utiliser. De plus, je ne comprend pas pourquoi je ne pourrais pas avoir l'applet si j'utilise une ip statique, la puissance du signal, les réseaux à portée n'étant pas pour moi corrélés à la configuration IP.
De plus, ce qui me gêne dans cet outil est que c'est lui qui configure la connexion wifi, qui lance wpa_supplicant. Il rentre donc en conflit avec le système. A mon humble avis, les connexions réseaux doivent être gérées par les outils de la couche système (scripts de démarrage, fichier de configuration système de /etc) et non par un outil utilisateur qui stocke la conf je ne sais où. Cet outil devrait à mon sens demander au système d'utiliser telle configuration. Cela donne que lorsque je démarre mon ordinateur, le réseau est connecté en dernier, gaim ne pouvant se connecter. C'est assez gênant, et pas très user-friendly. (de plus sur mon portable personnel, /etc/init.d/networking met du temps à démarrer, comme s'il essayait de démarrer la connexion wifi qui ne peut fonctioner).

Qu'en pensez-vous ? avez-vous utilisé NetworkManager ?
  • # pb au niveau des applis réseau

    Posté par  . Évalué à 2.

    Je ne dis pas que c'est uniquement de leur faute, mais une appli réseau ne devrait pas râler (ou alors pas trop fort) si le réseau n'est pas disponible. Elle devrait attendre sagement qu'il le soit, et se connecter à ce moment sans rien demander à personne.
    • [^] # Re: pb au niveau des applis réseau

      Posté par  . Évalué à 8.

      moi ce qui me gêne plutôt c'est que normalement le réseau doit être configuré par /etc/init.d/networking, et non pas une autre application. Ainsi, tu peux intégrer d'autres outils/applis plus facilement car tu sais quand les choses sont faites.
      • [^] # Re: pb au niveau des applis réseau

        Posté par  . Évalué à 2.

        Ok. Mais je sais pas exactement ce que ça veut dire en fait... si tu arrives dans une gare et tu veux te connecter à son réseau wifi, en gros, tu fais quoi ?
        • [^] # Re: pb au niveau des applis réseau

          Posté par  . Évalué à 5.

          si tu arrives dans une gare et tu veux te connecter à son réseau wifi, en gros, tu fais quoi ?


          Typiquement :
          1. Tu demandes à ta carte réseau si elle a détecté des réseaux :
          bash-3.1# iwlist eth1 scanning
          eth1 Scan completed :
          Cell 01 - Address: 00:09:5B:AD:**:**
          ESSID:"****"
          Protocol:IEEE 802.11g
          Mode:Master
          Channel:11
          Encryption key:on
          Bit Rate:54 Mb/s
          Extra: Rates (Mb/s): 1 2 5.5 6 9 11 12 18 24 36 48 54
          Quality=65/100 Signal level=-61 dBm
          Extra: Last beacon: 37ms ago


          Ici, un réseau chiffré avec diffusion du ESSID est disponible (le mien).

          2. Si un ou plusieurs réseaux sont disponibles, soit :
          2.1 Les réseaux ne sont pas chiffrés : sous réserve que ta carte réseau soit paramétrée pour accepter n'importe quel ESSID (iwconfig ethX essid any), tu dois pouvoir t'associer aux réseaux en question.
          2.2 Les réseaux sont chiffrés :
          2.2.1 Tu possède la clef de chiffrement (pour faire simple, chiffrement en WEP) : tu configures ta carte réseau en indiquant le sésame magique (iwconfig ethX key xxx).
          2.2.2 Tu ne possèdes pas la clef :
          2.2.2.1 Tu dois attendre ton train : tu utilises des logiciels de cassage des clefs (il y en a plusieurs, aircrack est le plus connu).
          2.2.2.2 Tu n'as pas le temps ou tu as des scrupules : /sbin/shutdown -h now
  • # Ch'uis d'accord

    Posté par  . Évalué à 2.

    Je suis assez d'accord avec toi, j'ai testé et effectivement c'est pas des plus pratique. Un autre point qui me chiffonne, est qu'il faille lancer une session utilisateur pour avoir le réseau : pour un PC portable c'est peu génant, car il ne reste pas longtemps avec le *dm, et donc assez rapidement il est connecté, mais pour une machine moins nomade, on peut trés bien imaginer qu'elle reste connectée sans session utilisateur, et là NetworkManager me semble peu adapté - à moins que je sois passé a coté de quelque chose...
    • [^] # Re: Ch'uis d'accord

      Posté par  (site web personnel) . Évalué à 9.

      Dans la TODO list on trouve des trucs genre "faire un démon qui permette de se connecter à des réseaux favoris au démarrage", bref c'est encore très beta.

      Par contre cet outil est absolument indispensable. Pour moi c'est le genre de truc qui peut retenir sous Windows avec les jeux par exemple. Visiblement sur linuxfr on n'imagine pas à quel point se faire son propre script de roaming avec wpa_supplicant et ifuppasdownalorsfaiskekchose ça n'est PAS une solution pour les gens (les vrai, là-bas dehors).
      • [^] # Re: Ch'uis d'accord

        Posté par  . Évalué à 1.

        Par contre cet outil est absolument indispensable. Pour moi c'est le genre de truc qui peut retenir sous Windows avec les jeux par exemple.
        Mais on est tous d'accord avec toi, il nous faut un outil de gestion des connexions WIFI.

        Visiblement sur linuxfr on n'imagine pas à quel point se faire son propre script de roaming avec wpa_supplicant et ifuppasdownalorsfaiskekchose ça n'est PAS une solution pour les gens (les vrai, là-bas dehors).
        Mais là tu aurais pu t'abstenir; les clichés du genre "moi je sais, vous, vous ne savez pas" ce n'est pas très constructif !

        On essaye ici d'avoir une discution autour de NetworkManager pour savoir si cet outil correspond aux attentes de tous, et s'il est correctement fait. Pour ma part, je ne le trouve pas très user-friendly car il t'impose d'utiliser une configuration IP spécifique, et qu'il démarre la connexion wifi lui-même au lieu de configurer le système pour le faire. Pour toi il est indispensable parce qu'il correspond à tes besoins propres. Sauf que tes besoins ne sont pas les besoins de tous, si on ne couvre qu'une partie des multiples configurations wifi pouvant exister, on risque de voir naître une multitude d'outil...
      • [^] # Re: Ch'uis d'accord

        Posté par  . Évalué à 1.

        bref c'est encore très beta.

        Je savez bien que j'étais passé à coté de qqe chose... Bon, donc dans un futur proche, ça devrait fonctionner correctement. Comme d'hab. ;-)
  • # Peut être...

    Posté par  . Évalué à 2.

    Peut être faire un rapport de bug. C'est une béta...
    • [^] # Re: Peut être...

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      http://bugzilla.gnome.org/show_bug.cgi?id=331529

      Mais j'admet que je ne pige pas pourquoi network manager n'utilise pas ifconfig et sa clique... c'est vraiment dommage.

      Je suis vraiment pas convaincu jusqu'à présent.

      Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Peut être...

      Posté par  . Évalué à 6.

      J'ai fait un rapport de bug pour le problème de gaim, et la réponse qui m'a été donnée est de ne pas activer la connexion automatique de gaim !

      J'ai fait un rapport de bug pour le problème du dhcp (et je n'étais pas le premier), mais la réponse est que NM ne supporte que DHCP.
  • # Test sous Gentoo et pessimisme ordinaire

    Posté par  . Évalué à 4.

    Perso, j'avais testé un peu la bête il y a qlqs temps (0.6.0 à l'époque je crois) sous Gentoo. J'ai été pas mal déçu. Ce qui m'intérressait avant tout, c'était l'aspect monitoring de la chose (la petite applet pour faire joli, mais surtout l'emmission de messages sur le DBUS quand l'état des interfaces change). Seulement voilà, c'est vraiment du tout en un, et on ne peut pas utiliser une partie du système sans lui confier intégralement la gestion du réseau.

    Qu'à celà ne tienne, j'ai essayé de le laisser faire pour voir... Mais là je suis comme toi rebuté par les limitations du système, dont sa stricte dépendance sur un DHCP. Entre ce machin automatique et obscure, qui ne marche que pour les cas simples, et la méthode Gentoo standard, qui marche tout aussi simplement dans les les même cas mais qui sait aussi gérer toutes les situations plus particulières¹, mon choix est vite fait, et je l'ai viré.

    Bref mon impression est que NetworkManager ne peut/veut pas en faire autant que les scripts standards des distribs (côté simpliste de la chose), mais que en même temps il ne peut pas s'y intégrer non plus (côté tout-en-un de la chose). Et je ne crois pas être le seul à l'avoir eu cette impression, je me souviens par exemple de commentaires peu enthousiastes d'un dev de Mandriva².

    Du coup, je suis curieux de voir quelle sera vraiment l'adoption de ce système par les distribs : je vois très mal nombre d'entre elles switcher vers un système de gestion réseau qui consituerait une régression, et je ne suis pas sûre non plus qu'elles aient toutes envie de supporter deux systèmes distincts et incompatibles en parallèle.

    Btw, qlq'un sait ce que va faire Kubuntu ? Est-ce que des interfaces à NetworkManager existent pour KDE ?

    ¹ si il y a des curieux qui veulent se faire une idée de la gestion du réseau sous Gentoo, je les laisse regarder les fichiers de config d'exemple :
    http://sources.gentoo.org/viewcvs.py/baselayout/trunk/net-sc(...)
    ...Sachant qu'il ne faut pas se laisser impressioner par la longueur de ces fichiers : pour une utilisation de base similaire à ce que sait faire NetworkManager, y'a besoin de zero ligne de config pour l'ethernet, et d'une par clef pour le wifi. Le reste, c'est pour s'écarter de ce sentier battu.

    ² http://mail.gnome.org/archives/networkmanager-list/2005-July(...)
    Bon ça date un peu ceci dit, et je ne sais pas si leur point de vue a évolué depuis. Des gens au courant dans le coin ?
    • [^] # Re: Test sous Gentoo et pessimisme ordinaire

      Posté par  . Évalué à 2.

      Ce que je sais c'est que network-manager, network-manager-kde et network-manager-gnome sont disponibles sous dapper flight 6. J'ai essayé network-manager-gnome mais pas kde, donc je ne peux te répondre que partiellement.
    • [^] # Re: Test sous Gentoo et pessimisme ordinaire

      Posté par  . Évalué à 2.

      Btw, qlq'un sait ce que va faire Kubuntu ? Est-ce que des interfaces à NetworkManager existent pour KDE ?

      D'après ce que j'ai compris, pour kubuntu, ce sera knetworkmanager (une interface à networkmanager) qui sera intégré. A voir...
  • # Ethernet

    Posté par  (site web personnel) . Évalué à 3.

    Je n'ai pas de wifi mais networkmanager s'est occupé sans problème de mon reseau ethernet en dhcp sur la dernière flight de Dapper drake.
    Ca fait quand même bien fenêtres-style l'applet reseau... Autant pour du wifi ca me parait très utile mais pour un reseau filaire je vois mal l'utilité (d'autant plus qu'on considère l'utilisateur peu avancé avec ce genre d'outils, donc je vois mal l'utilité de lui annoncer que son ordi s'est vu attribuer telle ip etc)

    Après c'est sur on peut avoir un portable qui utilise du wifi + de lethernet de temps en temps, bref, un developpement à suivre je pense.
    • [^] # Re: Ethernet

      Posté par  . Évalué à 2.

      Sous Ubuntu, NetworkManager ne fonctionne que pour les interfaces configurées en dhcp, il faut donc les lignes suivantes dans /etc/network/interfaces :

      auto wlan0
      iface wlan0 inet dhcp

      J'ai sur mon portable également un interface eth0 mais elle n'apparaît pas sous NetworkManager... bizarre...
      • [^] # Re: Ethernet

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        nan, NM ne fonctionne que pour les interfaces non configurées dans /etc/network/interfaces.

        Supprime les lignes qui parlent de wlan0 ou eth0 et elles apparaitront dans NM

        Mes livres CC By-SA : https://ploum.net/livres.html

        • [^] # Re: Ethernet

          Posté par  . Évalué à 2.

          ou plutôt NM fonctionne pour les interfaces non configurées ou configurées comme je l'ai dit. Et c'est bien là mon problème, si je configure mon interface NM fonctionne mais /etc/init.d/networking échoue. Donc si je l'enlève tout devrait aller comme il faut...

          NM remplace donc l'outil de configuration réseau de gnome, et n'est donc pas un outil supplémentaire dans le cas d'une configuration DHCP.

          C'est ce que j'en conclus.
    • [^] # Re: Ethernet

      Posté par  . Évalué à 1.

      > Après c'est sur on peut avoir un portable qui utilise du wifi + de
      > lethernet de temps en temps

      Ouais enfin, ça rend pas NM nécessaire pour autant. C'est mon cas ici, et les scripts réseaux (via ifplugd/netplug, wpa_machin, etc.) s'occupent tous seuls de switcher entre ethernet et wifi selon ce qui est accessible (avec priorité pour l'ethernet). Dans ce contexte, l'applet, si besoin d'une applet il y a, elle peut être passive (purement informative, juste pour faire joli).
  • # moi

    Posté par  (site web personnel) . Évalué à 2.

    Bon pour parler de mon expérience : je suis sous dapper et je ne suis pas du tout un utilisateur expert.
    Pour moi, dans mon cadre particulier d'utilisation, networkmanager est une bonne appli. Je branche ma freebox, je renseigne ma passphrase WPA et roulez jeunesse ! ça marche !
    Peut-être que dans d'autres cas de réseaux plus complexes networkmanager n'est pas assez bien mais pour une utilisation de base comme la mienne (DHCP) c'est très appréciable et très ergonomique de ne pas devoir se taper des configs ésotériques.

    PS : c'est vrai que c'est chiant de sortir son password de login PUIS de devoir en plus sortir son password du trousseau de clé. Pourquoi c'est pas intégré ? pourquoi faut-il deux passwords ?
    • [^] # Re: moi

      Posté par  . Évalué à 2.

      Le password de login est renseigné au login manager, application lancée en root, qui va ouvrir une session utilisateur.

      Le password du trousseau te sert à décrypter le contenu de ton trousseau, via et pour les applications utilisateur. Le trousseau est, je le répète, *crypté*, et est donc illisible sans clé pour tout le monde (y compris root). Ceci permet d'avoir une certaine confidentialité dans un environnement où l'on n'est pas soi-même l'administrateur du système.

      Si tu es admin et seul utilisateur de ta machine, tu peux plus ou moins résoudre le problème du "double login" en choisissant d'être loggué automatiquement sur ton compte utilisateur sans demande de password (pas très secure, mais pourquoi pas).

      Cela dit, si tu es le seul utilisateur de ta machine, tu n'as pas forcément besoin de crypter ton trousseau de clés (sauf si tu penses qu'on peut s'introduire frauduleusement sur ton système), et tu peux donc choisir un mot de passe vide (en tout cas, c'est possible avec le kwallet de KDE).

      Revenons au problème initial : si on veut ni login automatique, ni password vide pour le trousseau, peut-on imaginer un système où le fait de se logguer "libère" la clé de déchiffrement du trousseau ?
      Je ne dis pas que c'est impossible (il faudrait un peu d'imagination pour trouver un protocole sécurisé), mais dans l'état des choses, pour faire cela, il faudrait que le login manager (processus root) puisse d'une certaine manière transmettre la clé au gestionnaire de trousseau, ce qui veut dire que root aurait moyen de connaître la clé de déchiffrement du trousseau, et donc toutes les clés stockées dans le trousseau. Bref, ce n'est pas gagné.
      • [^] # Re: moi

        Posté par  . Évalué à 2.

        tu ne peux pas mettre de mot de passe vide dans le wallet de gnome. J'ai essayé, il refuse.
      • [^] # Re: moi

        Posté par  . Évalué à 4.

        > il faudrait que le login manager (processus root) puisse d'une
        > certaine manière transmettre la clé au gestionnaire de trousseau

        J'ai croisé ton message, mais oui, c'est exactement comme ça que fonctionne le module PAM que j'ai cité plus bas. Par contre, par rapport à ce que tu décris après, la clef transmise est le mot de passe de login, et pas une autre. Ça peut être vu comme une limitation, mais ça évite d'avoir à stocker cette clef ailleurs, ce qui serait déjà plus délicat niveau sécurité.

        > ce qui veut dire que root aurait moyen de connaître la clé de
        > déchiffrement du trousseau

        Bof, ça c'est de toute façon le cas. Rien n'empêche le root de, par exemple, patcher gnome-keyring pour logguer les mots de passe. Je crois que de manière générale, il faut soit faire confiance à son root, soit ne pas toucher à la machine.
        • [^] # Re: moi

          Posté par  . Évalué à 2.

          > Bof, ça c'est de toute façon le cas. Rien n'empêche le root de, par
          > exemple, patcher gnome-keyring pour logguer les mots de passe. Je
          > crois que de manière générale, il faut soit faire confiance à son root,
          > soit ne pas toucher à la machine.

          Je pense qu'effectivement, on n'a pas trop le choix, à moins d'être carrément parano, et de stocker son trousseau de clés sur une "clé" USB... et encore. Non, de toute manière, le root peut changer n'importe quel morceau de programme de l'OS ou autre. Si on n'a pas confiance dans le root, on ne peut pas avoir confiance dans la machine sur laquelle on travaille.

          Bref, l'utilisation actuelle des différents wallets est bancale. Et ta solution avec le module pour PAM me semble la voie à explorer (sauf pour les trousseaux non cryptés).
      • [^] # Re: moi

        Posté par  (site web personnel) . Évalué à 3.

        >> Le password de login est renseigné au login manager, application lancée en root, qui va ouvrir une session utilisateur.

        heuuu....je pige pas trop là !
        C'est bien mon password de user que je renseigne dans la fenêtre non ? donc c'est bien moi, le user patrick_g, qui me connecte sur mon laptop. Donc pourquoi me demander à nouveau le password du trousseau ? A quoi sert ce trousseau puisque je suis protégé par mon password de user ? Si c'est une protection contre le root, outre le fait que je suis le seul utilisateur, elle est de toute façon illusoire !

        Ce que je constate c'est que je me fais chier quand je me connecte :
        1) login + user password
        2) password du trousseau
        3) re-password du user pour apt-get des maj de sécu !

        Je ne veux pas d'autologin car ce n'est pas sécurisé mais là c'est un poil trop....
        • [^] # Re: moi

          Posté par  . Évalué à 3.

          Théoriquement il n'y a que toi qui peut lire ton trousseau, même non crypté.

          Seulement :
          1 - root peut lire ton trousseau (mais comme dit plus haut, si on n'a pas confiance en root... )
          2 - si les droits en lecture ne sont pas limités à ton compte utilisateur, c'est embêtant
          3 - si ton système se fait infiltrer et que quelqu'un gagne les droits de ton compte utilisateur, tu te fais prendre tes password
          4 - si tu es dans un environnement physique non sûr (situation très courante !), quelqu'un pourrait profiter de ton compte et de tes passwords. D'où l'intérêt de crypter, d'où l'intérêt du gestionnaire de trousseau, où des options permettent que le trousseau se ferme, soit après chaque utilisation, soit après une certaine période de temps. Tu peux aussi gérer l'accès au trousseau appli par appli.

          Maintenant si tu es dans une situation où ça ne te dérange pas que ton trousseau soit ouvert une bonne fois pour toutes, la solution avec le module de PAM m'a l'air pas mal.

          >> 3) re-password du user pour apt-get des maj de sécu !
          Je ne suis ni débianeux ni ubunteux, mais ce ne serait pas plutôt le password du root qu'on te demande, là ?

          J'ai cru entendre qu'Ubuntu avait une manière assez spéciale de gérer le root... ça a peut-être un rapport ?
          • [^] # Re: moi

            Posté par  (site web personnel) . Évalué à 2.

            Pour on 3)
            Ubuntu utilise sudo, et sudo demande bien le mot de passe de l'utilisateur pour lancer un programme avec les droits root.
            (l'utilisateur en question doit être inscrit dans la liste des sudoers, editable avec visudo, pour avoir le droit d'utiliser sudo)
        • [^] # Re: moi

          Posté par  . Évalué à 1.

          Si j'osai je dirai que le wallet gnome est un beau raté...

          Juste après le login on se voit demander un mot de passe pour dévérouiller le trousseau déjà ça lasse.

          Si on a eu le malheur de vouloir utiliser gnomevfs pour se connecter à des serveurs réseaux on se voit demander par le trousseau tout un tas d'autorisations qui parfois ne sont même pas mémorisées. Je suppose que l'autorisation est demandée pour que l'application puisse parcourir le réseau mais bon... pourquoi diable dois je autoriser au lancement de l'application et non au moment où je cherche à parcourir le dit réseau ? Soundjuicer qui veut que je déverrouille mon trousseau je trouve ça idiot (surtout qu'il le redemande à chaque fois, toujours autoriser ne fonctionnant pas).

          Avez vous déjà essayé de refuser de donner l'autorisation à une application ? Ben donnez la, vous gagnerez du temps, il insiste le bougre... En gros de toute façon vous finirez par autoriser toutes vos applications à l'utiliser sans même prendre la peine de lire quel programme le demande, donc la sécurité...
    • [^] # Re: moi

      Posté par  . Évalué à 2.

      > PS : c'est vrai que c'est chiant de sortir son password de login PUIS
      > de devoir en plus sortir son password du trousseau de clé. Pourquoi
      > c'est pas intégré ? pourquoi faut-il deux passwords ?

      En tout cas, techniquement, le comportement que tu souhaites est possible à obtenir, via un module PAM :
      http://www.hekanetworks.com/index.php/publisher/articleview/(...)
      Il faut évidemment que le password de gnome-keyring soit le même que celui de login (enfin, tout ça est expliqué sur la page en question).
      Et par contre il faut une version super récente de PAM (0.99), donc c'est plus à titre informatif que je le mentionne, parceque ça ne marchera pas sous Dapper (0.79).
      Ni sous Gentoo d'ailleurs (0.78) :-/
  • # NetworkManager vs Net_Applet

    Posté par  (site web personnel) . Évalué à 2.

    Le support WPA était une des raisons qui avait motivé Mandriva pour développer son propre outil plutôt que d'utiliser NetworkManger ( http://qa.mandriva.com/twiki/bin/view/Main/NetworkManagerCri(...) ). Par contre je ne savais pas que NetworkManager ne gérait pas les connexions statiques vue que Net_Applet le gère.

    Cependant au vue du développement très rapide de NetworkManager, je pense que tous ces problèmes seront réglés très prochainement. De plus il ne faut pas oublier qu'il y a le support VPN et WPA entreprise ( avec certificats ) dans NetworkManager. La meilleure solution est de faire des rapports de bugs dans ce genre de situations.

    http://qa.mandriva.com/twiki/bin/view/Main/NetApplet
    http://qa.mandriva.com/twiki/bin/view/Main/NetApplet2007Prop(...)

Suivre le flux des commentaires

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