virtual cluster with rdomain(4)
Hi misc, I wanted to tinker with the cluster manager sysutils/nomad but unfortunately I´ve no spare cluster for tinkering... So I had the idea of utilizing OpenBSDs outstanding possibilities for network isolation to create a virtual cluster on my VM at openbsd.amsterdam. I had different ideas to achieve it but nothing worked so far. So I'd describe my first approach because I think this is the most OpenBSD idiomatic one: I created 5 vether[0-4] devices, everyone in its own rdomain [0-4] and assigned every device its own inet address space 10.10.[0-4].1/24 I also set the 10.10.[0-4].1 as default route in each rtable. Now I learned that pf(4) is needed to route between this 5 rdomains but after several attempts I've no clue how this could be defined. Actually I wanted rdomain 0 to work as hub for all rdomains >0. Maybe someone can hint me in the right direction regards Thomas (host of the u2k20-hackathon, if someone remembers ;-) some further listings if my description above is unclear: ud$ ifconfig vether vether0: flags=8843 mtu 1500 lladdr fe:e1:ba:d7:cc:16 index 23 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.10.0.1 netmask 0xff00 broadcast 10.255.255.255 vether1: flags=8843 rdomain 1 mtu 1500 lladdr fe:e1:ba:d8:73:32 index 24 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.10.1.1 netmask 0xff00 broadcast 10.255.255.255 vether2: flags=8843 rdomain 2 mtu 1500 lladdr fe:e1:ba:d9:bd:e8 index 26 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.10.2.1 netmask 0xff00 broadcast 10.255.255.255 vether3: flags=8843 rdomain 3 mtu 1500 lladdr fe:e1:ba:da:07:4d index 28 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.10.3.1 netmask 0xff00 broadcast 10.255.255.255 vether4: flags=8843 rdomain 4 mtu 1500 lladdr fe:e1:ba:db:31:c8 index 30 priority 0 llprio 3 groups: vether media: Ethernet autoselect status: active inet 10.10.4.1 netmask 0xff00 broadcast 10.255.255.255 ud$ netstat -R Rdomain 0 Interfaces: lo0 vio0 enc0 pflog0 vether0 Routing tables: 0 71 Rdomain 1 Interfaces: vether1 lo1 Routing table: 1 Rdomain 2 Interfaces: vether2 lo2 Routing table: 2 Rdomain 3 Interfaces: vether3 lo3 Routing table: 3 Rdomain 4 Interfaces: vether4 lo4 Routing table: 4
Re: Not possible to sysupgrade via snapshots right now?
On 5/9/2021 4:04 AM, Stuart Henderson wrote: On 2021-05-08, Scott Vanderbilt wrote: Apologies if this is a question to which there is an obvious answer, but I could not find one in the sysupgrade man page, in the FAQ, or by Googling. Is it not possible to do a sysupgrade from 6.9-current to latest using snapshots at the moment? When I try, I get the following response from sysupgrade: This can only have happened if you were running a "6.9" kernel and not "6.9-current". You might still have the boot messages to confirm; zgrep OpenBSD /var/log/messages* I can assure you with absolute certainty that this machine in question was running 6.9-current prior to the attempt to run sysupgrade. Is it possibly relevant that the upgrade files were "cached" to a host on my LAN before the sysupgrade? I typically download all the upgrade files to a local machine and sysupgrade that machine first. Then for two other machines on my network, I sysupgrade with /etc/installurl pointing to my local server. I do this to prevent multiple downloads from the OpenBSD servers. Might having SHA256.sig come from one location while the other upgrade files come from a second location possibly confuse sysupgrade?
Re: Trying to understand/debug caldav vs. httpd issue
On Fri, May 07, 2021 at 09:06:31AM -, Stuart Henderson wrote: > On 2021-05-05, T. Ribbrock wrote: [...] > This is not a bad place to ask. Your description is good but anyone > looking into what's up will want to test, so if you could include > the test tools and a description of setup needed to reproduce that > would help. Including the tcpdump traces would help too. Don't worry > about the mail being long. thank you! In that case, I'll spend some more time in providing the items you mentioned to get them even more generic - currently, the test config is based on my main server and has a few, let's say "historic idiosyncracies" in it. I have always installed Nextcloud manually up until now and I've already noticed some differences between the Nextcloud package-readme and my own config. Not that I think that this will have any significant influence on the issue at hand, but I want this to be as easy to reproduce as possible. I should be able to post them over the next few days (bit strapped for time). [...] > > The Qt-client sends the http-headers first in one TCP-segment (I'm not > > too good on terminology...). Once that has happened, httpd already sends > > back the 401 - and *then* the Qt-client sends the XML-body in a second > > TCP-segment, causing the "400 Bad Request" response (I presume because > > httpd is expecting new headers at this point, not a content body). > It makes no difference to the HTTP protocol whether headers and body are > in separate TCP segments, but some software may handle things wrongly. > httpd uses libevent and it wouldn't be the first time libevent-based > software has problems with data in separate TCP segments (I have a > feeling we might have had a problem with ftp-proxy related to this > but can't find any details, perhaps it was never fixed), That's what I thought as well, but I'm simply not deep enough in the matter to make that call. My skills are just about good enough to read through the httpd sources and with the help of the debug output to get *some* idea of the flow, but that whole libevent-part is beyond me. [...] > Pretty sure it will be on the httpd side. Ok, then I can at least already tell the SailfishOS community member who helped me that he can put this on hold for now on his side. That's something! Regards, Thomas -- - Thomas Ribbrockhttp://www.ribbrock.org/ "You have to live on the edge of reality - to make your dreams come true!"
Re: miniroot.img boot-looping on rpi-4b
Nothing is connected to the Pi except the USB-C for power, the SD card, and the 3 serial wires. On 5/9/21, Justin Yang wrote: > Do you have any USB disks connected to your pi? If so, try to remove that > and boot again to see if it works. > > On Sunday, May 9, 2021, Rob Whitlock wrote: > >> Hello, >> >> I am trying to install OpenBSD 6.9 on a Raspberry Pi 4B. I copied >> miniroot69.img to the SD card with this command: >> >> dd if=miniroot69.img of=/dev/rdisk2 bs=1m >> >> I put it in the Pi and upon boot it fails with this error message >> printed out through serial: >> >> U-Boot 2021.01 (Apr 16 2021 - 15:39:01 +1000) >> >> DRAM: 1.9 GiB >> RPI 4 Model B (0xb03114) >> MMC: mmcnr@7e30: 1, emmc2@7e34: 0 >> Loading Environment from FAT... ** No partition table - mmc 0 ** >> In:serial >> Out: serial >> Err: serial >> Net: eth0: ethernet@7d58 >> PCIe BRCM: link up, 5.0 Gbps x1 (SSC) >> starting USB... >> Bus xhci_pci: probe failed, error -110 >> No working controllers found >> Hit any key to stop autoboot: 0 >> switch to partitions #0, OK >> mmc0 is current device >> ** Bad device specification :1 bootfstype ** >> "Synchronous Abort" handler, esr 0x9604 >> elr: 0009197c lr : 000930c8 (reloc) >> elr: 3b36d97c lr : 3b36f0c8 >> x0 : 6d63625f646e7320 x1 : 5f656c62 >> x2 : 3b3d30a0 x3 : 0001 >> x4 : 3afe9fe0 x5 : >> x6 : 3b3d30a0 x7 : 3b3d30b0 >> x8 : 3afea070 x9 : 0008 >> x10: 3b3d07f2 x11: 3af64780 >> x12: x13: 0004 >> x14: 3af4be58 x15: >> x16: 4110 x17: 2285e5950900a046 >> x18: 3af57da0 x19: 3afe9940 >> x20: 0811 x21: 0811 >> x22: x23: >> x24: x25: >> x26: 0028 x27: 0003 >> x28: x29: 3af4bac0 >> >> Code: 2a1b03e1 97e5 2a0003f8 140d (f8777800) >> Resetting CPU ... >> >> resetting ... >> >> Any help would be appreciated. >> >> Rob >> >> > > -- > Justin Yang >
Re: Not possible to sysupgrade via snapshots right now?
On 2021-05-08, Scott Vanderbilt wrote: > Apologies if this is a question to which there is an obvious answer, but > I could not find one in the sysupgrade man page, in the FAQ, or by Googling. > > Is it not possible to do a sysupgrade from 6.9-current to latest using > snapshots at the moment? When I try, I get the following response from > sysupgrade: This can only have happened if you were running a "6.9" kernel and not "6.9-current". You might still have the boot messages to confirm; zgrep OpenBSD /var/log/messages*
Re: Bidirectional audio between OpenBSD sndiod <-> Debian pulseaudio
On Sat, May 08, 2021 at 10:29:35AM +, Martin wrote: > Hi list, > > It is great to have bidirectional audio between OpenBSD host and Debian guest > (headless). I hope I move in a right way to make this thing working. > > Required configuration: > mic-in on OpenBSD host >> Debian VMM guest > audio-out from Debian VMM guest >> OpenBSD host > > Does anybody using pulseaudio or any other driver to have > bidirectional network audio stream between VMM guest and OpenBSD > host system? Hi, These days I use a simiar setup with Alpine running in a OpenBSD-hosted VM. The main purpose of sndiod -L option is to handle such setups (don't forget to copy your ~/.sndio/cookie on the VM). In the past, I used a lot Debian, but on a real machine. I didn't try to involve pulseaudio or any alsa tweakery, to limit the number of audio software layers and in turn get the maximum audio stability. So I just rebuild the software I needed with sndio support enabled (that was mostly firefox and few audio players).
Re: miniroot.img boot-looping on rpi-4b
Do you have any USB disks connected to your pi? If so, try to remove that and boot again to see if it works. On Sunday, May 9, 2021, Rob Whitlock wrote: > Hello, > > I am trying to install OpenBSD 6.9 on a Raspberry Pi 4B. I copied > miniroot69.img to the SD card with this command: > > dd if=miniroot69.img of=/dev/rdisk2 bs=1m > > I put it in the Pi and upon boot it fails with this error message > printed out through serial: > > U-Boot 2021.01 (Apr 16 2021 - 15:39:01 +1000) > > DRAM: 1.9 GiB > RPI 4 Model B (0xb03114) > MMC: mmcnr@7e30: 1, emmc2@7e34: 0 > Loading Environment from FAT... ** No partition table - mmc 0 ** > In:serial > Out: serial > Err: serial > Net: eth0: ethernet@7d58 > PCIe BRCM: link up, 5.0 Gbps x1 (SSC) > starting USB... > Bus xhci_pci: probe failed, error -110 > No working controllers found > Hit any key to stop autoboot: 0 > switch to partitions #0, OK > mmc0 is current device > ** Bad device specification :1 bootfstype ** > "Synchronous Abort" handler, esr 0x9604 > elr: 0009197c lr : 000930c8 (reloc) > elr: 3b36d97c lr : 3b36f0c8 > x0 : 6d63625f646e7320 x1 : 5f656c62 > x2 : 3b3d30a0 x3 : 0001 > x4 : 3afe9fe0 x5 : > x6 : 3b3d30a0 x7 : 3b3d30b0 > x8 : 3afea070 x9 : 0008 > x10: 3b3d07f2 x11: 3af64780 > x12: x13: 0004 > x14: 3af4be58 x15: > x16: 4110 x17: 2285e5950900a046 > x18: 3af57da0 x19: 3afe9940 > x20: 0811 x21: 0811 > x22: x23: > x24: x25: > x26: 0028 x27: 0003 > x28: x29: 3af4bac0 > > Code: 2a1b03e1 97e5 2a0003f8 140d (f8777800) > Resetting CPU ... > > resetting ... > > Any help would be appreciated. > > Rob > > -- Justin Yang
