OpenBSD Journal

unofficial OpenBSD kernel update archive

Contributed by grey on from the ymmv dept.

P-O Yliniemi writes in with what some of our readers will hopefully find useful:

I've built up a small site with a daily updated archive of kernel changes since the release of OpenBSD 3.5 and 3.4.

From this site, anyone interested in not having to use CVS (and open up holes through their firewall) to update their own local copy of the kernel source can download a small file, which updates the source to the patch branch (-stable).

The kernel update site is available on: http://openbsd.mooo.com/

(Comments are closed)


Comments
  1. By jkm (195.58.96.34) on

    Nice. But dont use security as a reason to use your service.

  2. By barbazoo (195.22.66.194) on

    Pardon my ignorance but,
    why would I need to pry a hole in my firewall to run CVS?

    Comments
    1. By PeO (193.13.137.245) on

      While setting this up, I noticed blocked connections from merlin.sunsite.ualberta.ca (using anoncvs@anoncvs.ca.openbsd.org:/cvs as CVSROOT) source ports 1022 & 1023 to port 1022, and from 1023 to 1021 on my fw. The reason seems to be that the machine doing the updates is on a private IP, and SSH tries to communicate directly to my outside address. Redirecting traffic on the port range to the update server seemed to solve the problem.

      Comments
      1. By Fábio Olivé Leite (161.114.64.72) on

        So you have a serious NAT misconfiguration. Please don't spread FUD about having to "open up holes" in one's firewall just for a simple outbound client ssh connection. And SSH has nothing to do with ports 1021, 1022 and 1023, let alone a server connecting back into the client on such ports.
        Hope this helps bring sanity back into the house.

        Comments
        1. By Anonymous Coward (81.226.254.33) on

          Well, its possible that some bofh out there have some thing like this in their conf: block out on $ext_if all pass out on $ext_if proto tcp $INTERNAL_NET to any port 80

  3. By kokamomi (217.215.84.114) on

    maybe, since i bet you don't have that much b/w, you should look into maintaining a bittorrent for that iso instead? also, by keeping this iso up to date with the patch branch, you'll be filling a vacant niche. for those who are intrested in a clean install and rather not go through applying a bunch of patches first thing. good luck!

    Comments
    1. By Anonymous Hero (212.238.188.197) on http://openbsd.sabotage.org/

      The problem with distributing a patched version of OpenBSD is that it will no longer be possible to verify the MD5 for the RELEASE (on ftp.openbsd.org) and the patched versions they will differ and thus there is room for F.U.D..

      Comments
      1. By kokamomi (217.215.84.114) on

        yeah, but i guess the whole point with this site is that if you don't trust the guy, don't use it. simple. i don't beleive the ftp.openbsd.org md5 checksums aren't as much about security as it is about detecting possible data corruption of the binaries (wich could yield unexpected crashes way after installation). neither {src,sys,ports,XF4}.tar.gz has any checksums in the distros. damaged source won't compile, i guess.

        Comments
        1. By SH (217.215.150.208) on

          Indeed, on more that one occasion I got a corrupted download of some data, and the MD5 sum was quite handy to test this. Some Linux distributions even let you test your burning of their ISO as part of the installation, but in this case, burning a coaster is quite common. Avoids some support questions, I gather :D

          /SH

        2. By RC (4.61.195.140) on

          i don't beleive the ftp.openbsd.org md5 checksums aren't as much about security as it is about detecting possible data corruption of the binaries

          Indeed. If it was about security, one of the main guys (Theo, most likely) would have a cron script that downloads the checksum file from the FTP servers every so often (once an hour?) and compare it with the local copy of what it should be. Then they would be able to tell right away if their FTP server has been compromized, and changes made. Everyone downloading the whole files is comparing them with the checksum, so Theo would only have to make sure the MD5 checksum files don't change.

  4. By Anonymous Coward (134.58.253.130) on

    How do you mean, open up holes in your firewall?
    I'm behind a NAT, and I can use CVS just fine, thanks. No need for opening up holes.
    And if you don't have a fast connection, well, cvs up doesn't use more bandwidth than necessary.
    If you really don't want to download source, buy the cd's. They have all of the source code on them.

  5. By Pete (80.203.236.21) on

    blah blah blah, i386 only, blah blah blah

    Comments
    1. By PeO (213.114.101.179) on

      There's no such thing as "i386 only" kernel source code. All platform-specific source changes are updated and put in the update-archive. If you meant the CD image, that's another story. Actually, that CD image was a late add-on to the site (two days after I had made the announcement), and should be seen as a "bonus" for the majority of the *BSD users. Tell me what other platforms you want me to support, and I'll see what I can do (I can most probably not test all the requested releases).

      Comments
      1. By Pete (80.203.236.21) on

        bootable sparc64 would save me the trouble of make release'ing :-)

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]