PXE Boot not working properly from Storage Node

[george1421]

@Silv4n This is an interesting problem. I think we will need to ping the @developers on this one. I’m pretty sure we can just copy over the apache stuff from the master node to the storage node to enable https, on the storage node. The issue is telling the storage node to use https in its scripting vs http.

[Silv4n]

@george1421 I’m gonna assume, that I can’t just change the boot.php file from the remote site to use https, right?

[george1421]

@Silv4n There is a setting some place where it defines which protocol to use. There is a text based config file in the fog www directory.

[george1421]

@george1421 It would be interesting if you copied over the apache certificates from the master node to the storage node as well as the apache configuration required to make the storage node https compatible. THEN in the storage node configuration there is a web url setting where we need to add in https.

This is just me thinking without any input from the developers.

[Silv4n]

@george1421 Hmm, okay thanks for your input, I guess I’ll wait till the devs can confirm this, before breaking the storage node or something, because the sync for example works without any issues.

[Silv4n]

@george1421 Nvm, I’m gonna try

[george1421]

@Silv4n said in PXE Boot not working properly from Storage Node:

Nvm, I’m gonna try

That was my thought, it already doesn’t work. How bad could you make it?

[Silv4n]

@george1421 I haven’t copied the certs over yet, because there were already certs on the server, but now this error appears in the apache log, I’m not sure if copying over solves that:
http://prntscr.com/r4nmiu

[george1421]

@Silv4n Your link only contains an ugly picture of the US president in the ad. Please do scare me like that this early in the morning. I’m a USA citizen I see enough of that here…

[Silv4n]

@george1421 Based on cookies i guess ;), for me it shows the screenshot, but im gonna copy it here instead:

[Wed Feb 19 15:43:44.859522 2020] [ssl:emerg] [pid 16345] AH02565: Certificate and private key 10.144.1.22:443:0 from /var/www/fog/management/other/ssl/srvpublic.crt and /opt/fog/snapins/ssl/.srvprivate.key do not match

[george1421]

@Silv4n I would save those existing keys off to the side and then copy the keys over from the main fog server. This is not ‘technically’ the right way, but we just need to see it work right now.

The right way would be to build new keys for the storage node using the root CA created on the master FOG node.

[Silv4n]

@george1421 Alright, I’m gonna test that tomorrow morning or tonight and than I’ll leave feedback here.

[Silv4n]

@george1421 Alright, I’ve copied over the

/opt/fog/snapins/ssl/.srvprivate.key

And the apache service started now and after a reinstall with HTTPS (which worked now without an issues) I can access the Web GUI of the Storage Node via HTTPS. It also generated a new boot file etc. However, the PXE Boot still throws the chainloading error, when trying to actually boot in to something. It also tries to connect there still with HTTP.

[Sebastian Roth]

@Silv4n said in PXE Boot not working properly from Storage Node:

It also tries to connect there still with HTTP

Edit /tftpboot/default.ipxe on the storage node and adjust the URL in the last line.

Though there is another thing that you need to fix I’d guess. I haven’t done a HTTPS enabled storage node setup in a while. But I’d think your iPXE binaries on the storage node do not include the correct cert yet.

As there was an issue in the build script of FOG 1.5.7 I’d suggest you do the following on your storage node:

• Make sure you have the whole CA copied form your master node to your storage node. It’s in /opt/fog/snapins/ssl/CA/ and includes hidden files, so make sure you grab all of it. Put that in the same location on the storage node and make sure ownership and rights are set exactly as they were before (compare ls -al output).
• Grab the iPXE build script from the latest FOG project development code branch and rebuild the iPXE binaries to include your CA cert:

sudo su -
cd /path/to/your/fogproject-source-dir/
cd utils/FOGiPXE
wget -O buildipxe.sh https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/utils/FOGiPXE/buildipxe.sh
chmod +x buildipxe.sh
./buildipxe.sh

• Keep an eye on this to be sure it doesn’t end with an error. Then copy the new binaries over to the destination:

cd ../../packages/tftp/
mkdir /tftpboot/arm64-efi
mkdir /tftpboot/10secdelay/arm64-efi
mkdir /tftpboot/10secdelay/i386-efi
find -type f -exec cp -Rfv {} /tftpboot/{} \;

• Make sure you edit /opt/fog/.fogproject and set httpproto='https' for when you re-run the FOG installer in the future.

I know this might seem overly complicated but from my point of view those steps are best suited in your current situation of half HTTP/HTTPS.

[Silv4n]

@Sebastian-Roth Ok, in /tftpboot/default.ipxe there currently is chain https://10.144.1.22/fog/service/ipxe/boot.php##params, so there is already https. Im’m gonna try now the cert gen etc.

[Silv4n]

@Sebastian-Roth So I’ve generated the new certs etc. and now I have a new error message (Permission denied):
https://imgur.com/a/yK4TwNZ

[Silv4n]

@Sebastian-Roth Oh, and I can access the file from the browser

[Sebastian Roth]

@Silv4n iPXE errors out and gives you a command line. Please run command certstat and post a picture of the output here.

[Silv4n]

@Sebastian-Roth https://imgur.com/a/YpoaNPz

[Sebastian Roth]

@Silv4n Oh well, I should have read the whole topic more closely and think about it a bit more. Copying the certs for Apache from the master server over will cause trouble because it’s got the wrong IP/DNS name in it.

In this case I’d suggest you re-run the installer on the storage node and tell it to recreate the Apache cert and key.

• Make sure have set httpproto='https' in /opt/fog/.fogproject!
• Run the installer like this: ./installfog.sh --recreate-keys