Supprimer tout / var / log?
Puis-je tout supprimer dans /var/log? Ou dois-je supprimer uniquement les fichiers (récursivement) dans /var/log mais laisser des dossiers?
Quelqu'un a-t-il une bonne ligne de commande rm? (Mes compétences en administration me rendent nerveux.)
Note: J'utilise Debian. Je ne sais pas quelle version.
Au lieu de supprimer les fichiers, vous devez les faire pivoter, e. g. en utilisant logrotate.
Vous ne savez jamais quand vous aurez réellement besoin des journaux d'il y a quelque temps, il est donc préférable de les archiver (jusqu'à un âge raisonnable, par exemple 3 mois).
logrotate peut compresser vos anciens fichiers journaux afin qu'ils n'occupent pas beaucoup d'espace disque.
Si vous supprimez tout dans/var/log, vous vous retrouverez très probablement avec des tonnes de messages d'erreur en très peu de temps, car il y a des dossiers qui devraient exister (par exemple exim4, Apache2, apt, cups, mysql, samba et plus). Le plus: certains services ou applications ne créeront pas leurs fichiers journaux s'ils n'existent pas. Ils s'attendent à ce qu'au moins un fichier vide soit présent. La réponse directe à votre question est donc "Ne faites pas ça !!!".
Comme l'a souligné joschi, il n'y a aucune raison de le faire. J'ai des serveurs Debian en cours d'exécution qui n'ont pas eu un seul fichier journal supprimé depuis des années.
Supprimer tous les fichiers:
find /var/log -type f -delete
Supprimer tous les fichiers .gz et tournés
find /var/log -type f -regex ".*\.gz$"
find /var/log -type f -regex ".*\.[0-9]$"
Essayez d'exécuter la commande sans "-delete" pour la tester.
Je clone des machines virtuelles à partir d'un maître. Il est parfaitement logique d'effacer le journal sur le maître afin que lorsque vous démarrez les clones, vous n'obtiendrez pas le journal du maître. J'ai fait dans tcsh:
cd /var/log
foreach ii ( `find . -type f` )
foreach? cp /dev/null $ii
foreach? end
qui efface les journaux mais conserve les fichiers.
Nettoyer tous les journaux sur un système Linux sans supprimer les fichiers:
for CLEAN in $(find /var/log/ -type f)
do
cp /dev/null $CLEAN
done
Samba (/var/www/samba) crée des noms de fichiers journaux avec des adresses IP, vous pouvez les supprimer:
for CLEAN in $(find /var/log/samba -type f)
do
rm -rf $CLEAN
done
Vous pouvez utiliser l'option ctime pour retrouver d'anciens fichiers ... par exemple:
find -ctime +30
Comme bindbn l'explique, essayez d'abord de rechercher les fichiers de récupération et après avoir utilisé l'option supprimer: D
/var/log dispose souvent des autorisations de drwxrwxr-x, n'est donc pas accessible en écriture à moins que l'utilisateur ne soit root ou n'appartienne à un groupe privilégié. Cela signifie que de nouveaux fichiers journaux ne peuvent pas être créés par des utilisateurs non privilégiés.
Applications qui s'attendent à se connecter à un point dans /var/log touchera souvent un fichier existant quelque part dans le /var/log hiérarchie pendant l'installation (ce qui se produit souvent avec des privilèges élevés), et chmod et éventuellement chown à ce moment-là aux autorisations appropriées pour les utilisateurs non privilégiés qui utiliseront l'application.
Les journaux Apache, par exemple, sont généralement écrits par nobody, qui est un utilisateur avec le moins de privilèges possible pour qu'Apache puisse faire son travail sans mettre le système en danger indu. Mais même une application plus courante s'attend souvent à pouvoir écrire dans un fichier journal dans /var/log.
Que se passe-t-il donc si le fichier journal et le chemin d'accès au fichier journal n'existent pas? Cela dépend entièrement de l'application. Certaines applications ignoreront tranquillement la journalisation. D'autres créeront de nombreux avertissements. Et d'autres vont simplement renflouer. Il n'y a pas de règle stricte; cela dépend de la vigilance du développeur de l'application, ainsi que de la façon dont le développeur considère sa capacité à se connecter. Au mieux, l'application tentera soit d'écrire, soit de créer puis d'écrire dans un fichier journal à une destination dans /var/log, et se trouvera dans l'impossibilité de le faire car il est exécuté par un utilisateur qui n'a pas les privilèges pour écrire dans cette partie du système de fichiers.
Donc, la réponse courte est non, ne supprimez pas tout dans /var/log - il casse les utilisateurs du contrat avec des privilèges suffisants pour faire de telles choses avec les applications qui s'exécutent sur leur système, et provoquera du bruit, une défaillance silencieuse de la journalisation et une rupture totale.
L'action appropriée à entreprendre est de configurer logrotate avec les fichiers de configuration appropriés. La rotation est généralement associée à une tâche cron. La rotation peut être basée sur un intervalle, ou basée sur la taille, ou les deux. Il est même possible de définir des règles qui évitent la rotation basée sur un intervalle si le fichier journal est toujours vide à l'expiration de l'intervalle. La rotation peut inclure l'envoi de fichiers journaux, la compression, la suppression, la destruction, etc.
L'utilisateur moyen n'aurait pas à se soucier trop de la rotation des journaux. Les développeurs voudront probablement s'assurer que les journaux qu'ils utilisent ont des règles de rotation établies. En fait, les développeurs ont probablement de bonnes manières de configurer la rotation des journaux au moment de l'installation pour tous les journaux spécifiques au logiciel que le logiciel va créer et écrire.
J'ai implémenté un simple nettoyeur ici:
https://github.com/Lin-Buo-Ren/Coward-Unix-Log-Cleaner
Il s'agit simplement:
- Supprime les noms de fichier avec les modèles de nom de fichier logrotated suivants sous
/var/log^.*/.+\.[[:digit:]]+(\.[[:alpha:]]+)?$^.*/.+\.old$(Insensible à la casse)
- Tronquer/vider les fichiers avec des noms de fichiers avec les modèles de nom de fichier journal suivants sous
/var/log^.*/.+\.log$(Insensible à la casse)