4

I have a strange issue that I really would like to know more about. Yesterday I was deploying a new site on my hosting server. The day before I switched from PHP 5.2.17 to PHP 5.4.10 on the server. The strange thing was that the version was still reported to be 5.2.17? I asked a co-worker to go to the site and he got the correct version. Finally, I turned of my VPN (not used for this specific server) and instantly I could see the server running the correct PHP version. Now I would really like to know why this would ever happend? The only thing I can think of is that this must be some kind of caching issue in conjunction with the running VPN tunnel?

If I create a new file over SSH in the webroot I cannot access the file though my browser, instead I receive a 404 page. If I turn of or restart my VPN this error goes away.

I'm using Juno Pulse as my VPN client.

Another interesting thing that I noticed is that after I restarted the VPN client the page reports the correct version again.

9
  • What VPN client are you using and how did you check the PHP version? – Spokey Sep 14 '15 at 10:38
  • @Spokey - I edited my answer and added info about the client. I'm using Juno Pulse. I checked the php version by adding an info.php file that executes phpInfo(); and added this to the root of the site. – Cyclonecode Sep 14 '15 at 11:11
  • It sounds like you were reaching a cached page. Since you are no longer effected by this behavior, what exactly, is your question? – Ramhound Sep 14 '15 at 11:41
  • @Ramhound - The question is why this happend. What is caching the page? If I renamed the info.php to info2.php (this should not be cached) then I experienced the same behavior when accessing the new info2.php file through my browser? – Cyclonecode Sep 14 '15 at 11:44
  • 1
    Not necessary - it depends on how the load balancer is configured. It could be balancing on IP address or some kind of session cookie. It may be worth trying a different browser to eliminate the possibility of injected cookies for load balancing. You might also want to try fingerprinting the servers to see if they are different [ both of these are longish shots, but worth trying. – davidgo Feb 16 '17 at 23:38
1
+25

It sounds to me like a provider+dns issue - specifically I postulate the provider has multiple machines - possibly with shared web storage but periodically synced system storage -, and by using / not using a VPN you changed the routing to a different machine - before PHP - was updated.

The signs of this are : 1. Its not a cache. Renaming the info.php file ruled it out. 2. Its a routing related issue - thr VPN chsnges the routing. 3. It was a temporary issue.

1
  • I don't believe it was a temporary issue since I could reproduce by restarting the VPN connection. – Cyclonecode Feb 16 '17 at 22:12
1

Without checking the underlying setup it's difficult to say exactly what the issue was however based on some of the information you provided it was unlikely a cache given that you created the info2.php file and had the same problem.

Which would indicate you where routed to another server when using the VPN. Either by a load balancer at your provider or DNS (See if there is multiple records/round-robin). There isn't any caches at your VPN that would possibly cause this (Which I think is what you are getting at).

There are many different load balancer configurations but one such configuration is based on a hash of the IP which would explain why you where always stuck to the same system (that had possibly not synced your changes yet) but where routed to another when accessing from another IP. See nginx's ip_hash for an example of one such balancer configuration. Specifically,

The first three octets of the client IPv4 address, or the entire IPv6 address, are used as a hashing key. The method ensures that requests from the same client will always be passed to the same server except when this server is unavailable.

As for the DNS option check if your domain routes to multiple A records, maybe using a tool like mxtoolbox as this also might explain being routed to another system if no actual LB is in place.

Something that comes to mind for a situation similar to this was recently code changes where not being shown to certain requests. The problem was ENOM allowed the CNAME to the root record which isn't allowed per RFC1034 in their interface. However what actually happens is they simply lookup the A records of the CNAME which in this case was an AWS ELB and created 2 A records for the two IP's the ELB resolved to and then a few months later when AWS changed one of the IP's the ELB was routing to this wasn't reflected so some requests where being routed to the old ELB IP and in turn displaying the old cached code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.