CrashPlan Plugin

 

The plugin can be download from the Unraid Plugin Wiki Page: http://lime-technology.com/wiki/index.php?title=UnRAID_Plugins

 

Instruction on how to connect can be found at http://lime-technology.com/wiki/index.php?title=CrashPlan#Configuring_the_Crashplan_engine_from_a_Windows_Machine

 

• Reboot or run "installplg /boot/config/plugins/crashplan-0.1-i468-1atv.plg"
  
• Settings can be configured under the Settings Tab.
  
• Automatically tar's CrashPlan for quick install on reboot
  
• Start and Stop CrashPlan with Array

 

I recommend running  "installplg /boot/config/plugins/crashplan-0.1-i468-1atv.plg" from the console, telnet or ssh to install, because the size of the files to download is ~20MB and will take a while to complete on some connections.

 

The first time you start it JAVA will also be download, so please be patient and wait for the webpage to respond.

 

*Note: CrashPlan requires SSH installed and running to be able to do the port redirect to access via the GUI on another machine. http://lime-technology.com/forum/index.php?topic=14998.0

 

Updates

 

October 23, 2011

 

• Used symbolic links to store crashplan on disk indead of using a tar file that needed to be restored each boot
  

 

To upgrade the plugin, remove the previous one, install the new one by rebooting or using installplg.  After the reboot  you will need to go to the settings page and specify the CrashPlan install path.  Enable the service. This will install CrashPlan to the Install Directory.  If you want to restore your previous settings from the tar, disable the service in the settings page and ensure it is stopped.  From a telnet/ssh session run the following "tar -C / -xvf /pathtoyourtar/crashplan.tar" without the quotes.  This will untar your last backup to the install directory via the sumbolic links.  Now enable the service and you should be restored

 

Thanks

SeeDrs

If you're going to duplicate someone else's plugin, you should at least indicate the differences so as not confuse people about what yours does that required you to create your own.  It's also good form to thank others who helped you or inspired you as you designed your code.

 

Removed link...

If you're going to duplicate someone else's plugin, you should at least indicate the differences so as not confuse people about what yours does that required you to create your own.  It's also good form to thank others who helped you or inspired you as you designed your code.

 

Original CrashPlan Plugin for v5b11+

 

I suggest your read what the plug-in's actually do.  The plug-in you are referring to is just a GUI to CrashPlan which doesn't actually install the software itself.  This one actually installs CrashPlan and has nothing to do with the other "GUI" plugin which didn't inspire me to create this one in any way.  Initially I create the plugin for my needs then share it with the community.  If you don't like it don't download it.  

 

Another thing, Instead of being negative why don't you be positive. What would be great is to combine the excellent "GUI" for CrashPlan created by cleight and the work that I did automating the install of CrashPlan via a plugin into a single plugin.

 

I sure hope comments like yours does not deter people from contributing to the community, without people spending their own time creating plugin's, add-on, unmenu, ect. Unraid would not be the same. If someone has improved on other peoples work and has forgot to mentioned them, do point it out, but with positive intent, because I am sure most people don't intend to offend the original creators.  I'd be happy to see anyone take my plugins that I created and improve them, since that would benefit myself and other users. I perfect example to this is speeding_ant offering suggesting and work to the APCUPSD Plugin

 

P.S. I'd take your own recommendation and change you're link from "Original CrashPlan Plugin for v5b11+" to "Original CrashPlan GUI Plugin for v5b11+" to not confuse anyone else. I did postfix the subject with (Installer) to fix your confusion.

Thanks SeeDrs, anxious to try this out.

Another thing, Instead of being negative why don't you be positive.

 

I'm sorry you took my comment as a negative attack on your work.  It wasn't intended to be that way.  Without seeing any indication of the differences, it is not inconceivable to think the two Crashplan plugins were similar, especially to people who didn't write the code.  While I am appreciative of your efforts, I don't think there was a need to be hostile towards my comments.  By excluding the word "GUI" you were assuming that most people would pick up on that nuance in your language, and immediately recognize the difference.  Issuing a defensive response doesn't change the potential for confusion.  Again I apologize for upsetting you.

I have a question... I currently have my Crashplan install sitting on my cache drive and in my Go script I create a symbolic link to the Crashplan directories then start crashplan.  This gives me the benefit of never having to re-tar since all changes are persistent.  Now as far as I understand, the go script runs after plug-ins are installed, if this is the case I won't be able to use this plugin right?  I believe this won't find the files in the right place...

 

Are there any work arounds?  I'd love to use the plugin if possible.

I have a question... I currently have my Crashplan install sitting on my cache drive and in my Go script I create a symbolic link to the Crashplan directories then start crashplan.  This gives me the benefit of never having to re-tar since all changes are persistent.  Now as far as I understand, the go script runs after plug-ins are installed, if this is the case I won't be able to use this plugin right?  I believe this won't find the files in the right place...

 

Are there any work arounds?  I'd love to use the plugin if possible.

 

The plugin is not designed that way, but I do like the idea of the symbolic links.  I might re-design it to work that way.

Yeah, I liked the approach because I prefer not to tar and untar on each reboot, if the directories are on a drive (cache SSD in my case) I know Crashplan stays updated... 

 

Here is the post that I got the idea from

 

http://lime-technology.com/forum/index.php?topic=4008.msg95628;topicseen#msg95628

Yeah, I liked the approach because I prefer not to tar and untar on each reboot, if the directories are on a drive (cache SSD in my case) I know Crashplan stays updated... 

 

Here is the post that I got the idea from

 

http://lime-technology.com/forum/index.php?topic=4008.msg95628;topicseen#msg95628

 

I'm going to switch over to that technique. I did it that way with the dropbox plugin.

SeeDrs: I'm glad to see someone figured out how to install CrashPlan via a plugin instead of the manual way.

 

I would like to see one uniform plugin for CrashPlan and would like to merge our two together if yo wouldn't mind? I know your web interface does some of the things mine does, and some of yours does stuff mine doesn't. Please let me know if you have a problem with the merger.

 

Thanks,

Chris

SeeDrs: I'm glad to see someone figured out how to install CrashPlan via a plugin instead of the manual way.

 

I would like to see one uniform plugin for CrashPlan and would like to merge our two together if yo wouldn't mind? I know your web interface does some of the things mine does, and some of yours does stuff mine doesn't. Please let me know if you have a problem with the merger.

 

Thanks,

Chris

 

Sounds like a good idea, I'm going to update the installer to use symbolic links to store the CrashPlan data on a disk instead of taring/untaring each reboot. I'll probably get that done tonight. After that you can take it and do your magic on the web interface.

SeeDrs: I'm glad to see someone figured out how to install CrashPlan via a plugin instead of the manual way.

 

I would like to see one uniform plugin for CrashPlan and would like to merge our two together if yo wouldn't mind? I know your web interface does some of the things mine does, and some of yours does stuff mine doesn't. Please let me know if you have a problem with the merger.

 

Thanks,

Chris

 

Sounds like a good idea, I'm going to update the installer to use symbolic links to store the CrashPlan data on a disk instead of taring/untaring each reboot. I'll probably get that done tonight. After that you can take it and do your magic on the web interface.

 

This is what I was hoping to see.  +1 to the both of you.

 

Now, if you can get this working with the JRE plugin for native Crashplan control, users won't have to mess with the hacked SSH connection method to make changes.

I would like to see one uniform plugin for CrashPlan and would like to merge our two together if yo wouldn't mind? I know your web interface does some of the things mine does, and some of yours does stuff mine doesn't. Please let me know if you have a problem with the merger.

 

This would be great, thanks to both of you for making this available!

I have updated the plugin to use symbloc links instead of a tar file to save CrashPlans state. 

 

Cleight, you can start to incorporate your work into that version, then once that is done, we can run it through some test, then post it in a new thread.

 

 

SeeDrs

