Je souhaite modifier les paramètres d'historique de tous les utilisateurs des systèmes que je gère. Je voudrais qu'il contienne les informations du terminal de connexion comme dewho
sysadmin:/ # who
sysadmin pts/0 Mar 26 07:11 (sysadmin.doofus.local)
Je modifie actuellement mon historique des manières suivantes. Je sais que bon nombre de ces paramètres ont été abordés ici plusieurs fois. Cependant, j'ai tiré ce code de " Linux System Administration Recipes by: Juliet Kemp " il y a longtemps.
shopt -s histappend
PROMPT_COMMAND='history -n;history -a'
HISTSIZE=100000
HISTFILESIZE=100000
HISTTIMEFORMAT="%m/%d/%y %T "
shopt -s histappend
résout le problème lorsque vous avez plusieurs terminaux, des informations ouvertes peuvent être perdues.
PROMPT_COMMAND='history -n;history -a'
s'étend pour donner un ajout en temps réel à l'historique sur plusieurs terminaux.
HISTSIZE=100000
HISTFILESIZE=100000
augmente la quantité de history
rétention
HISTTIMEFORMAT="%m/%d/%y %T
"fait précéder chaque ligne de l'histoire d'un horodatage
Ce que vous obtenez généralement history
835 ls
836 cd ..
Mes history
résultats actuels modifiés
5853 03/26/12 07:16:49 ls
5854 03/26/12 07:16:50 ll
Le retour de history
je voudrais voir
5853 03/26/12 07:16:49 sysadmin.doofus.local ls
5854 03/26/12 07:16:50 sysadmin.doofus.local ll
001 03/26/12 05:11:29 demo_user.doofus.local cd
002 03/26/12 05:11:30 demo_user.doofus.local ll
Je ne suis pas "marié" à voir le DNS
nom. Je ne le voudrais là que s'il le tire de who
ou d'un autre emplacement sans avoir besoin d'effectuer une recherche ou une requête de quelque nature que ce soit. Je serais content de l'adresse IP.
002 03/26/12 05:11:30 192.168.0.2 ll
Pourquoi? Je gère plusieurs systèmes où un ID utilisateur que plusieurs utilisateurs d'un même groupe partagent pour effectuer leurs tâches quotidiennes. Cela me permettrait de corréler leur emplacement réel et leur utilisateur réel au sein de l'organisation avec ce qu'ils ont fait dans l'histoire.
Je suis conscient que ce n'est pas optimal et je voudrais le changer mais, lorsque vous êtes sur un navire de la taille d'un paquebot de croisière, vous n'essayez pas de faire des virages en épingle à cheveux. (Remarque: lorsque vous faites cela, les passagers essaient de vous jeter par-dessus bord)
Quoi qu'il en soit, jusqu'à ce que je puisse les migrer vers une meilleure solution, j'aimerais avoir cette capacité de suivi.
De plus, si vous avez des recommandations sur ce que j'utilise actuellement pour mes history
modifications, j'aimerais l'entendre.
Merci,
Modifier: 1
Je ne veux pas exécuter d'autres programmes ou avoir à configurer quoi que ce soit supplémentaire "dans des limites raisonnables".
Je veux ajouter des 0
frais généraux, si je dois ajouter, il doit être petit.
Je fais confiance à mes utilisateurs, je voudrais juste (si quelque chose devait arriver) voir lequel des 10 utilisateurs qui se sont connectés au système avec le même utilisateur: mot de passe l'a fait. Ou bien, il pourrait ne pas s'agir d'un utilisateur, il aurait pu être oublié cron
sur un système qui effectue une connexion en tant qu'utilisateur pour faire quelque chose. Ou une application Ex: BMC Control-M
qui se connecte ssh
et exécute des tâches. Il ne s'agit pas tant de trouver de «mauvais utilisateurs» que de pouvoir le retrouver avec un minimum d'effort.
Modifier 2:
Les systèmes exécutent SLES et RHEL
/proc
/dev
et les /home
répertoires d' utilisateurs . Cela ajoute des frais généraux. Alors que history
sont déjà en cours d'enregistrement et que leurs informations de connexion sont connues du système connectant IP, etc. Ces informations, si elles ne sont pas déjà disponibles "statiquement", pourraient être définies de cette façon ou stockées dans une variable ou un fichier et entrées dans les history
enregistrements et le résultat. serait très petit ou 0.
auditd
. Je ne sais pas si ses journaux vous donneront suffisamment d'informations. La difficulté de ce que vous voulez est précisément pourquoi les comptes partagés sont si décriés.
auditd
c'est un peu comme si inotify
vous deviez lui dire quoi surveiller pour les changements. Fichiers individuels, répertoires, etc. Je ne veux pas aller à ce niveau de configuration. En fait (je le fais), mais je m'en fiche pas mal. Je dois puppet
gérer ce genre de choses. auditd
est livré avec la charge supplémentaire et le temps de configuration également. Si un compte modifie quelque chose, je voudrais quand même regarder en arrière dans l'historique et voir qui ou quoi se connecte et essaie.
PROMPT_COMMAND=
exécute simplement des commandes normales avant l'invite suivante, ne pourriez-vous pas écrire une fonction appelant sed / awk qui fonctionne sur la dernière ligne du fichier d'historique pour ajouter les informations. puis appeler cette fonction PROMPT_COMMAND=
pour ajouter les données? il serait hackish mais devrait faire l'affaire.