[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-misc
Subject:    binary patches
From:       Jacob Meuser <jakemsr () clipper ! net>
Date:       2001-06-23 4:13:13
[Download RAW message or body]

On Fri, Jun 22, 2001 at 05:10:07PM -0500, Gerardo Santana Gómez Garrido wrote:
> On Fri, Jun 22, 2001 at 01:30:05PM -0700, Jacob Meuser wrote:
> > On Fri, Jun 22, 2001 at 05:00:11AM -0500, Gerardo Santana Gómez Garrido wrote:
> > > On Fri, Jun 22, 2001 at 10:38:25AM +0100, Peter N. M. Hansteen wrote:
> > > > At 10:20 AM 6/22/01, Gerardo Santana Gómez Garrido wrote:
> > > > >Even more interesting: "binary patches".
> > > > 
> > > > My first thought is, won't that be pretty hard, considering
> > > > people are likely to at least configure their kernels to be
> > > > rather different from GENERIC?
> > > 
> > > Yeah, exactly. That was my third thought. When patches apply to the kernel,
> > > binary patches would be available for GENERIC kernels only.
> > > 
> > > My first thought was *trust*
> > > 
> > > The binary packages must have md5 signatures.
> > > 
> > > Second thought, what about config files? According to OpenBSD policy, they
> > > must not be modified automatically. The user has to apply the changes by
> > > hand. So, the binary package has to alert about a new service.conf.new
> > > config file (a postinstall message).
> > > 
> > > See the mess? Not a big deal, but not a priority for developers for sure.
> > > But still interesting... This would solve the problem of those admins that
> > > didn`t leave enough space in their firewalls/whatever for the source code
> > > and can`t patch.
> > > 
> > 
> > If you check the misc@ archive, you may see that I have posted messages
> > stating that I'm working on binary patching.  You may have seen the post
> > early last week that said I hoped to release my work last week.  Well, 
> > tomorrow, I promise, I will post a URL.  I was working on some 
> > documentation and testing last night.  
> 
> I missed the posts from two weeks ago :/... I had to attend my fake life.
> 
> > 
> > Major features:
> > * md5 AND size checks for packages AND all updated/new files
> > * preinstall and postinstall scripts, as well as description files
> > * extremely verbose; lets you know EVERYTHING that's going to happen,
> >     and asks if you want to proceed
> > * optional 'auto' mode, that does everything without being prompted
> > * all updated/obsoleted files are archived
> > * intelligent fetcher that knows what you need for your system
> > * ONLY relevant files are updated; files that don't need to be updated 
> >     are left alone
> > * written in perl, for portability
> > * unrestrictive BSD style license
> > 
> > I'm basically making patches of the install tarballs, and as a by-product
> > am producing updated install sets.  I can't afford the bandwidth/diskspace
> > to distribute the tarballs, but I could send them to someone who can,
> > if they're interrested.
> 
> I'll wait for the script then. I want to take a look at it.
> Instead of patching install sets, a package for just the programs to be
> patched would be better. This may be accomplished just like the ports system
> does it. May I help you? I have some ideas. The existing build system will
> be very helpful.

Well, I designed it for myself, how I would like it to work even
if I didn't write it.  My 'net connection is a 56k modem.  I left
Linux so I wouldn't have to download a whole package to update 1 file 
in it.  I certainly don't want to download packages that have irrelevant 
updates.  That's why the patches are based on the install tarballs, 
it's also the reason the packages only contain changed or new files,
NOT a complete package in the normal sense of software packages.
The fts patch, for example mostly affects files in the compXX.tgz tarball.
I don't have that installed on my firewall.  Sure, the package could have
a PLIST or some such thing to connect files to tarballs, but then I'd
still be downloading irrelevant files, and then, of course, there would
be the need to parse that list, blah, blah, blah.  As a matter of
personal opinion, I think a preinstall and a postinstall script, along
with a standard 'install' file copying mechanism in the main program,
is better than one install script, like pkg_add uses. 

Perhaps you didn't notice, but the ports system on OpenBSD doesn't
do updates AT ALL, doesn't even try.  (OK, it can tell you what's old, 
but that's it.)  Updating is different than installing.  Now, as pkgs
are just tarballs, like the install tarballs, (OK, there's a little more
to them, like PLIST instead of simply tar, but) with some tweaking, 
the system I created could make pkg binary patches also.

I'm not sure what you mean by the build system being helpful.  My original
plan was to do full rebuilds a la release(8), however, ar doesn't play
nice.  Also, the idea here is binary patches.  Binary.  The idea is
one build can update any number of systems.  I'm building the updated
binaries using the patches from errata.html, and separating the files
into their respective tarballs using release(8).  I don't see what part
of the build system that I'm not using would help with this project.
   
> 
> > 
> > As far as updating the 'etcXX.tgz' tarball, the updated files are 
> > fetched but not installed, for the most part.  I wrote a postinstall
> > script for the sendmail patch that builds a new /etc/mail/sendmail.cf,
> > using /usr/share/sendmail/cf/`hostname`.mc if it exists.  If it doesn't
> > exist, and not in auto mode, asks which file in /usr/share/sendmail/cf
> > to use.  If in auto mode and `hostname`.mc doesn't exist, uses 
> > opedbsd-proto.mc.  If all else fails, it copies the new sendmail.cf from
> > the 'etc' tarball.  If sendmail.cf is updated, the old one is backed up
> > as /etc/mail/sendmail.cf.bak, and it is also archived, as all updated/
> > obsolete files are.  Most of this is just so the auto mode will work
> > sanely.  It is all optional.  Also, sendmail must be stopped before
> > /usr/libexec/sendmail/sendmail can be updated, so the preinstall script
> > kills it.  If the sendmail_flags line in /etc/rc.conf is not commented
> > out, the postinstall script restarts sendmail with the sendmail_flags.
> > I updated a machine that runs sendmail as a daemon, complete with
> > custom sendmail.cf in about 5 seconds using auto mode.  As stated before,
> > this is optional, because it conflicts with OpenBSD policy.
> 
> Well, this is a innecessary complexity, in my opinion. I would follow the
> OpenBSD policy.
> 
That's why it is optional.  I mostly did it because I wanted to see if 
it could be done in some kind of sane manner.  It is somewhat complex,
but it works quite well.  For me anyway. 

> > 
> > Oh, and it doesn't do anything as far as the kernel is concerned.  I
> > suppose it would be pretty easy to have it fetch an updated GENERIC 
> > kernel though.  Then the user can modify it with config -e.  Is it 
> > possible to store the config -e stuff in a file, to be used on new
> > kernels?
> 
> Aha. The kernel is ok.

It would be nice though, no?  Optional, of course, but I think it would 
be nice.

<jakemsr@clipper.net>

> >  
> > <jakemsr@clipper.net>
> 
> -- 
> ISC. Gerardo Santana Gómez Garrido
> OpenBSD México http://www.openbsd.org.mx/~santana
> 4291424

[prev in list] [next in list] [prev in thread] [next in thread]