{"id":7809,"date":"2011-07-16T10:47:24","date_gmt":"2011-07-16T14:47:24","guid":{"rendered":"http:\/\/www.opticality.com\/blog\/?p=7809"},"modified":"2011-09-03T12:05:23","modified_gmt":"2011-09-03T16:05:23","slug":"installing-crashplan-on-a-pogoplug-pro","status":"publish","type":"post","link":"https:\/\/opticality.com\/blog\/2011\/07\/16\/installing-crashplan-on-a-pogoplug-pro\/","title":{"rendered":"Installing CrashPlan on a PogoPlug Pro"},"content":{"rendered":"

There are critical updates embedded in this post, added on 9\/3\/2011, all preceded with Update<\/strong>:. You can apply those instructions separately if you’ve already completed the rest of this installation. Updates will be marked with End Update<\/strong> to allow for multi-paragraph updates. I will strike-through<\/del> the parts that were replaced, so that you can safely ignore them if you’re going through this guide for the first time.<\/p>\n

PogoPlug<\/a> Pro is an amazing device (coupled with an amazing service). CrashPlan<\/a> is an amazing piece of software (and also provides a fee-based amazing service). I\u2019ve had both for a while and think very highly of them.<\/p>\n

To solve a number of my own problems (not caused by either service!), I decided to investigate marrying them (the PogoPlug device, with the CrashPlan software). To be slightly more accurate, I wanted the device to perform an additional function (beyond backups). I wanted it to be my primary DLNA<\/a> server.<\/p>\n

Caution<\/strong>: none of what follows is supported<\/strong> by either company. You will be voiding your PogoPlug warranty and CrashPlan does not<\/strong> support this configuration of their Linux software. Proceed at your own risk!<\/p>\n

My primary reason for installing CrashPlan on this device is to compensate for the pathetic<\/strong> upload speed provided by Time Warner, all of 485Kbps, shared with my wife, for normal Internet use, VoIP calls and backups. In other words, not really a useful real-time backup solution. Since we are often at other, very high-speed locations, I still believe that paying for the CrashPlan online backup service is the way to go (and gives me great comfort), but when I\u2019m home, I wanted a local solution (that didn\u2019t involve plugging in a hard drive to my laptop).<\/p>\n

Since I was able to do this, successfully, the instructions can be found on the Net. Since it took me way longer to find the various pieces, let alone get them to work, than I felt it should have, I\u2019m writing this (for myself, as well as for others who might give up more easily than I did). None of the credit goes to me, I\u2019m just collecting the wisdom of others in one place, hopefully an easy one to find.<\/p>\n

Update<\/strong>: All sections marked Update<\/strong>: that apply to Java and udev were courtesy of Ankit Mohan<\/a>. Ankit used this guide to get CrashPlan running on his PogoPlug, then dug in a lot more than I did to solve the problems I described. I am indebted to him. End Update<\/strong>.<\/p>\n

There are a number of Linux distributions available for the PogoPlug Pro (an ARM-based device). I chose Arch Linux<\/a> because it was the most prominent one I found and because it has a very good reputation independent of the PogoPlug. The specific ARM implementation<\/a> has it\u2019s own site, which is where I started my odyssey.<\/p>\n

After reading the overview on that page, I clicked on the Installation tab. The instructions there are extremely clear. The first time I followed them, the formatting of my external drive failed. I ended up formatting the drive while it was connected to a laptop running Linux, but all of the other instructions on that page worked. I will repeat them here, so that anyone who doesn\u2019t want to link off of this page can simply follow all the way through.<\/p>\n

You have to register your PogoPlug at my.pogoplug.com<\/a>. This is required, even though we will shortly be disabling the service, since this is the only way to get SSH access to the device. You will be able to reverse the process, returning the device to a full PogoPlug in the future, should you desire that, but it\u2019s not a dual-boot<\/em> situation where you decide which version you want it to be.<\/p>\n

Once you\u2019ve enabled SSH on the device, you can set your own password. The username will be root<\/strong>. The default password for a PogoPlug Pro is ceadmin<\/strong> (as noted, you can change it via the website, or once you log in, with the passwd<\/strong> command. Change it<\/strong>!<\/p>\n

One of the steps that they don\u2019t cover is discovering the IP address of your PogoPlug, so that you can SSH to it. In a home environment, this is relatively easy (for the geeks among us). You login to your router, look at the list of attached devices and easily spot it.<\/p>\n

I\u2019m installing the software on a second device as I type along. I\u2019m in an office environment and don\u2019t have access to the router. There are hundreds of devices in the office. I had to write down the MAC address of the PogoPlug, go over to a system administrator and ask him to search the DHCP log files for that MAC address. He did and I found out the address that was assigned to it. Whew.<\/p>\n

I successfully logged into the device, just to make sure it worked, while it was still an official PogoPlug. That step was optional, but comforting. Since the next step is to power down the device (which you can safely do by just pulling the power cord, especially if you have no hard drives attached yet), since I\u2019m logged in as root, I typed \/sbin\/halt<\/strong> instead, to be a little safer. Wait 60 seconds (for added safety), then pull the power cord.<\/p>\n

We\u2019re going to install Arch Linux on an external drive. The only thing that will be changed on the PogoPlug itself is the boot sector, which will now point to the external drive (that\u2019s what would need to be reversed to restore the PogoPlug functionality).<\/p>\n

With the PogoPlug powered down, attach only<\/strong> the drive that you intend to install Arch Linux on. This way there will be no confusion or errors. Later on, if you want multiple drives attached (for backups and\/or media files) it will be easy to add them. I am using a 2TB Fantom Drives to do my install.<\/p>\n

Once the drive is attached (and turned on), plug the power cord back into the PogoPlug and wait for it to boot. Then SSH back on to it (the root password will be what you set it to, or ceadmin if you didn\u2019t change it). The box is still running the PogoPlug software, with your drive attached to it.<\/p>\n

Type: killall hbwd<\/strong><\/p>\n

That will stop the PogoPlug software from running on the box. We don\u2019t want it to interfere with the installation of Arch Linux. You might have to wait a bit for the service to stop. If you want to check, type the following:<\/p>\n

ps | grep hb<\/strong><\/p>\n

The only result should your grep<\/em> process. Then, you can type:<\/p>\n

\/sbin\/fdisk \u2013l<\/strong><\/p>\n

The last line of output should start with \/dev\/sda1<\/strong>. That means your disk drive was found and has a partition on it (it\u2019s likely formatted already). We are about to erase everything<\/strong> on the disk, so be absolutely sure that you want to continue with this adventure before doing that! If you\u2019re ready, type:<\/p>\n

\/sbin\/fdisk \/dev\/sda<\/strong><\/p>\n

That will bring up the fdisk program on the entire drive (sda as opposed to sda1 which is the first partition). You will now have a prompt that is directly from the fdisk program. We will type a number of one character commands<\/strong>. Right after you type the character and press enter, fdisk will go off and do what you asked it to.<\/p>\n

Type: o<\/strong><\/p>\n

That will clear the partition table so that the disk will become unusable (for the moment). As you can see from the messages, nothing has been committed in stone as yet (very soon). This has modified an in-memory copy of the partition table.<\/p>\n

Type: p<\/strong> (to verify the above, that there are now no partitions)<\/p>\n

Type: n<\/strong> (press Enter, this will create a new partition)<\/p>\n

Type: p<\/strong> (to make it a Primary partition. At this point, I\u2019ll stop saying \u201cPress Enter\u201d, but you still have to!)<\/p>\n

Type: 1<\/strong> (to make this partition #1<\/a>)<\/p>\n

At the next two prompts (First and Last cylinders), just Press Enter<\/strong> to accept the defaults (you are making the entire disk available as the first and only partition).<\/p>\n

Now comes the destructive part. This will actually wipe out any data you had on the disk (but still doesn\u2019t modify the PogoPlug in any way!).<\/p>\n

Type: w<\/strong> (this writes the partition table back out to the disk)<\/p>\n

You are now back at the command line. If you\u2019re a paranoid type (or just careful), you can verify that things worked by repeating the fdisk command and listing out the partition table, all in one shot:<\/p>\n

\/sbin\/fdisk \u2013l<\/strong><\/p>\n

This is the output on my system:<\/p>\n

Device Boot\u00a0\u00a0\u00a0\u00a0\u00a0 Start\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 End\u00a0\u00a0\u00a0\u00a0\u00a0 Blocks\u00a0 Id System
\n\/dev\/sda1\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 1\u00a0\u00a0\u00a0\u00a0\u00a0 243201\u00a0 1953512001\u00a0 83 Linux<\/p>\n

2TB, in one partition, marked for use by a Linux system. Now we need to actually create the filesystem, which in our case will be an ext3<\/strong> one. This will require downloading some commands that will need to be executed. Here are the steps:<\/p>\n

Type: sync<\/strong> (to flush any filesystem changes)<\/p>\n

Type: cd \/tmp<\/strong> (to change to a temporary, writable working directory)<\/p>\n

Type: wget http:\/\/archlinuxarm.org\/os\/pogoplug\/mke2fs<\/strong> (to retrieve the program mke2fs)<\/p>\n

Type: chmod 755 mke2fs<\/strong> (to make it executable)<\/p>\n

Type: .\/mke2fs -j \/dev\/sda1<\/strong> (the leading dot is critical. This will format the partition to an ext3<\/strong> filesystem)<\/p>\n

The above command can take quite a while, depending on the size of your external drive. This is the command that failed for me on my first PogoPlug, so I ended up having to detach the drive, connect it to a Linux laptop, perform the same exact command as above (which was already available, I didn\u2019t need the wget part) and then reattach the drive to the PogoPlug.<\/p>\n

Note<\/strong>: it failed for me again. I was able to format it using the built-in \/sbin\/mkfs.ext2 command (passing in the \u201c-j\u201d flag), but I didn\u2019t trust that it was building a true ext3 filesystem (ext2 + journal). So, I disconnected the drive from the PogoPlug, attached it to a VirtualBox VM on my Win7 laptop, and formatted it there as a real ext3. Took forever<\/strong>, but it worked.<\/p>\n

Whether the mke2fs command worked for you or whether you had to format the drive separately, like I had to on two separate installations, you\u2019re now ready to install Arch Linux on the external drive. You should already (still) be in \/tmp, but to make sure, feel free to type: cd \/tmp<\/strong><\/p>\n

Type: wget http:\/\/archlinuxarm.org\/os\/oxnas\/oxnas-install.sh<\/strong> (that retrieves the install script)<\/p>\n

Type: chmod 755 oxnas-install.sh<\/strong> (this makes the script executable)<\/p>\n

Type: .\/oxnas-install.sh<\/strong> (this starts the script, which will send lots of messages to your terminal window. It also downloads the root filesystem image, which is roughly 129MB, so it can take a while if you don\u2019t have a fast network connection.)<\/p>\n

When it\u2019s finally done (took between 5-10 minutes on a very high speed connection in the office), the output should look like this if it succeeded (at the very end):<\/p>\n

#############################
\n## Looks good!
\n# Sync …
\n# Unmount
\n# Reboot to enter into Arch Linux ARM<\/p>\n

Note the looks good!<\/strong> and then the instructions to reboot. That\u2019s what we\u2019re going to do next.<\/p>\n

Type: \/sbin\/reboot<\/strong> (cross fingers!) \"Winking<\/p>\n

This will immediately disconnect you from the terminal window you were in. You need to wait a few minutes for the orderly shutdown of the PogoPlug, followed by the booting up of Arch Linux ARM. You can watch the lights on your external drive to see when there is activity on it, indicating that the booting has begun. When the light settles down, the boot is complete.<\/p>\n

We\u2019re ready to log back in (this time to the new operating system), and the password has been changed to a new default one. The user is still root<\/strong>, but now so is the password (root<\/strong>), which you should change right away with the passwd<\/strong> command. It\u2019s quite possible that the IP address of the box has changed<\/strong> during the reboot, so please verify the new (or existing) one, before SSH\u2019ing back on.<\/p>\n

If the IP address did not<\/strong> change, then you might have to remove the old key associated with it, or ssh might refuse to connect, thinking it\u2019s a security violation. If you get the same IP address again, you may need to run the following command first (on your local machine, the one you are SSH\u2019ing from):<\/p>\n

Type: ssh-keygen -R 192.168.1.123<\/strong> # (using your device’s IP, which won\u2019t likely be 192.168.1.123)<\/p>\n

The following First Steps page<\/a> on the Arch Linux ARM Wiki explains the above, and gives you a number of other useful tips. I followed them religiously the first time through, but I changed the order a bit this time around and it saved a bit of typing (or I think it did).<\/p>\n

Instead of going through the above, this time I updated all of the packages right away. I believe that it installed openntpd and updated the \/etc\/rc.conf file (one of the first steps that I performed manually the last time). You can do what I did, then check if openntpd is installed and running.<\/p>\n

Type: pacman \u2013Scc<\/strong> (clear out old packages. I said YES to the first, and NO to remove unused repositories)<\/p>\n

Type: pacman \u2013Syu<\/strong> (this will do a large update, first syncing the repositories, then updating all packages)<\/p>\n

Now comes a crazy part. I say crazy because by the time you read this, perhaps the maintainers of Arch Linux ARM will have updated the repositories and this will no longer be necessary. Then people will think I\u2019m an idiot, so be it, I\u2019m putting it in here because it can\u2019t hurt!<\/del><\/p>\n

Type: pacman \u2013Sy udev-compat<\/strong> (to fix a problem with udev + syslog-ng taking up 100% of your CPU)<\/del><\/p>\n

The 100% cpu problem might be happening as you read this (if you\u2019ve done the previous steps already). It might be filling up your disk in \/var\/log as well. We can check that in a minute (here\u2019s the thread that helped me<\/a>: there\u2019s a typo in that thread, \u201csleep3\u201d should be \u201csleep 3\u201d), but first, let\u2019s do a few more things and then reboot.<\/del><\/p>\n

Update<\/strong>: Type pacman -Sfy udev-oxnas udev-automount<\/strong> (this fixes the udev problem noted above, now struck-through. I added the f<\/strong> option to pacman to force the removal of the bad udev, or udev-compat that you installed if you’ve already completed these instructions. You will have to say Y to the prompt to remove<\/strong> udev, which defaults to N.) End Update<\/strong>.<\/p>\n

Let\u2019s create a swapfile:<\/p>\n

Type: dd if=\/dev\/zero of=\/swapfile.img bs=1M count=1024<\/strong> #for a 512MB swapfile, use count=512<\/p>\n

Type: mkswap \/swapfile.img<\/strong> (to turn the file we just created into a valid swapfile)<\/p>\n

Type: swapon \/swapfile.img<\/strong> (to see whether you get any errors, you shouldn\u2019t)<\/p>\n

Now we\u2019ll edit \/etc\/rc.local (use your favorite editor, I use \u201cvi\u201d, you might prefer \u201cnano\u201d) to add exactly four<\/del> one lines<\/del> after the comments:<\/p>\n

swapon \/swapfile.img
\nkill $(pidof udevd)<\/del>
\n sleep 3<\/del>
\n udevd &<\/del><\/strong><\/p>\n

The first line turns the swap on after each reboot. The next three lines kill the bad udev (even after updating the udev-compat the process sometimes misbehaves at boot), then sleeps for three seconds and restarts udev, which makes it seem to behave correctly so far.<\/del><\/p>\n

OK, time to reboot and see if we have a stable system:<\/p>\n

Type: sync<\/strong> (flushes the memory to disk)<\/p>\n

Type: reboot<\/strong> (you should lose your ssh connection right away)<\/p>\n

Wait until the disk activity settles down a bit, then ssh back in.<\/p>\n

Type: top<\/strong> (to see what processes are running. If udev and\/or syslog-ng are at the top, something isn\u2019t good)<\/p>\n

Type: q<\/strong> (to exit top, whenever you\u2019re done looking around)<\/p>\n

You can follow any of the additional instructions for setting up a user, adding sudo, changing TimeZone settings, etc. All are linked from the First Steps above.<\/p>\n

Since the reason I did this was to install DLNA<\/a>, I\u2019ll cover that first (it\u2019s really short), then we\u2019ll move on to the heavier CrashPlan setup. Skip the next few lines if you have no interest in DLNA.<\/p>\n

Type: pacman -Sy minidlna jack<\/strong> (this names two packages, but will install something closer to 44, with dependencies)<\/p>\n

You should edit the file \/etc\/minidlna.conf and change any variables (where the files are stored, where to store the DB, what you want to call your DLNA server, etc.). You can read the Wiki page (linked above) to see the more important entries.<\/p>\n

Then add the word minidlna<\/strong> at the end of the DAEMONS= line, which should be at the bottom of the \/etc\/rc.conf file. This will auto-start the DLNA server every time the PogoPlug is booted. To start it right now, type: \/etc\/rc.d\/minidlna start<\/strong><\/p>\n

Update<\/strong>: I discovered two things. 1) Many devices, e.g. Google TV and Sony Bravia TV, don’t show any of the files with a filetype of FLV. It turns out that if you simply rename the filetype to AVI (probably others), the files play fine (assuming they were encoded with H.264). 2) After you populate your media directory, run the following command and wait patiently: minidlna -R<\/strong> to force a build of the database. You probably want to kill all minidlna processes when this is done and start it again (minidlna<\/strong> alone on the command line is good enough). You can tail the minidlna.log file (in your database directory) to know when the database rebuild is done. End Update<\/strong>.<\/p>\n

Whew. Finally ready for the very tricky and long installation of CrashPlan. This is not for the faint of heart, nor is it in any way supported by CrashPlan. It works for me (and obviously others), but you\u2019ll have to be the judge as to whether the hassle is worth it for you.<\/p>\n

Let\u2019s start with crediting the place that got me unstuck, the CrashPlan support forums! Kudos to CrashPlan for allowing this type of discussion on their forums, even though they don\u2019t support this configuration. Here\u2019s the thread<\/a>, but all of the interesting bits are in the long comment by Torbjorn<\/strong>. It was really hard for me to find, because I was searching for the word PogoPlug. This solved the problem for Sheeva (the baseline of the Pogo), but it\u2019s not quite identical.<\/p>\n

Type: pacman \u2013Sy openjdk6 cpio<\/strong> (we need to get a working Java installed and CrashPlan will require the cpio package separately)<\/p>\n

The next step (according to Torbjorn) is to download an ancient (2005) libjtux source package, apply a patch and compile it. He supplies a pointer to the source (amazingly, still available) and the patch file is available as an attachment to his comment. You can grab both from the the thread linked above. If you do, you will likely have to download a bunch of development packages (using pacman), starting with gcc.<\/p>\n

Instead, I will attach the completed libjtux.so<\/a> that I built (following those instructions), to save you time, effort and potential errors. I also just grabbed it from my first build and applied it to my second, for the same reasons.<\/p>\n

Now we need to install CrashPlan itself by heading to the download page for Linux<\/a>. I right-clicked on the download button (currently version 3.0.3, but the software auto-updates after the first install). I copied the link location. Back on the PogoPlug:<\/p>\n

Type: wget http:\/\/download.crashplan.com\/installs\/linux\/install\/CrashPlan\/CrashPlan_3.0.3_Linux.tgz<\/strong> (that should work, but starting at the http part, just paste in the link you copied if it\u2019s newer than 3.0.3)<\/p>\n

Type: cd \/tmp<\/strong><\/p>\n

Type: tar \u2013xzf WHEREVER_YOU_DOWNLOADED_THE_CRASHPLAN_FILE<\/strong> (which could be \/tmp to simplify matters)<\/p>\n

Type: cd CrashPlan-install<\/strong><\/p>\n

Type: .\/install.sh<\/strong> (all of the defaults seem reasonable to me, though I did put my archives in another directory. You will need to page through the license file with the space bar and accept that as well. The init scripts on Arch are in \/etc\/rc.d, which is the other thing I changed from the default.)<\/p>\n

When this is done, it will report that it has successfully started the CrashPlan service. It did not<\/strong>. That\u2019s because we haven\u2019t yet replaced the libjtux.so that comes with CrashPlan. The problem is that it was compiled with an Intel i386 architecture.<\/p>\n

Type: cd \/usr\/local\/crashplan<\/strong><\/p>\n

Type: mv libjtux.so libjtux.so-ORIGINAL<\/strong> (no real need to save it, other than to memorialize the changes we\u2019re making)<\/p>\n

Type: cp WHERE_YOU_DOWNLOADED\/libjtux.so .<\/strong> (this copies my version from wherever you downloaded it, or you can right click my link above, and wget<\/strong> directly from my website to this directory)<\/p>\n

Torjborn mentions editing a file to add jna.jar to it. I didn\u2019t need to do that, and the directory he references doesn\u2019t exist. I think it\u2019s from a different installation of Java (for the original Sheeva) and not necessary when using the openjdk6 package.<\/p>\n

Update<\/strong>: This next part solves the timing delays, apparently among a number of other issues that I wasn’t even aware of! Once again, thanks to Ankit for figuring this all out.<\/p>\n

You will need the nss<\/strong> package installed. Mine was there after the major update above. If you don’t have it installed, type: pacman -Sy nss<\/strong><\/p>\n

<\/strong>The file that’s missing from openjdk, which is causing all of the problems with CrashPlan, is libjnidispatch.so. It’s part of the jna package (Java Native Access). You’ll have to download a Debian package and extract the file.<\/p>\n

Select a location near you from this link: http:\/\/packages.debian.org\/sid\/armel\/libjna-java\/download<\/a>. In the US, I chose this link directly: http:\/\/ftp.us.debian.org\/debian\/pool\/main\/libj\/libjna-java\/libjna-java_3.2.7-4_armel.deb<\/a><\/p>\n

Assuming you downloaded that file to \/tmp, here are the commands to extract the file we’re interested in:<\/p>\n

Type: cd \/tmp<\/strong><\/p>\n

Type: ar vx libjna-java_3.2.7-4_armel.deb<\/strong> (this will extract three files, one of which contains the file we’re interested in)<\/p>\n

Type: tar -xzf data.tar.gz<\/strong> (this will unpack the tar file, creating a series of directories in \/tmp\/usr)<\/p>\n

First we need to create the target directory for this. Since mkdirs (make nested directories) doesn’t exist by default, we’ll execute a number of consecutive mkdir commands. Hint: you can hit up-arrow after each command and just append the next directory name in the series of mkdir commands.<\/p>\n

Type: cd \/usr\/local\/crashplan\/lib<\/strong><\/p>\n

Type: mkdir com<\/strong><\/p>\n

Type: mkdir com\/sun<\/strong><\/p>\n

Type: mkdir com\/sun\/jna<\/strong><\/p>\n

Type: mkdir com\/sun\/jna\/linux-arm<\/strong><\/p>\n

<\/strong>Type: cp \/tmp\/usr\/lib\/jni\/libjnidispatch.so com\/sun\/jna\/linux-arm\/<\/strong> (now we have the file in the correct directory)<\/p>\n

Type: cp -p jna-3.2.5.jar jna-3.2.5.jar-ORIGINAL<\/strong> (this isn’t strictly necessary. Aside from documenting our change, it allows us to recover from errors more easily)<\/p>\n

Type: jar uf jna-3.2.5.jar com\/sun\/jna\/linux-arm\/libjnidispatch.so<\/strong> (this is the critical step, inserting the library into the jar file that CrashPlan uses. I’m not sure the com\/sun\/jna\/linux-arm directory creation is necessary, but better safe than sorry)<\/p>\n

It seems that in addition to solving the timing issues (long delays in starting up), this actually dispatches (duh) maintenance tasks like pruning, synchronizing, etc. It’s all good, but there is a side-effect (well worth it!) that the Java process now takes up a significant amount of CPU, even when backups aren’t active, since it appears to actively maintain the system. Previously, Java would consume 0% of the cpu when it wasn’t backing up.<\/p>\n

End Update<\/strong>.<\/p>\n

We\u2019re ready to start CrashPlan (at least to see if it comes up and stays up). We can do it by hand, but I am going to add it to the DAEMONS list at the end of \/etc\/rc.conf (like we did with minidlna) and reboot the machine to ensure that it comes up on it\u2019s own. The daemon name to add right after minidlna<\/strong> is crashplan<\/strong> (lower case).<\/p>\n

Type: \/sbin\/reboot<\/strong><\/p>\n

If you did everything above correctly, when you log back in, there should be a java process running, with CrashPlan as the application. It can a few minutes to completely initialize. In that case, we\u2019re done, right? Wrong<\/strong>! CrashPlan is indeed sitting there, waiting to go to work, but it needs to be configured to allow your machine(s) to start backing up to it. Under normal circumstances, this would be trivial to do, but since the PogoPlug is a headless server, we have to jump through a few final hoops.<\/p>\n

Once again, CrashPlan support to the rescue<\/a> (again, for a completely unsupported feature<\/em>). If you want to understand the details, or are enough of a techy to prefer the theory, I urge you to just read the CrashPlan document and skip to the final section of this post. If you want fewer steps (and warnings) to follow, I\u2019ll give you the bare necessary steps here.<\/p>\n

They key is that on every machine that has CrashPlan installed, there are two programs: 1) the server that does all the work and 2) the GUI (graphical user interface) that connects to the server when launched, and allows you to configure and monitor the server process. On the PogoPlug, we only have #1<\/a>. The good news is that the GUI speaks to the server over the network. By default, that network is local to the machine that the server is running on, but with some ssh magic (and a little editing of a configuration file), we can make that a remote connection.<\/p>\n

