Agreed completely. But I still need someone with experience using lshw to write a data processor (json => SQL) for that data. Also, we will need to sanitize the lshw output to ensure we omit identifying information. For example, ip addresses on the network interfaces need to be filtered out. It might be better to write an option for upstream lshw to anonymize the output. Any volunteers to work with me on those two items? On Thu, Nov 9, 2017 at 9:12 AM, Don Zickus <dzickus@xxxxxxxxxx> wrote: > On Wed, Nov 08, 2017 at 05:02:05PM -0500, Nathaniel McCallum wrote: >> It isn't documented in F27, but it does work. However, we probably >> want at least this patch: >> https://github.com/lyonel/lshw/commit/135a853c60582b14c5b67e5cd988a8062d9896f4 > > And some beaker stuff looks interesting in > > https://github.com/lyonel/lshw/commit/f95aa917a84a8ee74ce79e9b4f9e198d21a2e4d9 > > Regardless. My overall point was the lshw tool seems to embody a lot of > what you were looking for and thought it could be useful (with some more > fixes) instead of re-inventing the wheel with new plugins. :-) > > Up to you guys. > > Cheers, > Don > >> >> On Wed, Nov 8, 2017 at 4:28 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: >> > On Wed, Nov 08, 2017 at 04:09:26PM -0500, Nathaniel McCallum wrote: >> >> I just looked at the code for lshw. The master branch already supports >> >> JSON. We just need them to release it. >> > >> > Eh? 'lshw -json' doesn't work for you? I thought that was a supported >> > output for a while now. At least it works on my F27 box, but I think we >> > have it running successfully under RHEL-7 too. >> > >> > Cheers, >> > Don >> > >> >> >> >> On Wed, Nov 8, 2017 at 3:23 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: >> >> > On Wed, Nov 08, 2017 at 03:16:24PM -0500, Nathaniel McCallum wrote: >> >> >> I just played around with lshw a bit. We should totally make it export >> >> >> JSON. We can then submit this directly (as one census plugin). >> >> > >> >> > Yes, that is how we use it to update hardware info internally to our Beaker >> >> > instance. :-) >> >> > >> >> > Cheers, >> >> > Don >> >> > >> >> >> >> >> >> On Wed, Nov 8, 2017 at 12:34 PM, Don Zickus <dzickus@xxxxxxxxxx> wrote: >> >> >> > On Tue, Nov 07, 2017 at 10:49:02PM +0000, Jeremy Cline wrote: >> >> >> >> Hey folks, >> >> >> >> >> >> >> >> For some time now, Fedora has operated without a database of hardware >> >> >> >> users have. Smolt, the old hardware database, was retired in 2012[0] and >> >> >> >> its intended successor[1] was never deployed by Fedora Infrastructure. >> >> >> >> >> >> >> >> It would be nice to have a hardware database, so I (and hopefully some >> >> >> >> others) would like to get Census up and running for Fedora. Before we >> >> >> >> look at deploying Census, however, it would be good to make sure it has >> >> >> >> everything we need. >> >> >> >> >> >> >> >> Census has client plugins to collect information[2]. At the moment, it >> >> >> >> has plugins for: >> >> >> >> >> >> >> >> * The vendor, device, subsystem_vendor, subsystem_device, and class from >> >> >> >> each PCI device >> >> >> >> >> >> >> >> * The idVendor, idProduct, bcdDevice, and bDeviceClass for USB devices >> >> >> >> as well as the bInterfaceClass, bInterfaceSubClass, and >> >> >> >> bInterfaceProtocol for each interface >> >> >> >> >> >> >> >> * The contents of /etc/os-release >> >> >> >> >> >> >> >> * All the RPMs installed on a system >> >> >> >> >> >> >> >> Other than the drivers bound to the PCI and USB devices (which is an >> >> >> >> open PR[3]), what else would be good to collect? >> >> >> >> >> >> >> >> [0] https://fedoraproject.org/wiki/Smolt_retirement >> >> >> >> [1] https://github.com/npmccallum/census >> >> >> >> [2] https://github.com/npmccallum/census/blob/master/client/plugins/ >> >> >> >> [3] https://github.com/npmccallum/census/pull/3 >> >> >> > >> >> >> > Internally, we have been focusing on using 'lshw' as the tool that provides >> >> >> > all that info and handles all the arch funkiness (and includes firmware). >> >> >> > If there is anything missing, we have tried to push upstream to that >> >> >> > project. >> >> >> > >> >> >> > Would that cover a lot of the info you are looking for? >> >> >> > >> >> >> > Cheers, >> >> >> > Don >> >> >> _______________________________________________ >> >> >> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx >> >> >> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> >> _______________________________________________ >> >> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx >> >> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx >> _______________________________________________ >> kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
