update/upgrade

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

Re: update/upgrade

Jay Patel-7
If you are looking for one liner for snapshots :

http://bsdguru.in/3/any-tutorial-for-installing-snap-on-openbsd-5-8

and for stable m:tier is best.



On Mon, Sep 21, 2015 at 8:56 AM, Quartz <[hidden email]> wrote:

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

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Stuart Henderson
In reply to this post by quartz-2
On 2015-09-20, 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).
>
>

You don't need to use mtier-produced binpatches, the framework to generate them
is also available

http://opensource.mtier.org/binpatchng.html

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Marcus MERIGHI
In reply to this post by quartz-2
[hidden email] (Quartz), 2015.09.21 (Mon) 02:43 (CEST):

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

openup
# Author: Antoine Jacoutot <[hidden email]>

OpenBSD commit stats ajacoutot@
http://www.oxide.org/cvs/ajacoutot.html

e.g.
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr

Bye, Marcus

> !DSPAM:55ff540b42247974415012!

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Adam Thompson
In reply to this post by quartz-2
On 09/20/2015 10:26 PM, Quartz wrote:
> 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.

Handling updates/upgrades in OpenBSD has always been one of the more
difficult parts for ordinary users.
Having said that, Antoine &c. have developed a great service.

As to "lose interest", I think you're missing the fact that m:Tier is a
company, not just another open-source project.  They've been around for
over seven (7) years already.  If they were going to simply "lose
interest", I think they'd have done so long ago.  They do have a regular
website, at www.mtier.org, that fills in all the gaps you were talking
about in a previous post.

You can also *pay* for a subscription, which I would assume - barring
utter insanity on the part of every employee there - would go a long way
towards ensuring they stick around.  (Per a previous conversation with
them, you don't have to buy a subscription for every single machine
you're updating - but confirm that with them before basing any plans on
that.)

-Adam

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Amit Kulkarni-5
In reply to this post by Marcus MERIGHI
On Mon, Sep 21, 2015 at 8:57 AM, Marcus MERIGHI <[hidden email]>
wrote:

> [hidden email] (Quartz), 2015.09.21 (Mon) 02:43 (CEST):
> > >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.
>
> openup
> # Author: Antoine Jacoutot <[hidden email]>
>
> OpenBSD commit stats ajacoutot@
> http://www.oxide.org/cvs/ajacoutot.html
>
> e.g.
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/etc/rc.d/rc.subr
>
> Bye, Marcus
>
> > !DSPAM:55ff540b42247974415012!
>
>
In addition, a couple of other committers (robert@, jasper@) also work or
used to work for mtier. Mtier supports the OpenBSD project in many other
ways too.

Reply | Threaded
Open this post in threaded view
|

Re: update/upgrade

Chris Cappuccio
In reply to this post by quartz-2
Quartz [[hidden email]] wrote:
> >If availability is critical you might consider redundancy with CARP/pfsync.
>
> 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.

Stuart already gave you the link for the infrastructure. If those guys stop
running it, you or anyone else can take up the torch. It's not rocket
science, dude. The project itself has left the door open for a competent
third party to take this role. One has done so, and released their entire
build infrastructure. Is there another finer point you need clarified?

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 9:36 PM, Quartz <[hidden email]> 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.
>


Is it possible to upgrade via separate OS? Chroot into a new system, run sysmerge & voila?

12