Re: bioctl: Can't locate device

2024-01-22 Thread Mischa Peters



> On Jan 22, 2024, at 15:55, Jan Stary  wrote:
> 
> On Jan 22 13:53:17, open...@mlst.nl wrote:
>> Hi Jan,
>> 
>> I followed the Disk FAQ, foe UEFI.
>> https://www.openbsd.org/faq/faq14.html#softraid
>> 
>> # fdisk -gy -b 532480 sd1
>> # fdisk -gy -b 532480 sd2
>> # fdisk -gy -b 532480 sd3
>> # fdisk -gy -b 532480 sd4
>> 
>> For all of them I did:
>> # disklabel -E sd1
>> sd1> a a
>> offset: [64]
>> size: [39825135] *
>> FS type: [4.2BSD] RAID
>> sd1*> w
>> sd1> q
>> 
>> # bioctl -c 1 -l sd1a,sd2a softraid0
> 
> To be clear: this creates sd5 ...
> 
>> # bioctl -c 1 -l sd3a,sd4a softraid0
> 
> ... and this creates sd6, right?

Yes… someone did make me see my mistake. I never created the device with 
MAKEDEV. After that the devices are seen!

Thanx for helping me out as well. 

Mischa

> 
>> # dd if=/dev/zero of=/dev/rsd5c bs=1m count=1
>> # dd if=/dev/zero of=/dev/rsd6c bs=1m count=1
>> 
>> After that newfs.
> 
> How exactly? newfs sd5a?
> Without any fdisk or disklabel on the newly created sd5?
> What does disklabel sd5 say?
> 
>> One thing I forgot:
>> root@epyc1:~ # sysctl hw | grep drive
>> hw.sensors.softraid0.drive0=online (sd5), OK
>> hw.sensors.softraid0.drive1=online (sd6), OK
>> 
>> Mischa
>> 
>>> On 2024-01-22 12:56, Jan Stary wrote:
>>> How exactly did you create the sd5 SR RAID 1 and the sd6 SR RAID 1?
>>> 
>>> On Jan 22 12:23:36, open...@mlst.nl wrote:
 Hi All,
 
 I created to softraid0 drives, following the FAQ.
 ALl seems to be working without problems, however bioctl isn’t able
 to “see”
 the softraid0 drives, sd5 and sd6.
 
 root@epyc1:~ # dmesg | egrep 'sd([0-6])'
 sd0 at scsibus1 targ 0 lun 0: 
 t10.ATA_DELLBOSS_VD_37b61d1b1f560010_
 sd0: 457798MB, 512 bytes/sector, 937571968 sectors, thin
 sd1 at scsibus2 targ 1 lun 0: 
 sd1: 7630885MB, 512 bytes/sector, 15628053168 sectors
 sd2 at scsibus3 targ 1 lun 0: 
 sd2: 7630885MB, 512 bytes/sector, 15628053168 sectors
 sd3 at scsibus6 targ 1 lun 0: 
 sd3: 7630885MB, 512 bytes/sector, 15628053168 sectors
 sd4 at scsibus7 targ 1 lun 0: 
 sd4: 7630885MB, 512 bytes/sector, 15628053168 sectors
 sd5 at scsibus9 targ 1 lun 0: 
 sd5: 7630625MB, 512 bytes/sector, 15627520063 sectors
 sd6 at scsibus9 targ 2 lun 0: 
 sd6: 7630625MB, 512 bytes/sector, 15627520063 sectors
 root on sd0a (964c4608967fd9ca.a) swap on sd0b dump on sd0b
 
 root@epyc1:~ # for i in $(jot 7 0); do bioctl sd${i}; done
 sd0: , serial 37b61d1b1f560010
 sd1: , serial (unknown)
 sd2: , serial (unknown)
 sd3: , serial (unknown)
 sd4: , serial (unknown)
 bioctl: Can't locate sd5 device via /dev/bio
 bioctl: Can't locate sd6 device via /dev/bio
 
 root@epyc1:~ # df -h
 Filesystem SizeUsed   Avail Capacity  Mounted on
 /dev/sd0a  986M107M830M12%/
 /dev/sd0l  277G192K263G 1%/home
 /dev/sd0d  3.9G   10.0K3.7G 1%/tmp
 /dev/sd0f 29.1G1.3G   26.3G 5%/usr
 /dev/sd0g  986M288M648M31%/usr/X11R6
 /dev/sd0h 19.4G   23.8M   18.4G 1%/usr/local
 /dev/sd0k  5.8G2.0K5.5G 1%/usr/obj
 /dev/sd0j  2.9G2.0K2.8G 1%/usr/src
 /dev/sd5c  7.0T367G6.3T 6%/var
 /dev/sd6c  7.0T670G6.0T10%/var/data
 
 Any idea?
 
 Mischa
 
 
