Journal vos prévisions 2009 ..

Posté par  (site web personnel) .
Étiquettes : aucune
4
26
déc.
2008
Alors, 2009 approche cher journal ?
Que nous prévois tu de beau pour cette année toute neuve encore sous le plastique ?
La sortie de duke nukem forever en exclu sous hurd 1.02 ? Le retour a l'âge de pierre ? et pourquoi pas celui de paul plutôt ?
Allez, une nouvelle guerre pour que les journaleux de nos chaînes indépendantes du PAF puissent enfin raconter quelque chose d'intéressant ? nan parce que la crise, c'est comme dallas ou amour gloire et beauté, on s'en lasse un peu a force, surtout au milieu du premier épisode !
MIR tombera t elle enfin ? ah non zut la c'est moi qui ait encore les pieds humides /o\
A vos moules ... prêts ? trollez !

  • # Hurd become Tux

    Posté par  . Évalué à 6.

    On va changer Hurd en mono kernel , changer son nom en Linux histoire d avoir un kernel qui passe en GPL 3

    • [^] # Re: Hurd become Tux

      Posté par  . Évalué à 0.

      si tu veux, je te présente Nexenta,

      the Nexenta project, the land of free and open source distribution combining the OpenSolaris kernel with Ubuntu userland

      http://www.nexenta.org/

      et en plus ils ont une jolie girafe comme logo, ça peut être que bien !

      • [^] # Re: Hurd become Tux

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

        C'est parce que la girafe est plus grande que le manchot donc il lui pète la gueule a la sorti de l'école. La preuve que nexenta est meilleur que GNU/Linux !

      • [^] # Re: Hurd become Tux

        Posté par  . Évalué à 6.

        > the Nexenta project, the land of free and open source distribution combining the OpenSolaris kernel with Ubuntu userland

        Le "Ubuntu userland" m'énerve bien...
        M'enfin, il suffit de cliquer sur le lien du texte "Ubuntu" pour savoir qu'on a affaire à des abrutis.

        • [^] # Re: Hurd become Tux

          Posté par  . Évalué à 1.

          "M'enfin, il suffit de cliquer sur le lien du texte "Ubuntu" pour savoir qu'on a affaire à des abrutis."

          C'est crai que le lien craint ^^

  • # Jabber aura 10 ans

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

    En 2009, Jabber aura 10 ans, ça j'en suis sûr, ça se passera le 4 janvier :
    http://slashdot.org/articles/99/01/04/1621211.shtml
    Le 4 janvier 1999, Slashdot titrait : « Open Real Time Messaging System »

    C'est Jeremie Miller, l'inventeur de Jabber qui a posté ça :
    « Jeremie writes "Jabber is a new project I recently started to create a complete open-source platform for Instant Messaging with transparent communication to other IM systems(ICQ, AIM, etc). Most of the initial design and protocol work is done, as well as a working server and a few test clients." »

  • # Cfengine v3...

    Posté par  . Évalué à 4.

    ... notamment avec les "templates", permettant de créer un fichier de configuration, à la manière de puppet, qui peut utiliser des templates ERB...

    ... sauf que si cfengine continue à bouffer aussi peu de ressources qu'il n'en prend, ce sera toujours quelques dizaines (fois le nombre de machines) de Mo de RAM économisés par rapport à puppet (20-30Mo consommés par client, pour 40-50Mo alloués, et dans les 90-100Mo pour le serveur : ras-le-bol des béhémoths, surtout s'ils gèrent très mal l'itération sur les tableaux de variables... cfengine ne bouffe que 1-2Mo par client, et sensiblement la même chose par instance du serveur - voilà : ça, c'est pour mon troll moulesque).

    Comptons aussi sur les variables typées (avec l'itération qui devrait être possible quelle que soit la situation), la compatibilité avec les anciennes versions (même si ce ne sera apparemment pas si facile que ça, et qu'on devrait plutôt parler d'inter-opérabilité, c'est toujours mieux que puppet dont les versions récentes du client sont totalement, et parfois, pas de manière évidente, incompatibles avec le vieux serveur, ce que je trouve vraiment très moche), la facilitation de l'ordonnancement des actions via les promesses, ou encore, une intégration avec nagios semble-t-il facilitée...

    Bon, je ne m'avance pas trop en prédisant sa sortie pour 2009 : c'est annoncé depuis un moment, et cette réécriture de ce, déjà très bon, logiciel (même si pas forcément facile d'accès) devrait sortir en janvier.

    • [^] # Re: Cfengine v3...

      Posté par  . Évalué à 3.

      Pas la peine de donner des arguments contre Puppet, c'est mal conçu dès le départ. Dommage que les bonnes idées soient perdues au milieu d'une architecture qui pose problème.

      Un des trucs les pires avec Puppet: c'est la partie cliente qui télécharge tout (enfin pas tout, j'exagère) et qui décide ce qui lui est destiné ou pas, qui gère les variables et le reste. Donc si on a une partie de la configuration qui ne s'applique qu'à la moitié de son parc, c'est téléchargé dans tout le parc quand même. Et si c'est en rapport avec la sécurité, tant pis :-) Autant utiliser ssh avec des scripts, au moins on n'a que nos propres bugs.

      Cfengine c'est un peu brut de fonderie, mais ça fonctionne bien. Et longtemps.

      • [^] # Re: Cfengine v3...

        Posté par  . Évalué à 3.

        > Un des trucs les pires avec Puppet: c'est la partie cliente qui télécharge tout (enfin pas tout, j'exagère) et qui décide ce qui lui est destiné ou pas, qui gère les variables et le reste.

        Oui, c'est le principe du "pull" (je tire), par opposition au "push" (je pousse) de la configuration... sauf que... c'est pareil avec cfengine (auquel je me suis mis depuis deux bons mois)... ou alors, j'ai vraiment loupé quelque chose ?

        A priori, lorsque tu fais un cfrun sur un serveur (ou plus généralement, une machine qui a un "grant" vers les cfagent des clients qui t'intéressent et qui sont dans le cfhost), la seule chose que tu fais, c'est faire que les clients exécutent leur cfagent, en "pullant" leur config à partir d'un serveur...

        Après, tu mets des barrières avec des ACL (via les "grant", justement), mais à ce niveau, c'est kif-kif entre les deux... c'est peut-être chiant de bien séparer (surtout pour des clés uniques à chaque machine), mais pour ça, le principe est le même entre les deux applis...

        Le plus lourd, c'est de faire les bons "grant" sur le cfservd qui a les politiques du site... après, tu peux passer par le même cfagent.conf, très générique, mais lequel va faire venir un import.conf qui va dépendre du nom de domaine ou d'hôte, par exemple : ainsi, pas d'exposition inutile de données sensibles (si, dans ce cas, on fait confiance à son DNS)...

        Sinon, tu peux aussi passer par un rsync ou assimilé, pour faire ton "push"... mais techniquement, même si ça y ressemble avec cfrun, cfengine n'en fait pas, de "push"...

        Alors, certes : c'est lourd... mais le "push", c'est dangereux - imagine que le réseau tombe pendant que tu es en train de forcer l'envoi de ta config... c'est la ca-ca, c'est la ca-ta, c'est la : ca-ta-strophe... la config est à moitié appliquée, et ton système client est mal, très mal. Maintenant, pour les clés d'hôtes SSH, backuppc, et cie, si quelqu'un a une meilleure manière de faire qu'un "grant" par hôte, je suis preneur.



        Non, au final, il y a de bons trucs dans puppet (expressivité du ruby, grosse abstraction, même si elle peut être lourde à redéfinir, auquel cas revenir à bash/perl est plus simple pour cfengine, modularité, ...), mais reste que je le trouve bloaté jusqu'à l'os (occupation/allocation mémoire, plantages aux erreurs imbitables - et puis, qu'est-ce que c'est que cette mode des démons lourds en langage interprété ?) et beaucoup trop jeune (pas d'itération sur les variables dans les exécutions de commande dans un terminal, ou test logique un poil avancé qui viennent tout juste d'être intégrés... ah ouais : super pour étendre le bousin, tiens... et j'en passe)... même si je veux bien lui reconnaître qu'il apporte quelques bonnes idées et de la diversité où il en manque, ça ne transforme certes pas la comparaison puppet/cfengine, sur le site du premier, par son auteur, en autre chose qu'un troll éhonté, ridicule et auto-masturbatoire (oui, je sais : faut bien vendre, m'enfin)...

        ... quand à bcfg2, sa conf en XML suffit à me faire saigner des yeux... je ne comprends toujours pas comment on peut avoir l'idée de demander aux gens d'éditer ce genre de trucs... ou alors, faudrait générer la conf bcfg2 avec quelque chose de plus haut niveau, et de lisible ? Je préfère ne pas savoir... sinon, je crois qu'il est plus "push" que "pull", mais je ne saurais en jurer... "XML ma tuer" avant.

        Bref, vivement cfengine, mon préféré, en v3,... Ah, tiens, d'ailleurs, ce seront ses 16 ans, cette année.

        • [^] # Re: Cfengine v3...

          Posté par  . Évalué à 3.

          j'ai vraiment loupé quelque chose
          C'est moi qui ai dit une bêtise :-)
          Je n'ai tellement jamais eu de problèmes avec cfengine que je n'ai même pas mémorisé ce défaut. Cela dit je suis revenu aux bon vieux ssh, y compris pour les installations (quasi) automatisées.

          Comment faire du pseudo push: le client se connecte au serveur en lui déclinant son identité (autentification forte de préférence). Le serveur répond gentiement (idem) et prépare lui-même les données "toutes cuites". Le client n'a plus qu'à cueillir les données pré-digérées. C'est le principe de tous les serveurs "normaux" (web, mail etc).

          C'est exactement le même principe qu'un serveur web avec du PHP ou du Ruby dans les pages: c'est le serveur qui s'occupe d'exécuter les pages, pas le client.
          Avec cfengine et Puppet, c'est comme si le client web recevait les pages brutes et exécutait les scripts (genre je me connecte à la base de données, on voit tout de suite que c'est idiot).

          • [^] # Re: Cfengine v3...

            Posté par  . Évalué à 4.

            > c'est comme si le client web recevait les pages brutes et exécutait les scripts (genre je me connecte à la base de données, on voit tout de suite que c'est idiot)

            Idiot, je n'irais pas jusque là : je dirais plutôt "délicat". Par exemple, pour ce qui est des mots de passe d'administration, j'utilise sudo avec une identité que je réserve pour ça : en revanche, je ne mets pas le même mot de passe pour toutes les machines ; ie j'en ai un pour la DMZ publique, un pour la DMZ privée, un pour les stations en accès public, et un pour les machines qui ont un rapport avec l'administration - et bien, c'est facile : ça fait quatre sous-domaines et quatre "grant", chacun vers le fichier qui contient les mots de passes hashés idoines pour le sous-domaine.

            Pour les clés d'hôtes, les démons qui ont besoin d'avoir des mots de passe, et cie, comme je l'ai dit, un "grant" par hôte.

            Pour le reste, de toute façon, je me fous qu'on accède aux fichiers de conf : les seules clés SSH à copier sont publiques (bon courage pour choper mes clés privées : elles sont dans des smartcards, qui sont dans des poches de mon futal), et la plupart des fichiers (bashrc, conf d'aptitude, ...) ne sont pas sensibles, puisqu'identiques entre chaque machine, et même accessibles en lecture aux utilisateurs potentiels du système... cela dit, comme je fais déjà une ségrégation par "grands" sous-domaines (pour le "shadow") et par hôtes (pour ce qui l'est, privé), j'en profite ainsi pour que tout le monde n'ait pas accès à toute la configuration (genre, ma DMZ publique, avec Exim et cie, n'a aucune idée que j'ai du serveur MythTV, deux CUPS et va savoir quoi, grâce aux imports dynamiques en fonction du nom de domaine, qui impliquent une conf cfengine séparée, et inaccessible pour les autres, mais aussi via du DNS séparé, et du firewall comme il faut [je réfléchis quand même à IPSEC, à l'occasion de mon futur passage à IPv6], entre autres).



            Le tout est d'être précautionneux, cohérent, et de ne pas donner accès à n'importe quoi, à n'importe qui... dans ce cas, le "pull" est, m'est avis, plus sain que le "push", ne serait-ce que parce que l'application de la conf ne dépend pas directement d'une connectivité à un instant "t" (chacun de mes quatre sous-domaines vérifie sa config toutes les 20 minutes, mais ils le font en décalé de 5 minutes - ce qui fait que le moindre trifouillage de câble réseau pendant 5 minutes aurait 100% de chances d'être nuisible, avec du push)...

            Sinon, on peut aussi coupler le "push" avec cfagent via autre chose (SSH, rsync, ...) : on force la copie de fichiers dans le "inputs" des clients, avec un fichier de contrôle pour marquer que la copie a bien été faite (pour parer aux coupures de réseaux, et aux fichiers à moitié copiés), puis on laisse cfagent les manipuler - ça peut éviter de se prendre les pieds dans les "grant" (mais ça fait intervenir davantage d'outils, et c'est donc potentiellement plus casse-gueule que de n'en avoir qu'un, qu'on maîtrise bien - après, l'idéal serait d'avoir tout ça dans un seul outil - oui-da).

            Après, à chaque admin, à chaque site, ses pratiques... moi, je fais ça pour m'amuser, avec deux vieux Athlon-XP en guise de serveurs, et 4 PC clients (plus d'autres clients, qui tiennent plus de l'artefact que du PC, comme la Squeezebox ; m'enfin, pas de cfengine pour eux ; sauf en ce qui concerne le routage, les serveurs auxquels ils accèdent, ...)... OpenVZ me permet de faire tourner entre 20 et 30 serveurs (entre 40 et 50, à terme - par exemple, Exim, Dovecot, Fetchmail, ou encore RSS2mail ont chacun leur conteneur... j'ai aussi plusieurs DNS autoritaires et récursifs, afin de bien compartimenter... et j'en passe : moult), et pour que tout soit uniforme facilement (y compris les clients), quelque chose comme cfengine, si manié avec dextérité et précaution, c'est quand même génial.

            Même si faire gaffe à ce qu'on fait avec lui peut passer par des changements dans les manières de faire, et dans l'organisation du site, c'est aussi une occasion de revoir la cohérence de ce dernier : s'il y a trop de choses à y modifier pour faire les choses proprement avec Cfengine, c'est l'occasion de se poser des questions, et, pourquoi pas ? d'optimiser...

            Là où, en revanche, j'abonde dans le sens de tes remarques, c'est que des exemples de comment gérer proprement ce genre de choses, je n'en ai trouvé ni pour puppet, ni pour cfengine... dans un cas comme dans l'autre, la doc est bonne (très bons tutoriels et manuels de référence, pour chacun), mais ne couvre que des usages vraiment basiques, et pas ceux qu'on _va_ rencontrer dans un vrai site, avec plusieurs domaines, et des données sensibles. En gros, ils se contentent d'expliquer le "quoi", mais pas trop le "comment" ni le "pourquoi", ce qui augmente forcément la difficulté pour venir à les utiliser proprement.

            • [^] # Re: Cfengine v3...

              Posté par  . Évalué à 3.

              Addendum : 'fin pour résumer, tout dépend des ACL (ce qui serait de toute façon le cas pour le "pseudo push" dont tu parles, pour que n'importe qui n'accède pas à n'importe quoi, ce qui revient exactement au même que ce que je fais - les "grant", ça va dans la conf du cfservd, donc le serveur est de toute façon le seul à les connaître ; et le seul où je les configure)...

              ... et les ACL, c'est chiant à mettre en place : rien de neuf sous le soleil ;)

  • # C'est l'année de Linux sur le desktop....

    Posté par  . Évalué à 8.

    2009, c'est sûr sera l'année de linux sur le desktop!

    Les assembleurs/vendeurs de PC vont s'apercevoir que linux est plus performant, facile d'utilisation, moins difficiles à prendre en main et surtout moins cher et donc que ça va relancer leurs ventes en temps de crise.

    Donc ces même vendeurs vont passer sur du 100% linux (même apple va laisser tomber MacOS X)...

    Enfin!! Depuis le temps qu'on attendait çà..... et qu'on en était tous certains!

  • # linuxfr

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

    Linuxfr sera toujours mieux à vent

    • [^] # Re: linuxfr

      Posté par  . Évalué à 0.

      Normal, c'est grenelle !

  • # JLA

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

    Pierre Tramo sortira un MultiDeskOS entièrement en java (évidemment) et bien sûr il fera tourner Duke Nukem Forever.

    Hurd fera du son (oupa) et avec un translator bien placé on pourra écouter la FSF song en français de manière transparente (avec la version rap, techno, etc.).

    Linux sera prêt pour le desktop grâce à INX [http://inx.maincontent.net/].

  • # Environ 50% des prévisions seront fausses.

    Posté par  . Évalué à 3.

    --> [] malgré les prévisions météo peu engageantes.

Suivre le flux des commentaires

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