update/upgrade

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

update/upgrade

quartz-2
We have a bunch of low power embedded devices that we'd like to keep
reasonably up to date, but the disk space and cpu overhead of tracking
-stable is kind of a nonstarter. Is there another/better way of doing
things these days? (Other than applying dozens of patches manually).

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Pedro Tender-2
Snapshots?
On Sep 20, 2015 9:54 PM, "Quartz" <[hidden email]> wrote:

> We have a bunch of low power embedded devices that we'd like to keep
> reasonably up to date, but the disk space and cpu overhead of tracking
> -stable is kind of a nonstarter. Is there another/better way of doing
> things these days? (Other than applying dozens of patches manually).

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Kimmo Paasiala
In reply to this post by quartz-2
On Sun, Sep 20, 2015 at 11:49 PM, Quartz <[hidden email]> wrote:
> We have a bunch of low power embedded devices that we'd like to keep
> reasonably up to date, but the disk space and cpu overhead of tracking
> -stable is kind of a nonstarter. Is there another/better way of doing things
> these days? (Other than applying dozens of patches manually).
>

Something like this?

http://www.bsdnow.tv/tutorials/stable-iso

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Josh Grosse
In reply to this post by quartz-2
On Sun, Sep 20, 2015 at 04:49:45PM -0400, Quartz wrote:
> We have a bunch of low power embedded devices that we'd like to keep
> reasonably up to date, but the disk space and cpu overhead of tracking
> -stable is kind of a nonstarter. Is there another/better way of doing things
> these days? (Other than applying dozens of patches manually).

https://stable.mtier.org/

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
In reply to this post by Kimmo Paasiala
> Snapshots?

> Something like this?
> http://www.bsdnow.tv/tutorials/stable-iso

Well, preferably something that doesn't require the machines to go
offline for a while.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
In reply to this post by Josh Grosse
> https://stable.mtier.org/

A cli update program that applies binary patches is pretty much perfect,
but I'm not sure we want to rely on a 3rd party for that service. (And I
know that a built-in update program is probably never going to happen).

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Christian Weisgerber
In reply to this post by quartz-2
On 2015-09-20, Quartz <[hidden email]> wrote:

> We have a bunch of low power embedded devices that we'd like to keep
> reasonably up to date, but the disk space and cpu overhead of tracking
> -stable is kind of a nonstarter.

You do that part on a bigger box, build releases there, and use
these to update the low power devices.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Pedro Tender-2
In reply to this post by quartz-2
As it was already stated in @misc, mtier is probably as safe as relying on
openbsd code.
On Sep 20, 2015 10:29 PM, "Quartz" <[hidden email]> wrote:

> https://stable.mtier.org/
>>
>
> A cli update program that applies binary patches is pretty much perfect,
> but I'm not sure we want to rely on a 3rd party for that service. (And I
> know that a built-in update program is probably never going to happen).

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
In reply to this post by Christian Weisgerber
> You do that part on a bigger box, build releases there, and use
> these to update the low power devices.

That doesn't really help the situation. These machines don't have
identical setups so you'd still have to do a lot of manual merging
and/or write and maintain a library of custom merge scripts for them.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
In reply to this post by Pedro Tender-2
> As it was already stated in @misc,

I don't think I got that message. (?)

> mtier is probably as safe as relying on
> openbsd code.

I'm not worried so much about safety in the sense of compromised code,
but rather the practicalities of setting up a workflow that depends on
something that can disappear at any time without notice. Their website
has zero information about them as a company or who (if any) of them are
also OpenBSD devs or what. It also looks like they only started a couple
years ago.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Nick Holland
In reply to this post by quartz-2
On 09/20/15 20:34, Quartz wrote:
>> You do that part on a bigger box, build releases there, and use
>> these to update the low power devices.
>
> That doesn't really help the situation. These machines don't have
> identical setups so you'd still have to do a lot of manual merging
> and/or write and maintain a library of custom merge scripts for them.

You think the master builds are done on a machine that is identical to
yours at home?  No.

Build a -stable release on a same platform faster machine.  Now unpack
the .tgz files on the target machines, copy in /bsd, /bsd.rd, reboot.
ta-da, patched machine.  None of your configuration is touched by this
process.

If you are modifying the OpenBSD install to where this doesn't work, you
are on your own, but this has nothing to do with slow
hardware...building from source would do the same thing, as would upgrading.

Upgrades?  Do as usual from binary releases.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
> You think the master builds are done on a machine that is identical to
> yours at home?

Obviously not, but that doesn't have any bearing on what I said.


> Build a -stable release on a same platform faster machine.  Now unpack
> the .tgz files on the target machines, copy in /bsd, /bsd.rd, reboot.
> ta-da, patched machine.  None of your configuration is touched by this
> process.

Maybe I'm unclear on what building -stable actually does. Correct me if
I'm wrong, but "world" encompasses a lot more than just the kernel and
ramdisk, right? Simply replacing just those two alone isn't fully
keeping on top of things.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Josh Grosse
On Sun, Sep 20, 2015 at 09:36:55PM -0400, Quartz wrote:

> >You think the master builds are done on a machine that is identical to
> >yours at home?
>
> Obviously not, but that doesn't have any bearing on what I said.
>
>
> >Build a -stable release on a same platform faster machine.  Now unpack
> >the .tgz files on the target machines, copy in /bsd, /bsd.rd, reboot.
> >ta-da, patched machine.  None of your configuration is touched by this
> >process.
>
> Maybe I'm unclear on what building -stable actually does. Correct me if I'm
> wrong, but "world" encompasses a lot more than just the kernel and ramdisk,
> right? Simply replacing just those two alone isn't fully keeping on top of
> things.
 
