Arch Linux User Repository

thanks @senorsnor i updated the depends

I contacted crashplan support about the ClassCastException I mentioned below, and they told me that Java 9 is currently not supported, they ony support Java 8. This confirms my findings that it works on Java 8 perfectly. Please update the dependencies.

I replied on the crashplan thread, but... TL;DR

Stop, disable and then remove crashplan.
Install, enable and then start crashplan-pro.
Use GUI to log into your account.
Done.

The logging in was the hardest part for me, because my servers are headless. I installed the CrashPlanPro client on my Mac, then used the documentation to disable the server daemon (because it'd use port 4243 and because I don't want to back it up). From there, you get the .ui_info file on your *server* (in /var/lib/crashplan/) to re-use on the client (where ever it goes). Setup a local SSH port forward 4243:localhost:4243 and then run the client. It'll connect over the port forward and you can log in. It seems to pull all the settings from CrashPlan, then you can change them if you want.

Has anyone successfully migrated from Crashplan for Home? The upgrade failed on the app though my account is now registered under Crashplan for Small Business - how can I install Crashplan Pro and retain all of my settings from Crashplan for Home?

Crashplan-pro 4.9.0-3 crashes on my system if I run it with jre9-openjdk-headless, throwing a ClassCastException, see below. It runs fine with jre8-openjdk-headless. I'll file a bug for this at crashplan. If you can reproduce it, would be good to update the dependencies I think.

[10.12.17 19:11:37.253 ERROR main com.backup42.service.CPService] Error starting up, java.lang.ClassCastException: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader
STACKTRACE:: java.lang.ClassCastException: java.base/jdk.internal.loader.ClassLoaders$AppClassLoader cannot be cast to java.base/java.net.URLClassLoader
at com.code42.lang.ClassPathHacker.logURLs(ClassPathHacker.java:46)
at com.backup42.service.CPService.start(CPService.java:570)
at com.backup42.service.CPService.main(CPService.java:2565)

You'll have to check the logs in the Crashplan folder most likely. This just shows that it tries to start, then dies.

Also, I looped through 1-500 against https://web-ebm-msp.crashplanpro.com/client/installers/CrashPlanPRO_4.9.0_1499922000650_${x}_Linux.tgz and couldn't grab anything.

I don't know if:
INFO sgDispatch-2 ervice.peer.PeerVersionValidator] WE have an old version, localVersion=1436674888490 (2015-07-12T04:21:28:490+0000), remoteVersion=1499922000650 (2017-07-13T05:00:00:650+0000), remoteGuid=42

matters in any way.

It just keeps the source and package files from showing up as something that needs committing, you don't ever want/need to commmit the /pkg/ or /src/ dir. And you *probably* never need to commit any *.tgz (the download from crashplan) or *.xz (the package made by makepkg).

Most AUR projects have one, though I don't think the *crashplan* AUR package is a very good example because it blocks *everything* and then explicitly enables the things they think they care about.

@fryfrog I merged the restart patch but I'm not sure if adding a .gitignore is a good practice here.

https://ptpb.pw/X_QS

^ This makes the restart work and adds a .gitignore.

This is a git format-patch that changes the deps, makes the "restart" work (I think) and adds a .gitignore.

https://ptpb.pw/4OTT

I'd actually love to figure out how to update 4.9.0 too, it is 1436674888490 while it wants to update to 1499922000650. But just changing that in the URL isn't enough. :/

Edit: Don't try to apply this, you just made a bunch of the changes I did too. :)

@fryfrog thanks i updated the depends

@aaronm-cloudtek: I'm guessing crashplan and crashplan-pro are fairly similar, have you considred changing the dependencies? Over there, it defaults to 8 and the jre is good enough.

https://aur.archlinux.org/packages/crashplan/

Ha, the *section* is commented out, I'm a big dummy. :)

From my `/etc/pacman.conf` I have the following, which seems like all I need for it to be enabled? :/
#[multilib]
Include = /etc/pacman.d/mirrorlist

I had no issues installing on multiple PCs. Do you have multilib enabled?

0 ✓ fryfrog@apollo ~ $ pacaur -S crashplan-pro
:: Package crashplan-pro not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for gcc-libs-multilib (dependency tree: crashplan-pro gcc-libs-multilib)

^ I'm trying to install this for the first time due to Crashplan Home being discontinued... what multilib does it need? :/

