Re: setting up an email server in a recent version of OpenBSD

2021-09-27 Thread Kastus Shchuka
On Mon, Sep 27, 2021 at 08:42:30PM +0300, Teno Deuter wrote:
> Dear group,
> 
> anyone could point to some recent online resources how to setup an email
> server in OpenBSD? What I found from Google was a bit thin. So I'm
> wondering if I was missing something out there.

Did 
https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-with-opensmtpd-dovecot-and-rspamd/
come up in your search?



Re: vi: count occurrences of a substring

2021-09-04 Thread Kastus Shchuka
On Sat, Sep 04, 2021 at 05:00:29PM +0100, ropers wrote:
> However, that's as inaccurate as, or potentially even more inaccurate
> than your version, at least as far as vim-ilarity is concerned.  My
> awk-ward incantation matches vim's :%s/abc//gn precisely.

Not sure if this is less "awk-ward":

:%!perl -0777 -ne 'print s/abc//g;'

and then undo the change to the buffer

- Kastus



Re: snapshot boot fails with error "entry point at 0x1001000"

2020-10-26 Thread Kastus Shchuka
On Sun, Jul 05, 2020 at 09:32:47PM -0700, Kastus Shchuka wrote:
> On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> > Kastus Shchuka  wrote:
> > “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able 
> > to boot it.
> > Boot stops at the line
> > 
> > entry point at 0x1001000
> > 
> > If I try bsd.rd kernel, it boots just fine. After this failure with 
> > snapshot I 
> > installed 6.7-release, and it boots without any issues.”
> > 
> > 
> > I've experienced something similar, including the sensitivity to kernel 
> > size. As best I can observe, the EFI bootloader is being handed a different 
> > block of RAM than where the kernel is actually loaded (which is at a fixed 
> > address defined in boot.c). Which block of memory gets returned, and 
> > whether boot fails, seems to be dependent on the particular UEFI 
> > ROM/chipset. In my case, debugging over serial, I observe a page fault 
> > while the kernel is still being loaded into RAM.
> > “Are there any other solutions than compiling a custom smaller kernel?”
> > 
> > 
> > Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it 
> > for me:
> > --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> > +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> > @@ -303,9 +303,9 @@ efi_memprobe(void)
> > bios_memmap_t   *bm;
> > EFI_STATUS   status;
> > EFI_PHYSICAL_ADDRESS
> > -addr = 0x1000ULL;  /* Below 256MB */
> > +addr = 0x100;
> >  
> > -   status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, 
> > EfiLoaderData,
> > +   status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> > EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> > if (status != EFI_SUCCESS)
> > panic("BS->AllocatePages()");
> > Let me know if that helps. I can't guarantee that this is actually what is 
> > causing your issue but it worked for me.
> 
> I tried this patch and was able to boot kernel from snapshot 2007-07-03 with 
> recompiled BOOTX64.EFI.
> It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.
> 
> I wonder what would it take for the patch to be accepted in -current?
> 
As Mike Larkin pointed in 
https://marc.info/?l=openbsd-misc=160377179930502=2, "mach mem"
output may shed some light on the problem.

So, for the ASRock J4105M motherboard, the output is this:

>> OpenBSD/amd64 BOOTX64 3.50
boot> mach mem
Region 0: type 1 at 0x0 for 248KB
Region 1: type 2 at 0x3e000 for 8KB
Region 2: type 1 at 0x4 for 376KB
Region 3: type 2 at 0x9e000 for 392KB
Region 4: type 1 at 0x10 for 261120KB
Region 5: type 1 at 0x12151000 for 1454584KB
Region 6: type 2 at 0x6adcf000 for 41480KB
Region 7: type 1 at 0x6d651000 for 324KB
Region 8: type 4 at 0x6d6a2000 for 160KB
Region 9: type 2 at 0x6d6ca000 for 3916KB
Region 10: type 1 at 0x6da9d000 for 10388KB
Region 11: type 2 at 0x6e4c2000 for 688KB
Region 12: type 1 at 0x6e56e000 for 6728KB
Region 13: type 1 at 0x1 for 6291456KB
Region 14: type 2 at 0x1000 for 34116KB
Region 15: type 2 at 0x6ec0 for 282624KB
Region 16: type 2 at 0xd000 for 16384KB
Region 17: type 2 at 0xd3709000 for 4KB
Region 18: type 2 at 0xe000 for 262144KB
Region 19: type 2 at 0xfe042000 for 12KB
Region 20: type 2 at 0xfe90 for 12KB
Region 21: type 2 at 0xfec0 for 4KB
Region 22: type 2 at 0xfed01000 for 4KB
Region 23: type 2 at 0xfee0 for 4KB
Region 24: type 2 at 0xff00 for 16384KB
Low ram: 1024KB High ram: 295236KB

