Re: Is this an intrusion?
Maurice McCarthy wrote: > Hi, > > $ xauth list > ... > advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 > f3aa08ed0926482c51f5cb386e28a0ea > > > Virgin Media is my ISP. Is this an intrusion into my system please? I > ran xauth remove ... just for the sake of it anyhow. well, even if it wasn't, you just posted the secret key to a public list, so probably wise to remove it anyway. :)
Re: Is this an intrusion?
On 15/06/2017 16:47, Dot Yet wrote: > On Thu, Jun 15, 2017 at 9:12 AM Maurice McCarthy > wrote: > >> Hi, >> >> $ xauth list >> ... >> advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 >> f3aa08ed0926482c51f5cb386e28a0ea >> >> >> Virgin Media is my ISP. Is this an intrusion into my system please? I >> ran xauth remove ... just for the sake of it anyhow. >> >> Thanks >> Moss > > > Maybe. Are there other hints in the system log files, history files around >> someone trying to authenticate or execute commands? Was there a possibility >> that there was a screen sharing session done for any kind of support >> activities (would not be the case as you are already suspecting intrusion). >> More likely you typo'd adding a host, advancedsearch is what NXDOMAIN queries get directed to, just turn it off on my virgin media
Re: Is this an intrusion?
On Thu, Jun 15, 2017 at 9:12 AM Maurice McCarthy wrote: > Hi, > > $ xauth list > ... > advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 > f3aa08ed0926482c51f5cb386e28a0ea > > > Virgin Media is my ISP. Is this an intrusion into my system please? I > ran xauth remove ... just for the sake of it anyhow. > > Thanks > Moss Maybe. Are there other hints in the system log files, history files around > someone trying to authenticate or execute commands? Was there a possibility > that there was a screen sharing session done for any kind of support > activities (would not be the case as you are already suspecting intrusion). >
Re: vmd: cannot reset VCPU 0 - exiting
On Thu, Jun 15, 2017 at 09:18:57AM -0500, Ax0n wrote: > Thanks, Mike. That helped. > > What's the oldest viable microarch required for unrestricted guest, and can > I detect this capability in dmesg the way we can see VMX/EPT? I'm on the > hunt for a decent desktop specifically for vmm, and had been eyeballing > some dirt cheap Craigslist i5s. Now it seems that might not be the best > plan. > Westmere or later. Check wikipedia and the Intel ark site. -ml > On Thu, Jun 15, 2017 at 1:40 AM, Mike Larkin wrote: > > > On Wed, Jun 14, 2017 at 10:25:43PM -0500, Ax0n wrote: > > > I'm having trouble booting OpenBSD 6.1-Release in vmm on recent > > snapshots. > > > > > > I can boot an amd64 bsd.rd and do the install, but the resulting disk > > image > > > aborts silently (or hangs with no console output) with the subject line > > > above the only hint of what happens, found in daemon.log, and > > "vm_resetcpu: > > > failed" in dmesg. > > > > > > I can boot my -stable disk image if I specify -b /bsd (and thus, use the > > > snapshot kernel from the host to boot the -release VM's disk image) but > > > this seems like a Bad Idea. > > > > > > > Your machine is older and doesn't have unrestricted guest capability, which > > for the moment means no BIOS. Since that's the default now, this is why it > > is breaking. > > > > I will fix this at some point but for now, use -b, and set it the same as > > the disk image. That should force it to fallback to the old faux-bootloader > > mode, loading the disk's own /bsd image (not from your host): > > > > vmctl start test -c -i 1 -d disk.img -b disk.img > > > > -ml > > > > > dmesg: > > > OpenBSD 6.1-current (GENERIC.MP) #8: Wed Jun 14 16:10:57 MDT 2017 > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > real mem = 8560467968 (8163MB) > > > avail mem = 8295235584 (7910MB) > > > mpath0 at root > > > scsibus0 at mpath0: 256 targets > > > mainbus0 at root > > > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdc010 (37 entries) > > > bios0: vendor TOSHIBA version "V2.90" date 12/10/2010 > > > bios0: TOSHIBA Qosmio X505 > > > acpi0 at bios0: rev 2 > > > acpi0: sleep states S0 S3 S4 S5 > > > acpi0: tables DSDT FACP HPET MCFG APIC BOOT SLIC DMAR SSDT > > > acpi0: wakeup devices EHC1(S3) EHC2(S3) HDEF(S3) PXS1(S4) RP05(S5) > > PXS5(S5) > > > RP07(S5) PXS7(S5) GLAN(S4) PEG4(S4) PEG5(S4) PEG6(S4) LID_(S4) > > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > > acpihpet0 at acpi0: 14318179 Hz > > > acpimcfg0 at acpi0 addr 0xe000, bus 0-255 > > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > > cpu0 at mainbus0: apid 0 (boot processor) > > > cpu0: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.23 MHz > > > cpu0: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > > cpu0: 256KB 64b/line 8-way L2 cache > > > cpu0: TSC frequency 1729233020 Hz > > > cpu0: smt 0, core 0, package 0 > > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > > cpu0: apic clock running at 132MHz > > > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > > > cpu1 at mainbus0: apid 2 (application processor) > > > cpu1: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > > cpu1: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > > cpu1: 256KB 64b/line 8-way L2 cache > > > cpu1: smt 0, core 1, package 0 > > > cpu2 at mainbus0: apid 4 (application processor) > > > cpu2: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > > cpu2: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > > cpu2: 256KB 64b/line 8-way L2 cache > > > cpu2: smt 0, core 2, package 0 > > > cpu3 at mainbus0: apid 6 (application processor) > > > cpu3: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > > cpu3: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > > cpu3: 256KB 64b/line 8-way L2 cache > > > cpu3: smt 0, core 3, package 0 > > > cpu4 at mainbus0: apid 1 (application processor) > > > cpu4: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > > cpu4: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,
Re: HPLIP HP Laserjet Pro MFP M130fn PPD Plugin installation fails
On Sun, Jun 04, 2017 at 07:09:19PM +0200, Reheis Claus wrote: > Hi all, > > Recently I acquired an HP Laserjet Pro MFP M130fn and I would like to > use it with my OpenBSD Deskop... > As it is supported since hplip 3.17 I have to use OpenBSD Current. > I managed to get until the plugin installation, but now I am stuck at > the point: > > /usr/local/bin/python2.7 plugin_install.py > > License blablabla > > Do you accept the license terms for the plug-in (y=yes*, n=no, q=quit) ? y > sh: lsb_release: not found > Plugin installation failed > error: Plugin installation failed > > Any advice? thx Hi. Thanks for the report. FWIW I just fixed it in current. -- Antoine
Re: vmd: cannot reset VCPU 0 - exiting
Thanks, Mike. That helped. What's the oldest viable microarch required for unrestricted guest, and can I detect this capability in dmesg the way we can see VMX/EPT? I'm on the hunt for a decent desktop specifically for vmm, and had been eyeballing some dirt cheap Craigslist i5s. Now it seems that might not be the best plan. On Thu, Jun 15, 2017 at 1:40 AM, Mike Larkin wrote: > On Wed, Jun 14, 2017 at 10:25:43PM -0500, Ax0n wrote: > > I'm having trouble booting OpenBSD 6.1-Release in vmm on recent > snapshots. > > > > I can boot an amd64 bsd.rd and do the install, but the resulting disk > image > > aborts silently (or hangs with no console output) with the subject line > > above the only hint of what happens, found in daemon.log, and > "vm_resetcpu: > > failed" in dmesg. > > > > I can boot my -stable disk image if I specify -b /bsd (and thus, use the > > snapshot kernel from the host to boot the -release VM's disk image) but > > this seems like a Bad Idea. > > > > Your machine is older and doesn't have unrestricted guest capability, which > for the moment means no BIOS. Since that's the default now, this is why it > is breaking. > > I will fix this at some point but for now, use -b, and set it the same as > the disk image. That should force it to fallback to the old faux-bootloader > mode, loading the disk's own /bsd image (not from your host): > > vmctl start test -c -i 1 -d disk.img -b disk.img > > -ml > > > dmesg: > > OpenBSD 6.1-current (GENERIC.MP) #8: Wed Jun 14 16:10:57 MDT 2017 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > real mem = 8560467968 (8163MB) > > avail mem = 8295235584 (7910MB) > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdc010 (37 entries) > > bios0: vendor TOSHIBA version "V2.90" date 12/10/2010 > > bios0: TOSHIBA Qosmio X505 > > acpi0 at bios0: rev 2 > > acpi0: sleep states S0 S3 S4 S5 > > acpi0: tables DSDT FACP HPET MCFG APIC BOOT SLIC DMAR SSDT > > acpi0: wakeup devices EHC1(S3) EHC2(S3) HDEF(S3) PXS1(S4) RP05(S5) > PXS5(S5) > > RP07(S5) PXS7(S5) GLAN(S4) PEG4(S4) PEG5(S4) PEG6(S4) LID_(S4) > > acpitimer0 at acpi0: 3579545 Hz, 24 bits > > acpihpet0 at acpi0: 14318179 Hz > > acpimcfg0 at acpi0 addr 0xe000, bus 0-255 > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.23 MHz > > cpu0: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > cpu0: 256KB 64b/line 8-way L2 cache > > cpu0: TSC frequency 1729233020 Hz > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 132MHz > > cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE > > cpu1 at mainbus0: apid 2 (application processor) > > cpu1: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > cpu1: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > cpu1: 256KB 64b/line 8-way L2 cache > > cpu1: smt 0, core 1, package 0 > > cpu2 at mainbus0: apid 4 (application processor) > > cpu2: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > cpu2: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > cpu2: 256KB 64b/line 8-way L2 cache > > cpu2: smt 0, core 2, package 0 > > cpu3 at mainbus0: apid 6 (application processor) > > cpu3: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > cpu3: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > cpu3: 256KB 64b/line 8-way L2 cache > > cpu3: smt 0, core 3, package 0 > > cpu4 at mainbus0: apid 1 (application processor) > > cpu4: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > cpu4: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA, > CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM, > PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16, > xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR > > cpu4: 256KB 64b/line 8-way L2 cache > > cpu4: smt 1, core 0, package 0 > > cpu5 at mainbus0: apid 3 (application processor) > > cpu5: Intel(R) Core(TM) i7 CPU Q 740 @ 1.73GHz, 1729.00 MHz > > cpu5: > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,
Is this an intrusion?
Hi, $ xauth list ... advancedsearch.virginmedia.com:0 MIT-MAGIC-COOKIE-1 f3aa08ed0926482c51f5cb386e28a0ea Virgin Media is my ISP. Is this an intrusion into my system please? I ran xauth remove ... just for the sake of it anyhow. Thanks Moss
Re: Rebuilding a degraded RAID5 softraid array
> Have you had the same problem, in that softraid wouldn't assemble the > RAID volume with a missing disk? How did you "remove" the failed device > from the RAID array (ie. you 'add' the new disk with -R during rebuild, > but how do you 'remove' the failed/offline drive with eg. bioctl)? No, in fact I used RAID5 purely for testing if I broke something during my softraid hackings or not. My testing of RAID5 was intensive offlining and rebuild with a new drive. No, I've not used 4 real drives, but in fact just 2 real drives and on every just 2 RAID partitions. I created array with something like -l /dev/sd0a,/dev/sd0d,/dev/sd1a,/dev/sd1d -- or so and then randomly put some drive/partition off-line by bioctl -O and then used the same to rebuild by bioctl -R. If you put drive offline it'll be offline and will not be attempted to be added again if its health status changes (somehow and whatever it means). softraid founds its drives since it uses (1) specific RAID partitions and (2) it saves specific metadata to the partition. This way RAID partitions (those already part of some array) know what array they are part of. That also means that if you use bioctl -c on drive/partition which is already part of some array, it'll not attempt array creation but array attachement. It's somewhat misleading and I always felt that there should be clear "attach" and "create" options in bioctl but so far have not come with any patches for this. Anyway, easy testing. Do you have some windows/linux machine with virtualbox or do you use openbsd with vmd? If so just create virtual openbsd environment with several drives and test what I suggest: (1) create RAID5, (2) put one of the drives into off-line mode (3) rebuild with another drive. Easy isn't it? If this runs fine for you, do the same on real array...and pray/cross your finger/do whatever you do in this case. :-)
Re: Rebuilding a degraded RAID5 softraid array
Karel Gardas @ 2017-06-15T09:07:39 +0200: > On Thu, Jun 15, 2017 at 7:04 AM, LEVAI Daniel wrote: > > Thanks Karel for pointing this out, you are in fact right, and > > nothing is wrong with the logging, I just forgot that I'm decrypting > > that device 'automatically' in rc.local. And the kernel log was from > > before this, hence the similar device names. I still think that > > nonetheless I should've gotten a degraded array that I can work with > > (eg. rebuild). > > > > As a matter of fact I removed everything from the machine, and left > > just the four drives of the array, then booted into bsd.rd from a > > thumb drive. > > > > Strangest thing is, if I boot with the 'bad' (=failing) drive as > > part of the array, softraid brings the volume online (albeit > > degraded) and I can even decrypt/mount the volume and use it (only > > one drive being bad in the array of RAID5). If I remove/replace > > said failing drive, I'm not getting a degraded volume, just the > > error about the missing chunk and that it refuses to bring it > > online. > > > > Either I completely misunderstood the whole idea about softraid and > > the RAID5 setup (I mean, removing a device - failed or not - > > shouldn't hinder the assembly of the array, right?), or I'm missing > > something really obvious 8-/ > > I'm not sure, but I think that there is somewhat blury line in between > the array creation and array attach. In fact OpenBSD is using the same > command for this bioctl -c . So I see you do have two possibilities > probably: > > 1) IMHO more safe. If you do have enough SATA ports, then attach both > your failing drive and your new drive to the system. Boot. OpenBSD > should detect and attach RAID5 in degraded state and then you will be > able to perform your rebuild (if your failing drive is not offline, > you can use bioctl to offline it) So I'd have the degraded array with four disks, plus the new one not in the array, but lying there in the background. Let's say the failing drive is offline. Then to rebuild the degraded array, I'd run # bioctl -R /dev/newdisk sd8 This way, I basically add a new disk to the array, so I'll have a five disk RAID5 setup (with a failing drive being the 'fourth')? How do you think the behavior -- that now softraid won't assemble the volume with a missing disk -- will change, after I remove the failing drive again, leaving the array then with four but working drives? > or > 2) less safe (read completely untested and unverified by reading the > code on my side). Use bioctl -c 5 -l > to attach the RAID5 array including the new drive. Please do > *NOT* force this. See if bioctl complains for example about missing > metadata or if it automatically detects new drive and start rebuild. I've actually given this some thought before, but I swiftly discarded it, -c being a 'create' option, and I didn't want to 'overwrite' my existing RAID5 array. But to be sure I'm on the same page, this way I won't have five disks attached, only four (one of them being the new and clean one), and I'd basically instruct softraid to 'recreate' the RAID5 array from the 3 original and 1 new drive? The assumption is -- if I'm not mistaken -- that softraid would somehow figure out that 3 of the four disks (specified by option '-l') are parts of a RAID5 array, then it'd essentially 'add' the new disk as the fourth, right? > Generally speaking I'd use (1) since I used this in the past and had > no issue with it. Have you had the same problem, in that softraid wouldn't assemble the RAID volume with a missing disk? How did you "remove" the failed device from the RAID array (ie. you 'add' the new disk with -R during rebuild, but how do you 'remove' the failed/offline drive with eg. bioctl)? Daniel
Re: Rsnapshot configuration - Data integrity
On 17-06-14 21:43:58, G wrote: > I didn't want to use aide for data integrity. Just wanted/want to > familiarize my self with various intrusion detection tools. In that case also have a look at https://ossec.github.io/ and http://www.la-samhna.de/samhain/
Re: Rebuilding a degraded RAID5 softraid array
On Thu, Jun 15, 2017 at 7:04 AM, LEVAI Daniel wrote: > Thanks Karel for pointing this out, you are in fact right, and nothing is > wrong with the logging, I just forgot that I'm decrypting that device > 'automatically' in rc.local. And the kernel log was from before this, hence > the similar device names. > I still think that nonetheless I should've gotten a degraded array that I can > work with (eg. rebuild). > > As a matter of fact I removed everything from the machine, and left just the > four drives of the array, then booted into bsd.rd from a thumb drive. > > Strangest thing is, if I boot with the 'bad' (=failing) drive as part of the > array, softraid brings the volume online (albeit degraded) and I can even > decrypt/mount the volume and use it (only one drive being bad in the array of > RAID5). > If I remove/replace said failing drive, I'm not getting a degraded volume, > just the error about the missing chunk and that it refuses to bring it online. > > Either I completely misunderstood the whole idea about softraid and the RAID5 > setup (I mean, removing a device - failed or not - shouldn't hinder the > assembly of the array, right?), or I'm missing something really obvious 8-/ I'm not sure, but I think that there is somewhat blury line in between the array creation and array attach. In fact OpenBSD is using the same command for this bioctl -c . So I see you do have two possibilities probably: 1) IMHO more safe. If you do have enough SATA ports, then attach both your failing drive and your new drive to the system. Boot. OpenBSD should detect and attach RAID5 in degraded state and then you will be able to perform your rebuild (if your failing drive is not offline, you can use bioctl to offline it) or 2) less safe (read completely untested and unverified by reading the code on my side). Use bioctl -c 5 -l to attach the RAID5 array including the new drive. Please do *NOT* force this. See if bioctl complains for example about missing metadata or if it automatically detects new drive and start rebuild. Generally speaking I'd use (1) since I used this in the past and had no issue with it.
