Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Programming Software Linux Technology

Running a UDP Remote Console with Linux 2.6 39

Posted by simoniker from the so-there dept.
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."
This discussion has been archived. No new comments can be posted.

Running a UDP Remote Console with Linux 2.6 More

Running a UDP Remote Console with Linux 2.6

Comments Filter:
  • I've got to say, it looks really tempting. Things don't usually go that far south, but when they do, it's definitely an advantage to have every piece of information you can get. Especially the kernel messages. Unfortunately, until the clietn daemon can be fixed to work with the latest version of netconsole, this is pretty much worthless, because I can imagine few people willing to leave netcat running on a production machine 24-7...

    • Re:Tempting... (Score:4, Funny)

      by Bruce Perens ( 3872 ) <bruce@perens.com> on Monday August 16, 2004 @03:22PM (#9984382) Homepage Journal
      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:Tempting... (Score:5, Informative)

        by hattmoward ( 695554 ) on Monday August 16, 2004 @04:01PM (#9984778)
        It looks like the packet format is syslog compatible in the recent 2.6 kernels. I think the work is already done. =)
        • My syslog daemon (in Debian sarge) doesn't have a switch to tell it what hosts are OK to listen to. It just has a big on-off switch for accepting connections from the network (which seems to mean anything but localhost).

          Bruce

          • Re:Tempting... (Score:4, Informative)

            by hattmoward ( 695554 ) on Monday August 16, 2004 @04:24PM (#9985010)

            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.

            • I posted a comment about this below the article on technocrat, thanks.

              I must confess to being surprised that syslog can't just be told to accept packets only from a list of IPs.

              Bruce

              • Re:Tempting... (Score:5, Interesting)

                by hattmoward ( 695554 ) on Monday August 16, 2004 @04:54PM (#9985282)

                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:Tempting... (Score:3, Interesting)

                  by Bruce Perens ( 3872 )
                  That's a good answer, thanks! I had not thought about the ease of spoofing a UDP packet. I'm actually surprised that so far I am not losing any of them between Texas and California.

                  If I had another machine in the same data center, I'd not be sending UDP over the internet.

                  Thanks

                  Bruce

                • The reason you don't see this feature made more prominent is that UDP packets are easily spoofed

                  I've had good luck with syslog-ng's TCP support. That's what brought me to syslog-ng in the first place.

                  Or is that what you were getting at?

  • some conditions.. (Score:5, Informative)

    by molo ( 94384 ) on Monday August 16, 2004 @03:38PM (#9984569) Journal
    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
    • Yes. I really want a console server. I can't get one without paying a lot more or getting less for what I'm paying.

      Bruce

      • Re:some conditions.. (Score:5, Informative)

        by molo ( 94384 ) on Monday August 16, 2004 @04:10PM (#9984862) Journal
        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
      • Offtopic, but I love your use of when in the article summary :)

    • Re:some conditions.. (Score:5, Informative)

      by Paul Jakma ( 2677 ) on Monday August 16, 2004 @06:03PM (#9985975) Homepage Journal
      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.

      • 3. Ok, seemingly hard lockups are out - but these are more and more uncommon with 2.6 - but nearly everything else is dumpable, unless it screws with the NIC driver itself? I'll have to check out that watchdog, that sounds useful.

        4. Thanks for the info, I'll have to read up on that.

        -molo
        • 3. Ok, seemingly hard lockups are out - but these are more and more uncommon with 2.6 - but nearly everything else is dumpable, unless it screws with the NIC driver itself? I'll have to check out that watchdog, that sounds useful.

          What do you mean by "hard lockups" exactly? NMI cant be disabled AIUI, so unless hardware were hung, there's a good chance you can get a panic.

          --paulj

        • Re:some conditions.. (Score:3, Insightful)

          by emag ( 4640 )
          3. Ok, seemingly hard lockups are out - but these are more and more uncommon with 2.6 - but nearly everything else is dumpable, unless it screws with the NIC driver itself?

          Well, a friend of mine using 2.6 is experiencing random lockups (we suspect either hardware problems, or ghosts), with nothing ever logged. However, he can still ping the machine even after it's locked up, but the console also doesn't respond. I've pointed him at this article, and he's going to try enabling netconsole to see if anythi
          • If he can ping the machine, the kernel is still functional. If he can ssh in, then userspace is still functional and X or the console is locked up.

            Is he using X, a framebuffer console or a standard VGA console? I've had plenty of times where X locked up on me and I wasn't able to recover the video device. This is not uncommon on some hardware. Best bet at that point is to ssh in and reboot.

            If X locks up, there is nothing to be logged. The kernel sees it as just another userspace process.

            -molo
            • X isn't running on that particular system. Existing ssh sessions freeze. New ssh sessions can't be initiated. FWIU, no new TCP sessions can be initiated. No clue if it's framebuffer or VGA console, but apparently C-A-# works to switch consoles, though the rest of the keyboard doesn't respond at all. So like I said, it sounds like some sort of bad hardware, or ghosts. I should also mention this only started happening with 2.6. Under 2.4 it was rock solid.
    • Interrupts are used to *receive* - i.e. they provide the kernel with the notification that *something* happened to the NIC.
  • I really don't see much benefit here. Seems like someone just took syslogd and made it a kernel module. Just one more piece of the kernel to crash. Personally I'd rather keep the kernel as small as possible. Less to go wrong that way.

    While on the topic, though, it would be nice if Linux did something similar to IRIX, where a crash would save the kernel coredump to the swap partition. Yes, I know the Linux Kernel Crash Dump [sourceforge.net] project does this, but they're not exactly stable yet (hell, their website won't even load right now).

  • For FreeBSDers, try ethercons (Score:5, Interesting)

    by drdink ( 77 ) * <smkelly+slashdot@zombie.org> on Monday August 16, 2004 @04:48PM (#9985229) Homepage
    If you use FreeBSD and find this interesting, you should take a look at rwatson's ethercons [watson.org] 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.
  • remote console manager, you won't see them,

    My console is a 300 baud teletype you insensitive clod!

  • SNMP trap? (Score:1, Insightful)

    by professorfalcon ( 713985 )
    Why not just send an SNMP trap?

Slashdot Top Deals

Hackers are just a migratory lifeform with a tropism for computers.

Close