Facts for default interface #29
Comments
Facter.add("defaultgw_gw_address") do
setcode do
Facter::Util::Resolution.exec('ip route get 8.8.8.8 | tr -s " " | cut -d" " -f3 | head -1')
end
end
Facter.add("defaultgw_interface") do
setcode do
Facter::Util::Resolution.exec('ip route get 8.8.8.8 | tr -s " " | cut -d" " -f5 | head -1')
end
end
Facter.add("defaultgw_address") do
setcode do
Facter::Util::Resolution.exec('ip route get 8.8.8.8 | tr -s " " | cut -d" " -f7 | head -1')
end
end
Facter.add("defaultgw_internet_address") do
setcode do
# google returns an error with our ip address, nice!
# this is the original way:
#Facter::Util::Resolution.exec('curl --connect-timeout 10 -s "https://www.google.com/search?q=ip+address" | grep -o "Client IP address: [[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+" | grep -o "[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+"')
# this is smarter as we are caching the address in /tmp/.myip
iptables_wan_external_ipaddress_tmp = "/tmp/.myip"
command = 'test `cat ' + iptables_wan_external_ipaddress_tmp + ' 2> /dev/null | wc -l` -eq 1 || curl --connect-timeout 10 -s "https://www.google.com/search?q=ip+address" | grep -o "Client IP address: [[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+" | grep -o "[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+\.[[:digit:]]\+" > ' + iptables_wan_external_ipaddress_tmp + ' && chmod 400 ' + iptables_wan_external_ipaddress_tmp + ' && cat ' + iptables_wan_external_ipaddress_tmp + ' | head -1'
Facter::Util::Resolution.exec(command);
end
end
|
|
Hope this can make it into the package. |
|
Thanks for your interest and this contribution! Since these facts hit the network, they could theoretically take a long time to run. If a machine has a poor connection or no Internet connection, what do you expect would happen? Would it be possible for these to start badly misbehaving? Secondly, the current implementation of this shells out and does a lot of logic in a command, which is difficult to test and if it breaks, it can be hard to figure out why. Would you be comfortable/willing to translate this to a more pure ruby implementation? |
|
Happy to contribute! Regarding your questions:
Just ported everything and now it is fully in Ruby. On Fri, Mar 22, 2013 at 5:34 AM, Adrien Thebo notifications@github.comwrote:
|
|
Sorry for the few quick consecutive emails, but attached is now a version On Fri, Mar 22, 2013 at 12:46 PM, Dan Fruehauf malkodan@gmail.com wrote:
|
|
Please disregard the last one, this should be the final version. On Fri, Mar 22, 2013 at 1:06 PM, Dan Fruehauf malkodan@gmail.com wrote:
|
|
Just in case the attachments didn't make it through, the current new implementation (in ruby) can be found here: |
|
@danfruehauf thanks for the port and answering my questions, and sorry about the delayed response. So the cache in |
|
Thanks for the response. No, /tmp/.myip is definitely fragile, what is $vardir/facter-cache? Does it actually exist? I relied on you to provide as well some code review. I'm not happy with /tmp/.myip. If a few instances of facter try to modify the cache file at the same time - undefined behaviour. Possibly what I can do is change it so it writes to a tmp file and then overwrites the file (transactional), what do you say? |
|
The new verion is more "atomic", as renaming files should be atomic (linux and variants, not windows) The new version is here (same URL): About proper caching, this is an open issue: If you have a better solution, please go ahead (merely modifying a single variable). I never claimed it is 200% robust, but this fact is rather useful... |
|
Hi Adrien, Following up on this one, as I didn't get any response for the last 7 days. |
|
@danfruehauf apologies for my lack of response on this! I have been up to my eyeballs in backlogged work across my projects so I'm not intentionally ignoring this; I'm just having trouble making time for everything. I'll try to take a few moments today to look at this more closely. |
|
@danfruehauf I have some concern about the namespacing of the facts, but before I twiddle with them, are you dead set on the names you've used here, or are you flexible? |
|
@wolfspyre This whole thing came here as I wanted to post it for the community to use but realized that it can complement an already existing project rather than opening a new one. It's very simple facts, but very useful as well, at least in my opinion... |
|
@danfruehauf |
|
@danfruehauf network_nexthop_ip => 10.12.99.1 I've refactored them so that all the route/nexthop/interface information is collected sans network activity by getting the nexthop for to 0/0 and then parsing the output of ip route get on that host. I rewrote the public_ip fact to use ip-echo.appspot.com which is fed off google's appengine. I am not dead set against putting it back in, but I'm uncertain the benefit outweights the added complexity. Thoughts? I'm just cleaning the facts up a little bit more and I'll put them in a PR. |
|
@wolfspyre I'd still go for google.com for getting the IP, the parsing takes no time (comparing to network latency) and google.com would usually be up, whilst other providers I might not trust as much. For instance, ifconfig.me was heaps easier to parse, but significantly slower. About caching, I'd still go for caching because when I test puppet configuration I'd like it to be fast. True, on average server would access these facts only once every 30 minutes, but still, if nothing changed, why not cache it? |
|
ip-echo.appspot.com is actually hosted on google's app engine: http://googcloudlabs.appspot.com/ for site in google.com ip-echo.appspot.com; do echo ${site};time wget http://${site} -qO -| wc -c;done HOME: real 0m0.186s real 0m0.148s NJ: real 0m0.124s real 0m0.097s HKG: real 0m0.041s real 0m0.191s SJC: real 0m0.159s real 0m0.146s LON: real 0m0.119s ip-echo.appspot.com real 0m0.142s add on top the extra processing time of the headers of the wget, and I'm still pretty convinced that ip-echo's going to be the more efficient solution more often than not. As you can see, the output of a wget to google.com is actually a little over 10kb, whereas the output from ip-echo is 14-15 bytes. I'm using open-uri and timeout to add in a 1 or 2 second timeout so worst case this won't ever hold things up even on isolated systems for >2s. The reason I'm averse to the caching here, is I think it introduces fragility but doesn't bring any benefit. What situation do you see the caching helping? |
|
Pretty intensive testing. Difficult for me to argue with that. I'd still go for some sort of caching as I'd like the fact to stay viable all the time. But still, looks solid. |
Hey there, I have 4 facts that are relatively useful and I thought of joining them to this repository instead of opening a new one with just the facts.
The facts they expose are:
I'll attach the code in a comment as it is not that long...
The text was updated successfully, but these errors were encountered: