Posts made by John Sartoris

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?

@hancocza @Sebastian-Roth

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.partitions and d1.minimum.partitions in 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

@tom-elliott

@tom-elliott said in Not NTFS Partition error 34 during capture:

@john-sartoris Way too many pictures with minimal text inbetween makes it hard to follow.

Sorry about that. I figured that would be the best way to capture the sequence of output from fog. The actual problem isn’t giving much information. Hopefully something else inline would stand out to someone with more detailed experience.

If I change the image settings to “Multiple partition image - single disk (not resizable) -(2)”, the upload proceeds. This tells me the problem is with the partition resize.

This might present me a problem. Previous years we had 500g-1tb spinning drives, this year we switched to 250g ssd drives. The reported device size in Partclone is 267.9g.

I swapped back to zstd compression and 200m split. The capture failed out with this. Trying again with gzip.

edit: Missed the image

@sebastian-roth said in Not NTFS Partition error 34 during capture:

Maybe try scheduling a debug upload task and when you get to the terminal run fixparts /dev/sda2 and answer y(es), w(rite), y(es). After that start the upload process by issuing fog command. Please see if things changed.

I didn’t get time yesterday to focus on this. Here’s the output I received.

I’m not sure this procedure is correct. /dev/sda2 being a partition shouldn’t have a partition table…

I rolled back to the snapshot and ran again with “fixparts /dev/sda” and received no warnings, did a write anyway. Reran the “fog” the process again even though there were no changes. I watched closer all the lines that go by, and notices a few of interest.

It finds and identifies 2 NTFS partitions. Ntfs resize happens without error. Problem only appears with the actual partclone capture.

Clearing the ntfs flag … Failed???

This is just before fog saves the new partition layout and starts the partclone captures.

@sebastian-roth
I was trying your suggestion about “fast startup”. I had skip double checking that option, as I said because disabling hibernate is supposed to disable “fast startup”, and that the extra cad software specifically asks to disable it.

Yes, I still get the run list overlap, but that is following the not ntfs partition and reboot, the system pxe boots back to fog and doesn’t start uploading at all just straight to “run list overlap”.

As for my my process and error messages regarding this image, I’ll try to line that out here. This is going to start back from the previous image. I build my images in vmware on an ESXi server and take heavy advantage of snapshots to rollback to useful points.

1.  (July 2016) finish windows updates
2.  (July 2016) snapshot point 1
3.  (July 2016) delete active install user profile
4.  (July 2016) run windows disk cleanup
5.  (July 2016) run sysprep script - run as admin
	5a.(script)  purge temp files
	5b.(script)  stop fog service
	5c.(script)  purge log files
	5d.(script)  purge cleanup cache files
	5e.(script)  remove default user profile to force use of network default
	5f.(script)  clear wsus ids from registry
	5g.(script)  clear hklm\system\setup\upgrade key for tracking upgrade history
	5h.(script)  clear regkey of any autologon remnants 
	5i.(script)  revert some regkeys to default from Group Policy settings
	5j.(script)  rearm office 2016 install (fix duplicate keys in KMS and WSUS)
	5k.(script)  start "sysprep /generalize /oobe /quit /unattend:unattend.xml"
6. (July 2016) run "shutdown -s -t 0 -f" manually
7. (July 2016) capture fog image(upload successfully as 2016Base-R2.0)
8. (July 2016) rollback to snapshot point 1
9. (July 2016) clone VM fork to PLTW image
10. (July 2016) install extra cad software
11.  (July 2016) snapshot point PLTW2
12.  (July 2016) delete active install user profile
13. (July 2016) repeat steps 3-6
14. (July 2016) capture fog image(upload successfully as 2016PLTW-R2.0)

Jump forward to Dec 2016

Base Update - R2.1

15. rollback base to snapshot point 1
16. update avast av to version 1609
17. update java
18. update other base software
19. disable windows "DiagTrack" service
20. cleanup other reg keys for updated policy settings
21. snapshot point Base2
22. repeat steps 3-6
23. capture fog image(upload successfully as 2016Base-R2.1)

