home *** CD-ROM | disk | FTP | other *** search
/ Il CD di internet / CD.iso / SOURCE / A / GETTY / _GETTY.TAR / usr / doc / getty_ps / README.linux < prev   
Encoding:
Text File  |  1994-05-18  |  11.8 KB  |  266 lines
  1.  
  2. GETTY_PS 2.0.7d for Linux 1.0 and higher
  3. ----------------------------------------
  4.  
  5.  
  6. OVERVIEW
  7.  
  8. This is my third major release of getty_ps for Linux.  It is intended
  9. for Linux kernels at version 1.0 or higher (although it should function
  10. correctly on 0.99.15 kernels as well).
  11.  
  12. There are many modifications to the source.  Some changes in the
  13. serial drivers prompted this release.  vhangup() is handled correctly
  14. now.  Also, thanks to Ted's new serial drivers, monitoring for other 
  15. processes that have possibly messed up the line is much easier now.
  16.  
  17. The following bugs have been fixed:
  18.  
  19.     * SCHED is cleaned up and now handles timezones and
  20.       daylight savings time correctly
  21.     * utmp logging should work correctly now, regardless of
  22.       which init program is being used
  23.     * RINGBACK has slightly more sane default parameters
  24.  
  25. The following features have been added:
  26.  
  27.     * error and debug logging are handled with syslog by
  28.       default (you can still log to a file if you must)
  29.     * users of ifmail (fidonet) should be able to run ifmail
  30.       without patching the getty source
  31.     * debugging and error output is more verbose and easier
  32.       to understand
  33.  
  34. This release is intended as a maintenance release only.  The next
  35. version of this package will be quite a bit different in most 
  36. aspects.  There are some useful features coming up (such as fax-
  37. receive and call-back).  
  38.  
  39. If you have any problems setting up the package, questions about mod-
  40. ifications, or suggestions for additional features, feel free to mail 
  41. me.  I am more than happy to help out.  When you mail me with problem
  42. reports, please be sure to include full debugging output from getty
  43. that illustrates the problem; I am pretty much helpless without it.
  44.  
  45. As always, I would love to hear any bug reports.
  46.  
  47. Kris Gleason
  48. gleasokr@boulder.colorado.edu
  49.  
  50.  
  51. CONTENTS
  52.  
  53. 1.  Brief explination of serial drivers under Linux (0.99.15 and up)
  54. 2.  Compiling and installing the programs
  55. 3.  Setting up the configuration files
  56. 4.  Troubleshooting
  57. 5.  Credits, Thanks, Etc...
  58.  
  59.  
  60. 1.  SERIAL DRIVERS
  61.  
  62.     The serial drivers have changed again as of 0.99.15.  If you are
  63.     not too interested in knowing how the serial ports work, you can
  64.     probably skim over this section.
  65.  
  66.     The basic idea behind Linux serial drivers is that callin and
  67.     callout devices should not try to use the same line at the same 
  68.     time.  In the past, this was accomplished by juggling lockfiles.
  69.     The new scheme takes care of the problem in the kernel.  Instead 
  70.     of one modem device, there are now two: a callin device, named 
  71.     /dev/ttyS# (where # is the port number), and a callout device, 
  72.     named /dev/cua# (again, # = port number).  The callin devices are 
  73.     used by programs like getty; the callout devices are used by 
  74.     programs like Seyon and Kermit.  If you don't have the callout 
  75.     devices in /dev, you create them with the mknod command.  They 
  76.     are character devices, major number 5, minor number same as the 
  77.     corresponding callin device.  Consult the Linux Device List for
  78.     more information about creating the /dev entries.
  79.  
  80.     So how does it work?  Simple...
  81.  
  82.     Suppose that kermit wants to open /dev/cua1 for a callout session.
  83.     The kernel allows the line to be open if and only if no other
  84.     program currently has the corresponding /dev/ttyS1 line open; if
  85.     it does, the error EBUSY is returned in errno.  
  86.  
  87.     The /dev/ttyS1 line is a bit more complicated.  By default, the device
  88.     'blocks' on open.  This means that the program will be stopped until
  89.     the device is clear to open.  For the device to be clear, two things
  90.     must be true:  no process can be using the corresponding /dev/cua1
  91.     line, and the carrier detect line of the serial port must be high.
  92.     While the device is blocking, it is not busy, so callout devices can
  93.     use the line.  In other words, if getty is running on /dev/ttyS1, as
  94.     long as no incoming calls open the line (causing the carrier to go
  95.     high), other programs are free to use the line.  Blocking can be dis-
  96.     abled by setting the O_NDELAY flag to the open system call.  In this 
  97.     case, carrier detect is not needed to open the line; however, if 
  98.     /dev/ttyS1 is busy, EBUSY is still returned in errno and the open fails.
  99.     Finally, a blocking open will return EAGAIN in errno if another process
  100.     closes the corresponding callout device.  This allows getty to easily
  101.     monitor the serial line, and reinitialize if another program might
  102.     have changed serial port parameters (or modem parameters).
  103.  
  104. 2.  COMPILING AND INSTALLING THE PROGRAMS
  105.  
  106.     Two binaries are the product of this package:  getty and uugetty.
  107.     The only difference between getty and uugetty is that uugetty checks
  108.     and creates lockfiles.  Uugetty should be used on any bidirectional
  109.     line (modems, for example).  Getty should be used on unidirectional
  110.     lines (virtual consoles, dumb terminals).
  111.  
  112.     Everything should be all set to compile on any 'normal' Linux box
  113.     (whatever that is).  Just untar the sources (which I assume you've
  114.     done if you're reading this), edit the Makefile to reflect your
  115.     local configuration, favorite linking flags, etc...
  116.  
  117.     Also, edit the file tune.h, and change this to your liking.  Most
  118.     everything is compiled in by default, so you probably don't need
  119.     to tinker with this too much.  Do a make depend; make all to build 
  120.     the programs.  I have also included binaries of getty and uugetty; 
  121.     these files were compiled with gcc 2.5.8, and linked with 
  122.     libc.so.4.5.21.  If your library is older, you will have to do the 
  123.     compile yourself (or grab the new library).
  124.  
  125.     After the sources are compiled, MAKE A BACKUP COPY OF YOUR EXISTING
  126.     WORKING GETTY PROGRAM!  I cannot stress this enough.  There is a good
  127.     chance that you will not have things configured correctly the first
  128.     time around, and will not be able to log into your machine.  This is
  129.     also probably a good time to get one of those bootable rootdisks.  In
  130.     any case, be sure you can boot your system in single user mode before
  131.     you install anything.
  132.  
  133.     I like my getty binaries in /etc.  If you want yours in /bin or /sbin, 
  134.     edit the Makefile.  Make install to copy the binaries into the correct 
  135.     directories.  By default, your old getty and uugetty programs are saved 
  136.     under getty- and uugetty-.  After everything is running smoothly, you 
  137.     can remove these backup files.
  138.  
  139.  
  140. 3.  SETING UP CONFIGURATION FILES
  141.  
  142.     After you install the binaries AND BEFORE YOU LOGOUT/SHUTDOWN you must 
  143.     edit the file /etc/inittab.  The argument format for getty_ps is:
  144.     
  145.       getty tty speed [terminal-type]
  146.       uugetty tty speed [terminal-type]
  147.  
  148.     'Tty' is the line to run on (without the /dev).  Speed is the line speed
  149.     as defined in /etc/gettydefs.  This argument must match the first field
  150.     of one of the lines in /etc/gettydefs (see gettydefs(4) man page). The
  151.     optional terminal-type is the expected type of terminal to be found at the
  152.     other end.  I set this to console for vt's and vt100 for serial lines.
  153.     Here is the relevant portion of my /etc/inittab file:
  154.  
  155.     1:123:respawn:/etc/getty tty1 VC console
  156.     ...
  157.     s2:23:respawn:/etc/uugetty ttys2 2400 vt100
  158.  
  159.     Be sure the format of the inittab entries you create are consistent
  160.     with the version of init you are using.  This example works with a
  161.     SYS-V compatible init program.  If you are using simpleinit, the
  162.     format is different.  You will want to change one of the lines to 
  163.     use your OLD WORKING getty (named getty- if you used make install) 
  164.     until everything is stable.
  165.  
  166.     Next, you want to create the configuration files.  The file
  167.     /etc/gettydefs must exist for proper operation.  See the man page
  168.     for gettydefs(5) for the format of this file.  There is an example
  169.     under the examples directory that you can use to get started.
  170.  
  171.     You will also want to set up /etc/syslog.conf to properly log 
  172.     getty error and debug output.  By default, getty logs to facility
  173.     LOG_AUTH.  Errors are sent with priority LOG_ERR, and debugging
  174.     output is sent with priority LOG_DEBUG.  If you don't like syslog,
  175.     make the proper adjustments to tune.h.  Here are the relevant lines 
  176.     from my /etc/syslog.conf:
  177.  
  178.     auth.warning;        /usr/adm/auth.log
  179.     auth.debug;        /usr/adm/getty.debug.log
  180.  
  181.     Finally, you want to create configuration files for the individual
  182.     lines.  These are kept in /etc/default.  If you are running getty on
  183.     tty2, the configuration file is /etc/default/getty.tty2; for uugetty
  184.     on ttyS0, /etc/default/uugetty.ttyS0.  Also, if you want the same file
  185.     for all instances of getty or uugetty, you can make the file
  186.     /etc/default/getty or /etc/default/uugetty.  Example configuration
  187.     files are under the examples directory.  
  188.  
  189.     See the getty(1) manual page for more information on this file.  These 
  190.     configuration files are optional, so your system won't crash if you 
  191.     don't have them, and no configuration files are needed to run getty 
  192.     on a virtual console or dumb terminal (though you can still have them 
  193.     if you want).  The main purpose of the configuration files is to 
  194.     configure your modem correctly.
  195.  
  196.     If you think you have everything right, reboot your system (you do have
  197.     a _working_ bootable floppy, right?  I thought so).  If you can log into
  198.     your system on the consoles you set to use the new getty, everything is
  199.     working fine (at least on the consoles).  
  200.  
  201.     Next, after you have edited the configuration file for your modem's tty
  202.     line, go over to a friend's house and try to call up.  If you have a
  203.     14400 baud Hayes modem, the files I have included should drop right in
  204.     and work; otherwise they might need some editing.
  205.  
  206. 4.  TROUBLESHOOTING
  207.  
  208.     So, what could possibly go wrong?
  209.  
  210.     In my experience, the major source of confusion with getty_ps has
  211.     been setting up the chat sequences correctly.  Failing chat 
  212.     sequences will cause init to produce errors like 'respawning too 
  213.     fast'.
  214.  
  215.     If your modem is not responding as expected to the INIT/OFF/CONNECT 
  216.     chat sequences, getty will be continuously respawning.  Check your
  217.     log files; if you have have lots of lines that say INIT sequence 
  218.     failed, this is the problem.  Check your /etc/default/* files.  You 
  219.     can turn on    debugging of the init sequence by adding the following line
  220.     to your defaults file:
  221.  
  222.     DEBUG=010
  223.  
  224.     or, alternatly, add the -D010 flag to the entry in /etc/inittab.
  225.     
  226.     This will log some helpful information to syslog.  Read this for clues 
  227.     as to what might be going wrong.
  228.  
  229.     If you get CONNECT sequence failed, then the CONNECT line is to blame.  
  230.     Debug this line the same way.
  231.  
  232.     If you have other problems.  Turn on full debugging:
  233.     
  234.     DEBUG=777
  235.     
  236.     and read the debugging log.  If you can't make heads or tails of it,
  237.     mail it to me and I'll see what I can do with it (after all... it 
  238.     may be a bug).  I don't know anything about other types of modems, 
  239.     so if you have modem specific questions, I probably can't help much.
  240.  
  241.  
  242. 5.  CREDITS, ETC...
  243.  
  244. Special thanks to all of these people:
  245.     Paul Sutcliffe     ... original author
  246.     Steve Robbins      ... former maintanier of getty_ps
  247.     Michael Haardt     ... SYSV init support
  248.     Theodore Tso       ... for a valuable discussion of the
  249.                            new serial drivers
  250.     Shane Alderton     ... for the ringback patches
  251.     Julian Cowley      ... for helping with the transition to the
  252.                                0.99.15 serial drivers
  253.     Dr. G.W. Wettstein ... for syslog patches
  254.     Eugene Crosser     ... fidonet patches
  255.  
  256. I have included all of the original documentation from this package under
  257. the OLD directory.  You might find it useful.  If you find that this file
  258. is missing something, please let me know.  I've tried to be as complete as
  259. possible without writing a book, but I have been known to screw up in the
  260. past.
  261.  
  262. Good Luck.
  263.  
  264. Kris Gleason
  265. gleasokr@boulder.colorado.edu
  266.