À main levée, combien d'entre vous aiment redémarrer leurs serveurs ? Je ne vois aucune main.
Les longs temps de disponibilité sont impressionnants, n'est-ce pas ? Cela fait de vous l'un des enfants cool à se vanter de votre disponibilité de 853 jours sur un système de production. Ce qui n'est pas si cool, c'est que vos utilisateurs aiment utiliser /tmp
comme leur dépotoir personnel sans tenir compte de la santé globale du système ou de vos droits de vantardise de disponibilité. Et le redémarrage ne supprime pas les fichiers utilisateur, seulement ceux du système. Même ce soulagement est temporaire jusqu'au redémarrage des services et à l'ouverture des applications par les utilisateurs.
Remarque : Une exception pour ne pas supprimer les fichiers temporaires de l'utilisateur après un redémarrage consiste à activer
tmp.mount
, mais c'est un sujet pour un autre article. De plus, des scripts de maintenance du système sont en place pour RHEL 7 et versions ultérieures.
Il est impossible de forcer les utilisateurs à se conformer à la politique de suppression des fichiers du /tmp
répertoire en temps opportun. Alors, que doit faire un administrateur système frustré lorsque vous avez des dizaines, des centaines, voire des milliers de /tmp
répertoires et utilisateurs à gérer ? La réponse est de déployer des scripts de gestion des fichiers utilisateur.
Vous pouvez créer des scripts de maintenance et les placer dans crontab
supprimer périodiquement les fichiers utilisateur de /tmp
annuaire. C'est un service malheureux mais nécessaire à fournir à vos utilisateurs. La plupart des administrateurs système expérimentés vous diront que vous ne devez pas supprimer les fichiers de /tmp
sauf si vous savez qu'ils ne sont pas utilisés, cependant. C'est un bon conseil. Certains services écrivent des fichiers de verrouillage dans /tmp
, certaines applications l'utilisent et les utilisateurs l'utilisent. Alors, comment déterminez-vous quels fichiers votre script de nettoyage peut balayer sans problème ?
[ Téléchargement gratuit :Aide-mémoire sur les commandes Linux avancées. ]
Que diriez-vous de filtrer les fichiers en fonction de l'heure du dernier accès ? C'est un bon choix si vous avez une limite de temps sur les fichiers restants dans /tmp
. Par exemple, si vous avertissez vos utilisateurs qu'il reste des fichiers dans le répertoire /tmp
répertoire sera supprimé s'ils n'ont pas été consultés dans les deux jours, sur une base continue, ils doivent en tenir compte. L'utilisation de l'heure du dernier accès pour les fichiers utilisateur résout le problème si vous excluez également les fichiers appartenant à l'utilisateur root. Par exemple, utilisez :
find /tmp -type f \( ! -user root \) -atime +2
Ce script affiche tous les fichiers dans le /tmp
répertoire n'appartenant pas à root auquel on a accédé il y a plus de deux jours. Maintenant pour ajouter le commutateur de suppression de la commande :
find /tmp -type f \( ! -user root \) -atime +2 -delete
Copiez ce texte dans un fichier, rendez-le exécutable et créez un crontab
entrée qui exécute ce script toutes les huit heures. Par exemple, vous pouvez ajouter ceci à votre crontab
:
* */8 * * * /opt/scripts/tmp.clean.sh
Ce script et ce programme garantissent que votre /tmp
répertoire est maintenu relativement exempt de déchets. Ce n'est pas infaillible, cependant. Si un utilisateur décide de vider une énorme quantité de données dans le /tmp
répertoire, cette action peut entraîner d'autres problèmes, comme l'impossibilité de se connecter au système via SSH.
Maintenance du /tmp
répertoire n'est pas facile. Les utilisateurs adorent déposer des fichiers dans /tmp
et les y laisser indéfiniment. Heureusement, pour les récidivistes, il y a toujours la possibilité de verrouiller leur compte ou d'envoyer un e-mail fortement formulé sur la perte d'accès à un système jusqu'à ce que l'affaire soit résolue par leur responsable. Ces tactiques attirent généralement l'attention de l'utilisateur et les infractions ultérieures sont rares.