Please see FAQ 5.4, which articulates how to build a release (-stable, or
-current).  The definitive documentation is release(8).

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Nick Holland
In reply to this post by quartz-2
On 09/20/15 21:36, Quartz wrote:
>> You think the master builds are done on a machine that is identical to
>> yours at home?
>
> Obviously not, but that doesn't have any bearing on what I said.

you rejected the right answer for wrong reasons, so what you said was
unclear at best.

>> Build a -stable release on a same platform faster machine.  Now unpack
>> the .tgz files on the target machines, copy in /bsd, /bsd.rd, reboot.
>> ta-da, patched machine.  None of your configuration is touched by this
>> process.
>
> Maybe I'm unclear on what building -stable actually does. Correct me if
> I'm wrong, but "world" encompasses a lot more than just the kernel and
> ramdisk, right? Simply replacing just those two alone isn't fully
> keeping on top of things.

"world" as you appear to be using it isn't an OpenBSDism, so I would
suggest you start at the top of FAQ5 (very top -- 5.1 might be among the
most important but failed to be understood concepts in OpenBSD), and
start reading.
   http://www.openbsd.org/faq/faq5.html
Your situation is even mentioned...
Reading with an open mind not fogged by other projects uses of various
words and processes or your own preconceptions of how things work is
highly recommended.

When you build a release, you are going through the process used for the
official releases, and generate the entire set of files you see in a
platform release directory on a distribution mirror.

You can then install a new -stable release on your slow hw as fast as
you can copy it over and unpack the tar files, and your downtime is
limited to the time of a reboot.  You can also install these releases on
blank hardware as well.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Patrick Dohman
In reply to this post by quartz-2
> On Sep 20, 2015, at 3:49 PM, Quartz <[hidden email]> wrote:
>
> We have a bunch of low power embedded devices that we'd like to keep reasonably up to date, but the disk space and cpu overhead of tracking -stable is kind of a nonstarter. Is there another/better way of doing things these days? (Other than applying dozens of patches manually).
>

Does your embedded storage run NOR/NAND or something like SDHC Memory Cards?

If your systems are running SDHC you can easily create clones with a laptop & the DD utility.

Regards
Patrick

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
In reply to this post by Nick Holland
> "world" as you appear to be using it isn't an OpenBSDism,

.... ugh. You're right, you're right... I'm also managing several
FreeBSD projects and I'm getting things mixed up. Let me go through the
man pages again and try to sort things out in my head.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
In reply to this post by Patrick Dohman
> Does your embedded storage run NOR/NAND or something like SDHC Memory
> Cards?
>
> If your systems are running SDHC you can easily create clones with a
> laptop&  the DD utility.

A couple of them do, but it doesn't matter in this case. The main issue
with compiling is that it can effectively knock the system offline for
hours which isn't acceptable. Any process that involves shutting the
machine off or booting into a separate OS image has the same problem.

It's just a question of minimizing downtime.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Josh Grosse
On Sun, Sep 20, 2015 at 10:36:12PM -0400, Quartz wrote:

> >Does your embedded storage run NOR/NAND or something like SDHC Memory
> >Cards?
> >
> >If your systems are running SDHC you can easily create clones with a
> >laptop&  the DD utility.
>
> A couple of them do, but it doesn't matter in this case. The main issue with
> compiling is that it can effectively knock the system offline for hours
> which isn't acceptable. Any process that involves shutting the machine off
> or booting into a separate OS image has the same problem.
>
> It's just a question of minimizing downtime.

You build a release of -stable on one single platform, such as a workstation,
and then deploy it as a binary update to your production servers.
Build time is then separate from production maintenance windows.

My flight of -stable servers share the same architecture, and I have a single
build machine.  These servers are in redundant configurations using carp(4)
so I am able to perform maintenance without any operational downtime.  

I'll repeat -- without any operational downtime.

But I have the luxury of deploying redundant systems with carp(4).

The maintenance windows do take about 10 minutes of wall time, because these
machines are all "embedded" sized -- Alix systems -- and the slowest part of
the update is untarring filesets onto their compact flash storage devices.
If they had magnetic drives or SSDs the windows would be less than 5 minutes.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Rob Pierce
In reply to this post by quartz-2
On Sun, Sep 20, 2015 at 10:36:12PM -0400, Quartz wrote:

> >Does your embedded storage run NOR/NAND or something like SDHC Memory
> >Cards?
> >
> >If your systems are running SDHC you can easily create clones with a
> >laptop&  the DD utility.
>
> A couple of them do, but it doesn't matter in this case. The main issue with
> compiling is that it can effectively knock the system offline for hours
> which isn't acceptable. Any process that involves shutting the machine off
> or booting into a separate OS image has the same problem.
>
> It's just a question of minimizing downtime.

If availability is critical you might consider redundancy with CARP/pfsync.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

quartz-2
> If availability is critical you might consider redundancy with CARP/pfsync.

It's not critical enough to be worth dealing that. Going down for like
15 minutes is fine, but most of a day is not.

In a perfect world we're looking for an update mechanism similar in
speed and ease to other OSs where you can run a one liner on the live
system which automatically downloads and installs a few files and
reboots. I'm trying to get as close to that as possible without having
to create and maintain a whole home-grown custom procedure.

It looks like the M:tier thing is pretty close, my only concern is how
long it'll last before the maintainers lose interest and the project
gets abandoned.

12