Re: Relinking unique kernel failed after syspatch

[Leo Unglaub]

Hey,

On 03/20/18 05:43, Predrag Punosevac wrote:

1095 KB00:00 Installing patch 010_ahauth
Relinking to create unique kernel... failed!

I looked into /usr/share/compile/GENERIC.MP/relink.log but the only
thing in there is:


(SHA256) /bsd: FAILED


https://marc.info/?l=openbsd-misc=151245106222333=2
thank you for the link. I am not sure it fits my case because i did not 
modify the kernel myself. This server is as unmodified as it gets, there 
are no packages installed, no binaries changed, ... . The only thing i 
modified on that server is /etc/ntpd.conf.


Thanks anyway and greetings
Leo

Re: Relinking unique kernel failed after syspatch

[Predrag Punosevac]

Leo Unglaub wrote:

> Hello,
> today I wanted to apply the latest patches on our servers. They all 
> worked fine, only on one server where i was missing some previous 
> patches as well it got an error from syspatch.
> 
> > # syspatch
>
> > Get/Verify syspatch62-005_ahopts.tgz 100% \
> >
> |**|
> \
> > 703 KB00:00 Installing patch 005_ahopts
> > Get/Verify syspatch62-006_prevhdr... 100% \
> >
> |**|
> \
> > 783 KB00:00 Installing patch 006_prevhdr
> > Get/Verify syspatch62-007_etherip... 100% \
> >
> |**|
> \
> > 1030 KB00:00 Installing patch 007_etherip
> > Get/Verify syspatch62-008_unbound... 100% \
> >
> |**|
> \
> > 1294 KB00:00 Installing patch 008_unbound
> > Get/Verify syspatch62-009_meltdow... 100% \
> >
> |**|
> \
> > 40344 KB00:13 Installing patch 009_meltdown
> > Get/Verify syspatch62-010_ahauth.tgz 100% \
> >
> |**|
> \
> > 1095 KB00:00 Installing patch 010_ahauth
> > Relinking to create unique kernel... failed!
> 
> I looked into /usr/share/compile/GENERIC.MP/relink.log but the only 
> thing in there is:
> 
> > (SHA256) /bsd: FAILED
> 


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

Relinking unique kernel failed after syspatch

[Leo Unglaub]

Hello,
today I wanted to apply the latest patches on our servers. They all 
worked fine, only on one server where i was missing some previous 
patches as well it got an error from syspatch.


# syspatch 
Get/Verify syspatch62-005_ahopts.tgz 100% |**|   703 KB00:00
Installing patch 005_ahopts
Get/Verify syspatch62-006_prevhdr... 100% |**|   783 KB00:00
Installing patch 006_prevhdr
Get/Verify syspatch62-007_etherip... 100% |**|  1030 KB00:00
Installing patch 007_etherip
Get/Verify syspatch62-008_unbound... 100% |**|  1294 KB00:00
Installing patch 008_unbound
Get/Verify syspatch62-009_meltdow... 100% |**| 40344 KB00:13
Installing patch 009_meltdown
Get/Verify syspatch62-010_ahauth.tgz 100% |**|  1095 KB00:00
Installing patch 010_ahauth

Relinking to create unique kernel... failed!


I looked into /usr/share/compile/GENERIC.MP/relink.log but the only 
thing in there is:



(SHA256) /bsd: FAILED


I have not rebooted the server in case there is some additional 
information I need to provide in order to fix this. (Is there even 
something to fix? Or is there already an improvement for this in 6.3)?


Is it safe for me to reboot this server or do I have something else i 
need todo before rebooting the server?


Here is a full dmesg from that machine:


OpenBSD 6.2 (GENERIC.MP) #2: Sun Dec 10 21:14:42 CET 2017

