Sorry for the delay ... unfortunately work must come before e-mail!!!
Thanks to all who replied regarding my problem with getty, UUCP and setting
up a modem in general. Here is my original post:
> Hello Sun Managers!
>
> We spent the better part of Friday night last week attempting to get a Hayes
> compatible modem to work properly on our SPARCstation 2. Previously, we had
> the modem working fine for dialing out (using /dev/ttya), as well as using
> our FAX package (TruFax) for answering incoming calls. Since we are getting
> a second modem dedicated for faxing, we want to configure the modem to allow
> us to dial in for normal work, SLIP and UUCP *and* dial out for UUCP and
> communications via a program like Kermit.
>
> After digging through the Sun System and Network Adminstration manual and
> reading (and re-reading) the zs manual page we though we had it. We *almost*
> had it. Here is what we ended up with late Friday night:
>
> A device, /dev/ttyd0, with major 12, minor 0 and character special
> A device, /dev/cua0, with major 12, minor 128 and character special
> A Hayes-compatible modem with auto answer enabled
> An entry in /dev/ttytab that looks like:
>
> ttyd0 "/usr/etc/getty D2400" dialup on remote
>
> The permissions and ownership on /dev/ttyd0 where 666, owned by root
> and a group of staff (?).
>
> The permissions and ownership on /dev/cua0 where 600, owned by uucp
> and a group of staff (?).
>
> We modified the eeprom (and rebooted) to have:
>
> ttya-rts-dtr-off=false
> ttya-ignore-cd=true
>
> What we ended up with was getty running on /dev/ttyd0, which changed the
> permission of the file to something like 622. We were able to dial in and
> connect, but the connection seemed to be in 7 bits and some wierd parity.
> After playing with it some more, sometimes we could just hit return and get
> a login prompt, other times we had to intermix a break and returns. Some
> times the connection would be proper in 8 bits, other times it would be
> unproper in 7 bits. We tried adding a "p8" entry to gettytab for the D2400
> entry and that caused getty to never put up a login prompt. We also had
> a problem where an incoming call would drop carrier, but getty would never
> time out. We added a "to" entry to gettytab for the D2400 entry and again
> that caused getty tonever put up a login prompt (we did kill getty to get
> it restart after modifying gettytab).
>
> To top things off, the cua0 device is owned by uucp with read/write permissions
> only. To me, this means that any communication software we use to dial out
> must be suid to uucp. Is this correct? Also, when getty is waiting for
> carrier detect to go high and to begin the login process, we are unable to
> gain access to /dev/cua0. I thought that the two minor numbers would govern
> how this should work.
>
> Could someone *please* point out the error of our ways? I'd really appreciate
> a step by step "how to" guide for adding the modem. The Sun manuals are
> cryptic and, even after following them, it seems you need to work some special
> magic to get things to happen. The O'Riely "Essential System Administration"
> is better, but still does not give the "desired" results. Everything we have
> read gives us in the indication you can use the same line for dial in/out
> but we just can't figure it out!
>
> Thanks!
Well, I was close ... There were a couple of probelms.
The eeprom shouldhave been configure to have ttya-ignore-cd=false. This way,
the port will properly register that carrier detect is enabled. Once this was
taken care of, the port no longer kept carrier detect high and the port was
free to be used for dial out at the same time. This also corrected the problem
of getty not logging the user off of the port when the user hung up.
As for the ownership of /dev/cua0, if it is owned by uucp, then it is necessary
to have all user communication programs suid to uucp. Since file transfers
received by the user would then also be owned by uucp, this was a bad idea.
The other solution was to allow permissions of 666 on the port and have it
owned by whomever (uucp, root, ...) and this worked like a champ.
I did not have to modify anything in gettytab. It was all in getting the
port to properly recognize carrier detect and getting the modem to auto
answer the line.
Here are the replies I received. Please feel free to e-mail me if you have
any questions. I've since set up about 4 modems on different systems, as well
as UUCP and a couple of FAX programs, all sharing ports and I've got a pretty
good grip on it now! Thanks to everyone for the helpful information!!!!!
> >Subject: getty, UUCP and modems
> >To: sun-managers@eecs.nwu.edu (Sun Managers Mailing List)
> >Date: Mon, 25 Jan 93 10:29:04 CDT
> >Cc: hammond@sunloop.Central.Sun.COM (Kevin Hammond)
>
> This is what I have on my SPARCstation 1 (with US Robotics Dual Standard):
>
> eeprom settings:
> ttyb-rts-dtr-off=false
> ttyb-ignore-cd=true
> ttyb-mode=19200,8,n,1,h
>
> device settings ("ls -lg" output):
> crw-rw-r-- 1 root tty 12, 129 Jan 26 15:37 /dev/cua1
> crw--w--w- 1 root wheel 12, 0 Jan 26 15:48 /dev/ttyb
>
> /etc/gettytab settings:
> default:p8:lm=\r\n%h login\72 :sp#9600:
> slip.19200:lm=\r\nlogin\72 :sp#19200:to#45:
>
> /etc/ttytab settings:
> ttyb "/usr/etc/getty std.19200" unknown on modem
>
> ============================================================================
> | Keith Farrar | AMIX Corporation | Mountain View, CA | (415) 903-1026 |
> | DOMAIN: keith@markets.amix.com | UUCP: {uunet|sun|netcom}!markets!keith |
> ============================================================================
>
> In message <9301251629.AA02770@venus.title.sun>you write:
>
> + Hello Sun Managers!
>
> Hi again! Looking at turn around time, you sent this before
> your first message got anywhere near here. Curse of the slow links :-(
>
> + ttya-rts-dtr-off=false
>
> I actually have this set to true, but then I use it (9600 with
> compression), but then I need it as the effective speed changes.
> Definatlty needed with Sparcs going faster than 9600 whether it's
> constant or not (the serial ports can't kepp up with bi-directional
> transfers any faster than that - have to go uni-directional.)
>
> + ttya-ignore-cd=true
>
> See earlier comments :-)
>
> + only. To me, this means that any communication software we use to dial out
> + must be suid to uucp. Is this correct? Also, when getty is waiting for
> + carrier detect to go high and to begin the login process, we are unable to
> + gain access to /dev/cua0. I thought that the two minor numbers would govern
> + how this should work.
>
> Can you do a "ps" to see what terminal is associated with the
> getty? If it has a terminal associated with it, that means it thinks
> the carrier has gone high, and it's grabbed the port, blocking cua0.
> If it's got a ?, that means its opening of the terminal is blocked
> (ie, no CD yet) so it hasn't got an associated terminal as yet, and
> should not be blocking cua0.
>
> + Could someone *please* point out the error of our ways? I'd really appreciate
> + a step by step "how to" guide for adding the modem. The Sun manuals are
>
> So would we all :-)
>
> + cryptic and, even after following them, it seems you need to work some specia
> + l
> + magic to get things to happen. The O'Riely "Essential System Administration"
> + is better, but still does not give the "desired" results. Everything we have
> + read gives us in the indication you can use the same line for dial in/out
> + but we just can't figure it out!
>
> Hope this helps! If you want, I'll try and dig out my
> gettytab file from home tonight (on tape on the DEC 'cause I got rid
> of my old Sun - happily running OSF/1 at home since last May.)
>
> Cya,
> Andrew.
>
> /*
> * Andrew Rutherford andrewr@itd.adelaide.edu.au
> * +61 8 228 5669 Real Programmers always confuse Christmas and
> * Room 1060, Adelaide Uni Halloween because OCT 31 == DEC 25 !
> */
>
> >From pascoe@rocky.gte.com Fri Oct 16 18:27:53 1992
> Return-Path: <pascoe@rocky.gte.com>
> Received: from [128.90.91.35] by rocky (5.65c/DNI-7.0-dhp)
> id AA03281; Fri, 16 Oct 1992 18:27:45 -0400
> Message-Id: <199210162227.AA03281@rocky>
> Date: Fri, 16 Oct 1992 18:27:46 -0500
> To: pascoe
> From: pascoe@rocky.gte.com
> Sender: pascoe@rocky
> Subject: Modem setup
>
> >Date: Wed, 8 Jul 92 08:36:59 EDT
> >From: leonh%hhb@Princeton.EDU
> >To: pascoe%princeton.UUCP.UUCP%rocky.dnet@bunny.gte.com
> >Subject:
> >
> >Dave,
> > This is something we use as a guide for our people to set up
> >dial-in/dial-out on a SUN; with this version being 'kermit' specific
> >(rather than UUCP specific). This is assuming that your Sparcstation is
> >working correctly of course. Please do not distribute this to others
> >without asking me first. Thanks.
> >===============================================================================
> >
> > SETUP INSTRUCTIONS FOR TELEBIT MODEMS AND SUNOS 4.1.1
> >
> > ** KERMIT Specific version ** Leon A. Howorth
> > Racal-Redac, Mahwah, N.J.
> > Last Revision: 06/24/92
> >===============================================================================
> >1. CABLE PIN-OUT:
> >
> > The following is a summary of the necessary pins for the cable
> > connecting the modem to the SUN serial port.
> >
> > Sun - Telebit
> >
> > 1 - 1
> > 2 - 2
> > 3 - 3
> > 4 - 4
> > 5 - 5
> > 6 - 6
> > 7 - 7
> > 8 - 8
> > 20 - 20
> >
> >
> >2. MODIFY /etc/remote
> > Add this entry (all characters are literal, i.e. the ^ is 'shift 6'
> > on the Sun):
> >
> > tb9600:dv=/dev/cua0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
> > tb19200:dv=/dev/cua0:br#19200:el=^C^S^Q^U^D:ie=%$:oe=^D:
> >
> >3. Check that you have the following entries in /etc/gettytab:
> >
> >2|std.9600|9600-baud:\
> > :sp#9600:
> >g|std.19200|19200-baud:\
> > :sp#19200:
> >
> >4. CREATE THE DIALIN AND DIALOUT DEVICES:
> >
> > cd /dev
> >
> > Dialin device (This renaming is optional):
> > -------------
> > mv ttya ttyd0 # if port A is used
> > mv ttyb ttyd1 # if port B is used
> >
> > Dialout device:
> > --------------
> > mknod cua0 c 12 128 # if port A is used
> > chmod 666 cua0
> > chown uucp.uucp cua0
> >
> > mknod cua1 c 12 129 # if port B is used
> > chmod 666 cua1
> > chown uucp.uucp cua1
> >
> >5. ENABLE CARRIER DETECT ON SERIAL PORT AND ENABLE GETTY FOR DIALIN:
> >
> > As of SunOS 4.1.1 it is no longer necessary to modify the kernel in
> > order to enable or disable software/hardware carrier detection on a
> > tty line. The following command is provided in /etc/rc:
> >
> > /usr/etc/ttysoftcar -a > /dev/null 2>&1
> >
> > (The following example enables hardware carrier detect on serial
> > port A and enables getty for dialin):
> >
> > cd /etc
> >
> > vi /etc/ttytab
> >
> > ****** The line in /etc/ttytab for port A ******
> >
> > ttya "/usr/etc/getty std.9600" unknown off local secure
> >
> > ****** is changed to: ******
> >
> > ttyd0 "/usr/etc/getty std.19200" dialup on remote unsecure
> >
> > Then restart getty on ttya with the command:
> >
> > kill -1 1
> >
> >6. CONFIGURE MODEM
> >
> > Tip to the modem using "tip tb9600" and configure it with the command
> > string below. (This example is supposed to be ONE line of data, NOT two.
> > The commands can be given one at a time or in groups, provided the final
> > command line ends with "&W" ).
> >
> >AT &F S0=1 S07=080 S48=1 S51=5 S52=2 S54=3 S58=2 S66=1 S68=255
> >
> >S95=2 S110=0 S111=10 S130=2 S131=1 S151=5 S255=0 Q6 X3 &W <CR>
> >
> >
> > Upon execution of the command line, the serial interface speed will be
> > changed to 19200 bps. As a result of this action, garbage characters
> > will be echoed as a response to any input. Exit tip using the "~."
> > command. Use "tip tb19200" to access the modem at 19200 bps.
> >
> >==============================================================================
> >
> >Additional Information:
> >-----------------------
> >
> >1. Dialin from V.32 modems
> >
> >If other sites with V.32 modems have trouble connecting to your
> >Telebit, set S120=16. This is by default a "hidden" register set to
> >zero, but it will appear along with the other registers (by means of an
> >"ATN?" command) if it is reset to other than zero. This eliminates
> >the additional V.25 answer tone, following the PEP answer tone but
> >prior to the V.32 answer tone, in more recent versions of the Telebit
> >firmware.
> >
> >2. Kermit, Parity and modem settings
> >
> >The following contributed by Jim Guiliano of Customer Support at Mahwah.
> >It pertains to the resolution of dialin problems to a SUN 3 system from
> >customers with systems using serial ports set to 8 bits, no parity (such
> >as an IBM PC) and using Kermit.
> >
> > "As per our discussion, the following information pertains
> > to the changes I made on sun3cad to correct the problems we were
> > experiencing with kermit transfers from customer logins. They also
> > helped in outgoing transfers.
> >
> > First, I set S111=10 in the Telebit modem. This forces the
> > modem to recognize the kermit transfer protocol at 8 bits and no
> > parity. S111 was originally set to 255 which let the remote modem
> > determine the transfer protocol. I found that if the remote modem
> > also had S111 set to 255, or to 0, the net result was that no
> > protocol was recognized (the same as setting it to 0). Since I know
> > that the only transfer protocol we will be using is kermit, I felt
> > that this was appropriate.
> >
> > Second, I set getty on the dial-in port to force 8 bits and
> > no parity. I did this by adding "p8:" to the end of the std.19200
> > entry in the gettytab. This was needed since according to the man
> > page for getty, the default is 7 bits and even parity. After changing
> > the gettytab file, I had to send an HUP signal to the init process
> > by typing "kill -1 1" so that the change would be read in and take
> > effect.
> >
> > The reasoning behind choosing 8 bits and no parity is simply
> > that when kermit is invoked, defaults to 8 bits and no parity. This
> > can be changed by using command line arguments, or setting the parity
> > at the kermit prompt, but I figured that this was too much trouble.
> >
> > My tests of the new setup show that transfers now will work
> > at the highest connect speed possible. The only trouble I had was that
> > after kermit finished transferring a file, some extra garbage ended up
> > on the receiving machine at the unix prompt. This sometimes was taken
> > by the system as a command, or caused the connection to hang, or for
> > me to get disconnected. If I used kermit in the server mode, or had
> > kermit running on both ends and shuttled back and forth, I did not
> > see any problems from the extra garbage."
> >
> >3. RTS/CTS Flow Control on Sparcstation
> >
> >In one case the modem and system were set up to use hardware flow
> >control, but the flow control would not work properly unless S58=3
> >(XON/XOFF) was set on the modem, rather than the desired S58=2
> >(RTS/CTS). A multimeter was used to test the voltages (DC) between
> >pins 7 (signal gnd) and 20, and between pins 4 (RTS) and 20. The
> >voltage between 4 and 20 was zero. This indicates a system (not a
> >modem) problem.
> >
> >4. The following applies to the version of kermit currently available at
> >Racal-Redac, Mahwah, N.J. (ckuker.mak file version 2.1.1 and ckutio.c
> >file dated 27 Jan 88):
> >
> >Do the following as 'root' for SunOS 4.1.1 systems:
> >
> > chown root.staff kermit
> > chmod 511 kermit
> > chmod 2777 /var/spool/locks
> >
> > For SunOS 4.0.3 only:
> >
> > chown root.staff kermit
> > chmod 511 kermit
> > chmod 2777 /var/spool/uucp
> >
> >
> ----------------------------------------------------
> Dave Pascoe
> pascoe@rocky.gte.com
> GTE/MSED - Needham Heights, MA
> Amateur Radio: KM3T
> (617) 455-5704
>
> --
> Dave Pascoe
> Internet: pascoe@rocky.ndhm.gtegsc.com
> GTE/MSED - Needham Heights, MA
> (617) 455-5704
>
> Turns out your first post did get through -- I'll append my response to
> it here in case that address didn't work. Meanwhile I've thought of
> one other quirk which may be involved: in my experience it has been
> necessary to cycle power after changing the tty eeprom settings -- a
> simple reboot does not seem to be sufficient. (The eeprom "reset"
> command might do the job -- I have not tried that.)
>
> Re making kermit (and perhaps other programs) setuid/uucp, I think it
> would work OK to change the permissions on /dev/cua0 to 666 if you do
> not need to control which programs are able to use the dialout.
>
> Re 7 vs 8 bits, I think you may be stuck with 7 at least in 4.1.x due
> to getty and/or login not being 8-bit clean. 7 "should" be sufficient
> as long as you do not intend to use non-English characters in login
> names or passwords -- if 8-bit characters are needed after login you
> can always use stty to change the line parameters.
>
> - - - begin appendage - - -
>
> >From perryh Tue Jan 26 15:36:51 1993
> To: hammond@kwhpc.chi.il.us
> Subject: Re: dial in/out modems
>
> > Last night we spent a good couple of hours trying to configure a modem
> > to be used for both dialing in an dialing out. Previously, we had it
> > configured fine for dialing out, but had never set it up to dial in.
> >
> > We are configuring a Hayes compatible modem on a SPARC 2.
> >
> > We changed the eeprom to the following:
> >
> > ttya-ignore-cd=true
> > ttya-rts-dtr-on=false
>
> AACCKKKK!!!
>
> ttya-ignore-cd should be false -- you do NOT want to IGNORE cd on a
> bidirectional line! Also, make sure that the modem is configured to
> track CD, and reset/reinitialize when DTR drops at the end of a call;
> the command to do this is generally something like
>
> AT &F &C1 &D3 &W
>
> but check the modem manual as not all modems support &D3.
>
> > 1) a login never seems to timeout, thus if you connect and
> > drop carrier, you will never get a login prompt again.
>
> That's because you're ignoring CD, so SunOS never "sees" CD drop.
>
> > Sometimes the session is all uppercase with *real* uppercase
> > letters escaped with a \, sometimes the session is fine.
>
> This will happen if you enter a login name containing no lowercase
> letters -- getty is assuming that you have an uppercase-only terminal.
> This is a holdover from the ancient past.
>
> > 3) after the modem reports "CONNECT 2400", pressing return will
> > not get a login prompt. It typically takes a series of
> > returns and breaks to get the prompt.
>
> Probably related to ignoring CD.
>
> > The other problem is that, after reading the Sun manual on adding a modem
> > and the man page for zs, it seems you should be able to have a device with
> > major 12 and minor 0 for dialing in that you hand getty and a device with
> > major 12 and minor 128 that you can use to dial out with UUCP, tip or
> > some other communications package. We have devices configured this way,
> > but once getty is on ttya (major 12, minor 0) we can *never* gain access
> > to cua0 (major 12, minor 128).
>
> This, too, is caused by ignoring CD.
>
> > Furthermore, isn't the modes on cua0
> > supposed to be 600 and owned by uucp? If this is so, how is a regular
> > user supposed to gain access to the dialout port via a program like kermit?
> > Would kermit need to be suid to uucp?
>
> If you want to restrict dialout to "approved" programs, the cua devices
> should be 600/uucp and the approved dialout programs should be suid/uucp.
> For example
>
> -rws--x--x 1 uucp daemon 73728 Oct 11 1990 /bin/tip
>
> and yes, kermit would also need to be suid/uucp.
>
> .SH
> Serial Dramas (April 92)
> .LP
> Serial lines supposedly are easy to work with: they don't carry lethal
> voltages, don't require complicated data encoding schemes, and run over
> wiring as simple as home telephone circuits. But, first time installation
> of a modem or another serial device is likely to take you more than just a
> few hours to get it right while you try all the various switch combinations,
> cable connections, and SunOS table entries.
> .LP
> Actually, the myriad of configuration options makes serial lines seem much
> more dramatic or traumatic than they should be. This month we look at the
> basics of asynchronous serial communications and how SunOS drives and
> interprets its various signals. We'll also walk through the configuration
> protocols for a dial-in and dial-out modem. And, finally, we'll apply our
> knowledge of hardware handshaking to catch the power failure signal from an
> uninterruptible power supply.
> .SH
> Serial Line Signals
> .LP
> The Electrical Institute of America (EIA) is responsible for the two
> "recommended standard" (RS) specifications commonly in use today for
> asynchronous serial communications, RS-232 and RS-423. The latter
> specification is a subset of the former; it handles slightly wider voltage
> ranges and a higher voltage slew rate, but any port that handles RS-423
> signals easily will accept an RS-232 connection. The serial ports on Sun
> systems, ttya and ttyb on Sparcstations, for example, can manage either
> RS-423 or RS-232 connections, so we'll consider just RS-232 from here on
> since that's a more commonly-known designation.
> .LP
> Only three lines, transmit (TxD), receive (RxD), and a signal reference
> (GND), are needed for RS-232 asynchronous serial communications; some control
> signals, such as XON/XOFF are embedded in the data. This so-called three
> wire serial connection is commonly used with simple serial devices, such as
> printers and dumb data terminals.
> .LP
> For advanced communications needs, such as demanded by hardware flow
> control, the RS-232 standard also specifies several control
> signals. Request to Send (RTS) and Clear to Send (CTS) indicate the
> transmitter's and receiver's readiness to send and receive data,
> respectively. Very few modems use RTS and CTS, which are sometimes called
> the "hardware modem control" signals.
> .LP
> Rather, most modems use two other control signals, Data Terminal Ready
> (DTR) and Data Carrier Detect (DCD). When DTR is active or logically
> "high", the terminal device (your workstation, for example) is telling the
> data device (the modem, for example) that it is ready to make a connection.
> An active DCD indicates that the data device or modem is currently connected
> with another data device modem. The acronyms and terminology can be
> confusing; so, just think of these signals in terms of dialing your
> telephone: DTR tells you if the phone is plugged into the wall and working,
> DCD means that you've called or received a call and now can talk. Easier
> yet, many modems have signal lights that inform you of such connections as
> well as entertain you.
> .LP
> Physically, RS-232 devices are connected with at least a three conductor
> cable, although the number and qualities of the cable wires vary depending
> on the application. For high speed communications, you need a higher
> quality cable. To use a modem, you'll need a cable
> with enough wires for the data and handshaking control signals.
> The RS-232 specification assigns data and control signals to specific
> pins on common cable connectors (Table 1 and Figure 1).
> .DS
> Signal DB-25 pin DIN-9 pin
> Transmit Data TxD 2 3
> Receive Data RxD 3 2
> Request To Send RTS 4 7
> Clear To Send CTS 5 8
> Data Set Ready 6 6
> Ground GND 7 5
> Data Carrier Detect DCD 8 1
> Data Terminal Ready DTR 20 4
> .DE
> .LP
> Data Set Ready (DSR) is similar in function to DTR, and is used
> mostly by synchronous devices.
> .SH
> Hard Vs. Soft Carriers
> .LP
> RS-232 hardware specs sound simple so far? Software configuration for the
> modem isn't so easy -- for instance, DCD is interpreted by several different
> parts of SunOS. Before we describe how to configure SunOS to handle
> incoming and outgoing serial data via modem, let's examine how it handles
> DCD and DTR signals.
> .LP
> There is a simple rule for serial ports: You can't
> complete an open() system call on a tty (connected
> to a serial port) until there's a carrier present on
> that port. This rule can be a problem for those cheap, 3-wire connections
> to terminals we mentioned earlier, you need to supply a carrier signal of
> some sort to be able to use the tty port.
> .LP
> Fortunately, SunOS contains a technique commonly known as "software
> carrier." Instead of looking for a DCD signal,
> SunOS provides it in software and ignores the signal (or absence of
> a signal) on the actual RS-232 connector. This is the default configuration
> for terminal ports. You also can tell SunOS to use the
> DCD signal supplied by the terminal or modem for a true hardware carrier.
> You should use software carrier for persistent connections,
> like printers, terminals and other equipment that tends to stay put once
> attached. Hardware carrier is useful for devices that will make and
> break connections, like modems. Using hardware carrier also lets you
> share a single tty port for dial-in and dial-out modems, as we'll see
> shortly.
> .LP
> You choose hardware versus software carrier detection in the eeprom settings
> and the /etc/ttytab file. If the command, "eeprom ttya-ignore-cd" returns
> "true", SunOS ignores the hardware signal present on the ttya
> external connector and supplies its own carrier. Otherwise, use the
> command, eeprom ttya-ignore-cd=false, as the first step towards enabling
> hardware carrier detection on the serial port A. Substitute "ttyb" in
> these commands for the second CPU serial port.
> .LP
> Entries in the /etc/ttytab file also affect hardware carrier detection.
> A typical one might read:
> .DS
> ttyb "/usr/etc/getty std.9600" unknown off local
> .DE
> The first field is the name of the tty device - the file name you'll find
> in the /dev directory. The next entry is the process that should be
> run on this port. In this case, it's a standard getty at 9600 baud.
> The third field contains the default terminal type, and the fourth
> field indicates whether the the tty port is in use or not. If the
> fourth column is "off," then no process is run on that port.
> .LP
> The last field in the ttytab file controls the software carrier mechanism.
> If it's "local", the field tells SunOS that a carrier
> should be supplied in software. Change this flag to "remote" for hardware
> carrier detection.
> Thereafter, a call to open() on that tty device won't be
> completed until the external device, the modem, for instance, generates a
> carrier signal. This "block until connection" scheme is essential for
> using a single modem for dial-in and dial-out connections: it keeps the
> getty process from grabbing control of the serial port until someone
> actually calls in on the modem. Until then, the serial port is free
> for dial-out use.
> .LP
> The Dial-In Modem
> .LP
> The first step to connecting a modem, whether used for dial-in or -out
> service, is get the right cable. It should
> have each connector pins connected directly to their
> counterparts -- pin 1 to pin 1, pin 2 to pin 2, and so on. If you
> were wiring a terminal, you would need to cross the RxD and TxD signals
> so that one device's output became the other's input. Modems take
> care of this crossover for you, so the modem-to-machine connection
> should always be made with a "straight through" cable. Also, most external
> modems have 25- or 9-pin connectors; cable adaptors are available from a
> variety of sources, or refer to Table 1 and Figure 1 to fashion your own cables.
> If you have a SPARCstation with a DIN-8 (round) serial port connector, use
> the Sun-supplied pigtail for a more common 25-pin interface.
> .LP
> Next, check the switch settings or configuration of your modem. Most modems
> can be set to permanently indicate a DCD.
> Make sure your modem is set to drive DCD only when a connection
> to another modem is established.
> .LP
> The eeprom setting for the tty port (b in the following examples) to which
> the modem is attached should also look for an external carrier signal:
> .DS
> #eeprom ttyb-ignore-cd=false
> .DE
> Finally, ensure that the last field in the /etc/ttytab entry for ttyb is
> "remote."
> .LP
> You also might want to change the "getty definition" for the port to better
> match your's with the dialup modem's characteristics. Getty definitions are
> contained in /etc/gettytab. We'll leave it to you to read and interpret the
> SunOS manual pages for gettytab and decipher the proper settings. For this
> discussion, we'll use " Fast-Dial-2400" for the common dial-in 2400-baud
> modem. And, include "on" in the /etc/ttytab description so that the getty
> is started:
> .DS
> ttyb "/usr/etc/getty Fast-Dial-2400" unknown on remote
> .DE
> If you change /etc/ttytab, you must either reboot the system or manually
> execute ttysoftcar and tell init to start the new getty:
> .DS
> # ttysoftcar -a
> # kill -1 1
> .DE
> The ttysoftcar utility reads /etc/ttytab and configures software or
> hardware carrier detection for each tty port. It also is part of the normal
> boot process executed by /etc/rc. The kill command sends the HUP signal to
> init (process 1) which makes init re-read /etc/ttytab and start the getty
> process on the dial-in port.
> .LP
> At this point, we've solved half of the problem of setting up a serial port
> with a modem to answer dial-in calls: There's a getty trying to open ttyb,
> and when a connection is made with the modem, it'll drive DCD and the getty
> process will finish opening ttyb. The dial-in user gets a login prompt, and
> getty starts up a login process to verify the user's name and password.
> .LP
> If you find messages on your console about failed or invalid logins on
> ttyb, it may be that the getty process continually is sending out a login
> message because the modem is driving DCD all of the time. The gettty/login
> is incorrectly interpreting the modem's echo or error response to be a login
> sequence which results in an invalid login attempt and, hence, the error
> messages on the console. This may happen so quickly that it's hard to
> detect, so try watching the process id of the getty on ttyb. Once started,
> the same getty process should run until a connection is established. If you
> see getty processes with increasing process ids, chances are that you have a
> modem that is imitating a flailing user and consuming CPU cycles.
> .SH
> Setting Up a Dial-Out Modem
> .LP
> It usually is desirable to set up a modem on the serial port of the
> workstation for both dial-in and dial-out duties. Here's where the delayed
> device opening comes in handy: when the modem is busy, it can't be opened
> and used by another process. However, if getty opens the device and holds it
> open waiting for dial-ins, we can't use the modem for dial-out. By forcing
> hardware carrier detection, on the other hand, we can delay getty's open
> call to the tty device until there's really a connection from a dial-in
> user.
> .LP
> The first step towards setting up the modem for dial-out use is to create a
> new device that is an "alias" for ttyb. To create a dial-out device, add
> 128 to the minor device number of the dial-in device. Minor device numbers
> are given by ls -l. For example, to create the cuab device alias of ttyb:
> .DS
> # ls -l /dev/ttyb
> crw-rw-rw- 1 root 12, 1 Jun 6 1990 /dev/ttyb
> # mknod /dev/cuab c 12 129
> # chmod 666 /dev/cuab
> # ls -l /dev/cuab
> crw-rw-rw- 1 root 12, 129 Jan 26 1992 /dev/cuab
> .DE
> The mknod command creates a new character device with major number 12 (the
> same as the existing ttyb) and minor number equal to ttyb's minor device
> number plus 128 (129). The most significant bit of the
> minor number is used by the tty driver as an override of the hardware
> carrier detection scheme.
> .LP
> This arrangement lets us open the modem device for dial-out, even though we
> insisted on hardware carrier detection with the other software
> configurations. When you're dialing out, you don't want to wait for
> a connection to your modem - carrier detect doesn't make sense because
> you are initiating the connection, not waiting for it. We really only
> want the hardware carrier detection to work for dial-in.
> If you attempt to use kermit,
> tip or cu, and get "device busy" errors, check that the modem is actually
> free, and then verify that you're opening a device with a minor number
> larger than 128.
> .SH
> Controlling Other Serial Devices
> .LP
> There are many devices other than a modem that operate with serial
> interfaces, such as temperature monitors, card readers, even a simple door
> buzzer. One such device that is gaining increasing use is the
> uninterruptible power supply (UPS). A UPS ensures that your systems have
> enough backup power during a power failure so you have time to gracefully
> shut down.
> .LP
> But Murphy's Law also ensures that you won't be there when the juice is
> turned off, UPS or not. Fortunately, most UPSs also come with a serial
> interface that is activated when a power failure occurs. So, you can have
> your workstation manage its own graceful shut down: establish a serial
> connection to one of the system ports, and use the delayed open feature of
> hardware carrier detection for power failure notification by the UPS system.
> The trick is to make the power failure signal look like a modem connection.
> .LP
> Start by cabling your UPS so that the power failure signal is presented as
> DCD on the Sun system serial port. Proceed as if you are setting up a
> dial-in modem (see above), but when you edit /etc/ttytab, replace the getty
> entry with the name of a local utility that will perform an orderly
> shutdown. For example:
> .DS
> ttyb "/usr/local/bin/powerfail" unknown on remote
> .DE
> Listing 1 is a sample powerfail utility. The tool tries to explicitly open
> the tty device, but since no carrier is present, the open() call is blocked.
> If and when a power failure signal is provided on the DCD line, open()
> completes, and "shutdown" is invoked to halt the machine nicely.
> .LP
> If you have several machines on the UPS, you'll probably want to execute a
> script that shuts them down in order. But, at the same time, you want the
> script to check and make sure each machine can be reached for shut down --
> there's no sense spending the UPS's battery lifetime waiting for a remote
> machine that has already crashed or is unreachable. And, if you use one
> machine as the master for the entire computer room's shut down, make sure
> any network equipment connecting the machines is powered by the UPS as well.
> .LP
> The sample powerfail code in Listing 1 will manage a shut down as soon as
> the UPS becomes the main source of power and activates the serial port.
> However, you may want your automated systems to wait several minutes before
> shutting machines down, for instance if the power failure is brief or the
> result of a brown out.
> .LP
> The powerfail.2 utility given in Listing 2 sets an alarm timer which must
> expire before the subsequent shut down procedure takes effect. When
> the alarm signal is received, the process executes a shutdown. If the DCD
> signal is dropped before the alarm goes off, the process exits and nothing
> happens. The monitoring process is killed by the same mechanism that
> cleans up a login shell if a dial-in session is interrupted and the
> connection broken. Since the power failure
> utility is managed by /etc/ttytab, init will spawn another copy of it to handle
> the next power flicker.
> .LP
> Listing 1. Powerfail utility for use with an uninterruptible power supply.
>
> #include <stdio.h>
> #include <sys/file.h>
>
> main(argc, argv)
> int argc;
> char **argv;
> {
> int fd;
> char device[128];
> sprintf(device, "/dev/%s", argv[1]);
> fd = open(device, O_RDONLY);
> if (fd < 0) {
> printf("%s: failed to open %s , argv[0], device);
> exit(1);
> }
> execl("/usr/etc/shutdown", "shutdown", "-h", "now", (char*)NULL);
> }
>
>
> Listing 2. Powerfail.2 utility waits for timeout before shutting down but
> can be avoided by restored power.
>
> #include <stdio.h>
> #include <sys/file.h>
> #include <sys/signal.h>
>
> main(argc, argv)
> int argc;
> char **argv;
> {
> int fd;
> int do_shutdown();
> char device[128];
>
> sprintf(device, "/dev/%s", argv[1]);
> fd = open(device, O_RDONLY);
> if (fd < 0) {
> printf("%s: failed to open %s , argv[0], device);
> exit(1);
> }
> signal(SIGALRM, do_shutdown);
> alarm(10);
> sigpause(); /* wait for something to happen */
> }
>
> int do_shutdown()
> {
> execl("/usr/etc/shutdown", "shutdown", "-h", "now", (char*)NULL);
> }
>
>
> rouble.
> >
> > My tests of the new setup show that transfers now will work
> > at the highest connect speed possible. The only trouble I had was that
> > after kermit finished transferring a file, some extra garbage ended up
> > on the receiving machine at the unix prompt. This sometimes was taken
> > by the system as a command, or caused the connection to hang, or for
> > me to get disconnected. If I used kermit in the server mode, or had
> > kermit running on both ends and shuttled back and forth, I did not
> > see any problems from the extra garbage."
> >
> >3. RTS/CTS Flow Control on Sparcstation
> >
> >In one case the modem and system were set up to use hardware flow
> >control, but the flow control would not work properly unless S58=3
> >(XON/XOFF) was set on the modem, rather than the desired S58=2
> >(RTS/CTS). A multimeter was used to test the voltages (DC) between
> >pins 7 (signal gnd) and 20, and between pins 4 (RTS) and 20. The
> >voltage between 4 and 20 was zero. This indicates a system (not a
> >modem) problem.
> >
> >4. The following applies to the version of kermit currently available at
> >Racal-Redac, Mahwah, N.J. (ckuker.mak file version 2.1.1 and ckutio.c
> >file dated 27 Jan 88):
> >
> >Do the following as 'root' for SunOS 4.1.1 systems:
> >
> > chown root.staff kermit
> > chmod 511 kermit
> > chmod 2777 /var/spool/locks
> >
> > For SunOS 4.0.3 only:
> >
> > chown root.staff kermit
> > chmod 511 kermit
> > chmod 2777 /var/spool/uucp
> >
> >
> ----------------------------------------------------
> Dave Pascoe
> pascoe@rocky.gte.com
> GTE/MSED - Needham Heights, MA
> Amateur Radio: KM3T
> (617) 455-5704
>
> --
> Dave Pascoe
> Internet: pascoe@rocky.ndhm.gtegsc.com
> GTE/MSED - Needham Heights, MA
> (617) 455-5704
>
>
> Status: OR
>
> etcom.com!lincoln!brian
> Reply-To: sunloop!netcom.com!lincoln!brian
> Followup-To: junk
> Received: from ZEXEL by lincoln.ZEXEL (4.1/SMI-4.1)
> id AA15549; Fri, 22 Jan 93 10:40:21 PST
> Received: from bach.ZEXEL by ZEXEL (4.1/SMI-4.1)
> id AA24507; Fri, 22 Jan 93 10:40:21 PST
> Date: Fri, 22 Jan 93 10:40:21 PST
> Message-Id: <9301221840.AA24507@ZEXEL>
> To: sun-managers@eecs.nwu.edu
> Subject: SUMMARY: SunOS Alternatives
> Content-Length: 6391
>
> : SunOS Alternatives
> Content-Length: 6391
>
>
>
> Hello Fellow Sun Managers,
> I would like to thank all that replied to this informal survey.
> My intention was to get an idea of the mood of other sys ads
> as we approach the Solaris 2.* decision: not so much to discuss
> or decide on alternatives but more to get a clearer picture of the
> overall problem and possible solutions. The responses that I
> received were very helpful in this respect, and so I feel that
> a condensed summary is appropriate. Also, those that asked for a complete
> summary will have it mailed directly to them, and if you would like
> a complete summary (including each of the responses: 23 responses of
> 1-2 pages) simply e-mail me and it will be sent. A copy of the
> original mail is appended to this message.
>
> The first question that deals with alternative operating systems
> was the question that most interested me. Alternatives that were
> mentioned are: BSD , CHORUS, CMU's Mach, IBM's AIX, HP/UX,
> Ultrix, Linux/SPARC, MINIX/SPARC, Amoeba, GNU's Hurd, and
> finally Window's NT. Note that not all of these
> are currently available, but are expected to be in the coming
> months or early '94. The comments, though, that followed each
>
>
> s of
> 1-2 pages) simply e-mail me and it will be sent. A copy of the
> original mail is appended to this message.
>
> The first question that deals with alternative operating systems
> was the question that most interested me. Alternatives that were
> mentioned are: BSD , CHORUS, CMU's Mach, IBM's AIX, HP/UX,
> Ultrix, Linux/SPARC, MINIX/SPARC, Amoeba, GNU's Hurd, and
> finally Window's NT. Note that not all of these
> are currently available, but are expected to be in the coming
> months or early '94. The comments, though, that followed each
> of these suggestions were that:
> - there's no guarantee that these OS's will be any more stable
> than Sun
> - there will most likely be much less commercial SW available on these
> alternative OS's
> - support for most of these OS's would most likely need to be through
> informal net conversations
> - alternative OS's will lag behind hardware advances, so that
> if you want the latest HW from Sun then you'll need Solaris 2.*
> - you would just be switching from one set of problems to another,
> and most respondents feel that the devil you know is better
> than the devil you don't
>
> The second question, dealing with the time involved in the change
> of the OS, could have been worded better: basically, I was trying
> to get an idea about the time needed to switch to Solaris 2.* as compared
> with other alternative OS's. Basically, it is much to general a
> question to get a real answer, and most people told me that.
>
> The final question, dealing with having "faith" (poor choice of word)
> in the OS, produced some insightful answers and did a good job
> of getting to the heart of what people are thinking about doing
> in the coming months. The answers may be summarized as follows:
> - although this is going to take a lot of time (anywhere from
> a month to a year) to move to Solaris 2.*, most people are going to
> make the move: many feel constrained by their current HW and
> feel that Sun is as reliable as anyone else
> - the change will not be made until the fall or winter of '93:
> most have stated that they will run Solaris 2.* on one machine,
> work out the kinks, and when their favorite software is ported
> begin the tedious process of switching
>
> The majority of people finished by saying that Sun is by no means
> a sinking ship, that SVR4 is the future, and that it would still be
> several years until we could hope for a stable operating system
> from anybody.
>
> Brian
>
>
>
> Brian S. Boyd a.k.a. brian@zexel.com
> ZEXEL USA, Inc. (408) 738-4250 VOICE
> 265 Santa Ana Ct. (408) 738-4302 FAX
> Sunnyvale, CA 94086
>
> Disclaimer: Ha! My employers WISH they could have views like this!
>
> "If sex sells, what are we buying?"
> from "Consumers Awaken: Your Fly is Wide Open!"
>
>
>
> > From brian Fri Jan 15 15:05:01 1993
> > To: sun-managers@eecs.nwu.edu
> > Subject: SunOS Alternatives
> > Cc: laura
> >
> > Hail Fellow Managers!
> >
> > The time is arriving where each of us must make the decision
> > about whether or not to continue to follow Sun on their roller-coaster
> > ride through operating systems. Admittedly, I did not have to
> > deal with the Motorola to Sparc change (I have only been a
> > Sys Admin for two years), but I am concerned that Sun seems to
> > have little regard for the users (e.g., having to re-write
> > their apps every couple of years) and just assumes that we
> > will follow since we have already invested so much time and
> > money in the Sun system.
> >
> > I am writing this letter to question this assumption and to inquire
> > about possible alternatives to the "Sun way". Our site has
> > fifteen Sparc Stations, ranging from SLC's to Sparc 1+'s.
> > I would like to put forth the following set of questions to
> > this mailing list with the hope of revealing alternative paths
> > to the Sun OS "upgrade":
> >
> > 1. Are there other operating systems that will run on Sparcs?
> > - is this "standard": i.e., do manuals exist?
> > - if so, would you expect support to be available?
> >
> > 2. How long would you expect such a change to take place:
> > - small group (1-20 machines)
> > - medium group (21-50 machines)
> > - large group (51+ machines)
> > where I would consider the installation of the OS, the re-working
> > of the network, getting mail to run again, etc.
> >
> > 3. Do you have faith that Solaris 2.* will satisfy your
>
> ke place:
>
> > - small group (1-20 machines)
> > - medium group (21-50 machines)
> > - large group (51+ machines)
> > where I would consider the installation of the OS, the re-working
> > of the network, getting mail to run again, etc.
> >
> > 3. Do you have faith that Solaris 2.* will satisfy your
> > operating system needs?
> > - if no, balance that with the cost of changing operating
> > systems, and can you count on your new vendor to be
> > more stable?
> > - if yes, how much of your time do you expect the change
> > to Solaris 2.* consume?
> >
> > All of these are questions that are bothering me and I know that I
> > must resolve them before I make any sort of intelligent decision
> > about the upcoming operating system change.
> >
>
>
> y, I have not made up my mind either way, but am anxious
> > about the lack of support that Solaris 2.* has. If this is a sinking
> > ship, I would rather not buy a ticket; but if the negative image
> > has been generated by a resistance to change without it being a
> > reflection of its actual quality, then maybe it will be worth the
> > risk. In any case, I hope that any responses I receive will help
> > clear the current thick fog that now surrounds me as I try to
> > make the right OS decision.
> >
> > Thanks,
> > Brian
> >
> >
> > ******************************************************************
> >
> > Brian S. Boyd a.k.a. brian@zexel.com
> > ZEXEL USA, Inc. (408) 738-4250 VOICE
> > 265 Santa Ana Ct. (408) 738-4302 FAX
> > Sunnyvale, CA 94086
> >
> > "If sex sells, what are we buying?"
> > from "Consumers Awaken: Your Fly is Wide Open!"
> >
> > ******************************************************************
> >
>
>
>
>
> COM) by sunloop.Central.Sun.COM (4.1/SMI-4.1-900117)
> id AA04426; Tue, 26 Jan 93 21:04:32 CST
> Received: from Sun.COM (sun-barr.EBay.Sun.COM) by Central.Sun.COM (4.1/SMI-4.1)
> id AA04222; Tue, 26 Jan 93 21:04:28 CST
> Received: from ra.mcs.anl.gov by Sun.COM (4.1/SMI-4.1)
> id AA20748; Tue, 26 Jan 93 19:04:26 PST
> Received: by ra.mcs.anl.gov id AA21487
> (5.65c/IDA-1.4.4 for sun-managers-outbound); Mon, 25 Jan 1993 10:21:13 -0600
> Sender: sunloop!ra.mcs.anl.gov!sun-managers-relay
> Received: from antares.mcs.anl.gov by ra.mcs.anl.gov with SMTP id AA21481
> (5.65c/IDA-1.4.4 for <sun-managers@ra.mcs.anl.gov>); Mon, 25 Jan 1993 10:21:07 -0600
> Received: from delta.eecs.nwu.edu by antares.mcs.anl.gov (4.1/SMI-GAR)
> id AA29903; Fri, 22 Jan 93 12:08:18 CST
> Received: from sun2.nsfnet-relay.ac.uk by delta.eecs.nwu.edu with SMTP id AA30665
> (5.65c/IDA-1.4.4 for <sun-managers@eecs.nwu.edu>); Fri, 22 Jan 1993 12:06:49 -0600
> Via: uk.ac.aberdeen; Fri, 22 Jan 1993 16:04:42 +0000
> From: sunloop!aberdeen.ac.uk!G.ROBERTSON
> Reply-To: sunloop!aberdeen.ac.uk!G.ROBERTSON
> Followup-To: junk
> Date: Fri, 22 Jan 93 15:14:28 GMT
> Message-Id: <A9301221514.AA18698@uk.ac.aberdeen.sysa>
> Received: from cc1.comcen.abdn.ac.uk.abdn.ac.uk by aberdeen.ac.uk;
> Fri, 22 Jan 93 15:14:28 GMT
> To: sun-managers@eecs.nwu.edu
> Subject: SUMMARY:BudTool+Jukebox
> Content-Length: 6725
>
>
> Thanks for all the replies. Several people stated that BudTool support
> was not perfect. It appears to have improved more recently. Specifically...
>
> zilaitis@solomon.bms.com (Vicki Zilaitis) stated
> -------
> Overall we are very happy with the Budtool Software. The Jukebox
> Management software leaves alittle to be desired but Delta has been
> very open to suggestions and I am looking forward to the next
> software release. It really is an automated system. Once it is
> configured very little interface is required except of course when
> problems arise.
> --------
> Alternative back-up systems suggested were:
>
> fallan@awadi.com.au suggested :-
>
> you may want to have a look at Flashback.
> We use it for network backups here, and it is supposed to support
> stackers, jukeboxes etc, although so far we have not had the
> opportunity to try it with any of these.
>
> It certainly works well across the network, and handles multiple backup
> devices, even of mixed varieties. It also allows easy scheduling, and
> logging with automatic mailing of logs etc, compression of online
> indexes & tape labelling, and is driven from an OpenWindows interface.
> Also it isn't expensive. The details are below if you are interested.
> -------------
> shamash@boxhill.com suggested networker from legato, which I had already
> investigated. I had trouble getting accurate costs for this.
> I eventually discovered that the cost of the Exabyte 60 robotic interface for
> networker is UK22K. Everything seems to be an optional extra for networker,
> which,for my requirements, would cost me in excess of UK30K for a 100 user
> licence.
> -----------
> jdr@semi.harris.com said:-
>
> we ended up going with
> QuickRestore from Workstation solutions. They now have support for the
> 10i, and have everything we need in a networked backup solution.
>
> The cost is about 2k per server ( the server is the workstation with
> the backup device(s)), so overall cost is pretty reasonable.
> ----------
> jan@ii.uib.no stated:-
>
> we use the Backup Co-Pilot dump program, but everything else
> is handled by local scripts. We didn't like the fact that Co-Pilot
> put the database on the local machines, in stead of a central "dumphost".
>
> The Usenix conference papers have had several interesting reports on
> backup strategies. Might be worthwhile to check out.
> -----------
> alan%merccap@uunet.UU.NET sent me a summary from a previous query on
> sun-managers which covered:
> Networker Legato
> Backup.uunet Systems Center
> Budtool Delta Microsystems
> Backup Copilot Sun Microsystems
> Flashback Pinnacle Micro
> ----------
> Dave@usppc.abb.com is happy with Copilot, having tried Flasback first.
> -----------
> Christian Lawrence <cal@soac.bellcore.com> stated:
>
> I currently use Networker 25 with the jukebox
> and concurrent device add-on modules to drive an ATL with 2 8500's. It
> works like a champ !!! I've also used Networker to drive stackers ... and
> it works just fine there too. Thats actually one of its good points --
> it can drive multiple heterogenous clients (e.g. SOS & AIX) on multiple
> interfaces (e.g. single drive, stacker, carousel)....
> .... One thing worth noting with all these
> packages is that they consume a fair amount of space themselves !!! You
> should figure on about a 10 % margin to store all the tape/file indexing
> information needed by such a package.
> ------
> art%lsr-vax@uunet.UU.NET (Art Hays - PSTAFF) said:-
>
> Epoch systems has a good backup product that (according to them) scales
>
>
> ------
> Christian Lawrence <cal@soac.bellcore.com> stated:
>
> I currently use Networker 25 with the jukebox
> and concurrent device add-on modules to drive an ATL with 2 8500's. It
> works like a champ !!! I've also used Networker to drive stackers ... and
> it works just fine there too. Thats actually one of its good points --
> it can drive multiple heterogenous clients (e.g. SOS & AIX) on multiple
> interfaces (e.g. single drive, stacker, carousel)....
> .... One thing worth noting with all these
> packages is that they consume a fair amount of space themselves !!! You
> should figure on about a 10 % margin to store all the tape/file indexing
> information needed by such a package.
> ------
> art%lsr-vax@uunet.UU.NET (Art Hays - PSTAFF) said:-
>
> Epoch systems has a good backup product that (according to them) scales
> better than Networker to large nets. It manages Exabyte's jukebox.
> It has an X-based directory browser and recover tool.
> It's pricey, but it's good (I use it).
> -------
> lemke@MITL.COM (Kennedy Lemke) stated:-
>
> I have been using APUNIX's "mdump" program to do backups in our
> heterogeneous environment (with a little start-up shell script
> hacking to get rdump to do the right thing on DEC, NeXT, HP).
> It has been working fine.
>
> But one of my main problems is that it takes up to, say, 12
> hours do fill an entire 5 GB tape. This is due in part to slow
> dump programs, disks, the network, etc. Bottom line is that the
>
> Status: OR
>
> , NeXT, HP).
> It has been working fine.
>
> But one of my main problems is that it takes up to, say, 12
> hours do fill an entire 5 GB tape. This is due in part to slow
> dump programs, disks, the network, etc. Bottom line is that the
> tape doesn't actually stream during any of the backup process,
> and it wastes its time.
>
> Summer '92 USENIX had a paper about a system at Maryland they
> developed (freeware) that solves this problem....
> ..... The system is called "amanda".
>
> ----------
> sab@abars.att.com stated:-
>
> We have a product called ABARS (Automatic
> Backup, Archive, and Recovery System) that backs up a UNIX network
> over the network to a single jukebox. It is a combination of hardware
> and software that is completely supported by AT&T (no outside vendors
> needed!).
> --------
> dannyd@mel4360(.miden.com.au (Zdenek Dospisil) stated:-
>
> Did you talk to Control Data???~
> They have few products , which can solve yours problem .~
>
> ultiple robotic devices including :the Exabyte 10i and
>
> 120, the IGM carousel, The Metrum products, the optical jukebox
> products , and the STK silo.~
> ARIA*Client Migration Manager that automatically migrate files between
> a workstation (or server) and higher level server.~
> ARIA*Server Migration Manager migrates files between server and
> robotic devices ( old name is FARM)~
> ARIA*UniTree with support for multiple robotic devices.~
> They have as well FDDI .~
> -----------------------------------------------------------------------
> The original query:-
>
> I am hovering on the brink of purchasing this combination (BudTool + Jukebox)
> to back-up our ether+FDDI network of Unix(Mostly Sun) systems.
>
> We will soon (Easter) have 50Gb of Computing Service Unix files to back up off
> 5 servers on an FDDI LAN, PLUS ~20Gbyte(?) of Unix files on
> other systems on ethers. We had intended to fit EXB500 tape drives to
> the above 5 servers to back up their local files and to back up
> the rest(scattered over the net) on an Exabyte Jukebox or IGM ATL carousel.
>
> Having found out the cost per "media-host" of Budtool
> licences, I'm now looking at CoPilot for these servers. But Co-Pilot
> doesn't seem to manage Robotic devices, hence the remaining interest in BudTool
> on a single host for the network backups.
> -----------------------------------------------------------------------
>
> Well, I eventually discovered a product called PMP produced by a UK company
> active in Oil Company Computing (PECC).
> This provides me with the robotic interface for the Exabyte 60 Jukebox,
> an improved dump program, media management software including labelled tapes,
> SunOS+DOS client software, user directed restores, a site-wide licence and a
> (motif) windows interface at a price which is competative with BudTool and much
> better than Networker. I get local support too.
> Anyone interested should contact Maxine Dent of PECC, email md@pecc.uucp
>
>
> Several things:
>
> 1) ttya-ignore-cd=false
> 2) AT&C1&W
> 3) kermit SUID to uucp
> 4) no "local" for the ttyd0 entry in /etc/ttytab
> 5) don't use D2400, make your own entry and "lock" the DTE rate on the
> modem to the baud rate you set in your gettytab -- the data rate is
> independant of the DTE rate
> 6) reboot AND power cycle your Sun
>
>
> - Matt Goheen
>
>
> Please summarize, thanks.
>
> Hello,
>
>
> >
> > ttya-rts-dtr-off=false
> > ttya-ignore-cd=true
> >
>
> Wouldn't you want ttya-ignore-cd=false?
>
> If you ignore carrier detect, then the getty is always going to be active.
> I think you want getty to exit when Carrier drops.
>
>
> Ted Nolan
> ted@usasoc.soc.mil
>
Thanks to the following:
uunet.UU.NET!markets!keith
itd.adelaide.edu.au!andrewr
rocky.ndhm.gtegsc.com!pascoe
pascoe@rocky.gte.com
xerox.com!Perry_Hutchison.Portland
perryh
sunne.East.Sun.COM!stern
wbst845e.xerox.com!matt
neon.mitre.org!anderson
usasoc.soc.mil!ted
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:27 CDT