4

I have a subversion working copy on my laptop, and the corresponding repository on my NAS. When I am away from home, I update and commit over the internet over an encrypted connection to an domain name which resolves to my external IP. When I am at home and connected through my home network, I would like to update and commit over an unencrypted connection to my internal (home network) IP.

I would prefer not to use encryption or my external IP address when I at home, because both slow down the connection speed (10 MB/s without encryption and with internal IP, 1 MB/s with encryption and internal IP, and 0.5 MB/s with or without encryption and with external IP).

Is there any way I can let my working copy refer to a different URL depending on whether I am or not connected to my home network? Or is there another way to solve the speed problem?

math1985
  • 41

3 Answers3

1

Some options:

  • If this is through ssh (svn+ssh://...), then you can edit your .ssh/config to specify aliases for hosts. You could then write a script that edits this configuration file on network change so that the alias points to the right hostname.
  • If it isn't (through http or something), you could run a local DNS server that resolves a special domain name that you can make up to the IP of the correct domain name depending on which network the computer is on
  • (Probably less insane than the previous one) Run a TCP relay on your local computer on some port, and have it point to either server depending on the network you are on. For example, you could make it bind to localhost:8080 and have that be forwarded to myserver:80 when on network 1, publicserver:80 when on network 2. Then you could need to do a checkout from that address (svn checkout http://localhost:8080/...).

Just some random ideas, all of them feel like workarounds though. Maybe there's an easier way.

Or you may want to switch to a distributed version control system like git, which will allow you to push to the remote you want (git push -u someremote branchname, where someremote refers to one of the servers).

Etienne Perot
  • 282
  • I would say the second approach is actually the most practical. It is not very difficult to setup a DNS server and most home routers allow you to specify the address of the DNS server given out in DHCP replies. You can easily create a DNS split horizon system this way. – billc.cn Jan 29 '12 at 04:05
1

I solved a similar problem yesterday, so git repos on my laptop can be synced with a remote on my desktop machine, without having to use a different remote depending whether I'm on the LAN or away from home.

I ran dnsmasq on my desktop, with this config:

domain-needed
bogus-priv
no-poll
local=/localdomain/
addn-hosts=/etc/extra_hosts

/etc/extra_hosts contains a single entry with the IP of my desktop on the LAN and the domain name that resolves to my external IP e.g.

192.168.0.72 jwakely.example.com

Then on my laptop edit the NetworkManager config for my LAN wifi connection to "DHCP Addresses Only" and set 192.168.0.72 as the primary DNS server, and my router as the secondary (to do that without the NetworkManager GUI just set DNS1 and DNS2 and PEERDNS=no, or put the nameservers in /etc/resolv.conf manually)

It worked perfectly once I remembered to allow DNS queries (port 53) though my desktop's firewall.

When I'm on my home LAN the laptop uses the desktop for DNS queries, so gets the internal IP for jwakely.example.com, and all other DNS queries get forwarded to my desktop's usual DNS server (which happens to be my ADSL router.) Only the laptop uses the dnsmasq instance, all other hosts on the LAN still use the router for DNS as normal. If my laptop is on the LAN but my desktop's not running then the laptop uses its secondary DNS server and can't get the internal IP for jwakely.example.com but that's OK because the machine isn't running anyway.

Jonathan Wakely
  • 129
0

I hope, you know about Subversion's relocate command. You can use it by hand. If you'll use hostnames for internal and external access, which resolve only one in one location respectively, svn error on any repo-related operation remind to to relocate

Another (dirty) idea is to use VPN-connection in external nets for securing access to server and use common insecure protocol for repository access - in home net you just doesn't up VPN-link. Advantages of this way are: single URL, security on demand, error-proof simplicity

Jonathan Wakely
  • 129
Lazy Badger
  • 3,694