> On Dec 5, 2015, at 11:51 AM, trondd <tro...@kagu-tsuchi.com> wrote:
>
> On Sat, December 5, 2015 2:20 pm, openbsd-m...@clark-communications.com
> wrote:
>> I mostly follow -stable, and have scripts/tools that enable me to
>> (re)build
>> stable from source with minimal human intervention.
>>
>> To further automate this process, it would be helpful to have the current
>> release number and (at least) the most current patch number.
>
> What is your build process? The machine doing the build is running the
> same version it's building, right? Does 'uname -r' not work for you?
My build process begins outside of OpenBSD itself, so if I do not have a
machine running the current release version,
a machine running that release needs to be created. There are several ways to
make that happen, and currently
I spin up a virtual machine. At the moment, this is not an automated part of
my process, but I would like to make it so...
> As for the patch number, someone can correct me if I am wrong, but I don't
> believe it is recorded anywhere else. I used to parse the errata page but
> to be kinder to the server, I started parsing my local mirror which I
> actually found to be easier to get the info from.
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. In addition to reducing bandwidth demands of the
website, getting the information from my local mirror might lower the risk
that the website is more recent that my local mirror….
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
If I had that, i could ensure that the release I am about to build actually
contains the changes indicated by the patch level.
I am not looking forward to parsing these .sig files either :-(
> I maintain a "patchlevel" file on each system to keep track of what patch
> I have applied and I check it against the patches on my mirror in
> daily.local so I keep getting notified of out of date systems. I also add
> it to the motd so I see it when I log in, as well.
>
> I prefer this slightly manual intervention because I like to know what is
> changing on my systems. I'm already patching manually, so also
> maintaining the patchlevel file is minor.
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….
I don’t apply patches to running systems, I re-install them from scratch,
and automated
configuration management restores the system to where it should be.
I do not now, nor envision, that the re-imaging of a machine would happen
automatically.
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.
Your idea of a patch level file and adding that to motd is great, I will add
that to my configuration management, just to make it obvious when shelling
into a server.
A follow-on addition to that idea is to add a “patch level fact” to ones
configuration management tool of choice, so that the patch level is
reported….
