OpenBSD Journal

OpenBSD Auto Patching System

Contributed by jose on from the assisted-administration dept.

Justin contributes:
" OAPS I saw this listed while perusing Freshmeat . Every so oftem I see someone on the misc@ list asking about something like this. There are other options similar to this so this is just another to add to that list I guess."
This kind of reminds of the binary patches project , but the automation is killer. Anyone have a spin with this?

(Comments are closed)

Comments

  1. By Noob () on

    When I first started with OpenBSD I wanted to create a firewall/router. I don't like having a compiler on a machine which doesn't require one to perform its desired task.

    End result is that I had to use a shell script to build a complete release "man release" everytime there is a change in the stable branch. I then roll out the changes copying the packages base32.tgz etc.. with scp and then tar xvfzp them in place.

    I doubt I would trust someone other than the OpenBSD team with building my binary releases.

    It doesn't take that long to build a complete release. With the script I can usually get everything built including X on a 500Mhz PIII system in around 8 hours.

    This method seems to work best for me anyways.

    The down side is that it would be nice to have the system compiled on the hardware used for apparent optimization reasons, but I don't like having my 486 firewalls systems spending days compiling stuff.

  2. By devzero () on

    this is a great idea, but it BETTER use a public key system - if I'm going to basically entrust root to someone else, I want to make sure that that trust can't be easily spoofed by some el8 kiddie.

  3. By Chris Hedemark () chrisATyonderwayDOTcom on ftp://ftp.trilug.org/pub/OpenBSD/3.2/i386/stable

    For those who trust me, and this was made for those who do, you can get periodic updates of 3.2 in binary form from ftp://ftp.trilug.org/pub/OpenBSD/3.2/i386/stable (use this as your ftp install location). It will be more automated at some point but for now I am patching about once a week or so and uploading to the TriLUG server. If I am aware of a major hole I try to get the binaries up within 24 hours of a patch coming out.

    I asked Theo about getting this made "official" and with his normal level of tact I was declined. So if you trust me, feel free to use it. If you don't trust me, don't bother bitching about it.

    Comments

    1. By Anonymous Coward () on

      hmmm dead link?

      this works betta

      ftp://ftp.trilug.org/OpenBSD/3.2/i386/stable

  4. By JC () on

    Maybe I'm just not seeing it, but how's this one diffrent from tepatche?

    (Btw, anyone using one of these? Working well?)

    JC

    Comments

    1. By KH () on

      both are made in perl, and seems very similar,

      i have been using tepatche for a while, works fine for me

      regards

    2. By KH () on

      both are made in perl, and seems very similar,

      i have been using tepatche (http://www.deadly.org/article.php3?sid=20020627195351) for a while, works fine for me

      regards

    3. By Gunnar Wolf () gwolf@gwolf.cx on http://www.gwolf.cx

      I think the main difference is that Tepatche is a single script meant to do a single job - and does it quite well, IMHO (of course, as I wrote it, I will not bitch about it ;-) ).

      OAPS is more a collection of smaller tools that can be used to keep OBSD up to date, but can be used for many other things.

      OAPS seems much more extensible, Tepatche seems simpler to run if you only want basic OBSD patching functionality - and agree to do it every now and then by hand, when Tepatche tells you it does not understand a specific patch.

  5. By Anonymous Coward () on

    I would be happy with a more well described manpage for 'man release'. I made my own release this past weekend for the first time, but some of the steps are pretty vague. One of the steps says something like "update your /etc/var and /dev/makedev by hand and you're all set". Call me crazy but i don't just intuitively know what they want me to update in /etc and /var.

    I made my own little script to get this task accomplished, but it could definitely be more streamlined, as several of the steps require no input or intervention from my end to get the job done (so why not package them together)

    How about a tutorial on making your own release and then using that to update an existing system?

    Also, what about a way to script the install so all you have to do is pop a floppy in, and it will automatically partition and install your system. I rebuid my test machines fairly frequently and would love a way to automate this.

    Comments

    1. By Sam () on

      > don't just intuitively know what they want me to update in /etc and /var.

      Then maybe you shouldn't be doing it that way.

      Comments

      1. By Anonymous Coward () on

        typical answer. "if you don't know how to do this then maybe you shouldn't be trying" or "read the mailing lists, its out there"

        why the hell isn't it in the DOCUMENTATION? this shouldn't be an exercise in my researching skills to get something done, and I shouldn't have to me an active member of the development team/mailing lists to get something done.

        Comments

        1. By Anonymous Coward () on

          It's not in the documentation because it varies from release to release and from patch to patch. man release is an intentionally generic procedure. The upgrade mini-FAQ usually tells you what you need to do to /etc and /var:

          http://www.openbsd.org/faq/upgrade-minifaq.html

      2. By Anonymous Coward () on

        this doesn't return much of anything:

        http://www.google.com/custom?q=automate+install+OpenBSD&hl=en&lr=&ie=UTF-8&cof=GL:1%3BBGC:%23ffffff%3BT:%23000000%3BLC:%23125080%3BVLC:%23125080%3BALC:%23125080%3BGALT:%23125080%3BGFNT:%23000000%3BGIMP:%23125080%3BAH:center%3B&domains=archives.neohapsis.com&sitesearch=archives.neohapsis.com&start=0&sa=N

    2. By Ben Goren () ben@trumpetpower.com on http://www.trumpetpower.com/

      I would be happy with a more well described manpage for 'man release'. I made my own release this past weekend for the first time, but some of the steps are pretty vague. One of the steps says something like "update your /etc/var and /dev/makedev by hand and you're all set". Call me crazy but i don't just intuitively know what they want me to update in /etc and /var.

      Well, the problem is that /etc and /var is where you're supposed to make all your changes. Supose there's a change to /etc/rc.sysctl, and you've customized it to your liking. How to deal with that is, frankly, your problem.

      Granted, it might not be a bad idea for the man page to mention diff and mergemaster. The best idea is probably to use mtree (8) before doing the upgrade to find out what you've changed from the stock system, and then using cvs (1) to find out the changes between the old and new stock systems.

      Having said that, if you're tracking -STABLE, you don't need to worry about /etc and /var unless /errata.html tells you you need to.

      Cheers,

      b&

      Comments

      1. By Anonymous Coward () on

        Thank you, this is more along the lines of what I was looking for.

        I set up my test machine to be a stock install with absolutely no customization changes, so I think based upon your post that I don't have to worry much about etc and var because I never made any changes to the default install. So essentially unless errata tells me i need to worry about a config file change in one of those directories then i'm good to go.

        This way I can install the release version, apply all patches myself and then repackage it and upgrade my release level production servers that way (without having to compile on them at all or have much downtime)

  6. By Anonymous Coward () on

    Oh yes, automatically downloading and executing patches and shell scripts from a third party is a great way to open a big friggen gaping hole.

    Just patch the system yourself. Don't be a lazy halfwit - it's really not a great time expendature.

    Comments

    1. By Dom De Vitto. () on

      What you compile? you lazy halfwit!

      You should binary edit the updatede executables from the patch code, it's easy to spot and find the code if you know what you're doing. If you don't know x86 and how to use GDB, well you must just be soooo dumb!

      Hello? Why should patching a box require any kn owledge - with MS auto-update you just get asked to trust MS that you need the patches. just like 99.99% of obsd users trust Theo not to ship/commit crap code.

      Why isn't patching TOTALLY automatic???
      Excepting external forces - like not being able to reboot to run the patched kernel, because the system is used 24x7 - there are no complelling reason not to.

      Comments

      1. By Mike Stem Cell () on http://www.nedyah.org/feedback.asp

        Hello? Why should patching a box require any kn owledge - with MS auto-update you just get asked to trust MS that you need the patches. just like 99.99% of obsd users trust Theo not to ship/commit crap code.
        Question: Aside from the OpenSSH hole, how many times are you really forced to upgrade or patch your system? If you don't touch it, you won't break it. So its not like the sky is going to fall if you miss a patch (OpenSSH exploit excluded). If you want the latest and greatest features, if you want to keep up with all the changes, you're going to need some basic skills. If you can't handle that, don't worry, your machine is not going to start smoking. If you want auto-updating, look-ma-no-hands stuff, go install Redhat or Debian or Lindows. If you have systems that are really critical, which require every measure of security, OpenBSD is really the best choice, and auto-updating / trusting is not an acceptable course.

        Comments

        1. By Michael van der Westhuizen () on

          I quite agree with that sentiment. As much as I'd like to apply *all* patches there's no immediate rush for me to apply anything unless I'm actually running that service _and_ I've configured the service in the way that exposes the flaw. If nothing frantic happens we tend to update our boxes once every two months or so... no stress, no reboots :-p

  7. By Anonymous Coward () on

    What the heck is an auto patching system going to help when patches still are missing.

    Where are the patches for Apache???
    Others...?

    Sure thing, commit changes to the stable branch which correct security issues, but DO NOT make patches - no this OS should look secure and hence very few patches.

    THIS SUX!

    Comments

    1. By Anonymous Coward () on

      WHAT PATCHES ARE NECESSARY FOR APACHE? people bring this up in every fucking thread

      Comments

      1. By tedu () on

        there is no spoon

      2. By Anonymous Coward () on

        http://httpd.apache.org/ - read and see!

        OpenBSD and security, he don't think so
        No update to Apache 1.3.27.

        "Only one remote hole in the default install, in nearly 6 years!" is NOT true!

        Comments

        1. By Anonymous Coward () on

          apache is off by default. You're mistaken.

          The previous apache bug (chuck encoding) was not counted either.

        2. By Anonymous Coward () on

          I must say I'm getting really tired of wankers who haven't bothered to understand what a default install is...

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.]