Re: Bridging firewall with online update/upgrade

[Markus Wernig]

On 4/3/24 18:19, Karel Lucas wrote:

I want to use ETH1 for the input from my
ADSL modem, ETH2 and ETH3 for the output to my network. Furthermore, I
would like to use ETH4 for the update/upgrade of the firewall. Remove
the connection from ETH1, plug it into ETH4, and update/upgrade. Then
the connection returns to ETH1. ETH4 therefore receives an IP address
and ETH1,ETH2 and ETH3 not. But now the problem: as long as the network
connection of the ADSL modem is in ETH4, my network, including the
firewall, is no longer secured, and attackers can take advantage. I
therefore wonder whether it is possible to let the data flow via ETH1
and ETH4 first pass through PF before an update/upgrade is done via
ETH4. This means that the bridging firewall will have two entrances, one
without and one with an IP address. I would like to know if that is
possible, or if there is another option.
I'm not entirely sure about how bridging works on OpenBSD and PF, but 
the answer, from a network point of view, would be "Don't make ETH4 part 
of the same bridge as ETH1-3, and apply a basic, restrictive ruleset to 
ETH4, allowing only for the update traffic to/from $self".

(I hope I'm not missing something basic here)

Re: Bridging firewall with online update/upgrade

[Nick Holland]

On 4/3/24 12:19, Karel Lucas wrote:

Hi all,

I am creating a bridging firewall with OpenBSD and the following
hardware:
https://www.amazon.nl/dp/B0B6J89MXJ?ref=ppx_pop_dt_b_asin_image=1.
OpenBSD is already installed. I want to use ETH1 for the input from my
ADSL modem, ETH2 and ETH3 for the output to my network. Furthermore, I
would like to use ETH4 for the update/upgrade of the firewall. Remove
the connection from ETH1, plug it into ETH4, and update/upgrade. Then
the connection returns to ETH1. ETH4 therefore receives an IP address
and ETH1,ETH2 and ETH3 not. But now the problem: as long as the network
connection of the ADSL modem is in ETH4, my network, including the
firewall, is no longer secured, and attackers can take advantage. I
therefore wonder whether it is possible to let the data flow via ETH1
and ETH4 first pass through PF before an update/upgrade is done via
ETH4. This means that the bridging firewall will have two entrances, one
without and one with an IP address. I would like to know if that is
possible, or if there is another option.



There are lots of options, but I'm not seeing the point of the bridging
firewall here.  Sounds like you are making things complicated and I'm
suspicious you won't be getting much benefit from it.  I think you would
do much better with NAT.

But...pretending for the moment this is the right solution for you, if
you are already planning on physically moving to the box to do upgrades,
just download the installXX.img file on another machine, drop it on a
thumb drive, walk over to your bridge and reboot from the thumb drive
and upgrade, don't bother fiddling with cables.

I'm also pretty sure you can put an internal IP on one of the ports
other than the bridge, and copy the files and install from there.  That
would have the benefit of remote administration, too.

Nick.

Re: Bridging firewall with online update/upgrade

[Zé Loff]

On Wed, Apr 03, 2024 at 06:19:29PM +0200, Karel Lucas wrote:
> Hi all,
> 
> I am creating a bridging firewall with OpenBSD and the following hardware:
> https://www.amazon.nl/dp/B0B6J89MXJ?ref=ppx_pop_dt_b_asin_image=1.
> OpenBSD is already installed. I want to use ETH1 for the input from my ADSL
> modem, ETH2 and ETH3 for the output to my network. Furthermore, I would like
> to use ETH4 for the update/upgrade of the firewall. Remove the connection
> from ETH1, plug it into ETH4, and update/upgrade. Then the connection
> returns to ETH1. ETH4 therefore receives an IP address and ETH1,ETH2 and
> ETH3 not. But now the problem: as long as the network connection of the ADSL
> modem is in ETH4, my network, including the firewall, is no longer secured,
> and attackers can take advantage. I therefore wonder whether it is possible
> to let the data flow via ETH1 and ETH4 first pass through PF before an
> update/upgrade is done via ETH4. This means that the bridging firewall will
> have two entrances, one without and one with an IP address. I would like to
> know if that is possible, or if there is another option.
> 

I'd just run sysupgrade -n, unplug ETH1, reboot into the installer and
upgrade, reboot, and finally plug ETH1 back in.

-- 
 

Bridging firewall with online update/upgrade

[Karel Lucas]

Hi all,

I am creating a bridging firewall with OpenBSD and the following 
hardware: 
https://www.amazon.nl/dp/B0B6J89MXJ?ref=ppx_pop_dt_b_asin_image=1. 
OpenBSD is already installed. I want to use ETH1 for the input from my 
ADSL modem, ETH2 and ETH3 for the output to my network. Furthermore, I 
would like to use ETH4 for the update/upgrade of the firewall. Remove 
the connection from ETH1, plug it into ETH4, and update/upgrade. Then 
the connection returns to ETH1. ETH4 therefore receives an IP address 
and ETH1,ETH2 and ETH3 not. But now the problem: as long as the network 
connection of the ADSL modem is in ETH4, my network, including the 
firewall, is no longer secured, and attackers can take advantage. I 
therefore wonder whether it is possible to let the data flow via ETH1 
and ETH4 first pass through PF before an update/upgrade is done via 
ETH4. This means that the bridging firewall will have two entrances, one 
without and one with an IP address. I would like to know if that is 
possible, or if there is another option.

Octeon uboot update/upgrade kernel need to be copied to the fat partition of your USB drive in Ubiquiti

[Daniel Ouellet]

Took me a while to find this, and I saw a few questions on misc@ as well
and sense the same frustration I had.

The thread was this one:

http://marc.info/?l=openbsd-misc=144562030714263=2

I am sure more will have the same frustration then me on this as just
compiling the kernel it does take a LOMG while...

Anyway, on a working system you do need to copy the new kernel to the
fat partition of the USB dive and that was the frustrating part.

The solution is actually real simple after you have done it once...

Like Miod said: "the only filesystem #$%^@# u-boot can read"

Then just do this:

mount_msdos /dev/sd0i /mnt

cp -rp /bsd /mnt/bsd

umount /mnt

reboot and your done.

If you want to see your new file. NOT much space there, so can't keep
multiple kernel there.

# ls -al /mnt
total 22676
drwxr-xr-x   1 root  wheel16384 Dec 31  1979 .
drwxr-xr-x  13 root  wheel  512 Nov 13 22:38 ..
-rwxr-xr-x   1 root  wheel  4029297 Nov 13 22:38 bsd
-rwxr-xr-x   1 root  wheel  7559405 Oct 13 04:58 bsd.rd

at reboot you have the new kernel.

Hopefully this will save time to others too.

I haven't find it anywhere, so now it is!


# dmesg
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2015 OpenBSD. All rights reserved.
http://www.OpenBSD.org

OpenBSD 5.8-current (GENERIC) #0: Fri Nov 13 22:35:14 EST 2015
r...@gateway.ouellet.us:/usr/src/sys/arch/octeon/compile/GENERIC
real mem = 247463936 (236MB)
avail mem = 245170176 (233MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cpu0 at mainbus0: Cavium OCTEON CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way
clock0 at mainbus0: int 5
iobus0 at mainbus0
dwctwo0 at iobus0 base 0x118006800 irq 56
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 "Octeon DWC2 root hub" rev 2.00/1.00 addr 1
octrng0 at iobus0 base 0x14000 irq 0
cn30xxgmx0 at iobus0 base 0x118000800 irq 48
cnmac0 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f8
atphy0 at cnmac0 phy 7: F1 10/100/1000 PHY, rev. 2
cnmac1 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:f9
atphy1 at cnmac1 phy 6: F1 10/100/1000 PHY, rev. 2
cnmac2 at cn30xxgmx0: RGMII, address 44:d9:e7:40:ac:fa
atphy2 at cnmac2 phy 5: F1 10/100/1000 PHY, rev. 2
uartbus0 at mainbus0
com0 at uartbus0 base 0x118000800 irq 34: ns16550, no working fifo
com0: console
com1 at uartbus0 base 0x118000c00 irq 35: ns16550, no working fifo
/dev/ksyms: Symbol table not valid.
umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Cruzer Fit"
rev 2.00/1.27 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI4 0/direct
removable serial.07815571360927117103
sd0: 15267MB, 512 bytes/sector, 31266816 sectorsmisc
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (55072c2137c3a4e7.a) swap on sd0b dump on sd0b
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!

Re: update/upgrade

[Patrick Dohman]

> 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

[Jay Patel]

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

[Stuart Henderson]

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

[Chris Cappuccio]

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

[Marcus MERIGHI]

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

[Adam Thompson]

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

[Amit Kulkarni]

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

[Nick Holland]

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

[Quartz]

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

[Quartz]

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

[Nick Holland]

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

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

Re: update/upgrade

[Quartz]

"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

[Rob Pierce]

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

[Quartz]

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

[Quartz]

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

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

Re: update/upgrade

[Patrick Dohman]

> 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

[Quartz]

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.

update/upgrade

[Quartz]

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

Re: update/upgrade

[Pedro Tender]

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

Re: update/upgrade

[Quartz]

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

[Christian Weisgerber]

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

[Kimmo Paasiala]

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

[Josh Grosse]

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

[Quartz]

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

[Pedro Tender]

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