Re: Updater Proposal

[David Fifield <david () bamsoftware com>]

On Thu, May 19, 2011 at 11:01:32AM +0200, Marek Lukaszuk wrote:
> On Wed, May 18, 2011 at 22:08, olli hauer <ohauer () gmx de> wrote:
> > If you are looking at bsdiff from Colin Percival, then maybe also look
> > into the concept of the FreeBSD patch system. I think with some
> > work you can rewrite the scripts to update the binaries and nse scripts.
> >
> > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-update-server/article.html
> > http://www.freebsd.org/cgi/cvsweb.cgi/projects/freebsd-update-server/
> >
> > I suspect the *BSD users prefer the update by source system. To limit
> > traffic it may be a good idea to provide a .tgz file without the mswin32
> > sources which are not really usefull on this platforms
>
> All the discussion so far, as I can see (sorry if I missed anything)
> is about how to make sure that the whole update process is secure, but
> I didn't see any discussion on the performance on the update servers
> that this could have. Currently there is a lot of nmap users out there
> and when they all start to run the version of nmap that will support
> autoupdates/upgrades the amount of the traffic generated could be
> significant. Maybe a thought of a different transport mechanism to
> spread the load of the updates - torrent for example or something
> similar.
> Just an idea to think about.

Thanks for your suggestions. I'm glad this topic has provoked some
discussion and I know that Colin is paying attention to your ideas.

I've asked Colin not to worry about things like binary diffs and the
size of updates for the time being. Those are big topics on their own
and I fear that optimizing for them too early will hinder the
development of something that works. I think our priorities should be
first safety, then performance.

This may mean downloading a subset of the available files (but whole
files) quite frequently, or downloading all the files somewhat less
frequently.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/