I have created a Python script for Linux* called fog-inventory that you can use to update a Linux system’s inventory information in FOG. You can run it on a live system, or upload data from a JSON file. It’s a command-line utility that makes use of the FOG API system.

It’s intended to provide an alternative to booting a system to FOS in order to run the explicit inventory collection. Our local experience has been that no one ever does that, so the FOG inventory data slowly goes stale. This script can be run out of cron, at system startup, or even run in batch to update hosts by hand (if desired).

The release is on GitHub and includes documentation.

*You could also run this on Windows, though I’ve not done any testing there. It won’t be able to collect live inventory, but you should be able to use it to fetch inventory data to a file for editing, and to upload data from a file.

I write technical documentation for a living. I can help out with some of the documentation work and am somewhat motivated to document the API.

@sebastian-roth as you suspected, this ISO image did boot both legacy and EFI. Which has been a boon.

I have used this ISO four times this week, and it has been a huge time-saver.

@george1421 There are no error messages in the logs, helpful or otherwise.

I verified permissions on the ipxe directory. They are owned by the fog user, and for good measure I have them group-writable by www-data which is what the web server runs under.

@george1421 Yes, proxy settings are correct. I do get the list of FOG kernels to choose from and can see the proxy traffic. I also see the proxy traffic when downloading a kernel. It just never gets installed.

I did find the list of kernels here:

https://fogproject.org/kernels/

But would still like downloads to work via the UI.

I am trying to do a manual update of the kernel from the FOG Configuration menu, and when I start a download I get a “Download Started!” message, and after a while it ends with “Error: Download Failed: Failed - filesize”

Looking through old forum posts suggests one possible cause is permissions and password synchronization, but I am good on all fronts there. Correct file permissions on the ipxe directory, and the fog username and password are all in alignment.

So I am at a loss. The one thing that may be mucking up the works is that we need a proxy to get to the internet, but it does appear to be using the proxy: it is able to fetch the kernel list, and I see (via tcpdump) the proxy requests to api.github.com and raw.githubusercontent.com, so I presume it is downloading. But, after that, it hangs for a while before erroring out.

Where should I be looking here? Is there a log file that I am not seeing?

Can these kernels be fetched manually?

This is running on Ubuntu 18.04.4 LTS.

I just pushed a fix that should solve this.

@pep OK, that extra bit of information you provided combined with my testing at home confirms what you are seeing, and I understand what is going on.

If the machine is in FOG but has not been inventoried, then the -c option fails (because there is no inventory record to fetch). It should just error out gracefully so I need to catch that exception.

The script should allow you to post inventory for a system, however. So that is a bug. I specifically gave it the logic to create an inventory record if none exists, and that means it shouldn’t bomb out because it couldn’t find one. I will get this fixed.

@sebastian-roth as you suspected, this ISO image did boot both legacy and EFI. Which has been a boon.

I have used this ISO four times this week, and it has been a huge time-saver.

@pep Thank you for this info. The Windows stuff hasn’t really been fully vetted yet, and this helps a lot! I’ll set up a couple of VMs at home this weekend and wire them to FOG and see what needs to be done to get this working.

I am guessing it wasn’t able to figure out your hostname.

What happens if you just run:

python fog-inventory -x

Does that dump inventory info?

@pep Make sure to pull from the master branch, and be sure you are up to date. The Windows porting is not rolled into a tagged version yet.

That error is from the original distribution, and it comes from trying to run a UNIX-specific system call on a Windows system.