matt@iquery.UUCP (Matt Reedy) (12/08/88)
We have about 15 *nix boxes running a variety of flavors (Sys V/BSD/Xenix).
We'd like to have a single terminal in each programmer's office allowing
connections to any one of these machines (without having to run 15 cables from
each office). I've vaguely heard of something called "terminal servers". Is
this what I'm looking for? Anyone have any info on any brand in particular?
TIA.
matt
--
Matthew Reedy UUCP: {harvard!adelie,gatech!petro}!iquery!matt
Programmed Intelligence Corp.
400 N Loop 1604 E, Suite 330
San Antonio, TX 78232 (512) 490 6684venters@argos.uucp (Jeff Venters) (12/09/88)
In article <147@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: >We have about 15 *nix boxes running a variety of flavors (Sys V/BSD/Xenix). >We'd like to have a single terminal in each programmer's office allowing >connections to any one of these machines (without having to run 15 cables from >each office). I've vaguely heard of something called "terminal servers". Is >this what I'm looking for? Anyone have any info on any brand in particular? > >TIA. > >matt There are several approaches you can take. Here at CONVEX, we use both a switch type and ethernet terminal servers. The switch type requires more cables since you must run one cable for every terminal you intend to support (in all likelyhood it would be located in you computer room). You then run N lines to each host you want to serve. With the ethernet terminal servers you only need run one ethernet connection from each host. The terminal servers can be placed closer to the actual terminals (i.e., less wire). As for the user interface whenever you are not connected, if you type any key, a menu of available hosts is presented. These servers use "rlogin" to login to the host. I have been told by our operations folks that this approach has a much smaller incremental cost per terminal than the switch type server. The ethernet terminal servers we use are made by CISCO (sp?). The switch type is made by MICOM. I will say one good thing for the MICOM server, it has been very reliable. I can only recall it going down once or twice in the last 2 years. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jeff Venters, Convex Computer Corporation, Richardson, Texas Internet: venters@convex.COM | UUCP: {uiucuxc,sun,rice}!convex!venters =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England)) (12/10/88)
In article <147@iquery.UUCP> matt@iquery.UUCP (Matt Reedy) writes: >We have about 15 *nix boxes running a variety of flavors (Sys V/BSD/Xenix). >We'd like to have a single terminal in each programmer's office allowing >connections to any one of these machines (without having to run 15 cables from >each office). I've vaguely heard of something called "terminal servers". Is >this what I'm looking for? Anyone have any info on any brand in particular? > It depends. Do you have serial ports on these machines and no Ethernet? If so, you need a port selector or data pbx. Want to yank the serial ports off and use Ethernet? Then get terminal servers. Otherwise, just hardwire everyone to a machine and use the existing unix utilities to connect to other machines. Option three is cheapest, followed by option one.
DeadHead@cup.portal.com (Bruce M Ong) (12/10/88)
>We have about 15 *nix boxes running a variety of flavors (Sys V/BSD/Xenix). >We'd like to have a single terminal in each programmer's office allowing >connections to any one of these machines (without having to run 15 cables from >each office). I've vaguely heard of something called "terminal servers". Is >this what I'm looking for? Anyone have any info on any brand in particular? > >TIA. > >matt >-- >Matthew Reedy UUCP: {harvard!adelie,gatech!petro}!iquery!matt >Programmed Intelligence Corp. >400 N Loop 1604 E, Suite 330 >San Antonio, TX 78232 (512) 490 6684 I am not sure about the exact details; but you would need to install ethernet first; and you'll need terminal servers which support TCP/IP. Check with Bridge Communications Inc (Now under 3COM), and ask about their CS/1 product line. The phone is 1-800-ASK-3COM I think. deadhead@cup.portal.com
mccalpin@loligo.fsu.edu (John McCalpin) (12/10/88)
At FSU, we have had good luck with the Annex terminal servers from Encore. They have 16 serial ports (non-standard connectors, though), and one parallel printer port. Our box is set up for a thick-wire ethernet transceiver cable. We have had no hardware failures in the 2 years that we have had the box. It does re-boot itself (by grabbing its software from a local Sun) about every two to four weeks -- probably due to a soft parity error in the 1 MB local RAM. The software is pretty good, except that the parallel printer driver does not seem too reliable. Although all the ports are rated at 19,200 baud, the throughput on the higher-numbered ports starts to degrade if more than about 6 users are active at 9600 baud.... This is not noticeable interactively, but kermit file transfers slow down a lot.... John D. McCalpin mccalpin@masig1.ocean.fsu.edu
pavlov@hscfvax.harvard.edu (G.Pavlov) (12/12/88)
In article <12380@cup.portal.com>, DeadHead@cup.portal.com (Bruce M Ong) writes: > ...... and you'll need terminal servers which support TCP/IP. Check with > Bridge Communications Inc (Now under 3COM), and ask about their CS/1 product > line. The phone is 1-800-ASK-3COM I think. I won't pretend to have any real experience with these. But the overall sense of the net, as I interpret it, seems to be that "TCP/IP" and "Bridge" don't mix too well. Encore and Cisco have gotten much more favorable res- ponse. greg pavlov, fstrf, amherst, ny
burzio@mmlai.UUCP (Tony Burzio) (12/13/88)
In article <689@hscfvax.harvard.edu>, pavlov@hscfvax.harvard.edu (G.Pavlov) writes: > I won't pretend to have any real experience with these. But the overall > sense of the net, as I interpret it, seems to be that "TCP/IP" and "Bridge" > don't mix too well. Encore and Cisco have gotten much more favorable res- > ponse. We have a few Bridge servers and they work just fine through TCP. I like the fact that they boot themselves instead of waiting for a host to load software (the base unit has a floppy drive with the programs in it). The only problem we have had is that ULTRIX kind of supports 8 bit mode, and other UNIXs don't. Leave everything 7 bits and you won't have problems. We have experienced no hardware problems in 4 years (knock knock :-) ****************************************************************************** Tony Burzio * To err is human... To catch you at it requires a Martin Marietta Labs * computer... To fix it requires an accountant... ******************************************************************************
wilson@nova.laic.uucp (Robin Wilson) (12/14/88)
I was present at a presentation of the XYPLEX MAXserver line today. They claim to support both TCP and LAT from the same board (and individual serial connection). Also, they had a pretty good layout for management of the terminal servers (at least for my environment). My problem is, that I don't want to believe their presentation (I tend to be pessimistic about a manufacturer's claims) so I need some other input. How 'bout it; anybody heard any horror stories about XYPLEX? R.D. Wilson "My views -- hands off LMSC!"
jqj@oregon.uoregon.edu (J Q Johnson) (12/14/88)
In article <Dec.14.10.40.26.1988.112@ron.rutgers.edu>, ron@ron.rutgers.edu (Ron Natalie) writes: > Both Bridge and Cisco terminal servers will boot either from themselves > (Bridge uses a floppy, cisco uses roms (look ma! no moving parts) or over > the network. It should be noted that Bridge/3Com terminal servers can boot themselves over the network only from a special-purpose boot node (NCS) running XNS (even if you are using a TCP/IP or OSI version of the Bridge t.s.). Furthermore, the boot server must be on the SAME XNS NETWORK, normally the same Ethernet, as the terminal server. In contrast, Cisco and Annex terminal servers can boot themselves from any network node that supports tftp on tcp/ip, even across tcp/ip gateways. This is a very substantial restriction on the Bridge servers in a typical complex internet.
ron@ron.rutgers.edu (Ron Natalie) (12/14/88)
> We have a few Bridge servers and they work just fine through TCP. I like > the fact that they boot themselves instead of waiting for a host to load > software (the base unit has a floppy drive with the programs in it). Both Bridge and Cisco terminal servers will boot either from themselves (Bridge uses a floppy, cisco uses roms (look ma! no moving parts) or over the network. -Ron
prc@maxim.ERBE.SE (Robert Claeson) (12/19/88)
ron@ron.rutgers.edu (Ron Natalie) writes: > > We have a few Bridge servers and they work just fine through TCP. I like > > the fact that they boot themselves instead of waiting for a host to load > > software (the base unit has a floppy drive with the programs in it). > Both Bridge and Cisco terminal servers will boot either from themselves > (Bridge uses a floppy, cisco uses roms (look ma! no moving parts) or over > the network. The Annex terminal servers will boot over the network from either a computer or from another Annex. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
phil@wubios.wustl.edu (J. Philip Miller) (12/20/88)
In article <442@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: rutgers.edu (Ron Natalie) writes: >> Both Bridge and Cisco terminal servers will boot either from themselves >> (Bridge uses a floppy, cisco uses roms (look ma! no moving parts) or over >> the network. > >The Annex terminal servers will boot over the network from either a computer >or from another Annex. and what about the security implications when these devices reboot over the network? What keeps some charlatan from providing an "improved" set of definitions which destroys any secuity constraints which you have carefully provided? Forcing a device to reboot is frequently the easiest threat to execute.
burzio@mmlai.UUCP (Tony Burzio) (12/20/88)
In article <280@wubios.wustl.edu>, phil@wubios.wustl.edu (J. Philip Miller) writes: > and what about the security implications when these devices reboot over the > network? What keeps some charlatan from providing an "improved" set of > definitions which destroys any secuity constraints which you have carefully > provided? Forcing a device to reboot is frequently the easiest threat to > execute. There is no such thing as security and networks. There are enough holes in UNIX that you should not worry about this little one... ********************************************************************* Tony Burzio * TriDECaphobia: The fear of being burned Martin Marietta Labs * by buying DEC junk a fourth time... mmlai!burzio@uunet.uu.net * *********************************************************************
scarter@caip.rutgers.edu (Stephen M. Carter) (12/21/88)
>> Both Bridge and Cisco terminal servers will boot either from themselves >> (Bridge uses a floppy, cisco uses roms (look ma! no moving parts) or over >> the network. >and what about the security implications when these devices reboot over the >network? [....] Almost anything can be broken into. Given my sad all-night experiences of updating a handload of Bridge CS-100 floppies, plus the fact that a terminal server is not very high on a hacker's hit list, I'll prefer the network load (from my choice of unix boxes too, thank you--not a special, add-on, expensive boot device, aka server-server). Two more points: 1) In Cisco's product, one could purchase the optional NV memory board for the configuration information and use the prom to boot. This still leaves the option of a controlled mass configuration update via the network and leave the network access off at other times for the security minded people. 2) In Bridge's case, you are mistaken if you think you have a secure system by having the floppy. A rather trivial 20 line program can get you Global access on any Bridge on the network (even through gateways). Stephen Carter CAIP Center, Rutgers University
prc@maxim.ERBE.SE (Robert Claeson) (12/22/88)
In article <280@wubios.wustl.edu>, phil@wubios.wustl.edu (J. Philip Miller) writes: > In article <442@maxim.ERBE.SE> prc@maxim.ERBE.SE (Robert Claeson) writes: > >The Annex terminal servers will boot over the network from either a computer > >or from another Annex. > and what about the security implications when these devices reboot over the > network? What keeps some charlatan from providing an "improved" set of > definitions which destroys any secuity constraints which you have carefully > provided? Forcing a device to reboot is frequently the easiest threat to > execute. Well... You can - tell the box to boot from a specific server by default. - set a password so you can't reconfigure it without knowing the password, neither from the network nor from the Annex. - disable any commands you don't want someone to see. - enable the ACP (Access Control Protocol). - enable the logging facilities. - etc, etc. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
prc@maxim.ERBE.SE (Robert Claeson) (12/22/88)
In article <444@maxim.ERBE.SE>, prc@maxim.ERBE.SE (Robert Claeson) writes: > In article <280@wubios.wustl.edu>, phil@wubios.wustl.edu (J. Philip Miller) writes: > Well... You can > > - tell the box to boot from a specific server by default. > > - set a password so you can't reconfigure it without knowing the > password, neither from the network nor from the Annex. Oh, forgot to mention that the configuration is stored in an EEPROM in the Annex. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden "No problems." -- Alf Tel: +46 758-202 50 EUnet: rclaeson@ERBE.SE uucp: uunet!erbe.se!rclaeson Fax: +46 758-197 20 Internet: rclaeson@ERBE.SE BITNET: rclaeson@ERBE.SE
sob@watson.bcm.tmc.edu (Stan Barber) (12/28/88)
In article <109@oregon.uoregon.edu> jqj@oregon.uoregon.edu (J Q Johnson) writes: >It should be noted that Bridge/3Com terminal servers can boot themselves >over the network only from a special-purpose boot node (NCS) running XNS >(even if you are using a TCP/IP or OSI version of the Bridge t.s.). This is incorrect. The NCS does NOT run XNS. I have an NCS/AT that runs TCP/IP just fine, thank you. >Furthermore, the boot server must be on the SAME XNS NETWORK, normally >the same Ethernet, as the terminal server. The must be on the same ETHERNET, not the same XNS network. If you have a large network that uses bridges or bridging routers, it all works. >This is a very substantial restriction on the Bridge servers in a typical >complex internet. I agree that the 3Com/Bridge boot system is not the best, but let's try to argue from accurate information. Stan internet: sob@bcm.tmc.edu Baylor College of Medicine Olan uucp: {rice,killer,hoptoad}!academ!sob Barber Opinions expressed are only mine.
jqj@oregon.uoregon.edu (J Q Johnson) (12/28/88)
In <1357@gazette.bcm.tmc.edu>, sob@watson.bcm.tmc.edu (Stan Barber) replies: >>It should be noted that Bridge/3Com terminal servers can boot themselves >>over the network only from a special-purpose boot node (NCS) running XNS >>(even if you are using a TCP/IP or OSI version of the Bridge t.s.). > This is incorrect. The NCS does NOT run XNS. I have an NCS/AT that runs > TCP/IP just fine, thank you. Interesting. My CS200s (software v 20000) use UDP/IP for everything *except* booting. For booting, they send out XNS IDP packets with network number 0. What version are you running? >>Furthermore, the boot server must be on the SAME XNS NETWORK, normally >>the same Ethernet, as the terminal server. > The must be on the same ETHERNET, not the same XNS network. If you have > a large network that uses bridges or bridging routers, it all works. I stand by my phrasing. They must be on the same XNS network as defined by a this-net (net 0) IDP broadcast. Agreed that this network may contain several segments, and hence need not be "the same ETHERNET". The important thing is that it may not be an XNS internet -- a Hybridge is OK, but not an XNS router. > I agree that the 3Com/Bridge boot system is not the best, but let's try to > argue from accurate information. Agreed. Other problems with the 3Com/Bridge design: the bootstrap process (which uses XNS) does not appear to be able to cope well with lossy networks; the "remote" network management protocol (which uses UDP/IP) has effectively no security except obscurity of the protocol.
sob@watson.bcm.tmc.edu (Stan Barber) (12/29/88)
After some private mail on this issue, I am rereplying: ]In article <109@oregon.uoregon.edu> jqj@oregon.uoregon.edu (J Q Johnson) writes: ]>It should be noted that Bridge/3Com terminal servers can boot themselves ]>over the network only from a special-purpose boot node (NCS) running XNS ]>(even if you are using a TCP/IP or OSI version of the Bridge t.s.). ]This is incorrect. The NCS does NOT run XNS. I have an NCS/AT that runs ]TCP/IP just fine, thank you. The NCS/AT runs TCP/IP most of the time. XNS is used to boot only. ]>Furthermore, the boot server must be on the SAME XNS NETWORK, normally ]>the same Ethernet, as the terminal server. ]The must be on the same ETHERNET, not the same XNS network. If you have ]a large network that uses bridges or bridging routers, it all works. XNS is defined but not supported consistantly by all vendors. 3com XNS and Bridge XNS and Xerox XNS do not interoperate well. It is the case that Proteon's and cisco's XNS support may not support all these different forms of the protocol. (I know that Proteon only claims to support the XNS used by Novell.) So, we are both probably correct. >This is a very substantial restriction on the Bridge servers in a typical >complex internet. ]I agree that the 3Com/Bridge boot system is not the best, but let's try to ]argue from accurate information. Anyone want to contribute to the accurate information pool, please do. Stan internet: sob@bcm.tmc.edu Baylor College of Medicine Olan uucp: {rice,killer,hoptoad}!academ!sob Barber Opinions expressed are only mine.