Problem with HTTPS upgrade

Sebastian Roth

Ok lets try to get this sorted…

Let me just give you a rundown of everything that happened.
Yesterday
Fog 1.5.0 RC7 With SSL with ipxe built with CERT and DEBUG
Image deploy: 1GB/min(Slow)
Host registration fails

This is not nice but I can’t see the connection between either RC version or SSL iPXE to a slower deploy speed (which is simply a point of NFS or udp-cast if you do multicast). I’ve just done capture and deploy test (1.5.0 RC8) in my VM environment (SSL iPXE) and I get around 4-5 GB/min which I think is ok as all the VMs are running on a lenovo laptop - no server hardware or anything.

This morning
Fog 1.5.0 RC8 without SSL with ipxe built with CERT
Host registration succeded(PC-45)
Image deploy: 8.25GB/min

Fine, that’s good.

Fog 1.5.0 RC8 With SSL with ipxe built with CERT
registration detection fails(doesn’t see that it is PC-45)
Host registration fails
attempting to deploy and it takes the username/pass and just drops me back to fog

Yeah, sorry for that, we are still missing the HTTPS URL scheme in some places. But we’re getting there. You can download a patched version of the init.xz file here for now (SSL only!!!). But keep in mind that you need to put in that init.xz again after re-running the installer. Sorry for the inconvenience!

I’ll talk to @Tom-Elliott to add the fixes in the near future. The curl following redirects does not work as intended. See the manpage:

              When  curl follows a redirect and the request is not a plain GET
              (for example POST or PUT), it will do the following request with
              a GET if the HTTP response was 301, 302, or 303. If the response
              code was any other 3xx code, curl  will  re-send  the  following
              request using the same unmodified method.

              You  can  tell  curl to not change the non-GET request method to
              GET after a 30x response by  using  the  dedicated  options  for
              that: --post301, --post302 and -post303.

Sure we could add the --post302 option as well but I’d think we better make all those URLs https:// instead of relying on the redirect (which costs an extra round trip anyway!).

Sebastian Roth

Marking this solved now as I have tested it and there hasn’t been any negative response to this so far.

Sebastian Roth

I know this is an old topic but as a friend of mine asked me about HTTPS in FOG recently I felt that I could update this thread again.

If you run the installer with --force-https you need to run another script afterwards to build the iPXE binaries and include your SSL certificates.

cd /path/to/fogproject_gitrepo/bin
./installfog.sh --force-https
...
cd ../utils/FOGiPXE
./buildipxe.sh
...

FritzBox360

Hi,

is there an update?

i just installed a fresh Ubuntu 18.04.1 LTS and installed Fog 1.5.5 from git. I tried to configure it with SSL so i run the installer with --force-https, --recreate-CA and --recreate-keys and run into the error boot.php could not be found by the ipxe boot. Browsing with a browser works, after accepting the certificate. After a bit of google i found this thread here. So i tried to Re-buildIPXE as provided here in both ways without any luck.

As this thread from 2017 i not sure if it is still recommended?!

Sebastian Roth

@FritzBox360 The build script should re-run the installer after the binaries are compiled to install those to /tftpboot correctly. Did that happen? Any errors you got from the build script?

FritzBox360

@Sebastian-Roth yes, the istaller did rerun without a problem. After sone tests i copied the files from the /fogproject/ folder manualy. Same result!

There were no build errors running the script.

For now i edited the default.kpxe (not sure about the right file name by now) and removed the „s“ from the https connection to try normal http. Then i found the apache rewrite rule - after changing it and removing the rewrite, it woked! Sure, there is no „security“ by now but i know that the ipxe files are good and the chainboot is working.

On monday i will to look deeper in the rewrite rules, because the boot.php could not be found. Could be a certificate error but i am not sure if the ipxe error output should be different then. Could also be a broken link, but therefor it looks right.

Not sure where is the problem by now.

Sebastian Roth

@FritzBox360 Thinking more about this I had an idea. We had a special case with Ubuntu handling redirects differently. This was about the API but I can imagine this also causing what you see here: https://github.com/FOGProject/fogproject/issues/263

On the other hand I added a fix for that which should be in version 1.5.5 already. So maybe I am on the wrong track. Still take a look at the issue because there might be valuable information and commands like apachectl -S to track down the issue.

Please let us know if this is something we can fix in the code.

FritzBox360