r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 6843424 (65294MB)
avail mem = 66384637952 (63309MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcbe08000 (78 entries)
bios0: vendor FUJITSU // American Megatrends Inc. version "V5.0.0.11 R1.21.0 for 
D3401-H1x" date 05/15/2017
bios0: FUJITSU D3401-H1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT SSDT 
SSDT DBGP DBG2 SSDT UEFI SSDT DMAR ASF!
acpi0: wakeup devices PEGP(S4) PEG0(S4) PS2K(S3) PS2M(S3) PXSX(S4) RP09(S4) 
PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) 
PXSX(S4) RP01(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408.00 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 340800 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3408.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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
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-6700 CPU @ 3.40GHz, 3408.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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
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-6700 CPU @ 3.40GHz, 3408.00 MHz
cpu3: 

What's the inc. SSH conn. launch seq., rel. to login.conf rlimit enforcement?

[Tinker]

Hi,

When connecting to SSHD and authenticating as a user, in what sequence
are various processes launched (shell / shell with "-l" argument / sshd
child / login(1)), and in particular, at what stage are login.conf
settings enforced into the process context by login(1)?

I would guess this is what's described by the "LOGIN PROCESS" section
in the sshd(8) man page:

 * A child SSHD process is spawned already at connect time, meaning
   prior to step 1,

 * Steps 1 up to 4 are run as root by the sshd child,

 * login(1) is execve:ed at step "4. Changes to run with normal user
   privileges.", and it will
* enforce login.conf settings in the process context (rlimits,
  umask, etc.) while still root,
* change user, and
* execve /bin/sh (or sshd??) to perform the remaining steps (5-9)

 * The user's shell (without "-l") is execve:ed in step 9.

http://man.openbsd.org/sshd.8#LOGIN_PROCESS
http://man.openbsd.org/login.conf.5

Also I'd guess it should be a similar process for SFTP, telnet, and
other authenticated services.

Is this any correctly understood?

Tinker

Re: ipv6 nd

[Max Parmer]

On Tue, Mar 20, 2018 at 12:19:09AM +, Peter van Oord van der Vlies wrote:
> 
> 
> > Is slaacd or a dhcpv6 client running?
> 
> Yes i tried with slaacd

Does `slaacctl show interface $if` reflect that a router advertisement
has been received?

-- 
0x7D964D3361142ACF

Re: ipv6 nd

[Peter van Oord van der Vlies]

> Is slaacd or a dhcpv6 client running?

Yes i tried with slaacd

> --
> 0x7D964D3361142ACF

On Mon, Mar 19, 2018, at 16:27, Peter van Oord van der Vlies wrote:
> Hello Misc,
>
>
> Today i replaced my cisco 881 because it wasn't able to handle the
> bandwidth anymore.
>
>
> I had a working ipv6 setup for years with the following relevant part
> from my cisco wan interface
>
> config part:
>
>   ipv6 address autoconfig
>
>   ipv6 enable
>
>   ipv6 nd ra interval 30
>
>   ipv6 dhcp client pd my_prefix rapid-commit
>
> On my obsd wan interface i did ifconfig pppoe0 inet6 autoconf but i am not
> getting any global address.
>
> Anyone here that can set me into the right direction ?
>
> Thanks!
>
> Peter
>
>

Re: ipv6 nd

[Max R.D. Parmer]

Is slaacd or a dhcpv6 client running?

--
0x7D964D3361142ACF

On Mon, Mar 19, 2018, at 16:27, Peter van Oord van der Vlies wrote:
> Hello Misc,
> 
> 
> Today i replaced my cisco 881 because it wasn't able to handle the 
> bandwidth anymore.
> 
> 
> I had a working ipv6 setup for years with the following relevant part 
> from my cisco wan interface
> 
> config part:
> 
>   ipv6 address autoconfig
> 
>   ipv6 enable
> 
>   ipv6 nd ra interval 30
> 
>   ipv6 dhcp client pd my_prefix rapid-commit
> 
> On my obsd wan interface i did ifconfig pppoe0 inet6 autoconf but i am not
> getting any global address.
> 
> Anyone here that can set me into the right direction ?
> 
> Thanks!
> 
> Peter
> 
> 

ipv6 nd

[Peter van Oord van der Vlies]

Hello Misc,


Today i replaced my cisco 881 because it wasn't able to handle the bandwidth 
anymore.


I had a working ipv6 setup for years with the following relevant part from my 
cisco wan interface

config part:

  ipv6 address autoconfig

  ipv6 enable

  ipv6 nd ra interval 30

  ipv6 dhcp client pd my_prefix rapid-commit

On my obsd wan interface i did ifconfig pppoe0 inet6 autoconf but i am not
getting any global address.

Anyone here that can set me into the right direction ?

Thanks!

Peter

Re: minor too small - pkg_add

[Patrick Marchand]

> You updated from a base snapshot that had libssl.so.44.8 to one that
> has 45.0, but skipped the intervening 44.9 one.  Unfortunately, the
> package snapshot had been built against 44.9.
> 
> > a similar issue with libm. Now I can get around the error by building
> > the packages in ports, but I was wondering if there was an easy fix.
> 
> Wait a few hours until the next packages, built against 45.0, hit
> the mirrors.
> 

Oh that makes a lot more sense, I'll check it out when I get back from
work. 
Thanks 

Re: the Alpha lives...

[Paul de Weerd]

last update .. Theo has built a new snapshot which I installed on the
alpha.  It works well, and after booting into it the nsd configure run
works just fine.

So, thanks to Theo for the latest snap :)

Cheers,

Paul 'WEiRD' de Weerd

[ using 1135448 bytes of bsd ELF symbol table ]
consinit: not using prom console
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.3 (GENERIC) #0: Sun Mar 18 18:43:53 MDT 2018
dera...@alpha.openbsd.org:/usr/src/sys/arch/alpha/compile/GENERIC
Digital Personal WorkStation 600au, 598MHz
8192 byte page size, 1 processor.
real mem = 536870912 (512MB)
rsvd mem = 1941504 (1MB)
avail mem = 515727360 (491MB)
mainbus0 at root
cpu0 at mainbus0: ID 0 (primary), 21164A-0 (unknown minor type 0)
cpu0: architecture extensions: 1
cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 1
cia0: extended capabilities: 1
cia0: using BWX for PCI config and bus access
cia0: WARNING: Pyxis pass 1 DMA bug; no bets...
pci0 at cia0 bus 0
dc0 at pci0 dev 3 function 0 "DEC 21142/3" rev 0x30: dec 550 irq 0, address 
00:00:f8:76:04:64
nsphy0 at dc0 phy 5: DP83840 10/100 PHY, rev. 1
pciide0 at pci0 dev 4 function 0 "CMD Technology PCI0646" rev 0x01: DMA, 
channel 0 wired to compatibility, channel 1 wired to compatibility
atapiscsi0 at pciide0 channel 0 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom 
removable
cd0(pciide0:0:0): using PIO mode 3, DMA mode 1
pciide0: channel 1 disabled (no drives)
sio0 at pci0 dev 7 function 0 "Intel 82378IB ISA" rev 0x43
qlw0 at pci0 dev 12 function 0 "QLogic ISP1020" rev 0x05: dec 550 irq 8
qlw0: firmware rev 4.66.0, attrs 0x0
scsibus1 at qlw0: 16 targets, initiator 7
sd0 at scsibus1 targ 8 lun 0:  SCSI2 0/direct fixed 
serial.SEAGATE_ST34371W_JDD273270M5E3P
sd0: 4148MB, 512 bytes/sector, 8496884 sectors
sd1 at scsibus1 targ 9 lun 0:  SCSI2 0/direct fixed 
serial.IBM_DCAS-34330W_F3TD8398_
sd1: 4134MB, 512 bytes/sector, 8467200 sectors
sd2 at scsibus1 targ 10 lun 0:  SCSI2 0/direct fixed 
serial.IBM_DCAS-34330W_F3TE2118_
sd2: 4134MB, 512 bytes/sector, 8467200 sectors
ppb0 at pci0 dev 20 function 0 "DEC 21152" rev 0x02
pci1 at ppb0 bus 1
fxp0 at pci1 dev 8 function 0 "Intel 8255x" rev 0x0c, i82550: dec 550 irq 12, 
address 00:02:b3:61:21:e3
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci1 dev 9 function 0 "Intel 8255x" rev 0x08, i82559: dec 550 irq 16, 
address 00:02:b3:21:cd:c2
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
vga0 at pci1 dev 10 function 0 "Matrox MGA 1064SG 220MHz" rev 0x02
wsdisplay0 at vga0 mux 1
wsdisplay0: screen 0-5 added (80x25, vt100 emulation)
isa0 at sio0
isadma0 at isa0
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
lpt0 at isa0 port 0x3bc/4 irq 7
mcclock0 at isa0 port 0x70/2: mc146818 or compatible
stray isa irq 14
stray isa irq 3
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (92145ab06ead027c.a) swap on sd0b dump on sd0b
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
stray isa irq 3


