Chris wrote:
> Hi Folks,
>
> I am working with a headless server and I have learned that the
> "telnet" kernel boot parameter solves lots of my problems - but it is
> ugly. If I use "telnet" I have access to the terminfo database in the
> initrd.img and there are relatively few - none seem to display
> character cell graphics that either the Microsoft telnet client on XP
> Pro or an xterm on cygwin can display correctly. There seems to be a
> "linux", "vt100", "vt100-nav" and "xterm". Microsoft only "supports"
> "vt100" from that list. Cygwin, of course, will support all of them,
> but they all display similarly with the accented lowercase characters
> where the lines should be.
>
> I'm thinking I can hack the initrd.img and add a terminal that works,
> but I suspect that the lesser problem is to configure my display so it
> agrees with what is already there. Does anybody know what needs to me
> done so that my telnet client can display the same view that a
> physically connected monitor will display?
>
>
> Chris.
Generally 'ansi' of some sort.

But consider putting up webmin..its a much better way for most remote
management using browser technology. Use telnet for the deep and dirty
stuff.

On Tue, 2008-03-11 at 10:10 -0700, Chris wrote:
> Hi Folks,
>
> I am working with a headless server and I have learned that the
> "telnet" kernel boot parameter solves lots of my problems - but it is
> ugly. If I use "telnet" I have access to the terminfo database in the
> initrd.img and there are relatively few - none seem to display
> character cell graphics that either the Microsoft telnet client on XP
> Pro or an xterm on cygwin can display correctly. There seems to be a
> "linux", "vt100", "vt100-nav" and "xterm". Microsoft only "supports"
> "vt100" from that list. Cygwin, of course, will support all of them,
> but they all display similarly with the accented lowercase characters
> where the lines should be.

Microsoft terminal clients are JUNK. Microsoft has never shown
an interest in things like terminal databases or good emulation.

So... stick with Cywin xterm (if that's the best you can do... or get
a real native terminal emulator).

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

>
> I'm thinking I can hack the initrd.img and add a terminal that works,
> but I suspect that the lesser problem is to configure my display so it
> agrees with what is already there. Does anybody know what needs to me
> done so that my telnet client can display the same view that a
> physically connected monitor will display?
>

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).

>
> Generally 'ansi' of some sort.
>
> But consider putting up webmin..its a much better way for most remote
> management using browser technology. Use telnet for the deep and dirty
> stuff.- Hide quoted text -
>
> - Show quoted text -



"ansi" is not an option. As I said, there seems to be "linux",
"vt100", "vt100-nav" and "xterm". I have not explored webmin yet, but
I have heard of it on several occasions. Can it to headless initial
installs of the operating system? Can it do headless rescue?

Chris wrote:
>> Generally 'ansi' of some sort.
>>
>> But consider putting up webmin..its a much better way for most remote
>> management using browser technology. Use telnet for the deep and dirty
>> stuff.- Hide quoted text -
>>
>> - Show quoted text -
>
>
>
> "ansi" is not an option. As I said, there seems to be "linux",
> "vt100", "vt100-nav" and "xterm". I have not explored webmin yet, but
> I have heard of it on several occasions. Can it to headless initial
> installs of the operating system?

No. Obviously nothing that depends on a network can work until the
network..er..works..some machines will boot via serial ports..on those
we used reverse terminal servers or modems to access them when they were
'miles away'

Plus remote power recycling.

Generally that told us what to pack before we drove to the 'dark office :-)

>Can it do headless rescue?

Possibly, but I use a decent telnet for that. Generally if a machine
won't boot at all, you need to fix its hardware. So you need to be where
it is.



I am not clear as to what does not have an ansi option, your terminal,
or the headless box. If the terminal suggest finding a better emulator.
My debian certainly 'does ansi'

Ansi more or less gives you an 8 bit color 80x25 screen

> 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.

On Mar 11, 11:52 am, The Natural Philosopher wrote:
>
> I am not clear as to what does not have an ansi option, your terminal,
> or the headless box. If the terminal suggest finding a better emulator.
> My debian certainly 'does ansi'
>
> Ansi more or less gives you an 8 bit color 80x25 screen



For clarity, as originally posted: I am working with a headless server
and I have learned that the
"telnet" kernel boot parameter solves lots of my problems.

You could easily conclude that I am talking about booting the system,
but it is not clear that I am talking about booting either the
installation or the rescue environment. Elsewhere in this thread I
posted the isolinux and the grub stanza and that would have helped
clarify things. Your confusion is justified.

If you try this...
mount -o loop /path/to/fedora/dvd/distribution /tmp/iso
mount -o loop /tmp/iso/images/boot.iso /tmp/boot
cp /tmp/boot/initrd.img initrd.img.Z
gunzip initrd.img.Z
mkdir /tmp/initrd
cd /tmp/initrd
cpio -i < initrd.img

You will see that you have the filesystem for the initial ram disk and
in that filesystem is /.../etc/terminfo and in that directory are a
mere four entries -- "linux", "vt100", "vt100-nav", and "xterm" --
none of which seem to be able to express the display in a way that any
of my telnet clients can interpret correctly.

