brian@ucsd.EDU (Brian Kantor) (05/21/88)
We just installed the latest version of AT&T WIN TCP/IP for our 3B15, and got it working, more or less. ARRRGH! Things to watch out for while installing it: 1. Don't install it twice. If the first attempt at installing it fails, go back and remove everything before you start over. Guaranteed it won't install the second time without an intervening remove. If you had the beta test version, you'd better yank that out first or all kinds of things in the installation script will come unstuck. Make sure that none of the codefiles it's going to try to write on top of are running; perhaps going to single-user mode is worth doing, although the manual doesn't suggest that. 2. If you already have any of the files used by this software, it will just cheerfully overwrite them; this is particularly true of /etc/hosts, /etc/networks, and /usr/lib/sendmail.cf. Do a full backup of your /usr and root filesystems FIRST so you can put your versions back. You have been warned. 3. After you cpio the installation script in, go modify it so you can see what it's doing so you can undo anything you don't like it doing. I stuck a 'set -x' in the top of it. I consider a "please wait" message inadequate progress reporting, and the damn installation script seems to remove itself after completion (at least, I couldn't find it) so there's no reasonable way to find out what it did after the fact. Things to do to make it work: The script that goes in /etc/rc.d/rc2.net is broken. It starts the NI interface, then checks to see what it's status is. If you are doing ANYTHING except coming up from power-on, it may well find that the interface is already running. Since it's looking for the "just started" status return, it considers this an error, doesn't start the daemons, and you're stuck. I just commented out the test, so we now just tell the interface to start and keep on going. I've never had the interface fail to start, so this gamble seems worth it. The manual doesn't seem to list the status return codes for the nistart/nistatus programs, so I can't fix the script to work properly. Things you can't easily do anything about: The version of sendmail delivered is 4.12; which according to the Version log in our BSD sources was current on Sept 7, 1983 (yes, FIVE YEARS AGO). It's so full of bugs that you're lucky if mail gets delivered. We get around five or six messages a day from the mailer daemon telling me that /bin/mail was invoked from sendmail with bad command line arguments; luckily this is being forwarded to me on a BSD system where I can forward it on to the proper recipient. If you have any hope of using this machine for ethernet mail you'd better plan on porting the current version of sendmail or maybe replace it with MMDF or something. You can get the latest version of sendmail by anonymous FTP from ucbarpa, but it's configured for Berkeley systems and will take some work to port. Forget about subnets. This software has no idea what a subnet is. There isn't a nameserver. Even if you grab one of the ports of BIND to SysV, you're stuck, since you can't recompile the software to take advantage of it. And sendmail 4.12 never even heard of an MX RR. ------- Understand, this isn't meant to be a flame (although that might be appropriate...). Except for sendmail, what's arrived now seems to be working reasonably well. It seems obvious to me, however, that this is a product that hasn't been upgraded at all recently - I'm wondering how much time elapsed between the time Wollongong delivered it to AT&T and when we got it last week. I suspect it's been a couple of years. It's a good thing we don't have serious users on this machine (just a few students doing independent research) or I'd have to fix this stuff - probably by porting over as much of the 4.3 code as would work. But it's a whole lot better than nothing, and much less hassle than doing it ourselves would have been, so we aren't going to send it back. It sure could have been nicer though. Caveat, as they say, emptor. Brian Kantor UC San Diego
len@netsys.UUCP (Len Rose) (05/21/88)
No other comments to make but this one.. I have stashed
sendmail for system V on ames.. it is available by anonymous
ftp at ames.arpa ..
Len
--
Len Rose - len@ames.arc.nasa.gov
or {ames,decuac,ihnp4}!netsys!len
"This better not be haga!"scott@ksuvax1.cis.ksu.edu (Scott Hammond) (05/24/88)
In article <828@ucsd.EDU> brian@ucsd.EDU (Brian Kantor) writes: >We just installed the latest version of AT&T WIN TCP/IP for our 3B15, >and got it working, more or less. ARRRGH! What release of WIN/3B? We've had 1.1 on our 15s for several months now (but your problems look familiar). > >Things to watch out for while installing it: > >1. Don't install it twice. If the first attempt at installing it fails, >go back and remove everything before you start over. Guaranteed it And if you were running 3bnet, stop it and remove it. (I didn't realize the 3bnet software hadn't been pulled yet, made life interesting). >3. After you cpio the installation script in, go modify it so you can >see what it's doing so you can undo anything you don't like it doing. >I stuck a 'set -x' in the top of it. I consider a "please wait" message >inadequate progress reporting, and the damn installation script seems to >remove itself after completion (at least, I couldn't find it) so there's >no reasonable way to find out what it did after the fact. You'll find it in /usr/win3b/install; there is also a backout script "UNINSTALL". > >Things to do to make it work: > >The script that goes in /etc/rc.d/rc2.net is broken. It starts the NI >interface, then checks to see what it's status is. If you are doing >ANYTHING except coming up from power-on, it may well find that the >interface is already running. Since it's looking for the "just started" Have to check this. Haven't had any trouble with the net coming up at boot. Not surprising though. >Things you can't easily do anything about: > >The version of sendmail delivered is 4.12; which according to the >Version log in our BSD sources was current on Sept 7, 1983 (yes, FIVE >YEARS AGO). It's so full of bugs that you're lucky if mail gets >delivered. Ours seems to be _fair_. DONT try to use the frozen configuration. I use all new sendmail configs, and basically have non-local stuff go to a BSD machine with MX-Sendmail, BIND, etc. Most annoying is that locally delivered mail arriving over the network will have a From header listing the name of real user id of the last person to start the daemon (ie. if it was started at boot, then mail from the net says "From: daemon", if I started it while su-ed to root, it will say "From: scott". I got a copy of a binmail that fixes this from allyn@cs.ucsd.edu while I was upgrading sendmail for 3b2's (hope you don't mind me mentioning it Allyn). >If you have any hope of using this machine for ethernet mail >you'd better plan on porting the current version of sendmail or maybe >replace it with MMDF or something. You can get the latest version of >sendmail by anonymous FTP from ucbarpa, but it's configured for Berkeley >systems and will take some work to port. Suggest starting with 5.58 from ucsd for 3b2s/V.3.1 or wait for V.3 for the 15. >this is a product that hasn't been upgraded at all recently - I'm >wondering how much time elapsed between the time Wollongong >delivered it to AT&T and when we got it last week. I suspect it's >been a couple of years. Current release of WIN/3b is 2.1 I think (wish we had it). >It's a good thing we don't have serious users on this machine (just a >few students doing independent research) or I'd have to fix this stuff >- probably by porting over as much of the 4.3 code as would work. But Agreed. First thing ported was more. One more possible problem: When you first install, and boot the new system from /etc/system, be sure to rebuild unix (mkunix) while in SINGLE USER MODE. If you wait until multi-user to do it, you will find that when you reboot with /unix, one of the critical network processes won't start (took forever to discover this one). If anyone's WIN/3b1.1 rwho can see packets from 4.3bsd machines, I'd like to know how you got it to do that. Last note: For a while one of the 15's would cease receiving over the network. You could network out, but not in. The solution was to reboot. This problem disappeared... [Also, if you have a 3b2 with SysVr3.1 and WIN/3b1.1, your anonymous ftp won't do "ls". The fix is to get a BINARY copy of /bin/ls from a 3b15 running SYSVr2, and put in ~ftp/bin/ls. (don't ask me how I discovered this or why it works, the AT&T solution was to upgrade WIN/3b)] -------- Scott Hammond Dept of Computing & Information Sciences scott@ksuvax1.cis.ksu.edu Kansas State University scott@ksuvax1.BITNET attmail!ksuvax1!scott Manhattan, Kansas {cbosgd,pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!scott (913) 532-6350