<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>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. :)</div><div><br></div><div>Thanks,</div><div><br></div><div>Stuart</div><div><br><div><div>On Dec 18, 2009, at 00:04 , Matthew Nuzum wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Thu, Dec 17, 2009 at 5:19 PM, Stuart Thiessen <span dir="ltr"><<a href="mailto:thiessenstuart@aol.com">thiessenstuart@aol.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> We are using OpenGoo to serve as a master project management service<br> on our intranet. Apparently, the authors of OpenGoo have configured<br> OpenGoo so you have to hardcode a root URL. Now, most of the time, we<br> want to access it through our intranet, but we have configured our<br> router so that our home IP's have permission to connect to our<br> intranet server to access OpenGoo. But the problem is that I am not<br> sure how set things up so that I can set up a URL like <a href="http://my-domain.com" target="_blank">my-domain.com</a><br> such that when we are in the office, the computer knows it is a LAN<br> IP, but when we are at home, it is our office's public IP. OpenGoo<br> wants one URL to insert. I learned this the hard way when I hard coded<br> the IP address as the root URL. When we connect to the server, we<br> can't get past the login because it is returning a local IP address as<br> part of the web address which cannot be resolved over the Internet.<br> (Make sense what I am explaining?)<br clear="all"></blockquote></div><br>I've done this before too, though I've never been satisfied with my solution...<br><br>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 (<a href="http://www.yoursite.com">www.yoursite.com</a> = local.ip.address) and for the computers on the local lan it will use your static mappings.<br> <br>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.<br> <br>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.<br> <br>So for example, the server thinks it's name is <a href="http://www.something.com">www.something.com</a> and sets a cookie that's valid for *.<a href="http://something.com">something.com</a>. However you're really accessing it via x.y.z which doesn't match *.<a href="http://something.com">something.com</a>. You can verify this by using the firefox extension Live HTTP Headers.<br> <br>If this is your problem, you can do a couple things:<br> 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.<br> 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).<br> <br>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. :-)<br><br>-- <br>Matthew Nuzum<br>newz2000 on freenode, skype, linkedin, <a href="http://identi.ca">identi.ca</a> and twitter<br> _______________________________________________<br>Cialug mailing list<br><a href="mailto:Cialug@cialug.org">Cialug@cialug.org</a><br>http://cialug.org/mailman/listinfo/cialug<br></blockquote></div><br></div></body></html>=