Add lsusb fact

[jcpunk]

A list of connected USB devices can come in handy (for things like webcams).

[trevor-vaughan]

@jcpunk This looks like a great fact, but I'm not quite getting the general use case. This fact could return excessively large amounts on information on some hosts so we have to be careful tossing it into the general mix.

If you could provide a specific use case, that could be very helpful to deciding whether or not we can pull it in.

We're already looking at usbguard inclusion in the SIMP stack based on the requirements coming out in the RHEL 8 STIG but I currently don't see added benefit to having the list in place (but will completely admit that I may be missing something).

I've been thinking about the concept of 'targeted facts' where a control file on the system would both activate the fact and ensure that it only picks up a limited amount of information (even if it could return more).

[trevor-vaughan]

I've started a thread in the Puppet Slack to try and remedy the overall 'big facts' issue.

[jcpunk]

I'm using this fact in my existing puppet to identify some usb devices we've got that require special system drivers.

The code for that is actually pretty hideous... this fact was a 'step 1' in trying to clean up my internal nonsense and generally share with the community.

From a usability perspective on lsusb, I was wondering if the [bus][device] keys are actually necessary. Bus enumeration changes could result in a number of meaningless fact updates.

For the lspci fact, I'm also doing some horrid work internally to identify various RAID controllers and install their CLI management utilities. Odds are this fact could also be restructured into something more friendly too.

[trevor-vaughan]

@jcpunk Honestly, the fact looks just fine I'm just worried about the amount of wire space that will use on larger systems and/or systems with a ton of connected devices.

I figured that this was for something like driver installation and that totally makes sense but I think we'll need to see if we can get facter to be a bit smarter about letting us configure things before pulling this into core.

I hate letting it sit there but we won't close it (either facter will do something or we will) because we're starting to run into the 'large fact' issue across the board. Even some of the native facts are affected (one user in the Puppet Slack indicated that they had a 600+ core system with hundreds of NICs and it was just overwhelming).

[trevor-vaughan]

@jcpunk Just wanted to let you know that I haven't forgotten about these. Now that Facter 4 is out, these may become more of a reality but we may have to confine them on the Facter version or something.

[jcpunk]

No worries :)

[jcpunk]

I'm looking at Facter 4 a bit. Is there any doc for how I could build a custom ruby fact that provides a default ttl? Everything seems to point towards editing facter.conf.....

[trevor-vaughan]

@jcpunk Ah, I was more referring to the fact that it's back in Ruby and, therefore, easy to hack what we need into it :-D.

[trevor-vaughan]

@jcpunk OK, I think we can start to get this in place! We're going to need to update the code to ensure that it only fires when Facter 4 is in play and then we'll need to figure out how to tell users to confine it and add it to the README.

[jcpunk]

Is there some documentation you can point me towards to get up to speed on facter4 confinement?

[trevor-vaughan]

@jcpunk Heh, not really. I'm hoping that chucking the whole thing in something like if Facter.version > 4 will work but I'd have to play around with it in pry.

Hitting the Puppet Slack dev channel might be a good start though.