Apache & PHP not playing nice

[Varminter]

Evening gang,
I've got a problem with Apache & PHP and I'm not sure what's going on. The short of the long of it is, I've got some PHP pages that have been running for a while just fine. As of midnight last night, Apache has decided to not parse the PHP code on random pages and random sites. And it doesn't matter if the requesting browser is IE10, Chrome, or Firefox. It acts like PHP was not compiled in, nor was it included in the APACHE_OPTS in /etc/conf.d/apache2. There hasn't been an Apache or PHP update recently, so I doubt it is the version. But here's the Apache and PHP compile flags:

[666threesixes666]

what does

[Varminter]

[Varminter]

Any other ideas guys? I did

[miket]

When you say that your web server is not parsing PHP, what do you mean? Do you get PHP source code in your browser or do you get a blank page or some kind of error message? If you see PHP code in the browser, is it all jumbled into one line or does it appear as lines of PHP text?

I would not expect mod_php to quit working all of a sudden. (I would have tried a lot of other things before trying to rebuild packages.) When you talk about being able to access the server from outside your LAN but not have it work inside of it makes me think you have some kind of routing or firewall issue. Is Apache or any of your test hosts running in a VM (as in KVM, Xen, Virtualbox, etc)?

Here's another kind of test: how does Apache handle straight .html pages?

If nothing else, post what you get when you enter this command on any machine on your LAN:

[Varminter]

By not parsing, it is showing up as plain text in the browser window, similar to opening up the .php file in Notepad or the like. As for .html, it does fine. What's baffling me is that this problem only appears on the LAN at random times with multiple PCs. But people coming in on my WAN don't have the issue. I've got a person who has a VPN tunnel out to a client site, then he can get back in to the pages fine. But if he looks at them with IE9/10, Chrome, or Firefox, a lot of the .php scripts that generate the pages show the .php file. I'll see if I can't get a screen snippet up on the server in a bit.

Case in point, I got the Good_Capture.jpeg from Chrome on my PC, yet about 2 hours go I would have gotten the Bad_Capture.jpeg image. I actually had to go try another person's PC to get the Bad_Capture.jpeg.
An example of what I'm seeing:
http://www.d2i2.com/Bad_Capture.jpeg
And what that same page should look like:
http://www.d2i2.com/Good_Capture.jpeg

The curl -v run of the above came out fine:

[miket]

I started on a reply a few hours ago, but got stuck. My intuition is that problem comes from some interaction between DNS, the Apache VirtualHost configuration, and the headers that desktop browsers are setting. Your examples show that you used a fully qualified domain name (house.bearelec.com). When you tried reaching the web host from graphical browsers on the LAN, did you enter a FQDN or just "house"? DNS would resolve a name like that (assuming that you have domain bearelec.com in your /etc/resolv.conf) to the correct IP, but Apache would need an explicit ServerName or ServerAlias directive for house.

This theory falls apart in the face of the fact that the URL field of the browser shows the FQDN. Clearly cURL is doing the correct thing: it sends the Host: house.bearelec.com header, after all. From what I can gather, the graphical browsers are sending that same header.

The trouble is that I can't think of any real scenarios to get you in the trouble you've got. How about posting the VirtualHost section from your /etc/apache/vhosts.d/00_default_vhost.conf to see if there's something funky about it. The section ought to begin with something like

[Varminter]

I just changed the /etc/hosts file on the server this morning after looking at your post. It now has entries (FDQN and short name) for all the web-sites on the server, one FDQN & associated short names per line. I know I don't need to do it that way, just makes it easier to read and maintain.

[666threesixes666]

on a fresh rebuild/install of php i had a missing /etc/apache2/modules.d/70_mod_php5.conf

That's after purging apache & php. it would show text instead of run the php, and it was missing that file and that sorted everything out for me.

[miket]

Not having /etc/apache2/modules.d/70_mod_php5.conf or a missing -D PHP5 on the Apache command would surely be a showstopper, as you say. The difficulty is that Varminter's PHP does work some of the time.

There's one particular trick I'm trying to understand. If this web server is visible both on the network and from outside, that outside access has to be the result of tunnelling or maybe some awful trick with DMZ at the router. I say this because these are definitely local setups going on. The address of 10.0.0.6 is a private-use address; you can't route to that on the global internet.

Let me be sure of something. The hosts www.d2i2.com and varmintercustom.com both resolve to 65.182.241.92. To make this work, you'd have a vhosts configuration something like this:

[666threesixes666]

that kinda confused me... i had -D PHP5, but not 70_... and some php would load fine, and phpinfo() flat out refused to load. once that loads then you're pretty much set.

[Varminter]

miket - Yes, the house.bearelec.com domain name isn't registered on the net, but it really doesn't need to be with an internal DNS, especially since we're using that name for a client development project. You don't even need a DNS if you put that name into the hosts file on both the Linux and Windows boxes on a LAN or even a WAN, they'll treat that pseudo-domain name as a valid name. Since the first place 99% of the computers go hit their internal hosts file for name resolution before trying a DNS. Great for doing development, so long as the name you're using doesn't conflict with a real-world site you need to talk to at some point.

As for the AddHandler directive, the only ones that are active are in /etc/apache2/modules.d/*. I did a grep through the /etc/apache2/* tree. And I'm not using htaccess, I've had too many issues in the past getting that set-up. I should probably go out and revisit the documentation on that, since it has been a few years since I last looked at htaccess.

[miket]