reports/269/Overview.html

   1 <HTML>
   2 <HEAD>
   3 <TITLE>Automatic software distribution via HTTP</TITLE>
   4 <!-- Changed by: Petter Reinholdtsen, 31-Jan-1996 -->
   5 <!-- Deadline 29. january 1996 -->
   6 </HEAD>
   7 <BODY>
   8 <H1 ALIGN=center>Automatic software distribution via HTTP</H1>
   9 <H2 ALIGN=center>Adding a web-interface to Store</H2>
  10 <ADDRESS>Petter Reinholdtsen, Telenor Media</ADDRESS>
  11 <H2>Abstract</H2>
  12
  13 Store is a software administration tool which gives consistent
  14 configuration and distribution in an heterogeneous UNIX environment.
  15 It was originally implemented using NFS as the transport protocol.
  16 This paper presents an implementation of Store using HTTP.  This
  17 enables distribution of Store application across firewalls and
  18 filtering routers.  With this infrastructure it is possible for
  19 network aware software to query it's main site about new versions, and
  20 automatically upgrade itself.
  21
  22 <H2>Keywords:</H2>
  23 store, software distribution, automatic software upgrade, tardist, storetar
  24
  25 <H2>Introduction</H2>
  26
  27 Automatic software distribution in an heterogeneous UNIX environment
  28 can save many hours of labor.  With such infrastructure implemented it
  29 not only simplifies system administration, but also enables network
  30 software to automatically inform the user of new releases or even to
  31 automatically upgrade itself over the net.
  32
  33 <P>This paper presents an extension of Store[1] using HTTP. Store is a
  34 software administration tool made at PVV[2], an Computer Students
  35 Association at the University of Trondhjem, Norway.  For long, I have
  36 been planning to extend Store to use HTTP.  This was mostly because
  37 Store's regular transport-mechanism, NFS, is extremely insecure.
  38 Because of this insecurity, firewalls and some routers will not allow
  39 NFS-traffic.  HTTP on the other hand is considered harmless.
  40
  41 <P>This summer I had the pleasure of testing SGI's tardist.  This is
  42 an HTTP/WWW extension of their normal distribution format.  Being
  43 placed on the wrong side of an NFS-filtering router, I was very eager
  44 to implement Store using HTTP.
  45
  46
  47 <H2>Description of Store</H2>
  48
  49 Store is a system administration tool suite, which targets the
  50 maintenance and distribution of third party application in an
  51 heterogeneous environment.  Third party application is defined as
  52 <CITE>[...], any group of programs and data files that forms a
  53 logical unit and can be isolated from the operating
  54 system.</CITE>[4]  Normally this is some .tar.gz-distribution found
  55 on the Internet.
  56
  57 <P>Store uses NFS as the transport protocol, and a bunch of
  58 perl scripts to maintain and distribute the application.  The
  59 source-code and the "original" binary version of the application
  60 resides on a "Master store".  The binary version is automatically
  61 copied to "Slave stores" who serves the architecture in question.
  62
  63 <P>The appropriate version is placed in a "link three", which is
  64 soft-links into the local Slave or Master store.  Store uses three
  65 "axes" (domain, architecture and level) to choose the appropriate
  66 version for the given system configuration.  Every file is given a
  67 position on the axes.
  68
  69 <P>This system allows flexible and consistent application management
  70 of different setup for different systems.
  71
  72 <P>To allow software transfer via unsecure channels, Stig S. Bakken at
  73 PVV is working on application signing.  Each sysadm will sign the
  74 files he inserts on the master store.  The sysadm on the slave store
  75 can then choose who he trust, and only fetch the versions compiled by
  76 his trustees.
  77
  78 <P>Store also has functions to simplify compiling and configuring the
  79 applications.  These features are not described in this paper.
  80
  81 <H2>Store via HTTP</H2>
  82
  83 Store via HTTP presents the local slave or master store to the net.
  84 It presents three different "views" to the store; application list,
  85 application info and application binaries/source.  Different
  86 parameters are given to specify the wanted information.  To the list
  87 of application, normal parameters will be wanted architecture, level
  88 (alpha/beta/release/old) or date of change.  The application name is
  89 required for the application info.  The info-page is used by automatic
  90 software upgrade to get information about the latest versions and
  91 supported architecture.
  92
  93 <P>The HTTP server side is implemented as a standard CGI-script.  The
  94 script either returns formatted or unformatted lists (application list
  95 and info), or on-the-fly .tar.gz-files (binaries and source).
  96
  97 The client side is some perl-scripts which either connects to the HTTP
  98 server and downloads the wanted application, or unpacks the already
  99 downloaded software.
 100
 101 <P>By adding a new mime-type (application/x-storetar) to the users
 102 .mailcap and the appropriate programs to handle it, the user is able
 103 to browse the list of available software, and receive and install the
 104 software locally using a normal web-browser.  To install the software,
 105 the client program unpacks the newly downloaded .tar.gz-file in the
 106 slave store directory.  Currently the software must be downloaded and
 107 installed by the sysadm-user "store", but with suid-programs and
 108 password protection, any user could install software.
 109
 110
 111 <H2>Automatic software upgrade</H2>
 112
 113 Automatic software upgrade enable network-aware software to connect to
 114 the original site, and asks about the last version.  If there is a
 115 newer version available, the user is given the opportunity to
 116 automatically replace the old binaries/configuration files with new
 117 ones which are fetched over the net.
 118
 119 <P>To enable secure upgrade over the net, the software and the address
 120 of the master site must be signed, to prevent compromised software to
 121 enter the system.  With an public key-system, the author/distributer
 122 can distribute the public key and the with the initial package.
 123
 124 <H2>Future work</H2>
 125
 126 Store via HTTP only gives the infrastructure to distribute software.
 127 To fully explore the opportunities support for encrypting, payment and
 128 global caching must be developed.
 129
 130 <P>Encrypting gives the opportunity to restrict the availability of
 131 software in a more controlled way.  The software can be downloaded by
 132 anyone, but only unpacked and used by the authorized sysadm.
 133
 134 <P>Payment will enable the copyright owner of the application to sell
 135 the software via the Store HTTP infrastructure.  Different solution to
 136 this problem are currently being tested.  DigiCash[5], CyberCash[6]
 137 and Millicent[7] are some of the proposed systems.
 138
 139 <P>Global caching should be implemented to reduce the bandwidth used in
 140 distributing the software.  This could be solved by implementing a
 141 more intelligent interaction with the normal web-caches.
 142
 143 <H2>Conclusion</H2>
 144
 145 When the software administration tool Store is given an HTTP-based
 146 infrastructure, it no longer inherit the drawbacks of NFS.  It is now
 147 possible to automatically fetch software thru firewalls and filtering
 148 routers.  Via the HTTP-store infrastructure it is also possible to
 149 implement automatic software upgrading for network-aware applications.
 150
 151 There is still some missing parts in Store, notably signing of
 152 software and software caching.  The first part is being incooperated
 153 in the main Store distribution.  The second could be solved using the
 154 normal web-caches.  The current HTTP-Store server needs some tuning
 155 for optimized caching.
 156
 157
 158 <H2>Acknowledgments</H2>
 159
 160 Thanks to Per Einar Dybvik, Telenor Media, for inspiring me to write
 161 this paper (and paying me while implementing :-).  Thanks to Stig
 162 S. Bakken, University of Trondheim, for information about Store and
 163 many gory details.  Thanks to Ken Ronny Schouten for moral support and
 164 inspiring discussions.
 165
 166 <P>No thanks to the Computer Science department at University of
 167 Troms&oslash;, for neither help nor support.
 168
 169 <H3>References</H3>
 170 <OL>
 171
 172 <LI><A HREF="http://www.pvv.unit.no/~arnej/store/storedoc.html">Store
 173 - A System for Third Party Software Installation and Maintenance</A>
 174 <BR>http://www.pvv.unit.no/~arnej/store/storedoc.html
 175
 176 <LI><A HREF="http://www.pvv.unit.no/">ProgramVareVerkstedet</A>
 177 <BR>http://www.pvv.unit.no/
 178
 179 <LI><A HREF="http://www.pvv.unit.no/~arnej/store/storedoc_toc.html">STORE -
 180 Table of Contents</A>
 181 <BR>http://www.pvv.unit.no/~arnej/store/storedoc_toc.html
 182
 183 <LI><!-- 4 --><A HREF="ftp://ftp.pvv.unit.no/pub/store/paper.ps">Store - a
 184 System for Handling Third-Party Applications in a Heterogeneous
 185 Computer Environment</A>
 186 <BR>ftp://ftp.pvv.unit.no/pub/store/paper.ps
 187 <LI><!-- 5 --><A HREF="http://www.digicash.com/">DigiCash</A>
 188 <BR>http://www.digicash.com/
 189 <LI><!-- 6 --><A HREF="http://www.cybercash.com/">CyberCash</A>
 190 <BR>http://www.cybercash.com/
 191 <LI><!-- 7 --><A HREF="http://www.w3.org/pub/Conferences/WWW4/Papers/246/">Millicent</A>
 192 <BR>http://www.w3.org/pub/Conferences/WWW4/Papers/246/
 193 </OL>
 194
 195 <H3>About the Author</H3>
 196
 197 Petter Reinholdtsen (<A HREF="http://www.td.org.uit.no/~pere/">http://www.td.org.uit.no/~pere/</A>)
 198 &lt;pere@td.org.uit.no&gt; is an undergraduate at the University of
 199 Troms&oslash;.  His main interest is distributed information systems
 200 and the Internet.  He has been working with Internet services and web
 201 since he formed the first team at the Internet Hunt.  He has been in
 202 from the start at the Norwegian Telecom's main web-services, <A
 203 HREF="http://origo.telenor.no/">Telenor Origo</A> at Telenor Media.
 204 The last to years he has also been working part time as
 205 webmaster/designer at the university library and the Norwegian
 206 Historical Center.
 207
 208 </BODY>
 209 </HTML>