-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: minor too small - pkg_add

[Christian Weisgerber]

Patrick Marchand:

> I updated to the latest snapshot yesterday and when I run 
> pkg_add -Dsnap -u a bunch of pkg will not upgrade because it cant find
> ssl.44.9
> 
> It does find 44.8 and 45 but not that specific version, last week I had

You updated from a base snapshot that had libssl.so.44.8 to one that
has 45.0, but skipped the intervening 44.9 one.  Unfortunately, the
package snapshot had been built against 44.9.

> a similar issue with libm. Now I can get around the error by building
> the packages in ports, but I was wondering if there was an easy fix.

Wait a few hours until the next packages, built against 45.0, hit
the mirrors.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: OpenSMTPd maillist "compatible" manager Majordomo or what?

[Kevin Chadwick]

On Mon, 19 Mar 2018 18:59:45 +0300


> I have Sendmail + Majordomo setup which works for seven years
> excellent. Now I'm trying to update that setup to OpenSMTP with
> keeping Majordomo functionality for mail list management.
> 
> What do "the best" software to work with OpenSMTP? Any suggestions
> will be helpful.
> 
> Denis
> 
>  
> 

I like http://ports.su/mail/mlmmj

Re: acpidump and bsd.rd

[Theo de Raadt]

No.

bsd.rd is for installation.  It is not a diagnostic tool.

There are other ways to do diagnostics.


> does it make sense to add acpidump to bsd.rd ?
> I've tried to install snapshot on Dell R640 and installation went well
> but booting stops with this error:
> http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-01.jpg
> 
> i also noticed this ahci2 log while booting
> http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-02.jpg
> 
> So I thought to make release and to add acpidump and maybe pcidump in
> bsd.rd. Or maybe to collect acpi stuff from linux?
> 
> 

acpidump and bsd.rd

[Hrvoje Popovski]

Hi all,

does it make sense to add acpidump to bsd.rd ?
I've tried to install snapshot on Dell R640 and installation went well
but booting stops with this error:
http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-01.jpg

i also noticed this ahci2 log while booting
http://kosjenka.srce.hr/~hrvoje/zaprocvat/r640-02.jpg

So I thought to make release and to add acpidump and maybe pcidump in
bsd.rd. Or maybe to collect acpi stuff from linux?

OpenSMTPd maillist "compatible" manager Majordomo or what?

[Denis]

I have Sendmail + Majordomo setup which works for seven years excellent.
Now I'm trying to update that setup to OpenSMTP with keeping Majordomo
functionality for mail list management.

What do "the best" software to work with OpenSMTP? Any suggestions will
be helpful.

Denis

 

Re: minor too small - pkg_add

[Patrick Marchand]

> It seems you have to update your snapshot because it's too old. It was
> shipped with the lib version 44.8 and the current is now 44.9 from the
> output. That mean your snapshot is too old and the packages have been built
> against a more recent snapshot.
> 
> Regards
Hhmm I guess it's possible that the snapshot was updated at the same
time I was installing the last snapshot. I'll try updating again and
will report back.

Re: minor too small - pkg_add

[Solène Rapenne]

Le 2018-03-19 16:18, Patrick Marchand a écrit :

Hello,
I updated to the latest snapshot yesterday and when I run
pkg_add -Dsnap -u a bunch of pkg will not upgrade because it cant find
ssl.44.9

It does find 44.8 and 45 but not that specific version, last week I had
a similar issue with libm. Now I can get around the error by building
the packages in ports, but I was wondering if there was an easy fix.

Thanks,
Patrick


Hello,

It seems you have to update your snapshot because it's too old. It was
shipped with the lib version 44.8 and the current is now 44.9 from the
output. That mean your snapshot is too old and the packages have been 
built

against a more recent snapshot.

Regards

minor too small - pkg_add

[Patrick Marchand]

Hello,
I updated to the latest snapshot yesterday and when I run 
pkg_add -Dsnap -u a bunch of pkg will not upgrade because it cant find
ssl.44.9

