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.
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.
I’ve been looking into automatically adding certain mac addresses from my hosts and I have figured out how to use the API to import the list of macs and store them in the database, with the primary being the last entry.
What I’m looking for is a way to manage the pending macs for cleanup and or to via API accept them so they are no longer pending. API access should also provide access to the “Ignore Mac on Client” and “Ignore Mac on Image” options.
Would this be new or did I miss it somewhere?
I’ve been working on building some snapins and I’m looking at deploying some rather large packages (Adobe CS, Autodesk) and scripts. I think I’m doing pretty well, but I came across a thread from 2017 that peaked my interest.
Executed Snapin Status information in Webinterface
As I’m using Fog snapins to trigger external tools and scripts I thought this would be a really cool idea to have addition feedback along the process. I’ve been trying to look into these calls without much success.
checkin and obtain taskid
http://FOGSERVER/fog/service/snapins.checkin.php?mac=MACADDRESS
then to update status:
http://FOGSERVER/fog/service/snapins.file.php?mac=MACADDRESS&taskid=TASKID&stateid=STATEID
stateid seems to be an interger value, but I can’t find where the conversions to words are located in order to add additional values. Also I can’t seems to change the status using the call as described.
@Sebastian-Roth Any chance you’ve been able to look into these settings? I’m starting to work on creating snapin packages but they don’t seem to work right without being on all servers. So I’ve been manually replicating the files around until this replication interface issue can be resolved.
Wow, I just swapped back to the IP address to replicate a new image tweak, and this time I setup logging on my putty session. I received a flood of 26,000 lines , time stamped across 8 seconds as the Replication service registered the change and came online.
I’ve been working hard upgrading our fog servers to https mode. As we are stuck working from home currently with this Covid-19 quarantine, we have been focusing on our security settings and trying to gain remote functionality where possible.
I’ve made it through many steps, upgrading from Ubuntu 14 with Fog 1.5.7 to Ubuntu 18 with Fog 1.5.8, adding another offsite storage node for image testing, SSL certificate oversize issues, and content filter blocking iPXE using ocsp to verify our public cert.
I think my last problem comes down to the replication service. When the “Fog Configuration -> Fog Settings -> Web Server -> Web Host” is set to the IP address the replication works, however this causes the pxe files to generate with an IP and not the FQDN that matches the SSL Cert. If I change the setting to the FQDN to fix the pxe boot menus, then the replication log gets stuck with this repeating slowly over and over.
[04-21-20 2:28:00 pm] Interface not ready, waiting for it to come up: fogserver.xxx.org
The moment I change the setting back to the IP address the log floods with these interface ready messages for more lines than my putty buffer.
[04-21-20 2:09:03 pm] Interface Ready with IP Address: ntp.xxx.org
[04-21-20 2:09:03 pm] Interface Ready with IP Address: 10.2.xxx.yyy
[04-21-20 2:09:03 pm] Interface Ready with IP Address: 127.0.0.1
[04-21-20 2:09:03 pm] Interface Ready with IP Address: 127.0.1.1
[04-21-20 2:09:03 pm] Interface Ready with IP Address: ntp.xxx.org
[04-21-20 2:09:03 pm] Interface Ready with IP Address: 10.2.xxx.yyy
[04-21-20 2:09:03 pm] Interface Ready with IP Address: 127.0.0.1
[04-21-20 2:09:03 pm] Interface Ready with IP Address: 127.0.1.1
[04-21-20 2:09:03 pm] Interface Ready with IP Address: ntp.xxx.org
Where is the replication service looking to define the nic and how can I fix this?
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"
@quazz said in Not NTFS Partition error 34 during capture:
@john-sartoris That partition should be FAT32.
Not on anything that I have encountered. The EFI partition will be fat32, but the boot has always been NTFS for me. I haven’t gotten into efi much on windows machines.
@quazz said in Not NTFS Partition error 34 during capture:
It’s reporting 2 NTFS partitions. Is this correct with your partition layout?
A default Windows installation will only have one.
If you manually create a full disk partition during the installer, 1 is correct. If you install to a blank disk, the installer will create 2. The first being 100-500mb depending on version. It has been this way since Win7, I think. This small partition is the “Active” boot partition and to the best of my knowledge is used for booting bitlocker encrypted partitions. The primary boot files and some system level things need to remain unencrypted. Fog has specific rules to leave these small partitions basically untouched.
@sebastian-roth said in Not NTFS Partition error 34 during capture:
@John-Sartoris Maybe provide more information on the partition layout. See in
d1.partitionsandd1.minimum.partitionsin the image directory on your server.
d1.minimum.partitions is not in the /images/dev/082… upload folder
d1.partitions
label: dos
label-id: 0x86308630
device: /dev/sda
unit: sectors
/dev/sda1 : start= 2048, size= 1024000, type=7, bootable
/dev/sda2 : start= 1026048, size= 523259904, type=7