@sebastian-roth I was able to test on both an M83 and a 7010. I’ll be doing more widespread testing once we get back after the holidays, but everything seems to be fine!

@hancocza Ah sorry, I thought you’d know how to do that.

Go to the directory where you usually run the installer from, I’ll just use /root/fogproject her in the example but make sure you use what you have on your system extracted already.

cd /root/fogproject/utils/FOGiPXE/ ./buildipxe.sh /etc/ssl/certs/Certs/gd_bundle-g2-g1.crt cd ../../packages/tftp/ find -type f -exec cp -Rfv {} /tftpboot/{} \;

This is partly outlined in the wiki but still needs more consideration: https://wiki.fogproject.org/wiki/index.php?title=HTTPS#Custom_CA_and_certificates

@hancocza said:

maybe you have a better way of doing this?

In your case you better just comment or remove those five lines from the PHP code. The fog-client code is made to check if “url” ($location in the PHP code) is empty and defaults to the values specified in settings.json on the client.

Not sure if there should be a change to use the hostname instead of IP if specified in the .fogsettings file

Using DNS name is adding another layer of complexity and I wouldn’t want to add that as default for every FOG user. You can run FOG without setting up proper DNS and I see this as a good default to not add another hurdle for most of our users. If you want to switch to DNS/hostname you wre welcome to do so.

If there are issues in the code that we need to fix preventing you from using the hostname instead of IP, let us know. Best to open an issue on github and point out where things are going wrong.

@Sebastian-Roth Awesome, thank you!

@Sebastian-Roth that’s good news! I can test it out once it’s wrapped in. I tried what John did, but didn’t have any luck. Also tried following the wiki post on HTTPs/custom certificates that you shared in the other thread, but was still getting the overlength error. I decided to just use the certificate that FOG creates on install instead of my custom one for now.

@hancocza I totally missunderstood this whole topic right from the start. It would have helped a lot of you’d clearly mentioned that you are using a custom SSL certificate. Might be obvious but I did not get it.

So what you describe here has nothing to do with FOG as far as I understand it. The password input stuff is something Ubuntu is doing when you start the apache webserver and you have a password protected private key. We as in the FOG installer does not add anything to that. So my guess is that Ubuntu changed things with one of the latest updates.

Probably you just need to install the correct extra package to make this work again…

Gotchya, I will switch back to that. Thanks Joe!

@hancocza let me remote in and debug the issue. The installer had a bug which prevented it from pinning a server over https if port 80 was blocked. This has been fixed in v0.11.14, which will be released with the next server RC.

@hancocza Most probably your windows PCs have the CA certificate (imported) that was used to sign the other certificates. To be more concrete - the .NET keystore has the right CA cert to verify the other certs. But probably the Mac OS X mono keystore doesn’t!

Edit: Which version of mono did you install and which version of Mac OS X do you use?

All set now, thanks Tom!

@hancocza All the more reason version information is needed everytime. Thanks for letting us know it’s back and running.

@Tom-Elliott Seems to have worked now. Thanks!

Fixed in working version 6 1.5.0

@hancocza Ok, so I got this. I am looking into the building process of the FOG client right now as our client developer is absent right now. I might come up with a description of how to custom build the client (e.g. for custom SSL cert). I am still trying to get things sorted with the building tools. Let’s hope I get this fixed soon.

I agree with George, this is a NFS Port problem.