Voici une astuce permettant d’historiser toutes les commandes tapées dans un shell.
Cet méthode est inspiré d’un article que j’ai vu sur Linux Attitude, j’ai juste rajouté le fait de rediriger ces logs dans un fichier à part avec la mise en place d’un logrotate.
Ajouter dans /etc/profile :
# envoyer la commande dans syslog pour chaque commande AVANT exécution
trap 'logger -i -p local5.info -t bash "$USER $(tty): $(fc -ln -1)"' DEBUG
OU
# envoyer la commande dans syslog pour chaque commande APRES exécution
PROMPT_COMMAND='logger -i -p local5.info -t bash "$USER $(tty): $(history 1)"'
# fc ne marche pas correctement dans PROMPT_COMMAND
Rediriger les logs dans un fichier à part, pour cela créer le fichier :
vi /etc/rsyslog.d/shell.conf
Et ajouter :
local5.* -/var/log/shell.log
Le tiret (-) devant le fichier de log permet une écriture asynchrone (pas forcément nécessaire, car ça ne risque pas d’impacter les perf, mais bon…)
Créer un fichier logrotate
/etc/logrotate.d/shell
/var/log/shell.log {
rotate 30
daily
missingok
notifempty
delaycompress
compress
postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript
create 640 root adm
}
Une fois que tout est prêt, il suffit de relancer rsyslog :
/etc/init.d/rsyslog restart
28 octobre 2013
Hello,
On est d’accord que c’est pas la même chose mais pourquoi pas faire un script -a ?
C’est plus vraiment du log mais au moins il y a tout ce qui s’affiche sur le terminal.
Tcho !
28 octobre 2013
@Cascador je ne vois pas ce que tu veux dire par :
« faire un script -a ? »
Historiser les commandes permet de savoir qui a fait quoi et quand
Bonne soirée
29 octobre 2013
Hello,
Désolé, je m’exprime très mal. La commande script fait partie du paquet util-linux.
man script :
script fait une transcription de tout ce qui est affiché sur le terminal.
-a, –append : Ajouter la transcription à la fin du fichier en conservant le contenu du fichier
Perso, je m’en sers parfois pour avoir un historique des choix faits lors de problèmes de dépendances.
C’est une commande assez peu évoluée, c’est ce qui est le plus dommage. Le man explique les points négatifs de cette commande
Tcho !
29 octobre 2013
Salut @Cascador
Ok je comprends ce que tu veux dire, le but ici est de savoir qui tape quelle commande sur un serveur accessible par plusieurs personnes de plusieurs entité différentes.
Donc je ne veux pas laisser le choix aux utilisateurs de lancer script ou pas.
Voilà pourquoi 😉
29 octobre 2013
Mais surtout, quel intérêt de ce type de manip ?
La commande «history» sauvegarde déjà les commandes enregistrées par l’utilisateur.
Allez, je déteste ces pratiques de gros trous du culs…
29 octobre 2013
lol @Gnafek je vois que tu es du genre agréable 🙂
Heureusement que tu mentionnes l’historique de commande qui rend ton commentaire, malgré ton insulte, quelque part constructif.
Je t’invite à prendre un peu de recul, car lorsque tu gères des serveurs avec des intervenants multiples, il peut-être utile d’avoir des traces de ce qui est fait et pas forcément pour un besoin de flicage comme tu as l’air de le penser.
Tu peux personnaliser ton historique, mais si je ne m’abuse, tu vas gérer un nombre de ligne et non une durée sans rotation.
De plus, l’historique est stocké dans le répertoire de l’utilisateur, ce que je ne souhaite pas.
Un autre avantage est la possibilité d’envoyer les logs sur un serveur distant via rsyslog pour la sauvegarde ou pour éviter qu’un tiers y ai accès.
Ça permet aussi de lister dans un seul fichier toutes les commandes qui ont été lancé par les utilisateurs à une heure donnée. Avec les historiques, il faudrait regarder dans chaque bash_history
Pour le gars qui est d’astreinte par exemple et se rends compte d’un problème, il pourrait être content d’avoir ces informations.
Bref, j’arrête là.
Ton commentaire est tellement gros, que je me demande si c’est pas du fake 😉
30 octobre 2013
Il faudrait que je test !
@Gnafek l’historique base est une merde 😉
car si on se connecte a plusieurs session, sur le même compte, c’est la dernière session qui part qui écrase les historiques des autres session…
31 octobre 2013
Non désolé, je vois rien qui légitime…
Si le serveur flanche, il a ses propres mécanismes pour répertorier les erreurs, y’a aucune nécessité à aller épier ce que fait l’un ou l’autre…
La volonté de copier l’historique sur un serveur distant, c’est quoi à part un manque de confiance envers ses utilisateurs ?
J’aimerais pas t’avoir pour admin.
15 juin 2015
Et moi je n’aimerais pas t’avoir comme technicien… :p
31 octobre 2013
un historique sa doit marcher rien que pour retrouver le travail que l’on a fait ou que d’autres ont fait 😉
18 novembre 2013
merci, c’est en effet très utile et fais gagner du temps.
19 novembre 2013
Merci pour l’astuce
Quant a ceux qui n’en comprennent pas l’utilité … aie aie aie !
19 novembre 2013
Salut,
Est-il possible de savoir à partir de quelles IP clientes (SSH), les commandes ont été exécutées?
20 novembre 2013
Salut Olivier,
Tu peux déjà récupérer l’adresse ip via le fichier auth.log et donc en croisant, réussir à trouver l’ip.
Sinon, tu peux aussi récupérer la variable d’environnement $SSH_CLIENT qui contient l’ip et les ports associés à la connexion.
Tu peux donc mettre :
IP_SOURCE=`echo $SSH_CLIENT| cut -d » » -f1`
PROMPT_COMMAND=’logger -i -p local5.info -t bash « $IP_SOURCE $USER $(tty): $(history 1) »‘
Il y a peut-être mieux 😉
Bonne soirée
26 novembre 2013
Perso j’utilisais ça dans mon ancienne boite https://github.com/Poil/Useful-Linux-Scripts/blob/master/profile.d/history.sh
Ca log dans le bash_history et ça trace quel est l’utilisateur qui a exécuté les commandes (même après sudo su -)
Sans doute moyen de croiser les 2 pour avoir un truc vraiment top
20 novembre 2013
Super merci beaucoup pour l’info, je testeras ça 🙂
12 décembre 2013
Punaise, ca va me changer de la simple commande « history » !
Merci .. plus qu’à mettre ça en place !
20 décembre 2013
Hello,
J’ai trouvé un autre moyen de faire dès fois que ça intéresse quelqu’un :
http://ashok-linux-tips.blogspot.in/2012/04/log-commands-executed-by-all-users.html
Tcho !
20 décembre 2013
Merci beaucoup pour l’info @Cascador 😉
21 mai 2014
Simple remarque, dans le cas où on utilise :
PROMPT_COMMAND=’logger -i -p local5.info -t bash « $USER
ne pas oublier « export PROMPT_COMMAND » dans le /etc/profile
Merci pour cette info, c’est pratique.
16 octobre 2015
Bonjour et merci beaucoup pour cet astuce, c’est justement ce que je cherchais.
Pour ceux qui ne comprennent pas l’utilité, je vais juste leur expliqué mon cas actuel.
On est nombreux avoir un accès root, ne me blâme pas c’est déjà comme ça avant je j’arrive car ça fait partie de la politique interne de l’entreprise. Le problème actuel c’est que certains gens modifient des trucs en voulant apporter une amélioration mais c’est l’effet inverse qui apparaît, la performance du serveur ainsi que du site se dégrade de jour en jour.
Voilà pourquoi j’ai besoin de savoir qui a fait quoi à quel moment, car il est difficile de résoudre un problème qui se complique de jour en jour sans connaitre les causes exactes.
Comme vous pouvez le deviner, personne ne vas dire que c’est moi qui a fait ceci ou cela.
Merci encore pour cette info.
8 juin 2016
Et syslog-ng dans tout ça?