[Cialug] DNS-related Question

Matthew Nuzum newz at bearfruit.org
Fri Dec 18 00:04:40 CST 2009


On Thu, Dec 17, 2009 at 5:19 PM, Stuart Thiessen <thiessenstuart at aol.com>wrote:

> We are using OpenGoo to serve as a master project management service
> on our intranet. Apparently, the authors of OpenGoo have configured
> OpenGoo so you have to hardcode a root URL. Now, most of the time, we
> want to access it through our intranet, but we have configured our
> router so that our home IP's have permission to connect to our
> intranet server to access OpenGoo. But the problem is that I am not
> sure how set things up so that I can set up a URL like my-domain.com
> such that when we are in the office, the computer knows it is a LAN
> IP, but when we are at home, it is our office's public IP. OpenGoo
> wants one URL to insert. I learned this the hard way when I hard coded
> the IP address as the root URL. When we connect to the server, we
> can't get past the login because it is returning a local IP address as
> part of the web address which cannot be resolved over the Internet.
> (Make sense what I am explaining?)
>

I've done this before too, though I've never been satisfied with my
solution...

What worked fine was using dnsmasq. It's a dns server for your local
network. It uses a very simple configuration method. It also comes bundled
with a dhcp server. You just configure your /etc/hosts file with your static
mappings (www.yoursite.com = local.ip.address) and for the computers on the
local lan it will use your static mappings.

I suspect that whatever tool you're using to resolve hostnames on your
office lan can do something like this. I'm not an expert at configuring DNS
though. If you want to pursue this, tell us how you deal with DNS resolution
in your local network.

Your problem description piques my interest as a web-developer. I'll bet
that since you see the login screen but aren't able to login then the
problem is cookie related. It may be trying to set a cookie for a domain
that is different than what the browser is using to access the site and is
therefore rejecting the cookie.

So for example, the server thinks it's name is www.something.com and sets a
cookie that's valid for *.something.com. However you're really accessing it
via x.y.z which doesn't match *.something.com. You can verify this by using
the firefox extension Live HTTP Headers.

If this is your problem, you can do a couple things:
 1. fix the application to auto detect the domain in use from the variables
and using that value instead of hard-coding it into the apps configuration.
Drupal does it this way, you can look at the end of the settings.php file
for example code. You're basically patching the app server.
 2. put a proxy between you and your app server. This can have other
benefits besides fixing your problem. I recently saw demoed nginx which
would work and additionally offload ssl (if you're using it) and cache
static files, thereby improving app-server performance. You basically move
apache to a high port (8080 or whatever) and put nginx on the same server
proxying port 80 to localhost:8080. Then you configure your app so that it
thinks it's hostname is localhost:8080 and nginx will deal properly with
whatever domain you are using. Alternatives to nginx are apache's mod_proxy
(simple and simplistic) and squid (simple for single domain/app scenarios).

Personally, I prefer options 2 and 1 (in that order) to messign with DNS.
There are some sysadmins on this list that would rather mess with DNS I'm
sure. :-)

-- 
Matthew Nuzum
newz2000 on freenode, skype, linkedin, identi.ca and twitter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cialug.org/pipermail/cialug/attachments/20091218/e6f51f51/attachment.htm 


More information about the Cialug mailing list