>> 
>> 



Re: DisplayPort to HDMI DRM error report

2023-09-08 Thread Mischa Peters

It's not you, it's me.
I configured the wrong switch port. :/
Should work now.

Mischa

On 2023-09-08 16:46, Daniele B wrote:

Hello,

I just inserted in my student mini pc
OpenBSD 7.2

a brand new DP(male) to HDMI(female) adapter:
https://amazon.it/dp/B08GFJF7LP/

The adapter runs well as I'm able to interact with the station.
But just before the disk initialization some DRM message are reported
as diplayed below.

The tail of the dmesg says this:

drm:pid0:drm_dp_dual_mode_detect *ERROR* [drm] *ERROR* Unexpected DP 
dual mode adaptor ID 20

inteldrm0: 1920x1080, 32bpp
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using 
wskbd0

wskbd1: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
drm:pid901:drm_dp_dual_mode_detect *ERROR* [drm] *ERROR* Unexpected DP 
dual mode adaptor ID 20
drm:pid65608:drm_dp_dual_mode_detect *ERROR* [drm] *ERROR* Unexpected 
DP dual mode adaptor ID 20
drm:pid65608:drm_dp_dual_mode_detect *ERROR* [drm] *ERROR* Unexpected 
DP dual mode adaptor ID 20
drm:pid65608:drm_dp_dual_mode_detect *ERROR* [drm] *ERROR* Unexpected 
DP dual mode adaptor ID 20


Hope it is just fine to work around the prb.


-- Daniele Bonini




Re: vmm error mesg since upgrade to 6.9

2021-05-02 Thread Mischa Peters


