russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (12/17/90)
We are running an SGI 4D/240s with Irix 3.3.1. Recently the default terminal type for telnet logins changed from vt220 to wyse-50 and this has screwed up accounts who invoke tcsh as their login shell. (tcsh uses the terminal type to recognise cursor keys and other terminal features.) It would appear that tcsh uses the value of TERM that was set when it was invoked and ignores changes to TERM thereafter ( as in the .login file) After a bit of hunting through man entries I find that login sets the TERM variable from its environment. login is invoked by telnetd which will set the TERM variable from information supplied by the client. The terminal emulator we use (Based on ncsa telnet) does not set the terminal type. (This is to be fixed soon!) In the mean time I need a way of telling telnetd what the default terminal type to use. Can anybody Help!! Cheers, Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand. <rj_fulton@aukuni.ac.nz>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (12/18/90)
In article <1990Dec17.034330.27909@ccu1.aukuni.ac.nz>, russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >... > In the mean time I need a way of telling telnetd what the default terminal > type to use. "tset" might be useful, as in "eval `tset -s -Q`" somewhere in a .login file. The shipped /.login contains an example. Notice that /etc/ttytypes can contain "ttyq*" just as easily as "ttyd*". Tset(1) descripes solutions to what sounds like the problem at hand. Vernon Schryver, vjs@sgi.com
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (12/18/90)
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >We are running an SGI 4D/240s with Irix 3.3.1. >Recently the default terminal type for telnet logins changed from vt220 to >wyse-50 and this has screwed up accounts who invoke tcsh as their login >shell. (tcsh uses the terminal type to recognise cursor keys and other >terminal features.) It would appear that tcsh uses the value of TERM that >was set when it was invoked and ignores changes to TERM thereafter ( as in the >.login file) >After a bit of hunting through man entries I find that login sets the TERM >variable from its environment. login is invoked by telnetd which will set the >TERM variable from information supplied by the client. The terminal emulator >we use (Based on ncsa telnet) does not set the terminal type. (This is to >be fixed soon!) With the help of several people, particularly Dave Olson of SGI I have figured out what happened. Dave was able to supply the crucial information that telnetd does not set TERM if negotiations with the client fail to produce a terminal type. From this I concluded that TERM must be already set for the telnetd process. This could only happen if it was inherited from the parent process (inetd). Thus inetd must have TERM set! Somebody must have started inetd from a terminal. A quick check verified that this was the case. We had had some problems with logins and the operators had stopped and restarted inetd from the system console (which was a wyse-50) and all network logins thereafter came in as wyse-50s. The moral of the story would appear to be Don't restart inetd from a terminal unless it is absolutely unavoidable. This probably applies to other daemons as well. If you do have to, then a boot of the system should be scheduled asap. Thanks again to all who responded. I had better ring the local SGI people to let them know that we have fixed the problem! Cheers, Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand. <rj_fulton@aukuni.ac.nz>
barmar@think.com (Barry Margolin) (12/18/90)
In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >Dave was able to supply the crucial information that telnetd does not set >TERM if negotiations with the client fail to produce a terminal type. >From this I concluded that TERM must be already set for the telnetd process. The 4.3bsd telnetd doesn't have this problem. If it is unable to negotiate the terminal type, it doesn't supply the "-p" (preserve environment) option to /bin/login. And when it does negotiate the terminal type, it sets the environment that is inherited by /bin/login to only contain the TERM variable. I suggest you ask your vendor to adopt this strategy. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (12/18/90)
In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: > The moral of the story would appear to be Don't restart inetd from a terminal > unless it is absolutely unavoidable. This probably applies to other daemons > as well. No. The moral is that you should properly set up the environment of daemons you start. ---Dan
bhoughto@pima.intel.com (Blair P. Houghton) (12/19/90)
In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >The moral of the story would appear to be Don't restart >inetd from a terminal unless it is absolutely unavoidable. >This probably applies to other daemons as well. If you do >have to, then a boot of the system should be scheduled asap. You could unset/unsetenv TERM before starting that daemon, though yes, there could be other lurking environment hooks for this and other daemons. --Blair "setenv VACATION Christmas"
olson@anchor.esd.sgi.com (Dave Olson) (12/20/90)
In <1990Dec18.074044.13043@Think.COM> barmar@think.com (Barry Margolin) writes: | In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: | >Dave was able to supply the crucial information that telnetd does not set | >TERM if negotiations with the client fail to produce a terminal type. | >From this I concluded that TERM must be already set for the telnetd process. | | The 4.3bsd telnetd doesn't have this problem. If it is unable to negotiate | the terminal type, it doesn't supply the "-p" (preserve environment) option | to /bin/login. And when it does negotiate the terminal type, it sets the | environment that is inherited by /bin/login to only contain the TERM | variable. | | I suggest you ask your vendor to adopt this strategy. This is exactly how it works. However, if TERM isn't passed in to login by telnetd, AND TERM is already set in the environment, then login will use the value already in the environment, which in this case was inherited down the chain from the operator's shell -> inetd -> telnetd -> login. -- Dave Olson Life would be so much easier if we could just look at the source code.
russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (12/20/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: >> The moral of the story would appear to be Don't restart inetd from a terminal >> unless it is absolutely unavoidable. This probably applies to other daemons >> as well. >No. The moral is that you should properly set up the environment of >daemons you start. >---Dan OK, I add the proviso: "Unless you know exactly what you are doing." In a lot of cases now Unix systems are being administered by people who do not have an encyclopedic knowledge of Unix. We have only had our system for a year and are still finding out the finer points of its management. Cheers, Russell. -- Russell Fulton, Computer Center, University of Auckland, New Zealand. <rj_fulton@aukuni.ac.nz>
john@IASTATE.EDU (Hascall John Paul) (01/02/91)
In article <1990Dec19.181235.4193@odin.corp.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes: > In <1990Dec18.074044.13043@Think.COM> barmar@think.com (Barry Margolin) writes: > > | In article <1990Dec18.041334.7498@ccu1.aukuni.ac.nz> russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) writes: > | The 4.3bsd telnetd doesn't have this problem. If it is unable to negotiate > | the terminal type, it doesn't supply the "-p" (preserve environment) option > | to /bin/login. And when it does negotiate the terminal type, it sets the > | environment that is inherited by /bin/login to only contain the TERM > | variable. > | > | I suggest you ask your vendor to adopt this strategy. > > This is exactly how it works. However, if TERM isn't passed in to login > by telnetd, AND TERM is already set in the environment, then login will > use the value already in the environment, which in this case was inherited > down the chain from the operator's shell -> inetd -> telnetd -> login. They are not (as described above) exactly the same. Under BSD if telnetd cannot get a value for TERM from the other end, there is no TERM in login's environment (even if there is a TERM in telnetd's environment). -- John Hascall An ill-chosen word is the fool's messenger. Project Vincent Iowa State University Computation Center john@iastate.edu Ames, IA 50010 (515) 294-9551
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/02/91)
In article <1991Jan1.104335@IASTATE.EDU>, john@IASTATE.EDU (Hascall John Paul) writes: > ... They are not (as described above) exactly the same. Under BSD ... To clear up any confusion among readers of the preceding thread, IRIX 3.3 telnet and telnetd are very 4.3BSD-Tahoe-ish. The modest source differences are related to implementation details of things like PTY's and SV signals. The IRIS 4D has always had 4.3BSD networking, with a slavish but enthusiastic attitude toward BSD purity and 4.3 "diffability." I'm one of the slaves. Vernon Schryver, vjs@sgi.com
arc@kaibab.wpd.sgi.com (Andrew Cherenson) (01/04/91)
In article <79506@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: >In article <1991Jan1.104335@IASTATE.EDU>, john@IASTATE.EDU (Hascall John Paul) writes: >> ... They are not (as described above) exactly the same. Under BSD ... > >To clear up any confusion among readers of the preceding thread, IRIX 3.3 >telnet and telnetd are very 4.3BSD-Tahoe-ish. The modest source >differences are related to implementation details of things like PTY's and >SV signals. The IRIS 4D has always had 4.3BSD networking, with a slavish >but enthusiastic attitude toward BSD purity and 4.3 "diffability." I'm one >of the slaves. > > >Vernon Schryver, vjs@sgi.com To be precise, the IRIX 3.3 telnetd is based on the 4.3BSD "networking release" version and the telnet command is Dave Borman's March 1990 version.
deraadt@cpsc.ucalgary.ca (deraadt) (01/04/91)
In article <79769@sgi.sgi.com> arc@kaibab.wpd.sgi.com writes: > In article <79506@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com writes: > >In article <1991Jan1.104335@IASTATE.EDU>, john@IASTATE.EDU writes: > >> ... They are not (as described above) exactly the same. Under BSD ... > > > >To clear up any confusion among readers of the preceding thread, IRIX 3.3 > >telnet and telnetd are very 4.3BSD-Tahoe-ish. The modest source > >differences are related to implementation details of things like PTY's and > >SV signals. The IRIS 4D has always had 4.3BSD networking, with a slavish > >but enthusiastic attitude toward BSD purity and 4.3 "diffability." I'm one > >of the slaves. > To be precise, the IRIX 3.3 telnetd is based on the > 4.3BSD "networking release" version and the telnet command > is Dave Borman's March 1990 version. I thought that the original discussion was that login does not support the -h flag, and that a telnetd started with a $TERM set would result in login and telnetd providing telnetd's $TERM in the case when the correct $TERM could not be determined. I have no doubts that telnetd is 4.3 based. I would not want to write telnetd from scratch and get all the nitty gritty details right (aside: I prefer the simplicity and power of a real rlogin). But SGI's login certainly does not appear to be derived from a BSD login source of any kind. Boy, did I ever find that out when I tried to write my own login for the iris's. By the way, if anyone has a source to a login which works well on the iris, I would *love* to get a copy. We need to insert a permissions library call in the middle of login to determine if the person trying to login is allowed on, based on his login name, tty, and groups.. managed through a YP map called permissions.. Anyways, I'll be posting that library soon. <tdr. SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt Is it a typo? Should the '_' be an 's'?? :-) | deraadt@cpsc.ucalgary.ca -- SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt Is it a typo? Should the '_' be an 's'?? :-) | deraadt@cpsc.ucalgary.ca
deraadt@cpsc.ucalgary.ca (deraadt) (01/05/91)
In article <DERAADT.91Jan4074542@fsa.cpsc.ucalgary.ca> I write: > I thought that the original discussion was that login does not support the > -h flag, and that a telnetd started with a $TERM set would result in login > and telnetd providing telnetd's $TERM in the case when the correct $TERM > could not be determined. Whoops. Mess up. I mean -p. Ie., when telnetd starts login, it is not to provide the -p flag, and the result is that login is supposed to discard the previous environment and build an environment completely anew. Getty, on the other hand, does supply -p, because getty builds part of the environment, and login is supposed to just suppliment it. Oh well. I think I'm getting religous about a BSDism in a system V group. I should run for cover. <tdr. -- SunOS 4.0.3: /usr/include/vm/as.h, Line 44 | Theo de Raadt Is it a typo? Should the '_' be an 's'?? :-) | deraadt@cpsc.ucalgary.ca