Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Avoir une console où défilent les logs

totoffe

Bonjour,

J'aimerais avoir sur la Fedora une console où les logs défilent en temps réel (soit une "Konsole" dans KDE, soit une console texte externe), afin de pouvoir "garder un oeil sur le système".

Quelqu'un a-t-il une idée pour faire cela ?

Je crois qu'il existe une astuce au niveau de /etc/syslog.conf mais je ne me souviens plus laquelle.

Merci d'avance

Totoffe

valhalla

Ben pas besoin de te prendre la tete... tail est fait pour ca (pas pour te prendre la tete).

tail -f tonFichierDeLogASurveiller

A+

[supprimé]

Je ne connaissais pas la commande tail.
En effet, cela convient parfaitement à ce que je veux faire.

Merci beaucoup

A+

Totoffe

totoffe

Bon, je m'en suis très bien sorti et j'en suis assez content.
Voila ce que j'ai fait, ça peut servir à d'autres utilisateurs.

Le but du jeu étant d'avoir tous les logs défilant dans une console de kde, quelques manips étaient à faire. Rien de bien difficile cependant.

La première étape consistait à diriger tous les logs vers un fichier unique qui nous servira de "base de surveillance".

Pour cela, ouvrez une console et passez en root (avec la commande su)et éditez le fichier /etc/syslog.conf (par exemple avec vim)

Ajoutez les deux lignes suivantes :

# Diriger toutes les sorties dans un fichier unique
*.* /var/log/full.log

Sauvegardez la modification.
Puis relancez syslog

/etc/init.d/syslog restart

Jusque là tout va bien. Sauf que le propriétaire du fichier full.log est actuellement... root.
Donc pas question de lire le fichier avec votre compte utilisateur habituel. Pas question non plus de le lire dans une console root, ce ne serait pas élégant.

On pourrait changer le propriétaire du fichier, mais ce n'est pas une bonne idée, ce serait un mauvais choix en matière de sécurité.

On va donc passer par le groupe des admins (adm), ce qui me semble un bon compromis.

Donc, on commence déja par ajouter votre compte de utilisateur au groupe adm. Pour cela, allez dans le menu de KDE > Parametres du systeme > utilisateurs et groupes, puis cliquez sur l'utilisateur voulu. Cliquez ensuite sur propriétés, allez dans l'onglet groupe, cochez adm, validez.

Notez qu'il faudra fermer puis réouvrir votre session pour que la modification soit prise en compte.

Bon, vous voila dans le groupe adm, mais le fichier appartient toujours à root, du groupe root. On va donc le changer de groupe. Ouvrez une console en root et faites :

chgrp adm /var/log/full.log

Le fichier a toujours root comme propriétaire, mais désormais, il appartient au groupe adm.

On a presque fini, mais il reste un détail : seul le propriétaire a le droit de lire le fichier, mais pas le groupe. On va donc donner les droits en lecture au groupe :

chmod 640 /var/log/full.log

Voila, on est au bout : le fichier est desormais lisible par les membres du groupe adm, et donc par vous, puisque vous en faites maintenant partie !

Il ne vous reste plus qu'a ouvrir une console en tant que simple utilisateur dans un coin de KDE et de faire

tail -f /var/log/full.log

Les logs vont alors défiler en temps réel sur la console (on pourra stopper tail avec Control-C)

Ce qui est pratique avec une console sous KDE, c'est qu'on a les ascenceurs pour rattrapper la lecture en retard, et on peut laisser la console sur un bureau virtuel à part, si on ne veut pas l'avoir constamment sous les yeux.

Voila...

Bon, je suis un débutant sous Linux, je ne dis pas que ma solution est la meilleure, mais je la trouve simple à mettre en oeuvre. Que les pros soient indulgents et me corrigent le cas échéant. Et merci à ceux qui m'ont aidé pour la commande tail.

Totoffe

herrib

On va donc passer par le groupe des admins (adm), ce qui me semble un bon compromis.

Pas vraiment ... On affaiblit globalement la sécurité du système en attribuant massivement les droits du groupe adm à un utilisateur.

