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.
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 id's as you wish.
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 the section on 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 store 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. This is described in greater detail elsewhere. 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!
The STORE setup script is named 'inistore' and is available in a .tar.gz file together with the STORE scripts themselves.
NOTICE: This script isn't written yet, since I'm not sure what it should do. If this sounds reasonable to anyone, I'll try to implement it so the description fits...
This script will do some sanity checks, and ask you some questions. You should probably have the answers for these questions ready.
First, the inistore setup script will check that it's running as the "store" 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.
Unless /store/store already exists, it will be made.
If you already have some directories under /store/store, the script will ask you if you want to use one of these as the primary store, or alternately, what you want to name the primary store. Using the name of the hosting machine for stores is a strong tradition here, but it may also create some confusion.
The primary store is now made if necessary, and the primary administrative
area with initial files is placed in
/store/store/<primary>/Adm
for sharing in your admistrative domain. Additionally,
/store/store/Adm
is made a symlink to
/store/store/<primary>/Adm, and
the main directories are made in the administrative area:
bin/, etc/, logs/, and reports/.
The script will try to find the 'hostname' or 'uname' commands for determining the machine's name. If both fail, you are given a warning that this will lead to problems later. If only 'uname' is found, a hostname script is put into the bin/ directory in the administrative area.
The script will try to find perl. If it doesn't find perl, it will ask if you have perl some nonstandard place.
The script will ask you what shell the "store" user will run. If the shell is not one of the supported shells, some features will be unavailable, and you will need to do the shell setup (.profile equivalents) manually. If the shell is on the supported list, you will get some shell-specific questions. For (t)csh, you would be asked if you have a common file to source in the "store" user's .cshrc file, and similarly for .login. For bash, .bash_profile and .bashrc are similarly constructed, while .profile is set up for sh and ksh.
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.
The script also makes an initial version of the configuration files in the etc/ directory. At this point, the script needs to know the architecture for your machine. The script will probably not be able to figure this out.
If it turns out your architecture isn't in the predefined list of architectures, the script will need some extra information:
Last, 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).
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", except that it does not send mail. Since the output is then logged, it may be examined if needed.
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 EMACSLOADPATH, INFOPATH, MANPATH, PAGER and LD_LIBRARY_PATH.
arnej@lise.unit.no