With the patch, kernel is loaded in region 14 and it fits there.
Without patch, memory is allocated down from 0x1, and large kernel
overlaps with something and fails to boot.

There were reports on -misc that the patch does not help on some systems.

I wonder what can be tried differently to make it work on all systems?

Thanks,

Kastus



Re: 6.8 release crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)

2020-10-26 Thread Kastus Shchuka
On Mon, Oct 26, 2020 at 07:48:32PM -0700, Alfred Morgan wrote:
> I just wanted to report 6.8 release is having the same issue as
> https://marc.info/?l=openbsd-misc=160224393101534=2
> except I have a CHUWI HeroBox Windows 10 Mini PC,Intel Gemini-Lake N4100
> Quad-Core Processor,8GB DDR4 256GB SSD,Expandable 2TB 2.5 Inch HDD,1TB SSD
> with 2.4GHz/5GHz Dual WiFi 1000Mbps/BT4.2
> https://www.amazon.com/gp/product/B082VZP76P
> 
> On a 6.7 release I did syspatch and then a sysupgrade and got the entry
> point at: 0x1001000 error trying to boot after the upgrade was successful.

6.8 kernel is larger and does not play well with EFI on your system.
Can you try to patch efiboot.c as described in 
https://marc.info/?l=openbsd-misc=159401011632149=2
and see if it works on your system? It did help me on ASRock J4105M,
but there are reports on the list that it does not work on some other
systems, like Lenovo V130.

Thanks,

Kastus



Re: OpenSMTP - Wrong user for Dovecot LMTP

2020-10-18 Thread Kastus Shchuka
On Sun, Oct 18, 2020 at 08:55:16PM -0400, Aisha Tammy wrote:
> Hi,
> 
>  I just upgraded to 6.8 and the upgrade process has been super cool and 
> simple :)
> 
> Unfortunately I seem to have hit some weird issue in OpenSMTPD where it has 
> stopped
> delivering the mail using Dovecots LMTP due to sending as wrong user.
> 
> osmtpd tries to send the mail as *_smtpd* even when configured to send as a
> different user *excision*


Could it be this change: https://marc.info/?t=15878902902=1=2 ?



Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)

2020-10-09 Thread Kastus Shchuka
On Fri, Oct 09, 2020 at 03:37:37PM +0400, Michel von Behr wrote:
> Hi all,
> I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini Lake),
> but I get stuck at boot time with the message "entry point at: 0x1001000".
> Based on previous discussions [1] it looks like the problem is with
> BOOTX64.EFI
> For now I'll be running -stable, but I would like to follow -current. Is
> there a way to run -current with an old version of BOOTX64.EFI for example?
> (i.e., the only alternatives I'm seeing is either 1) compiling a GENERIC
> kernel with the older version of BOOTX64.EFI src, or 2) (try to) compile a
> custom/smaller kernel to avoid the issue).
> 
> [1] https://marc.info/?l=openbsd-misc=159147446008114=2
> 
> Any pointing to the right direction is welcome.

I had the same problem with EFI on ASRock J4105M system, essentially failing 
to boot a kernel larger than certain size. I posted my solution here:

https://marc.info/?l=openbsd-misc=159401011632149=2

I guess the patch requires more testing before asking for it to be
committed.

Thanks,

Kastus



Re: smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT

2020-08-15 Thread Kastus Shchuka
On Sat, Aug 15, 2020 at 07:49:28AM +, Martin wrote:
> It is worth to mention smtpd works absolutely fine for outgoing/incoming mail 
> if local machine has static IP address when:
> ...
> table sources {1.2.3.4} equivalent to
> table helonames {1.2.3.4 = smtp.domain.tld}
> ...
> 
> And yes, I have exactly the same action in /etc/mail/smtpd.conf
> 
> ...
> table sources {127.0.0.1}
> table helonames {1.2.3.4 = smtp.domain.tld}

