The in-progress Vagrant AWS has a lot of promise, especially for devops. The ability to test your Puppet or Chef scripts on an EC2 instance using Vagrant is very tempting. Unfortunately, it’s not yet quite stable enough to rely on, in my experience. Some errors seem to happen sporadically. Most are related to ssh, although running ssh manually works fine (either vagrant ssh or ssh user@host).
Sometimes, something as simple as mkdir fails without reason:
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!
mkdir -p '/vagrant'
Other times, rsync completes, but then it immediately terminates the instance:
[default] Rsyncing folder: /home/ben/aws-sandbox/ => /vagrant
[default] Terminating the instance...
I’m still hopeful that it can be useful to us in the future. Like I said, there’s a lot of promise in this young project.
At any rate, we took some time to research how to get SSH agent forwarding working, which is valuable for us when remote pairing. We were getting stuck with errors like this:
It turns out that vagrant itself ignores anything but identity files, which was key to getting agent forwarding to work. This can be inspected using vagrant ssh-config
It turns out that lib/vagrant/util/ssh.rb can be modified like so:
@@ -108,7 +108,7 @@ module Vagrant
# IdentitiesOnly option. Also, we don't enable it in plain mode so
# that SSH properly searches our identities and tries to do it itself.
if !Platform.solaris? && !plain_mode
- command_options += ["-o", "IdentitiesOnly=yes"]
+ command_options += ["-o", "IdentitiesOnly=no"]
# If we're not in plain mode, attach the private key path.
There’s a related change that can be made to make vagrant ssh-config match, but it seems to be cosmetic:
@@ -6,7 +6,7 @@ Host <%= host_key %>
IdentityFile "<%= private_key_path %>"
- IdentitiesOnly yes
+ IdentitiesOnly no
<% if forward_agent -%>
That was enough to get our SSH agent forwarding to work. These changes make sense in the context of AWS, but probably not in Vagrant at large. I’m tempted to make a pull request, but the above changes are a little half baked — and vagrant-aws still needs some fine tuning before the change can really be tested.
I recently helped an intern at Hedgeye work through a problem with a database query. Because I’m working in a separate timezone, I ended up making suggestions through a GitHub pull request. We discussed and decided that what I wrote was self-contained enough that I should re-post so it can help others.
There were lots of good questions (which I wish I had written down), including how to use it with iTunes, how to use it as a replacement for logrotate, how I was using Vagrant for testing, how to automate more than set of rules, etc.
South Shore Cultural Center, Chicago (Photo: Jeff Zoline CC BY-NC 2.0)
WindyCityRails was a lot of fun.
As I’ve done in the past, I took notes and put them into an open wiki on GitHub. Some quick stats: the wiki project is up from approx. 220 stars to 241 right now, and even got a few more contributors (~49 → 53).
Anyway, I thought I’d share some of the better talks:
Both David Chelimsky and Steve Klabnik contributed to the wiki, which was a nice surprise. :) Steve’s talk was really good, but hard to do it justice with any notes… I was happy to see that he annotated it.
I recently wrote a comment for “GitHub for Mac: Easier Updates”. Since it sums up my feelings on several subjects (including my feelings about the future of OS X), I thought I should repost it here.
Maybe more people use this than I realize, but I have to say I still don’t get this.
As a web developer myself, I tend to support web-based apps; perhaps the Mac app is popular with Mac/iOS developers? More can be done from the web interface, which works on Windows, Mac, and Linux. (Plus, the web UI always stays up to date.) The only additional feature this really seems to add is a “sync” button locally. Perhaps I’m missing something, but this is all that I take away from the feature list and what I’ve used of it.
To be honest, the direction in which OS X Mountain Lion is headed doesn’t thrill me. Since I’m contemplating a move from OS X back to Linux, it’s disappointing to see an interface for this closed system even being worked on. Such a huge amount of open-source projets are hosted on GitHub (including the Linux kernel itself). If I were to expect Linux support from anyone, it would be you guys. I can understand that OS X is likely a large market for GitHub users, but I would wonder about the portability of this app…
This would be much more compelling if it were an open-source interface for git repos, but I could understand how that might not be in GitHub’s best interest. (But imagine a GitHub tool built by the users, for the users…) Maybe I’m more of a git power user than I realize, but without at least support for a remote other than origin, multiple operating systems, etc., I can’t say this is something I’ll ever use. Making it open-source would be a bonus, although it seems unlikely at this point.
Maybe I’m just missing something, but other commenters here would seem to agree.
Update: By the end of the day, they deleted not only this comment, but many others that cast an unfavorable light on GitHub for Mac. (There was at least one other that had a function named shallWeUseThisSoft.)
In the interest of preservation, here are some other recently added comments that seem likely to be deleted:
Please do not distribute through the mac app store and if possible do not use an apple developer id to authenticate your apps so that we don’t end up with an ecosystem fully controlled by apple (see the gatekeeper non sense they are going to introduce in mountain lion).
Right now, we have some older, mostly-unused machines running a bunch of browsers attached to JSTD. While doing some maintenance today, I had an interesting idea: we need to support the browsers that are popular according to our analytics. That typically means the current and previous version, except for IE, which we support 7.0+ (9.0 is current).
So, we now have Chrome 16, 17 (current), and 18, along with Firefox 9, 10 (current), and 11.
Here’s some sample JSTD output from a Jasmine test suite we have:
Chrome 16.0.912.77 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (267.00 ms)
Chrome 17.0.963.56 Mac OS: Run 100 tests (Passed: 100; Fails: 0; Errors 0) (318.00 ms)
Chrome 17.0.963.56 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (196.00 ms)
Chrome 18.0.1025.39 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (209.00 ms)
Firefox 9.0.1 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (681.00 ms)
Firefox 9.0.1 Windows: Run 50 tests (Passed: 49; Fails: 1; Errors 0) (1598.00 ms)
Firefox 10.0 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (293.00 ms)
Firefox 10.0.2 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (260.00 ms)
Firefox 11.0 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (368.00 ms)
Microsoft Internet Explorer 7.0 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (2749.00 ms)
Microsoft Internet Explorer 8.0 Windows: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (2078.00 ms)
Microsoft Internet Explorer 9.0 Windows: Run 100 tests (Passed: 100; Fails: 0; Errors 0) (698.00 ms)
Safari 534.52.7 Mac OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (1553.00 ms)
Safari 6533.18.5 iPhone OS: Run 50 tests (Passed: 50; Fails: 0; Errors 0) (184.00 ms)