Linux script: fog inventory updater/editor


  • 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.


  • @mechalas yes, now it works perfectly. Cool


  • 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.


  • @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.


  • @mechalas well, I think I limited the topic.

    Your script works in some cases and not in others. The error it gives seems to be linked to the machine name. I have tried it on several computers, win10, w7, with different versions of python etc … and the only pattern I have found is that on computers that an image has been dumped via fog it works, if the computer is in fog with the client but an image has not been dumped does not work.
    In both win10 and w7 when it doesn’t work it gives the error I told you


  • @mechalas the first computer I tried was a w10 with python 3.9.5 and the inventory works with -x but the information does not go up. Now I have tested it with a w7 and python 3.8.10 and it works perfectly.

    This weekend I will try to do more testing


  • 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?


  • @mechalas OK,
    OK you are right.

    I have moved on, but now I have this error:

    Traceback (most recent call last):
    File “C:\temp\fog-inventory”, line 535, in <module>
    host, invid= fog.find_host(name=args.hostname)
    File “C:\temp\fog-inventory”, line 223, in find_host
    invid= int(invidstr)
    TypeError: int() argument must be a string, a bytes-like object or a number, not ‘NoneType’


  • @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.


  • @mechalas hello, I installed python on a windows 10 and when running it gives me an error,:c: \ temp> python fog-inventory -h
    Traceback (most recent call last):
    File “C: \ temp \ fog-inventory”, line 42, in <module>
    if os.getuid ():
    AttributeError: module ‘os’ has no attribute ‘getuid’

    pd: my knowledge of python is zero


  • I’ve made the first pass at adding Windows support, tackling the easy stuff that can be pulled from the registry. I’ll probably be able to get some of what’s missing currently but IMHO it’s really the BIOS version and date that are most likely to go stale on a system, and that has been implemented and tested.

298
Online

8.5k
Users

15.3k
Topics

143.3k
Posts