> On 2 May 2021, at 14:56, Dave Voutila  wrote:
> 
> 
> Mischa Peters writes:
> 
>>>> On 2 May 2021, at 14:25, Dave Voutila  wrote:
>>> 
>>> 
>>> Mischa writes:
>>> 
>>>> 
>>>> Interestingly I am seeing the same on my 6.9 hosts, except the host 
>>>> running -current.
>>> 
>>> Hmm. -current has some small changes to virtio emulation, specifically
>>> fixing some bad casts I found [1]. That might explain the difference
>>> with -current.
>>> 
>>>> The hosts are similar in regards to configuration.
>>>> I have migrated from bridge/vether to veb/vport.
>>>> 
>>>> May  2 13:14:38 r2 vmd[59033]: vionet_enq_rx: descriptor too small for 
>>>> packet data
>>>> May  2 13:15:12 r2 last message repeated 11 times
>>>> May  2 13:17:13 r2 last message repeated 34 times
>>>> 
>>>> # vmctl show | grep 59033
>>>>  6 59033 14.0G1.8G   ttyp5 root  running images
>>>> 
>>>> # vm.conf
>>>> switch "uplink_vlan880" {
>>>>   interface veb880
>>>> }
>>>> vm "images" {
>>>>   memory 4G
>>>>   disk "/var/vmm/images.qcow2"
>>>>   disk "/var/vmm/images_extra.qcow2"
>>>>   interface tap { switch "uplink_vlan880" }
>>>> }
>>>> 
>>>> # cat /etc/hostname.em0
>>>> up
>>>> # cat /etc/hostname.veb880
>>>> add vlan880
>>>> add vport880
>>>> up
>>>> # cat /etc/hostname.vlan880
>>>> vnetid 880 parent em0
>>>> up
>>>> # cat /etc/hostname.vport880
>>>> inet 46.23.xx.xx 255.255.255.0
>>>> inet6 2a03:6000:xxx::xx
>>>> up
>>>> 
>>>> I am using a combination of dhcp and static IP config on both hosts to 
>>>> provision the VMs.
>>> 
>>> Are you running dhcpd(8) on the host? Or using vmd(8)'s built-in dhcp
>>> service?
>> 
>> Only using dhcpd on the host.
>> 
>>>> What else can be relevant?
>>> 
>>> Logging into my obsd.ams host (that I haven't updated yet to 6.9) it's
>>> using "dhcp" in /etc/hostname.vio0. Do you see this same issue with
>>> *guests* running 6.8? Or only 6.9?
>> 
>> The host running -current only has 6.8 VMs. The hosts where I see the 
>> messages are 6.9 VMs on 6.9 hosts.
>> 
>> Let me spin a 6.9 -release host and run a bunch of 6.8 VMs. And or a mix.
>> 
> 
> I've managed to reproduce it on my end using vmd(8) from 6.9 and a
> config similar to what you and Holger are using. I have a few hunches
> and looking into it.

Nice! Let me know if there is something you need or want me to test. 

Mischa



Re: vmm error mesg since upgrade to 6.9

2021-05-02 Thread Mischa Peters


> On 2 May 2021, at 14:25, Dave Voutila  wrote:
> 
> 
> Mischa writes:
> 
>> 
>> Interestingly I am seeing the same on my 6.9 hosts, except the host running 
>> -current.
> 
> Hmm. -current has some small changes to virtio emulation, specifically
> fixing some bad casts I found [1]. That might explain the difference
> with -current.
> 
>> The hosts are similar in regards to configuration.
>> I have migrated from bridge/vether to veb/vport.
>> 
>> May  2 13:14:38 r2 vmd[59033]: vionet_enq_rx: descriptor too small for 
>> packet data
>> May  2 13:15:12 r2 last message repeated 11 times
>> May  2 13:17:13 r2 last message repeated 34 times
>> 
>> # vmctl show | grep 59033
>>   6 59033 14.0G1.8G   ttyp5 root  running images
>> 
>> # vm.conf
>> switch "uplink_vlan880" {
>>interface veb880
>> }
>> vm "images" {
>>memory 4G
>>disk "/var/vmm/images.qcow2"
>>disk "/var/vmm/images_extra.qcow2"
>>interface tap { switch "uplink_vlan880" }
>> }
>> 
>> # cat /etc/hostname.em0
>> up
>> # cat /etc/hostname.veb880
>> add vlan880
>> add vport880
>> up
>> # cat /etc/hostname.vlan880
>> vnetid 880 parent em0
>> up
>> # cat /etc/hostname.vport880
>> inet 46.23.xx.xx 255.255.255.0
>> inet6 2a03:6000:xxx::xx
>> up
>> 
>> I am using a combination of dhcp and static IP config on both hosts to 
>> provision the VMs.
> 
> Are you running dhcpd(8) on the host? Or using vmd(8)'s built-in dhcp
> service?

Only using dhcpd on the host.

>> What else can be relevant?
> 
> Logging into my obsd.ams host (that I haven't updated yet to 6.9) it's
> using "dhcp" in /etc/hostname.vio0. Do you see this same issue with
> *guests* running 6.8? Or only 6.9?

The host running -current only has 6.8 VMs. The hosts where I see the messages 
are 6.9 VMs on 6.9 hosts. 

Let me spin a 6.9 -release host and run a bunch of 6.8 VMs. And or a mix.

Mischa

> -dv
> 
> [1] 
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/vmd/virtio.c.diff?r1=1.84&r2=1.85&only_with_tag=MAIN



Re: Running out of pty's

2020-08-27 Thread Mischa Peters



--

> On 27 Aug 2020, at 16:25, Paul de Weerd  wrote:
> 
> On Thu, Aug 27, 2020 at 02:52:04PM +0200, Mischa wrote:
> | Hi All,
> | 
> | I am managing a OpenBSD instance for a customer of mine who uploads camera 
> images via sftp to be used in a single location.
> | It looks like there are quite a number of camera’s uploading at once.
> | I am seeing a lot of message like:
> | 
> | Aug 27 13:53:28 images sshd[68494]: error: do_exec_no_pty: fork: Resource 
> temporarily unavailable
> | Aug 27 13:53:43 images sshd[53989]: error: do_exec_no_pty: fork: Resource 
> temporarily unavailable
> 
> For the archives .. you're not running out of pty's but. 
> 
> you can't fork.  That's another resource that's limited.  There's
> a kernel limit (sysctl kern.maxproc), but there's also ulimits (those
> you are more likely to hit, especially if it's all the same user).

Thanx Paul! That was indeed it.
Increasing the maxproc in /etc/login.conf made it work.

Mischa

> | I have tried adding a bunch of pty’s and increased them,
> | inadvertently from 62 to 620, but I guess I missed something. :/
> 
> You missed the 'fork' part.  Oh, and the "no_pty" part of the function
> that was complaining: sftp can work without a pty (see
> https://man.openbsd.org/ssh#T - sftp doesn't need a pseudo terminal
> IIRC).
> 
> | Any insights someone can share?
> 
> Cheers,
> 
> Paul
> 
> -- 
>> [<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
> http://www.weirdnet.nl/ 



Re: 6.6-beta (RAMDISK_CD) #281 hangs on fsck

2019-09-08 Thread Mischa Peters



> On 8 Sep 2019, at 14:22, Otto Moerbeek  wrote:
> 
>> On Sun, Sep 08, 2019 at 02:12:07PM +0200, Mischa wrote:
>> 
>> For completeness here is a successful boot on 6.5 MP#5.
> 
> Can you try bisecting using bsd.rd's from the archive?

Let me try a couple and see if I get different results. 
Any recommendation on how far back to start?

Mischa 

>-Otto
> 
>> 
>> Mischa
>> 
 OpenBSD/amd64 BOOT 3.43
>> boot>
>> booting hd0a:/bsd: 10683784+2466832+34+0+675840 
>> [679209+128+857256+597608]=0xf8e4c0
>> entry point at 0x1001000
>> [ using 2135232 bytes of bsd ELF symbol table ]
>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>>The Regents of the University of California.  All rights reserved.
>> Copyright (c) 1995-2019 OpenBSD. All rights reserved.  
>> https://www.OpenBSD.org
>> 
>> OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019
>>
>> r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>> real mem = 206094401536 (196546MB)
>> avail mem = 199838711808 (190581MB)
>> mpath0 at root
>> scsibus0 at mpath0: 256 targets
>> mainbus0 at root
>> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7f42c000 (99 entries)
>> bios0: vendor Dell Inc. version "2.7.0" date 05/23/2018
>> bios0: Dell Inc. PowerEdge R620
>> acpi0 at bios0: rev 2
>> acpi0: sleep states S0 S4 S5
>> acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT 
>> EINJ TCPA PC__ SRAT SSDT
>> acpi0: wakeup devices PCI0(S5) PCI1(S5)
>> 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) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.40 MHz, 06-2d-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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,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.2, IBE
>> cpu1 at mainbus0: apid 32 (application processor)
>> cpu1: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 1200.00 MHz, 06-2d-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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>> cpu1: 256KB 64b/line 8-way L2 cache
>> cpu1: smt 0, core 0, package 1
>> cpu2 at mainbus0: apid 2 (application processor)
>> cpu2: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz, 06-2d-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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>> cpu2: 256KB 64b/line 8-way L2 cache
>> cpu2: smt 0, core 1, package 0
>> cpu3 at mainbus0: apid 34 (application processor)
>> cpu3: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz, 06-2d-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,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>> cpu3: 256KB 64b/line 8-way L2 cache
>> cpu3: smt 0, core 1, package 1
>> cpu4 at mainbus0: apid 4 (application processor)
>> cpu4: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz, 06-2d-07
>> cpu4: 
>> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>> cpu4: 256KB 64b/line 8-way L2 cache
>> cpu4: smt 0, core 2, package 0
>> cpu5 at mainbus0: apid 36 (application processor)
>> cpu5: Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz, 2800.00 MHz, 06-2d-07
>> cpu5: 
>> 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,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,PAGE1GB,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
>> cpu5: 256KB 64b/line 

Re: HTTPD and php-cgi

2018-05-04 Thread Mischa Peters

> On 5 May 2018, at 03:23, Duncan Patton a Campbell  wrote:
> 
> 
> I am looking for documentation on running php-cgi-5.6 under the bsd httpd 
> server.
> 
> From what I can tell, the function of php-fastcgi has been subsumed to 
> php-cgi-5.6, 
> but further than that I can find little or no salient documentation.  Any 
> pointers
> would be appreciated.

Hi Duncan,

Everything you need to know is in a README when you install the pkg. 

$ less /usr/local/share/doc/pkg-readmes/php-7.0.28

Unfortunately the php example has been removed from /etc/examples/httpd.conf

But you need something like the following in your httpd.conf:

server "default" {
listen on $ext_addr port 80
location "/.well-known/acme-challenge/*" {
root { "/acme", strip 2 }
}
location "*.php" {
fastcgi socket "/run/php-fpm.sock"
}
root "/htdocs/default"
}

Mischa



Re: httpd howto redirect port 80 to 443 in vm

2018-02-27 Thread Mischa Peters

> On 27 Feb 2018, at 05:04, niya  wrote:
> 
> hi
> using vmd in openbsd 6.2
> and following 
> http://thecyberrecce.net/2017/01/15/secure-webservers-with-openbsd-6-0-setting-up-httpd-mariadb-and-php/
> i have setup openbsd running a webserver
> everything installed and the webserver works via port 80 and 443.
> i can access the webserver from a remote client by browsing to the ip of the 
> host machine and redirecting to the vm address and port using pf.
> i tried to setup port 80 redirection to port 443 so that all all access is 
> over HTTPS, when i use http://host ip, i am redirected to https://default/
> how do i get the webserver to redirect to the ip address of the host machine?
> 
> my httpd.conf
> 
> server "default" {
> listen on $ext_addr port 80 block return 301 
> "https://$SERVER_NAME$REQUEST_URI";
> #   listen on $ext_addr port 80
> listen on $ext_addr tls port 443
> tls {
> key "/etc/ssl/private/server.key"
> certificate "/etc/ssl/server.crt"
> }
> directory {
> index "index.php"
> }
> location "*.php" {
> fastcgi socket "/run/php-fpm.sock"
> }
> 
> 
> shadrock

Hi,

$SERVER_NAME uses the name you have specified at ‘server “default”’ which is 
“default” in this case. 

Mischa



Re: relayd stops processing traffic intermittently

2017-12-23 Thread Mischa Peters

> On 23 Dec 2017, at 13:08, Claudio Jeker  wrote:
> 
>> On Sat, Dec 23, 2017 at 11:40:57AM +0100, Mischa wrote:
>> Hi All,
>> 
>> Since OpenBSD 6.2, just confirmed this in the latest snapshot 
>> (GENERIC.MP#305) as well, for some reason relayd stops processing traffic 
>> and starts flooding the log file with the following message:
>> 
>> Dec 23 11:19:11 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:12 lb2 relayd[52110]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:12 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:12 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>> [snip]
>> Dec 23 11:19:17 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:18 lb2 relayd[22515]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:18 lb2 relayd[52110]: rsae_send_imsg: poll timeout
>> Dec 23 11:19:18 lb2 relayd[69641]: rsae_send_imsg: poll timeout
>> ...etc...
>> 
>> Restarting the daemon "fixes" the problem.
>> Not sure how to trouble shoot this but I am able to reproduce this 
>> consistently by pointing SSLLabs towards relayd.
>> Would be great to get some pointers.
>> 
> 
> I have seen this as well on our production systems. This is a problem in
> the privsep part of the TLS code. I could not do more testing yet but my
> assumption is that a new option / feature is freaking this code out.

Anything I can do or collect to give you more information? 

Mischa


Re: relayd l7 loadbalancing

2017-08-16 Thread Mischa Peters
> On 16 Aug 2017, at 10:41, Claudio Jeker  wrote:
> On Wed, Aug 16, 2017 at 10:27:58AM +0200, Maxim Bourmistrov wrote:
>> 
>> Once connection is established, state is created in PF. Subsequent requests 
>> will be ???pipelined???.
>> It is possible to influence this behavior by manipulating tcp.established in 
>> pf.conf,
>> but I don???t think this is what you want.
>> 
> 
> This is not correct. The problem is keep-alive and the fact the once a
> backend is selected by relayd it sticks to it until the session is closed.
> This is a bug and something benno@ and I have on our radar to fix.

Great to hear! This will make relayd even more flexible. I guess your todo list 
must to long so I will wait patiently.
My C skills are non existent otherwise I would have tried to help.

> The workaround for now is to disable keep-alive this can be done by
> adding:
>   match header set "Connection" value "close"
> to your config. The solution is not ideal and will make page load times
> slower.

Will check the load times with and without, maybe it's workable for now.

Much appreciated!

Mischa



relayd l7 loadbalancing

2017-08-16 Thread Mischa Peters
Hi All,

I have somewhat the following config for relayd running on 6.1.
And I am trying to forward certain request paths to different hosts.

table  { xx.xx.xx.131 }
table  { xx.xx.xx.31 }
http protocol httpsfilter {
   match request header remove "Proxy"
   match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
   match request header append "X-Forwarded-By" value 
"$SERVER_ADDR:$SERVER_PORT"

   match response header set "Server" value "Sever"
   match response header set "X-Powered-By" value "Power"
   match response header set "X-Frame-Options" value "SAMEORIGIN"
   match response header set "X-Xss-Protection" value "1; mode=block"
   match response header set "X-Content-Type-Options" value "nosniff"

   match request quick path "/crm/" forward to 

   tcp { no splice }
}
relay host_tls {
   listen on $ext_addr_v4 port 443 tls
   listen on $ext_addr_v6 port 443 tls
   protocol httpsfilter
   forward to  port 80 check http "/" host example.com code 200
   forward to  port 80
}

I have tried both "match request quick path" and "match request quick url" but 
what I noticed is that as soon as you have visited one of the URLs that needs 
forwarding to a different host you end up at the  for all subsequent 
requests.
With "match request quick url" this is to be expected as it checks everything 
up to /.

For example:

http://example.com/ -> wwwhost
http://example.com/crm/ -> otherhost
http://exmaple.com/folder/ -> otherhost

Is this expected behaviour for "match request quick path" as well?
Is there any way to do this type of load balancing?

Thanx!!

Mischa



Re: vmd: routing problem

2017-07-20 Thread Mischa Peters
Hi Leo,

Can you ask them how they route the separate subnet to you?

Mischa

> On 20 Jul 2017, at 12:59, Leo Unglaub  wrote:
> 
> Hey,
> 
>> On 07/20/17 06:25, Mike Larkin wrote:
>> sysctl net.inet.ip.forwarding=1 ?
>> I'm not a networking expert but I think your VM's subnet mask is wrong for
>> the gateway you are trying to use.
> 
> thank you for your response. I tryed it with net.inet.ip.forwarding being 1 
> and 0. Both don't work. About the subnet, thats what confuses me as well, but 
> the data center tells me that it is correct. As far as i understand it they 
> do some crazy stuff there with there IPv4 routing:
> 
> https://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en#Subnets
> 
> Thanks and greetings
> Leo
> 



Re: OpenBSD as Open Networking OS

2017-07-17 Thread Mischa Peters
Hi Thomas,

I used to work for Cumulus and the tricky part with this is that you need to 
get access to the broadcom (and melanox) shipsets, which is not trivial and 
costly. 

I would love to see a BSD running on open networking equipment!

There are more NOS out there but they have their own speciality. Cumulus is the 
most generic to the deploy. There is also BigSwitch and IP Fusion. 

Mischa


> On 17 Jul 2017, at 11:00, miraculli .  wrote:
> 
> Hi misc,
> 
> I just read about a trending topic: SDN and Open Networking.
> The principal idea behind Open Networking is to allow the customer
> to install a custom OS to switch-hardware.
> The main software player in this business seems to be a penguin OS
> called: Cumulus
> There is also a overview of devices that are able install a custom OS:
> 
> https://cumulusnetworks.com/products/hardware-compatibility-list/
> 
> Is there any experience using OpenBSD in this domain and with this
> kind of hardware?
> 
> Thanks
> Thomas
>