It does find 44.8 and 45 but not that specific version, last week I had
a similar issue with libm. Now I can get around the error by building
the packages in ports, but I was wondering if there was an easy fix.

Thanks,
Patrick

Re: last snapshot points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/

[Sven Wolf]

Hi Peter,

thanks for your information.

Everything is fine now :)

Thanks,
Sven


On 03/19/18 12:43, Peter N. M. Hansteen wrote:

On Mon, Mar 19, 2018 at 12:34:43PM +0100, Sven Wolf wrote:

I've updated my system to the latest amd64 snapshot. When I run a system
updade from bsd.rd and pkg_add then it points to /pub/OpenBSD/6.3/ instead
to /pub/OpenBSD/snapshots/.

The problem occurs in my opinion since last friday. Is there something which
I can fix on my machine? Or is this an error from kernel?

Not the kernel, but the snapshot is close enough to release that this is 
expected
behavior. for a little while now, you will need to prepend -D snap to your other
pkg_add options if you're running a snapshot. It's in the pkg_add man page, but
easy to miss I guess.

- Peter

Re: relayd clients on same network with servers

[Kapetanakis Giannis]

On 19/03/18 13:51, Mischa wrote:
> Hi Giannis,
> 
> From my experience dealing with a lot of load balancers in my time, and also 
> working for different vendors, the easiest is to use source-nat.
> This is just configuration on the relayd itself without making "major" 
> changes in the rest of the network or servers. Which you would need to do to 
> when choosing different VLANs or DSR.
> 
> Your concern about source-net and hiding the client IP is valid, but easily 
> fixed with Client-IP header in http, if http is the protocol, otherwise you 
> will loose the client IP. ;)
> One more thing to remember with source-nat is the maximum amount of 
> concurrent connections you can handle in a single IP, if that is below 64k 
> you are fine, otherwise you will have to create a pool of IPs to source-nat 
> from.
> 
> In my opinion DSR is only relevant for services like FTP and NNTP, where you 
> have a lot more traffic going out than coming in, so you don't have to put 
> that burden through the single load balancer interface.
> 
> If you have the ability to change the VLANs that of course the cleanest of 
> all the option and source-nat the dirtiest, but it's also the simplest. :)
> 
> Good luck!
> 
> Mischa


Thanks for the reply Mischa,

Well since most of traffic is not http based I cannot use the headers for 
client IP :-/
This will also be a problem with firewalling on the real servers as well.
So that probably leaves out SNAT and relay proxy. I also agree that DSR is not 
needed.

Yes, multiple VLANs is the cleanest solution.

My concern is mainly with 1 VLAN and multiple subnets which does the trick of 
returning the traffic through the LB as well as keeping the setup simple.

Another solution would also be some kind of private vlans with openvswitch

thanks,

Giannis

Re: Ruby On Rails application with httpd

[Wesley MOUEDINE ASSABY]

Le 2018-03-19 15:55, Artur Pedziwilk a écrit :
On 15 Feb 2018, at 12:03, Wesley MOUEDINE ASSABY 
 wrote:


Is there a way to get a 'Ruby on Rails' application running with the 
embedded OpenBSD httpd(+slowcgi??) ?


Why like that? Relayd is perfect for that on OpenBSD IMHO.


Do you have an example ? (httpd + relayd)

Thank's anyway.

/Wesley

Re: Ruby On Rails application with httpd

[Artur Pedziwilk]

> On 15 Feb 2018, at 12:03, Wesley MOUEDINE ASSABY  
> wrote:
> 
> Is there a way to get a 'Ruby on Rails' application running with the embedded 
> OpenBSD httpd(+slowcgi??) ?

Why like that? Relayd is perfect for that on OpenBSD IMHO.

Re: Dual-ISP home router setup problems

[Samuel Wagen]

And of course, too much copy paste while trying to use documentation
IP ranges. The two gateways in pf.conf above should be

isp_a_gw = "198.51.100.1"
isp_b_gw = "203.0.113.1"

The rest stands.

