Netconsole, log de messages noyaux via UDP

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
30
sept.
2004
Noyau
Un pseudo driver réseau a fait son apparition dans le noyau 2.6 il y a neuf mois, et n'a pas été remarqué malgré son utilité plutôt importante dans certains cas.

Il s'agit de netconsole, écrit par Ingo Molnar et Matt Mackal, qui permet de logger les messages du noyau via réseau (UDP). Cela présente les mêmes avantages qu'une console série, c'est-à-dire que c'est bien pratique pour débugguer un noyau sans écran, ou dont le pilote graphique est cassé pour une raison X ou Y. L'avantage supplémentaire est que ça fonctionne sans port série, port qui n'existe plus sur bon nombre de portables ou architectures (PPC, Sparc, ...). Netconsole tente de s'initialiser le plus tôt possible, il fonctionne donc mieux si le pilote de la carte réseau est dans le noyau plutôt qu'en module. Il envoie ensuite tous les messages vers une adresse définie, en UDP sur le port 6666 par défaut. Ainsi, un simple netcat sur la machine de destination suffit pour lire ces messages: `nc -u -l -p 6666`.

Pour utiliser netconsole, il faut d'abord une carte réseau dont le pilote supporte le polling (la plupart le font, sinon il est trivial de l'ajouter). Ensuite il faut ajouter le support netconsole dans le noyau (CONFIG_NETCONSOLE=y, "Devices drivers / Networking support / Network console logging support"). Enfin, il faut ajouter la configuration de netconsole dans la ligne de commande du noyau (ligne 'append' dans le fichier de configuration de Lilo, par exemple), au format suivant :

netconsole=src-port@src-ipaddr/src-if,dst-port@dst-ipaddr/dst-macaddr

Par exemple,
"netconsole=32768@192.168.0.11/eth0,6666@192.168.0.4/08:00:20:76:3C:57" enverra les logs de 192.168.0.11:32768 à 192.168.0.4:6666 en utilisant l'interface eth0.

Il faut prendre en compte le fait que n'importe quelle machine peut envoyer des messages au destinataire ; pour éviter un possible ennui de sécurité il faut par exemple utiliser le firewall sur la machine de destination.

Le résultat sur la machine (192.168.0.11) :
[colin@jack ~]# dmesg
[...]
netconsole: local port 32768
netconsole: local IP 192.168.0.11
netconsole: interface eth0
netconsole: remote port 6666
netconsole: remote IP 192.168.0.4
netconsole: remote ethernet address 08:00:20:76:3c:57
[...]
eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:0a:95:a9:ff:bc PHY ID: 4061e4, addr: 0
eth0: Found BCM5221 PHY
netconsole: device eth0 not up yet, forcing it
eth0: Link is up at 10 Mbps, half-duplex.
eth0: Pause is disabled
netconsole: network logging started
[...]

Et sur la machine destination (192.168.0.4 dans notre cas) :
[colin@paperstreet ~]# nc -u -l -p 6666
Total memory = 640MB; using 2048kB for hash table (at c0400000)
Linux version 2.6.9-rc2 (colin@jack.colino.net) (gcc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r4, propolice)) #5 Wed Sep 29 14:43:14 CEST 2004
[...]

Aller plus loin

  • # Redondant ?

    Posté par  (site web personnel) . Évalué à 5.

    syslogd avait déja la possibilité d'envoyer tous ou certains logs vers une machine..
    Il s'agit ici seulement des logs du kernel ?
    Je ne vois pas ce que cela ajoute à la fonction réseau de syslogd..
    J'ai peut etre raté un épisode ?

    • [^] # Re: Redondant ?

      Posté par  (site web personnel) . Évalué à 10.

      Il s'agit là des messages du noyau (printk). C'est à dire les messages concernant l'initialisation du noyau, avant init, mais aussi les Oopses, et les messages Panic (si ce n'est pas le driver réseau du moins)...
      Syslogd ne loggue pas ce genre de messages...

  • # syslogd

    Posté par  . Évalué à -1.

    Je croyais que syslogd etait capable d'envoyer des logs sur le reseau ?

    Quel est l'interet d'avoir ca dans le noyau si un demon y arrive bien et depuis des lustres ?
    Il doit bien y avoir une raison mais je ne la trouve pas ...

    • [^] # Re: syslogd

      Posté par  . Évalué à 10.

      Je pense que l'interet par rapport a Syslogd est que si la pile IP est morte, le noyau peut toujours envoyer les messages a travers le reseau. Ca permet de recuperer surement plus de messages critiques.


      Netconsole est basee sur l'interface netpoll du noyau qui permet donc d'envoyer des paquets UDP sans passer par la couche IP. Un outil qui s'en sert est LKCD : Linux Kernel Crash Dump, qui permet de recuperer la memoire du noyau sur le reseau lorsque celui-ci plante.

      Voila voila,

      Bonne journee a tous !

      Welty

      • [^] # Re: syslogd

        Posté par  (site web personnel) . Évalué à 0.

        Si la pile ip est morte, je vois pas comment ce truc enverra des messages en udp. S'il intègre sa propre pile ip, c'est pas très intelligent : on se retrouve avec deux implémentations différentes de la pile ip.

  • # y'a pas une erreur?

    Posté par  . Évalué à 5.

    Pour utiliser netcat, il faut d'abord une carte réseau dont le driver supporte le polling (la plupart le font, sinon il est trivial de l'ajouter).

    ca ne serait pas plutot netconsole?

  • # IPv6

    Posté par  . Évalué à 3.

    D'après ce que j'ai pu constater en lisant les sources du noyau, netconsole ne peut envoyer des messages qu'en IPv4. Est-il planifié de pouvoir utiliser IPv6 pour ça?

    • [^] # Re: IPv6

      Posté par  (site web personnel) . Évalué à 4.

      Je sais pas. A première vue il n'y a pas d'équivent à in_aton() pour l'ipv6:
      __u32 in_aton(char*) dans net/ipv4/utils.c convertit une adresse au format ascii ("129.168.0.11") en int.
      Il faudrait d'abord un net/ipv6/utils.c avec
      in6_addr *inv6_aton(char *)

      voir dans inet_pton6() dans le fichier resolv/inet_pton.c de la glibc pour l'algo, il est pas tout simple.

      Le reste a l'air plus trivial:
      -ajouter deux champs in6_addr *local_ipv6, *remote_ipv6 à la structure netpoll (include/linux/netpoll.h)
      -modifier net/core/netpoll.c::netpoll_parse_options() : si "np->local_ip=ntohl(in_aton(cur));" rate (adresse non ipv4), setter np->local_ipv6 grâce à inv6_aton() (attention au byte order aussi).
      -Ensuite en fonction de la non-nullité de np->local_ipv6, l'utiliser en lieu et place de np->local_ip. (changer aussi iph->version et tout ça).
      -Et pareil pour remote_ip/remote_ipv6...

      Bref, un patch qui attend un courageux :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.