Your helonames table does not have an entry for 127.0.0.1, that is why it 
cannot find helo string for it.



Re: snapshot boot fails with error "entry point at 0x1001000"

2020-07-05 Thread Kastus Shchuka
On Sat, Jul 04, 2020 at 11:09:54AM +, Michael Baehr wrote:
> Kastus Shchuka  wrote:
> “I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to 
> boot it.
> Boot stops at the line
> 
> entry point at 0x1001000
> 
> If I try bsd.rd kernel, it boots just fine. After this failure with snapshot 
> I 
> installed 6.7-release, and it boots without any issues.”
> 
> 
> I've experienced something similar, including the sensitivity to kernel size. 
> As best I can observe, the EFI bootloader is being handed a different block 
> of RAM than where the kernel is actually loaded (which is at a fixed address 
> defined in boot.c). Which block of memory gets returned, and whether boot 
> fails, seems to be dependent on the particular UEFI ROM/chipset. In my case, 
> debugging over serial, I observe a page fault while the kernel is still being 
> loaded into RAM.
> “Are there any other solutions than compiling a custom smaller kernel?”
> 
> 
> Patching efiboot.c as follows and recompiling bootia32/bootx64 resolved it 
> for me:
> --- a/sys/arch/amd64/stand/efiboot/efiboot.c
> +++ b/sys/arch/amd64/stand/efiboot/efiboot.c
> @@ -303,9 +303,9 @@ efi_memprobe(void)
> bios_memmap_t   *bm;
> EFI_STATUS   status;
> EFI_PHYSICAL_ADDRESS
> -addr = 0x1000ULL;  /* Below 256MB */
> +addr = 0x100;
>  
> -   status = EFI_CALL(BS->AllocatePages, AllocateMaxAddress, 
> EfiLoaderData,
> +   status = EFI_CALL(BS->AllocatePages, AllocateAddress, EfiLoaderData,
> EFI_SIZE_TO_PAGES(KERN_LOADSPACE_SIZE), );
> if (status != EFI_SUCCESS)
> panic("BS->AllocatePages()");
> Let me know if that helps. I can't guarantee that this is actually what is 
> causing your issue but it worked for me.

I tried this patch and was able to boot kernel from snapshot 2007-07-03 with 
recompiled BOOTX64.EFI.
It fixes the problem with EFI memory mapping on ASRock J4105M motherboard.

I wonder what would it take for the patch to be accepted in -current?

Thanks,

Kastus



snapshot boot fails with error "entry point at 0x1001000"

2020-07-03 Thread Kastus Shchuka
Hi,

I installed 2020-07-03 snapshot on ASRock J4105M system and I am not able to 
boot it.
Boot stops at the line

entry point at 0x1001000

If I try bsd.rd kernel, it boots just fine. After this failure with snapshot I 
installed 6.7-release, and it boots without any issues.

I suspect I am hitting the same problem as in 
https://marc.info/?l=openbsd-misc=159325874410286=2.

Disk is partitioned with GPT, and system boots through EFI.

There were other reports about BOOTX86.EFI supposedely causing this problem,
as in https://marc.info/?l=openbsd-misc=159147446008114=2.

I tried to boot snapshot kernel on 6.7-release system to make use of older 
BOOTX86.EFI, 
but it stopped at the same line "entry point at 0x1001000"

I could be wrong, but I doubt that efi is the problem. It seems that kernel 
size is.

If kernel is smaller than 20MB, it boots. If it is larger, it doesn't.

Are there any other solutions than compiling a custom smaller kernel?

I cannot produce dmesg from snapshot, but here is dmesg from 6.7-release:

OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun  4 09:55:08 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8201129984 (7821MB)
avail mem = 7939952640 (7572MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x6d946000 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 05/04/2018
bios0: ASRock J4105M
acpi0 at bios0: ACPI 6.1
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT SSDT SSDT 
SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BGRT WDAT WSMT
acpi0: wakeup devices SIO1(S3) PS2K(S4) PS2M(S4) UAR1(S4) UAR2(S4) HDAS(S3) 
XHC_(S4) XDCI(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP04(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) J4105 CPU @ 1.50GHz, 1496.53 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) J4105 CPU @ 1.50GHz, 1495.86 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) J4105 CPU @ 1.50GHz, 1495.87 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) J4105 CPU @ 1.50GHz, 1495.86 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 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpipwrres0 at acpi0: DRST