For further clarification, try this - it won't hurt your machine.
Copy the isolinux directory from the distribution media to /boot
directory giving you /boot/isolinux/* and add the grub headless rescue
stanza listed elsewhere to your grub.conf. Reboot. Select the stanza
you just added. You will be stopping long before it has a chance to
actually do anything.

As you watch your console, you will see it report that anaconda is
starting a telnet server and will now wait for instructions from a
telnet client to configure the install/rescue - depending on what you
are doing.

So, telnet into that machine and you will see what I mean. The
display is there and functional, but really ugly and it doesn't seem
to matter which TERM I use. The importance of the filesystem for the
initial dam disk is that the telnet server will throw up its hands and
give up if the telnet client represents itself to be other then the
four I mentioned.

I hope this clears up any confusion and inspires an answer.

Thanks for your help.

Chris.

On 11 Mar, 18:20, Chris Cox wrote:
> On Tue, 2008-03-11 at 10:10 -0700, Chris wrote:
> > Hi Folks,
>
> > I am working with a headless server and I have learned that the
> > "telnet" kernel boot parameter solves lots of my problems - but it is
> > ugly. *If I use "telnet" I have access to the terminfo database in the
> > initrd.img and there are relatively few - none seem to display
> > character cell graphics that either the Microsoft telnet client on XP
> > Pro or an xterm on cygwin can display correctly. *There seems to be a
> > "linux", "vt100", "vt100-nav" and "xterm". *Microsoft only "supports"
> > "vt100" from that list. *Cygwin, of course, will support all of them,
> > but they all display similarly with the accented lowercase characters
> > where the lines should be.
>
> Microsoft terminal clients are JUNK. *Microsoft has never shown
> an interest in things like terminal databases or good emulation.
>
> So... stick with Cywin xterm (if that's the best you can do... or get
> a real native terminal emulator).
>
> I was not aware that the kernel allowed an output to "telnet" console
> type of option. *What option specifically are you using?
>
>
>
> > I'm thinking I can hack the initrd.img and add a terminal that works,
> > but I suspect that the lesser problem is to configure my display so it
> > agrees with what is already there. *Does anybody know what needs to me
> > done so that my telnet client can display the same view that a
> > physically connected monitor will display?
>
> 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).

Or use Putty. I rather like Putty, and find it effective for remote
network and serial communication with Linux terminals.

On Tue, 2008-03-11 at 15:59 -0700, Nico Kadel-Garcia wrote:
....
>
> Or use Putty. I rather like Putty, and find it effective for remote
> network and serial communication with Linux terminals.

I concur. It's not a bad terminal emulator... and it's FREE!!!
(it is what I use most... minicom though if directly connected serial)

On Mar 11, 4:36 pm, Chris Cox wrote:
> Ok.. so you're booting isolinux, not your distro correct?
>
Correct. The telnet kernel parameter probably doesn't have any
semantic meaning when booting the distribution because there are no
decisions necessary until a user logs in. Only during installation
and rescue does this technique have any meaning, unless your
distribution has some sort of really neat console redirection feature
that I don't have or do have but haven't discovered...



> I tried to repeat your situation, but may graphics looked fine,
> but I'll admit I'm coming from a KDE konsole and using ssh intead
> of telnet for my options to my syslinux... and while we're on
> the topic, are you using a particular distribution? If not,
> can you be explicit about what isolinux you are using including
> version? Not saying I'll attempt to fully replicate your
> scenario, but just in case others here might try.
>
I am playing with RedHat Fedora 8, so I agree with you much of what I
am seeing is going to be highly distribution specific and it is
entirely possible and even probable that other distributions have
avoided this ugliness.



> I tested by using SUSE's syslinux-like thing where the
> options are:
> hostip=AAA.BBB.CCC.DDD gateway=WWW.XXX.YYY.ZZZ netmask=255.255.255.0
> usessh=1
>
I may be wrong but I think isolinux and syslinux are two different
animals. Isolinux is used (in the RedHat world) for booting
installation media with the intention of installing, upgrading or
rescuing. Syslinux is used to boot a functional system on a disk
filesystem into execution. I don't know *why* there should be two,
but apparently there are two. It looks to me like your experiment
involved redirecting the console of the running system, which is a
pretty neat feature that I don't think Red Hat supports. Am I wrong?
Was this done from installtion media?

That is to say, what was the state of your experiment when you entered
the above values for the kernel and what ran as a consequence? Was
the state of the experiment "Booting the installation media" or was
the state of the experiment "Booting a boot-loader stanza"? The first
would be a valid observation for my problems and might shed light and
the second would probably not.



> Had no problems bring up yast in character mode with full text
> graphics rendering. But of course, apple vs. orange. Need to
> know more information about the "orange" you have. It actually
> matters quite a bit. I fully believe your scenario can be made
> to work fine using SUSE's syslinux-like thing... but that's
> not what you have.
>
> So.. question:
>
> Your isolinux solution came off of a CD that I ASSUME is
> a Linux distribution, which one (including version)?
>
> I think knowing that might help anyone who tries to recreate
> your problem.



Thanks for taking time to give this question some thought. It is not
earth-shatteringly important and it just seems to me that I should be
able to trivially solve it - and I don't know how! Com'on - we are
talking about telnet which has been around for thirty five years!
This frustrates me!

"Nico Kadel-Garcia" wrote
>On 11 Mar, 18:20, Chris Cox wrote:
>> On Tue, 2008-03-11 at 10:10 -0700, Chris wrote:
>> > Hi Folks,
>>
>> > I am working with a headless server and I have learned that the
>> > "telnet" kernel boot parameter solves lots of my problems - but

>> Microsoft terminal clients are JUNK. Microsoft has never shown
>> an interest in things like terminal databases or good emulation.
>>
>> So... stick with Cywin xterm (if that's the best you can do... or get
>> a real native terminal emulator).

>Or use Putty. I rather like Putty, and find it effective for remote
>network and serial communication with Linux terminals.

I second the PuTTY recommendation. Combined with pscp and psftp it does just
about everything you need. They haven't implemented sshfs yet though.

CC

On Mar 11, 1:10 pm, Chris wrote:
> Hi Folks,
>

>
> I'm thinking I can hack the initrd.img and add a terminal that works,
> but I suspect that the lesser problem is to configure my display so it
> agrees with what is already there. Does anybody know what needs to me
> done so that my telnet client can display the same view that a
> physically connected monitor will display?
>
> Chris.
The easiest way is to buy KVM with IP. After that, you would access
any machine with KVM from any remote machine.