facter-1.6.3 rpm is missing dmidecode as dependency
|Keywords:||vmware rpm demidecode packaging||Affected Facter version:||1.6.3|
i have a minimal Scientific Linux installation on a Vmware virtual Server, no dmidecode is installed. I install facter and get
facter | grep virtual is_virtual => false virtual => physical
i install dmidecode and get
facter | grep virtual is_virtual => true virtual => vmware
so dmidecode is needed by facter to detect vmware and should a rpm dependency
#3 Updated by Adrien Thebo over 1 year ago
I dislike having to force dmidecode as a dependency, because facter really should be able to function without demanding a certain set of detection utilities. That being said, I’ve seen this exact error on minimal installs, which definitely causes problems. The solution that I like more is creating more fallback methods that don’t rely on dmidecode that can resolve this information. The first thing that comes to mind is to check the first three bytes of the mac address for ethernet devices for the manufacturer information, or something equivalent. Ken, thoughts?
#4 Updated by Ken Barber over 1 year ago
MAC addresses can be spoofed/changed. In a virt environment they let you specify your own in some cases so its not perfect. Again – this comes back to the discussion we had regarding gathering a lot of various pieces and weighing it up – but mac addresses being very mutable only carry a little weight.
Like I said the /sys/class/dmi/id/* area is there to use – I would use that in preference for kernels that support it and fall back to dmidecode in its absence. In the cases where OS don’t have /sys/class/dmi/id then is it all bad to really on dmidecode from a package perspective in this case? We are probably talking What is wrong with dmidecode in a minimal system if the information is needed and the other alternatives are complex? As we discussed – it taps /dev/mem which is going to be hard to do on our own :–).
BTW – this does affect Redhat 5 …. it doesn’t have /sys/class/dmi … so you are stuck using other methods anyway … from a package perspective its going to be pciutils or dmidecode …
I think the other side of the coin is a concept of ‘certainty’. If lspci, dmidecode, vmware doesn’t exist, nor the sysfs – how can we be totally sure the system is virtual or not? Falling back to ‘physical’ … is this really correct in this case? Maybe we should default to ‘unknown’? I would see this is a 1.7.x change though :–).
#5 Updated by Adrien Thebo over 1 year ago
- Keywords changed from vmware rpm demidecode to vmware rpm demidecode packaging
Yep, completely right. dmidecode’s gonna be the best way to do this, but external dependencies are something I’ve been trying to avoid. We can add other detection methods too perhaps.