You need to recapture. Preferably to a new image so that if something goes wrong, you still have the old one.

There is no Software inventory.

Hardware inventory is performed either through the deployment/capture process of a registered machine, or via a dedicated Inventory from the FOG GUI. @george1421 the FOG Client does not perform “hardware inventory” in the level of telling a user what information the machine has. It simply registers an unregistered machine and allows the admins to approve/disapprove machines in a semi-autonomous methodology. (Not that I think you were saying otherwise, just wanted to make sure the information was more clear.)

Software deployment is not the “strong” element of what FOG does. We do have snapins which could potentially be used to install software, but snapins, in and of themselves, are not really a “software deployment utility”. This would be better suited for some other programs out there. Neither is it a patch management system. Again, you could use snapins to do these things, but this was not what snapins were designed for.

Unattended installation is managed particularly by how you want to manage the installation process. FOG, as @george1421 stated, doesn’t care what “state” your reference machine is in. It only captures the current state of the hard drive in a block level format. I would, personally, recommend using Sysprep (in the case of Windows) to generalize the machine before capture. This will allow you the ability to create what we call a “hardware independent” image. This, however, is not a requirement and FOG will happily capture your disk in any state you feel is sufficient for your needs.

Hardware inventory works just like an imaging task in fog works. (At least if you’re meaning what I think you’re meaning.) You create a task (deploy, capture, or inventory). FOG Uses PXE to load the machine from the network. This passes to a bootfile called iPXE. IPXE then handles checking for the task, and if there is one found booting the machine into the FOS (FOG Operation System) to perform the task. This data is stored in the FOG MySQL database linked to the registered host’s identifier.

Hopefully this helps. @george1421 already stated most of this, but I figured I could potentially help a little too!

@agray

static ip address management post install. Not a problem. DHCP is only required if you need to PXE boot into the FOG iPXE menu or for capture/deploy activity. After image deployment the target computer checks-in to the FOG server using the FOG Client service so that is how the FOG server knows about the target computer.

Driver install for single golden image. Its not easy, but not hard either. If you use Dell computers then Dell provides the driver cab files as you need them. You can look over these tutorials: https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed and https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection for guidance. You will need a little linux experience to setup, but its not too hard.

MDT driver less: Yes you can. We will build our golden image using a virtual machine. We use ESXi virtualization, but you could use Hyper-V or VirtualBox to build your golden image. Then capture from that visualized machine. But I do recommend that you install the Dell Win10PE drivers in the Out of box drivers section to make your deployment life a bit easier. These are generic drivers that will allow your target computer to initially get connected to the network and talk to the storage device. There are plenty of how tos out there on how to setup and MDT environment. The deployment research web site is pretty handy too with info.

@Sebastian-Roth Many thanks for this. I should be able to request that the labs can sit common VLANS with no port restrictions between them. I guess this might cause problems with multi-casting but worst case I can have a FOG server on each subnet. I’m going to start testing! thanks

@Tom-Elliott I see, the storage nodes themselves are not meant for capacity but redundancy and throughput? Is mounting a network storage location viable to expand my capacity?

@Wayne-Workman Probably one of the configs were changed and the updater is asking what to do. The best I could find quickly is: https://serverfault.com/questions/259226/automatically-keep-current-version-of-config-files-when-apt-get-install/593640

Try: apt-get update;DEBIAN_FRONTEND=noninteractive apt-get dist-upgrade -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" --force-yes

What a monster of a command…

@Sebastian-Roth
1.
This is a very new idea. Did not have chance to test wimlib yet. Next week will do so for sure.
I have Samba NAS , will try with centos.
2.
Another interesting wim usage scenario:
WIM keeps in the A-image base Windows + B-snaphot with drivers + C-snaphot with sql server.
And you decide what you want to restore after the Base. So for a host1 u have A+B. For host2 A+B+C.
Instead of 3 images you must keep only one image +2 deltas.

Thank you for clarifying this. I strictly use fog for imaging and joining multiple lab computers to the domain. Kudos to all that make this possible.

Thanks James…

@Tom-Elliott Hi Tom the FOGUpdater script fails on the mirrorlist trying to download. Is it possible for me to download the latest version manually and then pass it to the fogupdater.sh

@LycaKnight You are missing the parameter initrd=init.xz (kernel bzImage initrd=init_32.xz ...). I am fairly sure this is causing the kernel panic.

@phil-dosi said in FOG Server Requirements:

the worry comes over the response times with the FOG master

We have worked on improving the response speed in the last weeks and made some progress. It’s more related to master/storage communication but we have reduced that a fair bit so there is more room for client stuff. The fixes are not released officially yet. But I guess your project won’t manifest in the next days anyway. Until then we most probably have the next release out.

@Sebastian-Roth Thanks again, that fixed it 🙂

@dylan You would probably be really interested in this post:
https://forums.fogproject.org/topic/8906/to-sysprep-or-not-that-is-the-question

