Automatic software distribution via HTTP

Adding a web-interface to Store

Petter Reinholdtsen, Telenor Media

Abstract

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.

Keywords:

store, software distribution, automatic software upgrade, tardist, storetar

Introduction

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[1] using HTTP. Store is a software administration tool made at PVV[2], 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.[4] 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 his trustees.

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 supported architecture.

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 downloaded software.

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.

Future work

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[5], CyberCash[6] and Millicent[7] 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.

Conclusion

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.

Acknowledgments

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 inspiring discussions.

No thanks to the Computer Science department at University of Tromsø, for neither help nor support.

References

  1. Store - A System for Third Party Software Installation and Maintenance
    http://www.pvv.unit.no/~arnej/store/storedoc.html
  2. ProgramVareVerkstedet
    http://www.pvv.unit.no/
  3. STORE - Table of Contents
    http://www.pvv.unit.no/~arnej/store/storedoc_toc.html
  4. Store - a System for Handling Third-Party Applications in a Heterogeneous Computer Environment
    ftp://ftp.pvv.unit.no/pub/store/paper.ps
  5. DigiCash
    http://www.digicash.com/
  6. CyberCash
    http://www.cybercash.com/
  7. Millicent
    http://www.w3.org/pub/Conferences/WWW4/Papers/246/

About the Author

Petter Reinholdtsen (http://www.td.org.uit.no/~pere/) <pere@td.org.uit.no> 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 Historical Center.