Notamment sur la sécurité (c'est juste du texte, on ne peut pas faire confiance aux pid),
Normalement c'est l'admin qui gère la machine qui va regarder les logs.
Tu veux mettre de la sécurité en plus, mais pour quoi faire? Etre sur que le pid qui émet ce message ets bien celui qui devrait l'émettre ?
Ca veux dire que tu as déjà un gros problème : un programme qui fonctionne qui se fait passer pour un autre!
Et ça, c'est pas un serveur de log plus sécurisé, c'est une machine mieux administrer qu'il faut.
La "sécurité" qu'un système de log a besoin, c'est la non réupudiation et la non modification.
Pas l'authentification forte de chaque appli.
c'est le bordel à parser parce que il n'y a pas de vrai format standard
En même temps c'est pas toujours la même appli qui émet les logs, et elle n'a pas forcément les mêmes besoins que celle juste à coté.
Tu vas parser suivant ce qu'émets tes applis.
Si je fous des paquets IPs dans la log, je vais pas m'attendre à avoir les mêmes champs que si je regarde des demandes d'authentification.
que les timezones ne sont pas forcément indiquées,
A nouveau, Tu es censé connaitre les machines que tu loggues (et j'espère avoir un parc un tant soit peu cohérent).
Et suivant les soft de serveurs de logs que tu utilises, tu peux les avoir.
qu'on a 45 fichiers de logs,
Mauvais admin, changer d'admin.
Ca c'est un pur probleme d'administration, pas d'outils.
Tu créé les fichier comme tu le souhaite (perso chez moi c'est ////(.|)
Enfin voilà, à priori, avoir des logs sous une forme un peu plus structuré faciliterait grandement la tâche des admins en permettant de simplifier l'écriture d'outils de monitoring
Comme dis au dessus : "mauvais admin, changer d'admin".
Avec les serveurs de logs actuel (syslogng, rsyslog, ...) tu peux strutcturer tes logs, avoir des fonctions avancées, voir rajouter des informations par rapport au "syslog habituel" quand tu peux gérer ce qui tourne sur le client (par ce que mettre rsyslog sur un firewall matériel, amha, c'est plus dur ^^).
Sans compter que l'on parle de strucutre, mais certains serveurs de logs permettent d'utiliser des bases de données (mysql, ...) et donc relativement simple à "structurer" (en dynamique par une requêtes, ou simplement par des vues).
Je pense que le fait de casser la compatibilité est parfois nécessaire pour faire avancer les choses.
Parfois oui. Dans ce cas, les solutions existent déjà, sont fonctionnelles, et ne cassent pas la compatibilité avec les autres.
Donc absolument pas nécessaire.
[^] # Re: ce type il devrait arrêter de bosser su GNU/Linux
Posté par briaeros007 . En réponse au journal Lennart casse les logs!. Évalué à 6.
Normalement c'est l'admin qui gère la machine qui va regarder les logs.
Tu veux mettre de la sécurité en plus, mais pour quoi faire? Etre sur que le pid qui émet ce message ets bien celui qui devrait l'émettre ?
Ca veux dire que tu as déjà un gros problème : un programme qui fonctionne qui se fait passer pour un autre!
Et ça, c'est pas un serveur de log plus sécurisé, c'est une machine mieux administrer qu'il faut.
La "sécurité" qu'un système de log a besoin, c'est la non réupudiation et la non modification.
Pas l'authentification forte de chaque appli.
En même temps c'est pas toujours la même appli qui émet les logs, et elle n'a pas forcément les mêmes besoins que celle juste à coté.
Tu vas parser suivant ce qu'émets tes applis.
Si je fous des paquets IPs dans la log, je vais pas m'attendre à avoir les mêmes champs que si je regarde des demandes d'authentification.
A nouveau, Tu es censé connaitre les machines que tu loggues (et j'espère avoir un parc un tant soit peu cohérent).
Et suivant les soft de serveurs de logs que tu utilises, tu peux les avoir.
Mauvais admin, changer d'admin.
Ca c'est un pur probleme d'administration, pas d'outils.
Tu créé les fichier comme tu le souhaite (perso chez moi c'est ////(.|)
Comme dis au dessus : "mauvais admin, changer d'admin".
Avec les serveurs de logs actuel (syslogng, rsyslog, ...) tu peux strutcturer tes logs, avoir des fonctions avancées, voir rajouter des informations par rapport au "syslog habituel" quand tu peux gérer ce qui tourne sur le client (par ce que mettre rsyslog sur un firewall matériel, amha, c'est plus dur ^^).
Sans compter que l'on parle de strucutre, mais certains serveurs de logs permettent d'utiliser des bases de données (mysql, ...) et donc relativement simple à "structurer" (en dynamique par une requêtes, ou simplement par des vues).
Parfois oui. Dans ce cas, les solutions existent déjà, sont fonctionnelles, et ne cassent pas la compatibilité avec les autres.
Donc absolument pas nécessaire.