Contributed by jose on from the easy-upgrades dept.
Many deadly regulars will recognize homebrew script names like tepatche, easybakeoven88, binpatch, etc. My question is does the core development team still see these as untested, not useful, not needed, or most likely not a priority? Has there been any recent tallks to bring more advanced patching functionality into the core system in v3.5?"
Personally, I doubt we'll see binary patches coming soon from the official project. However, will these other, third-party upgrade systems make sufficient headway? Comments, anyone?
(Comments are closed)
By Peter Hessler () spambox@theapt.org on http://www.theapt.org
Which kind of binary patching is desired? The kind that would need `diff` and `patch` to work with binary files? Or are we talking about replacing binaries, and libraries, when needed?
Comments
By tedu () on
Comments
By mad () on
Here is example of recent OpenSSH 3.3-stable patches:
openssh-3.6.1$ du
625 ./usr/bin
77 ./usr/share/man/cat1
52 ./usr/share/man/cat5
36 ./usr/share/man/cat8
166 ./usr/share/man
167 ./usr/share
2 ./usr/libdata/ssh
3 ./usr/libdata
1220 ./usr
1221 .
openssh-3.7.1$ du
641 ./usr/bin
80 ./usr/share/man/cat1
52 ./usr/share/man/cat5
36 ./usr/share/man/cat8
169 ./usr/share/man
170 ./usr/share
2 ./usr/libdata/ssh
3 ./usr/libdata
1239 ./usr
1240 .
$ diff -u 3_6_1.uuencoded 3_7_1.uuencoded | wc
62028 62304 3900073
$ diff 3_6_1.uuencoded 3_7_1.uuencoded | wc
61730 123075 3922706
$ diff -u 3_6_1.uuencoded 3_7_1.uuencoded | gzip -9 > diff-u.gz
$ diff 3_6_1.uuencoded 3_7_1.uuencoded | gzip -9 > diff.gz
Result:
diff-u.gz (gzipped patch) = 1677636 bytes
diff.gz (gzipped patch) = 1669087 bytes
openssh-3.6.1.tar.gz (tar-gzipped binaries) = 509923 bytes
openssh-3.7.1.tar.gz (tar-gzipped binaries) = 516547 bytes
Comments
By tedu () on
By Anonymous Coward () on
Comments
By tedu () on
Comments
By Anonymous Coward () on
Yes, I know it isn't going to happen, but a guy's got to have a dream right? =)
Comments
By tedu () on
By Anonymous Coward () on
Microsoft has Windows Update, Debian has APT, Red Hat has up2date, etc. OpenBSD is close to having this because...
Developers in the Debian project had ported most of the dpkg and apt suite to OpenBSD, but then then became distracted with porting glibc.
(Why port glibc to OpenBSD? Isn't that missing the point?)
OpenBSD could probably be deployed with APT when somebody creates Debian control files for the base system, and writes a conversion script for the way that the ports system describes dependencies.
I investigated this, and it would probably be four weeks of work. Anybody that actually gets around to finishing the job would probably become famous and/or worshipped by administrators.
Comments
By Peter Hessler () spambox@theapt.org on http://www.theapt.org
Comments
By Anonymous Coward () on
Companies revolve around policy and procedure, and "automatic update" is now a feature on the purchasing checklist.
Any person that doesn't cringe when they hear "all you have to do..." is probably competent and thus has more important things to be doing. Applying patches to an operating system is something that should be delegated to the highschool intern.
I hear the begging on misc@ for CD-ROM purchases, but it is harder to make a business case for a software product without a 'standard' feature like automatic updates.
Comments
By Brett Jones () brett@5foot2.com on mailto:brett@5foot2.com
Yeah, trust the weakest link in the chain to do security/stablility updates, that's a great idea. They should do backups of critical data also, I mean shit, it's only backups.
By Anonymous Coward () on
Take old hardware for example. Disk too small, CPU too slow, not necessarily x86, no source tree handy, now upgrade this one without leaving a remote root open for more than, lets say 10 minutes.
Yes, I think signing patches and making them applicable in seconds is doable and of benefit, though not trivial if done right.
Comments
By Ben Johnson () on
Comments
By Giacomo Cariello () jwk@bug.it on mailto:jwk@bug.it
By krh () on
*raises hand*
I have to admit that I don't have the slightest clue of how to use CVS. I follow the recipes in the FAQ and sometimes it works. Other times it doesn't. Whether or not it works feels very random to me, almost as if I am using Windows. This is why I've given up on following -current and only use CVS if I feel like I have no other choice.
By Anonymous Coward () on
It really bit me this week with my FreeBSD and NetBSD servers...patches had not been released and source tree synchronization was required.
By Anonymous Coward () on
What I'm getting at, the average person doesn't want to cvs or patch source, then compile. They want to install a new binary.
The best solution? Use what the OpenBSD project already has:
1) An AWESOME CVS, Ports, Packages system
2) Dedicated Contributors
With those, the best idea I can think of is to have OpenBSD project members (with CVS check-in access) write ports (and therefore packages) for updates.
This is great for a few reasons:
1) It is easy to apply (pkg_add file.tgz)
2) It is easy to track (pkg_info)
3) It works as expected (just as Microsoft has Add/Remove programs for listing/managing hotfixes, we would have pkg_add)
By Anonymous Coward () on
cd /
tar pxfvz foo.tgz
Does anyone know if there is a (relatively) simple way to do this now?
Comments
By Anonymous Coward () on
cd /usr/src
patch -p0 <017_sshbuffer.patch
cd usr.bin/ssh
make obj
make cleandir
make depend
make && make install
Followed by:
make package
Which would then create a tarball (perhaps in /usr/src/packages or something) called ssh.tgz, which I could copy to another machine and type:
cd /
tar pxfvz /path/to/ssh.tgz
017_sshbuffer.patch
Comments
By Stefan () stefanjo@telia.com on mailto:stefanjo@telia.com
I dont know if this works "out of the box" (probably not) but I dont think it would be to hard to adapt.
By djm () on
Just make a release "man release" and copy the resultant tarballs to the hosts that you wish to upgrade. Once there, unpack them from the root with "tar zxvpf /path/xxxyy.tgz". Building a release will also build a GENERIC kernel which you can copy out too.
Comments
By James F. Wilkus () tflat+deadly@astrocreep.net on mailto:tflat+deadly@astrocreep.net
Comments
By Michiel van Baak () michiel@vanbaak.info on mailto:michiel@vanbaak.info
Now that I read about your little nifty perl script, is it possible I can have a copy ?
I'm not that good in scripting so I cannot make my own.
Thnx in advance
By RC () on
That's right, current, updated, binaries. All you'd really need to do is upgrade to the snapshot version.
If building from source is really that big of a burden, as people continue to claim, you always have that binary-only option.
Comments
By Anonymous Coward () on
Comments
By RC () on
Comments
By Anonymous Coward () on
Comments
By RC () on
What you are saying is that you never test software before you install it on a production system?
Personally, I was just pointing out that, those that need utmost stablity aren't going to have a problem compiling their OS, while those that consider it to much of a hassle, can just use the snapshots.
Even if you had binary-snapshots from OpenBSD, you're likely going to end-up causing some downtime with that attitude anyhow (not testing anything).
By Anonymous Coward () on
By Colin Percival () cperciva@daemonology.net on http://www.daemonology.net
1. `freebsd-update fetch`
2. [optional: look at the list of files for which updates were downloaded]
3. `freebsd-update install`
4. restart sshd.
This is much better than any of the existing update tools for OpenBSD; it's also more secure, since it uses 2048-bit RSA to sign the updates. (CVSup, by contrast, is completely insecure.)
The only requirements for FreeBSD Update to be used is that the system must have started with a binary install of the official release image, and the base system must not have been recompiled. (Any files which are recompiled might not be updated -- in particular, if you recompile the kernel, FreeBSD Update will thereafter not update the kernel.)
Nobody at BSDCon seemed interested in porting FreeBSD Update to OpenBSD (I expect this to be a one-day job -- there's really nothing FreeBSD-specific in FreeBSD Update). Maybe someone here will be interested?
The FreeBSD Update web site is http://www.daemonology.net/freebsd-update/
Comments
By Anonymous Coward () on
By Anonymous Coward () on
By Anonymous Coward () on
But the main problem remains: who'll trust non openbsd patch ?
This solution will be viable only if patch are signed by some openbsd's staff trusted/agreed key.
Comments
By Colin Percival () cperciva@daemonology.net on http://www.daemonology.net
By Anonymous Coward () on
I tried compiling the source straight and I get a compile error, I tried compiling with the pre-3.3 patch and I still get a compile error.
Is there anything I can do to get openssh protected on openbsd2.6?
Comments
By Jeff Flowers () jeff@goo.cc on mailto:jeff@goo.cc
By Johan () on
Where "This source" is openssh 3.7.1. With "earlier OpenBSD", I assume they mean pre-3.x.
By djm () on
By blahblahblahblahblahblahblahblahblahblahblahblahbl () on
By Anonymous Coward () on
E.g.: It's quite simple to run OpenBSD from a CF card, but neither gcc nor /usr/src will fit onto this, and I don't want to run another OpenBSD box just for the purpose of compiling stuff.
A mechanism like APT or even RPM would be really helpful.
Also, virtual servers (very popular in DE), are way to slow to make fast updates.
Comments
By Thomas W. Horna () on
patched 2-3 times using faq, and now i know that thingies by heart. Where is the Problem at all?
I love to retain freedom of compiling my binaries by myself.
By chuck () on
what I think most people would like to see is the core openbsd group embrace one of these projects and "officialize" it. of all OS fans, I believe that openbsd users would be the hardest to convince to grab a binary patch from any old joe as opposed to compile it.
That said, straight up source patches definitely have their strong points. Example: I use saslauth, and need to compile support for that into sendmail. Using Source RPMS, i would have no idea where to begin. On the downside, I do agree with a lot of people that I dont normally have the HD space for all the source.
Now that I think about it.....
Perhaps instructions included with the patch stating how to grab the portions of source from CVS that you need to compile would work best?
Comments
By Anonymous Coward () on
But is not easy... sendmail took me some time to realize how much source tree was needed to compile.
After that anyone can make bin updates if he/she/it needs to update more than one system.
Comments
By chuck () on
CVS has got to support labels, right?
So, with some volunteers, it might be able to come up with the correct CVS labels of different programs on Open. Perhaps do it the "evolutionary" openbsd way, where when a patch is given, thats when the label is created for that software, preventing a massive amount of work requiring to be done all at once.
Or maybe I'm crazy.
What I am imaging is something like:
cvs get gnu/usr.sbin/sendmail but not quite like that, instead using labels.
maybe....
cvs get -rOPENBSD_3_3_sendmail
please tell me, am I off my rocker?
By Mark Beihoffer () mark att dragonfly-7 daught com on http://www.dragonfly-networks.com
I don't know which type of system would work best, although others have made good points about disk space for source compilation (especially for Flash devices).
One thought that did occur to me as a Perl fan would perhaps to adapt the CPAN model, and have a shell that would allow you to search for patches and apply them interactively?
That for me would be easier and more comprehensible than some of the other suggestions. CVS is certainly an option, but it would appear to be a somewhat bloated, time/cpu/disk intensive one at best.
Comments
By Anonymous Coward () on
By Anonymous Coward () on
For the first time, we see a divergence beetween the choices in the dev community and popular demand of the users community.
Will they hear us ?
Comments
By Martin Reindl () wildweasel@bsdcow.net on mailto:wildweasel@bsdcow.net
Of course this doesn't mean input from users is useless or unwanted, but it will happen more likely if you provide code to start with that fits OpenBSD instead of crying out loud "I want that!"
Regards,
Martin
Comments
By ben () mlben@zouh.org on mailto:mlben@zouh.org
User community has already done the necessary code (see other posts, particularly the one about freebsd-update).
The only need at that point is to be aknowledged by the open staff (ie: could be just a cert key signed by openbsd CA, to let us sign patches ...).
No projects could envolve without this because users won't install untrusted third party binaries.
Comments
By Colin Percival () cperciva@daemonology.net on http://www.daemonology.net
Ok, maybe people running OpenBSD are more paranoid than those using FreeBSD; but I think you'd still see quite a few people taking advantage of binary updates a la FreeBSD Update if they were provided for OpenBSD, regardless of who provides them.
Comments
By ben () mlben@zouh.org on mailto:mlben@zouh.org
It could become, at least, a group of people who'll endorse responsability for bin patches.
I can make i386 and sparc updates.
Also will see what can be done with your code under openbsd.
Anyone to associate (especially with alpha, vax ...) ?
my email is provided.
By Martin Reindl () wildweasel@bsdcow.net on mailto:wildweasel@bsdcow.net
Until then i will continue to follow the good old way of upgrading and compiling on my boxen with standard Unix tools that OpenBSD provide and support. I don't feel there is something wrong with it, but maybe that's just me :)
Comments
By Anonymous Coward () on
'make release' is a good start, one other solution I've been using is making a list of files from the output of 'tar tvzf base.tgz' that I then pass to tar as a list of files to include. On one machine (the build machine) I 'make build', then tar all the files that were initially in base.tgz, scp/ftp it over to the other boxes, bring them down to single user if necessary and then just untar the base.tgz in /. One can do the same for other sets.
Updating /bsd is even easier. One of the machines I update this way has a 480MB HD (base.tgz && etc.tgz && bsd), so I've been forced to find a solution with a dedicated build machine.
By ben () on
I'm mostly agree with you: the better, the one - if there must be only one - way of upgrading is the plain old way (patch|cvs, make etc). Nothing "wrong" with this, indeed ;)
Furthermore, I think a tool to upgrade continuously all the binaries could deserve openbsd (see the dselect dependency nightmare, and all linux "bazaar" ;).
The need is different: only providing binary updates for security concerns, and admin will patch they're net fastly (or at least, they will do it;).
See for instance: I've a bunch of soekris VPN gateways to maintain with differents versions of openbsd (w/ compact flash drives). Also, we've a politic of "the less is the best" for our firewalls (implies no gcc or source trees). Patching sendmail then openssh (then openssh again) took me 3 plain days. I did idle all my current tasks (was hard to convince my managers ...). Not good.
I know a lot of admins around there that didn't upgrade (or that waited too long) for similar reasons: lazyness, lack of time ... you may think it's they're concern, but I don't: a trojaned box is a problem for all neihgbours.
See the poing ? binay updates for security problems is a real plus for large networks, for semi-emmebeded systems and for lazy (or busy) admins.
Give us reactivity to honour dev's proactivity ;)
By Randy Poznan () randy@hackuser.com on mailto:randy@hackuser.com
After cvs update. A make file will only build whats new in the src. Compare program could md5 compare (apps, libs, etc) and output a db of new binaries. Patch build program would read the db and create archive of new files, log changes, sign it, and name it with the date.
I dont exactly know if this project does unit testing? Binary patches probably would need testing to build user trust. A automated suite of tests for every application or library native to the distro. This could execute tests on programs based on old bugs or defined functionality via a single command.
Comments
By Matt () on
Comments
By Randy Poznan () randy@hackuser.com on mailto:randy@hackuser.com
New systems and deployed systems could install patches over the base install.