Journal Le journal

Posté par (page perso) .
Tags : aucun
28
6
sept.
2012

Puisque on parle beaucoup de systemd en ce moment, j'ai fait la migration quand j'ai compris que Arch allait passer à systemd, je préfère prendre un peu d'avance plutôt que de me retrouver face au mur.

Bon, pour moi, ça fonctionne bien mais je n'ai pas envie de parler de lui.

Une autre partie de systemd qui a fait faire des bonds à beaucoup de monde, c'est journald, le "remplaçant" de syslog… (ce qui n'est pas vraiment le cas).

Déjà, journald permet – pour ceux qui le souhaitent – de renvoyer les logs vers un service syslog standard, car ce dernier ne s'occupe pas de la centralisation réseau des logs, juste de leur collecte.

Ensuite, je faisais aussi partie des sceptiques sur ce journal sans fichiers de conf' texte pour un filtrage via le shell des logs.

Au final, je trouve journald très sympathique à utiliser car la commande d'extraction des logs permet de pré-filtrer ce que l'on cherche sur des critères pertinents, pour ensuite utiliser les utilitaires unix pour extraire l'information voulue.

Quelques petits exemples :

On cherche ici les logs d'un service en particulier, kdm:

[gnumdk@arch ~]$ journalctl _SYSTEMD_UNIT=kdm.service
Logs begin at Thu, 06 Sep 2012 09:00:41 +0200, end at Thu, 06 Sep 2012 11:03:12 +0200.
Sep 06 09:03:02 arch kdm_greet[405]: Cannot load /usr/share/apps/kdm/faces/.default.face: Aucun fichier ou dossi
Sep 06 09:03:04 arch kdm[404]: :0[404]: pam_unix(kde:session): session opened for user gnumdk by (uid=0)

On peut, de manière plus simple, passer directement le processus recherché :

[gnumdk@arch ~]$ journalctl /usr/sbin/sshd 
Logs begin at Thu, 06 Sep 2012 09:00:41 +0200, end at Thu, 06 Sep 2012 11:03:12 +0200.
Sep 06 09:00:45 arch sshd[348]: Server listening on 0.0.0.0 port 22.

