Re: update/upgrade
> On Sep 20, 2015, at 9:36 PM, 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. > Is it possible to upgrade via separate OS? Chroot into a new system, run sysmerge & voila?
Re: update/upgrade
Quartz [qua...@sneakertech.com] 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?
Re: update/upgrade
On Mon, Sep 21, 2015 at 8:57 AM, Marcus MERIGHI wrote: > qua...@sneakertech.com (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 > > 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.
Re: update/upgrade
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
Re: update/upgrade
qua...@sneakertech.com (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 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!
Re: update/upgrade
On 2015-09-20, Quartz 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
Re: update/upgrade
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 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.
Re: update/upgrade
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.
Re: update/upgrade
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.
Re: update/upgrade
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.
Re: update/upgrade
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.
Re: update/upgrade
"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.
Re: update/upgrade
> On Sep 20, 2015, at 3:49 PM, 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). > 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
Re: update/upgrade
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.
Re: update/upgrade
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).
Re: update/upgrade
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.
Re: update/upgrade
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.
Re: update/upgrade
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.
Re: update/upgrade
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.
Re: update/upgrade
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" 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).
Re: update/upgrade
On 2015-09-20, 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. You do that part on a bigger box, build releases there, and use these to update the low power devices. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: update/upgrade
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).
Re: update/upgrade
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.
Re: update/upgrade
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/
Re: update/upgrade
On Sun, Sep 20, 2015 at 11:49 PM, 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). > Something like this? http://www.bsdnow.tv/tutorials/stable-iso
Re: update/upgrade
Snapshots? On Sep 20, 2015 9:54 PM, "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).
