[/var] Trop important (RÉSOLU)

Support Debian
#1

Bonsoir,

En utilisant le soft ncdu (merci pour le soft…), je viens de m’apercevoir que le rep /var fait 15.7 G. Sachant la partition fait 28 G.

En regardant un peu plus en détail, les log prennent déjà 14,9 G.
Je vais tout mettre, mais les trois gros sont

  • degug.1 (7,9 G)
  • kern.log.1 (4,1 G)
  • kern.log (2,4 G)

et après ça descend à 243.2 M…
Ça fait quoi, si je fais sauté les 3 plus gros ?

Ça fais juste un peu d’air sur le disque, ou c’est le plongeon dans le vide, et scratche à la fin ?

Je vous remercie pour les réponses.

#2

C’est de l’administration à distance?

#3

Si on veux…

C’est un poste qui est à côté (un mètre au max), mais je passe en ssh… et utilise webmin également…

Je n’ai ni clavier, souris, écran… C’est un serveur de fichier.

#4

Bah tu peux les supprimer (ce ne sont que des logs), mais à ta place j’en ferait une copie d’abord pour les consulter et voir s’il n’y a pas des messages à répétition qui bourrent de façon considérable ces logs, auquel cas il y aurait peut-être des soucis à régler…

1 J'aime
#5

Ok, je te remercie pour l’info.

Je teste et reviens.

Bonne soirée.

#6

De rien, bonne soirée également :wink:

#7

Merci

#8

Mets en place une rotation des logs, sinon ce sera dix fois plus propre et te permettra de conserver un minimum de log et le contrôle sur le poids des logs.

#9

Pour paraphraser une publicité

On est mal!
Un exemple sur une machine wheezy intégrée à un Active Directory

fp2x@drhpcmss:~$ sudo du -h -s /var/log
Password:
197M    /var/log
fp2x@drhpcmss:~$ l /var/log/kern.log*
0 -rw-r----- 1 root adm    0 sept. 25 06:25 /var/log/kern.log
4 -rw-r----- 1 root adm 1236 sept. 23 09:43 /var/log/kern.log.1
8 -rw-r----- 1 root adm 4484 sept. 16 15:36 /var/log/kern.log.2.gz
4 -rw-r----- 1 root adm  238 sept.  8 15:27 /var/log/kern.log.3.gz
4 -rw-r----- 1 root adm  155 sept.  7 11:36 /var/log/kern.log.4.gz
fp2x@drhpcmss:~$ sudo du -h -s /var/log
197M    /var/log
fp2x@drhpcmss:~$ l /var/log/debug*
 0 -rw-r----- 1 root adm     0 juil. 22 06:31 /var/log/debug
88 -rw-r----- 1 root adm 82782 juil. 21 23:40 /var/log/debug.1
 8 -rw-r----- 1 root adm  5371 avril 25 07:29 /var/log/debug.2.gz
 8 -rw-r----- 1 root adm  5457 nov.   7  2015 /var/log/debug.3.gz
 4 -rw-r----- 1 root adm   616 oct.  14  2015 /var/log/debug.4.gz
fp2x@drhpcmss:~$ sudo du -h -s /var/log/samba
Password:
77M     /var/log/samba
fp2x@drhpcmss:~$ lsb_release --short --code
wheezy
fp2x@drhpcmss:~$ uptime
 14:43:14 up 76 days, 15:02,  6 users,  load average: 0,00, 0,01, 0,05
fp2x@drhpcmss:~$

Il y a un lézard qui dort sur votre système !

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean

Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#10

Bonsoir,

Merci pour les retours.

Ba en fait, je ne suis pas trop du style à regarder les logs (ho pas bien)…
Je regarde si le raid est opérationnel environ une fois par semaine.
Après, le serveur est en interne (après un parre-feu), et il y a deux postes (un raspberry sous osmc et un client sous archlinux), et de temps à autre (surtout quand il neige et que les oiseaux chantent…) il y a un portable sous… je ne sais plus quelle distrib c’est basé…
Pas de poste wouindow$, pas de wifi, le minimum syndical. Donc, normalement, il n’y a pas trop lieux qu’il y aille de problème particulier (je doute que le raisonnement soit des plus justes…).