Voilà, pour continuer cette semaine Lennart inside

  • # ?

    Posté par . Évalué à  10 .

    Si des gens se mettent à collecter des faits avant de faire des analyses, comment vont faire les trolls ?

    "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: ?

      Posté par (page perso) . Évalué à  -10 .

      Utilise e4rat et tu verras de l'inutilité de systemd en terme de performance au démarrage.

      Sinon ma question du jour est :
      Si la fonction "autorun" doit être développer dans udev ou dans gnome 3 ?

      • [^] # Re: ?

        Posté par . Évalué à  10 .

        Tu as oublié le lien vers le benchmark.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: ?

          Posté par (page perso) . Évalué à  9 .

          Je ne connaissais pas e4rat, et je n'ai pas installé systemd pour faire de benchmark. Cependant, ce e4rat a piqué ma curiosité, aussi je l'ai testé et en voici le retour:

          Conclusions :
          - pour un disque "standard/à plateaux", e4rat apport un gain indéniable en terme de temps de démarrage
          - comme e4rat est basé sur la défragmentation de ext4, et sur la pré-allocation, il n'y a gère de gain à attendre pour un disque SSD
          - son utilisation n'est pas transparente, dans le sens où après des mises à jours significatives de la machine, il faut repasser par les étapes "d'apprentissage" (e4rat-collect) et "d'optimisation" (e4rat-realloc). Ce n'est pas très compliqué à faire, mais pas vraiment à mettre entre les mains d'un néophyte.

          • [^] # Re: ?

            Posté par . Évalué à  7 .

            J'ai donc dus convertir mes partitions ext3 en ext4

            Tu rigoles pas quand tu fais des tests toi!

            il n'y a gère de gain à attendre pour un disque SSD

            Pas plus qu'avec systemd en fait. Le type qui consacre du temps à améliorer son temps de boot sur un disque ssd est un bel enc*leur de mouches.

            e4rat apport un gain indéniable en terme de temps de démarrage

            Et même un peu plus que le démarrage, car il est possible d'y faire rentrer une ou deux applications utilisée fréquemment (browser, éditeur,..) ce qui n'est pas négligeable, surtout sur les petites machines.

            • [^] # Re: ?

              Posté par (page perso) . Évalué à  2 .

              J'ai donc dus convertir mes partitions ext3 en ext4
              Tu rigoles pas quand tu fais des tests toi!

              Ce n'est pas non plus très compliqué. D'après https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 , il y a 2 commandes à taper pour les partitions non-système, et à remplacer le ext3 par ext4 dans le /etc/fstab.
              Pour la partition système, j'ai rebooté la machine sur un distribution live afin de lancer les commandes. Ce n'est pas le plus simple, mais cela m'a paru plus sécurisé.

              En fait, le temps de la conversion se résume grosso-modo à celui de faire un e2fsck .

              L'effet collatéral est que je ne peux plus monter mes partitions qu'en ext4 . Mais ce n'est pas un problème, puisque toutes les distributions majeurs ou en live le supporte par défaut.

              Et même un peu plus que le démarrage, car il est possible d'y faire rentrer une ou deux applications utilisée fréquemment (browser, éditeur,..) ce qui n'est pas négligeable, surtout sur les petites machines.

              Oui, tout à fait, il suffit lancer ces applis lorsque le "e4rat-collect" fonctionne.

            • [^] # SSD

              Posté par . Évalué à  6 .

              disque SSD

              Ça m'énerve à chaque fois que je vois ou entends : parler d'un disque SSD n'a aucun sens. Un disque, c'est une galette qui tourne. Il n'y a rien de tel ici.

              Donc on dit "SSD", tout court, et pas "disque SSD".

              • [^] # Re: SSD

                Posté par . Évalué à  1 .

                Ah tiens, wep. Mais va falloir que tu signale un gros bug chez Gnome, alors :
                Ah tiens, nan, ils y ont déjà pensé : https://live.gnome.org/Design/Apps/Disks#Discussion

              • [^] # Re: SSD

                Posté par (page perso) . Évalué à  4 .

                C'est le syndrome SDS
                (Syndrome du Disque SSD)

                Aussi appelé le syndrome PNS (PIN Number Syndrome)
                Voir aussi RAS syndrome

                • [^] # Re: SSD

                  Posté par . Évalué à  4 .

                  Il est dommage que les SSD ne soient pas mous, qu'est ce qu'on rigolerait!

                  • [^] # Re: SSD

                    Posté par . Évalué à  1 .

                    OS de petitmou, disque mou requis!

              • [^] # Re: SSD

                Posté par . Évalué à  2 .

                Et que penser de clé USB :)

              • [^] # Re: SSD

                Posté par . Évalué à  4 .

                Un disque n'a pas besoin de tourner pour être un disque. C'est surtout l'ensemble des points d'un plan situé à une distance inférieur à une constante donnée d'un point donné.

                Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                • [^] # Re: SSD

                  Posté par . Évalué à  3 .

                  Ok, si tu veux. Mais ça ne change rien au fait qu'un SSD n'a rien d'un disque.

              • [^] # Re: SSD

                Posté par . Évalué à  1 .

                Moi ça m'énerve à chaque fois que j'entends parler d'une souris informatique. Une souris c'est un rongeur qui mange du fromage, ou bien c'est un morceau de la patte arrière de l'agneau. Il n'y a rien de tel ici.

                • [^] # Re: SSD

                  Posté par . Évalué à  3 . Dernière modification : le 09/09/12 à 13:46

                  Parce que dispositif de pointage c'est plus vague (ça peut s'appliquer à une tablette graphique) en plus d'être lourdingue ?

                  Je comprends ton énervement mais tu ne proposes pas de mot pour remplacer souris. Mot qui vient j'imagine de la ressemblance avec l'animal, à cause du fil qui peut faire penser à une queue.

                  De plus,

                  c'est un morceau de la patte arrière de l'agneau

                  Et c'est super bon braisé en cocotte ! Mais déjà là je ne vois plus trop le rapport avec le rongeur ;)

                  D'ailleurs saviez-vous qu'en latin tous les petits rongeurs genre souris, mulot, surmulot, etc… étaient désignés par le mot musculus qui veut dire muscle. Parce que ces rongeurs faisaient penser à de petits muscles :)

                • [^] # Re: SSD

                  Posté par (page perso) . Évalué à  2 .

                  Moi ça m'énerve à chaque fois que j'entends parler d'une souris informatique

                  Non, mais franchement, le mec qui a inventé le truc, il avait envie d'appeler ça une souris, y'a pas de quoi en faire un fromage! :p

                  • [^] # Re: SSD

                    Posté par . Évalué à  2 .

                    Comme souvent c'est pas le mec qui a inventé le truc qui lui a donné son nom ! Par exemple c'est pas Thalès qui s'est dit, ça c'est le théorème de Thalès, c'est les gens après lui qui ont donné ce nom au théorème d'intersection…

                    • [^] # Re: SSD

                      Posté par (page perso) . Évalué à  3 .

                      Le type s'appelait M. Souris ?

                      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

                      • [^] # Re: SSD

                        Posté par . Évalué à  2 .

                        Mickey de son prénom ;)

      • [^] # Re: ?

        Posté par . Évalué à  6 .

        Ou pas. Sur un vieux portable (~2001), je n'ai vu aucune différence.

        Je sais qu'un exemple perso ne fait pas la règle, mais ce n'est pas non plus une solution miracle.

        Et tant que ma distribution ne le fournit pas par défaut (alors qu'elle fournit systemd), je n'ai pas vraiment envie d'installer un outil qui modifie un truc aussi vital que le filesystem.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: ?

          Posté par . Évalué à  3 .

          un outil qui modifie un truc aussi vital que le filesystem

          E4Rat ne modifie rien du tout, il réalloue.

          • [^] # Re: ?

            Posté par . Évalué à  1 .

            Parce que quand des blocs sont réalloués, rien n'est modifié ?

            J'avais testé e2defrag il y a longtemps en me disant que puisqu'il déplace des blocs, rien n'est modifié. Mal m'en a pris car comme ça prenait des heures, j'ai voulu l'annuler, et j'ai perdu une partition comme ça.

            Je suis bien d'accord que je suis seul responsable de ça, mais il est faux de dire que c'est sans effet.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: ?

              Posté par . Évalué à  2 .

              Ok alors, en tout cas j'utilise e4rat sur différentes machines sous différentes distro depuis un moment et je n'ai jamais eu de problème.

      • [^] # Re: ?

        Posté par . Évalué à  4 .

        Utilise e4rat et tu verras de l'inutilité de systemd en terme de performance au démarrage.

        D'après le site du projet, e4rat supporte uniquement les systèmes de fichiers ext4. Systemd n'a pas cette contrainte.

        • [^] # Re: ?

          Posté par . Évalué à  1 .

          Il y a aussi readahead / readahead-fedora, qui fait du préchargement des fichiers utilisés au boot, sans réallocation sur le disque (pas besoin d'ext4).

          Je n'ai pas essayé e4rat, parce que je ne voulais pas modifier la partition, donc je ne peux pas comparer. Mais readahead-fedora a divisé mon temps de boot par 2 (et ce n'est pas un sentiment, bootchart, toussa..)

    • [^] # Re: ?

      Posté par . Évalué à  -1 .

      ou sont les faits ?
      pour avoir vraiment des faits il faut comparer deux choses, genre avant apres
      mais la on a rien

    • [^] # Re: ?

      Posté par (page perso) . Évalué à  2 .

      Comme avant, en oubliant les faits et en ne gardant que l'émotionnel.

      Voir http://youarenotsosmart.com/2010/06/23/confirmation-bias/

  • # Grep

    Posté par . Évalué à  9 . Dernière modification : le 06/09/12 à 12:24

    Pardonnez ma remarque, mais extraire des informations d'un fichier texte ça ne se fait pas déjà avec grep ??? Et puis ça c'est standard sur quasiment tous les OS unix-like.

    • [^] # Re: Grep

      Posté par (page perso) . Évalué à  5 .

      journald enregistre les logs dans des fichiers binaires, comme sous Windows. Donc les outils traditionnels ne sont plus utilisables.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Grep

        Posté par . Évalué à  7 .

        Quelle est l'utilité d'un fichier binaire spécifique par rapport à un fichier texte gzippé ?
        Je veux dire, pourquoi ont-ils fait ce choix ?

        • [^] # Re: Grep

          Posté par (page perso) . Évalué à  10 .

          J'aurai tendance à dire pour la même raison que MySQL ne stocke pas ses bases dans des fichiers texte gzippés ? :)

          Non, en fait surtout parce que :

          [gnumdk@arch 6bfe1c940a35530556670757000002d6]$ journalctl -o json /usr/sbin/sshd
          Logs begin at Thu, 06 Sep 2012 09:00:41 +0200, end at Thu, 06 Sep 2012 13:10:38 +0200.
          [
          {
                  "__CURSOR" : "s=fb5ad03a60b34383af26f8a26268152c;i=2d5;b=9ee81871088f4474b32141ba6e2cb993;m=7ee67f;t=4c9
                  "__REALTIME_TIMESTAMP" : "1346914845081883",
                  "__MONOTONIC_TIMESTAMP" : "8316543",
                  "_BOOT_ID" : "9ee81871088f4474b32141ba6e2cb993",
                  "_TRANSPORT" : "syslog",
                  "PRIORITY" : "6",
                  "SYSLOG_FACILITY" : "4",
                  "SYSLOG_IDENTIFIER" : "sshd",
                  "SYSLOG_PID" : "348",
                  "MESSAGE" : "Server listening on 0.0.0.0 port 22.",
                  "_PID" : "348",
                  "_UID" : "0",
                  "_GID" : "0",
                  "_COMM" : "sshd",
                  "_EXE" : "/usr/sbin/sshd",
                  "_CMDLINE" : "/usr/sbin/sshd -D",
                  "_SYSTEMD_CGROUP" : "/system/sshd.service",
                  "_SYSTEMD_UNIT" : "sshd.service",
                  "_SOURCE_REALTIME_TIMESTAMP" : "1346914845081595",
                  "_MACHINE_ID" : "6bfe1c940a35530556670757000002d6",
                  "_HOSTNAME" : "arch"
          }
          ]
          
          

          En fait, journalctl permet de lire ses logs dans plusieurs formats ce qui peux vraiment facilité les choses quand on veut "parser" ces derniers. Et que c'est plus simple d'avoir des objets avec toutes les informations plutôt que des lignes de texte. Sur des très gros logs, journalctl doit être beaucoup plus rapide (affirmation gratuite).

          • [^] # Re: Grep

            Posté par (page perso) . Évalué à  8 .

            Et moi qui croyait que c'était pour avoir un système de log aussi utile que celui de Windows … Mince !

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

            • [^] # Re: Grep

              Posté par (page perso) . Évalué à  10 .

              Le problème des logs sous Windows, ce n'est pas vraiment l'outil mais les logs en eux même…

              Si tu veux commencer à avoir des logs utiles, il faut activer des clés de registre et ouvrir des fichiers texte de 30000 lignes absolument imbitables. Le juste milieu chez Microsoft, on connait pas.

              [m - 30] avant une réaction de PBPG :)

          • [^] # Re: Grep

            Posté par . Évalué à  1 .

            Il me semble qu'on peut très bien transformer du texte en json ou autre. Donc l'argument stocker en binaire pour pouvoir le sortir en plein de format est juste complètement foireux.

            Après l'argument de la rapidité je n'en sais rien.

            • [^] # Re: Grep

              Posté par (page perso) . Évalué à  5 .

              Sauf qu'il me semble que les logiciels formatent leur logs actuellement comme ils le veulent donc ca doit être un beau bordel à convertir si il faut gérer plein d’exceptions.

            • [^] # Re: Grep

              Posté par (page perso) . Évalué à  5 .

              il me semble qu'on peut très bien transformer du texte

              Je te prend au mot : prouve-le.
              Le problème des 36 bouts de texte des logs Linux, c'est que c'est une horreur à parser à coup de regex à faire fuir des gens au cerveau normalement constitué (je n'ai rien contre les gens comprenant regex, j'en suis même jaloux). Si jamais tu y arrives sur une distro, tu peux être sûr que sur la distro voisine ton script merdera.
              Et pour la vitesse, c'est le jour et la nuit (ben c'est un peu évident : tester 15 octets pour une date et en comprendre la signification, alors qu'un bête int32 suffit, c'est différent)

              • [^] # Re: Grep

                Posté par . Évalué à  6 .

                Le problème des 36 bouts de texte des logs Linux, c'est que c'est une horreur à parser à coup de regex

                Effectivement je n'avais pas vu ça comme ça. Mais là il aurait pu imposer un format texte pour systemd, du coup ce problème n'aurait pas forcément existé.

                Je critiquais juste l'argument « on stocke en binaire pour générer tout type de format », qui me semble complètement stupide. Que ce soit binaire ou texte au départ, on peut générer tout type de format aussi facilement, modulo la vitesse bien sûr.

                • [^] # Re: Grep

                  Posté par (page perso) . Évalué à  5 . Dernière modification : le 06/09/12 à 14:46

                  Pour reprendre l'exemple de la date, il est nettement plus simple de spécifier "le int est le nombre de jours depuis le 1/1/1970" que de prendre toute la norme ISO pour la date. Et aussi, la personne qui se plante dans l'implémentation le voit plus rapidement.
                  Le binaire a parfois du bon (même si tout n'est pas parfait avec du binaire, ça n'évite pas tous les problèmes d'implémentation) et pas qu'en vitesse (en vitesse, ça explose largement le texte), il ne faut pas le jeter "car c'est pas Unix on ne peux plus faire de grep", rien n'empèche de convertir le binaire en texte qu'on passe à Grep ensuite, l'avantage est qu'on peut "convertir" dans différents format bien plus facilement.
                  Certes HTML a gagné à coup de trucs "lisibles", mais ce n'est pas forcément ce qui est plus optimal.

                  PS : et pour les "conservateurs", c'est très simple de passer du binaire au vieux format texte, rien n'est perdu. L'inverse n'est pas vrai. Alors oui au journald en binaire!

                  • [^] # Re: Grep

                    Posté par . Évalué à  5 .

                    Pour reprendre l'exemple de la date, il est nettement plus simple de spécifier "le int est le nombre de jours depuis le 1/1/1970" que de prendre toute la norme ISO

                    Ce problème est indépendant de texte ou binaire il me semble. On peut tout à fait définir les structures de données dans les deux cas.

                    rien n'empèche de convertir le binaire en texte qu'on passe à Grep ensuite, l'avantage est qu'on peut "convertir" dans différents format bien plus facilement.

                    Ben c'est ce point que je trouve bizarre : en quoi convertir du binaire dans divers formats est plus simple que convertir du texte dans divers formats ?

                    Il me semble que c'est kif kif, voire avec un léger avantage pour le texte, mais j'ai peut-être manqué un truc.

                    Le binaire a parfois du bon

                    C'est sûr, l'inverse est aussi vrai. Après je n'ai pas plus d'avis que ça sur un journal binaire ou texte.

                    • [^] # Re: Grep

                      Posté par (page perso) . Évalué à  7 . Dernière modification : le 06/09/12 à 15:15

                      On peut tout à fait définir les structures de données dans les deux cas.

                      On peut. Sauf qu'en pratique, trop d'octets pour une date, les gens font un peu ce qu'ils veulent (par exemple, ils traduisent).
                      Alors certes, on peut spécifier lettre par lettre le format, mais pour reprendre mon exemple, un int c'est une ligne pour définir, combien de ligne pour définir un champs date?

                      L'avantage du binaire est surtout de rendre impossible des "adaptations", qu'on réserve à l'affichage.
                      L'expérience de l'analyse (c'est mon métier ;-) ) m'a appris que plus on laisse de la marge aux développeurs, plus ils font des conneries avec (du monde lisent les specs sans le lire). Limiter les possibilités pour dire la même chose rend les erreurs plus visibles (même en binaire, pour te donner un exemple une spec qui dit qu'un int est entre 1 et max(int), tu auras un gus pour commencer de compter à 0. si tu prends tout le domaine du int et surtout le début, ce genre de "compréhension de la spec" est diminué, moins d'erreur. Imagine avec 15 octets pour définir la date, combien d'erreurs et donc de merde pour "convertir" tu vas te taper… "Wed", "wed", "mer" pour mercredi? dans tous "convertisseur", vas-tu implémenter les 1000 langues du monde alors que définir en binaire un nombre de jours depuis 1970 aurait été plus simple et le convertisseur traduit dans la langue que tu veux?)

                      Un champs date en texte est simplement une merde absolue pour un programme (voir les clients FTP qui ont un mal fou et ont du code à plus savoir qu'en faire pour trouver de bêtes date/heure d'un fichier suivant le serveur FTP en face, FTP a ce même travers et ça pose un max de problèmes)

                      • [^] # Re: Grep

                        Posté par . Évalué à  1 .

                        Il dit que le int en question peut apparaitre en ascii dans un fichier texte au lieu de le stocker en binaire.

                        • [^] # Re: Grep

                          Posté par (page perso) . Évalué à  5 . Dernière modification : le 06/09/12 à 16:07

                          Pourquoi pas. Mais c'est pas lisible plus que ça par un être humain, et ça prend de la place (en plus de sa taille variable). En plus, tu sais si c'est en octal, décimal ou hexa?
                          Ca serait, de mon point de vue, les inconvénients du binaire mélangés aux inconvénient du texte, sans aucun avantage. Bref, je ne vois pas l’intérêt. Encore une fois, le binaire, il lui suffit d'un traducteur simple, tout comme il est simple de dire que 0x41 c'est "A" : c'est de l'affichage.

                        • [^] # Re: Grep

                          Posté par . Évalué à  3 .

                          Ça prend beaucoup plus de place, et si tu veux l'afficher comme une date (lisible par un humain) ça allonge (un peu, mais il faut le faire pour chaque ligne affichée) le traitement (il faut faire ascii -> int -> date, au lieu de int -> date)

                          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                    • [^] # Re: Grep

                      Posté par (page perso) . Évalué à  1 .

                      C'est sûr, l'inverse est aussi vrai. Après je n'ai pas plus d'avis que ça sur un journal binaire ou texte.

                      L'avantage d'un fichier texte, c'est sa robustesse : si après un problème il est mal fermé, on peut tout de même en lire le début, tandis qu'un fichier binaire risque d'être corrompu et inutilisable.

                      À ce propos, journald permet-il de faire l'équivalent d'un `tail -f' ?

                      • [^] # Re: Grep

                        Posté par (page perso) . Évalué à  3 .

                        L'avantage d'un fichier texte, c'est sa robustesse : si après un problème il est mal
                        fermé, on peut tout de même en lire le début, tandis qu'un fichier binaire risque d'être
                        corrompu et inutilisable.

                        C'est aussi le cas du journal de journald, le format a été pensé pour ça

                        À ce propos, journald permet-il de faire l'équivalent d'un `tail -f' ?

                        journalctl -f

                      • [^] # Re: Grep

                        Posté par (page perso) . Évalué à  3 .

                        L'avantage d'un fichier texte, c'est sa robustesse : si après un problème il est mal fermé, on peut tout de même en lire le début, tandis qu'un fichier binaire risque d'être corrompu et inutilisable.

                        ah, c'est nouveau…
                        Binaire != mettre des champs "temporaires" au début.
                        Un fichier binaire est pareillement robuste qu'un fichier texte si il a le même principe (que des "append")
                        Ce sont des préjugés sur les fichiers binaires qui sont sans fondements.

                        • [^] # Re: Grep

                          Posté par . Évalué à  3 .

                          Un fichier binaire corrompu, si ton outil n'a pas une certaine tolérance aux fautes, tu pourras difficilement l’exploiter.
                          Pour un fichier texte le problème est le même, néanmoins un oeil humain aura plus de facilité à récupérer de l'information.

                          Ceci dit, si journald a une sortie de type "classique", il me semble que ce troll n'a pas lieu d'être

              • [^] # Re: Grep

                Posté par . Évalué à  3 .

                C'est une horreur à parser parce que c'est non-standardisé. Mais il n'y a pas de raison pour laquelle le standard (imposé par systemd) devrait être binaire (opaque) plutôt que textuel (lisible). L'IETF se débrouille très bien avec du texte.

                • [^] # Re: Grep

                  Posté par (page perso) . Évalué à  4 .

                  Le texte, même standardisé, c'est coûteux en performance à parser (surtout avec l'UTF-8).

                  « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Grep

            Posté par . Évalué à  6 . Dernière modification : le 06/09/12 à 16:02

            Merci pour ta réponse, je ne comprends toujours pas tout (un utilisateur pas vraiment admin système)…

            Pour moi il y a deux aspects dans les logs d'une application :

            • les métadonnées des logs : date, heure, PID, état de l'OS etc. etc. : dans ce cas, que ce soit journalctl ou syslog ou autres, c'est facile de l'écrire de sorte que ce soit facile à parser, et la performance de lecture ne risque pas d'être déterminante (au doigt mouillé, on s'intéresse pas mal au contenu des logs tout de même !).

            • les logs proprement dits, ce que l'application a elle-même craché : à moins de modifier l'application, journalctl ne parsera pas les informations plus facilement que les scripts existants à grands coups de regex ; je veux dire, toute la complexité d'écriture des parseurs de logs pour l'appli X demeure, à la merci des moindre changements de formats de ce qu'elle loggue par l'application.

            Donc grosso modo journalctl propose un format unique pour les métadonnées des logs de tous les services qu'il lance ? Ça n'était pas déjà le cas avant avec syslog ? (de ce que j'en vois mais je ne comprends pas tous les cas d'usage, dans mon daemon.log toutes les lignes commencent par la date, puis le nom de machine, puis le nom de l'application et son PID (on pourrait ajouter toutes les infos sorties par ps pour le même prix), selon un ordre immuable qui se parse en deux coups de cuiller à pot ; qu'y manque-t-il ? ) En fait ce que journalctl apporte, c'est une forme de standardisation de ces infos qui n'existe actuellement pas ?

            Mis à part le gain de performance par un format binaire des logs, en fait je ne comprends toujours pas le problème que ça résout :).

            • [^] # Re: Grep

              Posté par . Évalué à  3 .

              non, l'une des raison de Journalctl c'est que les meta données sont crées par journald et non par le service (cas syslog). En cas de corruption d'un service, tes logs peuvent être corrompus.

              par exemple si veux les logs d'un boot précédant je fais :
              # journalctl _BOOT_ID=5cfd5397b3904a4eacfbf599bd20fa17

              toutes les lignes de log ont le même format pour les méta-informations, ce qui permet de faire ça simplement. Aujourd'hui c'est compliqué ce genre de requête. à mon avis ajouter toutes ces méta-informations au format texte n'aurait aucun avantage.

              Le format binaire n'empêche d'utiliser des outils textes, mais je peux choisir le format texte que je veux avant de le traiter et je peux cibler très rapidement. (c'est étrange que personne n'ait cité cet avantage dans les précédentes discutions).

              • [^] # Re: Grep

                Posté par . Évalué à  2 .

                Ok merci je comprends mieux.

              • [^] # Re: Grep

                Posté par . Évalué à  2 .

                C’est pas syslog qui rajoute les méta-données ?

                Il me semblait que l’application faisait un truc genre (c’est sortit de mon esprit, c’est pas censé être juste) : log(<facility>.<level>, <message>). C’est pas le cas ?

          • [^] # Re: Grep

            Posté par . Évalué à  3 .

            La question c'est est-ce que les logs sont exploitables en cas de gros crash de la machine ?
            est-ce que petites modifications du binaire rendent de grosses parties du log inexploitable ?
            est-ce que si le système redémarre dans un niveau d'init bas (partoche en ro, services non lancés, lib inaccessible, pas de machines de secours), on peut toujours utilisé journalctl ?

            Et est ce que çela corrige les manques de(s) syslog(s) ? (signature, authentification des machines envoyant des logs, et surement d'autres)

            Ceci dit avoir des logs aisément filtrable est une bonne idée, tant que je peux avoir en même temps une sortie texte "classique", et ce même si je regrette qu'il n'utilise pas un db texte.

        • [^] # Re: Grep

          Posté par (page perso) . Évalué à  5 .

          Lennart explique ses choix et les "révolutions" apportées par journald : https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Grep

        Posté par . Évalué à  7 .

        journald enregistre les logs dans des fichiers binaires

        En voilà une bonne nouvelle : on a désormais les inconvénients de Windows et les inconvénients de Linux en un seul système.
        Plus besoin de dual-boot, on peut s'auto-pourrir la vie juste avec Linux.

        • [^] # Re: Grep

          Posté par (page perso) . Évalué à  -2 .

          C'est Lennart : il créé des problèmatiques puis trouvent des solutions à ces problématiques ; solutions qui créent de nouvelles problématiques inutiles. Ça permet aux "fans" de sortir la phrase qui tue : "ben si t'es pas content de systemd/journald/…, arrête de geindre et amène TA solution". Et essayer d'expliquer que le problème solutionner par Lennart est un problème créé par lui pour être solutionné c'est impossible.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: Grep

            Posté par (page perso) . Évalué à  6 .

            En même temps, systemd peut forwarder les logs à syslog ou à ce que tu veux d'autre, donc de ce côté-là, tu peux garder exactement la même configuration qu'avant.

            • [^] # Re: Grep

              Posté par . Évalué à  7 .

              tu peux garder exactement la même configuration qu'avant.

              Quelle est la plus value du changement ?
              Les fans disent c’est vachement mieux !
              Les réfractaires disent ça marchait bien, c’était lisible pourquoi changer ?
              On leur répond tu peux tout changer, mais on peux formater pour que tu es l’impression que rien a changé.

              Je ne comprends pas bien.

              • [^] # Re: Grep

                Posté par (page perso) . Évalué à  7 .

                syslog, c'est un standard et journald ne peut pas arrivé et dire je ne sais pas causer avec syslog… Même le gestionnaire d’évènement de Microsoft sait le faire!

                • [^] # Re: Grep

                  Posté par . Évalué à  -1 .

                  syslog, c'est un standard

                  Init sys V est un standand.

                  journald ne peut pas arrivé et dire je ne sais pas causer avec syslog…

                  systemd peut arrivé et dire, jetez tout.

                  La cohérence, je ne vois pas.

                  • [^] # Re: Grep

                    Posté par (page perso) . Évalué à  3 .

                    systemd peut arrivé et dire, jetez tout.

                    Non, syslog c'est un standard utilisé partout dans l'industrie… (switch, …).

                    Ton sysvinit, vu qu'il discute avec rien, on s'en fout un peu.

                    Et si sysvinit était vraiment un standard, alors j'aurai pas besoin de faire des trucs comme ça:

                    #tina.pp
                    
                    # Script d'init compatible avec Debian Squeeze
                    class tina
                    {
                            file
                            {
                                    "/etc/init.d/tina.tina":
                                            owner => root,
                                            group => root,
                                            mode => 700,
                                            source => "puppet://servietsky.*****.fr/files/servers/tina/tina.tina"
                            }
                    
                    }
                    
                    
                    • [^] # Re: Grep

                      Posté par . Évalué à  2 .

                      Si tina = TimeNavigator, alors le problème vient de lui (ce logiciel est une merde) pas de SysV.

                      • [^] # Re: Grep

                        Posté par (page perso) . Évalué à  2 .

                        Non sans blague :) J'ai pas eux le choix du logiciel…

                  • [^] # Re: Grep

                    Posté par . Évalué à  1 .

                    systemd peut arrivé et dire, jetez tout.

                    La cohérence, je ne vois pas.

                    systemd est parfaitement compatible avec ton Init sys V.
                    C'est juste que tu ne pourras pas exploiter toutes les fonctionnalités supplémentaires qu'apporte systemd (dont tu n'as peut-être pas besoin).

                    Donc en quoi c'est pas cohérent ?

        • [^] # Re: Grep

          Posté par (page perso) . Évalué à  4 .

          on a désormais les inconvénients de Windows

          Et pourquoi c'est un inconvénient ? Et me dit pas qu'on peut pas parser facilement les logs, y'a les commandes qui vont bien sous Windows pour le faire, bon ca crache que du xml par contre…

          • [^] # Re: Grep

            Posté par . Évalué à  4 .

            Où est décrit le format binaire en question ?
            À part l'API d'accès, il n'y a rien. Donc si qqn veut faire un outil qui lit le fichier en question, sans passer par l'API, il ne peut pas.

            On en revient toujours à la même chose : interopérabilité, normalisation, etc.

            • [^] # Re: Grep

              Posté par (page perso) . Évalué à  7 .

              La réponse est "pour l'instant, on est encore en train de bosser sur le format de stockage, donc on va pas le documenter tant qu'on est pas sur qu'il est viable car on veut pas que des gens commencent à l'utiliser tant que c'est pas fini".

              Ça ne me parait pas déconnant de d'abord avoir du feedback avant de décider "c'est bon, ça bouge plus". On le fait sans arrêt avec les APIs, donc ça me parait une approche des plus viables, si ça s’éternise pas.

              Sinon, tant pis, ça va se terminer comme le format sur disque de sqlite, mysql ou postgresql, à savoir, personne ne va avoir rien à faire de le documenter. ( ou le format sur disque de svn, de la base rpm, d'openldap si les gens veulent des exemples autre que des SGDB ou assimilés ).

              Ceci dit, il y a une documentation sur le format d'export :
              http://www.freedesktop.org/wiki/Software/systemd/export

        • [^] # Re: Grep

          Posté par . Évalué à  0 .

          c'est exclusif à Windows le format binaire ?? syslog zip les fichiers log, c'est aussi un format binaire.

          • [^] # Re: Grep

            Posté par . Évalué à  2 .

            On peut aller plus loin en disant qu'un fichier texte est aussi un fichier binaire, puisque ça reste une suite de 0 et de 1.

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Grep

          Posté par . Évalué à  4 .

          D'un autre coté, un fichier texte, c'est jamais qu'un fichier avec du texte encodé en binaire dedans.

          Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

    • [^] # Re: Grep

      Posté par . Évalué à  3 .

      Et puis ça c'est standard sur quasiment tous les OS unix-like.

      Mouais, entre le grep POSIX et le grep GNU, y'a déjà un paquet de différences, alors dire que c'est standard…

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Grep

      Posté par (page perso) . Évalué à  7 .

      Dans ce cas, tu peux utiliser grep comme avant puisque tu connecte journald à syslog mais personnellement ce genre d'outil me simplifie la tâche parce que quand je cherche dans les logs, je dois d'abord passer du temps à les lire pour savoir comment identifier les lignes liées à l'application que je cherche ce qui est loin d'être pratique si l'application ne produit pas beaucoup de message.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

      • [^] # Re: Grep

        Posté par . Évalué à  1 .

        Moi, quand j’avais besoin de lire les logs, j’avais des filtres de coloration syntaxique. Ça permet de lire facilement les log dans ton éditeur de texte.

        • [^] # Re: Grep

          Posté par . Évalué à  4 .

          D'un autre côté, un truc comme journalctl |vim - répondra sans doute à ton besoin ?

    • [^] # O (log (n))

      Posté par . Évalué à  7 .

      Journal récupère les infos en O(log(n)), alors que grep nécessite de tout parser… O(n).

      Va t’amuser à parser des gigas de logs avec grep… Et je ne parle même pas de les convertir dans un format utilisable ou d’utiliser des regex évoluées…

      • [^] # Re: O (log (n))

        Posté par (page perso) . Évalué à  7 .

        Y a des outils proprios pour ça, genre splunk. D'ailleurs, comme c'est un problème que personne n'a, la boite est pas du tout en train de faire des bénefs et d'avoir plus d'employés que Canonical ( pour donner un point de comparaison ). Comme c'est aussi un souci qui n'existe pas, la boite est profitable sans doute grâce au trafic de drogue.

  • # Autres fonction sympa

    Posté par (page perso) . Évalué à  6 .

    Pour la prochaine version du journal, il sera possible d’empêcher l'altération des logs, en gros, un attaquant pourra supprimer tous les logs (et donc être grillé) mais pas les modifier.

    Titre de l'image

    • [^] # Re: Autres fonction sympa

      Posté par . Évalué à  0 .

      Quelle différence de principe avec grosso modo 'gpg --generate-key new_pubkey; gpg --encrypt new_privkey with_my_master_sealing_key ; gpg --encrypt-files /var/log/* --with-key new_pubkey' dans un crontab avec périodicité toutes les 15 minutes ?

      • [^] # Re: Autres fonction sympa

        Posté par . Évalué à  3 .

        Le coté temps réel ?

        • [^] # Re: Autres fonction sympa

          Posté par . Évalué à  2 .

          tu veux dire qu'il chiffre dès qu'il y a une ligne écrite dans le log ? C'est monstrueux si les applications sont un peu verbeuses, mais pourquoi pas. Alors avec un service qui ne lance que tailf et les commandes de chiffrement afférentes, plus le changement de clef régulièrement dans le crontab ?

          • [^] # Re: Autres fonction sympa

            Posté par (page perso) . Évalué à  2 .

            https://plus.google.com/104232583922197692623/posts/L1vzCnKCHMD

            J'ai pas compris qu'il chiffrait les logs sur le disque, surtout que dans ton exemple, tu chiffre la modif de l'attaquant mais je vois pas ce que ca va avancer.

            Dans l'idée, c'est de garantir l'intégrité du journal.

            • [^] # Re: Autres fonction sympa

              Posté par . Évalué à  1 . Dernière modification : le 06/09/12 à 16:46

              Dans mes exemples les opérations de chiffrement ne sont sans doutes pas les bonnes, mais s'il valide le log en temps réel, il fait forcément une opération à clef publique par modification.

              M'enfin ton lien montre bien qu'il les scelle à intervalle de temps régulier, pas en temps réel, et qu'il change la clef de scellement régulièrement aussi, avec une autre périodicité.

              Pour moi ça se fait avec les outils existants :
              à intervalle régulier :
              * bouger le fichier de log courant dans le répertoire des logs scellés (de la même façon que le gzip régulier) (genre logrotate quoi)
              * sceller le nouveau fichier (de toutes façons par un chiffrement à clef publique, il ne faut pas que l'adversaire trouve la clef de descellement qui permettrait de les modifier)

              à un autre intervalle : changer la clef de scellement, avec une chaîne de confiance jusqu'à la clef de descellement.

              Bref un crontab, trois commandes, et zou. Bon d'accord ça ne fournit pas un QR code, mais ça se rajoute facilement…

              • [^] # Re: Autres fonction sympa

                Posté par (page perso) . Évalué à  0 .

                Tu viens d'inventer un truc terreux, pas pro, pas pratique et franchement pas clean. Bravo, tu as ton certificat d'ingénieur certifié Epita. #trollinside

                Sinon, le concept de la cryptobidule sur les logs, c'est un bon truc; On a pareil pour les logs DCI. Chaque ligne de log à un hash du précédent log. Et en toute fin, un ensemble de certif/hash/fingerprint, qui permet de certifier les logs. Certes, sur un système lambda, ca doit bouffer un peu plus de CPU, mais sur un système avec chipset crypto, ca doit avoir un impact plus réduit (et ca assure plus de sécurité : très utile sur les servs de productions)

                • [^] # Re: Autres fonction sympa

                  Posté par . Évalué à  1 . Dernière modification : le 06/09/12 à 21:05

                  Bien sûr, il faut vérifier le mode cryptographique utilisé pour le scellement des logs, mais ma remarque portait avant tout sur le fait que ça pouvait se faire simplement avec les outils existant (au pire, avec un tout petit programme pour le mode crypto, mais qui repose le plus possible sur des briques existantes genre gpg & openssl).

                  Pas besoin d'un truc qui soit intégré à systemd, ça pourrait très bien en être séparé si l'accès aux logs était facile. Pas très orthogonal ni modulaire tout ça ! Et encore moins réutilisable par d'autres malheureusement.

                  (sinon je n'ai pas fait l'Epita, désolé :-p)

          • [^] # Re: Autres fonction sympa

            Posté par . Évalué à  2 .

            je pensais plus à un système de chiffrement par flux

            ceci dit je suis hs vu qu'il parlait plus de signature que de chiffrement

  • # Autre approche

    Posté par . Évalué à  4 .

    journald

    Journald me gêne car je ne souhaite pas avoir des logs en format binaire, je préfère parser avec des grep, cut, et autre outils texte, cela reste infiniment plus puissant que devoir passer par journalctl, d'autant plus qu'il s'agit ici d'une dépendance supplémentaire et systemd est une dépendance obligatoire de journald. En voici la raison :

    Logging is a core part of service management. The journal is tightly integrated with the rest of systemd to ensure that everything in the system can be monitored, introspected and debugged. The generated journal entries are queried from various components in systemd. In effect systemd and journald are so tightly coupled that separating them would make little sense. That said, it’s Free Software, so you can do with the code whatever suits you. Finally, you are actually wrong in believing that systemd was an abomination.

    (source, 1ère question de la FAQ) Les devs de LFS vont avoir du boulot…

    Le fait d'avoir un format universel est plutôt intéressant, mais dans ce cas, juste avec du texte. Il y a aussi le problème de la sécurité mais je n'en connait pas les détails.

    On peut tout de même ce poser des questions sur journald, que Lennart décrit comme :

    Simplicity: little code with few dependencies and minimal waste through abstraction.

    Par exemple il dit ici que l’outil doit être simple avec peu de dépendances, or systemd n'a rien d'une petite dépendance, de plus systemd est Linux only donc journald aussi. Ce qui veut dire que les applications devront avoir 2 solutions de log pour être un minimum portable. C'est bien évidement une très mauvaise approche.

    Autre approche

    On peut aussi prendre le problème des logs d'informations avec une autre approche :

    En C, il y a 3 flux ouvert par défaut : stdin, stdout et stderr, le dernier est utilisé pour les erreurs. On pourrait ainsi créer un 4ème flux, stdlog ou stddbg par exemple pour prendre en charge les logs, puisque c'est essentiel pour une application de pouvoir communiquer son état et sa situation.

    Il y aurait ainsi une entré /dev/stdlog et a chaque ligne ajoutée, le système s'occupe de rajouter les informations de temps, le PID, le nom de la machine …
    On pourrait alors imaginer une utilisation tels que celle-la :

    fprintf(stdlog, LOGP_WARN "Entering passive mode");
    fprintf(stdlog, LOGP_WARN "Parsing %s...", argv[1]);
    
    

    Que l'on pourrait manipuler ensuite de cette manière grâce aux redirections de flux :

    $ firefox 3>> firefox.log
    $ firefox 3>> firefox.log 2>&3   # Redirige aussi les erreurs vers les logs
    
    

    Ou encore …

    Puisqu'une raison d'être de journald est la non standardisation des logs, pourquoi ne pas proposer à la communauté une ébauche de standard ? Cela a en plus été déjà fait pour les logs server !

    • [^] # Re: Autre approche

      Posté par (page perso) . Évalué à  4 .

      J'ai installé systemd pour voir, je n'étais pas au courant pour journald, et figure-toi que je ne m'en suis même pas rendu compte!

      J'ai bien accès aux logs à travers systemd-journalctl (suis sous Debian), et les logs sont toujours présents normalement dans leurs fichiers texte respectifs.

      Il me semble qu'il a été dit ici qu'on pouvait très facilement convertir les logs binaires en texte, je crois que c'est ce qui a été fait.
      Donc dans l'immédiat, je ne vois pas en quoi ça serait un problème pour la compatibilité entre systèmes: il suffit que les outils "communs" continuent à se baser sur les logs texte.

      Quant à l'idée d'avoir un standard commun pour tout le monde dans les logs, pourquoi pas. Mais alors pourquoi en format texte plutôt qu'en format binaire?
      Et du coup: pourquoi ne pas utiliser directement le format proposé par journald?

      • [^] # Re: Autre approche

        Posté par . Évalué à  1 . Dernière modification : le 06/09/12 à 20:39

        Quant à l'idée d'avoir un standard commun pour tout le monde dans les logs, pourquoi pas. Mais alors pourquoi en format texte plutôt qu'en format binaire?

        Car l'interface la plus universelle est le texte. Sinon c'est un surplus non nécessaire, surtout pour les logs qui sont avant-tout lus par des humains, et non des programme.

        Il me semble qu'il a été dit ici qu'on pouvait très facilement convertir les logs binaires en texte, je crois que c'est ce qui a été fait.

        Le 'facilement' est un peu osé, je ne voit aucune raison valable pour utiliser le format binaire :

        • La taille des logs ? On a déjà des utilitaires tout-à-fait appropriés pour compresser des fichiers (gzip par exemple).
        • Les données binaires ne peuvent pas être loggées dans le format texte ? Parfaitement normal, ce n'est pas leur place.
        • Le format texte est plus facile à manipuler pour un pirate ? La véritable solution serait comme dit plus haut, un système de hash sur chaque ligne de manière à garantir l'intégrité du fichier.

        Donc dans l'immédiat, je ne vois pas en quoi ça serait un problème pour la compatibilité entre systèmes

        Si quelqu'un te fournit des logs au format journald tu fait quoi si t'es sur un BSD ou autre ? Tu ne peut pas installer le parseur journalctl car il est dans journald qui est lui-même plus ou moins inclut dans systemd que tu ne pourra pas installer. Je n'installerai pas un gestionnaire de services et de périphériques pour lire mes logs.

        Bon j’exagère un peu car rien n'empêche quelqu'un de fournir un autre outils pour parser le format journald et sortir du texte, mais le truc c'est que ce format peut être modifié à tout moment, il n'est pas documenté (il le sera probablement à long-terme) et il est linux-only pour le moment.

        • [^] # Re: Autre approche

          Posté par (page perso) . Évalué à  1 .

          Car l'interface la plus universelle est le texte.

          Tu as bien de la chance de comprendre les centaines de langues dans le monde. Pour info, les logs ne sont pas toujours en anglais (et pourquoi l’anglais devrait avoir la primauté d'ailleurs?)

          Sinon c'est un surplus non nécessaire, surtout pour les logs qui sont avant-tout lus par des humains, et non des programme.

          Et d'après toi, le texte est codé comment? Je vais t'aider : un programme transforme le texte qui n'est qu'un code binaire en une suite de pixels que tu peux lire.
          Si il doit faire une petite phase de traduction en plus, ça ne va pas le tuer ton programme d'affichage.

          • [^] # Re: Autre approche

            Posté par . Évalué à  2 .

            Si il doit faire une petite phase de traduction en plus, ça ne va pas le tuer ton programme d'affichage.

            Et si j'ai pas d'outils pour faire la traduction ? C'est totalement absurde de choisir le format binaire pour des logs, sa doit être lut par des humains ! Mais pourquoi faire compliqué alors que l'on peut faire simple, puissant et portable ?

            Et la langue ce n'est pas le problème, un grep marchera quand même, par contre un grep sur le format binaire c'est possible mais tout de suite moins efficace.

            • [^] # Re: Autre approche

              Posté par (page perso) . Évalué à  0 .

              Et si j'ai pas d'outils pour faire la traduction ?

              Et si tu n'as pas d'outils pour afficher 0x41 en "A" sur ton écran?

              C'est totalement absurde de choisir le format binaire pour des logs, sa doit être lut par des humains !

              0x41 n'est pas lisible par des humains, tu as déjà des outils de traduction. un de plsu ou de moins…
              Non, ce n'est pas absurde, à moins que tu trouves sympa de lire des 0 et des 1 (et encore, c'est déjà une traduction d'un été électrique)

              Ce qui est absurde est plutôt de vouloir se cantonner à une format "binaire" unique pour tout même ce qui n'est pas adapté. Bientôt des flux vidéos et audio en XML?

              Et la langue ce n'est pas le problème, un grep marchera quand même, par contre un grep sur le format binaire c'est possible mais tout de suite moins efficace.

              Ah oui? Ta vie doit être chiante si tu t'amuse à implémenter un parsing grep avec les centaines de langues pour dire "mercredi"… Non, les gens ne sont pas avec une seule langue sur terre, y compris sur des serveurs. Je te défie de me faire une ligne de grep qui parsera tous les logs de la terre pour la même erreur (rien qu'avec une date, mais si je te parle de faire un grep sur un message d'erreur précis, bon courage pour trouver toutes les traductions sur toutes les machines).

              Ton grep, il marche pour toi, mais n'est pas maintenable à plusieurs.

              • [^] # Re: Autre approche

                Posté par . Évalué à  4 .

                0x41 n'est pas lisible par des humains, tu as déjà des outils de traduction. un de plsu ou de moins…

                Ca devient ridicule comme argument

                Qu'est ce qu'on se fout de ce troll
                je croyais que journald pouvait sortir du texte et du binaire, l'admin fera comme il veut et le gars qui fait du forensic priera pour qu'il ait activé l'option texte

                • [^] # Re: Autre approche

                  Posté par (page perso) . Évalué à  1 . Dernière modification : le 07/09/12 à 18:04

                  Ca devient ridicule comme argument

                  Le binaire pas lisible par l'être humain n'en est pas moins ridicule. Il s'agit d'une simple conversion, ça ne tue personne. parait même que c'est déjà disponible, donc du coup tu peux greper dessus.

                  Bref, ce qui est ridicule est d'arriver à de tels "arguments" contre journald. C'est que finalement il ne doit pas y avoir trop de raisons d'être contre…

                  • [^] # Re: Autre approche

                    Posté par . Évalué à  5 .

                    Le binaire pas lisible par l'être humain n'en est pas moins ridicule. Il s'agit d'une simple conversion, ça ne tue personne.

                    j'y cois tout de même un point important (que j'avais déjà cité je crois)
                    il faut pouvoir effectuer cette conversion, en cas de corruption, avec du binaire, il faut espérer que la corruption ne soit pas sur des éléments de structures. Avec du texte tu pourras au moins lire à l'oeil nu une bonne partie des infos

                    Par contre je t'accorde que de faire un grep fichierDeLog pattern, ou un journalctl optionDeFiltrgage | grep pattern, ça ne change pas grand chose

                    et franchement, vu que journald peut avoir les mêmes sorties que syslog, je ne vois vraiment pas le problème

                    • [^] # Re: Autre approche

                      Posté par (page perso) . Évalué à  -2 .

                      Je vais expliquer pourquoi syslogd à l'époque le choix c'est fait sur le format texte et sur pas le format binaire :
                      C'est juste pour éviter un bon /dev/random sur ton fichier sur ton journal.

                      Dans ce cas, tu n'as plus aucune chance de savoir facilement si c'est journald qui a planté ton journal ou si tu viens de te faire hacker. C'est d'ailleurs un des problèmes des journaux d'events windows.

                      Les gens à l'époque sur des systèmes aussi low perf, on bien réfléchit à utiliser le format binaire, ils étaient pas c… quand même !

                      • [^] # Re: Autre approche

                        Posté par (page perso) . Évalué à  3 .

                        Je ne suis pas expert sécurité, mais un bon coup de script sur un journal au format texte ne pourrait pas rendre l'intrusion encore plus discrète en enlevant uniquement les entrées suspectes?

                        "A l'époque", peut-être qu'appliquer ce genre de script aurait pris trop de temps face à un bon /dev/random quasi instantanée, mais aujourd'hui, je pense que même sur de gros fichiers de journaux, ça prendrait quelques secondes au plus.

                      • [^] # Re: Autre approche

                        Posté par (page perso) . Évalué à  3 .

                        Garde tes explications pour toi parce que Le format texte est plus sensible à modification…

                        Et l'argument "tu n'as plus aucune chance de savoir facilement si c'est journald qui a planté ton journal ou si tu viens de te faire hacker" je te répondrais:

                        "tu n'as plus aucune chance de savoir facilement si c'est gzip/logrotate qui a planté ton journal ou si tu viens de te faire hacker", ca tiens aussi peu la route que le tiens.

              • [^] # Re: Autre approche

                Posté par . Évalué à  3 .

                Non, ce n'est pas absurde, à moins que tu trouves sympa de lire des 0 et des 1 (et encore, c'est déjà une traduction d'un été électrique)

                Oui quand même, mais avant de lire les commentaires déjà postés je me permettrait cette réponse. Y'a des limites hein ! Chacun les situe où ça lui plaît mais elles existent ! Entre lire (en tant qu'humain) du binaire, de l'hexadécimal, de l'ASCII, de l'Unicode, il y a une différence sensible.

            • [^] # Re: Autre approche

              Posté par (page perso) . Évalué à  1 .

              Mais pourquoi faire compliqué alors que l'on peut faire simple, puissant et portable ?

              Les logs textes ne sont ni simples (amuses toi à automatiser le bordel…), ni puissant (les grep sur du texte, c'est d'une lenteur, sponsorisé par Intel?), ni portable (format non précis, traductions).

              On est donc bien d'accord : il faut virer ces formats pas simples pas puissant pas portable, donc virer les logs "texte" tels qu'ils sont fait maintenant.

              Après, je sais, c'est dur de perdre son boulot, quand l'outil qui remplace permet de diviser par deux le nombre d'admins qui n'ont plus besoin de faire des scripts à la con… Si RedHat fait ça, tu crois que c'est pour le plaisir, ou ça va devenir un argument de vente sur le nombre d'admin par machine?

              • [^] # Re: Autre approche

                Posté par . Évalué à  2 .

                En même temps, "journal", quelque soit le format de sortie, loggue toujours une chaîne de caractères produite par l'application qui demande une journalisation, non, et ce avec qqs métadonnées autour (c'est une vraie question) ? Du coup les problèmes autour du texte dont tu parles ne sont pas résolus, même si qqn code un journal_grep, non ?

        • [^] # Re: Autre approche

          Posté par . Évalué à  9 .

          Car l'interface la plus universelle est le texte

          D'ailleurs il n'y a qu'un seul encodage. Oh wait…

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Autre approche

            Posté par (page perso) . Évalué à  6 .

            Non mais par contre, tu as qu'un seul format de sérialisation.
            Enfin un seul par lettre de l'alphabet.
            Enfin pour ceux qui ont un nom bien sur.

          • [^] # Re: Autre approche

            Posté par . Évalué à  3 .

            UTF-8 devient peu à peu le standard universel, oui (tu peux toujours coder en EBCDIC ou en CP1252 ou en UTF-16BE si ça t'amuse).

            • [^] # Re: Autre approche

              Posté par . Évalué à  3 .

              UTF-8 devient peu à peu le standard universel

              En Occident. Ya des endroits où c'est moins coûteux d'utiliser UTF-16, genre tous les gens à l'Est, là.

            • [^] # Re: Autre approche

              Posté par (page perso) . Évalué à  2 .

              Sans avoir spécialement de chiffres, je présume qu'UTF-16 est fortement utilisé aussi.

              (source http://fr.wikipedia.org/wiki/UTF-16 )

              « L'UTF-16 est en particulier utilisé dans les environnements windows. Dans ce système, les API dites unicode utilisent ce standard. Il en va de même du système NTFS.

              UTF-16 est le standard de chaînes de caractères utilisé par l'UEFI. »

              (source http://en.wikipedia.org/wiki/UTF-16 )

              « The Python language environment officially only uses UCS-2 internally since version 2.0, but the UTF-8 decoder to "Unicode" produces correct UTF-16. »

              « Java originally used UCS-2, and added UTF-16 supplementary character support in J2SE 5.0. »

              etc.

Suivre le flux des commentaires

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