Ok, so i think many of us are looking for a way to back-up a DroboFS to the “cloud” without having software running on a different machine.

I ran across www.crashplan.com and looks like a reasonable service and has a linux software that can be headless.

Headless Crashplan

Looks like it just needs java to run, can any of you programmers check and see if this can be compiled for a DroboFS?

‘just’ is a gentle way of putting it. There is a link to Java VM floating around the forums, so it might be quite easy.

Cross-compiling a JVM is a huge undertaking. I have looked at it, and the procedure seems to be long and quite complicated.

According to your link Java runs on drobo without cross compiling. Looks like it just needs to be bundled with crashplan and then crashplan modified to utilize java bundled with it (admittedly this is probably a over simplified way if looking at it)

Actually, what the link says is that Oracle is kind enough to give us an ARM port of their JVM. As you can imagine, that VM comes with all kinds of strings attached.

For instance, it is not possible to use that VM to create a DroboApp, since it is not licensed for further distribution of any kind. Therefore, no “bundling” allowed.

The ideal would be to get OpenJDK, which is basically the GPL-licensed version of that same Java VM, and cross-compile it for the Drobo. Once you get that, then you are able to bundle it with whatever you wish. But as I mentioned before, the steps to do that seem a bit overwhelming.

Nothing prevents you from making a one-shot deployment using the Oracle’s version, though. As you said, it should be simple enough (assuming the Oracle VM is easy to install on the FS).

Ricardo would it be possible for you to assist me in attempting to set this up?

EDIT:: I’ve already contacted CrashPlan, and they told me to add it as a feature request, went to the site and it looks to already be a feature request dated over a year and half ago, so i doubt we will ever see an official DroboApp from them.

I got bad news for you. I managed to unpack Crashplan 3.0.3 (from the .com website), and the problem is that their so-called java client actually uses a lot of JNI libraries.

In other words, although it is a Java app, it requires a bunch of platform-dependent native libraries. In particular, I have seen .so files for JNIWrapper and Jtux. Jtux seems to be cross-compilable (it is open-source), but JNIWrapper isn’t.

Sorry, but I guess we’re back to square one.[hr]

My guess the reason for this is that one of the closed source libraries they use (JNIWrapper) has never been ported to ARM.

Does this help at all? Crashplan on QNas

Not much, unfortunately. I suspected that Jtux could be cross-compiled, being open source and all that.

There is a world of difference between the QNAS (which has been hacked to run a complete Debian distro), and the FS (which runs some trimmed down Linux OS).

I have looked at that, and to recompile Jtux you need libjna, which uses libjnidispatch, which uses libffi, which may use something else (haven’t checked). As you can see it is a pretty big endeavor.

Sorry, we’re not much closer to a solution.

First i want to thank you for your help, and second i want you to take a look at Wuala Linux Client. Please also look at these sites Wuala ARM, Wuala init.d, Setting up Wuala, Wuala Headless.

From the looks of it this has worked on ARM based systems before, although it uses java it doesn’t seem to use the extra’s you mentioned before. Although this isn’t the same type of service as crashplan it is still something.

Ugh, I hate being the negative nancy around here, but Wuala won’t work either.

From your first link: “Required Packages: java-1_6_0-sun, libfuse2, fuse, xdg-utils”

Fuse (http://fuse.sourceforge.net/) is a pretty cool solution for mounting pseudo-filesystems, like the one created by Wuala. The problem is fuse requires a special module to be compiled with the Linux kernel. And, surprise surprise, the DroboFS’s kernel does not have it.

The worst part is that I have tried compiling extra modules for the kernel, but so far I have not yet been successful. It seems that the way the DroboFS OS is loaded at boot time basically prevents loading modules. :frowning:

I might be wrong, and someone with a better understanding of the Linux kernel can chime in and help us figure this one out, but until then this one is also a dead-end. I would say even deader than Crashplan, since Crashplan is just a lot of work, while this one may in fact be impossible (without recompiling and reflashing the FS kernel).