DA configures Apache wrongly

[TMC]

• The following scenario is real, only the values have been changed to protect our innocent Resellers!
  
  IP 123.123.123.1 is assigned to DA as a fixed IP for exclusive use by Reseller 1.
  IP 123.123.123.2 is assigned to DA as a shared IP for exclusive use by Reseller 2.
  So far, so good.
  
  Reseller 1 creates website A which DA maps correctly to IP 123.123.123.1 and Apache returns the correct content for the domain ("static IP").
  Reseller 2 creates websites B C & E which DA maps correctly to IP 123.123.123.2 and Apache returns the correct content for each domain ("name-based").
  So far, so good.
  
  Reseller 2 then creates websites F & G which DA maps correctly to IP 123.123.123.2 as before. Unfortunately DA configures Apache incorrectly at this point!
  
  DA correctly assigns Domain F to IP 123.123.123.2 and Apache returns the correct name-based Reseller 2 content.
  However, when DA assigns Domain G to IP 123.123.123.2....
  
  .... instead of returning the correct name-based CONTENT of DOMAIN G, Apache returns the CONTENT of DOMAIN A. As stated above, Domain A belongs to Reseller 1. Running TRACEROUTE confirms Domain G is correctly mapped to Reseller 2's IP address. But Apache is delivering the WRONG CONTENT for Domain G. On top of which, everyting which Reseller 2 has uploaded to its Domain G FTP account is simply ignored by Apache.
  
  Without causing downtime for either of our Resellers, how can we locate and manually fix the Apache misconfiguration causing this?

 

[ballyn]

The httpd.conf file for individual users (and domains) is kept in /usr/local/directadmin/data/users/<username>/httpd.conf.

That file is created by DA for every user based on the input in the panel...

I would have a look at that file for the user that owns domain G and make sure that the VirtualHost line is set correctly and that the ServerName and DocumentRoot are correct.

When apache reads this file, it should map all calls to ServerName (and ServerAlias) that come in on the VirtualHost IP/port and deliver the content in the DocumentRoot.

 

[TMC]

Okay now what?

• Thanks for the prompt reply, ballyn.

I would ... make sure that the VirtualHost line is set correctly ...

• Presumably when you say 'correctly' you're asking if the "Virtual Host" line in each of all the http.conf files belonging to Reseller 2's domain names are pointed to Reseller 2's shared IP address? YES THEY ARE / YES THEY DO. We compared both Domain F and Domain G http.conf files line-by-line. As you recall Apache is delivering the correct content for Domain F but not for Domain G.

... and that the ServerName and DocumentRoot are correct.

• Presumably when you say 'correct' you're asking if the "ServerName" line contains Domain G correctly, and if the "DocumentRoot" line contains the full path to "public_html" belonging to Reseller 2's Domain G <username> folder correctly? YES THEY DO. We checked these two configuration assignments in the http.conf files for both Domain F and Domain G, and they are correctly spelt in all lowercase text and show the correct <username> server path info.

When apache reads this file, it should map all calls to ServerName (and ServerAlias) that come in on the VirtualHost IP/port and deliver the content in the DocumentRoot.

• All of which sounds reasonable enough, however nothing in either of these files differes sufficiently to explain why Apache is delivering Domain F content correctly but delivering Domain G content incorrectly. As if the "DocumentRoot" value for Domain G were (wrongly) set to Reseller 1's <username> server path info.
  
  Is there anywhere else Apache might have been wrongly configured by DA during the creation of Domain G's website?

 

[mike_p]

If I understand you correctly, you are saying you cannot find any misconfiguration of APACHE, yet you are saying that DA has misconfigured it?

Before laying the blame, I'd identify the problem correctly.

eg are you confident that DOMAIN G has has been pointed at the right IP address (eg via external nameservers?). If it has inadvertently been pointed at 123.123.123.1, then it will show DOMAIN A content

 

[TMC]

Okay now what??

• Thanks for pitching in, mike_p.

Before laying the blame, I'd identify the problem correctly.
...
If it has inadvertently been pointed at 123.123.123.1, then it will show DOMAIN A content

• That's a big 10-4 good buddy. Unfortunately we're more than confident we have identified the problem correctly. Unless you're suggesting the results produced by TRACEROUTE should not be trusted (please study our first posting in this thread).
  
  Bottom line, we know that Reseller 2's external nameservers for both Domain F and Domain G are correctly configured because TRACEROUTE confirms both domains are correctly resolving to Reseller 2's IP address (123.123.123.2) and have been doing so for over a week. Or to explain it in the style of our Irish grandpa, TRACEROUTE confirms neither Domain F or Domain G are resolving to Reseller 1's IP address (123.123.123.1).
  
  INSOFAR AS WE CAN CONFIRM, Apache is simply not following the current httpd.conf settings CREATED BY DA for Domain G. Yet the current httpd.conf settings which again were CREATED BY DA for Domain F are working without error.
  
  What we're asking here is WHAT ELSE CAN WE INSPECT apart from httpd.conf as very sensibly suggested by ballyn? Apache returns Reseller 2's public_html CONTENT for Domain F correctly, in complete accord with Domain F's <username> httpd.conf. Yet the same is NOT happening with Reseller 2's Domain G, despite our having thrice confirmed Domain G's <username> httpd.conf settings are entirely correct (please study our detailed reply posting to ballyn above).
  
  Apart from Apache itself, WHO OR WHAT ELSE SHOULD WE TAKE ISSUE WITH apart from DA? The server sysadmin is the only human with root access to Apache; all other access to it is done via DA. Thus it appears perfectly correct to identify DA as our only suspect, your honor.
  
  Or is this a known Apache issue? Is there a debug mode available which could show us exactly what Apache is actually doing when port 80 requests arrive? How frequently does Apache load its httpd.conf? Should we restart Apache? Must we set up a cron event to force periodic Apache restarts (as is necessary to keep IIS under long-term control)? Will there be crumpets for tea? Enquiring minds need to know!

 

