Supprimer tout / var / log?

Puis-je tout supprimer /var/log? Ou dois-je uniquement supprimer des fichiers (récursivement) dans /var/logmais laisser des dossiers?

Quelqu'un at-il une bonne rmligne de commande? (Mes compétences en administration me rendent nerveux.)

Remarque: j'utilise Debian. Je ne sais pas quelle version.

Au lieu de supprimer les fichiers, vous devez les faire pivoter, par exemple 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.

Nettoyage de 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/loga 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.

Les applications qui s'attendent à se connecter à un point à l'intérieur /var/logtoucheront souvent un fichier existant quelque part dans la /var/loghiérarchie pendant le temps d'installation (ce qui se produit souvent avec des privilèges élevés), et le feront chmodéventuellement chownà des autorisations appropriées pour les utilisateurs non privilégiés qui seront en utilisant 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 /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 mesure dans laquelle le développeur considère sa capacité à se connecter. Au mieux, l'application tentera d'écrire, ou peut-être de créer puis d'écrire dans un fichier journal à une destination à l'intérieur /var/log, et se trouvera incapable de le faire car elle est exécutée 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 /var/log- cela 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, un échec silencieux de la journalisation, et une rupture totale.

L'action appropriée à entreprendre est de configurer logrotateavec 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 configurer 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 fichiers 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)

function goodbyelogs {
find /var/log -type f
}

for i in return $(goodbyelogs);
do sudo cat /dev/null > $i;
echo "Log $i has been cleared";
done

créez un script exécutable et essayez de l'exécuter en tant que root si sudo ne fonctionne pas pour vous