home *** CD-ROM | disk | FTP | other *** search
/ Peanuts NeXT Software Archives / Peanuts-1.iso / Documents / hardware / Best-Fortress-UPS-to-NeXT-connection.text < prev    next >
Encoding:
Text File  |  1993-06-10  |  2.8 KB  |  55 lines

  1. Notes on connecting a Best Fortress UPS to a NeXT serial port:
  2.  
  3. Hardware:
  4.   The correct cable wiring is as follows:
  5.       UPS (DB-9 male)      NeXT (Mini DIN-8 male)
  6.       ---------------      ----------------------
  7.            1                      3
  8.            2                      5
  9.            4                      4
  10.  
  11. Software for graceful shutdown:
  12.   The CheckUPS for Unix software package from Best includes a BSD Unix
  13.   version called checkups.bsd.  I got the floppy disk version of this
  14.   software; the 3.5 inch DOS-format floppy that comes in this package
  15.   reads fine on the NeXT.  To compile the file, you not only have to
  16.   rename it to checkups.c, but also change carriage-return line-feed
  17.   endings to just line-feed (i.e. newline).  Here's how I got the
  18.   program off the disk, changed the line ending convention and name,
  19.   and compiled it:
  20.     tr -d '\015' < /DOS/checkups.bsd > checkups.c
  21.     cc -bsd -o checkups checkups.c               
  22.   This compiles like a charm, without so much as a warning. As far as
  23.   I can tell from looking at it, it should run fine in its as-is
  24.   state.  However, I have only actually tested it after making two
  25.   minor modifications:
  26.     1) I changed it to directly run "/usr/etc/halt -p" to shut the
  27.        system down rather than an /etc/upsdown script that would
  28.        presumably contain this line.  This is a matter of taste and
  29.        I'm not convinced I'd recommend it.
  30.     2) I changed the printmsg function to use syslog (at the emergency
  31.        priority level) rather than the wall command to display the
  32.        messages.  The normal /etc/syslog.conf configuration is set up
  33.        so that emergency messages are in fact broadcast to all
  34.        logged-in users, just like with wall.  However, additionally
  35.        the messages wind up on the console and in the log file
  36.        (/usr/adm/messages).  This is useful in our situation, since
  37.        there is typically no one logged in to the file server
  38.        (particularly when the power is out, since nothing they could
  39.        log in from is on an UPS), so the broadcasting would likely
  40.        never be seen, but it is nice to have a record in the log file
  41.        of what happened.
  42.  
  43. Security:
  44.   If you don't make the protection modes on /dev/ttya more restrictive,
  45.   then any normal user, even logging in remotely, will be able to
  46.   power your machine down by just sending the right string to that
  47.   serial port.  So, I'd recommend making that device accesable only to
  48.   root.  In fact, I'd go further and do the same for all the various
  49.   flow controlled and dial in/out variations on tty, i.e.
  50.   /dev/{tty{d,},cu}{f,}a
  51.  
  52. Please let me know if you have any additional information (or
  53. corrections, heaven forbid) you would like to contribute to this file.
  54.   -Max Hailperin <max@nic.gac.edu>, Gustavus Adolphus College
  55.