On Mon, Mar 19, 2018 at 1:40 PM, Samuel Wagen  wrote:
> Hello,
>
> I'm trying to build a home router with OpenBSD. I have two ISPs, both are
> giving me real IPs, one with straight DHCP (ISP_A), the other - via PPPoE
> (ISP_B). I've described the topology with more detail in the diagram below.
>
> I wanted to use PF with routing domains instead of multipath forwarding, due
> to multipath being very finicky when a link goes down. My current setup is
> described below. I have the following issues:
>
> - Initially I can't pass traffic from the LAN. I think this is due to the
>   packets on em0 being dropped before PF has a chance to reach them, due
>   to missing default route on rdomain 0. If I execute the following two
>   commands:
> # route -T 0 add 198.51.100.0/24 127.0.0.1
> # route -T 0 add 203.0.113.0/24 127.0.0.1
>   then traffic starts passing half of the time - if the round-robin
>   decides it should go over the PPPoE link (ISP_B) - traffic from the LAN
>   flows. If, however, it decides to go through the other link (ISP_A) -
>   nothing passes, and I get the following kernel messages:
>
> arpresolve: 198.51.100.0: route contains no arp information
>
> - Traffic from the gateway itself to the Internet always fails, unless I
>   specify a routing domain manually (route -T 1 exec whatever). Not sure
>   what bogus route to add here, so that packets aren't dropped before PF,
>   and what to add to PF so that they flow.
>
> In other words, I'm stuck, and need some pointers on how to continue and what
> am I doing wrong. I'm running latest snapshot, but also tried with 6.2.
>
> Many thanks in advance.
>
> Here's the info about my config, let me know if you need me to provide some
> more. The "internet" networks are from RFC5737 for illustration purposes.
>
> 1. Network diagram
>
>+-+   +-+
>|  ISP_A  |   |  ISP_B  |
>+---+-+   +---+-+
>| |
>| |
>| |
> ++-+-+++
> ||  em1  em2/pppoe0   ||
> ||  DHCP client  real IP  ||
> ||  IP: 198.51.100.20IP: 203.0.113.40 ||
> ||  Net: 198.51.100.0/24 Net: 203.0.113.0/24  ||
> ||  GW: 198.51.100.1 GW: 203.0.113.1  ||
> ||  rdomain 1rdomain 2||
> G|  group isp_a  group isp_b  |G
> A||A
> T||T
> E+- - - - - - - - - - - NAT- - - - - - - - - - - -+E
> W||W
> A||A
> Y|   em0  |Y
> ||   DHCP server  ||
> ||   IP: 172.16.16.1  ||
> ||   Net: 172.16.16.0/24  ||
> ||   rdomain 0||
> ||   group lan||
> +++---++
>   |
>   |
>   |
>+--++
>|LAN|
>+---+
>
>
> 2. Interface config files
>
> - /etc/hostname.em0
>
> inet 172.16.16.1 255.255.255.0 172.16.16.255 group lan
>
> - /etc/hostname.em1
>
> dhcp group isp_a rdomain 1
>
> - /etc/hostname.em2
>
> up
>
> - /etc/hostname.pppoe0
>
> inet 0.0.0.0 255.255.255.255 NONE \
> pppoedev em2 authproto chap \
> authname 'user' authkey 'verysecret' \
> group isp_b \
> rdomain 2 \
> up
> dest 0.0.0.1
> !/sbin/route -T 2 add default -ifp pppoe0 0.0.0.1
>
>
> 3. DHCP server config (/etc/dhcpd.conf)
>
> subnet 172.16.16.0 netmask 255.255.255.0 {
> option domain-name-servers 172.16.16.2, 172.16.16.3;
> option routers 172.16.16.1;
> range 172.16.16.100 172.16.16.199;
> }
>
>
> 4. PF config
>
> # Need to figure out how avoid hardcoding these
> isp_a_gw = "172.16.18.1"
> isp_b_gw = "192.168.68.1"
>
> set debug debug
>
> match in log all scrub (no-df random-id max-mss 1440)
>
> match out log on em1 from (lan:network) nat-to (em1)
> match out log on pppoe0 from (lan:network) nat-to (pppoe0)
>
> pass out log on lan to (lan:network)
> pass in log quick on lan from (lan:network) to (lan)
>
> pass in log on lan from (lan:network) \
> route-to { (em1 $isp_a_gw), (pppoe0  $isp_b_gw) } \
> round-robin
>
> pass 

Re: relayd clients on same network with servers

[Mischa]

Hi Giannis,

>From my experience dealing with a lot of load balancers in my time, and also 
>working for different vendors, the easiest is to use source-nat.
This is just configuration on the relayd itself without making "major" changes 
in the rest of the network or servers. Which you would need to do to when 
choosing different VLANs or DSR.

Your concern about source-net and hiding the client IP is valid, but easily 
fixed with Client-IP header in http, if http is the protocol, otherwise you 
will loose the client IP. ;)
One more thing to remember with source-nat is the maximum amount of concurrent 
connections you can handle in a single IP, if that is below 64k you are fine, 
otherwise you will have to create a pool of IPs to source-nat from.

In my opinion DSR is only relevant for services like FTP and NNTP, where you 
have a lot more traffic going out than coming in, so you don't have to put that 
burden through the single load balancer interface.

If you have the ability to change the VLANs that of course the cleanest of all 
the option and source-nat the dirtiest, but it's also the simplest. :)

Good luck!

Mischa


> On 19 Mar 2018, at 11:20, Kapetanakis Giannis  
> wrote:
> 
> Hi,
> 
> I'm designing a new setup with relayd and multiple pools. I'm using redirects 
> with forward.
> 
> The problem I have is that all the real server as in the same VLAN.
> In advance the servers in one pool need to access the servers in another 
> pool, through the load balancer, thus having a problem with replies not 
> passing through the LB (ie IMAP server accessing LDAP servers)
> 
> I've thought of different solutions for this and I've come up to the 
> following. I need a second opinion:
> 
> 1) Use different VLAN per pool of servers
> 2) 1 VLAN, with 1 bridge and multiple subnets on vether devices
> 3) Source NAT to hide client IP
> 4) Use a relay as a proxy (instead of redirect on the $int_if)
> 5) Use DSR (route-to) with sloppy states
> 
> Solution 1 seems the best to me but it has overhead of adding/managing the 
> vlans everywhere.
> Solution 2 seems to work but I'm not quite sure about it
> 3 and 4 hide the client IP so I want to avoid it
> 5 also want to avoid, has problems with failover, don't like the half states
> 
> So 2 seems ok, I have basic separation of pools and I guess since I control 
> all the servers the jumping from one subnet to another is not a serious 
> security problem.
> 
> appreciate any opinions on this
> 
> Giannis
> ps. whole setup with carp-pfsync
> 

Re: last snapshot points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/

[Peter N. M. Hansteen]

On Mon, Mar 19, 2018 at 12:34:43PM +0100, Sven Wolf wrote:
> I've updated my system to the latest amd64 snapshot. When I run a system
> updade from bsd.rd and pkg_add then it points to /pub/OpenBSD/6.3/ instead
> to /pub/OpenBSD/snapshots/.
> 
> The problem occurs in my opinion since last friday. Is there something which
> I can fix on my machine? Or is this an error from kernel?

Not the kernel, but the snapshot is close enough to release that this is 
expected
behavior. for a little while now, you will need to prepend -D snap to your other
pkg_add options if you're running a snapshot. It's in the pkg_add man page, but
easy to miss I guess.

- Peter
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Dual-ISP home router setup problems

[Samuel Wagen]

Hello,

I'm trying to build a home router with OpenBSD. I have two ISPs, both are
giving me real IPs, one with straight DHCP (ISP_A), the other - via PPPoE
(ISP_B). I've described the topology with more detail in the diagram below.

I wanted to use PF with routing domains instead of multipath forwarding, due
to multipath being very finicky when a link goes down. My current setup is
described below. I have the following issues:

- Initially I can't pass traffic from the LAN. I think this is due to the
  packets on em0 being dropped before PF has a chance to reach them, due
  to missing default route on rdomain 0. If I execute the following two
  commands:
# route -T 0 add 198.51.100.0/24 127.0.0.1
# route -T 0 add 203.0.113.0/24 127.0.0.1
  then traffic starts passing half of the time - if the round-robin
  decides it should go over the PPPoE link (ISP_B) - traffic from the LAN
  flows. If, however, it decides to go through the other link (ISP_A) -
  nothing passes, and I get the following kernel messages:

arpresolve: 198.51.100.0: route contains no arp information

- Traffic from the gateway itself to the Internet always fails, unless I
  specify a routing domain manually (route -T 1 exec whatever). Not sure
  what bogus route to add here, so that packets aren't dropped before PF,
  and what to add to PF so that they flow.

In other words, I'm stuck, and need some pointers on how to continue and what
am I doing wrong. I'm running latest snapshot, but also tried with 6.2.

Many thanks in advance.

Here's the info about my config, let me know if you need me to provide some
more. The "internet" networks are from RFC5737 for illustration purposes.

1. Network diagram

   +-+   +-+
   |  ISP_A  |   |  ISP_B  |
   +---+-+   +---+-+
   | |
   | |
   | |
++-+-+++
||  em1  em2/pppoe0   ||
||  DHCP client  real IP  ||
||  IP: 198.51.100.20IP: 203.0.113.40 ||
||  Net: 198.51.100.0/24 Net: 203.0.113.0/24  ||
||  GW: 198.51.100.1 GW: 203.0.113.1  ||
||  rdomain 1rdomain 2||
G|  group isp_a  group isp_b  |G
A||A
T||T
E+- - - - - - - - - - - NAT- - - - - - - - - - - -+E
W||W
A||A
Y|   em0  |Y
||   DHCP server  ||
||   IP: 172.16.16.1  ||
||   Net: 172.16.16.0/24  ||
||   rdomain 0||
||   group lan||
+++---++
  |
  |
  |
   +--++
   |LAN|
   +---+


2. Interface config files

- /etc/hostname.em0

inet 172.16.16.1 255.255.255.0 172.16.16.255 group lan

- /etc/hostname.em1

dhcp group isp_a rdomain 1

- /etc/hostname.em2

up

- /etc/hostname.pppoe0

inet 0.0.0.0 255.255.255.255 NONE \
pppoedev em2 authproto chap \
authname 'user' authkey 'verysecret' \
group isp_b \
rdomain 2 \
up
dest 0.0.0.1
!/sbin/route -T 2 add default -ifp pppoe0 0.0.0.1


3. DHCP server config (/etc/dhcpd.conf)

subnet 172.16.16.0 netmask 255.255.255.0 {
option domain-name-servers 172.16.16.2, 172.16.16.3;
option routers 172.16.16.1;
range 172.16.16.100 172.16.16.199;
}


4. PF config

# Need to figure out how avoid hardcoding these
isp_a_gw = "172.16.18.1"
isp_b_gw = "192.168.68.1"

set debug debug

match in log all scrub (no-df random-id max-mss 1440)

match out log on em1 from (lan:network) nat-to (em1)
match out log on pppoe0 from (lan:network) nat-to (pppoe0)

pass out log on lan to (lan:network)
pass in log quick on lan from (lan:network) to (lan)

pass in log on lan from (lan:network) \
route-to { (em1 $isp_a_gw), (pppoe0  $isp_b_gw) } \
round-robin

pass out log on em1 from pppoe0 route-to (pppoe0 $isp_b_gw)
pass out log on pppoe0 from em1 route-to (em1 $isp_a_gw)

pass out log quick on em1 inet from (em1) modulate state rtable 1
pass out log quick on pppoe0 from (pppoe0) modulate state rtable 2


5. Additional issues

- How to avoid hardcoding the ISP defaut routes?
- How to use sticky sessions instead of round-robin?
- How to deal with links going down? E.g. not try to send traffic to a failed
  link.


-- 
sw

last snapshot points to /pub/OpenBSD/6.3/ instead to /pub/OpenBSD/snapshots/

[Sven Wolf]

Hi,

I've updated my system to the latest amd64 snapshot. When I run a system 
updade from bsd.rd and pkg_add then it points to /pub/OpenBSD/6.3/ 
instead to /pub/OpenBSD/snapshots/.


The problem occurs in my opinion since last friday. Is there something 
which I can fix on my machine? Or is this an error from kernel?


When I installed the snapshot from 2018-03-10 (about a week ago) 
everything worked as expected.


Here are the kernel informations from dmesg:

