Date: Sat, 16 Feb 2002 12:53:58 EST From: Ken Harrenstien <klh@panix.com> To: Ken Stailey <kstailey@surfbest.net> Cc: Alan Eldridge <alane@geeksrus.net>, "."@babolo.ru, ports@FreeBSD.ORG, klh@panix.com Subject: KLH10 port (was Re: [ade@FreeBSD.org: suggests installing in a USER's HOME dir]) Message-ID: <CMM.0.90.4.1013882038.klh@panix2.panix.com> In-Reply-To: Your message of Sat, 16 Feb 2002 08:53:15 -0500
next in thread | raw e-mail | index | archive | help
Interesting discussion.
The main problem, as I mentioned earlier, is that the KLH10 emulator
was never expected to be run or installed in the way you are trying to
support. Thus, you are dealing with some difficult issues that have
up until now been avoided, and the software itself isn't currently set
up to help with this.
For example, although there is a KLH10_HOME environment variable, it
is misleading; it is a placeholder that nothing actually uses yet.
Normally one runs while connected to the directory of interest.
Furthermore, after thinking about this overnight, I've come to the
conclusion that sharing a filesystem image is a bad idea even if you
arrange for only one person to use it at a time (which is of course a
good idea in any case; I like your lockf hack). There should be only
a single owner/user. At some future time it may be possible to allow
for read-only virtual packs (I believe TOPS-10 and TOPS-20 can do
this, but not ITS) but even then the storage requirements are a
problem.
Here's what I suggest:
[1] Installation of the KLH10 port should build all the emulator
binaries (including, eventually, the KL versions) and put everything
needed for the next step in a shared location in /usr. Exactly
which location I don't care; /usr/local/klh10, /usr/share/klh10,
whatever. I'll use $SHARED/klh10 to illustrate my examples.
[2] Installation of the PI ITS distribution, due to its large size,
should not store its contents in /usr. Perhaps it could store in
$SHARED/its everything EXCEPT the filesystem image, and include a
new "fetch-its" script that knows how to fetch said image from
ftp.its.os.org.
[3] A new "install-its" script must be provided that allows a user
(root or otherwise) to install a runnable instance of the emulator
plus ITS, based on the package contents previously installed. This
should:
Accept as argument, or create, a new KLH10_HOME owned by the user.
Symlink to (or copy) all the necessary files from $SHARED/klh10
and $SHARED/its.
Fetch and uncompress the PI ITS filesystem image, or accept a
filename to an existing image (tho if this is not owned by
the user, this is asking for big trouble).
Generate and modify a klh10.ini file for this instance.
If you want to permit only root to run a networked KLH10, don't set any
special bits on "dpimp". But if you do want to permit this for anyone
who is allowed to access the shared dpimp program, make it setuid-root.
But the latter is definitely the most dangerous configuration.
A few comments on Ken Stailey's last message:
> The details as pertain to the port. From the top down:
>
> its(1) command. A script. Tells where to pick up the emulator binary
> and what directory the .ini file and emulator bootstrap non-native
> binaries are in. Also does lockf(1) on the filesystem image. The its
> script is told where to find these things from the "make install"
> procedure. The script is located in $PREFIX/bin.
Sounds OK, with modifications to support the new config I suggest
above (ie assumes you have already installed your own copy, and looks
for your KLH10_HOME, perhaps sets it if needed to a default of ~/its.
A system-wide default would be unwise.)
> .ini file. A KLH10 configuration file. Controls where the filesystem
> image is and the emulator IP address. Again "make install" can patch the
> .ini file to control these parameters. Located in
> $PREFIX/share/klh10-ks-its.
This needs to be generated by "install-its" for each user instance.
> Emulator bootstrap files. These are not native binaries but ITS ones
> that are in the native filesystem not the image filesystem. Located in
> $PREFIX/share/klh10-ks-its . Must be in the same directory as the .ini
> file.
Most of these can be shared and the necessary symlinks established by
"install-its".
> Emulator binary (and data conversion support native binaries.) Located
> in $PREFIX/bin.
These were not intended to compete with the vast universe of man(1)
commands. I suggest that the user's PATH include a reference to
$SHARED/klh10/bin or something similar.
> Filesystem image. Defaults to $PREFIX/share/klh10-ks-its. Controlled
> by "make install IMAGE_HOME=/foo"
Not needed in the plan I suggest.
> Documentation. Located in $PREFIX/share/doc/klh10-ks-its
This may be easier to find in $SHARED/{klh10,its}/doc, but whatever
you think best is fine.
Finally...
There is one other thing you need to know before everyone goes off and
tries to run their own ITS. While the distribution includes ITS
bootstrap images, it is a regrettable fact that various things like
the IP host address are hard-wired into the ITS binary, and only a few
variants are provided in the distribution. It's expected that after
you are up, you will configure and build your own ITS (ie by running
MIDAS to rebuild it from source) with the correct addresses and other
things before attempting to make it available over the network.
It's expected that future versions of KLH10+ITS will conspire to make
this all settable from the .ini file, as well as add other
share-friendly things, but we're not there yet.
In the meantime there are ways around this if you only intend to run
it in a local subnet of the 10.x.x.x variety, but it's complicated
enough that the doc for this has not yet been written. (It would be a
great thing if someone did that, hint hint :-). Of course you can
always run without the net, it's just not as interesting.
Does this help?
--Ken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CMM.0.90.4.1013882038.klh>