Though, I haven’t used FOG at work for about 2 years now. I use it at home to create images of my Linux systems - and I do a lot of automated testing with fog. But I’m not doing much imaging anymore as I have no reason to do so.

I actually made some progress on this front. It became a bit more clear when I thought it over and made some considerations.

My setup is such that I have mirrored (via rsync) local repos of CentOS and Fedora. I then symlink the ISO’s within those repos to another place to make them easy for people to download the ISO. In this scenario I don’t have to do anything with the ISO to get the installation files need by PXE as they are available in the repo as I have syncd them.

With the above in mind, I should be able to accomplish the same for any Linux distro that I can mirror/rsync locally which nullifies the needs/goals of my OP.

I then thought about what OS’s this need actually applied to, and in my case it came down to Windows 10 and ESXi (various versions). I don’t mind downloading the ISO manually. What I was looking to accomplish was being able to take an iso or a batch of them in a dir and identify their; OS, version, build, revision and be able to use that to create a unique directory structure for said iso and then dumb the iso contents into the created dir structure for it.

The part I was hung up on was how to get the information I needed for this and that part, at least for Windows 10 (really any Windows ISO) and ESXi I have figured out at least as a proof of concept. I realized that the iso file name would not be the most reliable method of doing so and found ways unique to each OS family to identify the metadata I needed.

ESXi (having checked multiple Dell isos from 6.5-6.7):

I found that they had a /upgrade folder with 2 note worthy files in them. metadata.xml contains the version number and build number. profile.xml has the full name (so even if the file name of the iso is changed this should stay the same) from which I could extract things like the Dell revision and U1/U2 monikers used for Update 1 and Update 2, etc. It also has a tag for “creator” so I should be able to differentiate between Dell isos and non-dell isos.

To parse out the xml I found that xmllint provided by libxml2 would allow me to reliably pull this info from the xml files. Coincidentally, libxml2 was needed by wimlib anyhow (mentioned below for Windows).

Windows 10:

I installed wimlib and using the wiminfo command on the install.wim (combined with grep) I am able to pull information about the ISO as well as deduce if the ISO is a Windows ISO. I can get name, version, build number in this fashion.

I may expand this to Server 2016/2019 if they start releasing new iso builds “frequently” like they do with Windows 10, but older versions the iso hasnt changed for a long time and I have these setup already.

So basically it comes down to checking the ISO’s for the structure/files that match the OS family. In this case /upgrade/metadata.xml being ESXi and /sources/install.wim being Windows. Then I either parse out the XML for ESXi or using wiminfo pull the info from the wim file for Windows.

After that should be “easy”. Create a path using that info, check if it already exists, dump the iso contents, unmount, etc. I am also considering putting a fail safe kind of option in so that if the ISO doesnt match any conditions I am checking to “classify” it, I can prompt the user for manual input if they want to process the ISO allowing them to determine the path to dump it into.

Follow Up Question:

I hadnt considered it before, but generally speaking I assume it would be possible via the bash script to also update or add to the FOG’s iPXE menu by manipulating the “config” file that stores the menu? Or is there a database in between that would make that problematic?

I am not stuck on automating the menu creation but if its a relatively simple addition might as well add it.

Conclusion:

Once I get this written up into a moderately working fashion I intend to post it on my Github and would be happy to share the link back here.

Thanks

@numericOverflow You should research/test what happens if you run the update while the application is installed or not, running or not. Maybe it’s fine.

This is possible if you create your own background .png file. The settings are under Fog Settings-> Fog Configuration-> FOG Boot Settings-> IPXE XXXXX This will allow you to brand the FOG iPXE menu.

The background image file goes into /var/www/html/fog/service/ipxe directory. Use the existing bg.png to get the image size geometry. If I remember correctly there is a maximum background file size supported by iPXE. Refer to the iPXE docs for help on picking custom colors and background images.

FOG is not a backup tool, its a block level image cloning solution. It captures and restores full partitions at the block level. FOG doesn’t have the ability to track changed disk blocks. If you want something like that look into Veeam Backup Agent (free).

As far as I know this has not been attempted before. I know FOG has been installed under docker containers. In theory it should work on freenas jail but I’m pretty sure the installer will not work as the developer intended. You my have to had configure a few things.

Hello guys, just to give feedback to you, everything is working now, but only multicast is not working correctly. The multicast starts normally and deploys the image between the 3 VM´s, but the transmission rate got too low, worse than using unicast mode for the 3 VMs, I’m trying to find some solution on the internet now for my problem, it’s probably some configuration for the internal network in VirtualBox. Anyone have any ideia or know about this ?

@robertkwild In addition to the link posted by @igorpa2 and in addition to this wiki article refered to by @Sebastian-Roth, there is a tool called updateIP.

updateIP was created as a easy to use tool for updating your FOG server’s IP settings after you’ve updated the OS’s IP. I would highly recommend it.