Posted by Doug
Thu, 19 Jan 2006 20:06:15 GMT
I’m working from home a lot requiring a VPN connection to my work. The default VPN setup for the Mac is a little less than ideal; it routes all traffic through the VPN. As our VPN is a little sluggish, I’d like for only work related traffic to route through the VPN. Here’s what I had to do.
I started with this Mac OSX Hint to Set no default route for VPN Client via PPTP/L2TP. The hint says to set nodefaltrouter in /etc/ppp/vpn-name and then do my routing in /etc/ppp/ip-up. The good news is that in Mac OS 10.4 Tiger, there’s a configuration option for Internet Connect to toggle setting of the default route. Progress: all my traffic is no longer going over VPN.
Problem: my local DNS can’t do lookups for the company’s LAN. So, I go into Network Preferences for the VPN and statically assign the DNS Servers.
Hmmm, that should work but host name lookup still doesn’t work. Ah, I still don’t have a route defined for the corporate LAN to use the VPN. So, I create /etc/ppp/ip-up to include this simple command:
#!/bin/sh
route add 10.1.0.0/16 -interface ppp0
Unfortunately, this doesn’t automatically set the route when I establish the VPN connection. So, that’s where I stand. I’ve got /etc/ppp/ip-up chmod +x and manually run it when I initiate my VPN connection. Also, I think this whole setup will affect my other VPN configuration for which I do want all traffic to use. Ah, well… nothing’s perfect.
Posted in Security, Internet | Tags Apple, Tiger, VPN | no comments
Posted by Doug
Thu, 19 Jan 2006 17:18:12 GMT
This week I’ve bought a Logitech V270 Cordless Optical Notebook Mouse for Bluetooth. On paper it’s a great mouse. In practice, not so much.
I’m now a traveling software developer using an Apple Powerbook. I’ve relied on a wired Kensington Iridio mouse for a long time. It’s quite serviceable, but not fantastic. I wanted something I could travel with easily. Naturally I started looking into Bluetooth mice since my Powerbook has built-in Bluetooth. I spent longer than I should have at Micro Center looking at all the mice they had trying to decide on which I wanted.
I settled on Logitech’s Bluetooth mouse. It’s a simple and fairly inexpensive mouse that claims Mac compatibility on the box. It has a fairly high resolution of 1000dpi. Also, it comes with a handy little carrying bag to keep it from getting bunged up in my bag. Add in a physical on/off switch and it’s nearly the perfect travel mouse.
The only problem is that it’s constantly loosing connection with my Powerbook. I think it’s a designed feature for conserving batteries. The solution is simply to hold the left mouse button until it connects again to the Powerbook. The result is that nearly ever time I go to grab the mouse it’s disconnected. Very annoying. Even while I’m actually using it connection can be lost. I find it hard to believe that a battery saving option would be to simply stop working while in use.
I’m not sure what to do about it. I guess I should return it since it’s a fairly annoying mouse to use. But I like everything about the mouse except this very intrusive problem. If you have a solution to this problem, I’d love to hear it.
Also, if you could recommend a better Bluetooth mouse I’d like to hear that too. Here are my requirements:
- Bluetooth
- At least two buttons and a scroll wheel
- No “base station” to travel with. I want to simply toss the mouse in my bag and go
- On/Off Switch
- Reasonably high DPI to make Photoshopping easier.
- Mac support, of course
- Ideally I’d like to see battery level too; but oh well…
Here are two mice I’m considering:
Does anyone have any experience with either of these?
Posted in Hardware | Tags Bluetooth, Logitech, Mice | 7 comments
Posted by Doug
Thu, 05 Jan 2006 20:40:00 GMT
I don’t think my situation is that odd, but I had to make several tweaks to use SwitchTower work for me. I have a single server; my web server is Apache launching FCGI on localhost with MySQL also on localhost. I have two live versions of my application: a real “production” site and an “integration” site. I use the integration site to demonstrate code to my client before it’s moved into production. Integration uses the same code repository as production and uses the Rails development environment. There are two of us developers working on the project. Both of us should be able to deploy.
We’d like the default rake deploy to deploy to our integration server. We’d like something simple to also be able to deploy to our production environment. The first recommendation I got was to duplicate the lib/tasks/switchtower.rake tasks and then also duplicate config/deploy.rb for the two environments. So, I’d end up doing something like rake deploy for integration and rake deploy_production for production. This quickly lead to a lot of duplication.
Jamis Buck suggested to simply use conditionals in the config/deploy.rb to set the necessary parameters. After some experimentation, here’s what I ended up with:
set :application, "myapp"
set :repository, "svn+ssh://my.hostname.dom/path/to/svn/trunk"
if ENV['RAILS_ENV'] == 'production'
set :deploy_to, "/path/to/production/"
else
set :deploy_to, "/path/to/development"
end
role :app, "my.hostname.dom"
role :web, "my.hostname.dom"
role :db, "my.hostname.dom"
This means that as requested, the default rake deploy goes to integration. For production, RAILS_ENV="production" rake deploy works. This is very similar to all the other rake tasks for development vs. production.
There’s one catch though. The default :migrate task hard codes the RAILS_ENV when running the migration on the remote host. So, I had to override that task:
task :migrate, :roles => :db, :only => { :primary => true } do
directory = case migrate_target.to_sym
when :current then current_path
when :latest then current_release
else
raise ArgumentError,
"you must specify one of current or latest for migrate_target"
end
run "cd #{directory} && " +
"#{rake} RAILS_ENV=#{ENV['RAILS_ENV']} #{migrate_env} migrate"
end
The only change there is that I’ve substituted #{ENV['RAILS_ENV']} where the default has RAILS_ENV=production.
A note about subversion urls for the repository. SwitchTower accesses the repository twice during a deployment: first to check the latest version (run from the local system); second to actually check out that revision (run from the remote system). What that means is the repository needs to be accessible from both the system you deploy from and the system you deploy to. I was hoping to use the file:// url, but that’s a no go.
I’m too lazy to setup subversion’s http authentication, so that leaves svn+ssh://. SwitchTower users the Ruby Net::SSH module to perform all it’s functions. Net::SSH is smart enough to use the specified ssh-agent when doing it’s connections; however, it’s not smart enough to forward the agent connection. So SwitchTower will happily ssh into the remote host using the ssh-agent, but can’t use the agent when doing the svn checkout. That means it’s going to use the private ssh key on the remote server for the user who’s doing the deploy. As such, it’s either going to prompt for that key’s passphrase or prompt for the user’s system password if the key doesn’t exist. Until Net::SSH updates to allow forwarding the agent, there’s no way to use svn+ssh:// with SwitchTower without being prompted for a password.
One final problem. In SwitchTower::SCM there’s the default run_checkout that does the checkout and then adds an entry to the revisions.log for who did this deployment and when. The problem is that the last thing it does is chmod 666 #{log}. On my Debian/Linux system that command fails if you’re not the actual owner of the file. Same thing with re-linking current to the latest release. Hooks to the rescue:
task :before_deploy, :roles => :app do
run <<-CMD
/usr/bin/sudo /bin/chown #{ENV['USER']} #{deploy_to}/current;
/usr/bin/sudo /bin/chown #{ENV['USER']} #{deploy_to}/revisions.log
CMD
end
This only works though because both of us who do development/deployment have sudo privileges without password prompting. Jamis said he’d heard of others with this ownership/permissions problem, but hadn’t experienced it. I suspect it’s an OS/kernel issue. I haven’t investigated that though.
Posted in Ruby on Rails | 2 comments
