On 13-10-27 03:49 PM, Predrag Punosevac wrote:
This is definitelly a thread which I followed with great interest. In
the light of Stefan's diff I have three questions.
1. Does that make
http://blog.cochard.me/2012/03/openbsd-51-installation-on-sofraid4.html
accurate? That would mean that I can crypt everything on my laptop
including /.
That link, one of the ones I found, is now *partially* obsolete, see below.
The undeadly article is also now *partially* obsolete in the same way.
The individual steps and tools used are still 100% accurate, but the
underlying assumption of where /boot and /bsd must be placed is now wrong.
2. My second question is in the light of Stephan's
"It writes data to each chunk in sequence to provide increased capacity.
CONCAT does not provide redundancy."
Does above mean that if I want to use RAID 1/altroot for redundancy
purposes I still have to follow FAQ and create to identical root and
swap partitions on two separate HDD before using RAID 1 for the rest?
RAID1 and /altroot are two different, and complementary strategies.
The point of this thread is that you do *not* have to create identical
root and swap partitions, despite what the FAQ implies.
As of (at least) 5.4-RELEASE (and probably much earlier), after booting
from CD (or PXE, or bsd.rd), instead of choosing "Install" right away at
the first step, choose "shell".
Follow the same MAKEDEV steps that all the FAQ and blog entries talk about.
Zero out the MBR/partition table/disklabel (using "fdisk -iy") just like
before.
=== Here's where it changes: ===
Using "disklabel -E", create *one* partition, which can fill the entire
disk, of type "raid", on each disk.
No need for wd0a=/, wd0b=swap, wd0m=raid, just create a single wd0a=raid
and nothing else.
=== That's the change. ===
In my case, a system with three SATA drives, once I used bioctl(8) to
create the RAID1 volume, it attached as "sd3".
Now exit the shell, and enter the Installer. (I think you can reboot at
this point, if you need to, but I didn't test that.)
Tell the installer to use the newly-attached softraid(4) volume, not any
of the physical disks.
Auto-partitioning works, or you can do custom partitioning (in which
case the simplest is usually an 'a' slice covering most of the RAID
volume, and a 'b' slice for swap).
3. Are there any strong opinions on CARP/pfsync vs RAID 1/altroot for
firewall redundancy for small office use.
In my case, I've chosen to do sd0+sd1 as RAID1, and sd2 will mount as
/altroot. Then I have another entire identical system using both CARP
and iBGP.
This gives me two layers of *redundancy* (RAID1 and CARP), and one layer
of *recoverability* (altroot). In other words, I should never be
without a router in the first place, and if I completely !@#$%^& them up
(by human error), I still might be able to just pull the RAID1 disks and
boot off /altroot instead, and be back up and running in <5 minutes.
(Rationale: I don't feel like paying Cisco or Juniper $250k for this
capability when I can build it myself using OpenBSD. OK, those boxes do
several things much better than OpenBSD, but not $250k better, at least
not in my use case. The cheapest-possible way to do this with hardware
routers that I know of is to buy two refurb Catalyst 6500/SUP-720-VSE
chassis, or two Catalyst 3750X L3 switches, either of which would still
cost me ~$20k+. The OpenBSD solution is better in many ways and the
refurb servers running this only cost $1700 total including spare parts.)
RAID1, CARP, and /altroot solve three different problems.
They all happen to address the problem of a hard disk dying, but in
different ways.
RAID1 prevents a dead disk from affecting a running system.
CARP prevents an entire dead system from affecting a running network.
(in theory, anyway :-)
Altroot prevents corruption of a root partition from being completely
fatal; it's a point-in-time backup copy of / that you can restore from -
and in the worst-case scenario, replace the entire root disk with.
--
-Adam Thompson
athom...@athompso.net
