I'm so sorry it's taken me so long to do this summary -- I've been out
of town for a couple of weeks and a bit out of touch. I'm going to
attempt a concise summary but with all the responses -- over 3,000
lines! -- it's quite a chore.
Thanks to all below who responded. I'll post my original message
below these names and my summary below that.
Those who responded:
Stephen Harris <sweh@mpn.com>
"David J. Knight" <knight@atmos.albany.edu>
Erwin Fritz <efritz@glja.com>
"Brian E.W. Wood" <beww@intac.com>
Sanjay Patel <patesa@aur.alcatel.com>
Mark Henderson <mch@squirrel.com>
Aaron Lafferty <lafferty@oar.net>
Matthew Kelly <matt@hwcn.org>
Casper Dik <casper@holland.Sun.COM>
"Moore, William" <WMoore@dpsciences.com>
Danny Johnson <djohnson@nbserv2.dseg.ti.com>
Eugene Kramer <eugene@uniteq.com>
Rick Reineman <rick@lunger.llnl.gov>
Rich Kulawiec <rsk@gsp.org>
Reto Lichtensteiger <rali@meitca.com>
Frank Cusack <fcusack@voicenet.com>
David Beard <beard@abel.maths.adelaide.edu.au>
Aleksandar Milivojevic <alex@srce.hr>
Simon Convey <simon@iway.nl>
"Birger A. Wathne" <birger@Vest.Sdata.No>
Pablo Trincavelli <pablot@bancobisel.com.ar>
Tom E Smith <tesmit1@tessa.monsanto.com>
David Thorburn-Gundlach <david@bae.uga.edu>
James Kwong <kwong@solar.acast.nova.edu>
"Michael R. Zika" <zika@glacier.llnl.gov>
Benjamin Cline <benji@hnt.com>
"Peter L. Berghold" <berghold@tcg.com>
David Wolfskill <david@xtend.net>
"Stafford A. Rau" <srau@nortom.com>
"chris.oxenreider" <oxen1chr@dot.state.mn.us>
Gregory M Polanski <greg_polanski@adc.com>
Joseph S D Yao <jsdy@tux.org>
Chris Marble <cmarble@orion.ac.hmc.edu>
Nicholas Masika <masika@best.com>
Fred Vegliante <ftv@xylogics.com>
Janet Hoo <Janet.Hoo@Ebay.Sun.COM>
Alan Hodgkinson <alan@olsen.ch>
Original Post:
We are installing a couple of Ultra 1 boxes for a client and these
servers will be used for firewalls.
The vendor (who sold us the Suns) did not ship them with monitor/keyboard
or a video adapter and, upon investigating within our company, I was told
that we were not going to have a direct-connected console on these
systems. (This was decided before I came onto the project and is being
done to save the client money.)
The rationale is that the firewall will be administered from the sys
admin's desktop -- via TCP/IP -- and that anything that needs to be done
on a console level will be done via a terminal server setup on the sys
admin's desktop PC.
My question: Is this a bad idea?
I've always thought that it would be madness to not have a console on the
server itself because of the bad times -- system crashes, hardware
problems, etc... -- when you really need to be on the console. People
who *appear* to know more about this than me are claiming that this is no
problem and that the terminal server setup allows you to see and do
everything that would be done on a console -- including eeprom stuff,
boot messages, etc....
This all makes me kind of squeamish. Especially with the current
configuration, where there isn't even an adapter in the systems. (We're
loaning them an adapter to do the initial setup.) What if something
happens to the sys admin's workstation and it can't fulfill the
terminal-server function?
Thanks for any advice -- especially that based on experience. I don't
want to be a roadblock here based on my ignorance of how remote terminal
servers work, but I also don't want to give a client bad advice that may
lead to problems some day.
Many thanks in advance.
Bob Geiger
rgeiger@netcom.com
Summary:
Almost everyone said that not having consoles -- or even a keyboard/monitor
switch on each server should be no problem. The consensus seems to be that
not having 'heads' (consoles) on servers is a good idea. You save
the cost of the graphics card and monitor (which generally is never
used) and can remotely administer the machines, even right down to
the boot prompt level. This can be REAL useful for remote maintenance
especially at night when you don't want to go back into the office!
All you need to do is a have connection to the system's serial port and
to remove the keyboard. The Sun machines will boot with all console
traffic going through the serial port. TCP/IP-only access to a server,
in my opinion, isn't good enough. You will need access to the console
via a serial port. One day a machine will hang, you won't be able
to connect to the machine via TCP/IP and you'll have to do a stop-a
style reset.
What you connect to the serial port is another matter. In a computer
room it's nice to connect all your headless server's serial ports
to a terminal server. This can give console access to all servers
to anyone with the appropriate permissions on the network. Cheaper
solutions could be a PC with a bunch of serial ports (if you trust it)
or a terminal with a serial switch-box connection to each server.
Some terminal servers, in addition to providing access to a serial
line, also provide PPP connectivity via modems. This can be useful
too for remote maintenance.
Possible problems to look out for:
reboot the term server may send a BREAK on the serial line, causing
the Sun to drop into PROM mode
any console output that is not logged in /var/adm/messages is lost
Have a VT-220 console with keyboard standing by just in case!
when terminal server reboots/resets it can send a break signal
to the server, which will switch the server into a bootprom
mode. The machine is dead for the network.
Be very cautious about administering a firewall remotely
Remember that the "serial" equiv. of L1-A is "BREAK".
That's the summary... Let me know if you have any questions
Regards,
Bob
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:29 CDT