Go to the first, previous, next, last section, table of contents.
This chapter has some background information on STORE: The
background and history of STORE, the authors, the current TODO
list, and where to reach us.
- Problem: The problem background that created STORE
- History: The history of STORE
- Authors: About the authors.
- Todo: Todo-list.
- Contacts: Where to reach us, and how to get STORE
STORE was created out of the needs that we felt, managing a large,
heterogenous network of Unix machines. Despite claims in trade
rags, administrating unix isn't trivial. A list of factors create
complexity in the total system (different hardware, different OSes,
lots of third-party programs, different versions of "everything").
This complexity makes for a messy and unmanageable system. Some of the
most common problems a system administrator meets is:
/local/man/man1 often contains a great mass of files, but nobody
really knows what all the files do. Nobody dares to remove
anything, because it may be important.
A short while after a program is installed, nobody is really sure that
it is still consistent, because nobody is sure what files belong to that
Often it is unclear what version of a program that is actually installed,
since many programs do not have any means of displaying version or
patchlevel. The source code may not be available, or (worse) only the
source code for another, older version is available.
Because of limited disk space, source code is often removed shortly after
installing a program. Later, one realizes that a great deal of work had
been spent locally on porting and adjusting the program to fit the local
machines and setup. Source code is sometimes available on backup, but
finding it may be very time-consuming.
When the next version of the program needs to be installed, the same
adjustments must be reconstructed. The same problems appear when one
fixes a bug locally that is not merged into the official distribution.
On the other hand, source code may be lying around for ages because
everyone believes it is precious and cannot be regenerated.
Different people install programs in different ways and use different
file system layouts. Even if there are a local strategy, some programs
will not fit because they require special treatment. If you want to find
all files belonging to a program, you must spend a long time looking
through your file system.
When managing several separate installation and has to separately install
programs on all systems, they are often only installed on a subset of
the installations, where the installer needs them him/herself, or where
the pressure from users is greatest. Thereby some installation must
do without some programs, or they are left with old versions.
To obtain good performance, it is often desirable to make copies of programs
on several machines for use from local disk, but administrating this
distribution takes a lot of time.
Making report generators for what programs are available or finding unneeded
files is near-impossible,
These are the problems STORE is trying to solve.
The idea and basic concepts behind STORE has evolved from the
similar "depot" system made by NIST and CMU. The first
pilot version was implemented (mostly with shell scripts) and saw
some use on the student computing labs.
Later, a new and enhanced prototype version was implemented
on behalf of the IMF by Anders Christensen, a student at IDT, as
a half-year project (spring of 1992). It was renamed STORE so
as not to be confused with the NIST/CMU depot system.
At this time, the basic concepts were well-defined. Coming into full use
at IMF and Alkymi, many of the more practical tools made possible by
STORE was written, and needed optimizations was implemented. During the
following year, the internals of STORE changed a great deal, and
attempts was made to translate most of the programs' external interfaces
The original versions of STORE was conceived and implemented by Anders
Christensen. Arne Henrik Juul did a lot of the improvements and further
hacking as well as writing the examples on how to install software under
STORE. Steinar Bang wrote the original version of this TeXinfo document,
translating documentation written by the other two and adding some of his
own. Also involved with the underlying algorithms has been Tor Egge.
This section holds the current todo list for STORE:
Update the TODO list.
Flesh out, clarify, and generally clean up this documentation.
Write some more documentation, man-pages, etc.
Document generic architectures, version levels,
and several versions (in progress).
inistore distribution and installation script
for STORE. Document it.
Make STORE easier to configure.
Consistency checking of the STORE scripts.
Better (automatic) notification of newly installed packages. Maybe
automatically posted to USENET newsgroups or sent by email.
Better possibilities to ignore applications, just getting reports
when new versions arrive.
Finish translation of STORE to English. Mostly done.
proginfo, a user-oriented script.
Automate patch generation and auto cleanup of compile trees.
Creating tools for browsing the entire STORE installation for installed
program packages. Maybe making the information available with
gopher would be a good idea?
Actually implement the
status tool, reporting disk usage,
Precompute disk space requirements and avoid filling up
disks. This requires some way of getting the free/total
space on the disk, which probably means requiring GNU df.
Make the scripts more resistent to network problems.
Support dependencies between applications, so e.g. xdvi can be dependent
upon TeX fonts being installed.
Make postinst more robust by checking a database of notlinks patterns,
and implement some link tree locking to avoid several people trying
to use postinst at the same time, or someone using postinst as the
same time as cclient is deleting files and running nightly commands.
Better support for setuid/setgid programs. Today, you get a
message that something needs to be done, and have to fix
these problems manually.
Fix so cclient checks notlinks and complains if there's just a link,
Better support empty directories and directories with special
permissions. Today, only files in the version trees are significant, and
you need to add additional "nightly jobs" to fix permissions.
cclient even deletes empty directories in the link tree.
Make implementation as database of relations possible, so you don't
need the actual symlinks, but can hardlink or copy directly into
the (now) link tree.
Make a track interface and .tar.gz interface for machines wanting
to run programs compiled for STORE by just unpacking into
their `/store' directories (which may be just a symlink to
Make a track or ftp transport mode, instead of using NFS. This will
greatly boost reliability and performance over WANs.
Investigate the possibilities of implementing a user-level NFS server
doing the link tree to actual file conversion.
Changing the `linkup' and `linkdown' tools so that they
can be run by the owner of a particular directory. This would mean
that people could install STORE packages without knowing the
password of the "repository" user (someone with system priviledges would
create a package directory and changing the user to the account of
the maintainer and the group ownership to the "repository" group).
An `install' script that will attempt to infer the installation
directory and instead install into the version tree with a suitable
suffix. This is to "trick" `Makefiles' into installing programs
directly into the version tree. The `install' script should
guess the correct installation directory from names like
`/usr/bin', `/local/bin', and so on, to make it easier to
install software without a flexible installation setup.
For electronic mail contact, try
email@example.com and if
you do not receive a prompt answer, try
whereby you'll reach a greater group using STORE.
The primary distribution site for STORE is
our local FTP server. Currently it is put into the
/local/store directory in the anonymous FTP area.
To reach us by phone, try:
+47 7359 3535 - ask for Arne H. Juul
+47 7359 3681 - ask for Anders Christensen
Go to the first, previous, next, last section, table of contents.