On Sat, December 5, 2015 4:08 pm, openbsd-m...@clark-communications.com
wrote:
> Yes, if I end up writing a scraper, I will very likely obtain the html
> pages
> from the www directory of my local CVS mirror, rather than making http
> requests
> of the OpenBSD website.
>
> Another nice piece of data to have about a patch level would be the
> revision
> number in CVS for that patch.
> At present, the only place I see that information is inside the patch.sig
> file, e.g.
>
>       
> http://ftp.openbsd.org/pub/OpenBSD/patches/5.8/common/004_smtpd.patch.sig
>

I meant, I parse the files in patches/*/common, not the html in cvs.  I
found it easier.  I get a nice little report of the errata number, name
and synopsis.  It's mostly wasted as I see the cvs checkin first and am
already rebuilding. :)

> My approach is to build an entire new release for the current patch level.
> I understand this is way overkill, but given that is is a (mostly)
> automated
> process, I prefer this
> approach to manually applying and rebuildingâ*¦.

This is also what I do.  I rebuild the whole release and then apply the
kernel or base tarball to update the systems.  This way I have an
up-to-date release available for new system deployments as well.  I don't
have the luxury of redundency or down time to fully redeploy a system to
update it.

I do maintain configuration changes in siteXX.tgz files in case I do have
to redeploy.  Unfortunatly, they are mostly untested which is bad, but it
should get me 95% of the way.  A dev/staging environment is in the works.

> I can imagine that at some point I can have my build system send me a
> notification that a new patch is available, and a bit later,
> that a new release has been built and is available for installation,
> if/when I
> so choose.
>

My build machine monitors cvs for -stable updates in the code, as well as
changes to the patches/$version/ folder.  I see the cvs changes, and if
errata newer than the build machine's patchlevel have been created.  I
mirror the patches directory so all the systems compare their patchlevel
to my internal mirror.  Currently, I manually kick off a new release build
and then initiate an update from each system.

The patchlevel handles errata, but I can't yet be sure a system has the
latest stable changes.  The theory is that it's the errata that's
important, so I haven't solved that problem yet.

As it stands I have way better insite into the changes going onto my OBSD
machines as compared to the linux ones with rolling updates of hundreds of
packages of who-knows-what.

Reply via email to