cordy@qucis.queensu.CA (Jim Cordy) (06/14/89)
Thanks to all of you who sent me info on getting CAP working on the
GatorBox. I seems that the key problems were:
(i) if you don't apply the patch for bug cpr005, CAP 5.0 does not
work on Sun Unix at all,
(ii) our TCP/IP local net has several subnets each containing many
machines, and CAP seems able to communicate only through the machines
on the particular one that the GatorBox happens to be on, and
in fact to only one host even there because there is only one
/etc/atalk.local, so it can only work through *one* of our fifty
Unix machines sharing the same file systems,
(iii) the default AppleTalk patterns of the form "=:=@*" used by CAP
do not work through the GatorBox, you must literally specify the
exact AppleTalk zone you wish to talk to in every command. So
for example, "atlook =:=@LocalTalk" works, where as "atlook"
does not. Aufs can't be made to work at all without
significant modification because it always uses the "@*" form
no matter what you tell it in its options.
There were assorted other fiddly things that had to be fixed. I
finally managed to get getzones, atlook, atlooklws and lwpr all working,
but I still can't get Aufs to work. It always says it can't register
the server. If anyone knows the way around that one, let me know.
Meanwhile, thanks again to all of you who answered my plea.
By the way, to all of you who noted that Cayman had "fixed" the memory
loss bug in release 1.4 of the GatorBox software: Sorry, nope, you're
wrong, and it's easy to demonstrate. Simply drag a folder tree containing
upwards of 600 files from your Mac hard disk to a Unix directory mounted
through the GB, and after a few minutes you can wave goodbye to the GB.
Still searching for connectivity after all these years.
Cheers
Jim
--
Prof. J.R. Cordy cordy@qucis.queensu.ca
Dept. of Computing andInformation Science James.R.Cordy@QueensU.CA
Queen's University at Kingston cordy@qucis.bitnet
Kingston, Canada K7L 3N6 utcsri!qucis!cordytom@wcc.oz (Tom Evans) (06/19/89)
In article <201@qusunitf.queensu.CA>, cordy@qucis.queensu.CA (Jim Cordy) writes: > but I still can't get Aufs to work. It always says it can't register > the server. Aufs requires Atis to be running (run Atis, sleep 5, run Aufs) to register its name. Atis is hidden in cap/etc. The "start-cap-servers" file is total JUNK - ignore it. I suppose gurus always roll their own :-). If Atis is running, check atalk.local again (nope - you have got the rest running, hmmm.). You're not trying for a remote atis server are you (3rd. line in atalk.local)? > ...memory loss bug... > Simply drag a folder tree containing > upwards of 600 files from your Mac hard disk... 600 files! Egad - that's premeditated cruelty! Of course if the GatorBox had a few dozen megs of virtual memory (maybe we can rpc() a few megs from an unsuspecting host :-)... --------- Tom Evans tom@wcc.oz | Webster Computer Corp P/L | " "I Know" is just 1270 Ferntree Gully Rd | "I Believe" with Scoresby VIC 3179 Australia | delusions of Australia | grandeur." 61-3-764-1100 FAX ...764-1179 |
tom@wcc.oz (Tom Evans) (06/19/89)
In article <201@qusunitf.queensu.CA>, cordy@qucis.queensu.CA (Jim Cordy) writes: > but I still can't get Aufs to work. It always says it can't register > the server. From an answer on another newsgroup from ross@extro: > The only thing I can think of is your portmapper has stolen Port 7?? > (The IP port assigned to afp). You fix this by running the CAP stuff > before portmapper. We had this problem with SunOS 4.0.1 Maybe the NIC-sanctioned 200 ports are immune from this?
cordy@qucis.queensu.CA (Jim Cordy) (06/28/89)
In article <326@wcc.oz> tom@wcc.oz (Tom Evans) writes: > ... >> ...memory loss bug... >> Simply drag a folder tree containing >> upwards of 600 files from your Mac hard disk... 600 files is called a *backup*, and is the most useful thing I can think of that a Unix system can do for a large Mac with a fast hard disk, since true file service through AppleTalk is so slow. > >600 files! Egad - that's premeditated cruelty! Of course if the >GatorBox had a few dozen megs of virtual memory (maybe we can rpc() a >few megs from an unsuspecting host :-)... The memory on the GB has nothing to do with how many files you copy (or shouldn't). The Mac calculates the list and sends them one at a time anyway, and Unix accepts them one at a time. The point of copying 600 is to compund the incremental memory loss bug that the GB has on each file and/or folder access, to the point where it finally runs out. You can demonstrate the same bug by just running your GB for a couple of weeks without a reboot. By the way, we are now running CAP/aufs successfully through the GB and it works *great*. Even if the GB native emulation were working perfectly, CAP/aufs is still better since it provides separate private mount points for each user, and is much faster, so what's the point? Jim -- Prof. J.R. Cordy cordy@qucis.queensu.ca Dept. of Computing and Information Science James.R.Cordy@QueensU.CA Queen's University at Kingston cordy@qucis.bitnet Kingston, Canada K7L 3N6 utcsri!qucis!cordy
chris@cayman.COM (Chris North) (06/29/89)
In article <327@wcc.oz>, tom@wcc.oz (Tom Evans) writes: > Maybe the NIC-sanctioned 200 ports are immune from this? I am not sure if it is true that the 200 ports are immune from a portmapper takeover but I do know that the GatorBox does not yet support the 200 series ports. -Chris -- Chris North chris@cayman.COM Cayman Systems 26 Landsdowne Street Cambridge MA 02139 617-494-1999
chris@cayman.COM (Chris North) (07/04/89)
> Even if the GB native emulation were working perfectly, > CAP/aufs is still better since it provides separate private mount points > for each user, and is much faster, so what's the point? The GatorBox does provide a separate mount point for each user. Each user can mount his or her home directory.-- Chris North chris@cayman.COM Cayman Systems 26 Landsdowne Street Cambridge MA 02139 617-494-1999