At 08:59 AM 2/17/2005, Ken Harrenstien wrote:
> > Thanks for the info, Ken. I'll make sure we have such a machine available.
> >
> > I have a question about the cloning process, and I'd appreciate help in
> > understanding the details.
> >
> > You talked about a clone/prune. Does the making the initial clone involve
> > cloning the entire TOPS-20 virtual environment on Doug's machine from
> > within Linux, or from within TOPS-20? I had understood that it wasn't
> > practical to start out initially with a clean PDP-10/TOPS-20 installation
> > and simply load a dump of the Augment directories into it, and that it
> > would be better to initially snapshot the entire TOPS-20 environment
> > and file system. Is that the case?
>
>Yes.
>
> > As a point of reference, I'm not familiar with how the PDP-10/TOPS-20
> > environment lives under Linux, but in other systems I'm familiar with,
> > there is a very large file on the host file system for each volume of the
> > virtual file system. The virtual OS and virtual user files live in these
> > volumes. The emulator running on the host OS mounts the volume files,
> > and boots the virtual OS from a system volume. Is what I just described
> > the case here?
>
>Yes, if what you call a "volume" corresponds to a disk drive (or disk
>pack). The KLH10 emulator is strictly a hardware emulator. (01)
That's the case. Ah yes, disk packs -- takes me back to the 70's, almost
makes me feel young again! (02)
> > If so, is the initial clone done by installing your PDP-10 emulator on a
> > new Linux system, copying all the volume files to the new Linux system,
> > then configuring the emulator to mount the volume files and boot from
> > the system volume? (I'm assuming that a "structure" is how one refers
> > to a disk volume under TOPS-20.)
>
>With the above terminology caveat, yes. I should also note that a
>TOPS-20 "structure" is at least one disk large, but can span multiple
>disks. Contrast that with its Unix "filesystem" analog, which can
>live on part of a disk but does not (except for more esoteric types
>of filesystems) normally span multiple disks.
>
> > If all that is the case, then to ensure the privacy of Doug's files, it
> seems
> > like Rayleen would need to control the new Linux machine until she can
> > log in and remove all user accounts and personal files. To avoid having
>
>Not necessarily. She can bring up the clone on their own machine
>(it has enough power to drive two emulators at full speed) and that's
>what I've been assuming we would do. We would not transfer anything
>that had not already been vetted.
>
> > stray blocks of deleted files at this point, it seems like we'd need to use
> > DUMPER with a full wild-card specification (<*>*.*.*) to create a virtual
> > tape for each volume. Are these virtual tapes what we would consider
> > a first snapshot of a "clean" Augment sytem, and how would we reload
> > them into a fresh PDP-10/TOPS-20 environment? It seems like this
>
>Yes. We can use MTBOOT (magtape boot) for this purpose. There is
>(should be) some doc on the procedure in the KLH10 doc/ subdirectory. (03)
Thanks, that clarifies a few things. So the virtual tape she transfers will
presumably be a "clean" clone that we could also use as the basis of an
initial distribution. (04)
> > assumes all the virtual files we need live on isolated TOPS-20 volumes.
> > Is this a valid assumption for Augment?
>
>I'm not sure what you're puzzled about here. No file spans multiple
>volumes, if that's what you mean. You can come up with just the PS:
>structure (i.e. one drive) and then add the others. There will be a
>few initial hiccups with some Augment startup scripts that expect to
>find the other structures present, but none of that will prevent
>TOPS-20 or its core utilities from running. (05)
It was a misunderstanding on my part about how we restore from the
virtual tapes. I had slipped back into thinking of the case where we DUMP
only the structures that contain NLS/Augment, and reload them into a
freshly installed TOPS-20 system. I can see that's not the case initially. (06)
> > Sorry for all the questions, but I really want to understand the process
> > of in detail so that I can explain it accurately to others.
>
>No problem.
>
>There is one minor issue I should also mention that has a bearing on
>why we would go with a trimmed clone rather than start from scratch.
>The version of TOPS-20 that BI is using is essentially a copy of the
>SRI-NIC system, which used a monitor that was locally modified to
>handle structures of extended size -- more bits in the disk addresses.
>This affects enough things (like BOOT, MTBOOT, CHECKD) that they all
>have to be used together. AUGMENT itself doesn't depend on it, but
>until we have the luxury of learning how to re-install AUGMENT on a
>more "vanilla" TOPS-20, we have to keep using what's there.
>
>(Also, Doug's current incarnation does not include the SRC: structure,
>which contained all of the source code for the SRI-NIC TOPS-20 monitor
>and utilities. He has a tape, and I may have a copy of that tape, but
>we've never tried to repopulate/regenerate things from source.) (07)
I can see both technical and licensing issues here if we were ever
to turn this cloned system into an initial release to the community.
Presumably SRI still "owns" these monitor hacks, and not Boeing,
who presumably owns Augment. If the size of the Augment system
and journals is large enough to require the hacked monitor, then
we'd need to "kit" the monitor as part of a future Augment release
that installs on a "vanilla" TOPS-20. We'll burn that bridge once
we've crossed it. (08)
>--Ken
>
>
> > Thanks,
> >
> > At 11:49 PM 2/16/2005, Ken Harrenstien wrote:
> > > > When would you have some time to do the clone of Doug's
> > > > machine? If you could give me a couple of dates/times,
> > > > I can contact Raylene Pak about working with Doug to
> > > > expunge all but the guest account on the cloned system,
> > > > and contact Doug to see which time he'd prefer.
> > >
> > >We're in the middle of changing over to new hardware, so maybe wait a
> > >week for things to stabilize and then check again. All you really
> > >need is to get a good Linux box up on the net, accessible only via SSH
> > >(I can send you my ssh key), and I can download whatever Raylene
> > >generates, at my convenience.
> > >
> > >I should mention that your box really should have two ethernet NICs on
> > >it, both plugged into the same LAN, to compensate for brain damage on
> > >the part of the Linux networking code. Otherwise you can't telnet
> > >from the native system into the TOPS-20 running on the emulator.
> > >
> > >You'll also need to assign/reserve suitable static IP addresses and
> > >hostnames for the virtual TOPS-20(s) you want to run. DHCP won't do.
> > >
> > >--Ken
> >
> >
> > Philip Gust
> > Nouveau Systems, Inc.
> >
> > phone: +1 650 961-7992
> > fax: +1 508 526-8142
> >
> >
> > mailto: gust@NouveauSystems.com
> >
> > (09)
Philip Gust
Nouveau Systems, Inc. (010)
phone: +1 650 961-7992
fax: +1 508 526-8142 (011)
mailto: gust@NouveauSystems.com (012)
|