[mike_p]

Have you done the traceroute yourself, or are you depending on your reseller's word?

The reason I push this point is that the symptoms exactly suit the scenario in which DOMAIN G resolves to 123.123.123.1.

When I troubleshoot, when everything appears correct, I re-check every assumption.

As it is you describe a situation in which the APACHE configuration is correct (ie line by line comparison of DOMAIN F and G). Yet you still say it has been misconfigured by DA. I don't understand how you can marry those two 'facts' together.

Do you have control of the router, are there any .htaccess files around? Are they newly assigned IP addresses? (relative to the server)

 

[TMC]

Okay now what???

• Thanks for the quick follow-up, mike.

Have you done the traceroute yourself, or are you depending on your reseller's word?

• We do all our own traceroutes. Both domains F and G are without doubt resolving correctly and have done so for over a week.

The reason I push this point is that the symptoms exactly suit the scenario in which DOMAIN G resolves to 123.123.123.1.

• Your defense of DA is laudible, however you must appreciate that the symptoms also EXACTLY suit the scenario in which Apache has been broken and/or wrongly configured. Our question to you is, what process other than DA exists which we can viably identify as being responsible???

As it is you describe a situation in which the APACHE configuration is correct (ie line by line comparison of DOMAIN F and G). Yet you still say it has been misconfigured by DA. I don't understand how you can marry those two 'facts' together.

• Okay, please elaborate on your implication that some anonymous root user or core Linux process other than DA may have created Domain G's httpd.conf file. Remember no-one else has legitimate access to Apache's numerous configuration files except for DA (we've also verified this umpteen times).

Do you have control of the router, are there any .htaccess files around? Are they newly assigned IP addresses? (relative to the server)

• Your suggestions are appreciated, but they're getting a little off-topic. Yes we own the server router and the server IP addresses and have done so since last year. FYI all the other 100+ Apache domains on this DA server are being served correctly EXCEPT FOR DOMAIN G.
  
  Again we'd be grateful if you could specifically address the topic established in the opening post of this thread. Speculation about other scenarios are not an issue IN THIS CASE, thanks all the same.
  
  If there's nothing more we can possibly determine by passive diagnosis (such as examining DA's internal files to verify exactly what it thinks Domain G's IP assignment is), we'd honestly prefer to close this thread and start another about Apache debugging methods. Or about the wisdom of periodically restarting Apache or DA (which we have not done yet, although it's an increasingly attractive idea at this rate). Or others about the other hypothetical Apache/DA bugs as posted above.
  

 

[nobaloney]

If the individual owner httpd.conf files are correct, then there's got to be a reason why apache is returning the wrong information.

The first thing I'd check is that apache has been properly restarted. If it hasn't been, then apache will show the contents of the first site on that IP#.

The second thing I'd check is that the apache user can read the site's user's httpd.conf file. Check it's ownership and rights with the httpd.conf file for a working user.

The third thing I'd do (and this will take a while) is using a good editor, and working in /tmp or in /home/admin, replace all the include lines in the main /etc/httpd/conf/httpd.conf file with the actual file contents.

Then I'd search through the file for the wrong IP, for the right IP, and for the domain name, always from top to bottom.

The first test should be for the domain name. If it shows up more than once, then it's the last one that's being used by apache.

If it doesn't show up, then what's the first site showing up for the IP# of the site that's not showing up? That should be the site that shows up for the missing site.

If everything appears normal, then it sounds like a bug in apache.

Jeff

 

[TMC]

Eeek!

• Greetings JL, always a pleasure.

The first thing I'd check is that apache has been properly restarted. If it hasn't been, then apache will show the contents of the first site on that IP#.

• Please define "properly restarted". As far as our understanding goes, there are two and a half ways to restart Apache:
  [1] Reboot the server, wait a while, eventually Linux will restart both DA and Apache.
  [2] Login to the server as root, then type either this: service httpd restart
  or this: apachectl restart
  
  We have no idea how the latter two commands differ, if at all. Please make a recommendation!

The second thing I'd check is that the apache user can read the site's user's httpd.conf file. Check it's ownership and rights with the httpd.conf file for a working user.

• That's something we haven't checked on Domain G, but you can be sure we'll do it immediately after posting this.

The third thing I'd do (and this will take a while) is using a good editor, and working in /tmp or in /home/admin, replace all the include lines in the main /etc/httpd/conf/httpd.conf file with the actual file contents.

Then I'd search through the file for the wrong IP, for the right IP, and for the domain name, always from top to bottom.

• Eeek! Again very good advice, but we'll try assembling such a test file from the most recently backed-up files which are kept locally. That way we can use TextPad locally and avoid going insane using vi remotely
  
  Oh my ears and whiskers, so much for an early night

 

[toml]

Definitly take a look at the main httpd.conf (/etc/httpd/conf/httpd.conf in RH systems), and be sure the 'Include' line for the misbehaving domain is correct and readable by the apache user/group. If it is not readable or the 'Include' did not work, you should have got a syntax error or file error, but you never know. If it was never included properly, then all Apache knows to do, is return the default domain.

Also, the best way to restart Apache for the DA system is the 'service httpd restart' , don't use apachectl. Apachectl does not set all the variables needed to activate all the modules used for DA.