Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm beginning to pull out my hair.

Using Redhat/Apache we've three virtual hosts set up to serve three Drupal based domains and a fourth virtual host set up to serve Redmine via passenger all from one machine.

This set up is fine for all traffic, all network addresses can resolve all four domains. Due to the networking infrastructure, the box in question uses a proxy to see the outside world.

I have attempted to access the Redmine API from a script on the local machine and the response is an error:

While trying to retrieve the URL: http://projects/users.xml 

The following error was encountered: 

Unable to determine IP address from host name for projects 
The dnsserver returned: 

Name Error: The domain name does not exist. 
This means that: 

 The cache was not able to resolve the hostname presented in the URL. 
 Check if the address is correct. 

Accessing the API from an external machine provides the expected response, so the API is accessible - which leads me to believe that this is only a problem with Apache or/and PHP resolving the virtual host domain from itself.

I've made an educated guess that this might be a proxy issue, that the proxy being used is unaware of the local network DNS, but I don't know how to turn the proxy off for Apache to check, as I didn't set up this server and not familiar with proxy requirements generally.

If I can confirm whether or not this is a proxy issue, how do I make an exception for certain domains? I assume I need to make use of the NO_PROXY environment variable, but again, I don't know how to do this for the Apache user, and more importantly, dumping the ENV variables for the Apache user doesn't show a HTTP_PROXY value at all, so I am assuming Apache uses proxy configuration elsewhere.

Am I missing something obvious?

EDIT: As requested, nslookup for the domain returns:

$ nslookup projects
Server:         10.11.6.31
Address:        10.11.6.31#53

Name:   projects.INNSERVE.LOCAL
Address: 10.11.6.48

EDIT 2: As requested, wget results for URL in question:

$ wget projects/users.xml
--2012-12-22 19:12:51--  http://projects/users.xml
Resolving projects... 10.11.6.48
Connecting to projects|10.11.6.48|:80... connected.
HTTP request sent, awaiting response... 401 Authorization Required
Authorization failed.
share|improve this question
    
Show us result of "nslookup project" from local machine. –  alterpub Dec 19 '12 at 12:42
    
I've added the nslookup results to question. @alterpub –  kieran_delaney Dec 19 '12 at 14:27
    
Could you please post the output of wget projects/users.xml –  user130370 Dec 19 '12 at 16:22
    
I've added wget results to question. @EricDANNIELOU –  kieran_delaney Dec 22 '12 at 19:16
    
what do you get by accesing the ip directly? –  w0rldart Dec 22 '12 at 23:18

2 Answers 2

I'd try one of the following :

add

domain example.com
search example.com

to /etc/resolv.conf

Or add

11.22.33.44    projects.example.com projects

to /etc/hosts

Any of these are likely to solve the dns issue.

share|improve this answer
    
Hi Eric, all virtual hosts are already mapped in etc/hosts, domain is already defined, adding a search record to match makes no difference even after apache restart. –  kieran_delaney Dec 19 '12 at 14:26
up vote 0 down vote accepted

Out of desperation we've managed to fix the problem by re-defining the Apache webserver hosts files. Previously we had used Webmin to set these up (mostly, I created the projects hosts entry by hand for serving the Redmine installation via passenger).

The issue was as follows:

Projects was defined as a virtual host with a port number:

<VirtualHost our.ip.address:80>
DocumentRoot /opt/redmine-2.1.2/public
ServerName projects
...

Whilst all other virtual hosts were defined without explicitly labelling the port number:

<VirtualHost our.ip.address>
    DocumentRoot /var/www
    ServerName address.domain.local
    ServerAlias address

This worked fine in every respect other than Apache resolving it's own virtual hosts.

Changing the remaining virtual hosts to include the port number appears to have corrected this (and port numbers are important as we use multiple port numbers for various reasons not pertinent here).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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