J’ai été mis en alerte quand le disque de l’OS était plein à… ras bord… Là je me suis… Ho Mer**.

Utilisant un serveur dlna, je l’ai fait sauté direct (un peu déçu d’ailleurs au passage, mais bon, les goûts et les couleurs…). J’ai ainsi récupéré de la place.

Je me suis dis, tant qu’à chercher un peu… Et là, j’ai vu les logs…

J’ai eu le plaisir de regarder les 15G de log… Ça m’a pris 3hr…

Nan, j’déconne… Étant fainéant (j’entends par là, fainéant dans le sens optimisation du temps… Surtout quand il y a 15G de texte à lire… Ce n’est pas un rapport de thèse…). Le message qui revient souvent est :BANDWIDTH_IN:IN=eth0 OUT= MAC=00:Adresse_Mac_du_Poste:00 SRC=Adresse_IP_Poste_Client DST=224.0.0.251 LEN=147 TOS=0x00 PREC=0x00 TTL=255 ID=43893 DF PROTO=UDP SPT=5353 DPT=5353 LEN=127
Quand je vois çà… Plusieurs questions viennent…
Pourquoi mon serveur voit les échanges entre un poste client et 224.0.0.251 sachant que normalement il n’est pas serveur dhcp ?
Qui est 224.0.0.251 ?

Un autre message apparaît souvent :BANDWIDTH_OUT:IN= OUT=eth0 SRC=Adresse_IP_Serveur DST=239.255.255.250 LEN=321 TOS=0x00 PREC=0x00 TTL=4 ID=20119 DF PROTO=UDP SPT=33480 DPT=1900 LEN=301
Pourquoi le serveur cause avec 239.255.255.250 ?
Qui est 239.255.255.250 ?

Les deux principaux messages sont des exemples types…
Les messages ont commencés à appaître le 18/09… Pourquoi… ? Aucune idée.

Vous n’auriez pas quelques idées ?

Bonne soirée.

#11

Comme vous avez caché les paramètres source et destination, il nous reste l’information sur les ports utilisés

fgrep 5353 /etc/services
mdns            5353/tcp                        # Multicast DNS
mdns            5353/udp

Pourrait-on avoir le contenu de /etc/nsswitch.conf ?

Je peux me tromper, mais il me semble que les adresses en 239.xx.yy.zz.tt sont réservées au multicast.
Multicast sur wikipedia

Vous avez encore de la lecture : les journaux du pare-feu :slight_smile: et peut-être un petit paramétrage relatif au port 5353.

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean
Ingénieur civil du Génie Maritime.

Concierge qui roule, ne s’arrête qu’au bas de l’escalier.
Les proverbes philosophiques du Professeur Choron

#12

Bonsoir littlejohn75,

Merci pour ta réponse.

Désolé, j’ai caché les adresses… Rien de bien méchant. C’était plus par automatisme. Les postes clients sont 192.168.2.30 et 40.

J’ai un peu cherché concernant le port 5353 et le multicast, c’est un protocole utilisé par la Pomme pourrie. Donc, n’ayant aucun système sous Mac, pourquoi le serveur l’utilise ?

Le contenu /etc/nsswitch (du serveur) :[code]# /etc/nsswitch.conf

Example configuration of GNU Name Service Switch functionality.

If you have the glibc-doc-reference' andinfo’ packages installed, try:

`info libc “Name Service Switch”’ for information about this file.

passwd: passwd
group: group
shadow: shadow
gshadow: files

hosts: files myhostname mdns4_minimal [NOTFOUND=return] dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis[/code]
Là, je suis complètement largué…

Par contre, pour les journaux du parre-feu, ça sera plus long… Je vais testé dans le week-end, car je suis à mort pris en ce moment…

Bonne soirée.

#13

C’est du multicast DNS (mDNS), utilisé par Zeroconf/avahi. Je ne vois pas l’intérêt de logger ce trafic dans les règles iptables.

#14

Faudrait surtout comprendre pourquoi cela génère des millions de lignes dans les journaux.

F. Petitjean

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#15

Peut-être que c’est la conséquence de ce qu’il avait été demandé de faire à webmin

…In webmin under Networking -> Bandwidth Monitoring click “Turn Off Monitoring”…

Dans webmin onglet Réseau -> (Pour la suite, j’ai pas webmin installé => je ne connais pas la traduction des menus qu’il utilise en français.)

#16

Parce que Zeroconf, UPnP (l’autre type de paquet multicast sur le port 1900), Netbios et toutes ces cochonneries qui prétendent marcher toutes seules sans configuration, c’est bavard.

#17

Bonsoir à tous,

Merci beaucoup pour vos réponses, conseils, et questions. Je reviens un peu tard…

Visiblement, Zeronconf/avahi est utilisé par kodi. Vu que j’utilise osmc sur une framboise (interface kodi), ceci expliquerai peut-être cela…

Parceque GNU/Linux est particulièrement très bavard. Il aime bien discuter et tenir informer. facile celle-là. J’avoue, lire 15 Go… C’est très sympa quand on a du mal à s’endormir.

Merci pour cette info technique. Je n’ai pas tilté, mais je fais pas mal de choses depuis webmin… Enfin, quand je n’arrive pas à trouver les touches du clavier…

Ho, tout de suite…
Nan, sérieux, je l’ignorai également…

J’ai quelques infos (Enfin…) :
Je suis aller voir le parre-feu… Vieux, il est loin…
pFsense ne connaît pas le port 5353.
Pour les adresses IP, les seules qui soient détectées sont les suivantes :

  • 192.168.1.254,
  • 192.168.2.40 (62 requêtes sur 3371),
  • fe80::230:18ff:fea0:4d06 (c’est bizarre car il n’y a pas d’IPv6 en interne… Sauf que ça ressemble, mais nan… Je ne sais pas ce que c’est) (2 requêtes sur 3371…),

Et les adresse IP de destinations sont :

  • 224.0.0.1 ,
  • 212.227.17.188,
  • 212.227.17.172,
  • ff02::1 (2 requêtes sur 3371…),
  • 66.102.1.109 (2 requêtes sur 3371…).

Ce qui veux sûrement dire que le trafic n’est quand interne… Vieux, c’est le périph quoi…

Je suis retourné voir les logs, et là… RAS, des logs normaux quoi…
Il n’y a pas mention de BANDWITH IN ou OUT…

Je n’apporte pas toutes les réponses… Mais à par lire en détail, les logs, je ne vois pas trop comment faire.

Je mets le sujet [EN ATTENTE].

Je reviens dès que j’ai des nouvelles infos :wink:

Bon dimanche.

#18

192.168.1.254 : adresse IPv4 privée typique d’une box ou d’un routeur.

fe80::230:18ff:fea0:4d06 : adresse IPv6 link local (portée limitée au lien) configurée automatiquement sur une interface réseau active quand l’IPv6 est activé.

224.0.0.1 : adresse IPv4 multicast.

212.227.17.188 et 212.227.17.172 : adresses IPv4 de imap.gmx.com (serveur de relève de courrier).

ff02::1 : adresse IPv6 multicast link-local “all nodes” désignant toutes les machines connectées au lien.

66.102.1.109 : adresse IPv4 appartenant à Google.

#19

Bonjour

Finalement, est-ce que tu as désactivé le monitoring sur webmin ?

…In webmin under Networking -> Bandwidth Monitoring click "Turn Off Monitoring"…
#20

Bonjour,

Merci pour ta réponse.

Merci pour les infos.
Yes, pour les adresse 192.168.X.YYY. Ça c’est pour la box et le réseau interne.

Pour les serveurs de courrier, ça ne m’étonne pas.
J’ignorais pour l’adresse IP de google.

Par contre, concernant IP v6, je ne comprends pas, car il n’y a pas de poste en IP v6.
Et pour ff02::1:, je ne comprends pas non plus, mais je ne pense pas que cela soit trop important…