This chapter has instructions on how to set up a STORE system. It mostly assumes you are setting up a brand new STORE system on a site where STORE hasn't been used before, but is also useful if you're setting up a new STORE administrative domain, and are going to cooperate with other administrators in your organization. In this case, you should probably get some of the other administrators to help you out. In particular, if you're installing STORE somewhere at the University of Trondheim, please contact us first!
Short checklist of preliminaries:
If you are in doubt on these, read the next section carefully!
This is a quite long description of the preliminary actions to take before you can really start installing STORE, explaining in detail the 'Needed Items' list of requirements .
The STORE program system has some special requirements that must be dealt with before installing the STORE system itself. The most troublesome requirement is that STORE really needs a decent bit of disk space. If you are installing STORE on a large installation with lots of old applications, you will probably want to keep the old applications running while you install STORE and alternative versions of your applications there. If you don't already have some space free, the advised course is buying a disk before installing STORE. A 300MB partition is good for trying out STORE, while a full installation with some architectures would call for at least 1GB on the main server.
After getting some disk space, you need to make it available under `/store' on all the machines that should run STORE. First, let's look at a standalone system. In this case, make a big partition and mount it as `/store'. (Or alternately, make a symlink from `/store' to another partition - say `/usr/local/store' - that has some free space).
You also need to decide which user should own `/store' and run the STORE scripts. The recommended way is to make a specific "store" user and a "store" group. Currently at the University of Trondheim, this user is uid 52 and the group gid 52, and the "store" user should run "bash" or "tcsh" as shell. Using csh or ksh as equivalents for these should also work, and if you're starting a new, separate STORE installation, you can choose other id's if necessary.
The home directory for the "store" user should be taken to be the location of the administrative area for STORE, the `/store/store/Adm' directory. See section The administrative area.
At this point, you are ready for running the initial STORE setup script (as the "store" user).
Extra requirements when setting up a differing cases of repository servers: In the common case, you need to export the `/store' directory and possibly any `/store/store/<server>' directories. STORE is written to permit readonly mounting everywhere, since exporting readonly to the world is both simple and secure.
The clients need to mount the server's `/store' on `/store'. If you have a heterogenous setup, for example you have Sun clients running from an SGI server (or conversely), you need an extra linktree for the clients. See section A configuration file with foreign linktrees. You should also propagate the "store" user to the clients.
With all the different setups for mounting and exporting disks, and distribution password information, it is impossible to specify exactly what actions you need to take to export the filesystems from the server, mount them on the clients, and make a common "store" user. If you don't know how to do this on your machines already, you probably need to find out anyway, or hire someone who knows how. Giving specific examples here would be of doubtable use, seeing as there are different export file formats (and names), fstab formats (and names), two different automounters with differing setups, and a couple of NIS/YP versions here already.
(NOTE: I will try to include some amd examples, at least. -arnej)
In addition to all of this, you need the perl scripting language. Decent vendors actually ship perl as part of the operating system these days, and most sites quickly install it otherwise. If you haven't got it already, you need to compile and install it yourself, or get a binary version from somewhere. Perl is also needed for running many other system administration tools, so the sooner you get it, the better!
If you find you need perl, we have a package with perl for
various platforms available from ftp.unit.no in
`/local/store/perl-4.036.tar.Z'. This is also a good
example of a STORE application.
The STORE setup script is named 'inistore' and is available
together with the STORE scripts themselves from
ftp.ntnu.no in `/local/store/inistore-1.80.tar.Z'.
This script will do some sanity checks, and ask you one (possibly two) questions: Are you installing a new primary repository, and if not, what is the nearby primary repository named. See section Cooperating administrative domains.
First, the inistore setup script will check that it's running as the "repository" user, using the 'id' command. If this command is missing, or the output is not recognized as correct, the script will give a warning, and ask if you want to continue.
Then, the script checks that the `/store' directory exists and is owned by the user. If this fails, the script will abort with a fatal error.
The script needs either uname -n or hostname to
work, and will use the short form of the hostname as the name for
the repository. If only uname is found, the script will create
a hostname script in the administrative area.
If you already have the `/store/store/<host>/Adm/' directory, the script will ask you if you want it removed and reinstalled.
The administrative area with initial files is unpacked into
/store/store/<host>/Adm
for sharing in your admistrative domain. Additionally,
/store/store/Adm
is made a symlink to
/store/store/<primary>/Adm.
The script will copy the perl scripts used by STORE into
/store/store/<primary>/perl-internal and set this up as a
STORE application. The `/store/etc/internal' directory
will be made, with softlinks pointing to the perl-internal
application. You should not need to change the scripts in the
perl-internal application. (The internal nature of the scripts
are still changing fast, and isn't documented at all, so you
would need to know a lot about both STORE and perl to do real
modifications). However, on the primary repository you need to
maintain the files under `perl-internal/src/cf'
(See section The genarchs configuration file).
The script will try to determine a list of directories to use as a PATH when running scripts. It will try some well-known directories, and will also try using the common files given at the previous questions if possible. This is used in an initial version of the 'nightly' shell script in the bin directory.
After running the setup script, you still do not have a complete setup. These are the things you may want to do:
One of the most important things if you want a stable STORE system is to ensure that the nightly script (named `night.sh' or `nightly') runs regularly, and that the output is taken into consideration by the person(s) maintaining your STORE.
The nightly script should run the `batch' update scripts cmaster.pl, cslave.pl, cclient.pl on all machines in your administrative domain, and report.pl and status.pl once for the whole administrative domain.
If your machine is running standalone (your administrative domain is
just this machine), the scripts can be started directly. In all other
cases, some sort of remote job must be started. The normal case is to
run the scripts via the rsh or remsh commands. This may
provoke a need for `.rhosts' files in the STORE administrative
area, and may also need other customization.
Also, the nightly script needs to have a sensible default PATH variable. The setup script will guess a value, but you probably want to change it.
Lastly, the nightly script needs to send its results via mail to the STORE maintainers. This must be customized manually - both the list of recipients and the way to invoke the mail program probably needs changing.
One problem with the current nightly script is that installation of new versions of programs produces many warnings about links being changed and files being copied. The simplest way of dealing with this is just by running the nightly script twice and only collecting warnings on the second go, thus getting just the persistent output -- presumably errors that need manual fixing. This may be done by running "nomail.sh" first, then "night.sh" afterwards. "nomail.sh" is exactly like "night.sh", but all output comes directly on stdout. Note that if you run it from cron, the output is not saved.
For further help, there are some examples (See section night.sh script examples).
The standard user login should be changed to make users find the software installed under STORE. In addition, certain environment variables may need to be set to make programs work correctly when installed in STORE.
Changing the PATH to include `/store/bin' and `/store/gnu/bin' in appropriate places should be self-evident. However, you will probably also need to change the `XFILESEARCHPATH' environment variable, since you now have some application-default files in STORE, and some in your 'normal' old location. (Here, we have app-defaults directories under `/usr/lib/X11', `/store/lib/X11', `/local/lib/X11', and `/local/X11/lib/X11' !)
Some other environment variables that may need proper setting are `INFOPATH', `MANPATH', `EMACSLOADPATH', `PAGER' and `LD_LIBRARY_PATH'.
Go to the first, previous, next, last section, table of contents.