Re: Headless fun



I was not aware that the kernel allowed an output to "telnet" console
type of option. What option specifically are you using?

You will not understand the grub.conf without this brief explanation:
I mounted the installation .iso and I looked in /images where I found
boot.iso. I mounted that and I found /isolinux. I copied the
contents of that directory to my /boot directory for my running system
to create a /boot/isolinux directory that was a copy of the
installation media. Now you will understand the grub paths.


The stanza of isolinux.cfg that implements this looks like this:

label hlinux
menu label Install or upgrade an existing system (headless)
menu default
kernel vmlinuz
append initrd=initrd.img headless lang=us keymap=us telnet vnc
vncpassword=install ip=dhcp
label hrescue
menu label Rescue installed system (headless)
kernel vmlinuz
append initrd=initrd.img rescue headless telnet



The stanza of grub.conf that implements this looks like this:

title Install or upgrade an existing Headless system
root (hd0,0)
kernel /isolinux/vmlinuz headless lang=us keymap=us telnet vnc
vncpassword=install ip=dhcp
initrd /isolinux/initrd.img
title Rescue installed Headless system
root (hd0,0)
kernel /isolinux/vmlinuz rescue telnet
initrd /isolinux/initrd.img





I recommend outputting the console serially. Then if you want
your console(s) available from anywhere get a serial console device
(e.g. Avocent/Cyclades ACS) box. That's what we use for
"headless" (really that's NOT headless in the true sense) console
access.

Good server boxes will have a BIOS setting to redirect the startup
and BIOS out the serial port as well, allowing interaction with
BIOS settings, etc.

Vendors like DELL and HP have "lights out" style offerings that
basically give you a KVM over the network for the console. That's
another (expensive potentially) option. I don't like that option
though.

I prefer the serial solution in that it works for many devices
(most *ix boxes, switches, routers, SAN, etc).

Thank you for your observations and recommendations. I don't want to
be harsh to someone that has stopped to offer me help, but I do want
to improve the quality of the help I give and I get. Please interpret
my criticism as an opportunity to improve.

You completely ignore the question I asked, which is simply one of
terminal emulation and not one of headless management. You in effect
tell me that I am asking the wrong question. You recommend that I do
something differently, but you don't appear to understand enough about
what I am doing to make that recommendation. Your recommendations
tell me about feature and solutions that are not part of this
project. I prefer my solution because it works with ALL boxes.

Please notice that I answered your question without telling you why it
is the wrong question, and if I have not answered it completely, then
please tell me. I will certainly not be critical of any questions you
ask for clarification, since these questions indicate to me how to
improve my explanations and I see that as a good thing.

The more people we have doing things the way I like to do them the
more likely it is that the future will continue the way I want.
.



Relevant Pages