Alors, l’intérêt d'un nom de domaine est multiple.
D'abord, tu peux avoir le nom de domaine et changer de platforme d’hébergement. Le jour ou github sera devenu le nouveau sourceforge, les gens seront content de pouvoir basculer.
Ou si tu décides d'aller vers cloudflare ou un cdn devant ton site web, c'est pareil, un nom de domaine me semble requis.
Ensuite, si ton projet grandit, tu as parfois besoin d'avoir de l'infra en plus qui est pas exactement celle que propose github ( le cas qui me vient en tête serait d'avoir ton propre cdn, ton propre CI, etc ).
Je doute que ça soit le cas pour guake, mais c'est pas non plus impossible à envisager. Il y a suffisament de projets ou les CI existants sont pas suffisants ( parce que tu es pas root, parce que la plateforme est importante, parce que tu veux aller au dela des 2 versions d'ubuntu de travis, parce que tu as une communauté assez grande et github suffit pas pour la gestion des identités, etc ).
Parfois, tu trouves ça classe d'avoir ton alias mail. Ça simplifie quand même grandement la vie quand tu changes de provider mail, ou que des gens quittent le projet.
Enfin, je pense que si jamais tu as des histoires de trademarks, avoir le nom de domaine depuis X années peut aider quand même à convaincre que tu as utilisé le nom du projet depuis assez longtemps.
Tu peux faire un transfert de l'argent, puis annuler le transfert une fois que le nom de domaine est sous ton controle /o\
Ou tu peux lui faire appeler un numero surtaxé en france pour discuter avec toi, et une fois que tu as chopé les 400$ , tu lui verses, et il aura sa facture à la fin du mois .
D'un point de vue purement pragmatique, le fait de ne pas avoir d'ip stable et en multicast rends la solution moins attractive pour la configuration par défaut.
Du coup, on passe d'une ligne de config à "avoir une liste de serveur DNS dont on est pas sur de la survivance sur 5 ans". Ce qui deviens un patch plus intrusif à maintenir, vu qu'il faudrait soit coder en dur 3/4 serveurs de la liste ( ce qui est un risque ), soit avoir la liste des serveurs sur le disque, et la garder à jour ( donc accepter que le dns ne marche pas la première fois, surtout pour mettre les mises à jours ). Et rajouter aussi du code pour trouver le DNS le plus proche d'un point de vue réseau, alors que c'est le boulot du réseau de faire ça ( et la latence du DNS est importante quand même ).
Alors on va me dire que Google n'a pas vraiment un historique au niveau de garder les choses en marche longtemps, mais je pense qu'ils ont plus de moyen et plus d'appareil qui dépendent du fait que 8.8.8.8 réponde.
Mais bon, peut etre que c'est une vaste conspiration plutôt que le fait de pas vouloir maintenir un patch que personne n'a jamais écrit, sans doute parce qu'il est plus facile de râler sur un volontaire que de réfléchir à une solution.
Non, c'est la tendance qu'on retrouve partout. Soit tu fait des paquets et du code, soit tu es considéré comme un merde avec des talents périphériques.
Exemple:
- pendant trés longtemps, tu voulais avoir un droit de vote et un email @debian.org, il fallait devenir packageur. Les autres contributions ne comptait visiblement pas.
Autre exemple, tout le monde s'estime compétent en expérience utilisateur, même quand les gens sont pas capables de s'exprimer et d'employer le vocabulaire du domaine, et c'est un signe de non reconnaissance de l'expértise des gens qui bossent dedans ( et du coup, faut pas s'étonner de pas les voir venir se faire pourrir )
Ou le manque de considération qu'on donne aux documentations et/ou aux traductions, qu'on va voir comme tache pour débutant.
Ou tout ce qui est proche de l'application d'une forme d'empathie est vu comme une perte de temps. Discuter sur irc avec les utilisateurs, passer du temps sur les mailings listes de support, etc ( et c'est un truc qu'on retrouve aussi dans les startups : http://www.laurenbacon.com/women-tech-empathy-work/ )
Mais, oui, c'est bien que ça change, et qu'un peu de diversité dans la contribution arrive, et qu'elle arrive parce qu'il y a un début de diversité tout court sur des plans autre que la géographie et le type de bureau favori.
mais toutes ces informations sont enregistrées d’une façon
cohérente dans tous les fichiers de logs et sont parsables sans
surprise).
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Les programmes qui se chargent eux-mêmes de leurs propres logs
(souvent avec leur propre format) au lieu de passer par le
démon de journalisation du système poseront toujours problème,
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
Non, parfois deployer une machinerie complexe style ELK, Graylog, splunk n'est pas une meilleur option si ça te rajoute juste du taf sans rajouter des fonctions significativement requises.
L'admin sys, c'est pas gratuit, et je pense qu'il faut prendre sa remarque dans cet optique aussi.
la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.
J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.
Bah, si tu veux la réponse, tu peux te poser la question à toi même.
Sinon, ça existe déjà, ça s'appelle SQL ( le standard SQL qui date d'avant awk, je tiens à rappeller ). Tu as tes données, tu fait des selects, des LIMIT, des clauses WHERE, etc comme tu ferait avec grep/awk/sed. Et des requêtes sur les requetes, pour les bases de données assez avancés. Et des stockages en tables temporaires aussi, si tu as envie.
Sinon, plus prosaïquement, le reste du monde n'a pas attendu que tu te poses des questions, et le monde scientifique a depuis longtemps des notebooks, comme zeppelin, ipython/jupyter. Sans vouloir trop m'avancer, je pense que l'inspiration vient de maple ou mathematic, et que l'idée, c'est d'avoir un cli amélioré via le browser.
Et pour tout ce qui est big data, ç'est le truc que propose tout les éditeurs de ce que je vois du marché.
Par exemple, Zeppelin te permet d'interroger ton cluster spark pour faire des requêtes sur les flux en streaming, requêtes qui sont peu ou prou semblables aux concepts de grep/awk/etc. Et q
Tu fait des fausses dichotomies. C'est surtout dépendant de comment tu spécifie ton format.
Si tu dit "le timestamp est une chaine de maximum 10 caracteres", alors le jour ou tu passes à 11, tu casses tout et c'est du texte.
Si tu as un format binaire avec un entête qui donne la longueur ou ce genre de choses ( ce qui est fait par exemple en ipv6 ), alors tu peux gérer la transition.
Et les délimiteurs sont pas sans poser des soucis, tel que "devoir les échapper". je fait quoi si j'ai besoin d'avoir un espace ou ':' dans ma chaine ?
Le gros avantage du texte, c'est la stabilité très longue durée
(Unix à plus de 40 ans). Un format binaire est incapable de
vivre aussi longtemps. Par exemple du C de 1990 est toujours
compilable à l'heure actuelle, même s'il peut être difficile
de l'exécuter (problème de librairie). Un binaire, c'est
quasiment impossible d'en tirer encore quoi que ce soit.
Tu aurais du commencer par ça, parce que la, j'aurais compris que tu as visiblement aucun recul et que tu mélanges tout. J'aurais pas pris la peine de répondre.
Primo, tu peux toujours lire les fichiers zip et afficher les bmp des années 80. Donc tu repasseras pour le fait d'être incapable de durer aussi longtemps. La principale raison de la longévité d'une information, c'est d'avoir un standard qui décrit quoi faire des données, pas d'être au format texte. Par exemple, va prendre des fichiers xml sans avoir la dtd ou l'info de ce que doit faire, tu va t'éclater à tirer des informations de ton format "perenne" en mode texte.
Secondo, si ton programme C des années 90 est compilable, y a des chances qu'il s’exécute aussi. Pas forcement qu'il s’exécute correctement si il fait de la merde toléré à l'époque qu'on bloque maintenant. Ça a beau être du texte, encore une fois, ce qui est important, c'est l'usage qui est fait de l'information, pas le format.
D'après stackoverflow, il suffit juste d'utiliser le module struct de python. Parait que c'est un langage sympa, faudrait regarder.
Mais je pense que la question est purement réthorique, parce que malgré la doc présente sur le web ( http://www.freedesktop.org/wiki/Software/systemd/journal-files/ ) depuis des années et le fait qu'il existe 2/3 bouts de code pour le faire ( https://github.com/Lagg/c3-code/blob/master/journal.c et https://github.com/Laird-Dave/journaldparser/blob/master/extractor.py ), le fait est que personne n'a pris la peine ( ie, l'aprés midi de travail ) de faire quoi que ce soit de propre pour windows ou pour mac. Ça montre surtout que l'intersection des gens motivés et/ou capables de coder pour ces platformes et des gens ayant le besoin est proche de pas grand chose. Et c'est pas faute pourtant d'avoir des tas de gens qui disent qu'il faut le faire, vu le nombre de commentaires disant qu'il y a un souci et tout va exploser.
Si franchement, un mec arrive à coder ça dans le cadre d'un tutorial youtube en écrivant les 250 lignes requises de code, c'est que ça doit pas être si terrible.
Donc si c'est pas la difficulté qui bloque, soit c'est parce que les gens sous Windows sont incapables, soit ils ont pas le besoin. Je ne pense pas que les Windowsiens sont incapables, et vu les pavés que hervé poste sur ce thread, je pense pas qu'on puisse garder l’hypothèse qu'il n'a pas le temps ( ça m'a pris 5 minutes de recherche sur le web pour trouver le code ).
Donc j'en conclus que le besoin est suffisament faible pour que quelqu'un se motive à faire un truc.
Et c'est pas vraiment compliqué de voir pourquoi. Si c'est sur un serveur, la majorité des OS utilisé ayant systemd a également les logs en texte à coté, cf config RHEL/Centos, et Debian, en partant du principe qu'il y a pas autre chose mise en place, genre splunk, ELK, etc.
Si c'est pas sur un serveur, c'est sur un poste client et/ou embarqué, ou une variante. Et si c'est sur un poste client, y a des chances de préférer un Linux par la.
Encore une fois, prendre le code python que j'ai pointé, en faire un module qu'on met sur pypi, faire des builds kivonbien, c'est moins d'une journée de travail pour quelqu'un d'assez compétent. J'ai écrit un gem ruby en partant de 0 en moins de 4h depuis un café en république tchèque y a grosso modo 1 an, donc j'imagine que pypi doit pas être fondamentalement plus complexe.
Donc si le but était d'être constructif plutôt que de déposer une énième logorrhée sur Linuxfr, quelqu'un s'y attellerait. Personne ne s'y attelle, donc je conclue que le but est juste de râler.
Moi, je pourrais en effet faire ce module, mais je vois pas pourquoi je devrais consacrer du temps gratuit à une plateforme que j'utilise pas, que j'ai pas envie d'utiliser. Mais si quelqu'un me file des thunes, je peux changer d'avis. J'ai l'intuition que personne ne va rien donner, donc ça doit pas être si critique que ça.
s/gaspillé/dépensé dans des boites francais ou certains ici bossent/
Faut aussi se dire que des gens chez Thales et EADS, y en a des tonnes. Que si les informaticiens sont pas au chomage, c'est grâce aussi à ça. Qu'on a Amesys, des cabinets de conseils ( HSC, etc ), et tout un tas d'acteurs qu'on retrouve pas forcément ailleurs.
Et que si on a des tonnes de confs de secu ( stiic, nuit du hack, hackito ergosum et les autres dont j'ai oublié le nom ) en france, c'est aussi ça parce que les gens qui s'intéresse à ça trouve du boulot, et donc font des affaires pour gagner leur vie.
Donc l'influence de lobbying de toute cette industrie ( dans laquelle j'ai bossé ) est un point non négligeable de tout ça. Un point qu'on voit pas souvent mis en avant, et qui est pourtant existant.
Et je parle pas non plus de experts en machine learning francais comme tinyclues ou criteo et tout ça, qui font que dans l'esprit des gens ordinaires, on peut faire des miracles avec les algos, et qu'à force de dire "on est suivi par google et facebook", personne ne se dit que ça cimente l'idée que c'est faisable et facile. Et c'est pas les vendeurs de solutions qui vont dire le contraire.
Spoiler: 1984 est une œuvre de fiction, si Georges Orwell avait voulu faire danser la carioca à Wilson, ça aurait la même valeur pour déduire de ce qui peut et va arriver dans le monde réel.
Je pense qu'on devrait commencer à utiliser des cas moins imaginaires, comme parler de ce qui est arrivé au régime soviétique, à l'Allemagne de l'ouest ( "la vie des autres" ), à celui de Saddam Hussein ( et la montée de l'etat islamique sur les ruines de sa bureaucratie militaire ) ou les autres dictatures. À la rigueur, la, on pourrais faire une comparaison qui soit pas littéralement basé sur une histoire inventé par un déçu du système soviétique. La biographie montre quand même que pour quelqu'un d'engagé, il n'avait pas l'air d'avoir non plus un recul énorme, cf la controverse rappelé sur Wikipedia francais. Il avait visiblement pas trop de souci avec le concept de propagande de l'état pour peu que ça soit pour une voie qu'il crois, et pas le recul vis à vis du respect de la vie privé qu'on pourrait s'attendre de l'auteur de 1984, chose qui pour l'époque se concoit, mais qui nuance quand même vachement la différence entre ce qu'il pensait, et ce qu'on va lire dans le roman.
Techniquement, une décriminalisation du canabis serait exactement ce genre de loi. Divers lois décriminalisant la fornication en dehors du mariage le serait aussi. Ou le divorce.
<sarcasme>
Quoi, des exemples réalistes de choses qui arrivent au lieu de ressortir la NSA comme épouvantail passe partout, mais ou va le monde ?</sarcasme>
En pratique, non, les USAs ( je bosse pour une boite US depuis quelques années, la moitié de mon équipe est aux USAs ) ont des tonnes de prestas aussi dans les boites.
Et c'est visiblement courant de prendre les gens en prestation pour plusieurs années, malgré le fait de pouvoir virer les gens rapidement dans tout les cas.
Donc bon, pour l’honnêteté, on repasseras. Dire "tu meurs pas direct" quand au final, tu te retrouves à devoir virer les personnes sur qui tu as investit en formation, c'est bien joli, mais le salarié a perdu son taf dans tout les cas, et tu as perdu ton argent quand même.
La sécurité n'est pas l'objectif pour ce cas d'usage, ce qui
répond à ta dernière question
C'est pas tant la securité que "j'ai mon script d'init qui fait un killall mondemonamoid" et ça fuite hors du chroot. C'est déjà arrivé sur une ferme de compilation d'une distro francaise, avec sshd.
Si c'est une chose qui peut être prise en charge et mutualisée
par une ou des distributions, tant mieux et je trouve que ça
fait partie des choses qui justifie une distribution.
Mais pourquoi s’arrêter à la distribution et pas faire ça upstream ? Si tu as un truc de migration de la configuration de apache, pas de raison que le distributeur garde ça.
Et citons dans les alternatives (plus flexibles) à Ansible: https://propellor.branchable.com/
de Joey Hess (etckeeper, mr, git-annex et git-remote-gcrypt)
Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.
Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)
L'un des défaut que je trouve à Ansible est la piètre
ré-utilisabilité effective des rôles.
D'un part peu de rôles offrent la possibilité de spécifier son
chemin de template de fichier de configuration, à la place
c'est souvent une liste très sommaire d'options
D'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )
Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.
Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.
Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.
C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.
Tout le jeu est de trouver le bon niveau d'abstraction.
Il n'est pas possible à ma connaissance de profiter des
fonctionnalités d'un rôles sans qu'il n'impose aussi
l'installation à sa manière.
C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.
Un autre problème est la duplication souvent d'apparence
inutile des modules Ansible.
Comme ?
Enfin l'approche role-based est intéressante, mais les choses
ne sont parfois pas aussi simples.
Par exemple une machine peut faire office de reverse-proxy
supportant le SSL dans certains cas, mais pas dans d'autres et
d'autres tâches et/ou variables en dépendront (monitoring,
chemins, …)
Je ne suis pas certain que Ansible se prête à se niveau de
flexibilité.
Sur l'aspect future-proof, une config' Ansible dépendant d'une
paire de modules est-elle plus pérenne qu'un paire de shell-
scripts… hum. On verra jusqu'où le support et la compatibilité
suivra au fil des années et des changements de version majeure.
Je peux pas répondre pour les autres, mais j'ai toujours vu fabric comme étant juste un gros wrapper autour de ssh, et pas trés "haut niveau"
Par exemple, y a pas d'emphase sur le fait d'avoir des actions idempotentes, c'est quasiment equivalent à un script shell, mais en python.
Ansible a une tonne de module, donc tu vois de suite ce que tu peux faire. Fabric semble laisser le fait de connaitre la ligne de commande à l'utilisateur, donc je peux comprendre que ça paraisse plus complexe et moins attrayant.
En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.
Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).
Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.
Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.
Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.
Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.
Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.
Donc pour un usage perso, je pense qu'ansible fait l'affaire.
Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.
De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.
De manière amusante, il faut aussi que le financement augmente à la hauteur du nombre de paquet qui arrivent dans la distro. Si il y a 20% en plus à chaque release, ça implique d'avoir 20% de choses en plus à faire ( à la louche ), ce qui implique donc de réussir à suivre la cadence.
Perso, si j'étais eux, je commencerais par fixer un groupe restreint de paquets pour être supporté. Ensuite, revoir le groupe à chaque release, avec la possibilité pour les gens (qui payent pour le projet) de donner leur avis sur la liste de paquets.
[^] # Re: Intérêt d'un nom de domaine ?
Posté par Misc (site web personnel) . En réponse au journal Histoire d'un vol de domaine. Évalué à 10.
Alors, l’intérêt d'un nom de domaine est multiple.
D'abord, tu peux avoir le nom de domaine et changer de platforme d’hébergement. Le jour ou github sera devenu le nouveau sourceforge, les gens seront content de pouvoir basculer.
Ou si tu décides d'aller vers cloudflare ou un cdn devant ton site web, c'est pareil, un nom de domaine me semble requis.
Ensuite, si ton projet grandit, tu as parfois besoin d'avoir de l'infra en plus qui est pas exactement celle que propose github ( le cas qui me vient en tête serait d'avoir ton propre cdn, ton propre CI, etc ).
Je doute que ça soit le cas pour guake, mais c'est pas non plus impossible à envisager. Il y a suffisament de projets ou les CI existants sont pas suffisants ( parce que tu es pas root, parce que la plateforme est importante, parce que tu veux aller au dela des 2 versions d'ubuntu de travis, parce que tu as une communauté assez grande et github suffit pas pour la gestion des identités, etc ).
Parfois, tu trouves ça classe d'avoir ton alias mail. Ça simplifie quand même grandement la vie quand tu changes de provider mail, ou que des gens quittent le projet.
Enfin, je pense que si jamais tu as des histoires de trademarks, avoir le nom de domaine depuis X années peut aider quand même à convaincre que tu as utilisé le nom du projet depuis assez longtemps.
[^] # Re: C'est l'jeu ma pov' Lucette
Posté par Misc (site web personnel) . En réponse au journal Histoire d'un vol de domaine. Évalué à 10.
Tu peux faire un transfert de l'argent, puis annuler le transfert une fois que le nom de domaine est sous ton controle /o\
Ou tu peux lui faire appeler un numero surtaxé en france pour discuter avec toi, et une fois que tu as chopé les 400$ , tu lui verses, et il aura sa facture à la fin du mois .
[^] # Re: Quand systemd téléphone à Google
Posté par Misc (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
D'un point de vue purement pragmatique, le fait de ne pas avoir d'ip stable et en multicast rends la solution moins attractive pour la configuration par défaut.
Du coup, on passe d'une ligne de config à "avoir une liste de serveur DNS dont on est pas sur de la survivance sur 5 ans". Ce qui deviens un patch plus intrusif à maintenir, vu qu'il faudrait soit coder en dur 3/4 serveurs de la liste ( ce qui est un risque ), soit avoir la liste des serveurs sur le disque, et la garder à jour ( donc accepter que le dns ne marche pas la première fois, surtout pour mettre les mises à jours ). Et rajouter aussi du code pour trouver le DNS le plus proche d'un point de vue réseau, alors que c'est le boulot du réseau de faire ça ( et la latence du DNS est importante quand même ).
Alors on va me dire que Google n'a pas vraiment un historique au niveau de garder les choses en marche longtemps, mais je pense qu'ils ont plus de moyen et plus d'appareil qui dépendent du fait que 8.8.8.8 réponde.
Mais bon, peut etre que c'est une vaste conspiration plutôt que le fait de pas vouloir maintenir un patch que personne n'a jamais écrit, sans doute parce qu'il est plus facile de râler sur un volontaire que de réfléchir à une solution.
[^] # Re: Thème graphique
Posté par Misc (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 4.
Non, c'est la tendance qu'on retrouve partout. Soit tu fait des paquets et du code, soit tu es considéré comme un merde avec des talents périphériques.
Exemple:
- pendant trés longtemps, tu voulais avoir un droit de vote et un email @debian.org, il fallait devenir packageur. Les autres contributions ne comptait visiblement pas.
Autre exemple, tout le monde s'estime compétent en expérience utilisateur, même quand les gens sont pas capables de s'exprimer et d'employer le vocabulaire du domaine, et c'est un signe de non reconnaissance de l'expértise des gens qui bossent dedans ( et du coup, faut pas s'étonner de pas les voir venir se faire pourrir )
Ou le manque de considération qu'on donne aux documentations et/ou aux traductions, qu'on va voir comme tache pour débutant.
Ou tout ce qui est proche de l'application d'une forme d'empathie est vu comme une perte de temps. Discuter sur irc avec les utilisateurs, passer du temps sur les mailings listes de support, etc ( et c'est un truc qu'on retrouve aussi dans les startups : http://www.laurenbacon.com/women-tech-empathy-work/ )
Mais, oui, c'est bien que ça change, et qu'un peu de diversité dans la contribution arrive, et qu'elle arrive parce qu'il y a un début de diversité tout court sur des plans autre que la géographie et le type de bureau favori.
[^] # Re: Suppression de DSPAM
Posté par Misc (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
J'utilise pas jessie, mais j'utilise spamassasin aussi. Et j'ai vu https://rspamd.com/ , peut être à tester ?
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 8.
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
Exemple, apache propose ça :
https://httpd.apache.org/docs/trunk/mod/mod_journald.html
Pareil pour cupsd ( https://fedoraproject.org/wiki/Changes/CupsJournalLogging )
Y a pas besoin que les gens s'y mettent, suffit juste d'avoir une configuration par défaut dans une distribution, et que ça soit intégré.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 3.
Non, parfois deployer une machinerie complexe style ELK, Graylog, splunk n'est pas une meilleur option si ça te rajoute juste du taf sans rajouter des fonctions significativement requises.
L'admin sys, c'est pas gratuit, et je pense qu'il faut prendre sa remarque dans cet optique aussi.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 1.
Parce que sqlite est monoprocessus, dans mon souvenir ( à l'époque du lancement de trac, ce qui remonte ).
Si tu écrit, tu lis pas. Mais on m'a dit que ça a finalement changé, donc peut être que je me trompe.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 6.
la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 4.
J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 1.
Bah, si tu veux la réponse, tu peux te poser la question à toi même.
Sinon, ça existe déjà, ça s'appelle SQL ( le standard SQL qui date d'avant awk, je tiens à rappeller ). Tu as tes données, tu fait des selects, des LIMIT, des clauses WHERE, etc comme tu ferait avec grep/awk/sed. Et des requêtes sur les requetes, pour les bases de données assez avancés. Et des stockages en tables temporaires aussi, si tu as envie.
Sinon, plus prosaïquement, le reste du monde n'a pas attendu que tu te poses des questions, et le monde scientifique a depuis longtemps des notebooks, comme zeppelin, ipython/jupyter. Sans vouloir trop m'avancer, je pense que l'inspiration vient de maple ou mathematic, et que l'idée, c'est d'avoir un cli amélioré via le browser.
Et pour tout ce qui est big data, ç'est le truc que propose tout les éditeurs de ce que je vois du marché.
Par exemple, Zeppelin te permet d'interroger ton cluster spark pour faire des requêtes sur les flux en streaming, requêtes qui sont peu ou prou semblables aux concepts de grep/awk/etc. Et q
Par exemple pour spark, voir word count, ou on chaine les traitements :
https://spark.apache.org/examples.html
Pareil pour jupyter/ipython et les autres.
Maintenant, libre à toi de rajouter des choses, ipython/jupyter a la possibilité aussi de traiter du bash :
http://jeroenjanssens.com/2015/02/19/ibash-notebook.html
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 8.
Tu fait des fausses dichotomies. C'est surtout dépendant de comment tu spécifie ton format.
Si tu dit "le timestamp est une chaine de maximum 10 caracteres", alors le jour ou tu passes à 11, tu casses tout et c'est du texte.
Si tu as un format binaire avec un entête qui donne la longueur ou ce genre de choses ( ce qui est fait par exemple en ipv6 ), alors tu peux gérer la transition.
Et les délimiteurs sont pas sans poser des soucis, tel que "devoir les échapper". je fait quoi si j'ai besoin d'avoir un espace ou ':' dans ma chaine ?
Tu aurais du commencer par ça, parce que la, j'aurais compris que tu as visiblement aucun recul et que tu mélanges tout. J'aurais pas pris la peine de répondre.
Primo, tu peux toujours lire les fichiers zip et afficher les bmp des années 80. Donc tu repasseras pour le fait d'être incapable de durer aussi longtemps. La principale raison de la longévité d'une information, c'est d'avoir un standard qui décrit quoi faire des données, pas d'être au format texte. Par exemple, va prendre des fichiers xml sans avoir la dtd ou l'info de ce que doit faire, tu va t'éclater à tirer des informations de ton format "perenne" en mode texte.
Secondo, si ton programme C des années 90 est compilable, y a des chances qu'il s’exécute aussi. Pas forcement qu'il s’exécute correctement si il fait de la merde toléré à l'époque qu'on bloque maintenant. Ça a beau être du texte, encore une fois, ce qui est important, c'est l'usage qui est fait de l'information, pas le format.
Donc l'argumentaire est un chouia myopique.
[^] # Re: Définition
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 10.
D'après stackoverflow, il suffit juste d'utiliser le module struct de python. Parait que c'est un langage sympa, faudrait regarder.
Mais je pense que la question est purement réthorique, parce que malgré la doc présente sur le web ( http://www.freedesktop.org/wiki/Software/systemd/journal-files/ ) depuis des années et le fait qu'il existe 2/3 bouts de code pour le faire ( https://github.com/Lagg/c3-code/blob/master/journal.c et https://github.com/Laird-Dave/journaldparser/blob/master/extractor.py ), le fait est que personne n'a pris la peine ( ie, l'aprés midi de travail ) de faire quoi que ce soit de propre pour windows ou pour mac. Ça montre surtout que l'intersection des gens motivés et/ou capables de coder pour ces platformes et des gens ayant le besoin est proche de pas grand chose. Et c'est pas faute pourtant d'avoir des tas de gens qui disent qu'il faut le faire, vu le nombre de commentaires disant qu'il y a un souci et tout va exploser.
Si franchement, un mec arrive à coder ça dans le cadre d'un tutorial youtube en écrivant les 250 lignes requises de code, c'est que ça doit pas être si terrible.
Donc si c'est pas la difficulté qui bloque, soit c'est parce que les gens sous Windows sont incapables, soit ils ont pas le besoin. Je ne pense pas que les Windowsiens sont incapables, et vu les pavés que hervé poste sur ce thread, je pense pas qu'on puisse garder l’hypothèse qu'il n'a pas le temps ( ça m'a pris 5 minutes de recherche sur le web pour trouver le code ).
Donc j'en conclus que le besoin est suffisament faible pour que quelqu'un se motive à faire un truc.
Et c'est pas vraiment compliqué de voir pourquoi. Si c'est sur un serveur, la majorité des OS utilisé ayant systemd a également les logs en texte à coté, cf config RHEL/Centos, et Debian, en partant du principe qu'il y a pas autre chose mise en place, genre splunk, ELK, etc.
Si c'est pas sur un serveur, c'est sur un poste client et/ou embarqué, ou une variante. Et si c'est sur un poste client, y a des chances de préférer un Linux par la.
Encore une fois, prendre le code python que j'ai pointé, en faire un module qu'on met sur pypi, faire des builds kivonbien, c'est moins d'une journée de travail pour quelqu'un d'assez compétent. J'ai écrit un gem ruby en partant de 0 en moins de 4h depuis un café en république tchèque y a grosso modo 1 an, donc j'imagine que pypi doit pas être fondamentalement plus complexe.
Donc si le but était d'être constructif plutôt que de déposer une énième logorrhée sur Linuxfr, quelqu'un s'y attellerait. Personne ne s'y attelle, donc je conclue que le but est juste de râler.
Moi, je pourrais en effet faire ce module, mais je vois pas pourquoi je devrais consacrer du temps gratuit à une plateforme que j'utilise pas, que j'ai pas envie d'utiliser. Mais si quelqu'un me file des thunes, je peux changer d'avis. J'ai l'intuition que personne ne va rien donner, donc ça doit pas être si critique que ça.
[^] # Re: des surprises dans les votes pour et contre
Posté par Misc (site web personnel) . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 2.
s/gaspillé/dépensé dans des boites francais ou certains ici bossent/
Faut aussi se dire que des gens chez Thales et EADS, y en a des tonnes. Que si les informaticiens sont pas au chomage, c'est grâce aussi à ça. Qu'on a Amesys, des cabinets de conseils ( HSC, etc ), et tout un tas d'acteurs qu'on retrouve pas forcément ailleurs.
Et que si on a des tonnes de confs de secu ( stiic, nuit du hack, hackito ergosum et les autres dont j'ai oublié le nom ) en france, c'est aussi ça parce que les gens qui s'intéresse à ça trouve du boulot, et donc font des affaires pour gagner leur vie.
Donc l'influence de lobbying de toute cette industrie ( dans laquelle j'ai bossé ) est un point non négligeable de tout ça. Un point qu'on voit pas souvent mis en avant, et qui est pourtant existant.
Et je parle pas non plus de experts en machine learning francais comme tinyclues ou criteo et tout ça, qui font que dans l'esprit des gens ordinaires, on peut faire des miracles avec les algos, et qu'à force de dire "on est suivi par google et facebook", personne ne se dit que ça cimente l'idée que c'est faisable et facile. Et c'est pas les vendeurs de solutions qui vont dire le contraire.
Exemple :
https://www.youtube.com/watch?v=6uGQeA3x0bs
En dehors du coté anti jeunes qui m'étonne pas, le clip est quand même anxiogène au possible…
[^] # Re: mettre le net à sa place ?
Posté par Misc (site web personnel) . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 4.
Spoiler: 1984 est une œuvre de fiction, si Georges Orwell avait voulu faire danser la carioca à Wilson, ça aurait la même valeur pour déduire de ce qui peut et va arriver dans le monde réel.
Je pense qu'on devrait commencer à utiliser des cas moins imaginaires, comme parler de ce qui est arrivé au régime soviétique, à l'Allemagne de l'ouest ( "la vie des autres" ), à celui de Saddam Hussein ( et la montée de l'etat islamique sur les ruines de sa bureaucratie militaire ) ou les autres dictatures. À la rigueur, la, on pourrais faire une comparaison qui soit pas littéralement basé sur une histoire inventé par un déçu du système soviétique. La biographie montre quand même que pour quelqu'un d'engagé, il n'avait pas l'air d'avoir non plus un recul énorme, cf la controverse rappelé sur Wikipedia francais. Il avait visiblement pas trop de souci avec le concept de propagande de l'état pour peu que ça soit pour une voie qu'il crois, et pas le recul vis à vis du respect de la vie privé qu'on pourrait s'attendre de l'auteur de 1984, chose qui pour l'époque se concoit, mais qui nuance quand même vachement la différence entre ce qu'il pensait, et ce qu'on va lire dans le roman.
[^] # Re: Mouai
Posté par Misc (site web personnel) . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 3.
Techniquement, une décriminalisation du canabis serait exactement ce genre de loi. Divers lois décriminalisant la fornication en dehors du mariage le serait aussi. Ou le divorce.
[^] # Re: faut deja un acces aux données
Posté par Misc (site web personnel) . En réponse au journal Encfs déclaré relativement peu sûr. Évalué à 5.
<sarcasme>
Quoi, des exemples réalistes de choses qui arrivent au lieu de ressortir la NSA comme épouvantail passe partout, mais ou va le monde ?</sarcasme>
# Comment on propose ?
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Party Paris mai 2015 - appel à conférence. Évalué à 2.
J'ai pas trop trouvé comment proposer un ou deux talks sur le site web ( mais je suis aussi un peu fatigué ). Quelqu'un voit un lien évident ?
[^] # Re: Classique
Posté par Misc (site web personnel) . En réponse au journal sous-developpeurs-SSII. Évalué à 8.
En pratique, non, les USAs ( je bosse pour une boite US depuis quelques années, la moitié de mon équipe est aux USAs ) ont des tonnes de prestas aussi dans les boites.
Et c'est visiblement courant de prendre les gens en prestation pour plusieurs années, malgré le fait de pouvoir virer les gens rapidement dans tout les cas.
Donc bon, pour l’honnêteté, on repasseras. Dire "tu meurs pas direct" quand au final, tu te retrouves à devoir virer les personnes sur qui tu as investit en formation, c'est bien joli, mais le salarié a perdu son taf dans tout les cas, et tu as perdu ton argent quand même.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
C'est pas tant la securité que "j'ai mon script d'init qui fait un killall mondemonamoid" et ça fuite hors du chroot. C'est déjà arrivé sur une ferme de compilation d'une distro francaise, avec sshd.
Mais pourquoi s’arrêter à la distribution et pas faire ça upstream ? Si tu as un truc de migration de la configuration de apache, pas de raison que le distributeur garde ça.
[^] # Re: alt et p-
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 3.
Alors, j'ai croisé pour le moment personne qui utilise propellor. Et pourtant, je passe mon temps à zoner dans les meetups et ce genre de choses. Pour dire, j'ai croisé plus de gens avec cfengine, ou bcfg2 que propellor.
Dire "y a pas besoin d'apprendre un langage particulier, suffit juste de connaitre haskell" est un chouia trompeur :)
D'une manière générale, tu peux difficilement avoir la configurabilité que propose la configuration d'un logicial sous forme d'une liste d'options, donc tu va jamais aller très loin avec les roles/formules/modules/cookbooks des autres. Si tu veux réutiliser, il faut construire au dessus, ou prendre des trucs de bases ( example, ntpd me parait le truc qu'on peut réutiliser sans souci, vu que les gens vont changer au mieux 2/3 trucs )
Et pouvoir injecter tes propres fichiers, c'est globalement chercher les emmerdes, car le fichier deviens parti intégrante de l'interface du soft avec le reste du monde.
Exemple, tu veux déployer mediawiki. Dans un monde idéal, tu devrais pouvoir reprendre un role apache et voila. En pratique, vu que mediawiki doit toucher à la config apache ( pour se placer dans un vhost, ou avec une url particuliére ), il y a un couplage entre les 2. Et pire encore, le couplage est non exprimé de façon formel donc risque de casser à tout moment. J'utilise une convention d'avoir /etc/httpd/conf.d/$vhost.conf.d/ pour qu'un soft dépose un fichier de configuration apache, qui s'applique à $vhost.
Si tu décides de prendre une autre convention ou de changer le templates, tu peux casser ça. Mais comme c'est pas exprimé comme le serait une fonction ( ce que puppet propose ) avec verification à la compilation, tu dois déployer et voir que ça ne marche pas. Et même, une fois que tu as une fonction, tout ce que tu peux rajouter comme argument doit être supporté à jamais, donc les gens évitent d'en mettre trop. Et du coup, tu es limité.
C'est la ou Puppet a un avantage, via le fait d'avoir une phase de compilation capable de vérifier ce genre de choses. Mais ça ne rends pas les choses beaucoup plus réutilisables si tu veux sortir du cadre décidé par le créateur du module, et si un module puppet fait pas ce que tu veux, tu as pas le choix, il faut forker.
Tout le jeu est de trouver le bon niveau d'abstraction.
C'est du défoncage de porte ouverte. Encore une fois, tu as des interfaces non exprimés ( exemple, le chemin d'un fichier de configuration ), et soit tu gères ça dans le rôle lui même ( exemple, tu choisi l'emplacement du fichier de configuration via la méthode d'installation ), soit c'est un standard qui ne va pas bouger et que tu ne pas configurer sans tout casser. Donc soit le role impose la façon de faire, soit elle est imposé de façon externe. C'est comme un paquet de distrib, si tu veux le binaire d'apache dans "/usr/bin/sioux", tu peux pas ( sauf à tout refaire, et/ou modifier les choses à un autre niveau ). Il y a une cohérence interne au paquet/role à garder.
Comme ?
Bah, tu peux mettre passer des arguments à un rôle ou un include ( http://docs.ansible.com/playbooks_roles.html#task-include-files-and-encouraging-reuse et plus bas ). J'ai un role httpd qui le fait que j'utilise sur 3 projets indépendants, donc je vois pas en quoi ça serait pas faisable.
La, ça semble un peu du FUD…
[^] # Re: Ansible / Puppet
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 3.
Je peux pas répondre pour les autres, mais j'ai toujours vu fabric comme étant juste un gros wrapper autour de ssh, et pas trés "haut niveau"
Par exemple, y a pas d'emphase sur le fait d'avoir des actions idempotentes, c'est quasiment equivalent à un script shell, mais en python.
Ansible a une tonne de module, donc tu vois de suite ce que tu peux faire. Fabric semble laisser le fait de connaitre la ligne de commande à l'utilisateur, donc je peux comprendre que ça paraisse plus complexe et moins attrayant.
[^] # Re: Ansible / Puppet
Posté par Misc (site web personnel) . En réponse à la dépêche Présentation d'Ansible et version 2 à venir. Évalué à 10.
En général, le premier argument, ça va être les compétences et les affinités. Si tu as des gens dans ton équipe qui sont familier avec un outil, alors il vaut mieux le prendre.
Sinon, j'ai fait du puppet (beaucoup, mais y a longtemps), je fait beaucoup d'ansible et en ce moment, pas mal de salt, donc j'ai un avis forcément éclairé et valide sur le sujet (non pas que ça change grand chose, je l'aurais donné même si non fondé bien sur, on est sur l'internet).
Déja, ça depend de ce que tu as comme besoin. Puppet ne fait que de la gestion de configuration, donc si tu doit déployer ou orchester des choses, il te faut un deuxième outil (mcollective, func, fabric, ansible, saltstack, etc). Ansible par contre à la base fait du déploiement et de l'orchestration, et ça a été étendu à la gestion de configuration, et ça change tout.
Ça change tout parce que Ansible, étant sans agent, est plus ou moins obligé de faire des aller/retours sans arrêt et ça reste assez lent. Pour un projet, on a une infra de 10 machines, ça mets 10 à 15 minutes à tout appliquer à chaque commit git sur le dépôt. À coté de ça, Puppet était pas super rapide dans mon souvenir à cause de ruby ( notamment les allocations d'objets ) , mais c'était une infra plus compliqué, et au final, c'était quand même bien plus acceptable.
Du point de vue des fonctions, Puppet est bien plus mature et son DSL propose vraiment plus de choses, la ou Ansible pêche un peu ( le fait de pas avoir de fonction, par exemple, même si un équivalent va revenir avec la version 2 du moteur, via le fait d'avoir des includes dynamiques ). Puppet a un ecosystéme plus riche qu'ansible ( genre foreman, r10k, etc ), plus de modules et plus de gens qui connaissent. Et forcément, il y a aussi des bonnes pratiques à tort et à travers, des patterns, etc.
Puppet est plus complexe à installer, pas forcément à apprendre. Tu es pas obligé de tout connaitre, tout comme dans ansible, tu as pas forcément besoin de connaitre tout les modules.
Mais c'est vrai qu'avec ansible, tu arrives plus rapidement à obtenir un résultat utile, et l'outil est plus versatile.
Donc pour un usage perso, je pense qu'ansible fait l'affaire.
Pour une infra plus conséquente, je regarderais peut être plus du coté de puppet ou saltstack pour le moment.
De ce que j'ai vu, ansible est assez populaire chez les codeurs (ce qui n'est pas étonnant, vu qu'au final, c'est une suite de pas à suivre pour déployer ou obtenir un état), la ou puppet va plus correspondre à l'état d'esprit d'un packageur ou d'un architecte (le fait d'avoir des bouts d'état interdépendant pour obtenir un état général de ton infra, et de converger vers cet état). Donc en fonction de tes affinités, l'un va te paraitre plus naturel que l'autre.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
De manière amusante, il faut aussi que le financement augmente à la hauteur du nombre de paquet qui arrivent dans la distro. Si il y a 20% en plus à chaque release, ça implique d'avoir 20% de choses en plus à faire ( à la louche ), ce qui implique donc de réussir à suivre la cadence.
Perso, si j'étais eux, je commencerais par fixer un groupe restreint de paquets pour être supporté. Ensuite, revoir le groupe à chaque release, avec la possibilité pour les gens (qui payent pour le projet) de donner leur avis sur la liste de paquets.
[^] # Re: Bon, tu l'as cherché mais on est vendredi
Posté par Misc (site web personnel) . En réponse au journal Debian Jessie, release prévue le 25 Avril avec deux nouvelles architectures. Évalué à 2.
Parce que jamais aucun employé ne va être mécontent, et parce que les bécanes vérolés qui servent de passerelles n'existent pas ?