All of the work is going to be done on your desktop or laptop, where you already (presumably) have CrashPlan running. This is likely the machine that you want to backup to the PogoPlug. Let\u2019s just call it laptop<\/strong> so that it\u2019s obvious it isn\u2019t the PogoPlug.<\/p>\n

On laptop<\/strong>, make sure that the CrashPlan GUI isn\u2019t running. If it is, exit the application. Find the conf<\/strong> directory associated with CrashPlan on your system. On my Windows 7 x64 machine, it\u2019s this directory: \u201cc:\\Program Files\\CrashPlan\\conf<\/strong>\u201d. In that directory is a file called ui.properties<\/strong>. Edit that file. The following line is in that file: \u201c#serviecPort=4243\u201d. This line is commented (#), because 4243 is the default<\/em> value. You can leave that line commented and add a line below it:<\/p>\n

servicePort=4200<\/strong><\/p>\n

(You could also remove the comment and replace 4243 with 4200, but I recommend adding a new line.)<\/p>\n

Save the file to disk. While still on laptop<\/strong>, open a terminal window and execute the following SSH command (if you\u2019re using Putty to do this on Windows, rather than cygwin, I recommend reading the post back on the CrashPlan site).<\/p>\n

ssh -L 4200:localhost:4243 user@192.168.5.71<\/strong><\/p>\n

