Articles précédents : Articles
- [20] Opquast : sortie de la version 1.0
- [11] La Banquise : moteur de recherche libre sur le libre
- [169] Portable à 1 euro par jour : aussi sous GNU/LINUX
- [64] UFC-Que choisir déplore le manque d'interopérabilité dans la musique en ligne
- [17] Vulnérabilité via des formats d'images : Windows - GNU/Linux
- [37] Le marché des logiciels libres est arrivé à pleine maturité
- [48] Mairie de Paris : une contre-offensive libre ?
- [82] Microsoft face aux logiciels libres
- [86] Wikipedia dépasse le seuil du million d'articles
- [13] Les brevets épinglés dans la presse
Articles : Netconsole, log de messages noyaux via UDP
Posté par Colin Leroy (page perso, ). Modéré le 29 septembre 2004.
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, ...).
![[en]](../../../images/en.png)
La documentation de netconsole (682 clics)
> Lire la suite (10 commentaires, moyenne: 4,1). [dépêche : 2221 caractères]
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
[...]
Redondant ?
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 Colin Leroy (page perso, ) le 30/09/2004 à 07:13. (lien). É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
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 welty () le 30/09/2004 à 07:04. (lien). É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 yoho (page perso, ) le 01/10/2004 à 14:38. (lien). É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.
-
[^]Re: syslogd
Posté par yoho (page perso, ) le 05/10/2004 à 11:29. (lien). Évalué à 1.Bah pourquoi je suis moinssé ? C'est faux ?
-
-
y'a pas une erreur?
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?
-
[^]Re: y'a pas une erreur?
IPv6
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 Colin Leroy (page perso, ) le 30/09/2004 à 14:06. (lien). É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 :)
Cette page a été générée par Templeet en 0.1164s (dont 0.0477 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.