[Cialug] DNS-related Question

[Josh More]

Least pain for three developers is to modify your local hosts files and
optionally write a script that flips different versions in and out.

We tend to really like infrastructure solutions in this group, but
occasionally, endpoint modification is an easier path.  (Only when
scaling is not an issue.)





-Josh More, RHCE, CISSP, NCLP, GIAC 
 morej at alliancetechnologies.net 
 515-245-7701

>>> Stuart Thiessen <thiessenstuart at aol.com> 12/18/09 10:41 AM >>>
Well, it looks to me like OpenGoo in its config file asks you to set  
the root URL hardcoded. So it will bring up my page if I log in from  
outside with the public IP, but when it returns the next page, it is  
returning it prefixed with the hard coded root URL which of course is  
my LAN IP address and is not valid over the internet. So, that was why  
I was trying to do something where I put sub.my-domain.com in the hard- 
coded URL and then try to configure DNS somehow so that it can find  
the right IP (LAN or Internet) for sub.my-domain.com depending on my  
location.

Looks like my best options are configuring DNS, trying your dnsmasq,  
or configuring a VPN. There are only 3 of us on my team who need this  
kind of access, so I'm looking for the least pain solution. :-) Which  
of the three do you feel has the best security and least configuration  
headache of the three in your experience? I've never had to do this  
before so that's why I ask before I get myself into something too  
complicated. :)

Thanks,

Stuart

On Dec 18, 2009, at 00:04 , Matthew Nuzum wrote:

> 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
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug