Toujours le même problème avec l'I18N, c'est un boulot de malade et ca demande beaucoup d'attention tout le long de la chaîne. Dès qu'un maillon fait un truc un peu léger ça casse tout. Exactement pour ça que j'utilise tout en enUS._
J'aimerai prendre quelques instants pour résumer ton argumentation.
Donc :
1°) L'utilisateur ne sait pas se servir de Gnome-Shell sinon il saurait comment accéder à son appli en deux clicks => PEBCAK
2°) Les mainteneurs des packages Gnome3/Gnome-Shell ne savent pas se servir de Gnome-Shell sinon le .Desktop serait mieux configuré dans les distribs et tout le monde pourrait accéder a son appli en deux clicks => PEBCAK
3°) Tu ne sais pas te servir de Gnome-Shell, sinon tu ne serai pas en locale en_US, mais les traductions I18N c'est un boulot de malade qui demande d'être très concentré tout au long de la chaine.
Conclusion : Gnome-Shell ca permet d'accéder simplement à son appli en deux clicks, sauf que personne ne sait faire/ne veut faire et que ce serait un boulot de malade de le faire.
Sauf que moi, j'aimerais bien dépasser le stade du patch anecdotique, et m'impliquer dans un projet.
Le "stade" du patch anecdotique c'est la contribution à un projet.
Même sur des très gros projets libres tu peux finir par avoir une quantité non négligeable de code qui ne sont qu'une série de patch anecdotique. Le kernel Linux a commencé comme ça (et dans une certaine mesure il doit encore y avoir 30 à 40% du code qui sont des patchs anecdotiques)
Déjà, il faut trouver un projet qui m'intéresse
Mauvaise approche.
Pour commencer il faut que tu trouves un truc qui te casse les pieds. Un truc qui te manque. Code la fonctionnalité dont tu as besoin et dont tu vas te servir. Ensuite une fois ce problème réglé tu verras de toi même si ça serait intéressant de remonter le code dans un projet ou un autre.
(Ah au fait la tehcno marche du feu de dieu, mais pas sur le HFS+ implémenté par défaut sur mac - le commit/sync super retardé d'apple bouffe les perfs. Sinon sous Linux ca fait huit ans que je m'en sers (bon OK c'était pas vraiment une offre grand public (Et bon sang arrétez de marcher dans les trolls Apple de NedFlanders - ça l'encourage ( N.B : le stage de désintoxication du LISP a échoué, encore…))))
Tout à fait et c'est pour cela que la comparaison avec IPv6 Mobile est erronée.
Le problème est que je ne vois pas comment on peut faire des sources mutiples seulement avec de protocole MPTCP. Il va quand même bien falloir modifier les middle box ET les applis pour prendre en compte un changement d'IP.
Parceque mon appli quand elle va répondre à une demande, elle va le faire en "décidant" quelle est la bonne IP pour cette session.
Autant en IPv6 mobile avec mon IP qui se balade (voire qui est présente sur deux réseaux) - tout le niveau décisionnel va être géré par les routeurs. A partir de là mon appli se moque complètement de savoir si c'est une adresse IPv6 standard ou une appli IPv6 mobile. L'intelligence de routage se fait plus tard.
Par contre sur MPTCP il faut que mon appli sache que telle ou telle session correspond à X adresses IP. (Ou alors uen fois de plus qu'il y ait un proxy/daemon MPTCP qui fasse de la traduction d'adresse et qui fasse le load balancing).
Quand je lis les specs du MPTCP je n'arrive pas à me sortir de la tête que c'est juste une façon d'obtenir la même chose qu'avec de l'IPv6 Mobile mais sans passer à IPv4.
Je suis bien conscience qu'il y a des différences au niveau du protocole (je connais la dissociation IP/TCP) mais bon, IPv6 mobile était un truc qui devait permettre de rerouter rapidement (et à la volée) une machine (bon OK une interface) qui se déplace sur différents réseaux. MPTCP permet de faire la même (suivre un déplacement sur différent réseaux) chose au niveau connexion/session plutôt qu'au niveau machine.
Le premier problème que je vois est celui du double emploi - grosso-modo 80% des cas d'application de IPv6 mobile sont couverts par MPTCP (c'est à dire en pas se faire jeter et ne pas avoir à se réauthentifier en cas de changement de réseau).
Après pour les cas suivants (être capable de retrouver une machine ou qu'elle soit sur les réseau) il suffit d'écrire un petit démon qui balance un paquet de temps en temps pour permettre le seuivi. (une fosi qu'on aura les bonnes libs MPTCP ce petit démon devra peser dans les 50 lignes de codes et sera probablement donné en exemple dans la lib elle même).
Le second problème que ca pose est celui du déploiement. Le gros avantage d'IPv6 mobile (connexion continue avec un appareil mobile) est en train de partir à la poubelle. A partir de là on peut légitimement se demander si les opérateurs veront un interêt quelconque à déployer IPv6 mobile :Dans un cas j'achète du matos, je fais des tables de routages dynamiques et modifiées plusieurs fois par seconde si j'ai beaucoup de client, dans l'autre je met à jour le firmware de l'existant et je reste en v4 (Je veux pas être méchant mais le choix est vite fait…) Or si les opérateurs mobiles déploient MPTCP à la place de IPv6 mobile - on peut considérer que la norme IPv6 mobile est morte (non pas qu'elle soit super vivante en ce moment, ni qu'elle l'ait jamais été. Déjà IPv6 tout court…)
Le troisième problème que ca pose est celui du hack TCP pour pas passer en IPv6. Il y a 5 ou 6 ans je racontais en rigolant devant un commité d'experts ( https://linuxfr.org/board ) que les boites ne passeraient jamais en IPv6 (trop couteux et pas rentable du tout pour les premiers à faire le pas) et qu'on aurait à la place des hacks TCP qui permettrait de passer de 65536 ports à 16 millions. Comme ça NAT pour tout le monde et on en parle plus. C'était rigolo à l'époque - mais aujourd'hui ca me fait plus rire.
Donc si quelqu'un peut me dire que je me trompe (avec argument à l'appui - les one-liners "tu te trompes" et les "comment peut-on être assez @"!ù!! pour croire que" s'abstenir) ca me rassurerait. Je souhaite sincèrement être passé à coté d'une fonction IPv6 qui ne soit implémentable en 100 lignes de codes avec mptcp.
Petit filtre sur l’exécutable du serveur, le pid du processus qui a pris en charge le client
Deux choses que je ne connais pas. Je connais l'adresse IP du mec qui me casse les pieds c'est tout.
tu peux quand même filtré sur le service ce qui n'est pas possible avec le syslog original et certain service (attention, j'y vais comme toi, je lance des affirmations sans vérification mais c'est ce que je viens de lire).
Tout dépend de quoi on parle
- Si c'est service au sens de daemon - ben ca va être dur de pas filtrer dessus vu que généralement ses logs vont être à part. (genre /var/log/daemon) après si j'ai décidé de les fusionner avec d'autres logs ça devient un peu mon problème.
- Si c'est service au sens d'instance - la plupart des logiciels permettent quand mêle de loguer très correctement par instance, mais même dans le cas ou ils ne permettent pas (j'ai pas d'exemple en tête) - le facteur déterminant sera probablement ailleurs (une fois de plus IP extérieure, segment de protocole qui part en vrille, activité d'un utilisateur etc.) Donc on va passer d'une complexité de O(n) à une complexité de l'ordre de O(log(n)) + O(n*p) (Avec p < 1, p étant la proportion de logs dans l'instance concernée). C'est mieux, mais pas transcendant.
Mais bon, la seul chose que tu as démontré, c'est que dans tes exemples, journald s'en sort aussi mal que syslog…
Une fois de plus je pense sincèrement que journald est meilleur que syslog, et sans systemd rattaché je serai déjà en train de le tester - mais c'est pas pour autant qu'il fait le café, ramène le journal et garanti le retour de l'être aimé. Il a des défauts - ben comme tous les programmes quoi.
Donc si on part d'une commande catwoman qui dompte l'ignoble format de fichier binaire :
catwoman fichier_au_format_imonde | grep 'tralala' | sed 's/lala/soinsoin/g'
Le problème c'est qu'on ne vas pas faire catwoman fichier_au_format_immonde
On va faire catwoman --filtre filtre1 --filtre filtre2 --filtre filtre3 --répertoire répertoires_rempli_de_fafi --options_de_sorties option1 --options_de_sorties option2 | monanalyzer_que_j'aime
Le truc c'est que de taper tout ça c'est casse pied. Donc on va vouloir se créer des scripts qui simplifient la vie. Genre aller modifier monanalyzer_que_j'aime pour qu'il génère les filtres à la volée en fonction de demandes humaines compréhensibles, avec des options par défaut bien remplies etc.
Genre monanalyzer_que_j'aime --filtre filtre1 filtre2 filtre3 répertoire_rempli_de_fafi
Et bien entendu le résultat de la sortie peut contenir des éléments non imprimables du fait de corruption (ou tout simplement parce que les options que j'ai choisi peuvent afficher ce type de caractères) Et encore plus si je peux mettre un buffer de façon à ne pas déployer 3 000 000 de lignes en mémoire c'est mieux - mais si je peux utiliser les commandes (par exemple de less ou more) pour sauter de 500 lignes en avant ou en arrière sans devoir tout dérouler entre c'est le pied (c'est ça le back and forth - parfois nommé mode pager).
Si j'ai tout ça je peux vraiment bosser comme j'ai l'habitude. Mais c'est complexe à mettre en place.
Comme quoi la simplicité KISS est illusoire ?
Pour le dev oui (enfin jusqu'à Lennart qui a l'air bien décidé à venger des générations de dev du joug des sysadmins). Demande à Alan Cox pour voir - il a des trucs palpitants à raconter sur la console.
Encore une vraie question : en quoi fuse est une cochonnerie ? Il permet de pousser à l’extrême le concept du tout est fichier.
Tout est fichier OUI. Tout est système de fichier moins. Il y a quand même des trucs assez crade dans fuse (ce qui n'enlève rien au fait que c'est un outil très très pratique).
J'ai enlevé un seul mot et ça s'applique à 80 % des personnes qui ont posté sur cette page, moi compris (PAF !).
Merde, moi qui croyait être un réactionnaire hipster. Je pensais trop me la péter dans 2 ans genre "je crachais sur systemd avant que ce soit à la mode de le faire !"
Il doit être possible de compiler (et peut être même de linker) avec peu de libs installées.
Mais à l’exécution est-ce que ça peut vraiment se passer de tout le fratras qui est dans /src/shared ?
Le fait que tu indiques à la mimine à journalctl l'emplacement du fichier de log prouve effectivement de façon éclatante qu'il est capable de trouver les logs tout seul quand DBus est éteint.
J'imagine bien sur que pour le test soit concluant sur au moins un point tu as supprimé les différentes librairies systemd avant de lancer la commande.
Non parce que moi de mon coté j'ai juste relu les headers de journalctl et le makefile.am et très honnêtement j'ai toujours peine à croire que ca puisse fonctionner sans rameuter tout le fratras de libs et de dépendances qui vont bien.
Ceci étant je ne me suis pas penché à fond sur le truc, il y a peut-être moyen de limiter les dégats en allant modifier certains éléments de /src/shared - mais vache il y a du boulot.
Franchement, arrête de raconter n'importe quoi alors que tu n'as absolument jamais vérifier ce que tu avances depuis le début.
Et de 4 rien que sur ce thread là. Tu cherches à battre un record ? Ou tu penses sincèrement que ca sert à quelque chose ?
Les spec sont sorties vendredi. C'est tout de même intéressant de ne pas oublier le contenu du journal.
Les specs commencent par "il ne faut pas lire les logs en raw". Ca va quand même être compliqué de créer un outil de parsing des données en stand alone et de l'incorporer au projet dans ces conditions.
Non tu veux une position contractuelle sur un produit qui n'est pas encore en alpha.
J'aimerai avoir une position contractuelle le plus vite possible. C'est pour ça que j'ai brulé un ticket pour poser la question. Maintenant je me doute bien qu'ils vont pas me répondre demain. Seulement quand j'entends dire que FORCEMENT les distribs serveurs vont passer à systemd, je me permet juste de signaler que les distribs en question elles ont pas l'air pressées de l'annoncer publiquement. Après mon interprétation est que ça ne sera pas si "forcément" que ça, ou pour être parfaitement exact je pense (opinion personnelle toussa) qu'elles cherchent à retarder au maximum le moment ou elles vont annoncer qu'elles ne supportent plus les autres init officiellement (ou alors avec des features en moins). Et si c'est le cas ca laisse à penser à son tour que tous les sysadmin du monde ne rêvent pas franchement la nuit du jour ou ils vont enfin passer systemd en prod. (Une fois de plus opinion personnelle toussa).
Après personnellement systemd me pose de vrais problèmes (que j'essaye d'exposer avec un succès mitigé), et je râle un peu quand on m'explique que journald est nettement mieux que tout ce qui existe dans tous les cas possibles et imaginables (sauf les miens - ce qui prouve bien que je trolle puisque journald est parfait)
C'est justement un problème des log texte. Tu n'a rien de fiable pour distinguer la forme et le contenu
A part les specs tu veux dire. J'avoue que c'est fouilli en effet. Mais bon le parseur universel qui fonctionne aussi bien avec les logs du serveur mail que le branchement des LUN SCSI que suivit de réplication LDAP j'y crois moyen.
Ceci étant si il n'y avait pas systemd derrière je serai probablement déjà en train de déployer journal sur les serveurs de tests - parce que oui il y a de vrais avantages et que les défauts ne sont pas insurmontables (mais ils sont là quand même).
_ ça aurais très bien pu être fais en xml par exemple, mais je n'ai pas l'impression que l'idée te plaise d'avantage_
Que les chose soient claires : je préfère des logs en binaires à du XML. En fait je préfère des logs en BIG5 avec maximum un caractère par ligne dans des fichiers de 2ko maximum à du XML.
Je ne vois pas comment faire rentrer du n'importe quoi (par essence un log on peut jamais être sur à 100% de ce qui va se trouver dedans) dans du XML à moins de faire de la soupe d'escape dans tous les sens. Et ça non merci.
Tu m'appelles le jour ou tu cherches dans tes logs sur un autre critère sur ceux fournit par journal…
J'ai pas les moyens financiers.
En partant du principe que l'index sur service ne compte pas vraiment (dans l'ancien système je serais allé chercher le bon fichier de log à la main mais ça ne pose pas vraiment de problème.)
Rien qu'aujourd'hui :
Problème avec une gateway SIP : donc parsage de log sur le contenu, notamment au niveau des tokens de sécurité dans les phases d'initialisation. Petit filtre sur l'init et sur l'adresse IP du client - damned c'est pas indexé par journald. (environ 15 coups de fil à vue de nez)
On continue avec la mise en place d'une nouvelle stratégie de cache - petit tests sur les expirations de cache du proxy et du memcached en fonction du log/delog des users. Petit filtre IP extérieur/login/réponse memcached - caramba encore raté (une petite vingtaine de coup de fil)
Les utilisateurs se plaignent d'un ralentissement. Ca serait les tests ? (Petit filtre sur les IP des machines des admins dans les logs des serveurs de prod - non c'est pas ça (3 coups de fils)) - par contre awstats montre une grosse monté des connexions, notamment en erreur. Ben tient tou vient de la même plage IP extérieure (5 coup de fils) qui nous casse aussi les pieds sur Bind (1 coup de fil), sur les ports mails (1 coup de fil), et même sur les plages CIFS (1 coup de fil). Ban de la plage et mail bien senti au provider (qui en a probablement rien à foutre mais c'est pas une raison pour ne pas le faire).
Donc aujourd'hui seulement entre 40 et 50 coup de fils comme ça, à la louche. Et encore tu t'en tire bien on a pas débugué de java ou de Riak aujourd'hui.
et tu nous faire perdre du temps
GNARARARARH Je vous oblige a répondre à mes posts sur linuxfr grace à mes grands pouvoirs. Je suis diabolique.
va coder si t'es si bon que ca et que t'as tous compris aux problèmes d'init et de logs
Tout à fait le fait d'avoir des problèmes qui ne sont pas résolus par systemd fait de moi
a) Un expert sur tout ce qui concerne l'init et les logs
b) Un développeur émérite
c) Un mec avec assez de temps libre pour recoder tout ça en mieux
Et le pire c'est que je suis fan de beaucoup d'idées de journald (la continuité des logs par exemple, le coté analyse temps réel qui viendra surement bientôt, les index - même si j'aimerai pouvoir définir les miens etc.) Mais journald a encore de grosses lacunes et un aspect rédhibitoire : celui de ne pas pouvoir fonctionner sans systemd.
O(log(n)) c'est tout le temps, y'a pas d'indexeur dans journald…
Mais oui, il cherche parmi n éléments pour un élément spécifique en O(log(n)) le tout sans index, et ce y compris sur le contenu des éléments du journal.
Tu es au courant que ça n'est pas mathématiquement possible ?
Bien entendu journald indexe tous les champs ou presque (de façon générale tous les champs qui commencent par _ (donc les champs de confiances) sont indexés).
Tu veux faire une recherche sur un autre champ ? Ben tu te prends un O(n) dans la gueule (ce qui est une fois de plus tout à fait normal).
Mais de quoi tu parles, t'en a pas marre de raconter n'importe quoi ?
Je m’entraine avec des pro, donc je me lasse jamais.
Oui, par ce qu'il est bien connu que grep, sed, awk, perl et autres ont obligatoirement besoin d'un fichier, ils ne savent pas utiliser l'entrée standard qu'on leur donne avec un pipe.
Comment tu remontes dans les logs avant ton curseur initial avec une entrée standard ? Non juste pour savoir. C'est un truc qu'il m'arrive d'utiliser quand je lis des logs.
Ceci étant il semble que el bug soit en voie de correction : http://www.spinics.net/lists/fedora-devel/msg172481.html
Faux. Il suffit de libsystemd-id128.so et libsystemd-journal.so, pas besoin du reste de systemd. Sur ma machine ca prend environ 332ko.
Alors vu que id128 ne sert qu'à générer des id et que -journal ne fait que de créer les interface j'ai du mal à y croire.
Si il n'y a pas un systemd qui tourne, journalctl n'est même pas capable de trouver les logs tout seul. Il va essayer de se connecter à DBus pour parler à systemd. Et si il n'y a pas, ben il s'arrête là.
En attendant, tu peux fournir des vrais arguments? Parce que la, ben… Non,
Dans l'ordre du thread
https://linuxfr.org/nodes/96086/comments/1401649 : réponse à gnumdk sur l'avantage du parsage des index. Bien entendu ca ne marche que pour les index prédéfinis par journald, pour tout le reste soit on indexe à la mano soit on est en O(n) comme journald.
https://linuxfr.org/nodes/96086/comments/1401342 : deuxième partie : comment faire confiance à un init aussi fragile sur des trucs aussi cruciaux que le montage de disques NFS et qui se vautre quand il y a un fichier à la racine du /var. Je veux bien que ce soit le "début" de systemd - mais malgré tout c'est assez surprenant un init qui explose en vol comme ça. Surtotu quand on voit que les corrections ne sont pas faites coté systemd - mais coté appli (pour pas faire de mal au pauvre init tout fragile…)
https://linuxfr.org/nodes/96086/comments/1401231 : On peut parfaitement indexer des fichiers textes (et même le faire bien) - ca ne saurait donc être une raison suffisante pour passer à un format binaire. Premier (mauvais) exemple avec sqlite, second meilleur exemple avec dovecot + maildir/mbox
https://linuxfr.org/nodes/96086/comments/1401645 : Explication sur pourquoi journald est moins pratique et moins puissant en l'état que syslog. Petite digression sur le fait qu'il faille rameuter tout systemd pour lire un fichier de log (ce qui est pénible). Deuxième digression sur le thème "T'a qu'à utiliser les outils classiques pour ça". Merci, je sais que les outils classiques fonctionnent. Le but étant de montrer des lacunes (ou non) de journald, citer le rappatriement des données au format texte et leur analyse par les outils classiques n'apporte pas grand chose.
Ca serait mal élevé de ne parler que de moi :
https://linuxfr.org/nodes/96086/comments/1401432 : Alors oui, je ne sais pas de combien journald réduit la chose, mais toute réduction de taille est la bienvenue. Y-a-t-il seulement réduction de taille, je ne suis pas convaincu. Moonz non plus apparament.
https://linuxfr.org/nodes/96086/comments/1401277 : Tu es bien gentil de fournir tant d'arguments (la, pour le fichier spec, c'est clair, net, précis…), moi il me suffit déjà de regarder qui paye le salaire du développeur pour savoir au moins pour une distrib! Je demande une position officielle, on me répond par un commentaire dans un fichier source. Tu as l'air de considérer que c'est la preuve ultime. Pas convaincu.
https://linuxfr.org/nodes/96086/comments/1401344 : Mais je découvre qu'il y en a qui s'y mettent alors que le produit n'est même pas en alpha. Ou alors c'est du bluff, juste pour troller et inventer des critiques quand il n'y en pas. Je m'interresse à un produit qui modifie profondément le fonctionnement du système et qui nécesite une planification avancée c'est donc que je cherche à troller. Il n'y a pas d'autres explications possibles.
https://linuxfr.org/nodes/96086/comments/1401239 : Mais alors, pourquoi personne ne l'a donc fait?Faut croire que ce n'est pas si facile… qui va bien avec : https://linuxfr.org/nodes/96086/comments/1401705 : alors que c'est assez simple en fait (mais déjà ce simple, personne n'a suffisamment souffert de systemd pour le coder…). et avec : https://linuxfr.org/nodes/96086/comments/1401688 : Faut juste se dire que si ce n'est pas encore fait, c'est peut-être que dans la vraie réalité, ce n'est pas un problème.
Si ca n'existe pas dans l'ancien système c'est que c'est très compliqué, si ca n'existe pas dans le nouveau système c'est qu'il n'y en a pas besoin.
https://linuxfr.org/nodes/96086/comments/1401374 : Comme journald donc? Oui comme journald, le truc étant de démontrer que l'on peut doner à un fichier texte le même type d'index qu'à un fichier binaire tel celui utilisé par journald, on se retrouve au final avec un index du même type que celui de journald.
https://linuxfr.org/nodes/96086/comments/1401695 : journalctl et un pipe, et tu as tous les outils La j'avoue que j'ai beaucoup rigolé - déjà parcequ'une fois de plus il s'agit d'un raisonnement de type "Tu vois bien que le nouveau système est mieux, vu que l'ancien fonctionne" et ensuite parceque non, journalctl et un pipe ca ne donne pas tous les outils loin de là. Et surtout ca ne donne pas le comportement habituel de navigation au sein des fichiers de log. Journalctl c'est pas vraiment gunzip - je peux pas franchement faire un cat de tous mes filtres journald et les piper dans un less.
https://linuxfr.org/nodes/96086/comments/1401731 : Libre à toi de ne pas prendre systemd et journald, mais il faut assumer le coût de maintenance de ce truc archaïque que tu veux à la place. On parle du truc archaïque que tu me conseilles d'utiliser toutes les trois lignes quand je t'expose un problème ? Oui je pense que je vais suivre tes conseils et le garder encore un peu. Au moins jusqu'à ce que systemd devienne capable de faire ce dont j'ai besoin professionnellement. Je suis plus BSDinit que sysvInit (mais c'est un système archaïque aussi) et on est un petit nombre à vouloir le garder ce système archaïque. (Tous des réactionnaires à ornière j'imagine)
https://linuxfr.org/nodes/96086/comments/1401734 : Un peu comme un log texte qui est différent suivant la distro? Les log, c'est presque la même chose partout… Mais tu les aime,s va comprendre pourquoi.
Je sais qu'on est pas supposé dissocier le fond de la forme, mais rassure moi, tu as conscience du fait que tu parles du contenu et moi du contenant ?
Gni? Non, il suffit de faire un bête logiciel qui sort du texte des fichiers de log (bref, un bête remplaçant de journalctl qui fait qu'une chose)
Et qui interprete les meta systemd, comme la date, le numero de PID, le nom de la machine etc. Bref un truc qui prend un fichier binaire raw et qui le formatte pour l'affichage, et bien entendu qui prend en paramètre les éléments qui m'interressent, sinon je remonte TOUT le journal à chaque fois, et qui jongle avec les différents formats de contenu pour que l'on puisse traiter les sorties simultanément (avec un cat par exemple) et qui possède un système pour faire du back and forth (non parceque des fois je vais vouloir revenir en arrière sur le fichier qui défile, par exemple depuis un more - toujours sans charger TOUT le journal en mémoire).
Contrairement à ce que tu as l'air de penser faire un système qui fonctionne avec tous les outils traditionnels unix dans un nombre satisfaisant de consoles est loin d'être évident. Il ne s'agit pas juste de cracher les logs ligne à ligne.
Idéalement il faudrait que le lecteur de log émule un comportement de fichier, ce qui implique à son tour de faire un FS user space (petit et en user space), et donc d'installer des cochonneries sur la machine qui reçoit les logs.
Je ne suis pas sur que ce soit beaucoup plus simple que de recoder les outils unix pour qu'ils attaquent le raw directement. (Moi en tout cas je me sens plus à l'aise à écrire journalcat et journalgrep qu'à faire journalFS).
alors que c'est assez simple en fait
Ca doit être parce que c'est "super simple" que la première chose que dit la page freedesktop est "Faites pas les cons, utilisez l'API C (qui nécessite bien sur d'avoir tout systemd installé) sinon vous allez vous vautrer". Ils ajoutent aussi que si on ne veut vraiment pas utiliser l'API C il faut faire des exports complets (toujours via systemd). Mais alors attaquer les fichiers en raw - surtout pas mon bon ami.
La résistance au changement fait dire pas mal de choses…
Etre convaincu d'avoir raison et penser que toute personne qui vous contredit ne peut être qu'un réactionnaire mal avisé et stupide fait dire pas mal de conneries aussi.
Et t'aimes pas journalctl -f qui fait exactement la meme chose ?
Tu veux dire journalctl -af -o verbose ? ou journalctl -f -o short ?
Le truc c'est que c'est "presque" la même chose. Avec soit des petits bouts en plus, soit des petits bouts en moins.
Si la ligne est trop longue journalctl -f la tronque, et puis certains metas donnés par systemd n'apparaissent pas.
Si je passe en -af -o verbose, j'ai la ligne entière et les métas mais je peux me rammasser des caractères à la con et corrompre ma console.
Donc effectivement on est pas très loin, mais pour de la production une fois de plus…
Satisfaire ceux qui trouve un intérêt à systemd et ne pas faire son autiste qui fait chier le monde pour son plaisir.
Donc je rajoute un truc dont je n'ai pas besoin pour faire plaisir à des gens qui me considèrent comme un autiste parce que j'ose penser que systemd est un système inepte ?
Ecoute c'est l'argument qui m'a convaincu. Honnêtement dans ce thread on est déscendu très bas niveau mauvaise fois mais là on attend le top du top.
Donc vous pouvez me faire chier avec systemd mais j'ai pas le droit de vous faire chier avec systemd (parce que là je ferais mon autiste).
Ce qui est bien avec le libre… Ah non, en fait, rien à voir avec le libre! Ce qui est bien avec un format documenté, c'est que si le logiciel de lecture "par défaut" ne te convient pas, tu peux te cotiser et/ou développer un truc automne qui te plait à 100%.
C'est clair je n'ay avais pas pensé. Je vais de ce pas développer
Ah et en plus il y a un petit truc tout léger dans la page freedesktop :
Or, to put this in other words: this low-level document is probably not what you want to use as base of your project. You want our C API instead! And if you really don't want the C API, then you want the Journal Export Format instead!
Tant pis pour journalless, journalmore, journaleclipse, journalcat, journal> …. Dommage, pour une fois que j'étais motivé.
Qui a besoin des libs (au sens large hein - sd-gateway et totu le toutim) de journal, qui ne peuvent pas fonctionner sans les libs de systemd, qui à leur tour requierent DBus et d'autres trucs etc. En gros systemd et toute sa clique quoi.
Tu peux toujours le faire en configurant journald pour qu'il envoie les logs à ton système d'indexation préféré.
Oui je peux mettre journald juste pour faire joli et continuer à travailler en vrai avec syslog et consors, le tout pour un overhead modique. Mais là je ne vois pas l'interet.
A moins que tu ne puisses démontrer que ces commandes sont moins performantes ou moins puissantes que leurs homologues sur fichier texte. Tu peux?
a) Moins pratiques : il faut lire les logs sur un ordinateur qui a systemd et toute la clique installé. Si on essaye de lire les logs justement parceque le serveur plante/se comporte bizarrement il faut donc une autre machine avec systemd et toute la clique installée. A comparer avec des logs que ej peux lire sur n'importe quel machine ou presque et traiter avec le logiciel de mon choix.
b) Moins puissantes : avec des formats en texte pur je peux TOUT indexer si je veux, ou ne rien indexer si je veux aussi. Avec systemd si je veux utiliser les index en place je dois passer par l'API C, si je veux d'autres index tout le temps il faut soit que je passe par les USER_JOURNAL_FIELDS en les dénaturant soit que je fasse des exports et que je les indexe à la main (mais du coup je perd les index de base). Donc par exemple si je veux debugguer une phase initialisation SIP à la volée - ben je peux plus. Comme l'export ne fonctionne pas en continu ou en temps réel je suis obligé de faire un test, puis d'exporter, puis de lire le log et de recommencer. On dira ce qu'on voudra mais j'aimais tail -f moi.
c) Moins performant : Sur les choses qui sont prévus comme telle, il ne dervait pas y avori de soucis de performance avec journald. Il sera probablement plus rapide sur certains cas et moins rapide sur d'autres (Un format binaire normé peut difficilement battre de l'append de base sur de gros évènement genre crash java avec trois page de détails - par contre sur une flopée de petites insertion il devrait être meilleur.) Ceci étant j'attend une version stable pour faire des tests et voir le résultat.
Ca dépend des cas.
Pour le firewall, j'utilise les outils fournit avec (je suis sous pf que ce soit openbsd ou freebsd).
Pour les logs Apache et DNS vu qu'il y en a des tonnes, il y a d'abord un filtre baysien puis split des logs en deux (logs clasiques avec tout que je ne consulte quasiment jamais, logs de trucs "surprenant" qui ne fait souvent que quelques lignes par jour). Si j'ai un doute généralement j'ouvre le fichier de logs de l'heure concernée et j'y vais à la main (ca va vite vu que c'est classé par heure).
Pour les trucs verbeux et non prévisible (par exemple les echecs de mapreduce) c'est du custom basé sur Lucene
Pour les trucs proprios (on gère pas mal d'autocoms/gateway télécom non libres) on a des outils proprios pour analyser (et ils vont vite). de totue façon on a pas le format pour écrire nos propres trucs.
Sinon il y a aussi du awstats et des scripts qui font appel à rrdtool pour les rapports.
Après sinon il y a d'autres admins qui préfèrent lire les logs sous Mac ou sous Win et qui ont des outils à eux pour le faire.
[^] # Re: PEBKAC Comme d'hab...
Posté par Kaane . En réponse au journal Gnome-Shell, toujours pas convainquant après 1 an et demi. Évalué à 10.
Toujours le même problème avec l'I18N, c'est un boulot de malade et ca demande beaucoup d'attention tout le long de la chaîne. Dès qu'un maillon fait un truc un peu léger ça casse tout. Exactement pour ça que j'utilise tout en enUS._
J'aimerai prendre quelques instants pour résumer ton argumentation.
Donc :
1°) L'utilisateur ne sait pas se servir de Gnome-Shell sinon il saurait comment accéder à son appli en deux clicks => PEBCAK
2°) Les mainteneurs des packages Gnome3/Gnome-Shell ne savent pas se servir de Gnome-Shell sinon le .Desktop serait mieux configuré dans les distribs et tout le monde pourrait accéder a son appli en deux clicks => PEBCAK
3°) Tu ne sais pas te servir de Gnome-Shell, sinon tu ne serai pas en locale en_US, mais les traductions I18N c'est un boulot de malade qui demande d'être très concentré tout au long de la chaine.
Conclusion : Gnome-Shell ca permet d'accéder simplement à son appli en deux clicks, sauf que personne ne sait faire/ne veut faire et que ce serait un boulot de malade de le faire.
PEBCAK, définitivement PEBCAK…
# Mauvaise approche, changer d'approche.
Posté par Kaane . En réponse au journal Pourquoi je n’arrive pas à contribuer au logiciel libre.. Évalué à 10.
Sauf que moi, j'aimerais bien dépasser le stade du patch anecdotique, et m'impliquer dans un projet.
Le "stade" du patch anecdotique c'est la contribution à un projet.
Même sur des très gros projets libres tu peux finir par avoir une quantité non négligeable de code qui ne sont qu'une série de patch anecdotique. Le kernel Linux a commencé comme ça (et dans une certaine mesure il doit encore y avoir 30 à 40% du code qui sont des patchs anecdotiques)
Déjà, il faut trouver un projet qui m'intéresse
Mauvaise approche.
Pour commencer il faut que tu trouves un truc qui te casse les pieds. Un truc qui te manque. Code la fonctionnalité dont tu as besoin et dont tu vas te servir. Ensuite une fois ce problème réglé tu verras de toi même si ça serait intéressant de remonter le code dans un projet ou un autre.
[^] # Re: Révolutionnaire.... ?
Posté par Kaane . En réponse au journal Fusion Drive. Évalué à 5.
Apple n'a fait que reprendre cette technologie et lui donner un "nom qui sonne bien"
Euh non. Ils n'ont fait que reprendre le nom aussi…
http://www.fusionio.com/products/
(Ah au fait la tehcno marche du feu de dieu, mais pas sur le HFS+ implémenté par défaut sur mac - le commit/sync super retardé d'apple bouffe les perfs. Sinon sous Linux ca fait huit ans que je m'en sers (bon OK c'était pas vraiment une offre grand public (Et bon sang arrétez de marcher dans les trolls Apple de NedFlanders - ça l'encourage ( N.B : le stage de désintoxication du LISP a échoué, encore…))))
[^] # Re: Je sens que je vais me faire traiter de troll mais ...
Posté par Kaane . En réponse à la dépêche MPTCP, TCP dans un monde ultra‐connecté. Évalué à 2.
Tout à fait et c'est pour cela que la comparaison avec IPv6 Mobile est erronée.
Le problème est que je ne vois pas comment on peut faire des sources mutiples seulement avec de protocole MPTCP. Il va quand même bien falloir modifier les middle box ET les applis pour prendre en compte un changement d'IP.
Parceque mon appli quand elle va répondre à une demande, elle va le faire en "décidant" quelle est la bonne IP pour cette session.
Autant en IPv6 mobile avec mon IP qui se balade (voire qui est présente sur deux réseaux) - tout le niveau décisionnel va être géré par les routeurs. A partir de là mon appli se moque complètement de savoir si c'est une adresse IPv6 standard ou une appli IPv6 mobile. L'intelligence de routage se fait plus tard.
Par contre sur MPTCP il faut que mon appli sache que telle ou telle session correspond à X adresses IP. (Ou alors uen fois de plus qu'il y ait un proxy/daemon MPTCP qui fasse de la traduction d'adresse et qui fasse le load balancing).
# Je sens que je vais me faire traiter de troll mais ...
Posté par Kaane . En réponse à la dépêche MPTCP, TCP dans un monde ultra‐connecté. Évalué à 9.
Quand je lis les specs du MPTCP je n'arrive pas à me sortir de la tête que c'est juste une façon d'obtenir la même chose qu'avec de l'IPv6 Mobile mais sans passer à IPv4.
Je suis bien conscience qu'il y a des différences au niveau du protocole (je connais la dissociation IP/TCP) mais bon, IPv6 mobile était un truc qui devait permettre de rerouter rapidement (et à la volée) une machine (bon OK une interface) qui se déplace sur différents réseaux. MPTCP permet de faire la même (suivre un déplacement sur différent réseaux) chose au niveau connexion/session plutôt qu'au niveau machine.
Le premier problème que je vois est celui du double emploi - grosso-modo 80% des cas d'application de IPv6 mobile sont couverts par MPTCP (c'est à dire en pas se faire jeter et ne pas avoir à se réauthentifier en cas de changement de réseau).
Après pour les cas suivants (être capable de retrouver une machine ou qu'elle soit sur les réseau) il suffit d'écrire un petit démon qui balance un paquet de temps en temps pour permettre le seuivi. (une fosi qu'on aura les bonnes libs MPTCP ce petit démon devra peser dans les 50 lignes de codes et sera probablement donné en exemple dans la lib elle même).
Le second problème que ca pose est celui du déploiement. Le gros avantage d'IPv6 mobile (connexion continue avec un appareil mobile) est en train de partir à la poubelle. A partir de là on peut légitimement se demander si les opérateurs veront un interêt quelconque à déployer IPv6 mobile :Dans un cas j'achète du matos, je fais des tables de routages dynamiques et modifiées plusieurs fois par seconde si j'ai beaucoup de client, dans l'autre je met à jour le firmware de l'existant et je reste en v4 (Je veux pas être méchant mais le choix est vite fait…) Or si les opérateurs mobiles déploient MPTCP à la place de IPv6 mobile - on peut considérer que la norme IPv6 mobile est morte (non pas qu'elle soit super vivante en ce moment, ni qu'elle l'ait jamais été. Déjà IPv6 tout court…)
Le troisième problème que ca pose est celui du hack TCP pour pas passer en IPv6. Il y a 5 ou 6 ans je racontais en rigolant devant un commité d'experts ( https://linuxfr.org/board ) que les boites ne passeraient jamais en IPv6 (trop couteux et pas rentable du tout pour les premiers à faire le pas) et qu'on aurait à la place des hacks TCP qui permettrait de passer de 65536 ports à 16 millions. Comme ça NAT pour tout le monde et on en parle plus. C'était rigolo à l'époque - mais aujourd'hui ca me fait plus rire.
Donc si quelqu'un peut me dire que je me trompe (avec argument à l'appui - les one-liners "tu te trompes" et les "comment peut-on être assez @"!ù!! pour croire que" s'abstenir) ca me rassurerait. Je souhaite sincèrement être passé à coté d'une fonction IPv6 qui ne soit implémentable en 100 lignes de codes avec mptcp.
[^] # Re: Distributeur
Posté par Kaane . En réponse à la dépêche Lettre à Madame la ministre de la Culture concernant les abus de DRM. Évalué à 8.
La plupart s'en passeraient sans aucune hésitation.
Oui, enfin je doute fort que l'on puisse mettre Apple ou Amazon dans cette "plupart".
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 4.
Petit filtre sur l’exécutable du serveur, le pid du processus qui a pris en charge le client
Deux choses que je ne connais pas. Je connais l'adresse IP du mec qui me casse les pieds c'est tout.
tu peux quand même filtré sur le service ce qui n'est pas possible avec le syslog original et certain service (attention, j'y vais comme toi, je lance des affirmations sans vérification mais c'est ce que je viens de lire).
Tout dépend de quoi on parle
- Si c'est service au sens de daemon - ben ca va être dur de pas filtrer dessus vu que généralement ses logs vont être à part. (genre /var/log/daemon) après si j'ai décidé de les fusionner avec d'autres logs ça devient un peu mon problème.
- Si c'est service au sens d'instance - la plupart des logiciels permettent quand mêle de loguer très correctement par instance, mais même dans le cas ou ils ne permettent pas (j'ai pas d'exemple en tête) - le facteur déterminant sera probablement ailleurs (une fois de plus IP extérieure, segment de protocole qui part en vrille, activité d'un utilisateur etc.) Donc on va passer d'une complexité de O(n) à une complexité de l'ordre de O(log(n)) + O(n*p) (Avec p < 1, p étant la proportion de logs dans l'instance concernée). C'est mieux, mais pas transcendant.
Mais bon, la seul chose que tu as démontré, c'est que dans tes exemples, journald s'en sort aussi mal que syslog…
Une fois de plus je pense sincèrement que journald est meilleur que syslog, et sans systemd rattaché je serai déjà en train de le tester - mais c'est pas pour autant qu'il fait le café, ramène le journal et garanti le retour de l'être aimé. Il a des défauts - ben comme tous les programmes quoi.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 5.
Le problème c'est qu'on ne vas pas faire catwoman fichier_au_format_immonde
On va faire catwoman --filtre filtre1 --filtre filtre2 --filtre filtre3 --répertoire répertoires_rempli_de_fafi --options_de_sorties option1 --options_de_sorties option2 | monanalyzer_que_j'aime
Le truc c'est que de taper tout ça c'est casse pied. Donc on va vouloir se créer des scripts qui simplifient la vie. Genre aller modifier monanalyzer_que_j'aime pour qu'il génère les filtres à la volée en fonction de demandes humaines compréhensibles, avec des options par défaut bien remplies etc.
Genre monanalyzer_que_j'aime --filtre filtre1 filtre2 filtre3 répertoire_rempli_de_fafi
Et bien entendu le résultat de la sortie peut contenir des éléments non imprimables du fait de corruption (ou tout simplement parce que les options que j'ai choisi peuvent afficher ce type de caractères) Et encore plus si je peux mettre un buffer de façon à ne pas déployer 3 000 000 de lignes en mémoire c'est mieux - mais si je peux utiliser les commandes (par exemple de less ou more) pour sauter de 500 lignes en avant ou en arrière sans devoir tout dérouler entre c'est le pied (c'est ça le back and forth - parfois nommé mode pager).
Si j'ai tout ça je peux vraiment bosser comme j'ai l'habitude. Mais c'est complexe à mettre en place.
Comme quoi la simplicité KISS est illusoire ?
Pour le dev oui (enfin jusqu'à Lennart qui a l'air bien décidé à venger des générations de dev du joug des sysadmins). Demande à Alan Cox pour voir - il a des trucs palpitants à raconter sur la console.
Encore une vraie question : en quoi fuse est une cochonnerie ? Il permet de pousser à l’extrême le concept du tout est fichier.
Tout est fichier OUI. Tout est système de fichier moins. Il y a quand même des trucs assez crade dans fuse (ce qui n'enlève rien au fait que c'est un outil très très pratique).
J'ai enlevé un seul mot et ça s'applique à 80 % des personnes qui ont posté sur cette page, moi compris (PAF !).
Merde, moi qui croyait être un réactionnaire hipster. Je pensais trop me la péter dans 2 ans genre "je crachais sur systemd avant que ce soit à la mode de le faire !"
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
De ce que j'ai lu et compris (pas encore testé - pas sur de le faire très honnêtement) de ce qui est ici :
http://www.freedesktop.org/software/systemd/man/sd-journal.html
L'API fournit a la fois les capacités de parsing, mais aussi toutes les fonctionnalité pour faire client vis à vis de journald.
Si je me fie à ça :
#include
pkg-config --cflags --libs libsystemd-journal
Il doit être possible de compiler (et peut être même de linker) avec peu de libs installées.
Mais à l’exécution est-ce que ça peut vraiment se passer de tout le fratras qui est dans /src/shared ?
Ca serait une très bonne chose.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 4.
journalctl -D /var/run/log/journal/|grep 3.6.2-1-ARCH
Le fait que tu indiques à la mimine à journalctl l'emplacement du fichier de log prouve effectivement de façon éclatante qu'il est capable de trouver les logs tout seul quand DBus est éteint.
J'imagine bien sur que pour le test soit concluant sur au moins un point tu as supprimé les différentes librairies systemd avant de lancer la commande.
Non parce que moi de mon coté j'ai juste relu les headers de journalctl et le makefile.am et très honnêtement j'ai toujours peine à croire que ca puisse fonctionner sans rameuter tout le fratras de libs et de dépendances qui vont bien.
Ceci étant je ne me suis pas penché à fond sur le truc, il y a peut-être moyen de limiter les dégats en allant modifier certains éléments de /src/shared - mais vache il y a du boulot.
Franchement, arrête de raconter n'importe quoi alors que tu n'as absolument jamais vérifier ce que tu avances depuis le début.
Et de 4 rien que sur ce thread là. Tu cherches à battre un record ? Ou tu penses sincèrement que ca sert à quelque chose ?
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
Les spec sont sorties vendredi. C'est tout de même intéressant de ne pas oublier le contenu du journal.
Les specs commencent par "il ne faut pas lire les logs en raw". Ca va quand même être compliqué de créer un outil de parsing des données en stand alone et de l'incorporer au projet dans ces conditions.
Non tu veux une position contractuelle sur un produit qui n'est pas encore en alpha.
J'aimerai avoir une position contractuelle le plus vite possible. C'est pour ça que j'ai brulé un ticket pour poser la question. Maintenant je me doute bien qu'ils vont pas me répondre demain. Seulement quand j'entends dire que FORCEMENT les distribs serveurs vont passer à systemd, je me permet juste de signaler que les distribs en question elles ont pas l'air pressées de l'annoncer publiquement. Après mon interprétation est que ça ne sera pas si "forcément" que ça, ou pour être parfaitement exact je pense (opinion personnelle toussa) qu'elles cherchent à retarder au maximum le moment ou elles vont annoncer qu'elles ne supportent plus les autres init officiellement (ou alors avec des features en moins). Et si c'est le cas ca laisse à penser à son tour que tous les sysadmin du monde ne rêvent pas franchement la nuit du jour ou ils vont enfin passer systemd en prod. (Une fois de plus opinion personnelle toussa).
Après personnellement systemd me pose de vrais problèmes (que j'essaye d'exposer avec un succès mitigé), et je râle un peu quand on m'explique que journald est nettement mieux que tout ce qui existe dans tous les cas possibles et imaginables (sauf les miens - ce qui prouve bien que je trolle puisque journald est parfait)
C'est justement un problème des log texte. Tu n'a rien de fiable pour distinguer la forme et le contenu
A part les specs tu veux dire. J'avoue que c'est fouilli en effet. Mais bon le parseur universel qui fonctionne aussi bien avec les logs du serveur mail que le branchement des LUN SCSI que suivit de réplication LDAP j'y crois moyen.
Ceci étant si il n'y avait pas systemd derrière je serai probablement déjà en train de déployer journal sur les serveurs de tests - parce que oui il y a de vrais avantages et que les défauts ne sont pas insurmontables (mais ils sont là quand même).
_ ça aurais très bien pu être fais en xml par exemple, mais je n'ai pas l'impression que l'idée te plaise d'avantage_
Que les chose soient claires : je préfère des logs en binaires à du XML. En fait je préfère des logs en BIG5 avec maximum un caractère par ligne dans des fichiers de 2ko maximum à du XML.
Je ne vois pas comment faire rentrer du n'importe quoi (par essence un log on peut jamais être sur à 100% de ce qui va se trouver dedans) dans du XML à moins de faire de la soupe d'escape dans tous les sens. Et ça non merci.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 7.
Tu m'appelles le jour ou tu cherches dans tes logs sur un autre critère sur ceux fournit par journal…
J'ai pas les moyens financiers.
En partant du principe que l'index sur service ne compte pas vraiment (dans l'ancien système je serais allé chercher le bon fichier de log à la main mais ça ne pose pas vraiment de problème.)
Rien qu'aujourd'hui :
Problème avec une gateway SIP : donc parsage de log sur le contenu, notamment au niveau des tokens de sécurité dans les phases d'initialisation. Petit filtre sur l'init et sur l'adresse IP du client - damned c'est pas indexé par journald. (environ 15 coups de fil à vue de nez)
On continue avec la mise en place d'une nouvelle stratégie de cache - petit tests sur les expirations de cache du proxy et du memcached en fonction du log/delog des users. Petit filtre IP extérieur/login/réponse memcached - caramba encore raté (une petite vingtaine de coup de fil)
Les utilisateurs se plaignent d'un ralentissement. Ca serait les tests ? (Petit filtre sur les IP des machines des admins dans les logs des serveurs de prod - non c'est pas ça (3 coups de fils)) - par contre awstats montre une grosse monté des connexions, notamment en erreur. Ben tient tou vient de la même plage IP extérieure (5 coup de fils) qui nous casse aussi les pieds sur Bind (1 coup de fil), sur les ports mails (1 coup de fil), et même sur les plages CIFS (1 coup de fil). Ban de la plage et mail bien senti au provider (qui en a probablement rien à foutre mais c'est pas une raison pour ne pas le faire).
Donc aujourd'hui seulement entre 40 et 50 coup de fils comme ça, à la louche. Et encore tu t'en tire bien on a pas débugué de java ou de Riak aujourd'hui.
et tu nous faire perdre du temps
GNARARARARH Je vous oblige a répondre à mes posts sur linuxfr grace à mes grands pouvoirs. Je suis diabolique.
va coder si t'es si bon que ca et que t'as tous compris aux problèmes d'init et de logs
Tout à fait le fait d'avoir des problèmes qui ne sont pas résolus par systemd fait de moi
a) Un expert sur tout ce qui concerne l'init et les logs
b) Un développeur émérite
c) Un mec avec assez de temps libre pour recoder tout ça en mieux
Et le pire c'est que je suis fan de beaucoup d'idées de journald (la continuité des logs par exemple, le coté analyse temps réel qui viendra surement bientôt, les index - même si j'aimerai pouvoir définir les miens etc.) Mais journald a encore de grosses lacunes et un aspect rédhibitoire : celui de ne pas pouvoir fonctionner sans systemd.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
O(log(n)) c'est tout le temps, y'a pas d'indexeur dans journald…
Mais oui, il cherche parmi n éléments pour un élément spécifique en O(log(n)) le tout sans index, et ce y compris sur le contenu des éléments du journal.
Tu es au courant que ça n'est pas mathématiquement possible ?
Bien entendu journald indexe tous les champs ou presque (de façon générale tous les champs qui commencent par _ (donc les champs de confiances) sont indexés).
Tu veux faire une recherche sur un autre champ ? Ben tu te prends un O(n) dans la gueule (ce qui est une fois de plus tout à fait normal).
Mais de quoi tu parles, t'en a pas marre de raconter n'importe quoi ?
Je m’entraine avec des pro, donc je me lasse jamais.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
Oui, par ce qu'il est bien connu que grep, sed, awk, perl et autres ont obligatoirement besoin d'un fichier, ils ne savent pas utiliser l'entrée standard qu'on leur donne avec un pipe.
Comment tu remontes dans les logs avant ton curseur initial avec une entrée standard ? Non juste pour savoir. C'est un truc qu'il m'arrive d'utiliser quand je lis des logs.
Ceci étant il semble que el bug soit en voie de correction :
http://www.spinics.net/lists/fedora-devel/msg172481.html
Faux. Il suffit de libsystemd-id128.so et libsystemd-journal.so, pas besoin du reste de systemd. Sur ma machine ca prend environ 332ko.
Alors vu que id128 ne sert qu'à générer des id et que -journal ne fait que de créer les interface j'ai du mal à y croire.
Si il n'y a pas un systemd qui tourne, journalctl n'est même pas capable de trouver les logs tout seul. Il va essayer de se connecter à DBus pour parler à systemd. Et si il n'y a pas, ben il s'arrête là.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 4.
En attendant, tu peux fournir des vrais arguments? Parce que la, ben… Non,
Dans l'ordre du thread
https://linuxfr.org/nodes/96086/comments/1401649 : réponse à gnumdk sur l'avantage du parsage des index. Bien entendu ca ne marche que pour les index prédéfinis par journald, pour tout le reste soit on indexe à la mano soit on est en O(n) comme journald.
https://linuxfr.org/nodes/96086/comments/1401342 : deuxième partie : comment faire confiance à un init aussi fragile sur des trucs aussi cruciaux que le montage de disques NFS et qui se vautre quand il y a un fichier à la racine du /var. Je veux bien que ce soit le "début" de systemd - mais malgré tout c'est assez surprenant un init qui explose en vol comme ça. Surtotu quand on voit que les corrections ne sont pas faites coté systemd - mais coté appli (pour pas faire de mal au pauvre init tout fragile…)
https://linuxfr.org/nodes/96086/comments/1401231 : On peut parfaitement indexer des fichiers textes (et même le faire bien) - ca ne saurait donc être une raison suffisante pour passer à un format binaire. Premier (mauvais) exemple avec sqlite, second meilleur exemple avec dovecot + maildir/mbox
https://linuxfr.org/nodes/96086/comments/1401645 : Explication sur pourquoi journald est moins pratique et moins puissant en l'état que syslog. Petite digression sur le fait qu'il faille rameuter tout systemd pour lire un fichier de log (ce qui est pénible). Deuxième digression sur le thème "T'a qu'à utiliser les outils classiques pour ça". Merci, je sais que les outils classiques fonctionnent. Le but étant de montrer des lacunes (ou non) de journald, citer le rappatriement des données au format texte et leur analyse par les outils classiques n'apporte pas grand chose.
Ca serait mal élevé de ne parler que de moi :
https://linuxfr.org/nodes/96086/comments/1401432 : Alors oui, je ne sais pas de combien journald réduit la chose, mais toute réduction de taille est la bienvenue. Y-a-t-il seulement réduction de taille, je ne suis pas convaincu. Moonz non plus apparament.
https://linuxfr.org/nodes/96086/comments/1401277 : Tu es bien gentil de fournir tant d'arguments (la, pour le fichier spec, c'est clair, net, précis…), moi il me suffit déjà de regarder qui paye le salaire du développeur pour savoir au moins pour une distrib! Je demande une position officielle, on me répond par un commentaire dans un fichier source. Tu as l'air de considérer que c'est la preuve ultime. Pas convaincu.
https://linuxfr.org/nodes/96086/comments/1401344 : Mais je découvre qu'il y en a qui s'y mettent alors que le produit n'est même pas en alpha. Ou alors c'est du bluff, juste pour troller et inventer des critiques quand il n'y en pas. Je m'interresse à un produit qui modifie profondément le fonctionnement du système et qui nécesite une planification avancée c'est donc que je cherche à troller. Il n'y a pas d'autres explications possibles.
https://linuxfr.org/nodes/96086/comments/1401239 : Mais alors, pourquoi personne ne l'a donc fait? Faut croire que ce n'est pas si facile… qui va bien avec :
https://linuxfr.org/nodes/96086/comments/1401705 : alors que c'est assez simple en fait (mais déjà ce simple, personne n'a suffisamment souffert de systemd pour le coder…). et avec :
https://linuxfr.org/nodes/96086/comments/1401688 : Faut juste se dire que si ce n'est pas encore fait, c'est peut-être que dans la vraie réalité, ce n'est pas un problème.
Si ca n'existe pas dans l'ancien système c'est que c'est très compliqué, si ca n'existe pas dans le nouveau système c'est qu'il n'y en a pas besoin.
https://linuxfr.org/nodes/96086/comments/1401374 : Comme journald donc? Oui comme journald, le truc étant de démontrer que l'on peut doner à un fichier texte le même type d'index qu'à un fichier binaire tel celui utilisé par journald, on se retrouve au final avec un index du même type que celui de journald.
https://linuxfr.org/nodes/96086/comments/1401695 : journalctl et un pipe, et tu as tous les outils La j'avoue que j'ai beaucoup rigolé - déjà parcequ'une fois de plus il s'agit d'un raisonnement de type "Tu vois bien que le nouveau système est mieux, vu que l'ancien fonctionne" et ensuite parceque non, journalctl et un pipe ca ne donne pas tous les outils loin de là. Et surtout ca ne donne pas le comportement habituel de navigation au sein des fichiers de log. Journalctl c'est pas vraiment gunzip - je peux pas franchement faire un cat de tous mes filtres journald et les piper dans un less.
https://linuxfr.org/nodes/96086/comments/1401731 : Libre à toi de ne pas prendre systemd et journald, mais il faut assumer le coût de maintenance de ce truc archaïque que tu veux à la place. On parle du truc archaïque que tu me conseilles d'utiliser toutes les trois lignes quand je t'expose un problème ? Oui je pense que je vais suivre tes conseils et le garder encore un peu. Au moins jusqu'à ce que systemd devienne capable de faire ce dont j'ai besoin professionnellement. Je suis plus BSDinit que sysvInit (mais c'est un système archaïque aussi) et on est un petit nombre à vouloir le garder ce système archaïque. (Tous des réactionnaires à ornière j'imagine)
https://linuxfr.org/nodes/96086/comments/1401734 : Un peu comme un log texte qui est différent suivant la distro? Les log, c'est presque la même chose partout… Mais tu les aime,s va comprendre pourquoi.
Je sais qu'on est pas supposé dissocier le fond de la forme, mais rassure moi, tu as conscience du fait que tu parles du contenu et moi du contenant ?
Voilà, voilà…
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 3.
Gni? Non, il suffit de faire un bête logiciel qui sort du texte des fichiers de log (bref, un bête remplaçant de journalctl qui fait qu'une chose)
Et qui interprete les meta systemd, comme la date, le numero de PID, le nom de la machine etc. Bref un truc qui prend un fichier binaire raw et qui le formatte pour l'affichage, et bien entendu qui prend en paramètre les éléments qui m'interressent, sinon je remonte TOUT le journal à chaque fois, et qui jongle avec les différents formats de contenu pour que l'on puisse traiter les sorties simultanément (avec un cat par exemple) et qui possède un système pour faire du back and forth (non parceque des fois je vais vouloir revenir en arrière sur le fichier qui défile, par exemple depuis un more - toujours sans charger TOUT le journal en mémoire).
Contrairement à ce que tu as l'air de penser faire un système qui fonctionne avec tous les outils traditionnels unix dans un nombre satisfaisant de consoles est loin d'être évident. Il ne s'agit pas juste de cracher les logs ligne à ligne.
Idéalement il faudrait que le lecteur de log émule un comportement de fichier, ce qui implique à son tour de faire un FS user space (petit et en user space), et donc d'installer des cochonneries sur la machine qui reçoit les logs.
Je ne suis pas sur que ce soit beaucoup plus simple que de recoder les outils unix pour qu'ils attaquent le raw directement. (Moi en tout cas je me sens plus à l'aise à écrire journalcat et journalgrep qu'à faire journalFS).
alors que c'est assez simple en fait
Ca doit être parce que c'est "super simple" que la première chose que dit la page freedesktop est "Faites pas les cons, utilisez l'API C (qui nécessite bien sur d'avoir tout systemd installé) sinon vous allez vous vautrer". Ils ajoutent aussi que si on ne veut vraiment pas utiliser l'API C il faut faire des exports complets (toujours via systemd). Mais alors attaquer les fichiers en raw - surtout pas mon bon ami.
La résistance au changement fait dire pas mal de choses…
Etre convaincu d'avoir raison et penser que toute personne qui vous contredit ne peut être qu'un réactionnaire mal avisé et stupide fait dire pas mal de conneries aussi.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
Et t'aimes pas journalctl -f qui fait exactement la meme chose ?
Tu veux dire journalctl -af -o verbose ? ou journalctl -f -o short ?
Le truc c'est que c'est "presque" la même chose. Avec soit des petits bouts en plus, soit des petits bouts en moins.
Si la ligne est trop longue journalctl -f la tronque, et puis certains metas donnés par systemd n'apparaissent pas.
Si je passe en -af -o verbose, j'ai la ligne entière et les métas mais je peux me rammasser des caractères à la con et corrompre ma console.
Donc effectivement on est pas très loin, mais pour de la production une fois de plus…
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
Satisfaire ceux qui trouve un intérêt à systemd et ne pas faire son autiste qui fait chier le monde pour son plaisir.
Donc je rajoute un truc dont je n'ai pas besoin pour faire plaisir à des gens qui me considèrent comme un autiste parce que j'ose penser que systemd est un système inepte ?
Ecoute c'est l'argument qui m'a convaincu. Honnêtement dans ce thread on est déscendu très bas niveau mauvaise fois mais là on attend le top du top.
Donc vous pouvez me faire chier avec systemd mais j'ai pas le droit de vous faire chier avec systemd (parce que là je ferais mon autiste).
Ca me rapelle le bon vieux temps.
PLONK !
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
Ce qui est bien avec le libre… Ah non, en fait, rien à voir avec le libre! Ce qui est bien avec un format documenté, c'est que si le logiciel de lecture "par défaut" ne te convient pas, tu peux te cotiser et/ou développer un truc automne qui te plait à 100%.
C'est clair je n'ay avais pas pensé. Je vais de ce pas développer
journalgrep, journalawk, journalsed, journaltail, journalvi, journalemacs, journalperl, journal…
Bien sur.
Ah et en plus il y a un petit truc tout léger dans la page freedesktop :
Or, to put this in other words: this low-level document is probably not what you want to use as base of your project. You want our C API instead! And if you really don't want the C API, then you want the Journal Export Format instead!
Tant pis pour journalless, journalmore, journaleclipse, journalcat, journal> …. Dommage, pour une fois que j'étais motivé.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 3.
Non, il suffit de journalctl.
Qui a besoin des libs (au sens large hein - sd-gateway et totu le toutim) de journal, qui ne peuvent pas fonctionner sans les libs de systemd, qui à leur tour requierent DBus et d'autres trucs etc. En gros systemd et toute sa clique quoi.
Tu peux toujours le faire en configurant journald pour qu'il envoie les logs à ton système d'indexation préféré.
Oui je peux mettre journald juste pour faire joli et continuer à travailler en vrai avec syslog et consors, le tout pour un overhead modique. Mais là je ne vois pas l'interet.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 0.
Journal récupère les infos en O(log(n))
Les infos qu'il a indexé hein. Pas forcément les infos que tu veux. Pour les infos qui sortent des clous c'est du O(n) aussi.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 6.
A moins que tu ne puisses démontrer que ces commandes sont moins performantes ou moins puissantes que leurs homologues sur fichier texte. Tu peux?
a) Moins pratiques : il faut lire les logs sur un ordinateur qui a systemd et toute la clique installé. Si on essaye de lire les logs justement parceque le serveur plante/se comporte bizarrement il faut donc une autre machine avec systemd et toute la clique installée. A comparer avec des logs que ej peux lire sur n'importe quel machine ou presque et traiter avec le logiciel de mon choix.
b) Moins puissantes : avec des formats en texte pur je peux TOUT indexer si je veux, ou ne rien indexer si je veux aussi. Avec systemd si je veux utiliser les index en place je dois passer par l'API C, si je veux d'autres index tout le temps il faut soit que je passe par les USER_JOURNAL_FIELDS en les dénaturant soit que je fasse des exports et que je les indexe à la main (mais du coup je perd les index de base). Donc par exemple si je veux debugguer une phase initialisation SIP à la volée - ben je peux plus. Comme l'export ne fonctionne pas en continu ou en temps réel je suis obligé de faire un test, puis d'exporter, puis de lire le log et de recommencer. On dira ce qu'on voudra mais j'aimais tail -f moi.
c) Moins performant : Sur les choses qui sont prévus comme telle, il ne dervait pas y avori de soucis de performance avec journald. Il sera probablement plus rapide sur certains cas et moins rapide sur d'autres (Un format binaire normé peut difficilement battre de l'append de base sur de gros évènement genre crash java avec trois page de détails - par contre sur une flopée de petites insertion il devrait être meilleur.) Ceci étant j'attend une version stable pour faire des tests et voir le résultat.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 2.
Par curiosité, qu'utilises-tu ?
Ca dépend des cas.
Pour le firewall, j'utilise les outils fournit avec (je suis sous pf que ce soit openbsd ou freebsd).
Pour les logs Apache et DNS vu qu'il y en a des tonnes, il y a d'abord un filtre baysien puis split des logs en deux (logs clasiques avec tout que je ne consulte quasiment jamais, logs de trucs "surprenant" qui ne fait souvent que quelques lignes par jour). Si j'ai un doute généralement j'ouvre le fichier de logs de l'heure concernée et j'y vais à la main (ca va vite vu que c'est classé par heure).
Pour les trucs verbeux et non prévisible (par exemple les echecs de mapreduce) c'est du custom basé sur Lucene
Pour les trucs proprios (on gère pas mal d'autocoms/gateway télécom non libres) on a des outils proprios pour analyser (et ils vont vite). de totue façon on a pas le format pour écrire nos propres trucs.
Sinon il y a aussi du awstats et des scripts qui font appel à rrdtool pour les rapports.
Après sinon il y a d'autres admins qui préfèrent lire les logs sous Mac ou sous Win et qui ont des outils à eux pour le faire.
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
c'est un outil pas bien car pas grep
Je n'utilise jamais grep (ou sed ou awk) sur mes logs. (Enfin tellement rarement que c'est vraiment exceptionnel)
[^] # Re: Pourquoi du binaire
Posté par Kaane . En réponse au journal Documentation du format du Journal. Évalué à 1.
Désolé, j'ai du mal à voir la moindre différence
C'est pas grave, tu t'en remettras.