From owner-freebsd-ports Sat Feb 16 9:54: 7 2002 Delivered-To: freebsd-ports@freebsd.org Received: from mail3.panix.com (mail3.panix.com [166.84.0.167]) by hub.freebsd.org (Postfix) with ESMTP id E155037B400 for ; Sat, 16 Feb 2002 09:53:59 -0800 (PST) Received: from panix2.panix.com (panix2.panix.com [166.84.1.2]) by mail3.panix.com (Postfix) with ESMTP id 7996B9820B; Sat, 16 Feb 2002 12:53:58 -0500 (EST) Received: (from klh@localhost) by panix2.panix.com (8.11.3nb1/8.8.8/PanixN1.0) id g1GHrwT24078; Sat, 16 Feb 2002 12:53:58 -0500 (EST) Date: Sat, 16 Feb 2002 12:53:58 EST From: Ken Harrenstien To: Ken Stailey Cc: Alan Eldridge , "."@babolo.ru, ports@FreeBSD.ORG, klh@panix.com Subject: KLH10 port (was Re: [ade@FreeBSD.org: suggests installing in a USER's HOME dir]) In-Reply-To: Your message of Sat, 16 Feb 2002 08:53:15 -0500 Message-ID: Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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