Re: relayd forward with tls
> Take a look at the example in man relayd.conf. You have to set the X-header
> like:
>
> match header set "X-Forwarded-For" \ value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" \ value
> "$SERVER_ADDR:$SERVER_PORT"
This has nothing to do with relayd's forwarding rules in this topic.
Setting these headers is for logging in httpd.
Because if not set X-Forwarded-For then httpd logs the IP of the relayd
host as source for ALL requests and the original IP of the request would
be lost.
To overcome this httpd comes with a log format called "forwarded" which
appends X-Forwarded-{For,Port} to existing log format.
Re: relayd forward with tls
Em qui., 11 de jan. de 2024 às 13:35, Michael Hekeler escreveu: > > > Jan 9 07:10:24 stable relayd[29792]: relay wwwtls, session 1 (1 active), > > fqdn1, 127.0.0.1 -> 127.0.0.1:8080, done, GET -> 127.0.0.1:8080; > > Jan 9 07:10:25 stable relayd[28442]: relay wwwtls, session 1 (1 active), > > fqdn2, 127.0.0.1 -> 127.0.0.1:8081, done, GET -> 127.0.0.1:8081; > > Jan 9 07:10:31 stable relayd[29792]: relay wwwtls2, session 2 (1 active), > > 0, 127.0.0.1 -> 127.0.0.1:8080, done, GET > > Jan 9 07:10:35 stable relayd[28442]: relay wwwtls2, session 2 (1 active), > > 0, 127.0.0.1 -> 127.0.0.1:8080, done, GET > > Please examine your log: > The first and the second request are processed by "relay wwwtls" > The first is tagged "fqdn1" and the second request is tagged "fqdn2" > The first is relayed to 127.0.0.1:8080 > The second is relayed to 127.0.0.1:8081 > All is fine here :-) > > Now look to the third and fourth requests. > They are both processed by wwwtls2. > But they are not tagged (see tag 0) and thats the problem! > Because the request stays untagged in the protocol the relay wwwtls2 > chooses simply the first found forward rule: 127.0.0.1:8080 > > So examine your requests: > This is fine: 'curl https://fqdn1' > But this not: 'curl https://fqdn1:4430' > > See the difference? > > The second sets in HTTP-Header "[HTTP_HOST] => fqdn1:4430" > Thats why you should match "fqdn1:4430" in relayd.conf: > > match request header "Host" value "fqdn1:4430" tag "fqdn1" > - or - > match request header "Host" value "fqdn1*" tag "fqdn1" > That was exactly the problem. I didn't know how to read the logs nor the definition of HTTP_HOST. Thank you very much! -- Adriano
Re: Partition completely wiped out, why?
On Wed, Jan 10, 2024 at 7:44 PM Jonas Bechtel wrote: > After mounting with right ufstype, I saw right data. (Probably this is > what I remember. Files in root directory looked well there) > > In installation I went to manual disklabel edit. One of the steps there > was to assign the mount point /oldbsd5 there. > I think this is where you went wrong. During installation, when you are asked to edit the disklabel, the installer is going to erase every partition you define in preparation for installing OpenBSD onto your new empty partitions. If you want to keep a portion of the disk untouched (e.g. because it had data from before that you will want to continue to access later) what you need to do is leave that space unallocated, then after OS installation is completed you can edit the disklabel to define the additional partitions. TL;DR - when you are at the disklabel step in the installer, you are not being asked to declare partitions you want to keep, you are being asked to define partitions that you want wiped clean in preparation for your new OS install. -ken
Re: netcup.eu arm64 (kvm, Ampere Altra), bsd.rd hangup
> > > On 12/28/23 12:30, Michael Hekeler wrote: > > > > I try to install OpenBSD on netcup ARM, too... > > > > > I disabled the pluart driver in the ramdisk kernel (on a other machine > > > with > > > config -e -f /bsd.rd and copied the ramdisk kernel over to the nectup > > > server) and got access the the installation script. > > > > How did you disable pluart driver? > I installed OpenBSD on a Hetzner ARM64 system (CAX11) and modified the > ramdisk with > config -e -f /bsd.rd > disable pluart > quit Thanks :-) > > The modification should also be possible on any other ARM64 system (e.g. > Raspberry Pi 4). > > Then I copied the modified bsd.rd and > https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/BOOTAA64.EFI to the EFI > partition (directly under /boot/efi) on the Netcup server. > After that I started the OpenBSD BOOTAA64.EFI directly from the TianoCore > UEFI. > > > Could you provide more info, or share the bsd.rd? > You'll find my modified bsd.rd here: https://download.fusion-zone.net/ thanks again :-)
Re: relayd forward with tls
> Jan 9 07:10:24 stable relayd[29792]: relay wwwtls, session 1 (1 active), > fqdn1, 127.0.0.1 -> 127.0.0.1:8080, done, GET -> 127.0.0.1:8080; > Jan 9 07:10:25 stable relayd[28442]: relay wwwtls, session 1 (1 active), > fqdn2, 127.0.0.1 -> 127.0.0.1:8081, done, GET -> 127.0.0.1:8081; > Jan 9 07:10:31 stable relayd[29792]: relay wwwtls2, session 2 (1 active), 0, > 127.0.0.1 -> 127.0.0.1:8080, done, GET > Jan 9 07:10:35 stable relayd[28442]: relay wwwtls2, session 2 (1 active), 0, > 127.0.0.1 -> 127.0.0.1:8080, done, GET Please examine your log: The first and the second request are processed by "relay wwwtls" The first is tagged "fqdn1" and the second request is tagged "fqdn2" The first is relayed to 127.0.0.1:8080 The second is relayed to 127.0.0.1:8081 All is fine here :-) Now look to the third and fourth requests. They are both processed by wwwtls2. But they are not tagged (see tag 0) and thats the problem! Because the request stays untagged in the protocol the relay wwwtls2 chooses simply the first found forward rule: 127.0.0.1:8080 So examine your requests: This is fine: 'curl https://fqdn1' But this not: 'curl https://fqdn1:4430' See the difference? The second sets in HTTP-Header "[HTTP_HOST] => fqdn1:4430" Thats why you should match "fqdn1:4430" in relayd.conf: match request header "Host" value "fqdn1:4430" tag "fqdn1" - or - match request header "Host" value "fqdn1*" tag "fqdn1"
HUNSN routers - N100 I226-V
Has anyone tried these HUNSN mini pcs/routers with multiple interfaces? I'm thinking of getting one for home routing. Does it work with OpenBSD? (dmesg?) Performance? Will it route/firewall at 1Gbps? Intel N100 seems to be low on TDP and gives numbers. Any problems with I226? I've read about issues with I225 in the past. Thanks, Giannis
Re: Partition completely wiped out, why?
On Thu, Jan 11, 2024 at 02:39:45PM +0100, Jan Stary wrote: > I don't think you rm-rf'd your directory; > I suspect you simply newfs'd a new FS in its place. You can probably answer that question with a good degree of certainty by checking whether it's now FFS1 or FFS2. The old filesystem originally created with OpenBSD 5.x would have likely been FFS1. If the partition has been newfs'd with OpenBSD 7.4, it would have defaulted to creating an FFS2 filesystem. The first line of output from dumpfs will indicate the filesystem type.
Re: cwmrc and environment variables
Hello, On 2024/01/10 11:41:01 +, Ioan Samarul wrote: > Hello to you all! > > I am trying to define mappings in cwmrc for some of my scripts. If I > use the full path (/home/user/bin/someScript) they work as expected, > but if I use something like $HOME/bin/someScript cwm does not > recognize the mapping. > > Is there something else I should do or it is just not possible to use > environment variables? cwm does not replace environment variables. However, the default PATH includes ~/bin so just using `someScript' should work.
Re: Partition completely wiped out, why?
On Jan 11 01:35:20, p...@jbechtel.de wrote: > TL;DR - maybe the reason is some bad interaction between Linux mount > with wrong -o ufstype=old with following BSD auto-fsck on boot? I don't suppose linux's mount of a wrong type or obsd's autofsck would wipe the filesystem clean. > > > What also may be noted is that the ufs magic 0x00011954 (or, > > > 1954 0001, in hexdump switched 2-bytes) was present at position > > > 0x255c and 0x455c and several times at larger offsets. > > > > Could these be copies of the superblock? > > How to find out? Does this help? # scan_ffs -v wd0j man fsck says: -b block# Causes fsck to use the specified block as the location of the superblock. Block 32 is usually an alternate super block. So I'm guessing yes, these are copies of the superblock. > block 32 id 5351628a,266db641 size 900728 > block 6624 id 6581,4040010 size 4 > block 414688 id 5351628a,266db641 size 900728 > block 829344 id 5351628a,266db641 size 900728 > block 1244000 id 5351628a,266db641 size 900728 > block 1255916 id 95be8,c4834800 size 50640872 > block 1658656 id 5351628a,266db641 size 900728 > block 2073312 id 5351628a,266db641 size 900728 > block 2487968 id 5351628a,266db641 size 900728 > block 2902624 id 5351628a,266db641 size 900728 > block 3317280 id 5351628a,266db641 size 900728 > scan_ffs: read: Invalid argument > > Where? Into that same small partition? > > On another disk in that same machine? > > On other partitions on that same disk? > > OK, so here's an overview: > > old MBR table (read from one of the rare backups): >Partition 1 20480s -> 614400s (290MiB) ext2 "bootpart" >Partition 2614400s -> 4333568s (1.8GiB) 0xA6 (OpenBSD) >Partition 3 4333568s -> 2768s (7.5GiB) ext4 "main_system" >Partition 4 2768s -> 20971520s (474MiB) Linux swap > > old disklabel (partition 2 of old MBR table, again from backup): >Partition a614400s -> 4217312s (1.7GiB) type 7 (4.2BSD) >Partition b 4217312s -> 4333565s ( 57MiB) type 1 (swap) >Partition c 0s -> 20971520s ( 10GiB) type 0 (unused) >Partition i 20480s -> 614400s (209MiB) type 17 (unknown) >Partition j 4333568s -> 2768s (7.5GiB) type 17 (unknown) >Partition k 2768s -> 20971520s (474MiB) type 10 (other) To be sure: this is not what a fdisk or disklabel output looks like. So where exactly is this coming from? Also, how did you end up having partitions i, j, k, named like that? Is that what you did in your 5.4 install? > recent MBR table: >Partition 1 0s ->0s0x00 (unused) >Partition 2 0s ->0s0x00 (unused) >Partition 3 0s ->0s0x00 (unused) >Partition 464s -> 20971520s ( 10GiB) 0xA6 (OpenBSD) > > recent disklabel (partition 4) >Partition b 4217312s -> 5628288s 4.2BSD / Surely partition 'a'. Are you typing these by hand? Can you post the actual fdisk and disklabel output? >Partition b 5628288s -> 6152576s swapnone >Partition c 0s -> 20971520s unused >Partition d 17471040s -> 20971520s 4.2BSD /usr >Partition e 6162576s -> 13153248s 4.2BSD /var >Partition f 13153248s -> 17471040s 4.2BSD /home >Partition i 20480s -> 614400s unknown >Partition j614400s -> 4217312s 4.2BSD (/oldbsd5) > > > > assigned a mount point to the old partition, "/oldbsd5", which > > > worked on first boot. I just saw the usual files usr, mnt, ... when > > > invoking "ls /oldbsd5", assumed it was working then. Must have, if you could mount it and ls it. > > To be clear: you installed 7.4 somewhere else > > and just mounted the old small partition from > > the new 7.4 install, seeing the old data. > > Uh-oh, good question. I try to recall. Well, that's what you just said: the old partition being wd0j of the new install, being mountable and listable. Are you sure you didn't simply rewrite it during the 7.4 install? (Being in place, i.e. within the same sectors, but newfs'd empty.) > I tried to mount the partition in Rescue Linux. (not -o ro probably) I When? After you saw it as empty under you new 7.4 install? Why? > guess this "succeeded" but when trying ls /mnt/ I got some error. What error? > This failed because the UFS type selection defaulted wrong. Then I chose the > right UFS type with -o ufstype=44bsd, maybe -o ufstype=44bsd,ro > After mounting with right ufstype, I saw right data. (Probably this is > what I remember. Files in root directory looked well there) Well, could you also do the same from within your new 7.4 install? (Why would you bring another OS into it?) > In installation I went to manual disklabel edit. One of the steps there > was to assign the mount point /oldbsd5 there. Assigning a mount point does not mean the installer will not newfs it; you assign a mount point to the fresh filestystems too ... > > > Automatic
