bgo@PacBell.COM (Bud Odekirk) (10/18/89)
Does anyone out there have multiple PC's connected to an Apollo network ?
We are getting ready to SHIT CAN Apollo. We have formed a committee to find
an alternative to Apollo as soon as possible. Our main uses of Apollo are
E-mail and some file sharing. We converted from DPSS mail to Unix mail
a couple of months ago and we have had nothing but problems since.
Apollo's solution to all of our problems is to convert to SR10. We figured
that it would cost us in excess of 1 million dollars and we're not sure
that will solve our problems.
We have about 460 IBM PC's (or compatible) connected to the Apollo network
using DTERM and PCI. Our Sysadmin tells me that we are the only ones that
have this configuration and that is why no one else is encountering the same
kind of problems.
If anyone has a Apollo system that they are accessing with a large number of
PC's, I would appreciate hearing from them.
Thanks
/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/
2600 Camino Ramon, Room 3W600E
San Ramon, Ca. 94583
415 823-1379
{att,bellcore,sun,ames,pyramid}!pacbell!pbhya!bgo
\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/\*/wescott@LNIC1.HPRC.UH.EDU (Andrew M. Wescott) (10/20/89)
Learn some manners. I don't respond to overzealous idiots. Andrew Wescott University of Houston
markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) (10/20/89)
We are getting ready to SHIT CAN Apollo. We have formed a committee to find an alternative to Apollo as soon as possible. Our main uses of Apollo are E-mail and some file sharing. We converted from DPSS mail to Unix mail a couple of months ago and we have had nothing but problems since. Let me guess, "Unknown mailer error #<n>". The big problem is that /bin/mail assumes it can always attach to its mailbox (i.e., its not mounted and never locked) and plop in the msg. And since Berkeley doesn't like to make changes to sendmail, its likely only to get fixed by the vendor. Since the vendor, Apollo, doesn't use sendmail internally, they are not likely to even see the problem. Your only recourse here is to do what we did and thats to make the modifications to /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. The changes are small, yet understanding sendmail is not. Of course we are working on (yes, I know I said this a few months ago) a public release version of our changes. But let me tell you. Once it is set up correctly on the Apollos, you have 1 /usr/spool/mail directory, not N of them (where N equals the number of nodes in your network). And not through NFS. If you think you have problems now, then try setting up your spool directory through nfs and you'll see the joys of maintaining hundreds of mounts points with these non-apollo unix workstations you are planning to buy. Apollos can work to your advantage if set them up correctly. Apollo's solution to all of our problems is to convert to SR10. We figured that it would cost us in excess of 1 million dollars and we're not sure that will solve our problems. This is not the solution. The solution is to get corrected code. But I am still confused over what you are implying. Do you really want to run the same version of the os when there is a newer one available? Do you think that switching vendors is going to alleviate the particular problem of being told to run the next release of their OS. Every vendor enhances their OS and schedules new releases. They vary from a few months to every year or so. This is *every* Vendor. Get used to it. If you don't want to "keep up" and upgrade, then buy all PC's or all Mac's or something that a system administrator is not needed for. I'm also willing to bet you have software maintenance through Apollo which means you are *paying* them to enhance your os. Now that sounds like a waste of money to me. ------------------------------------------------------ Mark Giuffrida University of Michigan markg@caen.engin.umich.edu Naturally, these comments are strictly my own views. ------------------------------------------------------
danny@idacom.UUCP (Danny Wilson) (10/22/89)
In article <4653bf071.0017b5e@caen.engin.umich.edu>, markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes: > [...] > Your only recourse here is to do what we did and thats to make the > modifications to /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. > The changes are small, yet understanding sendmail is not. > Of course we are working on (yes, I know I said this a few months ago) > a public release version of our changes. Unless I am missing something, Apollo distributes BINARY code versions of all its programs (like everyone else). With this in mind, it seems quite impossible to modify /usr/lib/sendmail, /bin/mail etc without having the source code. Where is the source code coming from? -- Danny Wilson IDACOM Electronics danny@idacom.uucp Edmonton, Alberta alberta!idacom!danny C A N A D A X.400 danny@idacom.cs.ubc.cdn
vince@bcsaic.UUCP (Vince Skahan) (10/24/89)
It strikes me that getting rid of Apollo because you can't devote the
time (and pain...I've been there too) to learn sendmail is a pretty
shaky decision. Yes, it's painfil but ti does work once you've bled
enough.
That doesn't make it right, and there's no excuse in my mind for the
brain-dead sendmail.cf's you get by default from Apollo...but once you
set it up it DOES work. our > 15 subnets will attest to it.
I also agree with the bit about the file-locking in one /usr/spool/mail
being a pain in the neck. We get around that by having on
/usr/spool/mail PER RING and you hvae to know where somewhere is working
to get mail to their ring.
There are lots of semi-easy ways to get around it like:
- sticking everyone in your .mailrc by alias
- using system-wide /usr/lib/aliases that point to the right
ring
- messing with sendmail.cf to make pseudo-aliases by department,
building, etc.
It CAN be done but it (and unix - by definition) is never plug-and-play.
This is not necessarily Apollos's fault but is more probably the result
of being blindly unix-like (even when the unix way is lacking).
--
Vince Skahan Boeing Computer Services - Phila.
(215) 591-4116 ARPA: vince@atc.boeing.com
UUCP: bcsaic!vince
Note: the opinions expressed above are mine and have no connection to Boeing...