Nanal,
http://blog.ngas.ch/ nous gratifie (l'entrée a quelques mois, mais je me réveille maintenant) d'une réflexion sur l'évolution des technologies dans l'écosystème GNU/Linux. Ça se passe ici (en anglais).
En résumé et en prenant la liberté de reformuler un peu violemment, la tendance à vouloir rendre GNU/Linux prêt pour le desktop conduit à s'enfermer dans des technologies qui posent plus de problèmes qu'elles n'en résolvent. L'auteur cite pour appuyer son propos, principalement bien évidemment tous les logiciels que Lennart à pondu (ouai bon on n'est pas encore vendredi mais ça vient à grand pas), et aussi NetworkManager sur lequel il s'étend un peu plus sur ses dommages collatéraux. Il nous dresse un portrait qui est franchement bien plus effrayant d'un point de vue technique que Windows, et qui affecte aussi indirectement les systèmes qu'on pourrait espérer épargnés, tels que les BSD.
Voilà allez lire le post d'origine (si besoin à travers un service de traduction auto), qui est bien moins trollifère et bien plus intéressant que mon pauvre journal.
Braha.
# Ça sent le réchauffé…
Posté par Renault (site web personnel) . Évalué à 10.
C'est un troll assez récurrent et je trouve assez mal analysé que je mettrais volontiers sur le dos du « c'était mieux avant ».
Le travail de Lennart en est l'exemple typique souvent discutée ici. Oui les technologies de Lennart ne sont pas parfaits et ont eu des débuts difficiles (comme de très nombreux projets, comme KDE 4 longuement décriée alors que aujourd'hui la situation est bonne voire excellente).
Cependant, personne n'a forcé l'adoption de ses technologies, et si ça a été fait, c'est bien qu'il y avait des avantages pas forcément visibles au quotidien mais très utiles ailleurs. Puis aujourd'hui je doute que PulseAudio, systemd et autres soient si gênants sauf cas assez particuliers…
Ensuite, le coup de *BSD qui est victime de la linuxification des applications. À dire vrai, je n'ai jamais compris en quoi Unix et POSIX imposaient une compatibilité parfaite entre les différentes branches, ce n'est mentionné nul part et je pense que cela est nuisible. Après tout, si *BSD et Linux sont pareils, à quoi sert la différence ? *BSD n'est pas un Unix avec juste un noyau BSD et GNU/Linux un Unix avec un noyau Linux, sinon ça serait inutile (qui veut d'un OS qui ne diffère que du noyau par rapport au voisin ?), il y a un écosystème derrière, une philosophie, des avantages et inconvénients dans les choix effectués. Pour que tout cela ait un sens, il faut que les applications critiques se focalisent non pas sur la portabilité mais sur la performance et l'homogénéité.
Ce que je veux dire, c'est que POSIX c'est une base pour faciliter les transferts d'applications entre différents Unix notamment, cependant il y a des secteurs non concerné par la norme, et d'autres où c'est moins gênant. Prenons le cas du démarrage, c'est une étape qui dépend énormément du noyau et de ce qu'il fait en interne, il est donc je pense logique de faire une application propre pour chaque noyau pour bénéficier au mieux de ses capacités. Par contre les commandes shell comme rm, mv et autres sont indépendants du noyau en soit, ce qui rend la compatibilité pour ces commandes utiles.
Après tout, on dit souvent que Apple fait des produits propres, car ils maitrisent tous le processus de développement et font des intégrations fortes entre les différentes composants, car cela bénéficie des avantages de chacun. Si on se limite au plus petit dénominateur commun à chaque fois pour une portabilité (pas forcément utile dans ces cas là), ça limite drastiquement les possibilités. À quoi sert un noyau avec des différences de *BSD (donnant des avantages au premier sur le dernier et inversement), si on ne peut pas les exploiter par peur de brusquer la communauté ?
Je ne suis donc pas d'accord avec la compatibilité à tout prix que semblent vouloir les *BSD, car cela est non seulement illusoire mais aussi néfaste à la diversité des programmes et aux développements d'OS différenciés et puissants au profit d'OS moyens mais compatibles (rendant redondant les autres…).
Et je trouve pour l'instant que cette linuxification touche les couches concernés par le noyau de manière assez forte (donnant un intérêt à faire dans son coin, la compatibilité étant utile pour les couches plus hautes et indépendantes du noyau). Typiquement PulseAudio et systemd entrent dans ce cadre.
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 8.
Puis aujourd'hui je doute que PulseAudio, systemd et autres soient si gênants sauf cas assez particuliers…
Pareil que IE 6. Ça ne gênait absolument pas les utilisateurs, sauf cas assez particulier d'un ou deux sites(par ailleurs totalement oubliable pour les dits utilisateurs)
Prenons le cas du démarrage, c'est une étape qui dépend énormément du noyau et de ce qu'il fait en interne
Pas trop non. Enfin dans la mesure ou le noyau respecte les normes POSIX, le démarrage peut être accompli de moult façons différentes. La plupart des scripts écrits en SystemV fonctionnent sur plusieurs Unix différents, avec parfois un renommage de périph ici ou là.
il est donc je pense logique de faire une application propre pour chaque noyau pour bénéficier au mieux de ses capacités
C'est tellement logique que personne ne le fait. La plupart des scripts de démarrage fonctionnent très bien même si tu changes ton noyau. Encore qu'avec DBus/hald et autres network manager on se rapproche dangereusement du moment ou mise à jour du noyau = mise à jour de l'init. Ce qui serait une vraie catastrophe.
Par contre les commandes shell comme rm, mv et autres sont indépendants du noyau en soit, ce qui rend la compatibilité pour ces commandes utiles.
Le problème est justement des commandes shell, comme route, ifconfig, dhcpcd qui ont un comportement bizarre quand il y a network manager derrière.
À quoi sert un noyau avec des différences de *BSD (donnant des avantages au premier sur le dernier et inversement), si on ne peut pas les exploiter par peur de brusquer la communauté ?
Personne ne t'interdit de les utiliser. C'est juste qu'il y a des personnes qui veulent ne pas les utiliser. Pour des raisons diverses. La compatibilité est une des raisons, la stabilité du système (au niveau API), la prédictibilité, la flexibilité, la maintenance en sont d'autres. Honnêtement avec des API qui changent en permanence (DBus, HAL, Alsa) des daemons qui viennent casser des comportements séculaire d'UNIX sans rien apporter de fondamental, juste un peu de confort pour l'utilisateur et une absence récurrente de doc, on a clairement pas envie de sortir des clous et d'adapter l'OS à son besoin. Or c'est supposé être ça la force de Linux.
Et je trouve pour l'instant que cette linuxification touche les couches concernés par le noyau de manière assez forte (donnant un intérêt à faire dans son coin, la compatibilité étant utile pour les couches plus hautes et indépendantes du noyau). Typiquement PulseAudio et systemd entrent dans ce cadre.
Pour info PulseAudio est userland et SystemD va chatouiller le hardware. Donc dire qu'ils sont tous les deux dans le même cas c'est un poil contradictoire.
Je ne suis donc pas d'accord avec la compatibilité à tout prix que semblent vouloir les *BSD
Les *BSD ne veulent pas la compatibilité à tout prix,
- OpenBSD en a rien à battre
- NetBSD pleure un peu parcequ'ils n'ont pas la dev team assez fournie pour patcher l'ensemble de leurs ports assez vite pour mettre à jour si la compatibilité est cassée dans de telles proportions, donc ils essayent de coder des wrappings dans tous les sens pour permettre une certaine compatibilité. Mais vu la vitesse des changements des API et l'état de la doc c'est pas gagné.
- FreeBSD a déjà pris les devant et commence lentement (mais surement) à foutre dehors le GNU. Je pense que FreeBSD 11 ou 12 fonctionnera très bien sans GCC et les outils GNU.
Maintenant le problème c'est pas les *BSD, qui ont clairement l'habitude que la communauté Linux leur crache à la gueule (clause de publicité, accelerateurs TCP, scheduler, Pilotes wifi etc. ) c'est Linux tout seul. Je pense être relativement balèze en Linux/Unix Like et je n'arrive plus sous les dernières versions de Linux
- A créer des devices ou des pseudo devices persistant
- A configurer X11 comme je veux
- A faire des config réseau conditionelles
- A capter des events systèmes et à leurs associer des règles qui seront systématiquement respectés (mention spéciale au branchement de périph de stockage type clef USB)
Aujourd'hui c'est plus facile de faire des switchs de route entre différents alias de cartes réseaux sous Windows 7 que sous Linux avec network manager. Si ça ne vous inquiète pas, tant mieux.
[^] # Re: Ça sent le réchauffé…
Posté par totof2000 . Évalué à 9.
OUF! Je me sens moins seul ... Mais d'un autre côté, ça m'inquiète.
[^] # Re: Ça sent le réchauffé…
Posté par Renault (site web personnel) . Évalué à -2.
Sauf uqe PulseAudio peut être remplacée par Alsa à ta guise, certains le font d'ailleurs. Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6.
Oui, mais tu perds ici nettement les avantages que le noyau peut te procurer derrière au profit de la portabilité, et la portabilité d'init est à mon sens pas hyper utile… De plus systemd garde cette compatibilité pour ceux qui le souhaitent, la vie n'est-elle pas merveilleuse ?
Donc il n'existe aucun composant qui est uniquement afit pour *BSD ou Linux (en terme de noyau), car elle dépend de ses fonctionnalités ? C'est faux, et ça tend à le devenir de plus en plus pour certaines couches basses.
En quoi cela serait une catastrophe ? Tu aimes avoir des noyaux et autres composants basses sous-exploiter pour une compatibilité parfaite comme actuellement ? J'aime la compatibilité, mais avoir Linux et *BSD pour ne pas pouvoir les différencier pour avoir de la portabilité partout, c'est inutile, autant n'avoir qu'un noyau et OS et ne faire que des distributions.
Cela permet aussi une remise en uqestion de l'organisation précédente. On critique beaucoup x86, Windows et autres produits de l'informatique industriels car ils cumulent des défauts depuis des décennies pour ne pas briser la compatibilité ascendante. Cette composante est importante bien évidemment, mais parfois il faut savoir remettre en question les choses quand elles ne sont pas bonnes. L'informatique est un domaine en pleine évolution, passer à côté de ses dernières trouvailles juste pour ne pas briser les API peut être gênant…
Mêmes cas non, proches oui. Car que ce soit userland ou pas, l'interaction avec le noyau de ces programmes est plus important que pour Firefox par exemple, normal ce sont des composantes basses du système.
Pourquoi alors les utilisateurs de *BSD pleurent de la linuxification de certaines parties du système ?
J'ai de gros odutes uqe cela soit à sens unique tu vois… Je ne négligerais les torts d'aucun des deux partis.
Pour avoir tester, non. NetworkManager n'est pas parfait non plus mais ça fonctionne malgré tout assez bien, et là encore, tu peux t'en priver si tu veux (en perdant certains des avantages vis à vis de son intégration dans d'autres applications, ne serait-ce pour la détection du mode connecté/déconnecté).
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 9.
Sauf que PulseAudio peut être remplacée par Alsa à ta guise, certains le font d'ailleurs. Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6.
Déjà des programmes commencent à réclamer absolument Pulse Audio, ensuite il y a des incompatibilité et des différences entre l'API Alsa pure et l'API Alsa exposée par Pulseaudio. Donc non pour la première partie de ta phrase
Puis PulseAudio est libre et non obsolète, donc si défaut il y a rien, rien à voir avec le cas de IE6
Pulse Audio est (mal) documenté, ne gère pas les rendus de la même façon d'une machine à l'autre et casse pas mal de fonctionnalités de son avancés pour simplifier les fonctionnalités de base. Effectivement on n'avait pas accès au code d'IE 6 mais au moins les spécificités et les "quirks" d'IE 6 étaient connu et documentés (même si présentés comme des features... Un grand classique). Donc non pas tant de différence entre Pulse Audio aujourd'hui et IE 6 il y a 5 ans.
Oui, mais tu perds ici nettement les avantages que le noyau peut te procurer derrière au profit de la portabilité
Non. L'init n'a rien à voir avec le comportement du noyau. La compatibilité ne fait perdre qu'une seule chose : de la vitesse de boot, donc du pur confort. Rien n'empêchera ton appli après d'utiliser les spécificité du noyau, rien n'empêchera tes pseudo-devices de se créer ou tes droits de descendre. SystemD nef ait que deux choses :
a) accélérer le boot (éventuellement)
b) foutre un boxon de tous les diables dans la hiérarchie des devices et des dossiers systèmes.
De plus systemd garde cette compatibilité pour ceux qui le souhaitent, la vie n'est-elle pas merveilleuse ?
Sauf que c'est juste pour amorcer la pompe, avec derrière l'intention avouée de forcer la normalisation des hierarchies devices/folders pour éviter les scripts à rallonge. Donc à terme des Linux qui ne peuvent booter qu'avec SystemD ou des init qui émulent le comportement des SystemD.
Donc il n'existe aucun composant qui est uniquement afit pour *BSD ou Linux
Bien sur que si, mais ca ne sert à rien pendant l'init. Les noyaux sont très différents, avec des fonctionnalités spécifiques dans les deux cas, mais les API nécessaires à l'init sont les mêmes (et ces API sont très réduites). SystemD et consors ne changeront rien à cela (enfin j'espère, sinon c'est encore pire que ce que je pense).
En quoi cela serait une catastrophe ? Tu aimes avoir des noyaux et autres composants basses sous-exploiter pour une compatibilité parfaite comme actuellement ?
Ok tu ne sais pas de quoi tu parles. On parle des scripts qui attribuent une IP à ta carte réseau et qui lancent le démon apache là. Rien à voir avec les fonctionnalités des couches basses/moyennes/haute du noyau. Il s'agit juste des interfaces qui permettent de lancer un processus, de le daemoniser et de le rattacher à un user ou à un autre processus. Eventuellement de créer un device ou un container de sécurité (et encore c'est vraiment mieux quand c'est fait par le processus lui même plutôt que par le mécanisme d'init).
Cela permet aussi une remise en uqestion de l'organisation précédente.
Quelle remise en question ? Quand on arrive aux limites d'une API et qu'on la casse pour passer à autre chose c'est bien sur profitable, mais quand on a 28 fonctions d'une API pour le même résultat (Bonjour Alsa, bonjour ACPI, bonjour HAL) et qu'au final 3 finissent par être utilisée avec les 25 autres qui pourrissent sur pied sans être ni documentés ni mise à jour ni même marquée "deprecated". Ou est la remise en question ?
_ l'interaction avec le noyau de ces programmes est plus important que pour Firefox par exemple, normal ce sont des composantes basses du système._
Je veux bien que tu m'explique lentement en quoi PulseAudio interagit plus avec le noyau que Firefox, et en quoi il fait partie des composantes basse du système. PulseAudio est un programme userland pur qui choppe Alsa en mode exclusif et qui propose des interfaces pour le piloter. C'est aussi bas niveau que xmms.
Et SystemD c'est pas franchement le top non plus du point de vue "bas niveau", à terme il n'a pas d'autres but que de dialoguer avec DBus. Il est en espace kernel parfois certes, mais c'est juste une API d'abstraction.
Pourquoi alors les utilisateurs de *BSD pleurent de la linuxification de certaines parties du système ?
Principalement parce que ca va leur faire du boulot idiot en plus. Et aussi parce que la rupture du userland va être préjudiciable aux deux parties. Il y a aussi pas mal de BSDistes qui ont apportés de gros bout de codes et d'audits à des projets phares sous GPL (Déjà juste SSH) donc se voir claquer la porte au nez ca les ennerve.
J'ai de gros odutes uqe cela soit à sens unique tu vois… Je ne négligerais les torts d'aucun des deux partis.
Ben écoute quand tu auras trouvé des torts des *BSD (ie des projets sur lesquels les BSD ont profité du code Linux avant de le rendre incompatible avec Linux) fait moi signe, je te promet de ne pas les négliger non plus.
Pour avoir tester, non.
Ben écoute je veux bien ta solution sous Linux avec Network Manager actif pour faire du basculement de route conditionnel. pour l'instant je suis obligé de laisser tourner un watchdog en tache de fond et de simuler des trames DHCP le tout avec des règles IPTables longues comme le bras. Sous windows ca prend 3 ligne de WSH et la config résiste au reboot si le pont est toujours présent.
ne serait-ce pour la détection du mode connecté/déconnecté
Qui permet de crasher pas mal d'autres applications qui auraient parfaitement survécu grace à leur TTL si Network Manager était pas venu foutre le bronx dans les routes et les gateway. C'est toujours bon de perdre son tunnel SSH, sa connexion SIP et son VPN tout çà parceque le système a mis 5 secondes à contourner un équipement défectueux.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 0.
Donc si toi tu t'en fous, personne n'a le droit d'avoir du confort ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 10.
Donc si toi tu t'en fous, personne n'a le droit d'avoir du confort ?
Pour ce confort il faut :
a) Avoir DBus actif avant le lancement de la phase 2 de l'init
b) Réorganiser complètement toute la hiérarchie des fichiers de conf et des devices
c) Normaliser tous les events à la sauce Linux/SystemD
Donc non je m'en fous pas vraiment. Tout pilote/daemon/script écrit pour Linux SystemD devra être réécrit complètement pour tourner sur autre chose.
[^] # Re: Ça sent le réchauffé…
Posté par Zenitram (site web personnel) . Évalué à -3.
On te laisse proposer un système qui répond au besoin (le confort, si si, c'est un besoin) sans les inconvénients.
En attendant, il y en a qui s'est bougé pour répondre au besoin. Lui. Mais il vaut mieux critiquer les gens qui se bougent "bouh il me casse mon dinosaure qui ne répond pas au besoin mais je m'en fou" que de proposer mieux...
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 5.
_Mais il vaut mieux critiquer les gens qui se bougent "bouh il me casse mon dinosaure qui ne répond pas au besoin mais je m'en fou" _
C'est pas une critique, c'est un signal d'alarme. Le message ici c'est pas "ils ont cassé mon jouet", mais plutôt "les gars vous êtes sur que vous sciez la bonne branche là ?".
Je n'ai pour l'instant ni le temps, ni les compétences (mais ça, ça s’acquiert) de créer à la fois ma propre distrib, mon propre system d'init et mon propre DM pour piloter le tout. Tout ce pourquoi Linux me rend encore plus de services qu'il ne me coute de temps, je le garde. Mais déjà j'ai re-migré toute ma famille sous Windows, et mes serveurs de prod sont tous en BSD maintenant.
Linux ne me sert quasiment plus que pour le dev Java et le derushage video.
[^] # Re: Ça sent le réchauffé…
Posté par Adrien . Évalué à 2.
Perso je pense que les mec qui développent network-manager, pulseaudio, et ceux qui font des logiciels basés dessus ont bien réfléchit au problème… Seulement leur solution semble ne pas être la tienne. Pas de bol, c'est eux qui code.
[^] # Re: Ça sent le réchauffé…
Posté par totof2000 . Évalué à 1.
Le virage Linux de ces dernieres années c'est "On fonce vers le desktop, les serveurs on s'en fiche".
A partir de la on a tout compris.
Maintenant le problème vient bien plus des distributions que des développeurs. Et certains choix adoptés par les développeurs se justifient dans le cadre d'un desktop mais pas dans le cadre d'un serveur. Faire dépendre les process de démarrage de DBUS n'apportera que des problèmes sur un serveur, mais peut se justifier sur un desktop que l'on arrête/relance plus souvent. Et je pense que le fond du problème est là. Il faudra un jour que les distribs et développeurs choisissent entre desktop et serveur, sinon Linux risque de perdre des parts là ou il est bien utilisé c'est à dire les serveurs.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 2.
Pourquoi ? Une telle affirmation sans fondement n'est pas très convaincante.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par totof2000 . Évalué à 2.
Je sais mais je n'ai malhereusement pas trop le tempsde
trolldévelopper. Je vais voir si je peux lancer la discussion ce vendredi.[^] # Re: Ça sent le réchauffé…
Posté par Moonz . Évalué à 2.
D’un autre côté, si la solution actuelle me convient, pourquoi (et qu’est-ce que) je devrai coder ?
[^] # Re: Ça sent le réchauffé…
Posté par gnumdk (site web personnel) . Évalué à 0.
J'adore le mec qui vient faire chier tout le monde alors qu'il utilise même pas l'OS en question, vraiment magnifique...
En attendant, j'ai pas entendu parler d'une volonté de Linus de forcer l'utilisation de systemd dans Linux, donc bon, c'est quoi qui te fais chier, que tu peux plus utiliser RedHat sans ce truc ?
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 4.
J'adore le mec qui vient faire chier tout le monde alors qu'il utilise même pas l'OS en question, vraiment magnifique...
Tu es nouveau ici ?
Ceci étant même si mes serveurs et mes machines s'éloignent de Linux doucement, tout d'abord ça ne me fait pas plaisir et ensuite les machines de mes clients sont encore sous Linux.
Deux bonnes raisons de râler. (Si tant est qu'il en faille vraiment sur DLFP)
[^] # Re: Ça sent le réchauffé…
Posté par totof2000 . Évalué à 4.
J'adore le mec qui vient faire chier tout le monde alors qu'il ne sait pas lire.
>> Linux ne me sert quasiment plus que pour le dev Java et le derushage video.
Erreur il l'utilise. Plus beaucoup mais il l'utilise quand même. D'autre part il l'a utilisé et il est revenu en arrière pour les raisons qu'il explique donc une raison suffisante de raler.
[^] # Re: Ça sent le réchauffé…
Posté par Psychofox (Mastodon) . Évalué à 6.
un disque SSD ?
Parce que bon euh...system D est apparu sur ma fedora un jour. La vitesse de boot n'a pas bougé d'un iota. En tout cas rien de perceptible.
Par contre quand je suis passé à un disque SSD j'ai récupéré un boot en 5 secondes (et sans system D). J'en conclus donc que system D ne sert pas à grand chose car il n'offre que des différences de perfs marginales. Sans SSD on passe de lent à un poil moins lent et avec un SSD on est déjà dans un cas ou il n'y a plus rien à gagner.
[^] # Re: Ça sent le réchauffé…
Posté par B16F4RV4RD1N . Évalué à 3.
à tout hasard, la mise en veille / hibernation. Il paraît que même les utilisateurs de windows l'utilisent maintenant. Franchement, qui se soucie de gagner 5 secondes au boot, à part les mêmes qui s'astiquent le core pour gagner 8% de Mhz en plus en overclockant leur processeur ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ça sent le réchauffé…
Posté par Renault (site web personnel) . Évalué à 1.
systemd est loin d'être juste une histoire de gain de temps de boot… Il y a beaucoup d'avantages derrière tout ça notamment via l'intégration des cgroups par exemple et de dbus.
De plus, n'oublions pas que Linux est aussi sur le marché des serveurs et grosses machines où le temps de boot est un facteur qui peut être important. Un gros système mainframe peut mettre jusqu'à 30 minutes pour le boot… le temps est peut être négligeable pour nous mais pas d'autres applications.
[^] # Re: Ça sent le réchauffé…
Posté par Psychofox (Mastodon) . Évalué à 7.
le temps de boot d'un gros serveur est généralement lié aux tests hardware avant même qu'on arrive au bootloader.
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 2.
Tu m'inquietes. Tu redemarres souvent un serveur? Si oui tu devrais peut etre soit change le matos soit de facon de faire. Un serveur est generalement cense avoir de tres long uptime bien plus que le desktop...
[^] # Re: Ça sent le réchauffé…
Posté par qdm . Évalué à 1.
Même en éliminant le cas des serveurs de production qui effectivement ne "devraient" pas redémarrer dans un monde idéal, tu as quand même une palanquée de serveurs de test qui bougeant tout le temps lors de ces fameux tests passent leur temps à rebooter.
Et quant au serveur de production qui reboote, oui c'est rare, ça ne devrait pas arriver. Du coup, quand ça arrive (y compris pour des raisons indépendantes du serveur lui-même du style, "oh l'alimentation électrique qui est tombée s'avère n'avoir pas été si complètement redondée que ça"), on veut que les conséquences en soient le plus minime possible. Et un temps de redémarrage de 10 minutes, ça aide pas.
[^] # Re: Ça sent le réchauffé…
Posté par Anonyme . Évalué à 1.
Ben faut peut-être commencer à arrêter avec ces histoires de « un serveur qui a rebooté est un mauvais serveur ».
Rebooter un serveur, en soit, c’est pas mauvais, ça peut même éviter certains problème (comme un serveur qui veut pas rebooter en situation de crise, quand il a fallu changer une alim cramée).
[^] # Re: Ça sent le réchauffé…
Posté par qdm . Évalué à 1.
On est complètement d'accord. En production, l'objectif final n'est pas de minimiser les reboots, il est de minimiser le downtime. Donc, on doit suivre 2 axes pour ça:
1/ Minimiser les nécessités de reboot
2/ SI on doit quand même rebooter, minimiser le temps que ça prend.
[^] # Re: Ça sent le réchauffé…
Posté par B16F4RV4RD1N . Évalué à 3.
ouais mais bon, entre 2 ou 3 minutes, au final ça ne change pas grand chose que cela soit un ordinateur perso ou un serveur, si c'est pour rajouter une couche bizarre comme systemd, je préfère que cela mette 1 minute de plus.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ça sent le réchauffé…
Posté par Guillaume Rossignol . Évalué à 4.
Finalement, avec plus de 100cv dans la tour, peut-on gagner de la vitesse au boot ?
[^] # Re: Ça sent le réchauffé…
Posté par Anonyme . Évalué à 8.
C’est complètement con comme phrase.
PulseAudio se base sur ALSA pour apporté des solutions à certains problèmes eux même apportés par ALSA.
Je pense que tu dis tout dans ces phrases : il est inutile de porter certaines parti du système, pour d’autre, la compatibilité doit rester.
Je pense que l’init n’a pas pour vocation d’être compatible entre tous les systèmes donc un init personnalisé pour un noyau, ça ne me dérange pas. Par contre, ça me dérange quand on propose de lier cet parti du système avec le desktop (SystemD + GNOME par exemple) :
[^] # Re: Ça sent le réchauffé…
Posté par briaeros007 . Évalué à 6.
moi perso ça me gêne qu'on concoive un init qui fait 150 millards de trucs.
Par exemple je regarde ce site :
http://0pointer.de/blog/projects/why.html
Et je vois une tonne de yes ...
La philosophie unix c'est de faire une chose et bien.
Rajouter des tonnes de fonctionnalité qui n'ont rien à voir (désactiver un service sans avoir à éditer un fichier ... mais qu'est ce qu'on en a faire. on peut utiliser des interfaces d'administrations, l'init n'est pas forcé de "gérer" ce cas (qui est faux en plus)).
[^] # Re: Ça sent le réchauffé…
Posté par Anonyme . Évalué à 1.
Ha mais je suis tout à fait d’accord. Par contre, on peut faire un truc simple mai qui utilise les « aides » fourni par le noyaux.
[^] # Re: Ça sent le réchauffé…
Posté par neil . Évalué à -1.
« moi perso ça me gêne qu'on conçoive un noyau qui fait 150 milliards de trucs. »
— A. Tanenbaum
[^] # Re: Ça sent le réchauffé…
Posté par B16F4RV4RD1N . Évalué à 5.
moi ce qui me dérange surtout c'est que quand ça va arriver dans les distributions, ça va être « imposé » de la même manière que gnome3 ou grub2, c'est à dire qu'auparavant ça fonctionnait bien et maintenant on va mettre un truc compliqué et chiant à paramétrer, qui dans 30 % des cas fonctionnera mal (plus ou moins, enfin je ne sais pas, chez moi avec un panel de 3 ou 4 ordinateurs c'est 100 % de problèmes), les geeks s'extasieront du bidule tout en fustigeant la « résistance au changement des vieux rétrogrades » et pendant ce temps là, les potentiels nouveaux venus sous Linux fuiront ailleurs en voyant certains problèmes rédhibitoires...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Ça sent le réchauffé…
Posté par totof2000 . Évalué à 4.
Tiens c'est marant, on remplace Linux par Windows et on trouve toutes les raisons qui ont fait fuir les gens non geeks de Windows à Linux.
[^] # Re: Ça sent le réchauffé…
Posté par bubar🦥 (site web personnel) . Évalué à 5. Dernière modification le 16 février 2012 à 09:45.
mknodes fonctionne toujours e la même manière. Et tu peux modifier ton initrd pour le faire inside, ça fonctionne toujours aussi, ça. Tu peux donner un exemple précis ? Parceque la généralité est fausse, mais il est probable que tu ai des exemples bien vrais.
on peut utiliser soit le fichier de config à l'ancienne, soit son éclatement en sous fichiers dans l'arbo xorg.d. Mais c'est vrai que pour quelques points cela devient "problématique", typiquement une réso qui peut se marcher sur les pieds toute seule avec kms et un boot graphique (suffit de retirer le boot graphique), ou encore pour se configurer un pseudo X accueillant des progs pour tests (là je me suis arracher les cheveux la première fois). Mais là encore la généralité employée est fausse.
Ouf, networkmanager n'est pas aussi envhaissant que kms et xrandr. Suffit de le virer du boot (il y a vraiment des gens l'utilisant ici ??) et de taper les fichiers usuels. On peut faire exactement la même chose, et de la même manière, qu'auparavant. Y compris des configs conditionnelles, oui, ainsi que des centaines de cartes réseaux virtuelles à la volée.
gni ? udev est génial pour ça. Pourquoi cherches tu à le remplacer ? (ton début de phrase : "A capter des events systèmes" fait penser à ça). Il suffit de faire quelques règles udev pour tout cela (mention spéciales à usb-storage, oui oui :p ). Et si tu tiens vraiment à capter plus facilement et directement les events "systèmes", regarde les options du noyau de la distro, avant tout ?
Ne te méprends pas, je suis raccord avec ton propos (sauf sur le "boot" qui ne serait que confort : non, le boot systemd prend en condition des spécifités du noyau linux, et c'est bien normal), mais là, ces exemples me laisse quelques peu dubitatifs.
ps : je profite aussi de ce commentaire pour questionner sur l'utilisation du nom Lennart P. Ne voyant pas ce que cela vient faire là dedans (pour ou centre lennart), ce sont plutôt les techno que l'on devrait questionner. Résumer ces techno par un nom de dev, j'trouve ça pourri :p Par exemple PulseAudio a définitivement dégagé de mon desktop, définitivement (et ce n'est pas faute de l'avoir utilisr pendant longtemps, mais cette fois : décision prise. PA, dehors!) Dans le même temps, je trouve systemd génial pour linux.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 10.
Oui, moi. Pas sur des serveurs bien entendu, mais sur un poste client c'est génial.
Que demander de plus ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par mazarini . Évalué à 3.
J'ai activé le tethering usb sur mon tel, branché l'usb et il m'a suffit de choisir la connexion qui va bien dans la liste pour pouvoir l'utiliser sans problème. A part le choix de la connexion dans une liste, rien à faire.
Linux n'est pas utilisé que par des admin système ou réseaux, laissez nous le mode "Y clic" quand on est de repos.
[^] # Re: Ça sent le réchauffé…
Posté par William Steve Applegate (site web personnel) . Évalué à 9.
Moi aussi. Je fais
ifup eth0=eth0-workouifup eth0=eth0-home(bon, en fait c'est br0, mais c'est secondaire).Moi, je mets le mode hotspot WiFi sur le smartphone, et je fais
ifup wlan0=wlan0-htc(je n'ai pas cherché comment faire avec BT). Et sans NetworkManager pour me mettre le souk derrière. Si jamais j'ai du temps à perdre, je pourrai toujours écrire un widget graphique pour éditer mon /etc/network/interfaces et lancer les ifdown/ifup au changement de profil, mais je n'en ai vraiment pas besoin (la seule utilité serait éviter que les gens me regardent d'un air peiné parce que je tape une ligne dans un terminal).Et, vois-tu, j'aime bien cette sensation de comprendre ce qui se passe, pas d'avoir un démon quelconque qui bidouille ma conf' réseau dans mon dos. C'est là la différence pour moi entre Windows et Linux : pour l'un, la simplicité est dans l'interface utilisateur et la complexité est pour l'admin, l'autre est moins user-friendly mais l'admin peut comprendre son système plus facilement. Ça m'attriste un peu de constater qu'on tend à rejoindre l'approche d'en face.
Envoyé depuis mon PDP 11/70
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 4.
Mais j'ai pas envie de lancer une ligne de commande pour ça, même si je le peux aussi avec NM (man nmcli). Je préfère le faire en deux clics, c'est plus rapide en arrivant au boulot.
Il est vrai que tu soulèves un autre problème : NM ne prend pas en charge les ponts, et j'ai été obligé de ruser pour l'utiliser en même temps qu'un pont (je créé un tap0 auquel j'attache le pont, et NM continue de gérer eth0).
Ben j'ai pas envie d'acheter un nouveau téléphone juste pour ça. Le mien fait tethering et j'ai juste à synchroniser le bluetooth, je me contente de ça. Quant à mettre le souk, NM ne touche qu'à /etc/NetworkManager et par défaut il ne touche pas aux interfaces si elles sont prises en charge par le système (par exemples si elles sont dans /etc/network/interfaces sous Deb). Ça limite vachement l'étendue des éventuels dégâts, je trouve.
Ben là c'est pareil, en cherchant un peu tu peux voir ce qu'il se passe. Faut pas croire que parce que c'est sur dbus, c'est forcément opaque : tu peux lister les méthodes dbus (avec d-feet) pour contrôler voire scripter, et tout est basé sur des fichiers textes que tu peux modifier (/etc/NetworkManager, /etc/dbus-1/system.d/NetworkManager.conf, etc).
Bon après c'est vrai que le XML est peut-être de trop, mais ça n'est pas dû à NM. Et si c'est bien fait, c'est assez lisible ; d'ailleurs, je viens de jeter un œil à /etc/dbus-1/system.d/NetworkManager.conf, chose que je n'avais jamais faite, et je découvre qu'on peut y définir des droits particuliers en fonction du groupe.
Je trouve qu'on a autant accès à une GUI simple qu'à une admin complète.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par houra . Évalué à 5.
deux remarques là :
-1 pour être obligé de bidouiller comme ça dès qu'on a un cas particulier, ça apporte quoi NM ?
-2 cas particulier insolubles :
*- réseau internet sur interface eth0 , veut créer un pont Wifi pour que d'autres ordinateurs se connectent. ça marche pas. Je veux dire, je suis la doc d'Ubuntu fr , les docs anglosaxonnes , nada, rien. Et là où on avait la possiblité de rechercher à partir de la réponse sur le shell, ben là, on se retrouve comme Windows: ça marche juste pas. pas de messages d'erreur sur le shell, pas de sortie avec mode verbose graphique comme sous VLC, rien, que dalle.
*- comment monter simultanément deux réseaux sur une carte wifi ? cette option est impossible avec NetworkManager. ( apparemment hein, la doc étant ce qu'elle est... )
N'aurait-il pas été plus soluble et sympa de faire un machin en CLI , et un machin graphique qui dialogue avec le machin en CLI au moyen de messages systèmes ?
L'obligation de monter X11 pour atteindre des fonctionnalités avancées est une bêtise sans nom. Comme je l'ai écrit, l'idéal aurait été de pondre ces outils en CLI avec une interface de dialogue pour leurs pendants graphiques. Et ceci non seulement pour répondre à un maximum de besoins particuliers, faciliter les évolutions des outils en fonction des besoins, et surtout pour ces outils mijoter une interface de dialogue avec leurs pendants graphiques aux petits oignons. Et quid de dbus sous Wayland ou sous une IHM tierce ( à là Android par exemple ) ?
Inversement, si la distribution ou le gestionnaire de bureaux qui veut devenir distribution a réellement besoin d'outils purement graphiques tels que NetworkManager , alors ils n'envisagent pas leur système d'exploitation autrement qu'avec un affichage local . Alors utiliser le système client serveur X est une hérésie.
Sedullus dux et princeps Lemovicum occiditur
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 3. Dernière modification le 17 février 2012 à 12:24.
Rien en effet, mais ça n'enlève pas les autres qualités de NM, qui est à mon avis plus adapté et plus pratique dans la vie de tous les jours.
Faudra que j'essaie, mais je sais que NM peut configurer un point d'accès WiFi. Ça serait vraiment idiot que le pont ne soit pas fait.
Euh je ne savais déjà pas qu'on pouvait le faire tout court. Tu parles bien de connecter simultanément à deux réseaux sans fil via la même interface ?
Ben c'est ce qui est fait : il y a un démon qu'on configure avec des fichiers texte et avec lequel la GUI et la CLI dialoguent au travers de dbus. La CLI se nomme nmcli, mais il en existe d'autres (au moins cnetworkmanager).
Pas besoin de X11 pour utiliser NM. Encore une fois, voir nmcli.
Le problème, c'est que ce genre de besoin vient souvent d'admin, et sachant que NM est orienté utilisateur final, il fait l'impasse sur certains pour présenter un truc simple et pratique, et de ce point de vue c'est déjà pas mal.
Il n'est certes pas adapté à tous les usages, mais c'est bien là l'intérêt du libre : avoir le choix. On peut très bien s'en passer et utiliser autre chose.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par sifu . Évalué à 1.
Il m'est arrivé récemment le pb suivant sur ma Debian Sid. Ma carte vidéo était HS, j'ai donc voulu me connecté à ma machine via SSH. Et là, je me suis rendu compte que le réseau n'était accessible que si j’ouvrai une session. J'ai eu la larme à l'oeil ...
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 2.
Ça, c'est bizarre. Quand je me connecte par l'une des consoles plutôt que par X, je n'ai pas à activer le réseau, NM le fait d'emblée.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par Adrien . Évalué à 2.
Tout dépend de comment tu as paramétrés ton réseau. Ici sous Debian j'ai au moins deux méthodes pour avoir le réseau dans tes conditions :
– ifconfig, ifup, etc. : ça marche mais c'est chiant ;
– utiliser network-manager. Normalement pour toutes tes connections il y a une option « connection système ». Si tu la coche, alors elle la connexion ne dépendra pas de ta session et se lancera au lancement du système.
Faut pas :-) D'ailleurs si network-manager te saoûle, rien ne t'empêche de ne pas l'utiliser…
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 3.
troisieme solution wicd (qui a une interface ncurse qui fonctionne)!
[^] # Re: Ça sent le réchauffé…
Posté par Anonyme . Évalué à 2.
À quoi ça sert de faire des connexions non-système ?
NM étant principalement mono-utilisateur (en gros, je suis utilisateur ET admin de a machine, comme sous Windows quoi), les connexions non-systèmes n’ont pas lieu d’être.
[^] # Re: Ça sent le réchauffé…
Posté par sifu . Évalué à 1.
Merci de ton retour.
Justement, je n'avais rien paramétré. Cela fait pas mal de temps que je tournais avec cette installation et je pense que NM est arrivé lors d'une mise à jour (Debian Sid).
Ma première expérience a été douloureuse !
De mon point de vue, c'était une régression car sur ce poste de bureau j'ai pas vraiment besoin des features de NM.
[^] # Re: Ça sent le réchauffé…
Posté par Moonz . Évalué à 4.
Ce qui est tout à fait l’objet de l’article présenté par ce journal : à force d’essayer de faire plaisir à l’« utilisateur final », on fait chier tous les autres (admins, devs un peu curieux…) en détruisant ce qui faisait la force de Linux à leurs yeux.
Personnellement, ce qui m’a intéressé à l’informatique, c’est mon premier contact avec Linux, la transparence et la simplicité du système, qui me permet de comprendre tout ce qui se passe à coups de
cat. Ça me fait vraiment mal de penser que si tu m’avais mis un Linux d’aujourd’hui dans les mains à cette époque, je n’aurai rien compris et probablement pas cherché à m’intéresser plus à l’outil informatique.[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 1. Dernière modification le 20 février 2012 à 09:32.
Encore une fois : en quoi on les fait chier, puisqu'il suffit de ne pas l'installer ? Tu parles de la force de Linux, mais tu as justement le choix d'utiliser ce que tu veux, tu n'es forcé à rien !
Quand j'installe un serveur sous Debian ou Red Hat, NM n'est jamais installé.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par Moonz . Évalué à 3.
La découverte. Encore une fois, ce qui m’a amené à m’intéresser à l’informatique, c’est m’intéresser à comment ça marche « sous le capot », et voir à quel point c’était clair, simple et transparent. Aujourd’hui, quelqu’un qui ouvre le capot sans connaître grand chose, il va découvrir un foutoir sans nom et jeter l’éponge en se disant « l’informatique c’est trop compliqué ». Ceux qui savent qu’ils peuvent désinstaller ces strates de bloat sont ceux qui ont déjà (largement) passé l’étape découverte.
De plus en plus de fonctionnalités, qui ne nécessitaient pas ces trucs, en ont besoin. Un simple exemple : à l’époque de hal, on avait des utilitaires simples et assez sympas en ligne de commande pour gérer les disques amovibles (clés usb et tout). Ensuite, le tout a été unifié avec udisk. Toujours aussi simple et sympa. Et là, quelqu’un a décidé de mettre consolekit et policykit en dépendance de udisk. Je n’ai plus jamais été capable de monter une clé usb avec udisk.
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 2.
Ouf, networkmanager n'est pas aussi envhaissant que kms et xrandr. Suffit de le virer du boot (il y a vraiment des gens l'utilisant ici ??)
Pas moi en tout cas je prefere de tres tres loin wicd. Certes il fait pas le cafe mais il fonctionne lui au moins!
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 10.
mknodes fonctionne toujours e la même manière. Et tu peux modifier ton initrd pour le faire inside, ça fonctionne toujours aussi, ça. Tu peux donner un exemple précis ? Parceque la généralité est fausse, mais il est probable que tu ai des exemples bien vrais.
Cas typique, quand on branche une clef USB sur un Linux je veux les actions suivantes :
- Création d'un device basé sur un identifiant unique de la clef (par exemple son numéro de série)
- Scan de la clef pour chercher la présence d'un certificat
- Validation du certificat et démontage du device
- Montage du device sur un emplacement device précis en read only.
- montage du FS de la clef à un endroit précis.
Le truc de base qui te permet d'avoir un certificat à un emplacement fixe pour que Java puisse le chopper facilement. Et là c'est devenu une galère intégrale. Sur chaque variante de Linux il faut écrire un code différent, contourner les règles udev du système, parfois blacklister des devices. Et après avoir écrit deux pages de scripts, de règles udev et de contournements tu as généralement une mise à jour toute con qui vient te foutre ton système en l'air.
Tout ce dont j'ai réellement besoin c'est d'un moyen de pouvoir à DBus, HAL, Gnome, et tout un tas d'automounter : "vos gueule, vous touchez pas aux block devices". Mais ce moyen n'existe pas. Je peux dire à Udev de ne pas traiter l'ensemble des clef USB de marque Toto construite avant 2008, mais je ne peux pas dire à HAL de ne pas lancer d'évènement, je ne peux pas dire à DBus d'ignorer ces évènements si ils sont lancer et de ne pas les retransmettre. C'est juste gavant.
on peut utiliser soit le fichier de config à l'ancienne,
Dans pas mal de distribs, on ne peut plus. Tu peux faire ce que tu veux dans ton xorg.conf, le système en prendra en compte une partie, ou rien. D'autres parties ont étés éclatés à gauche et à droite (mention spéciale à monitor.xml sous ubuntu), d'autres encore sont régénérées à tous les boots, à peu près quoi que tu fasses.
Sans compter la cerise sur le gateau, dans les distribs "modernes" pour le desktop (Fedora, Ubuntu, OpenSuse de mémoire) si pendant que tu testes ta config le serveur X ne démarre pas, immédiatement un machin chose va se lancer automatiquement pour refaire ta config tout seul comme un grand ET ECRASER TOUTES TES MODIFS.
En plus en cas de mise à jour un peu importante de X11, le machin chose (qui est chiant à trouver, chiant à gicler) est réinstallé et lancer en mode forcé au prochain reboot. Et une fois de plus tu es bon pour refaire toute ta config.
Je crois que X11 sous Fedora c'est le seul truc qui m’ait fait dire que je regrettais les macros M4 de sendmail.
gni ? udev est génial pour ça. Pourquoi cherches tu à le remplacer ?
Mais je veux pas le remplacer, CF plus haut. J'adore udev. Maintenant si le couple HAL(ou devicekit)+DBus pouvait fermer sa gueule et le laisser bosser, ca me ferait vraiment plaisir. Et devine quoi ? SystemD dialogue avec DBus/HAL ou DBus/devicekit, pas à coup de probes sur les devices mappings.
_Ouf, networkmanager n'est pas aussi envhaissant que kms et xrandr. Suffit de le virer du boot (il y a vraiment des gens l'utilisant ici ??) _
Perso j'en suis là, je vire cette saleté dès que j'ai les mains dessus. Le problème c'est en prise de main à distance, gicler network manager à distance ca demande beaucoup de concentration pour ne rien oublier qui empêchera le réseau de remonter. Maintenant RHEL et Fedora râlent pas mal quand tu leur arraches NM. Et à la mauvaise installation du mauvais package il revient en force.
Je sens juste que ça va être de plus en plus dur de s'en passer, et ça m'énerve parce que c'est un truc qui ne me sert à rien et qui me bloque tout le temps...
non, le boot systemd prend en condition des spécifités du noyau linux, et c'est bien normal
Je n'ai pas dit que la solution SystemD n'utilisait pas de spécificité Linux, j'ai dit que dans le cadre d'un init ces spécificités étaient inutiles. Pire elles sont dangereuses, la tentation est grande de faire dans SystemD des opérations qui devraient être faite par le daemon lui même. Quand je vois les fonctionnalités de SystemD je me dis que pour faire fonctionner un serveur logique autrement que comme l'a voulu le packageur ca va devenir coton. Vrai beaux jeu de pistes en prévision.
[^] # Re: Ça sent le réchauffé…
Posté par imr . Évalué à 2.
Il n'y a pas de mécanisme pour empêcher l'installation d'un paquet dans RHEL et Fedora ?
[^] # Re: Ça sent le réchauffé…
Posté par bubar🦥 (site web personnel) . Évalué à 1. Dernière modification le 16 février 2012 à 19:30.
exclude=paquet dans yum.conf
Et en plus "râlent pas mal quand tu leur arraches NM." est faux, à moins de ne prendre le bon point de sortie de l'arbre de dep.
[^] # Re: Ça sent le réchauffé…
Posté par monde_de_merde . Évalué à -6. Dernière modification le 16 février 2012 à 10:50.
Lol n00b.
Ha pardon on est pas vendredi.
Ceci dit, tu râle que tu n'y arrives plus, mais à chaque fois que j'ai rencontré quelqu'un qui "n'y arrivait plus", la réponse à la question "C'est quand la dernière fois que tu as lu un bout de doc/man page ?" était "euh...". Après vous pouvez faire comme moi hein, pas de mémoire, pas de problème de mise à jour, je passe ma vie dans la doc.
[^] # Re: Ça sent le réchauffé…
Posté par Kaane . Évalué à 9.
"C'est quand la dernière fois que tu as lu un bout de doc/man page ?"
De quelle doc tu parles ? De la doc Alsa qui est vide ? De la doc SystemD dont l'encre n'a même pas le temps de sécher, de la doc distrib X11 qui est à peu près introuvable et souvent fausse.
Ou de doc/man pages en général ? Parce que les docs je passe mes journées dedans, à les lire, à les écrire, à les expliquer.
[^] # Re: Ça sent le réchauffé…
Posté par JGO . Évalué à 3.
Dans ce cas particulier, tu utilises NetworkManager sur ton netbook pour surfer et tu utilises la ligne de commande classique pour gérer les cartes réseaux de ton serveur. Ta distribution empêche d'avoir NetworkManager et les outils en ligne de commande ? En ce qui me concerne j'utilise NetWorkManager sur mon portable perso et un fichier en dur avec une IP écrite à la main sur mon fixe du bureau.
[^] # Re: Ça sent le réchauffé…
Posté par imr . Évalué à 7.
On est à la limité de l'attaque à l'épouvantail, à la limite parce que c'est le journal qui focalise l'attention sur lennart alors que ce n'est pas le coeur de l'article. Le coeur de l'article et du problème selon lui, c'est dbus et la manière dont les desktop utilise dbus qui fait qu'on ne puisse plus travailler sans eux donc sans X.
Les applis de lennart ne sont qu'un exemple; celui de network manager est plus grave dans les problèmes qu'il induit, et le problème de la compatibilité des BSD est un effet de bord.
Je suis assez surpris que network manager ne soit pas plus configurable en cli.
J'ai trouvé ça effectivement:
Il n'y a vraiment aucun moyen de configurer le réseau en cli proprement avec network manager? Il dit être obligé d'utiliser network manager sur une RHEL dans cette partie:
Ca parait énorme.
[^] # Re: Ça sent le réchauffé…
Posté par Adrien . Évalué à 1.
un truc comme ça quoi : http://packages.debian.org/sid/cnetworkmanager
[^] # Re: Ça sent le réchauffé…
Posté par Adrien . Évalué à 0.
bon en fait je me suis gourré sur cnetworkmanager (ça m'apprendra à ne pas lire l'article).
Enfin sur network-manager, le mec trolle comme un bon gros goret… Perso je n'ai jamais eu besoin d'installer network-manager sur un serveur, sur un poste utilisateur oui, mais un serveur surtout pas.
[^] # Re: Ça sent le réchauffé…
Posté par ahuillet (site web personnel) . Évalué à 4.
Ça c'est parce que tu n'as pas installé une RHEL récente...
[^] # Re: Ça sent le réchauffé…
Posté par imr . Évalué à 3.
C'est ton cas? C'est quoi les services qui ont besoin de nm pour tourner et les programmes qui fonctionnent mal sans lui?
[^] # Re: Ça sent le réchauffé…
Posté par ahuillet (site web personnel) . Évalué à 3.
Pour situer le contexte : je m'en sers pour du calcul haute performance, donc sur des machines qui ne sont pas supposées avoir X, Gnome, ... et dont on est plutôt content quand un minimum d'éléments tournent dessus.
RHEL serveur installe par défaut X, Gnome, Dbus, Pulseaudio, NetworkManager. Déjà, c'est particulièrement agaçant, mais tu peux supprimer X sans trop de problèmes - sauf que depuis la version 6, c'est NetworkManager l'outil "officiel" de configuration du réseau et c'est très difficile de s'en passer.
Par contre je ne partage pas la conclusion de l'auteur : moi j'arrive à ne pas lancer NM et les services qui m'intéressent (à savoir NFS et c'est à peu près tout) fonctionnent. Par contre, l'étape de configuration hors NM est assez compliquée parce que la distribution fait tout ce qu'elle peut pour te forcer à s'en servir.
Idem avec le remplacement de NSS-ldap par SSSD, qui complique énormément le fonctionnement sans rien apporter.
[^] # Re: Ça sent le réchauffé…
Posté par bubar🦥 (site web personnel) . Évalué à -2.
[root@LisaClarke ~]$ uname -rv
3.2.6 #1 SMP Tue Feb 14 19:31:12 CET 2012
[root@LisaClarke ~]$ cat /etc/redhat-release
Fedora release 16 (Verne)
[muny@LisaClarke ~]$ pstree
systemd─┬─atd
├─auditd───{auditd}
├─crond
├─dbus-daemon───{dbus-daemon}
├─httpd───8*[httpd]
├─rsyslogd───3*[{rsyslogd}]
├─sshd─┬─sshd───bash
│ └─sshd───sshd───bash───pstree
├─systemd-logind
├─systemd-stdout-
└─udevd
[root@LisaClarke ~]$ lsmod
Opening /proc/modules: No such file or directory
[root@LisaClarke ~]$
[^] # Re: Ça sent le réchauffé…
Posté par Vincent . Évalué à 1.
Est ce que c'est pas un peu overkill sur un serveur sans support de module de faire tourner udev et dbus ?
<mavie>Sur mon serveur perso de chez moi sur une archlinux "maison", mon petit serveur ne fait tourner ni udev, ni dbus (et j'ai pas de pam non plus d'ailleurs, ni de support de l'USB et encore moins des modules), avec un bon /dev statique old school. Parce que bon un serveur enfermé dans un placard, la gestion de configuration des périphériques à chaud dynamique tout ça ça me fait trop une belle jambe</mavie>Bien entendu un cas réel d'entreprise n'a évidemment pas du tout les mêmes contraintes que mon petit cas perso. :)
[^] # Re: Ça sent le réchauffé…
Posté par bubar🦥 (site web personnel) . Évalué à 3.
C'est un choix. Celui de descendre tout ça, mais sans avoir à perdre du temps lors des mises à jour. Le maintiens se fait selon ce qu'on peut attendre d'un système : un coup de yum update, et tout fonctionne, sans avoir besoin de retoucher : on peut s'occuper des services, et plus du système ;) Pour dbus, par contre, tu as raison, ça mérites un peu coup de polissage supplémentaire, vu qu'il ne sert à rien, et ne servira jamais à rien sur cette machine. Pour udev c'est pratique de le conserver dans la mesure ou usb-storage est présent : udev permet alors de n'autoriser que certaines clefs usb...
Arf, tu va être heureux si je t'apprends que le prochain login sera PAM only. Oui, oui Disponible dès la version prochaine de util-linux ! Donc soit tu passes à pam, soit il te faudra utiliser un autre login
[^] # Re: Ça sent le réchauffé…
Posté par Vincent . Évalué à 2.
Oui je sais, je comprend. C'est pour ça que je disais que les contraintes n'étaient pas les même chez soit et en entreprise. Rien que le fait de virer dbus et udev sur une archlinux c'est un peu chiant, faut recompiler quelques packages, suivre les maj. Mais bon j'arrive pas à trouver une distrib vraiment adaptée à chaque usage (en général c'est une distrib pour tout mais du coup y'a tout un tas de bordel inutile qui s'installe et se lance). Y'aurait peut-être gentoo, mais bon installer gcc et toute la clique sur un serveur ça me choque.
Pas trop non :( J'attendrai les patchs de slackware :)
[^] # Re: Ça sent le réchauffé…
Posté par bubar🦥 (site web personnel) . Évalué à 2. Dernière modification le 16 février 2012 à 11:13.
Oui, c'est pour ça que j'utilise NM chez moi, sur mon laptop, par flemme pour les connections itinérantes, mais qu'un serveur pro mérite qu'on s'y attarde un peu plus. Le truc (pivot, point d'équilibre) étant il me semble de rester en accord avec ce qu'attends le fournisseur pour que les mises à jour ne soient pas chronophages.
Je conçois gentoo en bi-machines au minimum. Un serveur ne contenant que ce dont il a besoin, et une machine de préparation, pour la compilation, permettant de pousser les paquets binaires sur le serveur (puisque gentoo permet de construire les paquets binaires, en une seule commande, c'est nickel). Les install gentoo àla ovh me font froid dans le dos :p
J'me doute (...) C'est un sacré coup aux distribs de type SlackWare, ça, ouhai. D'un autre côté, un bon coup de polish sur des paquets aussi importants ne fera pas de mal. (bref, je ne me prononce pas sur ça, pas d'avis tranché, mais c'est à anticiper que slackware va faire la tronche, ouhai) Par contre j'attends de voir prlimit, une autre nouveauté, miam celle là.
[^] # Re: Ça sent le réchauffé…
Posté par Misc (site web personnel) . Évalué à 3.
Dbus sert pour les remontés d'alert selinux, ou pour abrt. Je vois que dnsmasq utilise aussi dbus sur une fedora, et je peux supposer que libvirt l'utilise. Corosync ( utilisé par pacemaker ) fait du dbus pour signaler l'etat du quorum.
Et je trouve pas plus déconnant d'avoir dbus que d'avoir un demon rpc comme sur certains unix, genre solaris pour nfs et co. Le principe est simple, si on veut avoir des programmes qui font qu'une chose et bien, faut soit que chacun refasse son méchanisme de RPC dans son coin ce qui limite un peu, soit avoir un canal et un protocole de com en commun ( dbus, rpc, etc ), soit avoir un gros programme qui fait tout à la IIS ( comme ça il communique qu'avec lui même ).
Donc d'un point de vue du design, je pense que dbus est une solution. Y a sans doute des choses à améliorer, mais les alternatives sont pas vraiment convaincantes, et les idées futures attendent encore d'être écrites.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 4.
Oui, quand on choisit de ne pas personnaliser l'installation. Mais il suffit de décocher les environnements de bureau.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par JGO . Évalué à 3.
Il faut gueuler contre les choix idiots de RHEL, pas contre NetworkManager.
[^] # Re: Ça sent le réchauffé…
Posté par imr . Évalué à 3.
C'était le sujet de l'article ... Enfin, on a évité que tout le monde gueule sur Lennart...
[^] # Re: Ça sent le réchauffé…
Posté par Misc (site web personnel) . Évalué à 2.
sssd permet d'utiliser un cache, ce qui a 2 avantages :
- sur un portable, ben ça marche sans le réseau
- sur un desktop, tu évites du trafic inutile, et surtout, ton serveur marche encore même si le ldap est en rade ( ou en cours de maintenance ).
sssd permet aussi une intégration simplifié de kerberos, même si j'imagine que ça t'apporte rien si tu as pas de kerberos.
Et si j'en crois ce lien https://features.opensuse.org/310176 , {pam,nss}_ldap n'est pas sans souci ( même si je reconnait que j'ai pas vu ce genre de problème personnellement ).
[^] # Re: Ça sent le réchauffé…
Posté par Moonz . Évalué à 3.
C’était pas déjà censé être géré par nscd ?
[^] # Re: Ça sent le réchauffé…
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 7.
Donc la conclusion c'est qu'on parle d'une distro de merde quoi.
Faut arrêter de réduire Linux et ses distributions à trois ou quatre grandes distributions qui font souvent de la merde en ce moment.
Wicd fonctionne très bien, il existe un démon, et des clients pour le configurer, en ligne de commande, en ncurses, en GTK, ptre même qu'il y en a une en Qt je crois.
Et encore, Wicd n'est qu'une aide, on peut le virer (ce que je fais sur les serveurs).
J'utilise Slackware (Salix), et je n'ai aucun des problèmes cités dans le journal, forcément, j'ai pas de systemD de merde (j'adore le nom que ça donne en français d'ailleurs). J'ai lu les specs du truc...ça apporte des solutions à des non-problèmes. La phase de boot n'est pas des plus rapides (pas de parallélisation) qu'il est possible de concevoir, mais ça reste assez rapide...et surtout très simple à comprendre.
J'ai pas non plus de pulseaudio. Dans mon cas, je ne vois pas à quoi ça sert. Alsa fonctionne très bien. Si un jour je voudrais faire un truc qui demande une latence super faible parce que je me suis lancé dans l'édition musicale, je sortirai Jack. Le seul truc que je peux reprocher à Alsa c'est sa manque de doc, et son manque de support réseau. Mais c'est pas qu'on demande à un démon de son pour le desktop je crois.
Bref, Lennart fait et propose des outils. Libre à chaque distro de les intégrer ou non, en évaluant si les specs (et donc les raisons) de ses softs répondent à des problématiques que veut résoudre la-dite distro.
Vous aimez pas les outils de Lennart ⇒ changez de distro ;-)
P.S. Debian n'impose aucun de ces outils aussi il me semble. Arch non plus.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 2.
Moi si. Il suffit de ne pas l'installer dans la sélection des paquets.
Sinon, yum remove network-manager.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par nud . Évalué à 4.
Pour moi tous les problèmes "pratiques" semblent limités à Network Manager, qui est bien pratique sur un PC de bureau mais reste très limité quand on sort du tout venant. D'un autre côté, je doute qu'il soit nécessaire de se taper Network Manager sur un serveur comme le monsieur semble dire.
[^] # Re: Ça sent le réchauffé…
Posté par luc schimpf (site web personnel) . Évalué à 4.
Personnellement, j'aimerais connaitre ces appli qui refusent de fonctionner sans nm ?
Sous debian sid sans nm depuis... je sais plus, aucun problème.
Je conçois que ça peut être utile sur un portable qui est amené à changer de point d'accès, mais sur un pc de bureau ?
Quant à pulse, j'ai toujours pas compris à quoi ça sert...
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 6.
Faux. Toutes les connections sont dans des fichiers texte dans /etc/NetworkManager, et ça se contrôle en cli par la commande « nm ».
(oui, je trouve aussi que les majuscules dans /etc sont une aberration)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par nud . Évalué à 3. Dernière modification le 16 février 2012 à 10:17.
Euh, tu ne confondrais pas avec le
nm(1)debinutilsdes fois ?[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 1.
Exact, au temps pour moi.
La vraie commande est nmcli.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par oau . Évalué à 2.
bizarre ce que vous dites. Je commence à avoir pas mal de redhat 6 en prod et je ne savais même pas que Network Manager devait être utilisé. Visiblement sur mes machines il n'est pas installé (je n'installe pas moi même mes machines) et je n'en ai jamais eu besoin. Je fait ma conf réseau dans /etc/sysconfig/network-scripts/* comme depuis très longtemps. Et aucun des softs que j'utilise m'insulte parce que je n'ai pas nm.
[^] # Re: Ça sent le réchauffé…
Posté par bubar🦥 (site web personnel) . Évalué à 1.
Sur Redhat, si. Si on tiens à utiliser l'outil networkmanager, on peut l'utiliser en cli (la version cli est aussi complète que la version gui, à l'identique de ce qu'avait fait Mandrake à l'époque.). NetworkManager est clairement orienté laptop (wifi) et serveur. Mais pas fonctionnalités "routeur" (tel que le sous entends avec justesse, Kaane, plus haut). Pour ce type de besoin plus "couillu" il est vraiment aisé de se passer de NM, voir de le désinstaller sans aucun problème (sans pétage de dep foireuse, sans message "db modif outside of yum, alors que tu sais que cette dep est foireuse). Bref on peut vivre sans NM proprement, et facilement.
D'autant plus que cela renvoit, entre les lignes, à une potentielle perte de fonctionnalités de configuration graphique. Ce qui n'est absolument pas le cas. Hier, on configurait le système sans gui (ou wui), aujourd'hui on configure le système sans gui (ou wui).
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 3.
Utilise wicd qui lui a une interface ncurses. Encore une fois la preuve que faire un seul truc mias bine c'est nettement mieux!
[^] # Re: Ça sent le réchauffé…
Posté par Shuba . Évalué à 3.
Wicd c'est assez cool, certes, mais il pose quand même des problèmes, par exemple j'ai l'impression que tu ne peux pas avoir wicd qui gère ton interface wifi, et gérer ton eth0 à la main à côté, wicd va venir mettre son grain de sel... Ce qui n'est pas très pratique quand on cherche à faire un pont entre les deux interfaces.
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 1.
Parceque NM va te laisser faire cela? Il a bien change et est devenu beaucoup moins intrusif.
Un truc que je ne supporte pas avec NM c'est que si il est installe c'est a peu pres impossible de faire marcher un reseau sans devoir passer par ce truc.
/etc/init.d/NetworkManager stop #marche pas (on va dire que c'est a cause d'ubuntu)
/etc/dbus-1/event.d/25NetworkManager stop
/etc/dbus-1/event.d/26NetworkManagerDispatcher stop
hyper user-friendly (et marche pas tout le temps).
NM c'est peut etre bien sur RH mais sur le reste c'est un gros merdier.
[^] # Re: Ça sent le réchauffé…
Posté par inico (site web personnel) . Évalué à 0.
Essaie nmcli nm sleep true ...
[^] # Re: Ça sent le réchauffé…
Posté par Misc (site web personnel) . Évalué à 5.
Ben si vous avez des soucis, il faut faire des rapports de bugs auprés des packageurs des distributions ou ça marche pas. C'est pas compliqué, c'est presque comme Linuxfr, mais ç'est utile.
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 3.
Je m'en fous de NM je me sers de Wicd et ca marche tout simplement sans etre intruisif.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 1.
Ben alors pourquoi les gens se plaignent ?
Soit ils se servent de NM, soit ils le virent. C'est ce que je fais : sur mes postes, je le mets, sur serveur, je l'enlève. Point.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par Batchyx . Évalué à 2.
Tout le monde n'est pas administrateur sur sa machine. Et même si tu l'est, tu n'est peut-être pas non plus tout seul à utiliser la machine.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 2.
Donc si vous êtes plusieurs à utiliser une machine et que NM reste présent, c'est bien qu'il est utile à quelqu'un ? Sinon tout le monde serait d'accord pour l'enlever, non ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 4.
Ah j'oubliais generalement j'ai besoin de mon reseau tout de suite pas dans 6 mois donc je prefere avoir un truc simple qui marche plutot que la cafetiere en panne.
[^] # Re: Ça sent le réchauffé…
Posté par Misc (site web personnel) . Évalué à 3.
Et sauf erreur de ma part, il ne gére pas grand chose niveau modem 3g ( que ça soit les clés 3g, ou un tel via du bluetooth ). Autant le vpn, ça me dérange pas de monter ça à la main, autant c'est toujours emmerdant de devoir chasser la config correct sur internet ( en fonction de la clé et de la carte ) pour la 3g.
Ensuite, pour remplacer tout les trucs que tu es capable de faire à la main sans trop te faire chier, comme lancer dhclient, ou modifier ta config d'eth0, c'est vrai que wicd peut aider un peu. Mais bon, si ça fait que les trucs de bases, ça va, sauf à être un débutant, on arrive à faire ça soit même.
[^] # Re: Ça sent le réchauffé…
Posté par Albert_ . Évalué à 3.
Je sais pas je n'ai aps de cle 3g mais avec le telephone de ma femme le tethering et wicd marche tres bien.
[^] # Re: Ça sent le réchauffé…
Posté par Misc (site web personnel) . Évalué à 6.
Au dela de la récurence, c'est surtout les imprécisions apparentes qui me frappent, surtout qu'elles se cachent derriére une culture Unix étalé et assumé. Que je sache, la plupart des distros ont d'une part un installeur texte, et aussi une installaton automatisé. Ouais, faut sans doute lire la documentation pour le trouver, c'est scandaleux. Mais on peut pas raler sur "les distros linux deviennent trop pour les neuneus" et en même temps se plaindre qu'il faille avoir des compétences pour faire ce qu'on veut.
Quand au fait que des programmes ne marchent pas sans network-manager, j'en connait pas. Evolution et epiphany marche sans ( mais par défaut l'utilise, vu que c'est logique de se baser sur la configuration par défaut du systéme pour activer les fonctionnalités par défaut des programmes ). Gajim marche sans, Empathy aussi. Packagekit s'en sert pour determiner si la connexion est en 3g ou pas ( ie, est ce qu'il faut faire des mises à jour du cache ou pas ), mais pareil, il marche sans network-manager ( enfin, il part du principe qu'il peut faire la mise à jour ).
Donc si le sujet est "quand on touche à la configuration par défaut, il faut modifier la configuration d'autres outils", c'est juste logique.
J'ai jamais vu le moindre logiciel serveur refusant de tourner sans network-manager, mais je suis sur que l'auteur a des exemples tellement nombreux qu'il a pas cru bon de les donner.
Il connait pas nm-cli, comme dit plus loin ici. 4 ou 5 eme lien d'un moteur de recherche : http://fedoraproject.org/wiki/Features/NetworkManagerCmdline. Mais le premier est sur cnetwork-manager, qui est mort.
Donc ouais, ça bloque sans doute les résultats.
Il parle de vpn over ssh, et trés franchement, c'est une solution des plus baroques. Vu que pour faire ça, il faut d'abord passer root, faire un ssh -w ( depuis le compte root ) aprés avoir fait un tunctl des 2 cotés qui va bien, et mettre des permissions spécifiques pour changer l'ip du tunnel et laisser ssh écrire dans le device. Conceptuellement, c'est pas différent d'openvpn, mais c'est trés manuel. Et faire du vpn par dessus du tcp, c'est pas super. Et bien sur, tu doit te taper 1 interface par utilisateur du coté du vpn, ce qui est pas idéal ( ça monte pas pas trop à l'échelle ). Perso, je m'attendais à mieux de la part d'un security officier de netbsd que de faire faire des ssh en root et en se filant des permissions sur des devices.
Donc oui, faut passer à openvpn ( qui souffre pas des soucis suscités ), ou écrire son propre plugin. Il y a quelqu'un qui a fait un plugin pour iodine, donc c'est surement faisable ( même si c'est .
Et aussi, il a oublié le plugin pptp. Non pas que ça soit recommendé, mais si j'avais voulu troller, j'aurais mentionner ça pour l'exclure d'autant plus et pourrir nm. Et bien sur, il a aussi oublié le plugin pour openswan. Mais pareil, ipsec, c'est trop compliqué parce que c'est pas openssh.
Il parle de debugguer dbus, mais il connait pas les outils ( mdbus, d-feet, bustle ). Soit. En fait, c'est du pur FUD car il part du principe que :
1) dbus loggue dans journal et pas dans syslog
2) dbus loggue exclusivement dans syslog
3) dbus voit un traffic digne de la gare central de Shinjuku
Le 1 n'est pas vrai que je sache, et ne le sera peut être pas. Le 2 dépend de 1, mais que je sache, d'aprés la FAQ :
"You may run rsyslog or syslog-ng side-by-side with journald, and syslog messages will end up in both rsyslog/syslog-ng and the journal".
Quand à 3, si on part du principe que les desktops utilisent à fond dbus, un coup de dbus-monitor va montrer que le traffic est quand même loin de ses peurs et doutes. Et on peut imaginer que si ça devient si problématique, que quelqu'un va finir par écrire un outil capable de gérer ça.
Donc, le jour ou dbus et journal ne marcheront pas ensemble, il va falloir debugguer ça à l'ancienne, avec des -v, des --nofork et de gdb. Alors que si un soft random et syslog ne marche pas, faut débugguer ça à coup de -v, de --nofork, et de gdb. Vraiment, le futur me fait peur.
Donc bon, je lui souhaite bien du courage pour sa conclusion. Je peux comprendre la quête de simplicité, je peux comprendre que tout le monde n'aime pas les choix fait par Fedora, je demande même pas à comprendre pourquoi ou à convaincre. Mais le manque de sérieux d'une part des points soulevés me laisse songeur face à quelqu'un qui commence par aligner des compétences sur l'historique des systémes UNIX. Et même si je laisse le bénéfice du doute, j'en demeure pas moins plus que non convaincu, voir même échaudé par la communauté BSD.
[^] # Re: Ça sent le réchauffé…
Posté par Batchyx . Évalué à 5.
Tu à déjà essayé d'utiliser nmcli ? Réellement ?
Simple test : montre moi comment me connecter sur un réseau Wi-Fi sécurisé (paramètres exacts inconnus, sauf pour le SSID et la passphrase) avec une IPv4 fixe. En chronométrant le temps que t'a mis pour lire la doc. Parce que moi je n'ai pas lu la doc pour utiliser nm-applet, ni pour éditer /etc/network/interfaces.
[^] # Re: Ça sent le réchauffé…
Posté par zebra3 . Évalué à 2.
Oui, mais seulement pour ce qu'il est : il sert à contrôler, pas à configurer. La config, c'est dans /etc/NetworkManager/.
Déjà, tu pars de la doc (lien que tu obtiens depuis la doc du site officiel) et tu crées une connexion dans /etc/NetworkManager/system-connections/ssid :
Je précise que je n'avais jamais fait ça avant. Donc ce n'est pas si insurmontable, non ?
Je dirais dix minutes, mais je n'ai pas testé. De toute façon, on lit la doc une fois, et quand on a pigé, on n'a plus à la lire.
Reste qu'avant on critiquait NM parce qu'il n'avait pas de doc, et maintenant on critique parce que la doc est longue à lire ?
Admettez-le, vous n'aimez pas NM parce que ça bouleverse vos habitudes, c'est tout.
Tu vas nous faire croire que tu sais tout configurer sans lire la doc, sauf NM ? C'est bien pratique pour critiquer, tiens.
À ce compte-là, on peut tout critiquer : je n'ai jamais lu de doc pour utiliser Windows, parce contre j'ai lu plein de pages man Linux. Est-ce qu'on peut déduire que Windows est mieux que Linux ? J'ai lu la doc pour vi mais pas pour Notepad, donc Notepad est mieux ?
Au passage, tu sais configurer /etc/network/interfaces pour avoir une IP dynamique mais avec des DNS prédéfinis ? Parce que j'ai dû lire la doc pour le faire.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Ça sent le réchauffé…
Posté par Batchyx . Évalué à 4.
Donc il n'y a rien pour configurer en ligne de commande.
Encore faut-il connaître, ces foutus paramètres. Sachant qu'en Wi-Fi, la méthode normale et standard pour récupérer les paramètres, c'est de regarder les informations qu'il y a dans le beacon du point d'accès/élu (Oui, tu sais la, le machin qui contient le SSID, le type de cryptage et tout le reste quand tu cherche un réseau). Et non, j'ai pas envie de sortir tshark et une interface en mode monitor pour découvrir si l'AP est en WPA 1 ou 2, avec CCMP ou TKIP et tout le reste. Oui je sais, iw et iwconfig permettent de sortir les IE en hexa, que je devrai connaître par cœur... C'est ça, ouais.
Seulement si le format du fichier de conf est naturel et logique. Avec ifconfig, je n'ai jamais besoin de regarder la doc. Mais là, sortir un fichier aussi long de ma poche, non je sais pas faire. Surtout que lorsqu'il y a une erreur de syntaxe, le message d'erreur est planqué dans syslog, et il est incompréhensible pour un humain.
De mémoire, voici ce que serait un fichier de conf wpa_supplicant, rien que pour les paramètres wifi
Et non, je n'ai pas regardé la doc. Et j'ai pas du en écrire depuis des lustres.
Non seulement la doc de NM est longue, elle est aussi nulle, parce que elle te décrit comment NM est un programme qui n'est pas fait pour être utilisé autrement que par nm-applet. Essaye de l'attaquer en D-Bus, aussi, pour voir.
Faut arrêter un peu : un /etc/network/interface pour se connecter à un réseau en clair avec iwconfig (ce qui est mal), ça doit être dix lignes. mon script wpa_supplicant, ça doit être 6 lignes. Ton machin minimal, c'est déjà 18 lignes et en plus ça marche pas.
Y a des fichiers de configs qui sont vraiment fait pour être lisibles et utilisables par des humains, et d'autre non.
Normal, y en a pas. La seule méthode d'apprentissage sur ce système, c'est de l'essai et de l'erreur (fatale). Il y a des articles sur microsoft.com, mais tu n'y comprend rien.
C'est la faute à dhclient. Et encore, essaye de le configurer pour qu'il ignore le serveur DNS du serveur et ne configure aucun DNS; C'est juste impossible avec les derniers dhclient, merci l'ISC. Et je ne parlerai pas de la non-lisibilité du code source. Ah merde, j'en ai parlé...
Et sinon, tu fait ça comment avec Network Manager ?
# Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Ozz . Évalué à 6.
Il y a 2 jours, je me suis retrouvé sur un réseau sans dhcp avec ma nouvelle machine où j'ai décidé de ne pas virer les supers nouveautés pour une fois.
J'ai pas nm-applet sous la main, je ne connais pas les interfaces cli, bref je me dis que je vais faire simple:
# /etc/init.d/network-manager stop# ifconfig eth0 192.168.1.42No problemo, ça roule... 2 minutes... Parce que 2 minutes plus tard eth0 n'a plus d'ipv4 et j'ai une nouvelle interface eth0:avahi avec ip link-local.
Et je peux killall avahi avahi-autoipd, virer le droit x sur les bidules avahi dans /etc/network, rien n'y fait... la solution a été un apt-get remove --purge avahi-autoipd + reboot.
J'ajoute un
pulseaudio --killpour retrouver du son hier, et un alsamixer (c'est quoi l'équivalent pa?) qui segfault avant hier, et je conclus que je suis fan du nouveau desktop linux.Ok, je n'utilise probablement ces machins comme il faudrait, et c'est sur une debian testing, et c'est des anecdotes sans intérêts, mais j'ai besoin de parler de mes petits soucis parfois.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Albert_ . Évalué à 3.
Tu dois pas utiliser RH/Fedora et non je ne rigole pas, les trucs dont tu parles ne fonctionne correctement que sur cette distribution (enfin d'apres les fans de RH/Fedora...).
Et j'aime pas trop que des technos qui sont "force" et qui sont tellement simple a installer que en dehors de la distrib qui emploie les createurs personnes n'arrive a installe/configurer ca correctement...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par zebra3 . Évalué à 1.
C'est marrant, tout ça marche aussi sur mes Debian… Faudra que je vérifie que je n'ai pas installé des Fedora, si ça se trouve…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par inico (site web personnel) . Évalué à 1. Dernière modification le 16 février 2012 à 18:25.
NetworkManager ignore, sous Debian, les interfaces configuré manuellement dans /etc/network/interfaces, donc:
Puis ifup eth0 et NetworkManager te laissera tranquille.
On peut faire strictement pareil sous Fedora et Redhat (/etc/sysconfig/....) ...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 6.
Et si eth0 n'est pas spécifié explicitement, mais via un mapping (exemple : t'utilise guessnet pour faire de l'autodétéction via requête ARP. Encore l'un des trucs tout bêtes que network-manager ne supporte pas), ça continue à marcher ? Ah non. Et encore, y a pas si longtemps que ça, NetworkManager était très tatillon sur le format possible de /etc/network/interfaces, en interdisant par exemple la combinaison d'espaces et de tabs pour l'indentation ou pour séparer les options de leurs valeurs...
Et savait tu qu'avec les derniers ifupdown tu pouvait désormais splitter ton /etc/network/interfaces en plusieurs fichiers ? Ah ben non, NetworkManager le supporte pas...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par inico (site web personnel) . Évalué à 3.
D'après la doc de NetworkManager, on peut forcer NetworkManager a ignorer une interface a rajoutant dans /etc/NetworkManager/NetworkManager.conf/:
Ce qui exclut de NetworkManager tous les carte réseau ayant la MAC 00:22:68:1c:59:b1.
Est-ce suffisant pour faire ce que tu souhaite ?
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 3.
Oui, ça résoud le problème dans ce cas ... Encore faut-il en être au courant, une option dans l'interface graphique, ça serait trop demander ?
Mais de manière générale, j'aurai bien envie d'un moyen pour dire à NetworkManager d'arrêter de toucher à une interface, parce que je vais y faire des choses en dehors de sa portée. Le problème, c'est que, généralement, ces "choses" détruisent des interfaces et en créent d'autres avec des MAC différentes ou inexistantes ...
Sauf que pour moi et pour beaucoup d'autres utilisateurs, la méthode la plus simple reste trop souvent de purger NetworkManager...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par inico (site web personnel) . Évalué à 1.
D'après le man de nmcli, nmcli nm sleep true endort NetworkManager.
C'est sensé être utilisé avant l'hibernation de la machine mais cela devrait repondre au besoin.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Albert_ . Évalué à 2.
Je ne veux pas l'endormir mais le tuer. C'est a dire degager le !@$!$!$@# de daemon derriere.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par zebra3 . Évalué à 2.
ben apt-get autoremove --purge network-manager
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Albert_ . Évalué à 3.
Ca c'est ce que je fais mais cela confirme bien qu'il est pas possible de tuer une process NM sous Linux et cela ME pose probleme!
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par inico (site web personnel) . Évalué à 2.
Tu peut tuer NetworkManager.
Je ne vois pas ce qui le relancerai (à part upstart ou systemd mais cela se désactive aussi).
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par zebra3 . Évalué à 2. Dernière modification le 20 février 2012 à 09:58.
Chez moi, quand je lance /etc/init.d/network-manager stop, ben il s'arrête.
J'ai l'impression que tu critiques NM en te basant sur l'intégration d'une distrib en particulier. Il marche partout sauf sur la tienne, mais c'est quand même la faute de NM.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 3.
J'ai pas envie d'endormir NetworkManager, j'ai envie qu'il arrête temporairement de toucher à une certaine interface, de manière dynamique, en continuant à utiliser les autres.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 4.
ifconfig c'est le MAL. Il faut utiliser ip maintenant. C'est d'autant plus vrai lorsque tu passera tout ton réseau en IPv6. ifconfig ne supporte pas d'avoir plusieurs adresses IP sur une interface, alors que c'est nécessaire pour avahi-autoipd. Non ça va pas rentrer en conflit avec tout le reste, Le noyau à tout prévu pour, et de manière bien (pas du Lennart); il n'avait pas le choix de toute façon, s'il ne voulait pas rendre l'utilisation d'IPv6 trop chiante. Du coup ça marche en IPv4 aussi. Que demande le peuple ?
Pareil pour route : utilisez ip route à la place, vous serez moins surpris lorsque le noyau prendra des adresses sources bizarres pour aller sur le net, en IPv4 ou en IPv6...
Après, avahi-autoipd pourrait faire autre chose que créer un alias d'interface (encore un de ces trucs vieillots) lorsqu'il se rend compte qu'un truc vieillot lui à pété toute sa conf, mais ça c'est du Lennart tout craché : "Il faut que le programme marche, que l'utilisateur le veuille ou non !".
et dhclient pourrait disparaître lorsqu'on à plus besoin de lui ... mais bon, l'ISC est trop occupé à le récrire en espérant que le code soit moins horrible, puis à le récrire pour la même raison, parce que le code est toujours aussi horrible...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Ozz . Évalué à 1.
Ah, merci pour l'info.
En fait j'avais déjà lu qu'il fallait préférer ip à ifconfig/route, mais vu que ça ne m'avait jamais posé de problème et les vieilles habitudes étant ce qu'elles sont, j'ai fait comme si je n'avais rien vu et j'ai fermé l'onglet en sifflotant.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par totof2000 . Évalué à 2.
Encore un truc qui éloigne les distribs Linux du monde Unix.
Ca me plairait bien maintenant que ce fait soit assumé.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 4.
C'est quoi la méthode de configuration "normale" pour IPv6 dans le monde UNIX, déjà ?
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . Évalué à -1.
C'est quoi la méthode de configuration "normale" pour IPv6 dans le monde UNIX, déjà ?
ifconfig.
Et ça marche très bien.
ifconfig supporte très bien les interface avec plusieurs IP sur des protocoles différents. Sinon il y a des mécanisme d'alias, de bridge et de tunnels pour plusieurs IP sur le même protocole.
Quand à avahiautoipd, le mieux c'est quand même de le lancer seulement si les mécanismes de dhcp se vautrent, et que les tests avec l'ip par défaut/précédente se vautrent.
Et pour finir il ne créé pas plusieurs IP par interface logique.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 2.
On est en 2012. Toute interface physique à au moins une adresse IPv6 link-local, même lorsqu'on à pas de connéctivité IPv6. Lorsqu'on à une connéctivité IPv6, on à deux adresses. On peut même en avoir plus que deux si l'admin le décide. T'a vraiment envie de te panner 2 alias pour une connéctivité normale ? Oui, j'ai dit connéctivité normale, t'aura peut-être besoin des deux pour que ça marche.
avahi-autoipd c'est une blague, c'est l'équivalent des adresses link-local d'IPv6, pour IPv4. Tu peux toujours crier sur l'implémentation qu'est avahi-autoipd (l'implem, c'est du lennart, mais l'algorithme/protocole, c'est normalisé IETF), mais tu pourra pas crier longtemps sur le principe. Sache que ton linux chéri n'a pas attendu avahi-autoipd pour rajouter des adresses IPv6 link local à tes interfaces. Oui, tu en a maintenant. Il faudra vivre avec, tu en aura besoin pour récupérer des adresses globales...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . Évalué à 2.
On est en 2012. Toute interface physique à au moins une adresse IPv6 link-local, même lorsqu'on à pas de connéctivité IPv6
Et une embedded IPv4 et une IPv4 mapped IPv6 et souvent une site-local ou un organisation-local. Déclarée ou non, activée ou non.
On peut même en avoir plus que deux si l'admin le décide
En mode routeur on peut même avoir plusieurs branches.
T'a vraiment envie de te panner 2 alias pour une connéctivité normale ?
Non. Fort heureusement je n'ai pas à le faire, ils sont sur des scopes différents donc tout va bien. J'ai du mal à comprendre de quoi tu parles là.
avahi-autoipd c'est une blague, c'est l'équivalent des adresses link-local d'IPv6
Non c'est un fallback des adresses externes. Ca peut être utilisé autrement mais c'est fortement décommandé.
mais tu pourra pas crier longtemps sur le principe
J'ai crié sur le principe ? Tu compares des choses qui ne sont pas comparables et tu donnes un exemple à coté de la plaque. avahi_autopid va attribuer une adresse et une seule à une interface, en giclant l'adresse en place si il le faut.
Sache que ton linux chéri n'a pas attendu avahi-autoipd pour rajouter des adresses IPv6 link local à tes interfaces.
Oui et ? Encore une fois il n'y a aucun lien entre l'un et l'autre. Ce sont des mécanismes totalement différents.
Oui, tu en a maintenant. Il faudra vivre avec, tu en aura besoin pour récupérer des adresses globales...
Non, non si je veux je les enlève et ça n'empêche pas mes machines de fonctionner très bien en IPv6 full. J'aurais toujours besoin d'une adresse dans un des scopes locaux, mais pas forcément link.
D'ailleurs si j'avais besoin des link-local pour attribuer des global je serais plutôt emmerdé avec mes tunnels, ou même pour attribuer des adresses IPv6 à des devices type switch/firewall qui ont plusieurs liens sur le même réseau....
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 2.
Rien n'empêche d'avoir deux adresses globales sur une même interface ...
C'est quoi un "mode routeur" ?
Si ta distro met de la merde dans ton /etc/avahi/avahi-autoipd.action, peut être. Mais celui upstream pour Linux utilise ip pour rajouter l'adresse, ou crée des alias avec ifconfig si ip n'est pas installé. Donc non.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . Évalué à 1.
Rien n'empêche d'avoir deux adresses globales sur une même interface ...
Non mais vu que la deuxième ne sera pas en autoconf que ce soit statefull ou stateless ca coute rien de créer un alias à ce moment là. C'est même plutôt plus propre si tu veux pas avoir à jongler avec les *-local derrière. Et on n'est plus dans une configuration "normale" dans les deux cas.
C'est quoi un "mode routeur" ?
Le local sur site/organisation en ::2 avec un RAD qui tourne (radvd ou rtadvd)
Si ta distro met de la merde dans ton /etc/avahi/avahi-autoipd.action, peut être
Je sais pas si ma "distrib" fait de la merde, mais c'est ce qui est fortement préconisé par les auteurs du programme eux même. CF http://avahi.org/wiki/AvahiAutoipd
Mais celui upstream pour Linux utilise ip pour rajouter l'adresse, ou crée des alias avec ifconfig si ip n'est pas installé. Donc non.
Que ce soit via ip ou via ifconfig, que ce soit une bonne ou une mauvaise distrib tu auras toujours une seule adresse IP par interface (réelle, virtuelle ou alias). Il n'y a pas de notions de scope en IPv4 donc à un moment ou à un autre se pose la question "avec quelle interface je sors", et comme avahi-autopid préconise un metric de 99...
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 2. Dernière modification le 18 février 2012 à 15:42.
Hein ? la deuxième peut très bien venir de l'autoconf; tu peux mettre autant de préfixes que tu veux dans ton RA.
Pourquoi y a t'il besoin d'avoir un mode routeur particulier dans ce cas ?
Et ces scripts "gicle l'adresse en place s'il le faut" ? ah ben non ... ils appellent avahi-autoipd, qui lui va utiliser /etc/avahi/avahi-autoipd.action au moment de configurer l'interface ... et le /etc/avahi/avahi-autoipd.action upstream ne gicle jamais les IP en place. Si quelqu'un t'a viré tes IP lorsque ton DHCP foire, c'est le script de dhclient.
Non. Tu peux très bien avoir 256 adresses sur la même interface. Et dans le même subnet. Tu peux aussi en avoir 65536, mais le noyau aime pas trop, c'est dans une liste chaînée, il me semble.
La question "avec quelle interface je sors" se pose déjà lorsqu'on à une seule adresse par interface ... Il suffit juste de regarder la bonne table de routage.
Et pour répondre à "une fois que j'ai trouvé la bonne interface, avec quelle adresse je sors si l'appli n'a pas fait de bind()", tu regarde la même table de routage, sur la même entrée, et tu regarde le champ "adresse source préférée si pas indiquée par l'application". Si tu utilise ip route, tu pourra la mettre bien comme il faut. Si tu utilise encore /sbin/route, le noyau choisira une adresse source préférée à ta place, et prendra toujours celle que tu veux pas. Et tant pis pour toi, ça sera de ta faute.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . Évalué à 1.
Hein ? la deuxième peut très bien venir de l'autoconf; tu peux mettre autant de préfixes que tu veux dans ton RA.
Tu vas quand même devoir passer en mode router advanced pour que ça serve à quelque chose. Et donc définir des route, des anycast, des multicast pour chaque prefix,le tout à la mano. Certes maintenant on peut le faire sur le RAD, mais ca ne change rien au fait que ce ne soit pas automatique. En sus j'ignore comment ça fonctionne sous linux dernièrement, mais la dernière fois que j'ai regardé il y avait quand même des interface logiques nommées qui étaient créées dans ce cas là (des alias quoi). Sous BSD tu numérotes tes préfixes dans le RA pour pour que le default route et la prefered address soient facile à sélectionner. Après si tu veux faire de l'IPv6 sauce IPv4 libre à toi de définir toutes tes routes à la main, mais je ne vois pas l'intéret.
Pourquoi y a t'il besoin d'avoir un mode routeur particulier dans ce cas ?
Parce que le local-link doit correspondre à une présence unique sur le réseau. Sinon tu es hors specs. Peut-être que ça marche en config de base avec du local-link, j'en sais rien. Perso vu le bordel qu'est IPv6 j'essaye de rester dans les specs le plus possible.
_Et ces scripts "gicle l'adresse en place s'il le faut" ? _
Vu qu'ils interviennent exclusivement quand l'interface n'a pas su trouver une IP toute seule...
et le /etc/avahi/avahi-autoipd.action upstream ne gicle jamais les IP en place
Ce serait dommage, vu que c'est son boulot. Mais j'imagine que tu voulais dire "dans les distribs avec IPv4LL et ip on fait toujours attention à passer comme interface à avahi-autopid.action une interface avec un pseudo scope local pour ne pas perturber l'interface principale".
Et là la question qui fâche, sais-tu comment ip gére les pseudo scope IPv4 ? En utilisant les mécanismes d'alias.
Non. Tu peux très bien avoir 256 adresses sur la même interface.
Inteface physique oui, interface logique non.
mais le noyau aime pas trop, c'est dans une liste chaînée, il me semble
Tout à fait, tu as le prefered en head et les alias derrière.
Si tu utilise encore /sbin/route, le noyau choisira une adresse source préférée à ta place, et prendra toujours celle que tu veux pas.
Si tu veux on peut discuter pendant des heures de pourquoi le modèle "weak host" de Linux est un nid à bug qui peut foutre une grouille assez violente dans les réseaux avec son lot de routes asymétriques et son ARP qui clignote d'une carte à l'autre.
Sous BSD pour changer l'adresse source il faut passer par une étape de firewalling (PF ou IPFW le font très bien). Ça a l'air lourd comme ça, mais c'est fou le nombre de problèmes qu'on évite sur les systèmes qui ont plusieurs interfaces physiques.
Sous Linux, même si je passe pour un dinosaure j'utilise toujours /sbin/route, et quand j'ai besoin de forcer l'adresse et l'interface je passe par iptables.
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Batchyx . Évalué à 2.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Bien sûr que ça marche...
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Non ?
Non plus. Avahi-autoipd va directement taper sur netlink et observer les interfaces voulues en regardant si elles deviennent up ou pas. Si c'est up, on rajoute une ip. si c'est down, on l'enlève. Et si on rajoute une adresse sur la même interface ... ben avahi-autoipd s'en fout.
Pas du tout, c'est plutôt le contraire : les mécanismes d'alias sont utilisés pour rendre ifconfig compatible avec ip. Il n'y a pas si longtemps, ça n'était pas le cas, d'ou confusion pour les utilisateurs d'ifconfig, surtout avec avahi-autoipd, justement. Y avais des rapports de bug "avahi-autoipd écrase mon IP", alors que non, Internet fonctionne encore. C'est juste que ifconfig affichait seulement la première adresse IP que le noyau trouvait, et qui était, comme par hasard, l'IP link-local d'avahi. L'autre adresse n'était visible qu'avec ip.
Mauvaise configuration, changer configuration ?
Ça doit être génial pour les performances, non ?
[^] # Re: Les trucs qui s'amuse a tripatouiller la conf réseau
Posté par Kaane . Évalué à 2.
Bienvenue en 2012 ? Y a quoi comme distro aujourd'hui qui n'active pas CONFIG_ADVANCED_ROUTER ? Mis à part les distros orienté embarqué ou vielles machines, je vois pas ...
Je ne sais pas si Linux le fait par défaut. Je sais que ça s'active par défaut si tu mets deux prefix dans ton RAD. Je sais aussi que la plupart des gens qui s'essayent à faire du advanced router oublient généralement un ou deux trucs, sont surpris que ça marche pas et finissent par passer en DHCP6 qui est une horreur.
Bien sûr que ça marche...
C'est contraire à la norme, un jour tu vas tomber sur un router/switch/firewall ou autre qui va juste t'envoyer balader, ou qui refusera carrément de dialoguer avec toi. Il y a pas que du Linux sur un réseau.
Et bien tu prend le cas du premier post du fil : Un utilisateur arrive derrière, s'assure que dhclient est mort, puis fait un ip address add 192.168.1.42/24 dev eth0. Avahi va t'il gicler l'adresse ? ah ben non ... t'aura du link-local ipv4 et une adresse administrée localement. Et ça marche.
Le script qui est donné sur la home page de avahi.org n'utilise pas les pseudo-scopes, il est en scope link (donc le prefered de l'interface). Donc si tu fais ip address add sans scope tu vas gicler l'adresse avahi-autoipd CF :
Si tu repasses le script à la main (qui est toujours en scope link) tu vas regicler ta nouvelle adresse et remettre une adresse en 169.x à la place. Fais le test si tu ne me crois pas (avec le script de la home page d'avahi hein).
Maintenant si ta distrib a décidé de lancer quoi qu'il arrive un script autoipd avec un pseudo-scope local, ça la regarde. Mais bon a part du du zero conf à la sauce Apple je vois pas l’intérêt.
Avahi-autoipd il est aveugle et sourd. Tu l'invoque et il s’exécute, tu l'invoques pas et il ne bouge pas. (En tout cas c'était le cas la dernière fois que j'ai regardé et c'est aussi ce qui est marqué dans la doc, maintenant c'est vrai qu'avec Linux ça a pu changer trois fois depuis sans que la donc bouge d'un iota).
La bonne façon de l'invoquer c'est en fin de script dhclient suite à un echec. Maintenant tu peux aussi l'invoquer sur des événements DBus lié à netlink j'imagine. Je ne vois pas ce que ça apporterait une fois de plus.
Non le problème est là en fait :
https://bugzilla.redhat.com/show_bug.cgi?id=132925
https://bugzilla.redhat.com/show_bug.cgi?id=65114
Ca fait 10 ans que ifconfig est "deprecated", il fait la course avec OSS.
Maintenant mettons les choses à plat sur ce qui se passe :
ifconfig utilise inet. Quand on créé un alias avec ifconfig, il y a un hint qui est fichu dans un socket inet, le noyau reçoit le message et créé un alias. Quand ifconfig SOUS LINUX interroge une interface physique, il interroge en fait les sockets inet rattachés à cette interface et récupère les alias des sockets inet.
iproute faisait exactement la même chose avec les sockets netlink.
Donc au niveau noyau les alias étaient en place, mais iproute ne voyait pas les alias créé par ifconfig et réciproquement.
Après moults trolls et autre combats pour que Linux fasse comme le reste du monde (à savoir demander au noyau plutôt qu'aux sockets, mais ça a un cout en terme de perfs et ça aurait entrainé la réécriture d'une partie de la pile IP), il a été décidé qu'iproute lirait aussi les infos d'ifconfig , mais qu'ifconfig étant deprecated il pouvait aller se faire voir (on est alors en 2001).
Dans la plus pure tradition linux, 11 plus tard les scripts d'init réseau n'ont toujours pas été réécrit et utilisent toujours ifconfig. Il a donc bien fallu trouver des gruikeries pour que les sockets inet et les sockets netlink représentent à peu près la même chose.
Non, en fait le format de socket inet ne permettait pas au noyau de donner une réponse complète, à savoir toute les alias sur iptables nommées partaient à la poubelle. Faut dire que la dernière mise à jour de ifconfig sous linux ca date de 1999...
J'ai déjà changé, je suis sous BSD maintenant pour toutes ces sortes de choses. Avec un ifconfig qui est mis à jour régulièrement et qui marche très bien (cf mon tout premier post). Sous les différents Unix Like ifconfig a évolué pas mal au court des 14 dernières années contrairement à Linux. Maintenant si tu veux je peux te donner une série de commandes à passer sous un linux, qui utilise iproute2 sur une machine qui a deux interfaces physiques et qui ont pour effet de péter en morceau l'arbre de recherche ARP de tous les switchs un peu cheap du marché. Bonne ou mauvaise chose ça se discute, mais les BSD ne te laissent pas faire ce genre de clowneries.
De quoi de passer par une règle firewall pour les forwards de paquets depuis une autre IP ou une autre interface que l'IP ou l'interface naturelle ? Non pas du tout.
Et tant bien même ça aurait un impact, il serait toujours nettement plus faible que celui que pourrait générer un logiciel de configuration qui créé une règle firewall nommée par alias et par route comme le fait iproute2.
Le seul défaut est de devoir les palucher à la main là ou iproute2 les créé en automatique, mais vu les dommages collatéraux potentiels je fais partie des gens qui pensent que ce genre de config doivent être faite par un être humain avec un niveau de connaissance assez élevé sur ce qu'il est en train de bidouiller. Mais après ça se discute.
# Migration vers les BSD ?
Posté par Misc (site web personnel) . Évalué à 3.
Moi, un truc que j'aimerais voir, c'est si les changements sous Linux sont si génant pour autant de monde, est ce qu'il y a eu une migration massive vers les BSD ?
Je sais pas vraiment ou regarder pour voir des métriques. J'aurais bien regardé le nombre de commits mais je suis pas sur que ça reflete une augmentation du nombre d'utilisateurs. J'aurais bien regardé le nombre d'article dans les magazines, mais pareil, ça m'a l'air constant et ou en croissance, mais fait par des gens connus des communautés *BSD, donc pas vraiment la preuve d'une arrivée d'utilisateurs. Distrowatch, aussi peu fiable que ça soit, ne liste que openbsd, donc n'est pas pertinent.
Vous feriez comment ? Et avec quel BSD ? ( car bon, autant j'aime bien NetBSD, autant j'ai le sentiment que le projet est un peu au ralenti en ce moment :/ ).
[^] # Re: Migration vers les BSD ?
Posté par ahuillet (site web personnel) . Évalué à 5.
"Moi, un truc que j'aimerais voir, c'est si les lois passées par l'actuelle législature sont si gênantes pour tout le monde, est-ce qu'il y a eu une migration massive vers la Suisse ?"
Cet "argument" n'est pas sérieux. On a parfaitement le droit de critiquer des choix politique a fortiori quand on les vit.
(En ce qui me concerne j'aime bien Linux et tant qu'il y a Archlinux, une distribution qui ne suit pas la politique débile de RedHat/Ubuntu vis à vis de la desktopisation, je serai content... le souci étant de convaincre mes clients que RHEL n'est plus adapté à leur besoin, ce qui sera difficile.)
[^] # Re: Migration vers les BSD ?
Posté par Anonyme . Évalué à 2.
Heu… Arch Linux fournit ce que fournissent les développeurs.
[^] # Re: Migration vers les BSD ?
Posté par ahuillet (site web personnel) . Évalué à 4.
Par politique débile, je parlais du principe d'essayer de forcer les utilisateurs à utiliser certaines technologies (par exemple Pulseaudio sur Ubuntu, qui est une plaie à supprimer). Archlinux te laisse beaucoup plus libre à ce niveau : la distribution ne décide pas pour ses utilisateurs de quelle est la voie du Bien(tm) et ne les force pas à suivre cette voie.
(Je ne dis pas que tout le monde devrait l'utiliser, j'explique simplement que Archlinux a une politique différente - c-a-d pas de politique - de celle mise en place par RedHat et Canonical, et c'est quelque chose de très appréciable au moins dans certains cas.)
[^] # Re: Migration vers les BSD ?
Posté par Marotte ⛧ . Évalué à 4.
C'est-à-dire, laisser les utilisateurs/clients/amis se démerder avec les différentes politiques des différents upstreams.
Pourquoi pas ?
J'ai testé et utilisé brièvement Archlinux, clair que c'est une bonne distrib...
[^] # Re: Migration vers les BSD ?
Posté par totof2000 . Évalué à 2.
Je suis sous NetBSD, et j'y resterai au moins pour mes serveurs perso, et pour mon desktop.
En parallele j'ai un portable sous Arch qui ne me gène pas trop (il y a juste un bug quelque part qu'il faudrait que je prenne le temps de régler).
NetBSD bouge, même si tu ne le vois pas sur leur site. Dernièrement il y a eu une version qui est sortie et il semble que la version 6 ne devrait pas tarder.
Sinon si tu restes dans le monde x86, il y a freebsd qui semble bouger plus vite, ainsi qu'un tas de projets qui se basent dessus et dont le but est de faciliter l'installation et la prise en main par des choix qui sont faits à ta place.
[^] # Re: Migration vers les BSD ?
Posté par Marotte ⛧ . Évalué à 3.
Citons PC-BSD.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.