Jump to (Now) July 2017

Base Update - R2.2

24. roleback to Base2
25. windows updates
26. windows upgrade via Windows update to 1703
27. update base software
28. update Adobe Suite to 2017 versions
29. install HP HBMA driver (virtual mac address for docks)
30. snapshot Base3
31. repeat steps 3-6
32. capture fog image(upload successfully as 2017Base-R2.2)

PLTW update - R2.2 Skip R2.1 to match base version

33. roll back to snapshot point PLTW2
34. update avast av to version 1609
35. windows updates
36. windows upgrade via Windows update to 1703
37. windows updates
38. update cad software
39. update base software
40. snapshot PLTW3
41. repeat steps 3-6
42. capture fog image(upload fails as 2017PLTW-R2.2)
	42a. partclone uploads sda1 - no error
	42b. partclone errors sda2 - not ntfs partition
	42c. partclone exits to console - error "disk space is good to go"
	42d. computer reboots in 1 minute
	42e. pxe boot - fog picks up the process again
	42f. fog errors with "run list" before starting partclone.

@sebastian-roth
Tried it, and failed. I was hopeful. The box was checked even thought hibernate was off, and the extra software specifically asked to disable it…

@quazz

Like I said though, if I use a different VM to capture/backup into this “image” definition, it is successful. I can try lowering the compression to 9 and try again. I also started this image testing out the new ZSTD compression and it did not work so I switch to setting that worked (max compression, gzip). (Very impressed by the numbers, hoped it would work)

Forgot to mention that I tried running “chkdsk /f”. Reboot, checks, doesn’t report errors, still has same problem with the backup.

Operating System = Windows 10 - (9)
Image Type = Single Disk - Resizable - (1)
Partition = Everything - (1)
Comp = 21
protect = no
enabled = yes
replicate = yes
Image Manager = Partclone Gzip

If I assign my “base” vm to this image and capture it does so successfully. So I am not expecting this to be a fog server related issue.

Server

• FOG Version: 1.4.4
• OS: Ubuntu 14.04.5 LTS

Description

I’m trying to capture my second Windows 10 Creators 1703 image and I’m running into different problems than last time. I’ve experienced the shutdown tweak to sysprep with my previous image. I still think that is strange that sysprep can’t shutdown directly.

So my current problem, I forked an imaged from my previous working image so that I could add approx 100gb of extra CAD software. Then I went through the same sysprep process that worked before and with the forked image I am getting an error from Partclone, “ntfsclone-ng.c: NOT NTFS partition, ntfs mount error 34”.

I’ve gone back to my my previous image from before the fork to test the fog server and this “base” image still uploads successfully. After that it drops back to console and says “ensure disk space is good to go”. Server has 175gb free, image has 108gb used. Even uncompressed I should have plenty of space.

On subsequent reboots it reports with a different message. I figure this is because the system is in a broken state following the failed upload.

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.

@MRCUR said:

@John-Sartoris I would try those commands again while in audit mode. They 100% work for me on Enterprise 1511 (latest update, build 11586.104 I think?) while in audit mode using the built in admin account. You’ll see a bunch of failures for apps that cannot be removed (like Edge), but it still works. The Start menu should be pretty much empty once they’re run.

The commands worked, but I think I was removing something that I shouldn’t have. Initially I started removing the modern apps because of the “was installed for a user, but not provisioned for all users. This package will not function properly in the sysprep image.” error. I think it started as “Microsoft.WindowsCamera” but I don’t have notes of that. Then it moved on to “NET-Framework-Core” I think. And at some point I removed “Microsoft.WindowsStore”, then it really wasn’t happy.

Anyway, I now have an image that sysprep, captures and restores. I’m ok having the stock apps available for now. I expect to find a way to remove/block unwanted ones with group policy or some other tool. If not I’ll make another revision of the image. I’ve still got plenty of testing and experimentation before our mass roll out to the majority of our 1300+ hosts.