Mais qu'est-ce qu'il vous a fait Lennart ?! Mis à part bouger vos habitudes et certitudes ?
Quoi que pour les certitudes, c'est pas gagné pour tous ...
Bon, si je n'ai pas au moins un commentaire avec un début comme celui là ;-)
Perso, je suis plutôt fan. Mais je prend que ce qui m’intéresse. Je suis aussi, principalement avec Fedora (pas que).
- Pulse audio ne m'a pas trop posé de problème. Si ce n'est qu'il faut que j'active ou pas le son, car il ne l'est pas systématiquement. Et j'ai eu quelque problème avec une WebCam dont le micro passait avant mes sorties audio, mais c'est maintenant réglé.
- NetworkManager, je le désactive systématiquement sur mes PC fixes et sur mes portables je lui laisse uniquement le contrôle du WiFi. J'ai pris cette habitude car à une époque NetworkManager et livirtd ça n'allait pas bien ensemble. IL semblerait que ça aille mieux.
- Avahi. Je m'en fou. Je le désactive systématiquement.
- Systemd. Ça, ça me parait une bonne chose. J'ai lu avec passion son blog sur le sujet. C'est passionnant. Que l'on soit d'accord ou pas, ça ne peut être que passionnant. Sinon, c'est vraiment dommage.
- Journal ?
Concernant Journal, j'ai d'abord lu linuxfr, puis l'indtroduction à Journal de Lennart.
J'ai noté quelques problèmatiques soulevées ici, qui me paraissaient importantes, et j'ai trouvé les réponses dans l'introduction de Lennart.
**Sécurité **
The Internet is a dangerous place. Break-ins on high-profile web sites have become very common. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
Sécurité bis
So you are splitting up journal entries based on the user ID of the user sending them. But how do you make sure that the user doesn’t lie about who he is?
Thankfully, the Linux kernel supports SCM_CREDENTIALS, which provides us with information about the sender of a message he cannot fake.
Réseau
In the initial version journald’s network support will be very simple: to share journal files across the network, simply copy them to a central host with a tool like scp, rsync or via NFS. The journal browser client tool will then transparently merge these files, interleaving them as necessary. In a later version we plan to extend the journal minimally to support live remote logging, in both PUSH and PULL modes always using a local journal as buffer for a store-and-forward logic. Regardless which mode of transportation is used, the underlying journal format is designed to be scalable to large numbers of hosts and all entries are identified by both the machine ID and the host name. The goal is to implement an efficient journal monitoring tool that can browse journals from a multitude of hosts transparently and live, while leaving to the administrator the choice of transport so that he can adjust it to his own needs, i.e. whether live functionality is more important than avoiding the thundering herd, and other considerations.
Réinventer la roue
Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!
Well, sometimes improving an existing solution is the way to go, but when the changes necessary are too major a reinvention is a good thing, if it is done for the right reasons, and provides good compatibility with previous solutions. We believe we are doing it for the right reasons, and we try hard to provide greatest possible compatibility.
And no, just fixing the log formatting won’t get you much. Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.
Format binnaire
Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)
# Certitudes et habitudes
Posté par Phylyppe . En réponse au journal Lennart casse les logs!. Évalué à -4.
Mais qu'est-ce qu'il vous a fait Lennart ?! Mis à part bouger vos habitudes et certitudes ?
Quoi que pour les certitudes, c'est pas gagné pour tous ...
Bon, si je n'ai pas au moins un commentaire avec un début comme celui là ;-)
Perso, je suis plutôt fan. Mais je prend que ce qui m’intéresse. Je suis aussi, principalement avec Fedora (pas que).
- Pulse audio ne m'a pas trop posé de problème. Si ce n'est qu'il faut que j'active ou pas le son, car il ne l'est pas systématiquement. Et j'ai eu quelque problème avec une WebCam dont le micro passait avant mes sorties audio, mais c'est maintenant réglé.
- NetworkManager, je le désactive systématiquement sur mes PC fixes et sur mes portables je lui laisse uniquement le contrôle du WiFi. J'ai pris cette habitude car à une époque NetworkManager et livirtd ça n'allait pas bien ensemble. IL semblerait que ça aille mieux.
- Avahi. Je m'en fou. Je le désactive systématiquement.
- Systemd. Ça, ça me parait une bonne chose. J'ai lu avec passion son blog sur le sujet. C'est passionnant. Que l'on soit d'accord ou pas, ça ne peut être que passionnant. Sinon, c'est vraiment dommage.
- Journal ?
Concernant Journal, j'ai d'abord lu linuxfr, puis l'indtroduction à Journal de Lennart.
J'ai noté quelques problèmatiques soulevées ici, qui me paraissaient importantes, et j'ai trouvé les réponses dans l'introduction de Lennart.
**Sécurité **
The Internet is a dangerous place. Break-ins on high-profile web sites have become very common. After a successful break-in the attacker usually attempts to hide his traces by editing the log files. Such manipulations are hard to detect with classic syslog: since the files are plain text files no cryptographic authentication is done, and changes are not tracked. Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected.
Sécurité bis
So you are splitting up journal entries based on the user ID of the user sending them. But how do you make sure that the user doesn’t lie about who he is?
Thankfully, the Linux kernel supports SCM_CREDENTIALS, which provides us with information about the sender of a message he cannot fake.
Réseau
In the initial version journald’s network support will be very simple: to share journal files across the network, simply copy them to a central host with a tool like scp, rsync or via NFS. The journal browser client tool will then transparently merge these files, interleaving them as necessary. In a later version we plan to extend the journal minimally to support live remote logging, in both PUSH and PULL modes always using a local journal as buffer for a store-and-forward logic. Regardless which mode of transportation is used, the underlying journal format is designed to be scalable to large numbers of hosts and all entries are identified by both the machine ID and the host name. The goal is to implement an efficient journal monitoring tool that can browse journals from a multitude of hosts transparently and live, while leaving to the administrator the choice of transport so that he can adjust it to his own needs, i.e. whether live functionality is more important than avoiding the thundering herd, and other considerations.
Réinventer la roue
Why do you guys reinvent the wheel, again? Why not just add what you need to existing syslog? If you just clean up your log formatting, syslog should be fine!
Well, sometimes improving an existing solution is the way to go, but when the changes necessary are too major a reinvention is a good thing, if it is done for the right reasons, and provides good compatibility with previous solutions. We believe we are doing it for the right reasons, and we try hard to provide greatest possible compatibility.
And no, just fixing the log formatting won’t get you much. Not even the most basic requirements like binary blobs or sensible structured logging. Let alone stuff like indexing or proper access control.
Format binnaire
Will the journal file format be standardized? Where can I find an explanation of the on-disk data structures?
At this point we have no intention to standardize the format and we take the liberty to alter it as we see fit. We might document the on-disk format eventually, but at this point we don’t want any other software to read, write or manipulate our journal files directly. The access is granted by a shared library and a command line tool. (But then again, it’s Free Software, so you can always read the source code!)