I’ve tried to disable NFSv4 as per http://andy.delcambre.com/2007/06/25/disabling-nfsv4-on-ubuntu.html and the comments in “/etc/default/nfs-kernel-server” however the problem still exists.
Just wanted to say I really appreciate all the help you have both been.
I’m out for the day. I’ll pick this up again in the morning.
I’ve been trying to find someone saying that, and I couldn’t find it. In the past I remember reading that it wasn’t even needed for 7, but I can’t find that anymore.
As for any reason I know it might be needed, is just regenerating some of the unique install IDs. The machine ID and a few other locations are used for tracking in WSUS and Windows KMS Server. I have however seen that these were not even being regenerated by my last few rounds of Win7 syspreps. Sure I have “skip rearm” set. I don’t remember why but I do remember it being needed/suggested somewhere.
I’ve had to manually rearm and regenerate quite a few hosts this last year in efforts to keep my kms server active. Fortunately it’s as simple as 2 bat files and I only need to get 30ish to have a safety margin beyond the 25 threshold.
If I could run these automatically on deploy, or maybe better would be to alter my pre-sysprep cleanup to run it and as you suggest skip sysprep.
I’ll run some tests. Still curious what went wrong and why “CloudExperienceHostBroker” is causing trouble.
Our new HP Elitebook x360 laptops have a feature in the bios and a Windows driver for HBMA. Host based mac address. This allows the system to override the include Nic Dongle, or the HP thunderbolt docking stations mac address with one that is unique to the machine.
So far I haven’t seen this “supported” in the fog linux kernel so, I’m planning to use quick deploy and have the windows agent phone home for inventory and naming.
I’ve been taking advantage of the current quarantine situation to do some needed updates to our fog servers, and found myself in the same setup. After a few other things I’ve been trying to enable HTTPS with fog using a godaddy wildcard SSL cert.
The comment about 4kb max cert is what got me to my final solution. The cert file I was using was a copy from our other apache servers and was 8kb. Clearly this is larger than 4kb. What found was that my cert had been combined with the gd_bundle-g2-g1.crt as per instructions for other hardware setups.
Turns out this isn’t required for the setup here with Apache, Fog, and iPXE. I stripped my cert file back to the original from the download zip and configured apache to run with the following lines. This shrank my cert under 4kb and allowed iPXE to work.
SSLProtocol all -SSLv3 -SSLv2
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA2
SSLHonorCipherOrder On
SSLCertificateFile "/etc/gdssl/wildcard.solo.crt"
SSLCertificateKeyFile "/etc/gdssl/cert_key_nopass.pem"
SSLCACertificateFile "/etc/gdssl/gdig2.crt.pem"
I’ve updated to 1.5.9-RC1 after a bit of work, I think I’ve gotten everything working now.
I have my Public signed wildcard cert working.
I’ve got ipxe configured to Trust the godaddy root cert. This was important as our content filter was again blocking what I think to be the validation attempts. This time it was not showing up as OCSP, but simple “web-browsing”.
edited /tftpboot/default.ipxe to use hostname, and added parameter to change screen resolution. Some of our newest machines have 4k monitors that make the menu tiny.
And lastly, Replication services, Image and Snapin, both are working. It final magic seems that the Replication services use “Fog Configuration -> Fog Settings -> Web Server -> Web Host” and cross reference it to the StorageNode names. It then takes the IP address and Interface configuration from there to determine if the nic is “UP”. It seems DNS resolution is not done on the IP address field here. I had the names and not the actual IP addresses. After setting “Web Host” to the FQDN, and adjusting the StorageNode name to match, and setting the StorageNode IP to the ip, and finally restarting the replication services, things started to all work. Sorry, that one was wordy.
@Sebastian-Roth Thanks for your help. I’ll post new topics if I find anything 1.5.9-RC1 related.