Hi Thomas,
It is not permission problem.
Kiosk doesn't actually download anything when it is redirected:
from
Code: Select all
"http_server=10.20.30.40:80/porteus/520"
to
Code: Select all
"https://my.local.name/porteus/520"
It just logs a request to web server on port 80 (eg. it's request to
Code: Select all
http://10.20.30.40:80/porteus/520/default.jpg
), and when server responds with 301 redirect it moves on to next wget command due to unknown/silent error.
In effect it doesn't even try to access "kiosk.sgn" or "version" as those are in same wget command.
Also, after it logs request to
Code: Select all
http://10.20.30.40:80/porteus/520/xzm/
(folder) it doesn't proceed downloading *.xzm files as it never asks for data at HTTPS/443 and thus there is nothing to parse with rest of the init script.
part #2 - testing busybox wget
I did try unpacking the files next and moving them to test Linux machines.
I actually did tests on Ubuntu and on Porteus Kiosk client itself.
When I try your busybox version of wget from initrdpxe.xzm (without the "-q" flag obviously) I get error:
Code: Select all
./busybox wget https://my.local.name/porteus/520/docs/default.jpg
Connecting to my.local.name (10.20.30.40:443)
SSL_connect failed
wget: error getting response: Connection reset by peer
Likewise if I try to access the initial HTTP with redirect to HTTPS, I do get redirected part ok but SSL error is same:
Code: Select all
./busybox wget 10.20.30.40/porteus/520/docs/default.jpg
Connecting to 10.20.30.40 (10.20.30.40:80)
Connecting to my.local.name (10.20.30.40:443)
SSL_connect failed
wget: error getting response: Connection reset by peer
But if I try the same with normal wget, on same client (this is from your own Porteus Kiosk, so wget build that's being shipped with 5.2.0) I get normal download result:
Code: Select all
wget https://my.local.name/porteus/520/docs/default.jpg
--2021-05-21 13:08:14-- https://my.local.name/porteus/520/docs/default.jpg
Resolving my.local.name... 10.20.30.40
Connecting to my.local.name|10.20.30.40|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1258241 (1.2M) [image/jpeg]
Saving to: 'default.jpg'
default.jpg 100%[========================================================================================================================================>] 1.20M --.-KB/s in 0.09s
2021-05-21 13:08:14 (13.2 MB/s) - 'default.jpg' saved [1258241/1258241]
So HTTPS and permissions are all ok, firewalls, routes, DNS resolving, etc.
But ssl_helper included in PXE script obviously can't work correctly. I tried downloading other HTTPS sites (not local ones, normal websites) and I'd get same error.
Likewise, same error on Ubuntu with your busybox/wget. Example of fail and example of success with normal wget, on ubuntu, and with
www.google.com:
Code: Select all
./busybox wget https://www.google.com
Connecting to www.google.com (172.217.23.100:443)
SSL_connect failed
wget: error getting response: Connection reset by peer
wget https://www.google.com
--2021-05-21 13:46:56-- https://www.google.com/
Resolving www.google.com (www.google.com)... 172.217.23.100, 2a00:1450:4001:830::2004
Connecting to www.google.com (www.google.com)|172.217.23.100|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html’
index.html [ <=> ] 13.06K --.-KB/s in 0.003s
2021-05-21 13:46:57 (4.01 MB/s) - ‘index.html’ saved [13371]
All in all, seems that ssl_helper in initrdpxe.xz is not much of a helper at all
I just wonder how come noone ever tried PXE booting over HTTPS in all these years, I mean, it's not huge security risk in closed environment, but any file can be intercepted and modified by attacker, not to mention if you have some sensitive data in one of the *.xzm modules (eg. you pack a rd.0 script in it with something special or whatever).
I'll see what I can do about creating my own initrdpxe.xz module, if it's just picking up busybox from Ubuntu I could do that, but if it requires recompiling on my own... that's a bit over my Unix knowledge. (Edit: I did try to just copy binary, and as expected - error.)
Edit #2: just tried with
https://busybox.net/downloads/binaries/ ... box-x86_64 ; quick test from client that's already booted = works, and now on to make new initrdpxe.xz
Edit #3: seems I'm stuck till Monday... initrd.xz and initrdpxe.xz don't use same way of compressing as .xzm (I always thought it was just a styling with xzm as m-module). For modules I'd do something like:
Code: Select all
unsquashfs 003-settings.xzm
...
mksquashfs opt/ windows-chrome-update.xzm -comp xz -b 256K -Xbcj x86 -noappend -keep-as-directory
What's the process for .xz? Search brings nothing of value... I tried "unxz" and "xz --decompress" but both create a single file instead tree structure
Edit #4: never give up
Code: Select all
xz --decompress initrdpxe.xz
mkdir uncpio-pxe
cd uncpio-pxe/
cpio -idv < ../initrdpxe
cp ../busybox-x86_64 busybox
find | cpio -H newc -o | xz --check=crc32 --x86 --lzma2 > ../initrdpxe-new.xz
references:
Re: how open & close initrd.xz (Post by brokenman #53718) &&
Re: [SOLVED] Modify Default Files, etc. (Post by fanthom #12193)
Now to try to test remotely
Edit #5: seems that I did manage to create new initrdpxe.xz correctly, but it failed following redirect to HTTPS, when first two files (jpg) failed, I quickly removed redirect and rest of .xzm files were downloaded soon after, but it still faled, probably because it already didn't fetch the kiosk.sgn (same onliner with default.jpg)... now I killed my only test client and I'm trully locked until Monday.
I can only assume that the "busybox-x86_64" I've downloaded requires something else for working SSL, something that was present on Porteus Kiosk 5.2.0 once it fully booted, but not available in init phase...