Any specifics on how to upgrade plugins?  Do I just replace the old .plg with the new one and reboot?

Any specifics on how to upgrade plugins?  Do I just replace the old .plg with the new one and reboot?

 

Yes, there is and I got to post it.  I'll  update the Original Post.

Now, if you can get this working with the JRE plugin for native Crashplan control, users won't have to mess with the hacked SSH connection method to make changes.

 

I hope I'm missing something as my original crashplan guide could never overcome this one massive hurdle.

 

But how would installing a seperate JRE help avoid the ssh tunnel? The ssh tunnel is needed to configure the crashplan instance on unraid and, most importantly, to perform the initial login / registration with code42 and generate the .identity file.

 

The default JRE crashplan uses is just sucked down as part of the basic installation (it's provided by code42 and crashplan used to just wget it from their site as part of it's install process). If you install your own system JRE you don't need to also install the code42 provided one but apart from that any ssh tunneling required is still required as you still have to configure crashplan.

 

The only way I can see this ever changing is if code42 allow you to login / authenticate to their website via some command line tool that can be processed or share how the identity file is generated so it can be done manually.

 

It would be great if someones found another way to solve that issue - but I don't think the seperate JRE is it. Please tell me otherwise as I'd be quite happy!

p.s nice work on this and the GUI plugin!

Now, if you can get this working with the JRE plugin for native Crashplan control, users won't have to mess with the hacked SSH connection method to make changes.

 

I hope I'm missing something as my original crashplan guide could never overcome this one massive hurdle.

 

But how would installing a seperate JRE help avoid the ssh tunnel? The ssh tunnel is needed to configure the crashplan instance on unraid and, most importantly, to perform the initial login / registration with code42 and generate the .identity file.

 

The default JRE crashplan uses is just sucked down as part of the basic installation (it's provided by code42 and crashplan used to just wget it from their site as part of it's install process). If you install your own system JRE you don't need to also install the code42 provided one but apart from that any ssh tunneling required is still required as you still have to configure crashplan.

 

The only way I can see this ever changing is if code42 allow you to login / authenticate to their website via some command line tool that can be processed or share how the identity file is generated so it can be done manually.

 

It would be great if someones found another way to solve that issue - but I don't think the seperate JRE is it. Please tell me otherwise as I'd be quite happy!

 

Since I followed your original guide, I never had to go into the guts of the process to truly gain an understanding of what was actually going on.  As the author of that procedure, you obviously have much more insight than I do.  I guess I just assumed the lack of JRE support undermined running the GUI locally on unRAID.  I was hoping that with it installed, someone could create an iFrame and open the GUI that way.  Apparently that assumption was far too sophomoric for the reality of the problem.

 

The only other option I can think of, and it's a dangerous and volatile approach, would be to create an unRAID interface that writes to the config file.  That's a can of worms I'm not sure anyone would realistically want to take on, especially if a new version of Crashplan was released that changed the structure of the file.

 

Realistically reconfiguring Crashplan is not a daily chore, but having a seamless approach of course would be ideal.

Now, if you can get this working with the JRE plugin for native Crashplan control, users won't have to mess with the hacked SSH connection method to make changes.

 

I hope I'm missing something as my original crashplan guide could never overcome this one massive hurdle.

 

But how would installing a seperate JRE help avoid the ssh tunnel? The ssh tunnel is needed to configure the crashplan instance on unraid and, most importantly, to perform the initial login / registration with code42 and generate the .identity file.

 

The default JRE crashplan uses is just sucked down as part of the basic installation (it's provided by code42 and crashplan used to just wget it from their site as part of it's install process). If you install your own system JRE you don't need to also install the code42 provided one but apart from that any ssh tunneling required is still required as you still have to configure crashplan.

 

The only way I can see this ever changing is if code42 allow you to login / authenticate to their website via some command line tool that can be processed or share how the identity file is generated so it can be done manually.

 

It would be great if someones found another way to solve that issue - but I don't think the seperate JRE is it. Please tell me otherwise as I'd be quite happy!

 

