I’m a Docker/Compose newb myself, but I’m willing to help with testing. Maybe even container image creation if necessary. I’ve never made a container image before. Perhaps this would be a good time for me to pick up a new skill?

@Sebastian-Roth I wanted to put my 2 cents on generating barcodes for individual hosts. It’s definitely possible to add a barcode feature for each host, which could be printed using a Zebra label maker and stuck on the PCs.

@tcthorne If you want to switch over to the 1.5.9 dev branch I can give you instructions. That will take your fog build to 1.5.9.115 or later. The dev branch also contains fixes for single disk resizable function with windows 20H2 and later OS’

@jj-fullmer said in Secure Boot Support for Windows 11:
“As long as your CPU supports TPM 1.2 you can do a clean install of windows 11, you just can’t in-place upgrade (without a registry change).”

Is it possible to share the registry change? Unless something even better has changed, I am thinking of in-place windows 10 21H2 to 11 in a dual-boot ubuntu environment. I figure this would stop me from having to reinstall Ubuntu (or grub repair).

@Sebastian-Roth as well as all the others ( @developers @moderators @testers )

Would we want anything besides kernel information? I had some ideas:

Number of hosts
Number of images
Number of each type of image
Number of systems imaged in the last 7 days
Number of storage nodes
Number of storage groups
Other things?

It’s been said before, but will say it again. This is all anonymous data. There is no way to correlate this data back to any system.

It just provides us insight (and possibly bragging rights). imagine us being able to say “FOG imaged a bazillion systems last week, we’re proud of that” or maybe “FOG assists with managing a quadrillion million computer systems every day”. I’m being funny with the imaginary figures here, but you get the idea. It’d be nice to make statements like that on the home page fogproject.org

@dashwell The files are init.xz (64 bit CPU) and init_32.xz (32 bit CPU). Download those and move them into /var/www/html/fog/service/ipxe in your FOG server. Rename the existing files instead of overwriting them.

@dashwell Normally you would delete the file before capture in our source OS. But I know sometimes you just need to edit / remove one file from the target system.

You can do what you want with a FOG post install script. I have a tutorial on how to inject drivers into a target windows system that you can use as the basis. Start by reading this: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

The only scripts you will need to start with is fog.custominstall

In this section of the code you will need to change it for your purposes.

debugPause . ${postdownpath}fog.copydrivers # . ${postdownpath}fog.updateunattend umount /ntfs ;;

Lets change it to

debugPause . ${postdownpath}fog.nukemyfile # . ${postdownpath}fog.updateunattend umount /ntfs ;;

Now that above script will connect the C drive on the target computer disk to the /ntfs directory. The thing you have to remember is the FOG Post install script runs under linux and not a windows batch file. So there are some pain points you must remember. The first is the directory paths are forward slash ( / ) and not a backslash ( \ ). Second linux is case sensitive. So lets say you want to edit the unattend.xml file you would reference that file as /ntfs/Windows/Panther/Unattend.xml Note the path and case matching.

So now you will need to create a file called fog.nukemyfile in the /images/postdownloadscripts directory on the fog server. Hint: If you first create the file on a windows box use notepad++ not windows notepad. You will save some headaches later.

In that fog.nukemyfile file put the following.

#!/bin/bash rm "/ntfs/apps/broadcom/config.ini"

Assuming you wanted to remove the config.ini file in c:\apps\broadcom directory.

The last bit from the tutorial you will need to hook the fog.custominstall script into the fog.postdownload script as mentioned.

Hello,

I am using fog to manage a data center deployment consisting of over 1000 servers.

I am replying here as the UX feedback provided by @GeorgeBells here perfectly sums up issues I’ve been having as well.

If a feature request / ‘fix’ per details referenced above is NOT possible or planned, then I sincerely urge the dev team to consider allowing users to assign Snapins directly to images.

All of my equipment is of a similar spec, and the image I flash to them contains pre-configured FOG client as well as auto-setup scripts to configure UUID-based values on first boot.
All of my “snapins” are entirely image-specific by design.

I would like to quick register all new equipment, immediately flash the same specific image, and then deploy the same snapin every time.

Yes, this is true, I could do that but it won’t change anything the way the “Image Managament” page looks. I was thinking about the ability to browse through folders and display the content rather than displaying all the images. (I know there is the searching field but it’s not exactly the same)
We could imagine a tree on the left side of the panel and browse through categories like an explorer if you prefer.

Well, that was just an idea and the way it works at the moment suits my needs but I thought it could bring a little something.

Cheers.

@astrugatch We are booting and imaging over the internet.

@junkhacker

Thank you

@george1421

By and large I agree with you about the hash algorithm being irrelevant, however, some entities have requirements for minimum acceptable hashing for such kind of verification. I think a baseline of a choice between md5 and shasum baseline is fine, especially while development of the feature is ongoing (md5 is still widely used in forensics), however that will not always be the case and building support in for additional options might be better. The time cost involved is something the end user should accept when they select the additional complexity.

Just as a test, I timed sha 512 on my Windows 10 image. Here is the results:

d0715180-198f-4f02-93d6-a638d573b1e9-image.png

Took about 2m 8s for 8 GB give or take. So the wait isn’t terrible at higher algorithm complexity. This test was done with a two virtual processor VM on a server with a bunch of other vms running.

Interestingly enough, the shasum utility on ubuntu can compare hashes to a text file for verification.

4e873e2c-fd44-4f6e-b026-0462cccbd356-image.png

Also, I don’t think the hash need be taken inline with the imaging process, but be done post imaging, either on demand, or run in background automatically before image is made available for distribution.

Thoughts?

@Quazz While I do understand the good intend in this I think it’s very hard to maintain. We see enough issues with trying to make it work in the different distros. Adding the Stream PHP versions will be a nightmare I reckon.

@vdbmartial Persistent groups plugin is your answer. This is where you create a host template and then apply that template to the host during registration. Then when you deploy an snapin, printer, or setting applied to the template host, that will get applied to the target computer before imaging.

There currently is a bug in the process that we are working through here: https://forums.fogproject.org/topic/15084/persistent-groups-snapins-added-to-host-but-not-deployed

@sebastian-roth Ok thanks

@george1421 Thanks for the input!

I’m not looking to specifically put F2B in; I am putting in code to log to a file login failures and successes, then the SysAdmin can choose to setup a F2B jail based on that. I believe heavily in separation of responsibilities, so I will definitely look into writing a proper tutorial.

Do you think code for simply logging the login attempts would get merged?