Running a UDP Remote Console with Linux 2.6

Bruce Perens writes "Many system admins have learned how to use syslog to log events of remote systems. But when the kernel crashes, its final messages never get to syslog. If you don't have a remote console manager, you won't see them, unless you run netconsole."

Comments

Re: First Post?

[pizza_milkshake]

did you send them via UDP? perhaps your first attempt hasn't made it yet.

Re:Tempting...

[Bruce Perens]

Writing another client daemon would not be a big job. This is at most a 200-line program. No doubt a Perl hacker could do it in one line - but I might lose my lunch from looking at that :-)

Bruce

Re:Huh?

[Bruce Perens]

Well, I've got to say that I switched from the stable 2.4 kernel to the unstable 2.6 one to use netconsole, and so far 2.6 hasn't crashed and I haven't been able to see how far into the panic I'll get the messages. The system is being slashdotted now, maybe that will help.

Bruce

some conditions..

[molo]

This only works/is helpful in certain situations:

1. network driver is initialized
2. kernel messages are what you want to capture
3. the kernel doesn't get itself foobarred so badly that it can't send packets
4. interrupts are enabled (right? can't talk to the network card otherwise)

Also, if you change mac addresses or network cards of the first hop between the sender and receiver, this all needs to be reconfigured.

This can certainly be useful, but recognize its limitations.

-molo

Re:some conditions..

[molo]

Yes, serial console servers are quite useful for remote administration.

Another option might be to build your own - take an older spare machine and stick a PCI USB controller in it and add a bunch of USB-to-serial dongle devices (possibly with a USB hub). These show up as /dev/ttyUSB#.

You can then ssh in and use minicom or whatever. You get added security since many terminal servers don't support ssh, plus you have a fully configurable system to manage stuff. You could write a program to page/email you on certain kernel events for example. It could be pretty flexible if that is what you need.

Just my two cents.

BTW, Bruce, thanks for your contributions to the community and to Debian. We all appreciate it.

-molo

Re:some conditions..

[Paul Jakma]

1. Correct
2. Correct, the purpose of netconsole being to capture kernel messages that otherwise would not be sent due to a hung kernel - all other messages, syslog can take of.
3. Unlikely. If the kernel can panic, it can use netconsole. Used with nmi_watchdog, you can even get a stack trace from a stuck interrupt handler
4. No, netconsole uses polling-mode and drives the nic driver directly.

Note that netconsole can also dump the entire contents of RAM.

Re:Tempting...

[hattmoward]

It looks like the packet format is syslog compatible in the recent 2.6 kernels. I think the work is already done. =)

Re:Tempting...

[hattmoward]

Neither does the syslogd provided with slackware. The snippet below will allow you to inclusively list log hosts.

iptables -A INPUT -s $LOGHOST -p udp --destination-port 514 -j ACCEPT
iptables -A INPUT -p udp --destination-port 514 -j DROP

You can repeat the first line as many times as needed, replacing $LOGHOST with an IP or a resolvable domain name. Just make sure the DROP rule goes last.

For FreeBSDers, try ethercons

[drdink]

If you use FreeBSD and find this interesting, you should take a look at rwatson's ethercons patches. Basically, it is this but supports bidirectional communication. That means you can run a getty on it and login over ethernet console. Rather slick.

Re:Tempting...

[hattmoward]

It may not be as surprising when you note that sysklogd was written in a time where the network was considered more trustworthy, though there is another reason, which is mentioned below. You should also find the syslog-ng package available on your Debian system, which can filter by sending host, although it will spend more CPU time to do the blocking at that level. Both solutions work, though.

The reason you don't see this feature made more prominent is that UDP packets are easily spoofed, since there is no handshake required to get the payload through. With TCP, someone has to be at the "sending" host to reply to the handshake, while UDP simply accepts what it receives in the single packet (barring the sender being a local-net host, with strict ARP checking on the receiver). So anyway, filtering hosts doesn't completely cover you from log spoofing or DOSing, but it's still a good idea.

Re:Same thing as sending syslog to remote loghost?

[drdink]

This is a useful tool for those of us who have a slew of machines on a single network segment and don't want to have an expensive KVM or 47 monitors. The ability to put your consoles over the same wire you put your normal network traffic over is great. It is like those cable companies that also provide phone service over your cable line, sort of...
IRIX isn't the only operating system that does crashdumps. I've found them to be an invaluable tool for debugging FreeBSD. It has supported them for quite a long time. The ability to gdb your kernel and the vm after you reboot and see exactly where things went wrong is great. I still don't understand why Linux lacks this.

Re:Oh I'll see them...

[Bruce Perens]

My console is a 300 baud teletype you insensitive clod!

THERE'S STILL LOTS OF LIFE LEFT IN MY 5-LEVEL BAUDOT MACHINE.

BRUCE