OpenBSD 6.3 (GENERIC.MP) #68: Fri Mar 16 01:24:47 MDT 2018
OpenBSD 6.3 (RAMDISK_CD) #64: Sun Mar 18 15:14:26 MDT 2018
OpenBSD 6.3 (GENERIC.MP) #72: Sun Mar 18 15:09:43 MDT 2018

I've tested the upgrade via bsd.rd and also via install63.fs.

Thanks and best regards,
Sven

Re: stop syslogd from opening port 514 UDP

[Torsten]

> it is your test methodology that is broken

Well, I said "I want the machine to be invisible", so I don't think
there is anything wrong with me testing which ports are open and
checking what I can do (besides pf) to close them.

Anyway, thanks for your help!

Cheers!

Re: httpd / acme-client confusion

[Stuart Henderson]

On 2018-03-19, Markus Rosjat  wrote:
> Hi,
>
>> acme-client can only validate an authorization that way.
>> 
>> but for a forced renewal for something that's already active, there's
>> likely to already be a validated authorization on the letsencrypt account,
>> in which case it wouldn't need to revalidate.
>> 
>
> I did a forced renew after I got a valid certificate and stoped the 
> httpd before I did the forced renew

If you need to force a renewal it means the certificate isn't that old in
the first place and very likely to be in the window in which you already have
a valid authorization.

> I will do the suggested changes to the config and keep an eye on it.

Just place a file in the .well-known/acme-challenge directory and make
sure you can fetch it. Then you don't have to wait for a possible failure
sometime in the future when you're not thinking about it.

Re: Installing a snapshot to a USB key using bsd.rd

[Rodney Polkinghorne]

It turns out that the snapshot on Aarnet failed to match its checksum
for a blindingly obvious reason.  It was corrupt.

I installed a snapshot from another mirror, started X, and crashed the
kernel.  I'll try to post the details to bugs@ in a day or two, but
some hand holding would be appreciated.

Thanks everyone

Rodney

relayd clients on same network with servers

[Kapetanakis Giannis]

Hi,

I'm designing a new setup with relayd and multiple pools. I'm using redirects 
with forward.

The problem I have is that all the real server as in the same VLAN.
In advance the servers in one pool need to access the servers in another pool, 
through the load balancer, thus having a problem with replies not passing 
through the LB (ie IMAP server accessing LDAP servers)

I've thought of different solutions for this and I've come up to the following. 
I need a second opinion:

1) Use different VLAN per pool of servers
2) 1 VLAN, with 1 bridge and multiple subnets on vether devices
3) Source NAT to hide client IP
4) Use a relay as a proxy (instead of redirect on the $int_if)
5) Use DSR (route-to) with sloppy states

Solution 1 seems the best to me but it has overhead of adding/managing the 
vlans everywhere.
Solution 2 seems to work but I'm not quite sure about it
3 and 4 hide the client IP so I want to avoid it
5 also want to avoid, has problems with failover, don't like the half states

So 2 seems ok, I have basic separation of pools and I guess since I control all 
the servers the jumping from one subnet to another is not a serious security 
problem.

appreciate any opinions on this

Giannis
ps. whole setup with carp-pfsync

Re: httpd / acme-client confusion

[Markus Rosjat]

Hi,


acme-client can only validate an authorization that way.

but for a forced renewal for something that's already active, there's
likely to already be a validated authorization on the letsencrypt account,
in which case it wouldn't need to revalidate.



I did a forced renew after I got a valid certificate and stoped the 
httpd before I did the forced renew



if you really stopped httpd and there is still something listening then
there is another webserver process running.
You can check locally with netstat(1) or 'ps -aux'


there was no other process running since I checked that before I did the 
forced renew.


I will do the suggested changes to the config and keep an eye on it. My 
main problem was with the block statement the other thing I just noticed 
as I did testing with the config and started forcing the renew of the 
certificate


regards

--
Markus Rosjatfon: +49 351 8107223mail: ros...@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220   fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before 
you print it, think about your responsibility and commitment to the 
ENVIRONMENT

Re: stop syslogd from opening port 514 UDP

[Janne Johansson]

2018-03-19 8:07 GMT+01:00 Torsten :

> >> On my OpenBSD 6.2 syslogd is listening to port 514
> >> [...]
> >> prevent syslogd from opening that port in the first place?
>
> > If [...] no logging rules exist to send to a remote
> > host the socket is closed per default since 6.2. Perhaps you are logging
> > to a remote host?
>
> Thank you for you answer, indeed I am logging to a remote host. However,
> I don't understand why logging to a remote host opens port 514 incoming.
>
>
Because that is how UDP works. The code will not collect anything incoming
to that port, but it will still look like it's "listening" because its
open, and its open
so that syslog can send on it.


> Anyway, I understand you're saying that this is intended behaviour and
> cannot be circumvented other than using pf, right?
>
>
Well, given how it actually works, it is your test methodology that is
broken
(ie assuming an open port means someone will read and act on the data
and that this in turn means you are in trouble) so "circumventing" a faulty
assumption is hard to give a decent answer to.

Sure, you should PF all ports that you don't want to receive packets on so
that is still valid for UDP on port 514 and 512 and 30044, but you don't
have
to do it in order for syslog to not fill up your harddrive with spoofed log
lines
which you already concluded, so PF is always good, and it is also a solution
to the non-problem you already knew you had.

Other syslog daemons may be worse in this regard and reading guidelines
about them might lead you to think that you also must do X,Y and Z for
this particular daemon, but that is not so.

You might actually be able to find previous discussions on misc/tech about
it,
since it comes up now and then.