@Sebastian-Roth thank you for the reply and thanks for the link. I checked it with the apachectl -S but i am running only the two fog hosts - so it is okay. There is no apache default site availibe.

But i am on a new track now:

As you can see here there should be some cmds to check for certificates e.g. certstat - if this option is set in the general.h file. So i got the idea to check if sth. is availible.

After running into the error posted here i can press “s” for the ipxe shell - now i should be able to run the ipxe cmds (i think?!) but they are not availibe e.g. certstat “not found” - so i am not sure if the compiling is right here. Maybe we are missing the https, also selectable in general.h, or/and the whole certification instances.

I am very new to this compiling topic but i am trying to get into it - maybe you can help here or you got an idea to check for enabled modules in ipxe. thx.

Sebastian Roth

@FritzBox360 Take a look at the github repo to find our current iPXE header files we use to compile the binaries - legacy BIOS and UEFI. As far as I can see both HTTPS protocoll and cert* commands are enabled.

I might try a HTTPS enabled ubuntu install tonight to see if I can figure out what’s wrong. No promise though. Not sure if I find the time.

Sebastian Roth

@FritzBox360 Just did a fresh clean test install Ubuntu 18.04.1 server. Installed FOG and build iPXE binaries:

cd fogproject/bin
./installfog.sh --force-https --recreate-CA --recreate-keys
...
cd ../utils/FOGiPXE/
./buildipxe.sh
...

Make sure you let it run the installer at the end or copy the binaries by hand.

This was tested in a virtualbox test environment with legacy BIOS boot as vbox doesn’t support UEFI PXE boot, at least not the version I have. So UEFI could be different, though I don’t expect it to be.

FritzBox360

@Sebastian-Roth thanks for your time I did the same with the same error … Fresh installation of ubuntu with a fresh fog server. I will try it again on other hardware and another setup later this week.

Sebastian Roth

@FritzBox360 Please grep the logs (especially the compile stuff) and post here. I suppose there is something wrong with this.

Do you use git pull to get the repository or do you download the ZIP archive from github?

FritzBox360

@Sebastian-Roth okay, here is what i tried:

Freh install of ubuntu-18.04.1.0-live-server-amd64.iso in VMware. After the server is ready i did this.

sudo -i
apt update
apt upgrade
reboot

sudo -i
cd /root
git clone https://github.com/FOGProject/fogproject.git
cd fogproject/bin
./installfog.sh -C -K -S


cd ..
cd utils/FOGiPXE/
./buildipxe.sh

fog_error_1.5.5.log --> here
foginstall.log --> here
build.log --> here

Looks fine for me - but did not work. I will try it another setup later.

Edit: I am unable to upload my logfiles here - if i select a file for upload nothing happens - so i used pastebin, hope that is okay. Using CodeBlocks in the forum was to big.

Sebastian Roth

@FritzBox360 Great you posted all the logs. Definitely helpful here I reckon. In the install log I see that you install FOG without DHCP. So I suppose you have a DHCP server running in your network that provides PXE boot information (aka DHCP option 66 and 67). What kind of DHCP is this? Which boot file name does it point to? And which server? Does it point to the FOG server as PXE TFTP server or a different machine?

The install and build logs seem all fine.

FritzBox360

@Sebastian-Roth thank you for pointing me at the DHCP! I found the problem! All files are fine, but our company DHCP was not! After trying it in a seperated VMware Network it worked like a charm! So all the effort was in vain - i am sorry

We have an old fog running 1.4.4 in our DHCP config for managing the PXE Menu because we are running multiple (i)PXE Services in one subnet. I created a new boot menu item to forward the pxe boot to the new fog server.

like this:

iseq ${net0/mac} a0:36:9f:bd:XX:XX && goto testing ||
:testing
set pxeserver:ipv4 FOG-IP
set next-server ${pxeserver}
chain tftp://FOG-IP/default.ipxe
exit

Got it from here in 2017: https://forums.fogproject.org/topic/9648/add-a-second-pxe-boot-option

Worked fine, until now … And by now, i understand why no certification cmds were availibe because it got stuck in the old fog enviroment. Need sth. to reload the enviroment i think. I will take a look into it to find a way. Maybe i will open a new topic here!

Thank you @Sebastian-Roth for taking the time! Your scrips are fine - it was my fault …

Problem with HTTPS upgrade

206

11.6k

17.1k

154.6k