Upgrades and image manifests

[Dan Williams]

On Fri, 2007-06-29 at 14:21 +0200, Alexander Larsson wrote:
> On Fri, 2007-06-29 at 08:22 -0400, Dan Williams wrote:
> > Two questions here:
> > 
> > 1) what does the scheme do in the case where the file it's about to
> > replace on the local machine isn't the same as what the manifest on the
> > local machine says?  ie, local changes have changed the sha1 hash of the
> > local file.  That's essentially a policy decision, do we replace when
> > there are local changes or don't we.  A %config-type thing could work
> > here to mark files that you may/may not always want to replace.
> 
> At the moment it only touches the files that are affected by the diff in
> the manifest. If a file wasn't changed in the manifests we don't even
> look at it. However, if the file we're replacing has changed locally, we
> currently throw that away.
> 
> > 2) After downloading a blob, I assume the tool sha1s the downloaded file
> > to ensure that it's content matches the name, right?
> 
> Yeah, or rather, while downloading.
> 
> > > We need a library to do http downloads. I see we're shipping libcurl on
> > > the laptop. Is it ok to use this library? 
> > 
> > Yeah, though the ironic thing just occurred to me that libcurl is (along
> > with Mozilla) one of the more frequently updated pieces of a linux
> > distro :)
> 
> I ended up using urllib2 in python.

Right, python too :)  If we get a factory python process (didn't we have
one at one point?) we save some memory.

> > > (We also need a very simple http sever that maps sha1 -> file in system
> > > image for laptop-to-laptop upgrades, but I think we can do that without
> > > using a library.)
> > 
> > "simple" means lighttpd in my mind, but apache has a longer track
> > record.
> 
> simple means 300 lines of C code in serve-manifest.c...

That may work even better, 300 lines is certainly 1,000,000 times easier
to audit for security problems than all of apache or lighttpd.

Dan