Facter[1] does this and much more:
luke@midden(0) $ irb
irb(main):001:0> require 'facter'
=> true
irb(main):002:0> Facter.value
operatingsystem)
=> "Darwin"
irb(main):003:0> Facter.macaddress
=> "00:0a:95:96:5f:64"
irb(main):004:0> Facter.to_hash.each do |p, v| next if p =~ /key/;
puts "%s
^^^^^^^^^^^^^
^^^^^^^^^^^^^
can you explain that? custom .to_s?
Facter is meant to be a collection of mechanisms for retrieving a
named piece of data; e.g., 'uname -s' is the most common way of
retrieving the operating system name, but it's useless on any Linux
distro so instead I look for /etc/redhat-release or use lsbrelease.
Thus, it's pretty easy to think of Facter as a big hash, but instead
of simple values it has one or more ways of retrieving each value.
So, I just implemented to_hash as a way of returning all known facts
and their values.
I'm skipping any fact that matches /key/ here because Facter knows
how to retrieve SSH keys, which are huge and would have polluted the
output. I had to pick between confusing people by skipping those
values, or confusing people by including them.
seems like you should be able to do
y Facter.table('key') # or :key
for similar effect, or some such
What would be the intent of that? I think we're each missing
something here. Facter.to_hash just returns has hash of all of the
facts it knows about. Everything after that is normal, non-Facter
ruby. What would 'table' be used for?
looks very cool btw - i didn't know about Facter.
I originally wrote it a few years ago as an inventorying mechanism --
there's a simple tool[1] that stores these facts into LDAP -- but now
Puppet uses it heavily. Every time a Puppet client connects to the
server, it collects all of its known facts and passes them to the
server as a hash. The server then sets these facts as variables in
the top-level scope. Thus, you can use $operatingsystem or
$ipaddress in your Puppet configurations and use this data to make
decisions in your configuratin.
1 -
http://reductivelabs.com/projects/enhost