-- 
May the most significant bit of your life be positive.

Re: the Alpha lives...

[Paul de Weerd]

I know you're all on the edge of your seat for the next episode in
this saga .. so here goes.

`make build` failed during the night (after 431 minutes build time)
while running configure for nsd.  Here's the failing test:

checking size of off_t... pid 87911 (conftest): unaligned access: 
va=0xdfdfdfdfdfdfdfef pc=0xbd7b2fe0 ra=0xbd7b3380 op=ldq
configure: error: in `/usr/src/usr.sbin/nsd/obj':
configure: error: cannot compute sizeof (off_t)
See `config.log' for more details
*** Error 77 in usr.sbin/nsd (Makefile.bsd-wrapper:53 'config.status')
*** Error 1 in usr.sbin (:48 'all')
*** Error 1 in . (:48 'all')
*** Error 1 in . (Makefile:95 'do-build')
*** Error 1 in /usr/src (Makefile:74 'build')

However, there was one other issue like that just before it (also
while configuring nsd):

checking whether the C compiler (cc) accepts the "format" attribute... yes  


   
checking whether the C compiler (cc) accepts the "unused" attribute... yes  

checking if memcmp compares unsigned... pid 27732 (conftest): unaligned access: 
va=0xdfdfdfdfdfdfdfef pc=0x9de96fe0 ra=0x9de97380 op=ldq

   
no  
 
checking whether ctime_r works with two arguments... yes


   
checking for libevent... found in /usr  
 

Already talking to Florian (CC:'d) about this issue.

Paul 'WEiRD' de Weerd

On Sun, Mar 18, 2018 at 07:47:30PM +0100, Paul de Weerd wrote:
| Building a -current kernel took over an hour (I forgot to time it),
| but it worked!  I'm now going to build a release, but that's going to
| take several hours, if the kernel build time is any indication...
| 
| So here's the 6.3 dmesg (with some extra SCSI devices thrown into the
| mix, for fun):
| 
| [ using 1147568 bytes of bsd ELF symbol table ]
| consinit: not using prom console
| Copyright (c) 1982, 1986, 1989, 1991, 1993
|   The Regents of the University of California.  All rights reserved.
| Copyright (c) 1995-2018 OpenBSD. All rights reserved.  https://www.OpenBSD.org
| 
| OpenBSD 6.3 (GENERIC) #0: Sun Mar 18 18:48:27 CET 2018
| we...@alfalfa.alm.weirdnet.nl:/usr/src/sys/arch/alpha/compile/GENERIC
| Digital Personal WorkStation 600au, 598MHz
| 8192 byte page size, 1 processor.
| real mem = 536870912 (512MB)
| rsvd mem = 1941504 (1MB)
| avail mem = 515710976 (491MB)
| mainbus0 at root
| cpu0 at mainbus0: ID 0 (primary), 21164A-0 (unknown minor type 0)
| cpu0: architecture extensions: 1
| cia0 at mainbus0: DECchip 2117x Core Logic Chipset (Pyxis), pass 1
| cia0: extended capabilities: 1
| cia0: using BWX for PCI config and bus access
| cia0: WARNING: Pyxis pass 1 DMA bug; no bets...
| pci0 at cia0 bus 0
| dc0 at pci0 dev 3 function 0 "DEC 21142/3" rev 0x30: dec 550 irq 0, address 
00:00:f8:76:04:64
| nsphy0 at dc0 phy 5: DP83840 10/100 PHY, rev. 1
| pciide0 at pci0 dev 4 function 0 "CMD Technology PCI0646" rev 0x01: DMA, 
channel 0 wired to compatibility, channel 1 wired to compatibility
| atapiscsi0 at pciide0 channel 0 drive 0
| scsibus0 at atapiscsi0: 2 targets
| cd0 at scsibus0 targ 0 lun 0:  ATAPI 5/cdrom 
removable
| cd0(pciide0:0:0): using PIO mode 3, DMA mode 1
| pciide0: channel 1 disabled (no drives)
| sio0 at pci0 dev 7 function 0 "Intel 82378IB ISA" rev 0x43
| qlw0 at pci0 dev 12 function 0 "QLogic ISP1020" rev 0x05: dec 550 irq 8
| qlw0: firmware rev 4.66.0, attrs 0x0
| scsibus1 at qlw0: 16 targets, initiator 7
| cd1 at scsibus1 targ 0 lun 0:  SCSI2 5/cdrom 
removable
| cd2 at scsibus1 targ 1 lun 0:  SCSI2 5/cdrom 
removable
| cd3 at scsibus1 targ 2 lun 0:  SCSI2 5/cdrom 
removable
| cd4 at scsibus1 targ 3 lun 0:  SCSI2 5/cdrom 
removable
| cd5 at scsibus1 targ 4 lun 0:  SCSI2 5/cdrom 
removable
| sd0 at scsibus1 targ 5 lun 0:  SCSI2 0/direct removable
| sd0: 96MB, 512 bytes/sector, 196608 sectors
| st0 at scsibus1 targ 6 lun 0:  

Re: stop syslogd from opening port 514 UDP

[Torsten]

>> On my OpenBSD 6.2 syslogd is listening to port 514
>> [...]
>> prevent syslogd from opening that port in the first place?

> If [...] no logging rules exist to send to a remote
> host the socket is closed per default since 6.2. Perhaps you are logging
> to a remote host?

Thank you for you answer, indeed I am logging to a remote host. However,
I don't understand why logging to a remote host opens port 514 incoming.

Anyway, I understand you're saying that this is intended behaviour and
cannot be circumvented other than using pf, right?