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
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
r 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 recei
more, 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
connec
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&m=144562030714263&w=2
I am sure more will have the same frustration then me on this as just
compiling the kernel it does take a
> 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. T
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
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 worrie
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 u
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
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
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 cri
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 whe
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
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
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
"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.
> 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 tha
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 -sta
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
>
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.
t
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
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 di
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 script
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
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 lo
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).
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.
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
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 a
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 t
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).
32 matches
Mail list logo
