Historical Releases on CD for Donation
Hello: I have a small collection of old OpenBSD releases on CD that I am looking to donate: 2.8 - 2 CD's in original case with pullout instruction book 2.9 - 2 CD's in original case with pullout instruction book 3.0 - 3 CD's in original case with pullout instruction book and 9 out of 10 artwork stickers 3.1 - 3 CD's in original case with pullout instruction book 3.2 - 3 CD's in original case with pullout instruction book and 12 out of 12 artwork stickers 3.3 - 3 CD's in original case with pullout instruction book 3.4 - 3 CD's in original case with pullout instruction book 3.5 - 3 CD's in original case with pullout instruction book I'm open to suggestions as to who to give them to. Does there exist anywhere some public archive or computer museum where they would fit in? Barring that, is there anyone with a similar collection that's lacking these releases? Or perhaps someone who has made significant contributions to OpenBSD and would like them for sentimental reasons? I would like to see them go to some better use than (literally) gathering dust on my bookshelf. Appreciatively, Richard Koett.
apm(4) ioctls
On amd64 and aarch64 (the two architectures I have access to to check), the man page for apm(4) documents APM_IOC_NEXTEVENT, which doesn't appear in . (grep tells me that it also appears in the man pages for i386 and macppc and does not appear in any src/sys/arch/*/include/apmvar.h.) It looks like apmd uses kqueue to get this information; that interface doesn't appear in any documentation I've found. Am I looking in the wrong places, or is the documentation wrong here? Is the way apmd does it meant to be a supported interface? Thanks, dave -- Dave Vandervies dj3va...@terse.ca Plan your future! Make God laugh!
Re: M2 disk slowing down on sequential reads
> could be thermals. Or it could be some kind of cache total miss. I find it strange to overheat a storage after 4GB of transfers. Just saying. Thank you.
Re: M2 disk slowing down on sequential reads
On Jun 13 09:53:46, mlar...@nested.page wrote: > could be thermals. Try a better heat sink/fan on the drive then try again? Thanks for the hint. Indeed, the disk is hot; currently it only has a slab of heat paste on it.
Re: M2 disk slowing down on sequential reads
On Mon, Jun 13, 2022 at 06:01:39PM +0200, Jan Stary wrote: > This is current/amd64 on a PC (dmesg below). > It is using this M2 SSD as a system disk: > > sd0 at scsibus1 targ 0 lun 0: > naa.5001b448b8532530 > sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin > > I do a weekly dd read of all disks as a precaution > to see if any of the report any errors, as in > dd bs=1m conv=noerror if=/dev/rsd0c of=/dev/null > > This particular disk seems to be very fast when reading > up to something between 3GB and 4GB; then the speed drops: > > dd bs=1m count=1k conv=noerror if=/dev/rsd0c of=/dev/null > 1073741824 bytes transferred in 5.404 secs (198679263 bytes/sec) > 1073741824 bytes transferred in 5.271 secs (203672530 bytes/sec) > 1073741824 bytes transferred in 5.072 secs (211697503 bytes/sec) > > dd bs=1m count=2k conv=noerror if=/dev/rsd0c of=/dev/null > 2147483648 bytes transferred in 8.392 secs (255879364 bytes/sec) > 2147483648 bytes transferred in 8.413 secs (255242225 bytes/sec) > 2147483648 bytes transferred in 9.139 secs (234968292 bytes/sec) > > dd bs=1m count=3k conv=noerror if=/dev/rsd0c of=/dev/null > 3221225472 bytes transferred in 11.823 secs (272447923 bytes/sec) > 3221225472 bytes transferred in 12.124 secs (265674803 bytes/sec) > > dd bs=1m count=4k conv=noerror if=/dev/rsd0c of=/dev/null > 4294967296 bytes transferred in 53.442 secs (80365818 bytes/sec) > 4294967296 bytes transferred in 52.680 secs (81528574 bytes/sec) > 4294967296 bytes transferred in 52.082 secs (82465212 bytes/sec) > > dd bs=1m count=5k conv=noerror if=/dev/rsd0c of=/dev/null > 5368709120 bytes transferred in 179.967 secs (29831567 bytes/sec) > 5368709120 bytes transferred in 221.400 secs (24248900 bytes/sec) > 5368709120 bytes transferred in 215.760 secs (24882667 bytes/sec) > > That's a drop from 200MB/s to 20MB/s. > I get a similar rate of slowdown with different dd bs. > > Is this expected when doing a long sequential read of this kind of disks? > could be thermals. Try a better heat sink/fan on the drive then try again? > (The rotating disks also slow down when doing a long read, > but only marginaly: a dd read of the whole disk is not > that much slower than a read of the first 10GB.) > > Jan > > > > OpenBSD 7.1-current (GENERIC.MP) #0: Thu Apr 14 13:26:20 CEST 2022 > h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17009606656 (16221MB) > avail mem = 16476803072 (15713MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) > bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 > bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT > acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) > PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf400, bus 0-63 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.60 MHz, 06-2a-07 > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-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 99MHz > 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-2600 CPU @ 3.40GHz, 3492.10 MHz, 06-2a-07 > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > 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-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07 > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu2: 256KB 64b/line 8-way L2 cache > cpu2: smt 0, core 2, package
M2 disk slowing down on sequential reads
This is current/amd64 on a PC (dmesg below). It is using this M2 SSD as a system disk: sd0 at scsibus1 targ 0 lun 0: naa.5001b448b8532530 sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin I do a weekly dd read of all disks as a precaution to see if any of the report any errors, as in dd bs=1m conv=noerror if=/dev/rsd0c of=/dev/null This particular disk seems to be very fast when reading up to something between 3GB and 4GB; then the speed drops: dd bs=1m count=1k conv=noerror if=/dev/rsd0c of=/dev/null 1073741824 bytes transferred in 5.404 secs (198679263 bytes/sec) 1073741824 bytes transferred in 5.271 secs (203672530 bytes/sec) 1073741824 bytes transferred in 5.072 secs (211697503 bytes/sec) dd bs=1m count=2k conv=noerror if=/dev/rsd0c of=/dev/null 2147483648 bytes transferred in 8.392 secs (255879364 bytes/sec) 2147483648 bytes transferred in 8.413 secs (255242225 bytes/sec) 2147483648 bytes transferred in 9.139 secs (234968292 bytes/sec) dd bs=1m count=3k conv=noerror if=/dev/rsd0c of=/dev/null 3221225472 bytes transferred in 11.823 secs (272447923 bytes/sec) 3221225472 bytes transferred in 12.124 secs (265674803 bytes/sec) dd bs=1m count=4k conv=noerror if=/dev/rsd0c of=/dev/null 4294967296 bytes transferred in 53.442 secs (80365818 bytes/sec) 4294967296 bytes transferred in 52.680 secs (81528574 bytes/sec) 4294967296 bytes transferred in 52.082 secs (82465212 bytes/sec) dd bs=1m count=5k conv=noerror if=/dev/rsd0c of=/dev/null 5368709120 bytes transferred in 179.967 secs (29831567 bytes/sec) 5368709120 bytes transferred in 221.400 secs (24248900 bytes/sec) 5368709120 bytes transferred in 215.760 secs (24882667 bytes/sec) That's a drop from 200MB/s to 20MB/s. I get a similar rate of slowdown with different dd bs. Is this expected when doing a long sequential read of this kind of disks? (The rotating disks also slow down when doing a long read, but only marginaly: a dd read of the whole disk is not that much slower than a read of the first 10GB.) Jan OpenBSD 7.1-current (GENERIC.MP) #0: Thu Apr 14 13:26:20 CEST 2022 h...@box.stare.cz:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17009606656 (16221MB) avail mem = 16476803072 (15713MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F3" date 03/31/2011 bios0: Gigabyte Technology Co., Ltd. H67MA-USB3-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, 3492.60 MHz, 06-2a-07 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-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 99MHz 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-2600 CPU @ 3.40GHz, 3492.10 MHz, 06-2a-07 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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-2600 CPU @ 3.40GHz, 3492.09 MHz, 06-2a-07 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,SMX,EST,TM2,SSSE3,CX16,x
Re: How to compact partitions (disklabel)?
> Am 13.06.2022 um 10:21 schrieb Stuart Henderson : > > On 2022-06-13, Mike Fischer wrote: >> After solving a recent problem on a VM where the /usr/local was full I was >> left with a disklabel that had a hole of unused space in it (see below for >> details). I was wondering if there is a way to compact the partitions, i.e. >> move the partitions following the deleted one up to fill the hole, >> potentially leaving corresponding free space at the end. >> >> I’d prefer to not have to use dd(1) on the raw device to move the data? I’d >> hope for something that is smart enough to adjust the disklabel after moving >> the bytes. Wishful thinking? > > There's no good way to do this. My preference would be to attach a new > virtual disk, partition either manually or according to current auto > defaults for the larger disk, dump|restore and run installboot, then > remove the old virtual disk. Ok, thanks! I thought I missed something ;-) > >> 16 partitions: >> #size offset fstype [fsize bsize cpg] >> f: 5056800 8025952 4.2BSD 2048 16384 12960 # /usr > > You might find this a little tight too after some updates. # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 615M108M476M18%/ /dev/sd0k 3.7G798M2.7G22%/home /dev/sd0d 863M8.0K820M 0%/tmp /dev/sd0f 2.3G1.7G555M76%/usr /dev/sd0g 648M299M317M48%/usr/X11R6 /dev/sd0l 4.8G2.2G2.4G48%/usr/local /dev/sd0j 5.2G2.0K4.9G 0%/usr/obj /dev/sd0i 1.4G968M402M71%/usr/src /dev/sd0e 1.3G425M806M35%/var # 24% (555M) free seems ok for now, but thanks for the heads-up. Mike
Re: iwn0: fatal firmware error after sysupgrade to 7.1
On Mon, Jun 13, 2022 at 02:45:23AM +0200, Christian Schulte wrote: > > > On 12.06.22 13:22, Stefan Sperling wrote: > > On Sun, Jun 12, 2022 at 01:16:00PM +0200, Stefan Sperling wrote: > > > On Sun, Jun 12, 2022 at 10:28:33AM +0200, Christian Schulte wrote: > > > > Please see attached dmesg and pcidump. There has been a similar issue > > > > with > > > > the if_iwm.c driver. Maybe this one is related. > > > > > > These are seperate drivers so it is unlikely that these issues would > > > be related. > > > > > > How many different access points have you tried to reproduce the > > > problem with so far? > > Two. The router and a repeater bridging the WLAN of that router. There are 3 > more repeaters I could test this with. Cannot be related to those. No issues > with 7.0. > I don't yet quite understand where the problem is. I will need to see a beacon from an AP which triggers the problem in order to decide what we should try next. Can you please collect a fresh debug log again in the same way, and run this command at the same time to record beacons: tcpdump -n -i iwn0 -y IEEE802_11_RADIO -D in -s 4096 -w /tmp/iwn.pcap type mgt subtype beacon Once the fw error has happened you can Ctrl-C tcpdump and send me your new debug log and the pcap file which should now be stored at /tmp/iwn.pcap. Hopefully we can make progress then. Thanks!
Re: How to compact partitions (disklabel)?
On 2022-06-13, Mike Fischer wrote: > After solving a recent problem on a VM where the /usr/local was full I was > left with a disklabel that had a hole of unused space in it (see below for > details). I was wondering if there is a way to compact the partitions, i.e. > move the partitions following the deleted one up to fill the hole, > potentially leaving corresponding free space at the end. > > I’d prefer to not have to use dd(1) on the raw device to move the data? I’d > hope for something that is smart enough to adjust the disklabel after moving > the bytes. Wishful thinking? There's no good way to do this. My preference would be to attach a new virtual disk, partition either manually or according to current auto defaults for the larger disk, dump|restore and run installboot, then remove the old virtual disk. > 16 partitions: > #size offset fstype [fsize bsize cpg] > f: 5056800 8025952 4.2BSD 2048 16384 12960 # /usr You might find this a little tight too after some updates. -- Please keep replies on the mailing list.
Re: smtpd + dkimsign 7.0 upgraded to 7.1
Nothing stands out to me. Your maillog should contain more details on what goes wrong. martijn@ On Mon, 2022-06-13 at 00:15 -0700, latin...@vcn.bc.ca wrote: > Hello > > My mail server stop working after upgrade to 7.1; could somebody please > check the conf? > > # $OpenBSD: smtpd.conf,v 1.14 2019/11/26 20:14:38 gilles Exp $ > > # This is the smtpd server system-wide configuration file. > # See smtpd.conf(5) for more information. > > table aliases file:/etc/mail/aliases > > filter "dkimsign" proc-exec "filter-dkimsign -d agroena.org -s s1 -k > /etc/mail/dkim/agroena.org.private.key" user _dkimsign group _dkimsign > > # To accept external mail, replace with: listen on all > # > listen on socket filter "dkimsign" > listen on lo0 filter "dkimsign" > > action "local_mail" mbox alias > action "outbound" relay > > # Uncomment the following to accept external mail for domain "example.org" > # > # match from any for domain "example.org" action "local_mail" > match from any for domain "agroena.org" action "local_mail" > match for local action "local_mail" > match for any action "outbound" > > Thanks so much. > > > >
How to compact partitions (disklabel)?
Hi! After solving a recent problem on a VM where the /usr/local was full I was left with a disklabel that had a hole of unused space in it (see below for details). I was wondering if there is a way to compact the partitions, i.e. move the partitions following the deleted one up to fill the hole, potentially leaving corresponding free space at the end. I’d prefer to not have to use dd(1) on the raw device to move the data? I’d hope for something that is smart enough to adjust the disklabel after moving the bytes. Wishful thinking? Details: Partition sd0h, ≈2.42 GB in size, containing /usr/local was full on a 20 GB virtual disk in VMWare Fusion, used for OpenBSD 7.1 stable, amd64. The partitions where originally created using the defaults in OpenBSD 6.8 IIRC. I enlarged the virtual disk in VMWare by 5 GB to 25 GB and then in single user mode I added a new sd0l partition using disklabel(8), created a file system on it, mounted the new file system and used dump(8)/restore(8) to copy the data. Then I modified /etc/fstab to use sd0l instead of sd0h and rebooted. Lastly I used disklabel(8) to delete sd0h. This left the aforementioned hole of unused data on disk. (For completeness sake I also adjusted the MBR using fdisk(8) to make the OpenBSD partition reflect the new size. But I’m not sure if that was even required. Seemed to work fine without that change.) The current disklabel looks like this: # disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: VMware Virtual S duid: e592eaa53f566380 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 2610 total sectors: 52428800 boundstart: 64 boundend: 52428800 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 1299584 64 4.2BSD 2048 16384 10153 # / b: 2148640 1299648swap# none c: 524288000 unused d: 1833600 3448288 4.2BSD 2048 16384 12960 # /tmp e: 2744064 5281888 4.2BSD 2048 16384 12960 # /var f: 5056800 8025952 4.2BSD 2048 16384 12960 # /usr g: 1381856 13082752 4.2BSD 2048 16384 10710 # /usr/X11R6 i: 3059360 19538944 4.2BSD 2048 16384 12960 # /usr/src j: 11279680 22598304 4.2BSD 2048 16384 12960 # /usr/obj k: 8051648 33877984 4.2BSD 2048 16384 12960 # /home l: 10499168 41929632 4.2BSD 2048 16384 12960 # /usr/local # So partitions i through l would need to move. Thanks! Mike
smtpd + dkimsign 7.0 upgraded to 7.1
Hello My mail server stop working after upgrade to 7.1; could somebody please check the conf? # $OpenBSD: smtpd.conf,v 1.14 2019/11/26 20:14:38 gilles Exp $ # This is the smtpd server system-wide configuration file. # See smtpd.conf(5) for more information. table aliases file:/etc/mail/aliases filter "dkimsign" proc-exec "filter-dkimsign -d agroena.org -s s1 -k /etc/mail/dkim/agroena.org.private.key" user _dkimsign group _dkimsign # To accept external mail, replace with: listen on all # listen on socket filter "dkimsign" listen on lo0 filter "dkimsign" action "local_mail" mbox alias action "outbound" relay # Uncomment the following to accept external mail for domain "example.org" # # match from any for domain "example.org" action "local_mail" match from any for domain "agroena.org" action "local_mail" match for local action "local_mail" match for any action "outbound" Thanks so much.
