I’m trying to build up a nice demo of mcollective and trying to save some effort by using the RightScale CentOS AMI’s. I noticed they came with a nice script to pull down the user data and meta data so figured I might as well make some facts.
require 'find' if File.exists?("/var/spool/ec2/meta-data") Find.find("/var/spool/ec2/meta-data") do |path| filename = File.basename(path) factname = "ec2_#{filename}" factname.gsub!(/-/, "_") if File.file?(path) lines = File.readlines(path) if lines.size == 1 Facter.add(factname) do setcode { lines.first.chomp.to_s } end else lines.each_with_index do |line, i| Facter.add("#{factname}_#{i}") do setcode { lines[i].chomp } end end end end end end if File.exists?("/var/spool/ec2/user-data.raw") lines = File.readlines("/var/spool/ec2/user-data.raw") lines.each do |l| if l.chomp =~ /(.+)=(.+)/ f = $1; v = $2 Facter.add(f) do setcode { v } end end end end
If you arrange to run /opt/rightscale/bin/ec2.sh in rc.local and pop this fact above into your factdir you should be able to access all the meta data from facter.
# facter -p ec2_ami_id => ami-73270c07 ec2_ami_launch_index => 0 ec2_ami_manifest_path => pinetecltd-centos-clustera/cluster-webserver-1257783713.manifest.xml ec2_ancestor_ami_ids_0 => ami-31c72258 ec2_ancestor_ami_ids_1 => ami-ef01e486 ec2_ancestor_ami_ids_2 => ami-0916f360 ec2_ancestor_ami_ids_3 => ami-c8ac48a1 ec2_ancestor_ami_ids_4 => ami-cd52b6a4 ec2_ancestor_ami_ids_5 => ami-19be966d ec2_ancestor_ami_ids_6 => ami-65200b11 ec2_ancestor_ami_ids_7 => ami-3d200b49 ec2_ancestor_ami_ids_8 => ami-91200be5 ec2_ancestor_ami_ids_9 => ami-81200bf5 ec2_block_device_mapping_ami => sda1 ec2_block_device_mapping_ephemeral0 => sdb ec2_block_device_mapping_ephemeral1 => sdc ec2_block_device_mapping_ephemeral2 => sdd ec2_block_device_mapping_ephemeral3 => sde ec2_block_device_mapping_root => /dev/sda1 ec2_block_device_mapping_swap => sda3 ec2_hostname => ip-10-227-43-134.eu-west-1.compute.internal ec2_instance_action => none ec2_instance_id => i-9411e7e3 ec2_instance_type => m1.small ec2_kernel_id => aki-7e0d250a ec2_local_hostname => ip-10-227-43-134.eu-west-1.compute.internal ec2_local_ipv4 => 10.227.43.134 ec2_placement_availability_zone => eu-west-1b ec2_public_hostname => ec2-79-125-33-224.eu-west-1.compute.amazonaws.com ec2_public_ipv4 => 79.125.33.224 ec2_public_keys_0_openssh_key => ssh-rsa AAA ec2_ramdisk_id => ari-7d0d2509 ec2_reservation_id => r-c655bab1 ec2_security_groups_0 => rip ec2_security_groups_1 => defaultcluster => a
In addition if you just pass nice key=val pairs in as user data it will add those as facts too, the last above is from that.
Can these facts be accessed from puppet? I thought dashes weren’t valid in variable names.
Hmm, well spotted, I didn’t use them from puppet yet, I used them as selectors for mcollective.
I’ll adjust the fact so replace – with _
Have updated the code and sample output, thanks again
I’ve finally had some time to look at this in detail. All the info listed there is actually available via EC2 Meta-Data API (http://docs.amazonwebservices.com/AWSEC2/2009-08-15/UserGuide/AESDG-chapter-instancedata.html)
I’ll see if I can knock up a plugin to do this on machines that don’t have the RightScale raw files…
I recently added custom facts that I read from a REST call. Your example is similar that it reads from a file.
However, `facter my_newfact` won’t work. I assume the facts are registered by name somehow, however I do not use a string; it is generated by code. If you ran, say, `facter ec2_ramdisk_id`, does it work?
Thanks,
The builtin facts from facter does the REST call too.
The dynamic facts not showing up when ran with ‘facter foo’ is expected behavior at present and something that version 2 of Facter would probably solve.
Ah, if it’s merely cosmetic (seems to be), then all is well.