0 ✓ fryfrog@apollo ~ $ pacaur -S gcc-libs-multilib-git
:: Package gcc-libs-multilib-git not found in repositories, trying AUR...
:: resolving dependencies...
:: no results found for lib32-glibc>=2.20 (dependency tree: gcc-libs-multilib-git lib32-gcc-libs-git lib32-glibc)

@senorsnor maybe this helps? https://bbs.archlinux.org/viewtopic.php?id=172259

I installed the version from oct 6, and the package built with the PKGBUILD suggestion by blackhole, 2017-09-27 20:22 below. With both versions, my log is completely full with the lines below, all four cores of my cpu go to 100% and crashplan doesn't start. Unsure if it's me, the package, or crashplan?

Oct 08 23:20:28 kitten systemd[1]: crashplan-pro.service: Service hold-off time over, scheduling restart.
Oct 08 23:20:28 kitten systemd[1]: Stopped CrashPlanPRO Backup Engine.
Oct 08 23:20:28 kitten systemd[1]: crashplan-pro.service: Ignoring invalid environment assignment 'export LC_ALL=en_US.utf8': /opt/crashplan-pro/bin/run.conf
Oct 08 23:20:28 kitten systemd[1]: Starting CrashPlanPRO Backup Engine...
Oct 08 23:20:28 kitten CrashPlanEngine[7199]: Starting CrashPlan Engine ... Using standard startup
Oct 08 23:20:28 kitten CrashPlanEngine[7199]: OK
Oct 08 23:20:28 kitten systemd[1]: Started CrashPlanPRO Backup Engine.
Oct 08 23:20:36 kitten systemd[1]: crashplan-pro.service: Ignoring invalid environment assignment 'export LC_ALL=en_US.utf8': /opt/crashplan-pro/bin/run.conf
Oct 08 23:20:36 kitten CrashPlanEngine[7250]: Stopping CrashPlan Engine ... /opt/crashplan-pro/bin/CrashPlanEngine: line 145: kill: (7211) - No such process
Oct 08 23:20:37 kitten CrashPlanEngine[7250]: OK
Oct 08 23:20:37 kitten systemd[1]: crashplan-pro.service: Service hold-off time over, scheduling restart.
Oct 08 23:20:37 kitten systemd[1]: Stopped CrashPlanPRO Backup Engine.
Oct 08 23:20:37 kitten systemd[1]: crashplan-pro.service: Ignoring invalid environment assignment 'export LC_ALL=en_US.utf8': /opt/crashplan-pro/bin/run.conf
Oct 08 23:20:37 kitten systemd[1]: Starting CrashPlanPRO Backup Engine...
Oct 08 23:20:38 kitten CrashPlanEngine[7268]: Starting CrashPlan Engine ... Using standard startup
Oct 08 23:20:38 kitten CrashPlanEngine[7268]: OK
Oct 08 23:20:38 kitten systemd[1]: Started CrashPlanPRO Backup Engine.

# Maintainer: Anthony Boccia <aboccia [at] boccia [dot] me>
# Contributer: Griffin Smith <wildgriffin [at] gmail [dot] com>
# Contributor: Bill Durr <billyburly [at] gmail [dot] com>
pkgname=crashplan-pro
pkgver=4.9.0
pkgrel=2
pkgdesc="An business online/offsite backup solution"
url="http://www.crashplan.com/business"
arch=('i686' 'x86_64')
license=('custom')
depends=('java-runtime')
makedepends=('grep' 'cpio' 'gzip')
optdepends=('swt: needed by some to open the GUI')
backup=()
install=crashplan-pro.install
source=(https://web-lbm-msp.crashplanpro.com/client/installers/CrashPlanPRO_4.9.0_1436674888490_33_Linux.tgz
crashplan-pro
crashplan-pro.service)
sha256sums=('SKIP'
'b306d7da0dd41341512ce80ddcfb21bff8a9bb73ab5018696e69d08b89f7f1b6'
'SKIP')

