Il y a longtemps dans l'histoire d'UNIX, les utilisateurs d'un serveur étaient de véritables utilisateurs UNIX avec des entrées dans /etc/shadow et un shell de connexion interactif et un répertoire personnel. Il y avait des outils permettant aux administrateurs de communiquer avec les utilisateurs et de surveiller leur activité afin d'éviter les erreurs stupides ou malveillantes qui entraîneraient une allocation injuste des ressources du serveur.
De nos jours, votre base d'utilisateurs est moins susceptible d'avoir des entrées dans /etc/shadow , au lieu d'être géré par une couche d'abstraction, qu'il s'agisse de LDAP, de Drupal ou d'OpenShift. Là encore, il y a beaucoup plus de serveurs maintenant, ce qui signifie qu'il y a beaucoup plus d'administrateurs système qui se connectent et se déconnectent pour effectuer la maintenance. Là où il y a de l'activité, il y a des possibilités d'erreurs et de confusion, il est donc temps de dépoussiérer ces anciens outils de surveillance et de les utiliser à bon escient.
Voici quelques-unes des commandes de surveillance que vous avez peut-être oubliées (ou que vous n'avez jamais connues) pour vous aider à suivre ce qui se passe sur votre serveur.
qui
Tout d'abord, les bases.
Le who La commande est fournie par le package GNU coreutils, et son travail principal est d'analyser le /var/log/utmp déposer et rapporter ses conclusions.
Le utmp fichier enregistre les utilisateurs actuels sur le système. Il ne montre pas nécessairement tous les processus, car tous les programmes ne lancent pas utmp enregistrement. En fait, votre système peut même ne pas avoir de utmp fichier par défaut. Dans ce cas, who se rabat sur /var/log/wtmp , qui enregistre toutes les connexions et déconnexions.
Le wtmp le format de fichier est exactement le même que utmp , sauf qu'un nom d'utilisateur nul indique une déconnexion et que le ~ Le caractère indique un arrêt ou un redémarrage du système. Le wtmp le fichier est maintenu par login(1) , init(1) , et certaines versions de getty(8) , cependant, aucune de ces applications ne crée le fichier, donc si vous supprimez wtmp , l'enregistrement est alors désactivé. Cela seul est bon à savoir :si wtmp est manquant, vous devriez découvrir pourquoi !
La sortie de who --heading ressemble à ceci :
NAME LINE TIME COMMENT
seth tty2 2020-01-26 18:19 (tty2)
larry pts/2 2020-01-28 13:02 (10.1.1.8)
curly pts/3 2020-01-28 14:42 (10.1.1.5) Cela vous montre le nom d'utilisateur de chaque personne connectée, l'heure à laquelle leur connexion a été enregistrée et leur adresse IP.
Le who La commande fournit également humblement le moyen POSIX officiel de découvrir quel utilisateur vous sont connectés en tant que, mais uniquement si utmp existe :
$ who -m
curly pts/3 2020-01-28 14:44 (10.1.1.8) Il fournit également un mécanisme pour afficher le niveau d'exécution actuel :
$ who -r
run-level 5 2020-01-26 23:58 w
Pour un peu plus de contexte sur les utilisateurs, le simple w La commande fournit une liste des personnes connectées et de ce qu'elles font. Ces informations sont affichées dans un format similaire à la sortie de who , mais la durée d'inactivité de l'utilisateur, le temps CPU utilisé par tous les processus attachés au TTY de connexion et le temps CPU utilisé uniquement par le processus en cours. Le processus actuel de l'utilisateur est répertorié dans le dernier champ.
Exemple de sortie :
$ w
13:45:48 up 29 days, 19:24, 2 users, load average: 0.53, 0.52, 0.54
USER TTY LOGIN@ IDLE JCPU PCPU WHAT
seth tty2 Sun18 43:22m 0.01s 0.01s /usr/libexec/gnome-session-binary
curly pts/2 13:02 35:12 0.03s 0.03s -bash
Alternativement, vous pouvez afficher l'adresse IP de l'utilisateur avec le -i ou --ip-addr option.
Vous pouvez restreindre la sortie à un seul nom d'utilisateur en spécifiant sur quel utilisateur vous souhaitez obtenir des informations :
$ w seth
13:45:48 up 29 days, 19:27, 2 users, load average: 0.53, 0.52, 0.54
USER TTY LOGIN@ IDLE JCPU PCPU WHAT
seth tty2 Sun18 43:25m 0.01s 0.01s /usr/libexec/gnome-session-binary vidage utmp
Le utmpdump L'utilitaire fait (presque) exactement ce que son nom suggère :il vide le contenu de /var/log/utmp fichier sur votre écran. En fait, il vide soit le utmp ou le wtmp fichier, selon celui que vous spécifiez. Bien sûr, le fichier que vous spécifiez ne doit pas nécessairement se trouver dans /var/log ou même nommé utmp ou wtmp , et il n'est même pas nécessaire qu'il soit au bon format. Si vous alimentez utmpdump un fichier texte, il vide le contenu sur votre écran (ou un fichier, avec le --output option) dans un format prévisible et facile à analyser.
Normalement, bien sûr, vous utiliseriez simplement who ou w pour analyser les enregistrements de connexion, mais utmpdump est utile dans de nombreux cas.
- Les fichiers peuvent être corrompus. Alors que
whoetwsont souvent capables de détecter eux-mêmes la corruption,utmpdumpest de plus en plus tolérant car il ne fait pas d'analyse par lui-même. Il affiche les données brutes que vous devez traiter. - Une fois que vous avez réparé un fichier corrompu,
utmpdumppouvez corriger vos modifications. - Parfois, vous souhaitez simplement analyser les données vous-même. Peut-être cherchez-vous quelque chose qui
whoetwn'êtes pas programmé pour rechercher, ou peut-être essayez-vous de créer des corrélations par vous-même.
Quelle que soit la raison, utmpdump est un outil utile pour extraire les données brutes des enregistrements de connexion.
Si vous avez réparé un journal de connexion corrompu, vous pouvez utiliser utmpdump pour réécrire vos modifications dans le journal principal :
$ sudo utmpdump -r < wtmp.fix > /var/log/wtmp ps
Une fois que vous savez qui est connecté sur votre système, vous pouvez utiliser ps pour obtenir un instantané des processus en cours. Cela ne doit pas être confondu avec le haut, qui affiche un rapport en cours d'exécution sur les processus en cours ; ceci est un instantané pris à l'instant ps est émis, puis imprimé sur votre écran. Il y a des avantages et des inconvénients aux deux, vous pouvez donc choisir lequel utiliser en fonction de vos besoins. En raison de sa nature statique, ps est particulièrement utile pour une analyse ultérieure, ou simplement comme un joli résumé gérable.
Le ps La commande est ancienne et bien connue, et il semble que de nombreux administrateurs aient appris l'ancienne commande UNIX plutôt que la dernière implémentation. Le ps moderne (depuis le procps-ng package) offre de nombreux mnémoniques utiles, et c'est ce qui est livré sur RHEL, CentOS, Fedora et de nombreuses autres distributions, c'est donc ce que cet article utilise.
Vous pouvez obtenir tous les processus exécutés par un seul utilisateur avec le --user (ou -u ), ainsi que le nom d'utilisateur de la personne sur laquelle vous souhaitez un rapport. Pour donner à la sortie le contexte ajouté dont le processus est le parent d'un processus enfant, utilisez le --forest option pour une vue "arborescente" :
$ ps --forst --user larry
PID TTY TIME CMD
39707 ? 00:00:00 sshd
39713 pts/4 00:00:00 \_ bash
39684 ? 00:00:00 systemd
39691 ? 00:00:00 \_ (sd-pam) Pour chaque processus sur le système :
$ ps --forest -e
[...]
29284 ? 00:00:48 \_ gnome-terminal-
29423 pts/0 00:00:00 | \_ bash
42767 pts/0 00:00:00 | | \_ ps
39631 pts/1 00:00:00 | \_ bash
39671 pts/1 00:00:00 | \_ ssh
32604 ? 00:00:00 \_ bwrap
32612 ? 00:00:00 | \_ bwrap
32613 ? 00:09:05 | \_ dring
32609 ? 00:00:00 \_ bwrap
32610 ? 00:00:15 \_ xdg-dbus-proxy
1870 ? 00:00:05 gnome-keyring-d
4809 ? 00:00:00 \_ ssh-agent
[...]
Les colonnes par défaut sont utiles, mais vous pouvez les modifier pour mieux répondre à vos recherches. Le -o L'option vous donne un contrôle total sur les colonnes que vous voyez. Pour une liste complète des colonnes possibles, reportez-vous aux spécificateurs de format standard section du ps(1) page de manuel.
$ ps -eo pid,user,pcpu,args --sort user
42799 root 0.0 [kworker/u16:7-flush-253:1]
42829 root 0.0 [kworker/0:2-events]
42985 root 0.0 [kworker/3:0-events_freezable_power_]
1181 rtkit 0.0 /usr/libexec/rtkit-daemon
1849 seth 0.0 /usr/lib/systemd/systemd --user
1857 seth 0.0 (sd-pam)
1870 seth 0.0 /usr/bin/gnome-keyring-daemon --daemonize --login
1879 seth 0.0 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session
Le ps la commande est très flexible. Vous pouvez modifier sa sortie nativement afin de ne pas avoir à vous fier à grep et awk pour trouver ce qui vous tient à cœur. Fabriquez un bon ps commande, associez-la à quelque chose de mémorable et exécutez-la souvent. C'est l'un des meilleurs moyens de rester informé de ce qui se passe sur votre serveur.
pgrep
Parfois, vous pouvez avoir une idée d'un processus problématique et avoir besoin d'enquêter sur celui-ci plutôt que sur vos utilisateurs ou votre système. Pour ce faire, il y a le pgrep commande de psproc-ng paquet.
Dans sa forme la plus basique, pgrep fonctionne comme un grep sur la sortie de ps :
$ pgrep bash
29423
39631
39713 Au lieu de répertorier les PID, vous pouvez simplement obtenir le nombre de PID renvoyés :
$ pgrep --count bash
3
Pour plus d'informations, vous pouvez affecter votre recherche via des processus par nom d'utilisateur (-u ), borne (--terminal ) et l'âge (--newest et --oldest ), et plus. Pour rechercher un processus appartenant à un utilisateur spécifique, par exemple :
$ pgrep bash -u moe --list-name
39631 bash
Vous pouvez même obtenir des correspondances inverses avec le --inverse option.
pkill
Relatif à pgrep est le pkill commande. C'est un peu comme le kill commande, sauf qu'elle utilise les mêmes options que pgrep afin que vous puissiez envoyer des signaux à un processus gênant en utilisant les informations qui vous conviennent le mieux.
Par exemple, si vous avez découvert qu'un processus initié par l'utilisateur larry monopolise les ressources, et vous le savez grâce à w ce larry est situé au terminal pts/2 , vous pouvez alors arrêter la session de connexion et tous ses enfants avec juste le nom du terminal :
$ sudo pkill -9 --terminal pts/2 Ou vous pouvez utiliser uniquement le nom d'utilisateur pour mettre fin à tous les processus qui lui correspondent :
$ sudo pkill -u larry
Utilisé judicieusement, pkill est un bon bouton "panique" ou une solution de style marteau lorsqu'un problème devient incontrôlable.
Surveillance des terminaux
Ce n'est pas parce qu'une série de commandes existe dans un terminal qu'elles sont nécessairement meilleures que d'autres solutions. Faites le point sur vos besoins et choisissez le meilleur outil pour ce dont vous avez besoin. Parfois, un système graphique de surveillance et de création de rapports est exactement ce dont vous avez besoin, et d'autres fois, des commandes de terminal facilement scriptées et analysées sont la bonne réponse. Choisissez judicieusement, apprenez vos outils et vous ne serez jamais dans l'ignorance de ce qui se passe dans votre métal nu.
[Vous voulez en savoir plus sur la surveillance et la sécurité ? Consultez la liste de vérification de la sécurité informatique et de la conformité. ]