Problem with HTTPS upgrade

[sbenson]

@tom-elliott said in Problem with HTTPS upgrade:

CERT argument

Oh I am so over this issue i am blindly copying and pasting commands that look correct at first glance. I totally missed the CERT= argument

[sbenson]

Here’s something else I have found now. Deploying an image is going at 127MB/min, where previously it was going at 8GB/min

[Tom Elliott]

@sbenson Maybe a fluke? Mind restarting the fog server see if it helps out a little?

I doubt there’s anything else causing it as the init’s have nothing to do with the network boot process (after iPXE releases the init’s and kernels) which hasn’t changed beyond the change to actually follow the redirects back to the fog server in https mode as required.

[sbenson]

@tom-elliott I will reboot it(its a VM), but I also attempted to register a host and it didn’t work 3 times.
http://www.youtube.com/watch?v=sCV7x1zKBwE

[Tom Elliott]

@sbenson No Viable mac’s to use… hmmmm. I’ll take a quick look for that.

[Tom Elliott]

So the No Viable mac’s to use comes from the host page when it’s attempting to add the primary mac to the host. I know this portion works as I have deregistered and registered multiple hosts even in the latest working tree. Do you have MAC Filters setup that maybe this machine’s mac address is being filtered out before it gets a chance to use it?

[sbenson]

@tom-elliott No, no mac filters setup, this is a new laptop that I have been testing only with fog. I just rebooted the server, and now its going at ~1GB/min

[Tom Elliott]

@sbenson Maybe patch cable is iffy? There’s really loads of variables that can cause speed issues and nothing has been changed in regards to partclone with the exception of hfsplus to patch a 32 bit integer overflow potential. So if it’s going so slow I would say start by checking the network cable, switch it’s connected to, etc…

I don’t know anything else on the server beyond image replication, but that only occurs if you have multiple storage nodes (which I’m just guessing you don’t at this point).

The no suitable mac’s issue might be due to the https switchover, though everything else appears to be working as expected. I know the mac address is “usable” so I’ll see what I can do to try to replicate it.

[sbenson]

@tom-elliott I’ll swap it out for another, it was working fine the last time I imaged a machine. I’ll let you know

[sbenson]

@sbenson Nope still slow

EDIT: New patch, 3 different ports. Could it be because the content wasn’t actually over https previously… Registering still doesn’t work. Though I am still working off of the “Working” trunk. I will try 1.5.0 RC8 tomorrow with the debugging turned off.

[sbenson]

Updates, the fix for enabling https works

./buildIpxe CERT=/var/www/fog/management/other/ca.cert.pem TRUST=/var/www/fog/management/other/ca.cert.pem DEBUG=tls,x509,certstore

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 morning
Fog 1.5.0 RC8 without SSL with ipxe built with CERT
Host registration succeded(PC-45)
Image deploy: 8.25GB/min

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

If you want any more information I can test this all

[sbenson]

@tom-elliott any update?

[Sebastian Roth]

@sbenson I am sorry for taking so long to answer. Other things kept popping up and so I didn’t get to sit down and rework this from scratch. I’ve done it now and pushed a couple of fixes that make the installer do a proper job setting FOG up with SSL. I also added a script that does the iPXE compiling for you. Tom and I are still working on nicely integrating this with the installer.

Not much news for you so far I am afraid. So now I can actually get to what’s bugging you. The speed issue. I’ll look into this fairly soon! Promise!

[Sebastian Roth]

Ok lets try to get this sorted…

@sbenson said:

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.