build() {
cd $srcdir/crashplan-install

echo ""
echo "You must review and agree to the EULA before using Crashplan PRO."
echo "You can do so at:"
echo " - http://support.crashplan.com/doku.php/eula"
echo " - /usr/share/licenses/${pkgname}/LICENSE"
echo ""

echo "" > install.vars
echo "JAVACOMMON=`which java`" >> install.vars
echo "#APP_BASENAME=CrashPlan" >> install.vars
echo "TARGETDIR=/opt/$pkgname" >> install.vars
echo "BINSDIR=" >> install.vars
echo "MANIFESTDIR=/opt/$pkgname/manifest" >> install.vars
echo "INITDIR=" >> install.vars
echo "RUNLVLDIR=" >> install.vars
NOW=`date +%Y%m%d`
echo "INSTALLDATE=$NOW" >> install.vars

sed -imod "s|Exec=.*|Exec=/opt/$pkgname/bin/CrashPlanDesktop|" scripts/CrashPlan.desktop
sed -imod "s|Icon=.*|Icon=/opt/$pkgname/skin/icon_app_64.74.png|" scripts/CrashPlan.desktop
sed -imod "s|Categories=.*|Categories=System;|" scripts/CrashPlan.desktop
}

package() {
mkdir -p $pkgdir/opt/$pkgname
cd $pkgdir/opt/$pkgname

cat $srcdir/crashplan-install/CrashPlanPRO_$pkgver.cpi | gzip -d -c - | cpio -i --no-preserve-owner
chmod 777 $pkgdir/opt/$pkgname/log
sed -i "s|<manifestPath>manifest</manifestPath>|<manifestPath>/opt/$pkgname/manifest</manifestPath>|g" $pkgdir/opt/$pkgname/conf/default.service.xml

mkdir -p $pkgdir/usr/bin
ln -s "/opt/$pkgname/bin/CrashPlanDesktop" $pkgdir/usr/bin/CrashPlanDesktop

# Fix for 32 bit: 64 bit libs cannot be stripped from symbols
# so we just remove those libs
if [ "$CARCH" = "i686" ]; then
rm $pkgdir/opt/$pkgname/*64.so
fi

# Fix for encoding troubles (CrashPlan ticket 178827)
# Make sure the daemon is running using the same localization as
# the (installing) user
echo "" >> $srcdir/crashplan-install/scripts/run.conf
echo "export LC_ALL=$LANG" >> $srcdir/crashplan-install/scripts/run.conf

install -D -m 644 $srcdir/crashplan-install/install.vars $pkgdir/opt/$pkgname/install.vars
#Removed as of Version 4.8.0 as the EULA is no longer included in the source
#install -D -m 644 $srcdir/crashplan-install/EULA.txt $pkgdir/opt/$pkgname/EULA.txt
#install -D -m 644 $srcdir/crashplan-install/EULA.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
install -D -m 755 $srcdir/crashplan-install/scripts/CrashPlanDesktop $pkgdir/opt/$pkgname/bin/CrashPlanDesktop
install -D -m 644 $srcdir/crashplan-install/scripts/run.conf $pkgdir/opt/$pkgname/bin/run.conf
install -D -m 755 $srcdir/crashplan-install/scripts/CrashPlanEngine $pkgdir/opt/$pkgname/bin/CrashPlanEngine
install -D -m 755 $srcdir/crashplan-install/scripts/CrashPlan.desktop $pkgdir/usr/share/applications/crashplan.desktop

# rc.d daemon
install -D -m 755 $srcdir/crashplan-pro $pkgdir/etc/rc.d/crashplan-pro
# systemd unit
install -D -m 644 $srcdir/crashplan-pro.service $pkgdir/usr/lib/systemd/system/crashplan-pro.service
}

Until we can get the AUR package updated, does anyone have the appropriate PKGBUILD changes needed to get 4.9.0 installed?

@aboocia +1 support from me. Now that CrashPlan Home is being discontinued I've migrated all my data to CrashPlan SME.

@aboccia I would like to pledge support for aaronm-cloudtek's request

@aboccia would you consider adding a maintainer if you are unable to update the package in a timely manner? I'm happy to volunteer if needed.

Any estimate on when this package will be updated to 4.9.0?

The automatic updates that cause hourly restarts to upgrade and fail (saving new downloads and logs each time) are annoying.

I think that in the systemd service the right Unit section should be like this:

[Unit]
Description=CrashPlan Backup Engine
After=network-online.target
Wants=network-online.target

Could you please add a /etc/sysctl.d/40-crashplanpro.conf to the package with the following content:
fs.inotify.max_user_watches = 1048576

This would allow the crashplan engine to monitor backups set with a lot of files. See also https://support.code42.com/CrashPlan/4/Troubleshooting/Linux_real-time_file_watching_errors

I have resolved the problem at boot installing a modified version of this:

https://github.com/ava1ar/aur/tree/master/networkmanager-dispatcher-crashplan-systemd

I am using 4.9.0, the problem at boot is not resolved.

Yes please update the package to 4.9.0 using the link @adambot posted. I already modified my PKGBUILD locally with his link along with its hash and it has been working fine for a few days now.

Please update this package to 4.9.0 using the link @adambot posted.

After boot, systemd service is starting correctly, but I have "waiting for connection" forever on the application. If I restart systemd service connection is fine and working.

You can also see crashplanpro.com referenced in the "online management console" screenshot at the bottom of this features page without logging in: https://www.crashplan.com/en-us/business/features/

Yeah, crashplanpro.com is an official CrashPlan site. You can reach it from https://crashplan.com via "CrashPlan® for Small Business" and then "Sign In" on the top right.

It's legit.. Inside the dashboard it shows 4.9.0

Linux 4.9.0 build33 CrashPlan PRO

4.9.0 available: https://web-ebm-msp.crashplanpro.com/client/installers/CrashPlanPRO_4.9.0_1436674888490_33_Linux.tgz

@twistedjoe

I have fixed the checksum, not sure what happened there. I recall testing the build after updating the version, it may be possible that crashplan changed the tarball on their end. I always test before committing. As for your missing file issue, I am not seeing that on my end. Also I don't see the file shown in your paste, I do however see the similarly named "/opt/crashplan-pro/bin/../lib/com.backup42.desktop.jar" I am guessing that is what you should be referencing.

All is running fine on my end.

Cheers

After a fresh reinstall (changed the sha256sum to force the install),

it failed with the following:

http://pastebin.com/raw/4tJTuBAq

CrashPlanPro_4.7.0_Linux.tgz is failing the sha256 sums on my end.

Maybe it has been updated ?.

@twistedjoe


I'll add the Restart=always, it's a workaround for the crashes but if it keeps the service running for people than that is a plus.

I did test with RemainAfterExit=yes as you previously suggested, that seemed to help on my end.

Updating package to latest now.

Thanks for all your input.

@aboccia
When auto updating the daemon will stop (but not the systemd service).
In the middle of downloading jre-1.7 usually, systemd kill the update process.
The update log show that it was killed in the middle of loading it with wget.

No crash, it just stop. Then the service does not restart.
On the crashplan package they have Restart=always, which would make it at least restart after trying the update.

Maybe if it does not have to load jre, systemd don't have the time to catch up before the daemon is back and that prevent it from being killed in your case.

If you want to test it remove crashplan-pro + the /opt/crashplan-pro folder then reinstall the 4.5.2 package and start the daemon, the first thing it does once you open the GUI would be updating. Then you should have a upgrade.<SOME ID>.log file in /opt/crashplan-pro/log/.

Though, I guess it would be too much trouble + you are risking losing your existing backup if you do it.

@twistedjoe

I have updated to the latest 4.6.0, as for the auto update failure. I have not seen this same behaviour in my environment. I will look into testing it before applying your patch to the service file.

Thanks

Hi, the package seems to be outdated. 4.6.0 is out.
The auto-update is killing the service at the moment.
I tried to find a way to disable the auto-update, but was not able to.

I think we should disable auto-update and update the package instead (maybe if we ask code42 they will add an option).

In the meantime, I fixed the auto-update so it would not fail.


The problem seems to be that once the auto-update script stops the daemon, systemd catch up and kill the unit while the script is updating. This in turn kill the upgrade script mid completion.

The upgrade script is loaded with the upgrade itself by the java bin, so it will be hard to patch.

My temp fix is to add RemainAfterExit=yes to the service file. This way systemd will not kill the unit after the daemon has been stopped.

I am new to arch and systemd so this might have repercussions I don't know about.


Here is the patch file:
https://gist.github.com/twistedjoe/e976b40be22ec6e0d1a0



Just updating the package (without preventing auto update) is not really a solution in here case, because the daemon will just close silently every time there is an upgrade. I don't want to have to periodically check to be sure crashplan is still working. I need it to either upgrade automatically, or just don't try if it would crash.

@aboccia fine by me - I don't use it anymore myself. Disowning now.

@glittershark I currently require up to date versions of this package and will for the foreseeable future, I'd like to take over as the maintainer of this package if you are no longer able to keep things up to date. Please let me know.

Thank You

> e.g. add the following line to /etc/sysctl.conf
> fs.inotify.max_user_watches=1048576

Should be changed: sysctl.conf is no longer supported.

@glittershark: It's not nice to just copy-paste the crashplan PKGBUILD and everything and claiming you did all the work. At least leave the contributors in place (as is the case for crashplan-pro-e).