x.x.x.x instead of IP address

[richardforth]

Im creating this issue and closing it so that it can be referred to later, I am sure someone is going to raise this issue. at some point.

The problem is that apache2buddy has to rely on an external service via curl to get the IP address, in order to prevent ugly error messages taking up the ip address placeholder in the report, I made a try / except that puts x.x.x.x if no IP address could be found.

This is by design, there really is nothing I can do because it relies on the external service being responsive.

here is the function responsible:

sub get_ip {
        our $curl = `which curl`;
        chomp ($curl);
        if ( $curl eq '' ) {
                show_crit_box;
                print "Cannot find the 'curl' executable.";
                exit;
        } else {
                our $ip = `$curl -s myip.dnsomatic.com`;
                if ($ip =~ /429 Too Many Requests/) {
                        return "x.x.x.x";
                } else {
                        return $ip;
                }
        }
}

Over the years we have used several different providers, at the moment we are using myip.dnsomatic.com but in the past we used ip4.icanhazip.com.

the x.x.x.x is a result of "too many requests" to the external provider.

At the moment the only work around to getting a nice report without the x.x.x.x is to run the report again, and hope that the endpoint is free again.

Unfortunately this is the way it has to be, because, we did try to use pure perl to get the IP address, however perl can only see what is on the server, which may be a NAT local IP and not that helpful, also many operating systems have different networking configurations, so the effort wasn't worth the reward, with just these few lines of code we are able to pull the real external IP and it works maybe 298 times every 300 executions - but its all related to the capacity of the external supplier to service the requests, its not a bug in apache2buddy.

If myip.dnsomatic.com becomes unreliable, we will most likely move to a new provider, or try ip4.icanhazip.com again.

The alternative is to remove IP information from the report altogether, as one could argue it doesn't add much value, but for me I like it because its a double check that you have the right server and you can see at a glace what its public IP is, since apache2buddy is a one time dashboard more than anything. So for now it stays.

I hope that has adequately explained the x.x.x.x you might see from time to time, and again, my advice is to simply re-run your report if you see it.

Any issues that are raised on it will be closed and directed to this explanation.

Happy tuning!
Rich