Automatic software distribution via HTTP
Adding a web-interface to Store
Petter Reinholdtsen, Telenor Media
Store is a software administration tool which gives consistent
configuration and distribution in an heterogeneous UNIX environment.
It was originally implemented using NFS as the transport protocol.
This paper presents an implementation of Store using HTTP. This
enables distribution of Store application across firewalls and
filtering routers. With this infrastructure it is possible for
network aware software to query it's main site about new versions, and
automatically upgrade itself.
store, software distribution, automatic software upgrade, tardist, storetar
Automatic software distribution in an heterogeneous UNIX environment
can save many hours of labor. With such infrastructure implemented it
not only simplifies system administration, but also enables network
software to automatically inform the user of new releases or even to
automatically upgrade itself over the net.
This paper presents an extension of Store using HTTP. Store is a
software administration tool made at PVV, an Computer Students
Association at the University of Trondhjem, Norway. For long, I have
been planning to extend Store to use HTTP. This was mostly because
Store's regular transport-mechanism, NFS, is extremely insecure.
Because of this insecurity, firewalls and some routers will not allow
NFS-traffic. HTTP on the other hand is considered harmless.
This summer I had the pleasure of testing SGI's tardist. This is
an HTTP/WWW extension of their normal distribution format. Being
placed on the wrong side of an NFS-filtering router, I was very eager
to implement Store using HTTP.
Description of Store
Store is a system administration tool suite, which targets the
maintenance and distribution of third party application in an
heterogeneous environment. Third party application is defined as
[...], any group of programs and data files that forms a
logical unit and can be isolated from the operating
system. Normally this is some .tar.gz-distribution found
on the Internet.
Store uses NFS as the transport protocol, and a bunch of
perl scripts to maintain and distribute the application. The
source-code and the "original" binary version of the application
resides on a "Master store". The binary version is automatically
copied to "Slave stores" who serves the architecture in question.
The appropriate version is placed in a "link three", which is
soft-links into the local Slave or Master store. Store uses three
"axes" (domain, architecture and level) to choose the appropriate
version for the given system configuration. Every file is given a
position on the axes.
This system allows flexible and consistent application management
of different setup for different systems.
To allow software transfer via unsecure channels, Stig S. Bakken at
PVV is working on application signing. Each sysadm will sign the
files he inserts on the master store. The sysadm on the slave store
can then choose who he trust, and only fetch the versions compiled by
Store also has functions to simplify compiling and configuring the
applications. These features are not described in this paper.
Store via HTTP
Store via HTTP presents the local slave or master store to the net.
It presents three different "views" to the store; application list,
application info and application binaries/source. Different
parameters are given to specify the wanted information. To the list
of application, normal parameters will be wanted architecture, level
(alpha/beta/release/old) or date of change. The application name is
required for the application info. The info-page is used by automatic
software upgrade to get information about the latest versions and
The HTTP server side is implemented as a standard CGI-script. The
script either returns formatted or unformatted lists (application list
and info), or on-the-fly .tar.gz-files (binaries and source).
The client side is some perl-scripts which either connects to the HTTP
server and downloads the wanted application, or unpacks the already
By adding a new mime-type (application/x-storetar) to the users
.mailcap and the appropriate programs to handle it, the user is able
to browse the list of available software, and receive and install the
software locally using a normal web-browser. To install the software,
the client program unpacks the newly downloaded .tar.gz-file in the
slave store directory. Currently the software must be downloaded and
installed by the sysadm-user "store", but with suid-programs and
password protection, any user could install software.
Automatic software upgrade
Automatic software upgrade enable network-aware software to connect to
the original site, and asks about the last version. If there is a
newer version available, the user is given the opportunity to
automatically replace the old binaries/configuration files with new
ones which are fetched over the net.
To enable secure upgrade over the net, the software and the address
of the master site must be signed, to prevent compromised software to
enter the system. With an public key-system, the author/distributer
can distribute the public key and the with the initial package.
Store via HTTP only gives the infrastructure to distribute software.
To fully explore the opportunities support for encrypting, payment and
global caching must be developed.
Encrypting gives the opportunity to restrict the availability of
software in a more controlled way. The software can be downloaded by
anyone, but only unpacked and used by the authorized sysadm.
Payment will enable the copyright owner of the application to sell
the software via the Store HTTP infrastructure. Different solution to
this problem are currently being tested. DigiCash, CyberCash
and Millicent are some of the proposed systems.
Global caching should be implemented to reduce the bandwidth used in
distributing the software. This could be solved by implementing a
more intelligent interaction with the normal web-caches.
When the software administration tool Store is given an HTTP-based
infrastructure, it no longer inherit the drawbacks of NFS. It is now
possible to automatically fetch software thru firewalls and filtering
routers. Via the HTTP-store infrastructure it is also possible to
implement automatic software upgrading for network-aware applications.
There is still some missing parts in Store, notably signing of
software and software caching. The first part is being incooperated
in the main Store distribution. The second could be solved using the
normal web-caches. The current HTTP-Store server needs some tuning
for optimized caching.
Thanks to Per Einar Dybvik, Telenor Media, for inspiring me to write
this paper (and paying me while implementing :-). Thanks to Stig
S. Bakken, University of Trondheim, for information about Store and
many gory details. Thanks to Ken Ronny Schouten for moral support and
No thanks to the Computer Science department at University of
Tromsø, for neither help nor support.
- A System for Third Party Software Installation and Maintenance
- STORE -
Table of Contents
- Store - a
System for Handling Third-Party Applications in a Heterogeneous
About the Author
Petter Reinholdtsen (http://www.td.org.uit.no/~pere/)
<email@example.com> is an undergraduate at the University of
Tromsø. His main interest is distributed information systems
and the Internet. He has been working with Internet services and web
since he formed the first team at the Internet Hunt. He has been in
from the start at the Norwegian Telecom's main web-services, Telenor Origo at Telenor Media.
The last to years he has also been working part time as
webmaster/designer at the university library and the Norwegian