Back again
Things have been busy for the last week or so, especially at Resolver, where we are moving inexorably toward a public launch. Normal blogging service will be resumed shortly.
Project: Automated offsite backups for an NSLU2 -- part 13
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9, Part 10, Part 11, Part 12.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. With suprisingly little effort, I've managed to get a tool called s3sync running on the "slug" (as it's known). s3sync is a Ruby script, so in order to run it, I had to install Ruby, which in turn meant that I had to replace the slug's firmware with a different version of Linux, called Unslung. Once all of this was done, I just had to set up the appropriate directory structures and certificates so that the sync tool could use SSL, and write a simple upload/download script. All of this worked pretty much as advertised in the tools' respective documentation -- for the details, see the previous posts in this series.
My final step had been to set up a cron job to run the upload script, but it had failed, not logging anything. In order to debug, I ran the upload script directly from the command line, and left it to run overnight, copying a large set of directories to S3.
Project: Automated offsite backups for an NSLU2 -- part 12
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9, Part 10, Part 11.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. With suprisingly little effort, I've managed to get a tool called s3sync running on the "slug" (as it's known). s3sync is a Ruby script, so in order to run it, I had to install Ruby, which in turn meant that I had to replace the slug's firmware with a different version of Linux, called Unslung. Once all of this was done, I just had to set up the appropriate directory structures and certificates so that the sync tool could use SSL, and write a simple upload/download script. All of this worked pretty much as advertised in the tools' respective documentation -- for the details, see the previous posts in this series.
My final step in my last post was to set up a cron job to synchronise quite a lot of data up to S3 overnight. This post covers what I found the next day.
MSBuild WTF: "The error was:"
Here's a fun one for anyone who uses msbuild (at least, v2.0.50727). Create a project file like this:
<Project DefaultTargets="Foo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Foo">
<Exec Command = "echo Hello!" />
</Target>
</Project>
From a command prompt, run the project; you will get a the effect you would expect.
Now replace the word "Hello" with "The error was: something random". Run it again.
C:\\Dev\\Resolver>msbuild foo.proj
Microsoft (R) Build Engine Version 2.0.50727.42
[Microsoft .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation 2005. All rights reserved.
Build started 15/11/2006 17:50:22.
__________________________________________________
Project "C:\\Dev\\Resolver\\foo.proj" (default targets):
Target Foo:
echo The error was: something random
EXEC : The error was: something random
C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
Done building target "Foo" in project "foo.proj" -- FAILED.
Done building project "foo.proj" -- FAILED.
Build FAILED.
EXEC : The error was:
C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
0 Warning(s)
2 Error(s)
Time Elapsed 00:00:00.09
C:\\Dev\\Resolver>
Fuzzyman and I bumped into this one at work today; our continuous integration server, which watches our Subversion repository and checks out, builds, and tests any code changes it sees, had reported a failure despite the fact that none of the tests had failed. It turned out that one test was quite innocently printing out the text "The error was: " followed by some logging information; it wasn't an error at all. As far as I can tell, the statement that the echo command exited with code -1 is absolute nonsense.
This behaviour is not documented anywhere that we were able to find; I can only assume it was added for some specific purpose in the context of Visual Studio...
Project: Automated offsite backups for an NSLU2 -- part 11
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9, Part 10.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. With suprisingly little effort, I've managed to get a tool called s3sync running on the "slug" (as it's known). s3sync is a Ruby script, so in order to run it, I had to install Ruby, which in turn meant that I had to replace the slug's firmware with a different version of Linux, called Unslung. All of this worked pretty much as advertised in the tools' respective documentation -- for the details, see the previous posts in this series.
Having confirmed that s3sync worked as I'd expect it to, I needed to install it
in a sensible place -- I'd previously just put it in /tmp -- set it up so that
I could use SSL to encrypt the data while it was on its way to Amazon, and then
write a script to synchronise at least one of the directories I want backed up.
I'd then be able to test the script, schedule it, test the scheduling, and then
I'd be done!
Project: Automated offsite backups for an NSLU2 -- part 10
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. With suprisingly little effort, I've managed to get a tool called s3sync running on the "slug" (as it's known). s3sync is a Ruby script, so in order to run it, I had to install Ruby, which in turn meant that I had to replace the slug's firmware with a different version of Linux, called Unslung. All of this worked pretty much as advertised in the tools' respective documentation -- for the details, see the previous posts in this series.
As all of the pieces were in place, I next needed to do some simple tests to make sure it could handle the kind of files I wanted it to back up. In particular, I wanted it to be able to handle deep directory hierarchies, and to remember user and group ownership and file permissions.
Project: Automated offsite backups for an NSLU2 -- part 9
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8.
I'm setting up automated offsite backups from my NSLU2 to Amazon S3. The tool I need to use to make this happen is called s3sync; it's a Ruby script, so in order to run it, I had to work out some way of installing Ruby. In order to do that, I had to replace the slug's firmware with a different version of Linux, called Unslung; once that was done, getting Ruby up and running wasn't too tricky. The next step was to get s3sync itself to work.
Christmas has come early
I read Make 6 last week -- a bit late, I know -- and fell immediately in love with the idea of BEAM robotics, simple robots that can be build at home with simple tools, but display complex behaviour. Last Wednesday I placed an order with Solarbotics for the components I needed to build the "Trimet" robot described in the magazine, and today it was delivered -- not at all bad for something that was shipped from Canada!
Given that my Dremel tool was delivered today as well -- oddly enough, Tesco.com (a supermarket) had the best UK price I could easily find -- it's all I can do to hold myself back from building a robot or two this evening... but I'll be strong, and will finish the NSLU2 project first.
Project: Automated offsite backups for an NSLU2 -- part 8
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7.
I've discovered that in order to get automated offsite backups from my NSLU2 to Amazon S3, I have to get it to run Ruby so that it can run s3sync. Installing Ruby required the slug's firmware to be upgraded to a new version of Linux, called Unslung, so I did that -- and I also installed s3sync on an Ubuntu machine as a dry run. Both of these worked out OK, so the next step was to get the Ruby language itself running under the Unslung firmware -- and importantly, to make sure that Ruby had the OpenSSL package installed; the latter had proven non-obvious under regular Linux, so I was expecting problems on Unslung, which is, after all, a cut-down version of the operating system.
Project: Automated offsite backups for an NSLU2 -- part 7
Previously in this series: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6.
I've discovered that in order to get automated offsite backups from my NSLU2 to Amazon S3, I have to get it to run Ruby so that it can run s3sync. I've installed the latter on a Ubuntu machine as a dry run, and it all looks good -- so now I need to get Ruby onto the slug, and the first step in that direction is to install Unslung.