Since I followed your original guide, I never had to go into the guts of the process to truly gain an understanding of what was actually going on.  As the author of that procedure, you obviously have much more insight than I do.  I guess I just assumed the lack of JRE support undermined running the GUI locally on unRAID.  I was hoping that with it installed, someone could create an iFrame and open the GUI that way.  Apparently that assumption was far too sophomoric for the reality of the problem.

 

The only other option I can think of, and it's a dangerous and volatile approach, would be to create an unRAID interface that writes to the config file.  That's a can of worms I'm not sure anyone would realistically want to take on, especially if a new version of Crashplan was released that changed the structure of the file.

 

Realistically reconfiguring Crashplan is not a daily chore, but having a seamless approach of course would be ideal.

 

 

I don't think we will ever have the official CrashPlan GUI running on unraid itself.

The actual GUI is do-able. But you'd need all the X libs installed under unraid. And then have to X forward to your local machine.

 

All quite heavy weight and even more of a pain than ssh forwarding.

 

What is more feasible is crashplan allowing command line configuration at some point in the future. There is a 'debug' command line mode within the GUI you can use to pass commands so it would seem (to me) a short step for them to make this available from the pure command line.

 

It may also be possible, once you have your .identity file created at the first install that your unraid crashplan plugin could then alter general day to day settings via a web form.

 

The crashplan settings are stored in an xml file, it could be possible to stop crashplan, rewrite the xml with the new values and then start crashplan up again. I don't know how much crashplan will care that the settings have changed underneath it - could be easily tested.

 

I also have a vague feeling some settings may be accessible via their web panel and can be pushed down to the client in which case perhaps some sort of api could be knocked up for the plugin to use via crashplan.com.

 

Those two things would certainly be worth investigating if anyone has the time and will..

SeeDrs: Here is what I got so far for the merger between our plugins. Everything is working however, I would like your help with setting up the backup for crashplan like you originally had in your plugin. Also I removed the installation directory and enable/disable plugin at the moment, I would like to be able to incorporate these features as well into my web interface.

 

Let me know what you think so far: http://dl.dropbox.com/u/8699829/Crashplan_test.plg

 

Also a few side notes: The way you were determining whether crashplan was running or not seemed to not be accurate. Your version would tell me it was running but I could do a ps -ef | grep crashplan and return nothing. My Plugin did completed a PS -EF query to see if it was truly running.

 

Also the installation directory part of your interface, I'm not 100% sure how that works as I have mine installing the backup tar file via the go script on boot, I don't have it installed permanently on a cache drive or spare drive.

... if anyone has the time and will..

 

Aye, there's the rub.    I have neither, and that's why I'm armchair quarterbacking from the back seat.

SeeDrs: Here is what I got so far for the merger between our plugins. Everything is working however, I would like your help with setting up the backup for crashplan like you originally had in your plugin. Also I removed the installation directory and enable/disable plugin at the moment, I would like to be able to incorporate these features as well into my web interface.

 

Let me know what you think so far:

 

Also a few side notes: The way you were determining whether crashplan was running or not seemed to not be accurate. Your version would tell me it was running but I could do a ps -ef | grep crashplan and return nothing. My Plugin did completed a PS -EF query to see if it was truly running.

 

Also the installation directory part of your interface, I'm not 100% sure how that works as I have mine installing the backup tar file via the go script on boot, I don't have it installed permanently on a cache drive or spare drive.

 

 

Is there a reason why you want to do the backup over using a symbolic link?  Using symbolic links is much cleaner, no need to schedule backups, or restore from the tar after each reboot.

 

My version check for the existent of a PID file to see if it us running. Which means there is a possibility of the pid file existing while the services is not running.

Any specifics on how to upgrade plugins?  Do I just replace the old .plg with the new one and reboot?

 

 

If you are talking about the beta one where the installer and guy ones are combined I would not use it.  If you are upgrading my install one to a newer version see the original post, it has instructions