Il est préférable d'ouvrir une console dans un environnement utilisateur et d'hériter des droits root pour y lire le fichier en question:

su -
<saisie du mot de passe root>
tail -100 le_fichier_en_question

Enfin, je signale qu'il existe des programmes qui permettent d'analyser les log simplement, en environnement graphique; je cite system-logviewer de l'environnement Gnome. Il en existe dans l'environnement Kde. Pourquoi dès lors passer par la console?

valhalla

J'ai pas tout lu mais je suis choqué par 2, 3 trucs...

Pas question non plus de le lire dans une console root, ce ne serait pas élégant.

Ha bon? pourquoi??? Tu crois que si les logs systemes sont interdit de lecture pour les utilisateurs non privilégiés c'est pour emmerder le monde??

On va donc passer par le groupe des admins (adm), ce qui me semble un bon compromis.

Tout comme Herrib... Arrivé au point ou tu en es tu peux faire un su... Faire autant de modif (surtout sur des choses assez critiques) juste pour lire les logs...

Mat

Valhalla et herrib, voilà la réponse à vos questions:

Totoffe a écrit:
Bon, je suis un débutant sous Linux, je ne dis pas que ma solution est la meilleure

:-D

valhalla

Ah oui 🙂 Bon j'avais precisé que je n'avais pas tout lu aussi!

flyingpenguin

Un sudo à la rigueur non ?

valhalla

+1 pour flyingpenguin

Le sudo semble etre une bonne solution.

herrib

Le sudo ne semble pas non plus une bonne solution car la corruption d'un compte utilisateur ouvrirait alors des droits immédiats avec le niveau root.

La solution consistant à ouvrir une console et hériter des droits root de façon expresse (par su) est préférable à une solution qui alloue de facto ces droits de façon permanente.

Mat: oui, oui, j'ai bien tenu compte de la déclaration de notre ami...

totoffe

Au temps pour moi...

Je pensais que passer par su, c'etait laisser une console ouverte en root en permanence (vu que je la laisse ouverte avec les logs qui défilent en continu), et j'avais l'impression que ce n'etait pas une bonne idée...

Comme je l'ai dit, je reste un débutant et je n'ai donc pas la science infuse.

Merci de m'avoir corrigé.

Petite question en passant : vaut-il également mieux passer par su si cette surveillance se fait à distance par une console avec ssh ?

Bonne journée.

A+

Totoffe

valhalla

BEn apres avec sudo t'es pas obligé de lui donner tous les droits root non plus.... Tu lui laisses seulement executer un tail sur le fichier de log par exemple.

flyingpenguin

herrib a écrit:
Le sudo ne semble pas non plus une bonne solution car la corruption d'un compte utilisateur ouvrirait alors des droits immédiats avec le niveau root.

Pas d'accord :-x 😉

Ben non, le sudo permet de gérer finement l'exécution de certaines commandes EXPRESSEMENTS MENTIONNEES et pour des utilisateurs bien précis. Je ne vois pas en quoi autoriser le tail à un utilisateur corrompt le système. sudo est moins dangereux que su pour des opérations qui doivent souvent être répétées régulièrement...

Bonne après-midi !

herrib

Oui, c'est vrai. Il faut alors paramétrer sudo sous une maille très fine .

Le su est potentiellement plus ravageur mais il est clairement défini comme un passage en mode root.

[supprimé]

Etrait de mon /etc/syslog.conf

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none /var/log/messages
*.info;mail.none;authpriv.none;cron.none /dev/tty6

# The authpriv file has restricted access.
authpriv.* /var/log/secure
authpriv.* /dev/tty6

# Log all the mail messages in one place.
mail.* -/var/log/maillog

# Log cron stuff
cron.* /var/log/cron
cron.* /dev/tty6

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler
uucp,news.crit /dev/tty6

# Save boot messages also to boot.log
local7.* /var/log/boot.log
local7.* /dev/tty6

Cela pose t'il des problème sécurité ?