Solved PXE Boot not working properly from Storage Node
-
Hey guys
When I try to PXE Boot to an Storage Node it works, but the FOG Screen seems broken and deploying etc. doesn’t work. Screen when booted in FOG Menu
For context:
My Master Node is in a different subnet than my storage node, i’ve opened FTP, MySQL, HTTP and HTTPS between those, and replication etc. seems to work.
Thanks in advance for any help!
Edit: Also when trying to execute memdisk the following error comes up:
https://imgur.com/a/zFPAjXz -
@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
- Make sure have set
-
This post is deleted! -
@george1421 said in PXE Boot not working properly from Storage Node:
So the root cause of this:
The fog install script does not honor https for storage node installs?
The fog installer did not provide the necessary command line switches when installing the storage node to enable https?As far as I can tell right now the only issue was that the storage node was not installed with HTTPS enabled in the first place and the buildipxe script in 1.5.7 has a bug that would not compile the cert into the binaries correctly (fixed for 1.5.8 already).
-
@Sebastian-Roth So the root cause of this:
- The fog install script does not honor https for storage node installs?
- The fog installer did not provide the necessary command line switches when installing the storage node to enable https?
-
@Sebastian-Roth Thanks to the both of you, it worked!
Proof: https://imgur.com/a/FiqaZNd
-
@Silv4n No, no need to reinstall apache/php stuff in this case! That part of the installer a left over from earlier. Won’t be asking in the next version anymore.
-
@Sebastian-Roth No problem, you’re helping me. With reinstall apache/php files or not?
-
@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
- Make sure have set
-
-
@Silv4n iPXE errors out and gives you a command line. Please run command
certstat
and post a picture of the output here. -
@Sebastian-Roth Oh, and I can access the file from the browser
-
@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 -
@Sebastian-Roth Ok, in
/tftpboot/default.ipxe
there currently ischain 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 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 (comparels -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 sethttpproto='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.
- Make sure you have the whole CA copied form your master node to your storage node. It’s in
-
@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.
-
@george1421 Alright, I’m gonna test that tomorrow morning or tonight and than I’ll leave feedback here.
-
@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.
-
@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
-
@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…
-
@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