Re: pflogd write /var/run/mypflogdinstance.pid?
On 12/13/20 8:32 PM, Theo de Raadt wrote: If a pflogd dies because of a bug, the pid listed in the file may be reused, and then your kill `cat pidfile` will kill the incorrect process. I understand your concern, but as written before, I am not asking to drop pkill support. How about adding a static -uuid option to the pflogd command line (instead of "-p /var/run/pflogd.pid"), to be shown in the process list as well? Of course pflogd should ignore this uuid option. Its only purpose is to support pkill/pgrep. This would be a much more reliable and easy to use search pattern for pkill/ pgrep than the executable name or the interface name. Regards Harri
Re: pflogd write /var/run/mypflogdinstance.pid?
>> On 2020-12-13, Harald Dunkel wrote: > On 12/13/20 7:10 PM, Theo de Raadt wrote: >> >> And I'm suggesting the arguments should look like this: >> >> pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd) >> pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) >> >> That might allow more accurate pkill targetting. >> > > Wouldn't you admit that this appears to be very fragile? If I add > some flags to the pflogd command line then I have to verify the > pkill commands in newsyslog.conf again. You can search the whole argument list, but you only have to match a subset. For log rotation that might be the logfile name. But I would think the interface name would generally be the most likely to be a unique parameter.
Re: How to whitelist a good IP coming in with a senderscore of 0?
December 13, 2020 6:26 PM, "Chris Bennett" wrote: > I have run into a problem with an organization getting a senderscore of > 0. > This is not at all a spam source, but a political organization which is > the kiss of death these days. > > What's the right method to deal with this? I certainly don't want to > stop senderscore filtering, but I do want to receive emails from them. > You should probably look into the bypass keyword, it lets you create a filter rule that will bypass a phase (ie: in phase connect, if ip addr is X, then bypass the phase). Gilles
Re: pflogd write /var/run/mypflogdinstance.pid?
On Sun, Dec 13, 2020 at 08:24:13PM -, Stuart Henderson wrote: > On 2020-12-13, Harald Dunkel wrote: > > On 12/13/20 7:10 PM, Theo de Raadt wrote: > >> > >> And I'm suggesting the arguments should look like this: > >> > >> pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd) > >> pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) > >> > >> That might allow more accurate pkill targetting. > >> > > > > Wouldn't you admit that this appears to be very fragile? If I add > > some flags to the pflogd command line then I have to verify the > > pkill commands in newsyslog.conf again. > > Obviously if the daemon is changed, the rc.d script would be changed to > cope with it. It would make sense if the newsyslog.conf command was changed > to use that too, then it would track whatever is set in pflogd_flags. > > I was trying to solve exactly this kind of issue ages ago on application level (I was using linux at that time) and the only reliable solution I found was to use posix semaphores. How to make sure if application is still running or not using some kind of identifier for it (which *may* be a pid)? When starting application I was increasing 'application ID' semaphore number by one with SEM_UNDO flag. If application exited or was killed (doesn't matter) it was kernel job to decrease semaphore back to zero. By checking semaphore value if it is non-zero you know exactly if the process is still running (or not). I hope I'm not introducing any confusion here - it's late in my $TZ. -- Aleksander
Re: How to whitelist a good IP coming in with a senderscore of 0?
On Sun, Dec 13, 2020 at 08:45:53PM +, gil...@poolp.org wrote: > You should probably look into the bypass keyword, it lets you create a > filter rule that will bypass a phase (ie: in phase connect, if ip addr > is X, then bypass the phase). > > Gilles > Thanks! Chris
Re: Switching from trunk(4) to aggr(4)
On Sun, 13 Dec 2020 20:34:35 - (UTC), Stuart Henderson wrote: > On 2020-12-12, Daniel Jakots wrote: > > I've been using a LACP trunk on my apu (with the three em(4)). On > > top of which I have some vlans. I've been doing that for years and > > it's working fine. > > I used load-balancing trunk on APU before but stopped when I came to > the conclusion that APU running OpenBSD wasn't going to push more > than 1Gbps anyway.. (I use failover way more than any type of load > balancing) Yes but: - the three cables between the switch and the APU looks beautiful - I don't have to care which if is em0 and which if is em2. Just plug everything. :) > I don't see anything on the switch side I could change, and the log I > have is merely the ports going up or down when I reboot. > > > Any idea why aggr(4) stays in no carrier status? > > Do you get any clues from "ifconfig aggr0 debug"? I just tried # ifconfig aggr0 debug # dmesg # ifconfig aggr0 down # ifconfig aggr0 up # ifconfig aggr0 # checked the debug flag was still there # dmesg I also looked at /var/log/message to be save, but nothing relevant. > What does the lacp status look like on the switch? (or does it just > say 'up' or something and not really have any status?) It doesn't say anything about the lacp, it just says the individual ports are going up or down (which is normal since I'm rebooting the apu to apply the network config change). Cheers, Daniel
Re: Switching from trunk(4) to aggr(4)
On 2020-12-12, Daniel Jakots wrote: > I've been using a LACP trunk on my apu (with the three em(4)). On > top of which I have some vlans. I've been doing that for years and it's > working fine. I used load-balancing trunk on APU before but stopped when I came to the conclusion that APU running OpenBSD wasn't going to push more than 1Gbps anyway.. (I use failover way more than any type of load balancing) > My trunk0 which works is > trunk0: flags=8843 mtu 1500 > > media: Ethernet autoselect > > status: active > > And the aggr0 which doesn't come up is: > media: Ethernet autoselect > > status: no carrier > > > The only different thing I could see is the key (0x403c with trunk(4), > 0x6 with aggr(4)) but I don't see how I could change it to try if it > matters. > > Initially I thought the random lladdr from aggr(4) could be a problem > so I set it in the hostname.aggr0 file but it didn't help. > > I don't see anything on the switch side I could change, and the log I > have is merely the ports going up or down when I reboot. > > Any idea why aggr(4) stays in no carrier status? Do you get any clues from "ifconfig aggr0 debug"? What does the lacp status look like on the switch? (or does it just say 'up' or something and not really have any status?)
Re: pflogd write /var/run/mypflogdinstance.pid?
On 2020-12-13, Harald Dunkel wrote: > On 12/13/20 7:10 PM, Theo de Raadt wrote: >> >> And I'm suggesting the arguments should look like this: >> >> pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd) >> pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) >> >> That might allow more accurate pkill targetting. >> > > Wouldn't you admit that this appears to be very fragile? If I add > some flags to the pflogd command line then I have to verify the > pkill commands in newsyslog.conf again. Obviously if the daemon is changed, the rc.d script would be changed to cope with it. It would make sense if the newsyslog.conf command was changed to use that too, then it would track whatever is set in pflogd_flags.
Re: How to whitelist a good IP coming in with a senderscore of 0?
On 2020-12-13, Chris Bennett wrote: > I have run into a problem with an organization getting a senderscore of > 0. > This is not at all a spam source, but a political organization which is > the kiss of death these days. > > What's the right method to deal with this? I certainly don't want to > stop senderscore filtering, but I do want to receive emails from them. > > Thanks, > Chris Bennett > > > It depends what software you're using.
Re: pflogd write /var/run/mypflogdinstance.pid?
On Sun, Dec 13, 2020 at 10:42:20PM +0300, Consus wrote: On Sun, Dec 13, 2020 at 08:27:24PM +0100, Harald Dunkel wrote: At least OpenBSD is not alone with this problem. On Debian there is a tool "/bin/pidof", trying to guess the pid of a daemon to kill by looking at the process list as well. Some dude from Google came up with a good solution (for Linux of course). If you open a /proc/[pid] directory this PID cannot be recycled unless you close the fd. Hence you can do this: 1. Read /var/run/foobard.lock and get PID 2. Open /proc/[pid] 3. Check that PID is in fact belongs to an instance of foobard 4. kill() it Easy. Hmm... My memory served me bad. It's not that PID won't by recycled, it's that fd referencing it (you can get one from opening /proc/[pid]) will becomes invalid after PID is dead/recycled. So calling pidfd_send_signal(fd, ...) will fail instead of killing the wrong process.
Re: pflogd write /var/run/mypflogdinstance.pid?
On Sun, Dec 13, 2020 at 08:27:24PM +0100, Harald Dunkel wrote: At least OpenBSD is not alone with this problem. On Debian there is a tool "/bin/pidof", trying to guess the pid of a daemon to kill by looking at the process list as well. Some dude from Google came up with a good solution (for Linux of course). If you open a /proc/[pid] directory this PID cannot be recycled unless you close the fd. Hence you can do this: 1. Read /var/run/foobard.lock and get PID 2. Open /proc/[pid] 3. Check that PID is in fact belongs to an instance of foobard 4. kill() it Easy.
Re: pflogd write /var/run/mypflogdinstance.pid?
Harald Dunkel wrote: > On 12/13/20 7:10 PM, Theo de Raadt wrote: > > > > And I'm suggesting the arguments should look like this: > > > > pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd) > > pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) > > > > That might allow more accurate pkill targetting. > > > > Wouldn't you admit that this appears to be very fragile? I already spoke to that earlier. > My point is that a pid file on a volatile file system is much more > reliable than pkill/pgrep. I am not asking you to drop pkill/pgrep, > but I am missing the old -p option to pflogd. If a pflogd dies because of a bug, the pid listed in the file may be reused, and then your kill `cat pidfile` will kill the incorrect process. You are wrong because pidfiles are NOT more reliable. Where is your concrete reliable proposal?? I don't have one, and I admit it. You want to win points over which broken choice is better?
Re: pflogd write /var/run/mypflogdinstance.pid?
On 12/13/20 7:10 PM, Theo de Raadt wrote: And I'm suggesting the arguments should look like this: pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd) pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) That might allow more accurate pkill targetting. Wouldn't you admit that this appears to be very fragile? If I add some flags to the pflogd command line then I have to verify the pkill commands in newsyslog.conf again. Newsyslog doesn't tell if pkill doesn't find anything to send a HUP to. Not to mention that the "-s 160" is not set with "rcctl set flags". Apparently there is some magic code somewhere else. If this code is changed, then this might break the newsyslog configuration as well. Sorry to say, buts its obscure and error-prone. My point is that a pid file on a volatile file system is much more reliable than pkill/pgrep. I am not asking you to drop pkill/pgrep, but I am missing the old -p option to pflogd. At least OpenBSD is not alone with this problem. On Debian there is a tool "/bin/pidof", trying to guess the pid of a daemon to kill by looking at the process list as well. Its part of the sysv init environment. For years I wondered how comes that daemons in my containers silently got killed. They were visible in the parent's process list and were found by pidof. Regards Harri
Re: pflogd write /var/run/mypflogdinstance.pid?
Harald Dunkel wrote: > On 12/7/20 7:19 PM, Theo de Raadt wrote: > > Yep. > > > > It is possible we need a better strategy --- like placing *all* original > > argv in the [priv] title. > > > > If you change the pflogd command line in the process list, what is > supposed to happen to the existing code using pkill or pgrep, expecting > the *old* line? I'm suggesting such people will just have to cope. the current privsep looks like this: pflogd: [priv] (pflogd) pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) And I'm suggesting the arguments should look like this: pflogd: [priv] -s 160 -i pflog0 -f /var/log/pflog (pflogd) pflogd: [running] -s 160 -i pflog0 -f /var/log/pflog (pflogd) That might allow more accurate pkill targetting. I'm suggesting we consider the same for all privpse daemons which label themselves "[priv]" right now. It requires keeping argv constant, and passing it down to the privsep startup code.
How to whitelist a good IP coming in with a senderscore of 0?
I have run into a problem with an organization getting a senderscore of 0. This is not at all a spam source, but a political organization which is the kiss of death these days. What's the right method to deal with this? I certainly don't want to stop senderscore filtering, but I do want to receive emails from them. Thanks, Chris Bennett
Issues with Teclast F7 Plus
Hello, I just got a Teclast F7 Plus laptop and installed OpenBSD 6.8-current on it. Most things works except apm and touchpad. Using zzz or ZZZ, it seems suspend/hibernation start but are never achieved. The backlight keyboard and power led are still on. On Linux, keyboard goes black and power led slowly blinks. Plus, there is no way to resume the laptop. I have to force a poweroff using the power button. Regarding the touchpad, it doesn't work ; neither with wsmoused(8) nor in Xorg. It seems to be identified and attached to pms0. Looking at a Linux dmesg, it references I2C: [5.462957] kernel: input: HTIX5288:00 0911:5288 Touchpad as /devices/pci:00/:00:17.3/i2c_designware.7/i2c-8/i2c-HTIX5288:00/0018:0911:5288.0001/input/input11 So I guess OpenBSD should rather attach it to imt(4)? Find OpenBSD & Linux dmesg attached. I also add output from OpenBSD pcidump, sysctl, usbdevs in case it helps. Thanks for help, Joel OpenBSD 6.8-current (GENERIC.MP) #222: Sat Dec 12 10:30:51 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8385544192 (7997MB) avail mem = 8116105216 (7740MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x79ce9000 (74 entries) bios0: vendor American Megatrends Inc. version "S8K1_A1 tPAD 3.01" date 11/02/2020 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MSDM MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI TPM2 DMAR WDAT WSMT acpi0: wakeup devices LID0(S3) HDAS(S3) XHC_(S3) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1097.40 MHz, 06-7a-01 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 19MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.64 MHz, 06-7a-01 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.97 MHz, 06-7a-01 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 4MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) N4100 CPU @ 1.10GHz, 1096.29 MHz, 06-7a-01 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,UMIP,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 4MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus 3 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpiec0 at acpi0 acpi0: GPE 0x26
Re: Switching from trunk(4) to aggr(4)
On Sun, 13 Dec 2020 11:00:32 +0100, livio wrote: > # cat /etc/hostname.aggr0 > trunkport em1 trunkport em2 trunkport em3 lacpmode active lacptimeout > slow description "i_data" > up I just tried adding "lacpmode active lacptimeout slow" in case ifconfig(8) was lying and they were not the default, but it didn't help. > It works well for me and I never had issues. I currently use a HP > switch, but it also works with Cisco. > Maybe some leftovers from the LACP config? I never encountered the > "no carrier status" issue though. What do you mean "some leftovers from the LACP config"? I only removed the trunk0 interface. There isn't anything to change on switch (since it works with trunk(4)), is it? For the record, the switch is a TP-LINK TL-SG3216 Cheers, Daniel
Re: pflogd write /var/run/mypflogdinstance.pid?
On 12/7/20 7:19 PM, Theo de Raadt wrote: Yep. It is possible we need a better strategy --- like placing *all* original argv in the [priv] title. If you change the pflogd command line in the process list, what is supposed to happen to the existing code using pkill or pgrep, expecting the *old* line?
Re: Switching from trunk(4) to aggr(4)
Hey,
My setup at home is almost identical. APU with aggr interface and a couple of
VLANs:
https://github.com/liv-io/ansible-playbooks-example/blob/master/bsd/host_vars/fw01.example.com.yml
# cat /etc/hostname.em{1,2,3}
up
# cat /etc/hostname.aggr0
trunkport em1 trunkport em2 trunkport em3 lacpmode active lacptimeout slow
description "i_data"
up
# cat /etc/hostname.vlan11
inet 10.1.1.2 255.255.255.0 NONE vnetid 11 vlandev aggr0 description "v_base"
up
# cat /etc/hostname.carp11
inet 10.1.1.1 255.255.255.0 NONE vhid 1 carpdev vlan11 advskew 10 pass
"" description "v_base"
# ifconfig aggr0
aggr0: flags=8943 mtu 1500
lladdr
description: i_data
index 11 priority 0 llprio 7
trunk: trunkproto lacp
trunk id: [(8000,,000B,,),
(8000,,0006,,)]
em1 lacp actor system pri 0x8000 mac, key 0xb, port pri 0x8000
number 0x2
em1 lacp actor state
activity,aggregation,sync,collecting,distributing
em1 lacp partner system pri 0x8000 mac, key 0x6, port pri
0x8000 number 0x12e
em1 lacp partner state
activity,aggregation,sync,collecting,distributing
em1 port active,collecting,distributing
em2 lacp actor system pri 0x8000 mac, key 0xb, port pri 0x8000
number 0x3
em2 lacp actor state
activity,aggregation,sync,collecting,distributing
em2 lacp partner system pri 0x8000 mac, key 0x6, port pri
0x8000 number 0x130
em2 lacp partner state
activity,aggregation,sync,collecting,distributing
em2 port active,collecting,distributing
em3 lacp actor system pri 0x8000 mac, key 0xb, port pri 0x8000
number 0x4
em3 lacp actor state
activity,aggregation,sync,collecting,distributing
em3 lacp partner system pri 0x8000 mac, key 0x6, port pri
0x8000 number 0x12f
em3 lacp partner state
activity,aggregation,sync,collecting,distributing
em3 port active,collecting,distributing
groups: aggr
media: Ethernet autoselect
status: active
It works well for me and I never had issues. I currently use a HP switch, but it
also works with Cisco.
Maybe some leftovers from the LACP config? I never encountered the "no carrier
status" issue though.
Let me know if I can extract any config for you.
HTH,
Livio
On 2020-12-12 16:44, Daniel Jakots wrote:
Hi,
I've been using a LACP trunk on my apu (with the three em(4)). On
top of which I have some vlans. I've been doing that for years and it's
working fine.
I thought about using aggr(4) instead (for no real reason). But the
aggr interface stays in "status: no carrier".
What I did is, I replaced my hostname.trunk0
trunkproto lacp trunkport em0 trunkport em1 trunkport em2
up
with a hostname.aggr0
trunkport em0 trunkport em1 trunkport em2
up
(and changing the parent in my hostname.vlan*). To apply the new
configuration, I just reboot.
My trunk0 which works is
trunk0: flags=8843 mtu 1500
lladdr 00:0d:b9:43:9f:fc
index 7 priority 0 llprio 3
trunk: trunkproto lacp
trunk id: [(8000,00:0d:b9:43:9f:fc,403C,,),
(0080,00:00:00:00:00:00,,,)]
em2 lacp actor system pri 0x8000 mac 00:0d:b9:43:9f:fc, key
0x403c, port pri 0x8000 number 0x3
em2 lacp actor state
activity,aggregation,sync,collecting,distributing,defaulted
em2 lacp partner system pri 0x80 mac 00:00:00:00:00:00, key
0x0, port pri 0x80 number 0x0
em2 lacp partner state aggregation,sync,collecting,distributing
em2 port active,collecting,distributing
em1 lacp actor system pri 0x8000 mac 00:0d:b9:43:9f:fc, key
0x403c, port pri 0x8000 number 0x2
em1 lacp actor state
activity,aggregation,sync,collecting,distributing,defaulted
em1 lacp partner system pri 0x80 mac 00:00:00:00:00:00, key
0x0, port pri 0x80 number 0x0
em1 lacp partner state aggregation,sync,collecting,distributing
em1 port active,collecting,distributing
em0 lacp actor system pri 0x8000 mac 00:0d:b9:43:9f:fc, key
0x403c, port pri 0x8000 number 0x1
em0 lacp actor state
activity,aggregation,sync,collecting,distributing,defaulted
em0 lacp partner system pri 0x80 mac 00:00:00:00:00:00, key
0x0, port pri 0x80 number 0x0
em0 lacp partner state aggregation,sync,collecting,distributing
em0 port active,collecting,distributing
groups: trunk
media: Ethernet autoselect
status: active
And the aggr0 which doesn't come up is:
aggr0: flags=8843 mtu 1500
lladdr 00:0d:b9:43:9f:fc
index 6 priority 0 llprio 7
trunk: trunkproto lacp
trunk id: [(8000,00:0d:b9:43:9f:fc,0006,,),
Re: OpenBSD as a NAS
Hello, For your use case make sure from reading softraid it will fit your needs in the first place, perform some tests to make sure softraid meets what you need. Otherwise have a look at hardware raids which OpenBSD supports. As far as NAS for local, yes OpenBSD's perfect for the job, I've used it since many years and still do. Had a few hardware crashes and filesystem rebuild but all in all never had any issue. I prefer the simple volumes, I don't understand RAID so good, as you feel confident with it use it either ways. Initially I had NFS and Samba and FTP, nowadays only Samba and FTP over SSH (I think that's called SFTP). OpenBSD file systems aren't journaled (file system check after a crash). Also check how to perperly tune the filesystems, I think soft updates can be advised. If you need further advises let ask. Jean-François Le 03/12/2020 à 00:19, Ashton Fagg a écrit : Hi all, I'm currently in the process of provisioning a new NAS for home. It's replacing an older Synology unit that ticks me off in so many ways. I am looking to hear other's experiences with using OpenBSD as a NAS - specifically in terms of reliability, and for suggestions on how to provision my storage. I have an LSI card (supported by the drivers in OpenBSD) that is currently flashed to IT mode, but it can of course flashed back to the IR firmware which lets it act as a hardware RAID controller. My needs for the NAS are as follows: NFS and Samba share support, reasonable performance, some amount of tolerance to disk failure, reliable and trustworthy software and file system, ability to closely monitor disk/array health. By extension, it should also be as simple as possible. It might be nice to have it be able to host an iSCSI volume, but that's not essential. I don't care about bleeding edge performance, fancy web UIs or any other "shiny" stuff. By my estimates, OpenBSD with softraid volumes should tick all of those boxes. The box will do nothing else besides be a file server. OpenBSD is my preferred OS nowadays, but I am open to something else if it's the best tool for the job. I guess I'm trying to find out if there's any compelling reason why I *shouldn't* use OpenBSD with softraid. (ZFS also scares me, btw. Maybe unjustifiably so, but it seems very complex and I suspect much of the hype comes down to zealotry and fanboyism.) The questions I have are: a) Is softraid reliable enough to support my use-case? Does anyone have anecdotes to encourage/discourage use of softraid for this application? b) Would I be better off using the LSI RAID controller for the arrays? c) Bearing in mind that the provisioning scheme I have in mind is to provision the disks in pairs (forming RAID1 arrays), thus resulting in 3-4 separate volumes (6-8 disks), is there any reason I should *not* use OpenBSD, and look more toward something like TrueNAS or FreeBSD? (Before anyone mentions it - Yes, I have a proper backup system. I do not rely on the redundancy provided by RAID arrays in lieu of a real backup. I have both a local backup and offsite backup.) Thanks in advance.
