home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / linux / 10235 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.2 KB

  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!rutgers!igor.rutgers.edu!athos.rutgers.edu!hedrick
  2. From: hedrick@athos.rutgers.edu (Charles Hedrick)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: SLIP and X386
  5. Message-ID: <Sep.8.22.24.55.1992.9151@athos.rutgers.edu>
  6. Date: 9 Sep 92 02:24:56 GMT
  7. References: <55pnpxd.genie@netcom.com> <1992Sep8.151235.3292@uwm.edu>
  8. Organization: Rutgers Univ., New Brunswick, N.J.
  9. Lines: 49
  10.  
  11. rick@ee.uwm.edu (Rick Miller) writes:
  12.  
  13. >Like I said, ka9q was *made* to use a serial line.  However, it doesn't
  14. >provide connections for other applications.  ka9q is *not* a service.
  15. >It's an application which *mimics* the performance of telnet and ftp
  16. >(which use the TCP/IP service), but does all the protocol itself.
  17.  
  18. >If you "telnet using ka9q", you're really "ka9q'ing in telnet mode".
  19. >Get it?  The 'real' telnet program (which makes TCP/IP-related system-
  20. >calls to the kernel) wasn't even used.
  21.  
  22. Telnet is a protocol, like IP or TCP.  Any program that implements the
  23. protocol is a "real" telnet program.  KA9Q implements it, so it's a
  24. real telnet program.  (In fact, it handles several telnet options more
  25. cleanly than a stock Sun.  When used with a current telnet server on
  26. the other end, the telnet implmentation in Linux KA9Q will allow ^S
  27. and ^Q to take effect immediately, and ^C or ^O will stop output
  28. immediately.  There is also an easy way to send the telnet special
  29. characters.  None of these things is true with the normal SunOS
  30. telnet.)  It is different than what you're used to on the Sun, because
  31. telnet, ftp, and various other things are done in as a single program,
  32. together with the basic IP and TCP processing, rather than as separate
  33. utilities.  This does have its limitations (e.g. not letting more than
  34. one user use IP over a given serial line), but there's nothing unreal
  35. about it.
  36.  
  37. The architecture of KA9Q actually does allow it to be used as a
  38. server.  I've seen a version that would support separate application
  39. programs such as telnet and FTP.  (Indeed someone claimed to have
  40. patches for the Linux KA9Q to do this, but didn't actually send them
  41. to me.)  I envisioned KA9Q's use on Linux as temporary, until a kernel
  42. implementation could be done.  So I didn't port the general server
  43. support.  However I have put X server support in.
  44.  
  45. >The same way, 'xhost' needs kernel TCP/IP.  It cannot use the ka9q package,
  46. >because ka9q is suited only to serving a single USER, not other processes.
  47.  
  48. I'm not sure how technically you mean xhost.  If you mean the ability
  49. to talk to X from another host, this will work.  Do "start x" in KA9Q.
  50. If you mean the xhost program, xhost is a utility that lets you limit
  51. what hosts X will talk to.  I haven't put that into KA9Q yet, because
  52. I wasn't sure it would be worth the time.  Since several people seem
  53. to find X support in KA9Q at least marginally useful, I'll probably do
  54. it.  However xhost really is a terrible way to do your X security.
  55. .Xauthority is a better approach.  I haven't tried it under Linux, but
  56. if the server was built with it, I see no reason why it wouldn't work
  57. through KA9Q.  (You'd need to build a copy of xauth, of course, and
  58. then FTP your .Xauthority file to the other end before opening your
  59. first X connection.)
  60.