In the above command, substitute your username (or root) where I put in \u201cuser\u201d and the IP address of your PogoPlug where I put in the \u201c192.168.5.71\u201d. This command makes port 4200 on laptop<\/strong> magically redirect to port 4243 on the PogoPlug, which is where the CrashPlan server is listening by default already.<\/p>\n

Now launch the CrashPlan GUI on laptop<\/strong> by double-clicking the icon (on Windows, it\u2019s probably in your system tray). You should see a request to create a new CrashPlan account (free) or log in to an existing one. Since I already have one (and presumably you do too), just put in your email address and password. It took quite a while for it to log in and download the configuration, but it worked. I think when I first tried it on my first PogoPlug it actually timed out, but worked the second time.<\/p>\n

Once that\u2019s done, you can exit the GUI, as all of the defaults are exactly what we want\/need. The only exception to that is if you want to let others (that aren\u2019t part of your account) backup to your PogoPlug. Then you will need to write down the CODE to enable that (it\u2019s toward the bottom of the front page on the GUI and also on a Settings tab).<\/p>\n

You can now exit from the ssh session that was started above (Type: exit<\/strong> or hit Ctrl-d in that terminal window).<\/p>\n

Once the GUI is shut down, edit the ui.properties<\/strong> file again and delete<\/strong> the extra line we added with \u201cservicePort=4200\u201d (or place the comment \u201c#\u201d back in front of it). Save the file.<\/p>\n

Launch the GUI again. This time it will connect to the local CrashPlan server on laptop<\/strong>. Now click on Destinations<\/strong> (bottom left entry on the left-hand navigation). Then click on the icon labeled Computers<\/strong> in the center (the PogoPlug is a real computer<\/em>!). Whatever you called your device should be in your list, no code necessary, since you should have used the same account<\/em> on both machines. If you didn\u2019t name your device, then Arch Linux ARM defaults your host name to alarm<\/strong> (get it? A<\/strong>rchL<\/strong>inuxARM<\/strong>?).<\/p>\n

Now you\u2019re truly done. If you have a large amount to backup, it could take a couple of days to complete the first backup, even though it\u2019s on a LAN. It will also alternate between the various backup locations (including CrashPlan Central), which is one of the reasons it will be somewhat slowed down.<\/p>\n

For reasons I can\u2019t explain, it can take a very long time to start the initial backup, even if you pause the other locations. The GUI correctly communicates with the server instantly, since I can see the correct directory created on the PogoPlug, but the destination still shows up as unavailable<\/em> for some period of time. Eventually, it gets going, and appears to be quite reliable from that point on.<\/del><\/p>\n

Update<\/strong>: I struck out the previous paragraph since I’m hopeful that with the addition of libjnidispatch.so to the jna jar file, you won’t experience the long startup delay.<\/p>\n

cp -p jna-3.2.5.jar jna-3.2.5.jar-ORIGINAL<\/p>\n","protected":false},"excerpt":{"rendered":"

There are critical updates embedded in this post, added on 9\/3\/2011, all preceded with Update:. You can apply those instructions separately if you’ve already completed the rest of this installation. Updates will be marked with End Update to allow for multi-paragraph updates. I will strike-through the parts that were replaced, so that you can safely […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"activitypub_content_warning":"","activitypub_content_visibility":"","activitypub_max_image_attachments":4,"activitypub_interaction_policy_quote":"anyone","activitypub_status":"","footnotes":""},"categories":[3,2,294,20],"tags":[372,1029,1028,237,1027,1373,1370],"class_list":["post-7809","post","type-post","status-publish","format-standard","hentry","category-3","category-2","category-technology","category-tv","tag-backup","tag-crashplan","tag-dlna","tag-linux","tag-pogoplug","tag-technology","tag-tv"],"_links":{"self":[{"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/posts\/7809","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/comments?post=7809"}],"version-history":[{"count":4,"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/posts\/7809\/revisions"}],"predecessor-version":[{"id":8569,"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/posts\/7809\/revisions\/8569"}],"wp:attachment":[{"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/media?parent=7809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/categories?post=7809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/opticality.com\/blog\/wp-json\/wp\/v2\/tags?post=7809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}