CrashPlan is a popular online backup solution, with most people using it to protect their data in the Cloud. However, by licensing CrashPlan PROe server you can be that Cloud and act as the storage provider for other client machines running CrashPlan PROe.
I was recently contracted to implement this on Synology hardware for North Bay Technologies, an IT services company in San Francisco. Instead of undertaking a careful manual install that would be difficult to maintain in future, I decided to go one better – to build a package which integrates properly with Synology DSM. I then back-merged most of the changes into the existing CrashPlan client package scripts so everything is as consistent as possible. It was agreed that I would also publish this to the community, so here it is!
I should stress at this point that although this package could technically install on Synology products with ARM or QorIQ processors, you should only use this on a model with an Intel CPU. Ideally you should equip it with more than 1GB of RAM too, because the application requires 1GB all for itself. The package repo will not advertise it to ARM systems, because they have far too little available RAM.
As with the CrashPlan client packages I have made, I have been careful to comply with Code 42 Software’s stipulation that no one redistributes their work.
Installation
- This package is for Intel CPUs only. It will work on an unmodified NAS, no hacking or bootstrapping required.
- More than 1GB of RAM is recommended.
- You will need to install my Java SE for Embedded package first. Read the instructions on that page carefully too.
- In the User Control Panel in DSM, enable the User Homes service.
- Purchase your Master License Key and licences (or obtain a trial key) from crashplan.com, download the PROe Server installer for Linux, and save in the public shared folder on your NAS. You should have created this folder when you installed the Java package.
- Install the CrashPlan PROe server Synology package directly from Package Center in DSM. In Settings -> Package Sources add my package repository URL which is http://packages.pcloadletter.co.uk.
Notes
- The package expects the end user to have separately downloaded the CrashPlan PROe Server installer for Linux, and it presents them with the official EULA during installation.
- For details of TCP ports used, to help you set up firewalling and/or port forwarding please consult the requirements document.
- Once running, CrashPlan PROe server is configured by a web dashboard on https://yourNasIP:4285/console/ This link can be found in the package info screen in Package Center in Synology DSM when the package is running.
- Full support documentation is available here.
- The DSM Package Center upgrade functionality allows you to move between my package versions without losing settings or data, but if you’re moving to a new CrashPlan PROe Server version you will need to do that manually via the admin web app, using the Linux downloads (with file extension .upgrade) available from Code 42 Software. Depending on how up to date your version is, you may need to update incrementally through several versions. Before you apply a Code 42 update package, you should manually install the latest Synology package for the specific PROe Server version you’re currently runnning. This will ensure the update scripts are handled correctly. So for example if you’re upgrading from 3.5.4 to 3.5.5 you should manually install cpproeserver3.5.4-merged-020.spk over the top first. You can find up to date package versions for each PROe Server build here:
cpproeserver3.2.1.2-merged-0020.spk
cpproeserver3.3.0.2-merged-0020.spk
cpproeserver3.3.0.3-merged-0020.spk
cpproeserver3.3.0.4-merged-0020.spk
cpproeserver3.4.1-merged-0020.spk
cpproeserver3.4.1.5-merged-0020.spk
cpproeserver3.5.1.1-merged-0020.spk
cpproeserver3.5.3.2-merged-0020.spk
cpproeserver3.5.4-merged-0020.spk
cpproeserver3.5.5-merged-0020.spk - The engine daemon script checks the amount of system RAM and scales the Java heap size appropriately (up to the default maximum of 1024MB). This can be overridden in a persistent way if you are backing up very large backup sets by editing /volume1/@appstore/cpproeserver/syno_package.vars.
- As with my other syno packages, this user account password is randomized when it is created using a perl script called passgen (I followed the example of the Transmission package). DSM Package Center runs as the root user so my script starts the package using an su command. This means that you can change the password yourself and CrashPlan will still work.
- The default location for saving backup data is set to /volume1/cpproeserver (where /volume1 is you primary storage volume) to eliminate the chance of them being destroyed accidentally by uninstalling the package.
- The package supports upgrading to future versions while preserving the machine identity, logs, login details, and cache.
- The log which is displayed in the package’s Log tab is actually the activity history. If you’re trying to troubleshoot an issue you may need to use an SSH session to inspect the more detailed log files which are stored in /volume1/cpproeserver/log
- I’m not sure if it works for the PROe products, but I would really appreciate it if you could use this affiliate link when purchasing your licences (you may need to browse to the PROe section of the website using the links in the footer of that page). If this package saves you the several days worth of work I put into making it, please also consider donating using the PayPal button on the right hand side of the page. Thanks!
Package scripts
For information, here are the package scripts so you can see what it’s going to do. You can get more information about how packages work by reading the Synology Package wiki.
installer.sh
#!/bin/sh
#--------CRASHPLAN PROe server installer script
#--------package maintained at pcloadletter.co.uk
DOWNLOAD_PATH="http://download.crashplan.com/installs/proserver/CP_VER"
DOWNLOAD_FILE="CrashPlanPROServer_CP_VER_Linux.tgz"
DOWNLOAD_URL="${DOWNLOAD_PATH}/${DOWNLOAD_FILE}"
TGZ_FILE="CrashPlanPROServer.tgz"
#remove file extension
DOWNLOAD_FILE="`echo ${DOWNLOAD_FILE} | sed -e 's/.tgz$//'`"
EXTRACTED_FOLDER="${DOWNLOAD_FILE}"
DAEMON_USER="`echo ${SYNOPKG_PKGNAME} | awk {'print tolower($_)'}`"
DAEMON_PASS="`openssl rand 12 -base64 2>/dev/null`"
DAEMON_ID="${SYNOPKG_PKGNAME} daemon user"
DAEMON_HOME="/var/services/homes/${DAEMON_USER}"
OPTDIR="${SYNOPKG_PKGDEST}/proserver/server"
VARS_FILE="${OPTDIR}/.install.vars"
ENGINE_SCRIPT="proserver"
SYNO_CPU_ARCH="`uname -m`"
[ "${SYNO_CPU_ARCH}" == "x86_64" ] && SYNO_CPU_ARCH="i686"
NATIVE_BINS_URL="http://packages.pcloadletter.co.uk/downloads/crashplan-native-${SYNO_CPU_ARCH}.tgz"
NATIVE_BINS_FILE="`echo ${NATIVE_BINS_URL} | sed -r "s%^.*/(.*)%\1%"`"
INSTALL_FILES="${NATIVE_BINS_URL}"
TEMP_FOLDER="`find / -maxdepth 2 -name '@tmp' | head -n 1`"
#this is where the user data will go, so it persists after a package uninstall
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/${DAEMON_USER}"
VARLOGDIR=${MANIFEST_FOLDER}/log
LOG_FILE="${VARLOGDIR}/com_backup42_app.log.0"
UPGRADE_FILES=""
UPGRADE_FOLDERS="activemq-data conf db keys"
source /etc/profile
PUBLIC_FOLDER="`cat /usr/syno/etc/smb.conf | sed -r '/\/public$/!d;s/^.*path=(\/volume[0-9]{1,4}\/public).*$/\1/'`"
preinst ()
{
if [ -z ${PUBLIC_FOLDER} ]; then
echo "A shared folder called 'public' could not be found - note this name is case-sensitive. "
echo "Please create this using the Shared Folder DSM Control Panel and try again."
exit 1
fi
if [ -z ${JAVA_HOME} ]; then
echo "Java is not installed or not properly configured. JAVA_HOME is not defined. "
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5"
exit 1
fi
if [ ! -f ${JAVA_HOME}/bin/java ]; then
echo "Java is not installed or not properly configured. The Java binary could not be located. "
echo "Download and install the Java Synology package from http://wp.me/pVshC-z5"
exit 1
fi
#is the User Home service enabled?
UH_SERVICE=maybe
synouser --add userhometest Testing123 "User Home test user" 0 "" ""
UHT_HOMEDIR=`cat /etc/passwd | sed -r '/User Home test user/!d;s/^.*:User Home test user:(.*):.*$/\1/'`
if echo $UHT_HOMEDIR | grep '/var/services/homes/' > /dev/null; then
if [ ! -d $UHT_HOMEDIR ]; then
UH_SERVICE=false
fi
fi
synouser --del userhometest
#remove home directory (needed since DSM 4.1)
[ -e /var/services/homes/userhometest ] && rm -r /var/services/homes/userhometest
if [ "${UH_SERVICE}" == "false" ]; then
echo "The User Home service is not enabled. Please enable this feature in the User control panel in DSM."
exit 1
fi
CP_BINARY_FOUND=
[ -f ${PUBLIC_FOLDER}/${DOWNLOAD_FILE}.tgz ] && CP_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${DOWNLOAD_FILE}.tar ] && CP_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${DOWNLOAD_FILE}.tar.tar ] && CP_BINARY_FOUND=true
[ -f ${PUBLIC_FOLDER}/${DOWNLOAD_FILE}.gz ] && CP_BINARY_FOUND=true
if [ -z ${CP_BINARY_FOUND} ]; then
echo "CrashPlan PROe server Linux installer not found. "
echo "I was expecting the file ${PUBLIC_FOLDER}/${DOWNLOAD_FILE}.tgz "
echo "Please visit crashplan.com, download the installer from ${DOWNLOAD_URL} "
echo "and place it in the 'public' shared folder on your NAS."
exit 1
fi
cd ${TEMP_FOLDER}
for WGET_URL in ${INSTALL_FILES}
do
WGET_FILENAME="`echo ${WGET_URL} | sed -r "s%^.*/(.*)%\1%"`"
[ -f ${TEMP_FOLDER}/${WGET_FILENAME} ] && rm ${TEMP_FOLDER}/${WGET_FILENAME}
wget ${WGET_URL}
if [[ $? != 0 ]]; then
if [ -d ${PUBLIC_FOLDER} ] && [ -f ${PUBLIC_FOLDER}/${WGET_FILENAME} ]; then
cp ${PUBLIC_FOLDER}/${WGET_FILENAME} ${TEMP_FOLDER}
else
echo "There was a problem downloading ${WGET_FILENAME} from the official download link, "
echo "which was \"${WGET_URL}\" "
echo "Alternatively, you may download this file manually and place it in the 'public' shared folder. "
exit 1
fi
fi
done
exit 0
}
postinst ()
{
VAROPTDIR=${MANIFEST_FOLDER}/data
VARLOGDIR=${MANIFEST_FOLDER}/log
ETCDIR=${OPTDIR}/bin
INITDIR=${OPTDIR}/bin
RUNLVLDIR=${OPTDIR}/bin
#create daemon user
synouser --add ${DAEMON_USER} ${DAEMON_PASS} "${DAEMON_ID}" 0 "" ""
#save the daemon user's homedir as variable in that user's profile
#this is needed because new users seem to inherit a HOME value of /root which they have no permissions for.
su - ${DAEMON_USER} -s /bin/sh -c "echo export HOME=\'${DAEMON_HOME}\' >> .profile"
#extract CPU-specific additional binaries
mkdir ${SYNOPKG_PKGDEST}/bin
cd ${SYNOPKG_PKGDEST}/bin
tar xzf ${TEMP_FOLDER}/${NATIVE_BINS_FILE} && rm ${TEMP_FOLDER}/${NATIVE_BINS_FILE}
mkdir -p ${OPTDIR}
mkdir -p ${INITDIR}
mkdir -p ${RUNLVLDIR}
mkdir -p ${VAROPTDIR}
mkdir -p ${VARLOGDIR}
cd ${PUBLIC_FOLDER}
#extract CrashPlan Linux installer (Web browsers love to interfere with .tar.gz files)
if [ -f ${DOWNLOAD_FILE}.tgz ]; then
#Firefox seems to be the only browser that leaves it alone
tar xzf ${DOWNLOAD_FILE}.tgz
elif [ -f ${DOWNLOAD_FILE}.gz ]; then
#Chrome
tar xzf ${DOWNLOAD_FILE}.gz
elif [ -f ${DOWNLOAD_FILE}.tar ]; then
#Safari
tar xf ${DOWNLOAD_FILE}.tar
elif [ -f ${DOWNLOAD_FILE}.tar.tar ]; then
#Internet Explorer
tar xzf ${DOWNLOAD_FILE}.tar.tar
fi
mkdir -p ${OPTDIR}/content-custom
mkdir -p ${OPTDIR}/installs
mkdir ${VAROPTDIR}/backupArchives
mkdir ${VAROPTDIR}/backupCache
mkdir ${VAROPTDIR}/dumps
chown -R ${DAEMON_USER} ${MANIFEST_FOLDER}
#extract nested tgz archive
cd ${OPTDIR}
tar xozf "${PUBLIC_FOLDER}/${EXTRACTED_FOLDER}/${TGZ_FILE}"
echo "#uncomment to expand Java max heap size beyond prescribed value of 1024M (will survive upgrades)" > ${SYNOPKG_PKGDEST}/syno_package.vars
echo "#USR_MAX_HEAP=1024M" >> ${SYNOPKG_PKGDEST}/syno_package.vars
echo >> ${SYNOPKG_PKGDEST}/syno_package.vars
#create a valid identity file if there is no existing GUID
GUID=
if [ -f ${VAROPTDIR}/.identity ] ; then
. ${VAROPTDIR}/.identity
fi
if [ "x${GUID}" == "x" ]; then
echo -n "GUID=" > ${VAROPTDIR}/.identity
java -cp "${OPTDIR}/lib/com.backup42.app.jar" com.code42.utils.UniqueId >> ${VAROPTDIR}/.identity
. ${VAROPTDIR}/.identity
if [ "x${GUID}" == "x" ] ; then
echo "Failed to create valid server identity. Identity Path: ${VAROPTDIR}/.identity"
exit 1
fi
fi
#amend entries in default server config file
sed -i "s%<OPT>%${OPTDIR}%" ${OPTDIR}/conf/conf_proe.properties
sed -i "s%<VAROPT>%${VAROPTDIR}%" ${OPTDIR}/conf/conf_proe.properties
sed -i "s%<VARLOGDIR>%${VARLOGDIR}%" ${OPTDIR}/conf/conf_proe.properties
#save install variables which Crashplan expects its own installer script to create
echo "" > ${VARS_FILE}
echo "OPTDIR=${OPTDIR}" >> ${VARS_FILE}
echo "VAROPTDIR=${VAROPTDIR}" >> ${VARS_FILE}
echo "VARLOGDIR=${VARLOGDIR}" >> ${VARS_FILE}
echo "ETCDIR=${ETCDIR}" >> ${VARS_FILE}
echo "INITDIR=${INITDIR}" >> ${VARS_FILE}
echo "RUNLVLD=${RUNLVLDIR}" >> ${VARS_FILE}
echo "INSTALLDATE=`date +%Y%m%d`" >> ${VARS_FILE}
echo "JAVACOMMON=\${JAVA_HOME}/bin/java" >> ${VARS_FILE}
#remove temp files
rm -r ${PUBLIC_FOLDER}/${EXTRACTED_FOLDER}
#change owner of CrashPlan folder tree
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
echo "CrashPlan PROe Server has been installed. When you start the package a few moments of first-time initialization "
echo "are needed before the management application will be available in your web browser. You can check the Log tab "
echo "to discover when it has fully started. "
echo "http://localhost:4280/console "
echo "https://localhost:4285/console "
echo "Please note that your clients will communicate with the server on TCP port 4282."
exit 0
}
preuninst ()
{
#make sure engine is stopped
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} stop"
sleep 2
exit 0
}
postuninst ()
{
if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
source ${SYNOPKG_PKGDEST}/syno_package.vars
fi
if [ "${LIBFFI_SYMLINK}" == "YES" ]; then
rm /lib/libffi.so.5
fi
#if it doesn't exist, but is still a link then it's a broken link and should also be deleted
if [ ! -e /lib/libffi.so.5 ]; then
[ -L /lib/libffi.so.5 ] && rm /lib/libffi.so.5
fi
#remove daemon user
synouser --del ${DAEMON_USER}
#remove daemon user's home directory (needed since DSM 4.1)
[ -e /var/services/homes/${DAEMON_USER} ] && rm -r /var/services/homes/${DAEMON_USER}
exit 0
}
preupgrade ()
{
#make sure engine is stopped
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} stop"
sleep 2
#if config data exists back it up
if [ -d ${OPTDIR}/keys ]; then
mkdir -p ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${OPTDIR}/${FOLDER_TO_MIGRATE} ]; then
mv ${OPTDIR}/${FOLDER_TO_MIGRATE} ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig
fi
done
fi
exit 0
}
postupgrade ()
{
#use the migrated config data from the previous version
if [ -d ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/keys ]; then
for FOLDER_TO_MIGRATE in ${UPGRADE_FOLDERS}; do
if [ -d ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FOLDER_TO_MIGRATE} ]; then
cp -R ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig/${FOLDER_TO_MIGRATE} ${OPTDIR}
fi
done
rmdir ${SYNOPKG_PKGDEST}/../${DAEMON_USER}_data_mig
#make log entry
TIMESTAMP="`date +%x` `date +%I:%M%p`"
echo "I ${TIMESTAMP} Synology Package Center updated ${SYNOPKG_PKGNAME} to version ${SYNOPKG_PKGVER}" >> ${LOG_FILE}
#daemon user has been deleted and recreated so we need to reset ownership (new UID)
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
fi
exit 0
}
start-stop-status.sh
#!/bin/sh
#--------CRASHPLAN PROe server start-stop-status script
#--------package maintained at pcloadletter.co.uk
DAEMON_USER="`echo ${SYNOPKG_PKGNAME} | awk {'print tolower($_)'}`"
DAEMON_HOME="/var/services/homes/${DAEMON_USER}"
OPTDIR="${SYNOPKG_PKGDEST}/proserver/server"
TEMP_FOLDER="`find / -maxdepth 2 -name '@tmp' | head -n 1`"
MANIFEST_FOLDER="/`echo $TEMP_FOLDER | cut -f2 -d'/'`/${DAEMON_USER}"
VARLOGDIR=${MANIFEST_FOLDER}/log
LOG_FILE="${VARLOGDIR}/history.log.0"
ENGINE_SCRIPT="proserver"
APP_NAME="CPServer"
SCRIPTS_TO_EDIT="${ENGINE_SCRIPT} proservermonitor"
ENGINE_CFG="${ENGINE_SCRIPT}"
LIBFFI_SO_NAMES="5 6" #armada370 build of libjnidispatch.so is newer, and uses libffi.so.6
CFG_PARAM="JAVA_MEM_ARGS"
#note that the vars in the next two string values are escaped for evaluation later on
JAVA_MEM_ARGS="-Xss128k -Xms\${JAVA_MIN_HEAP}m -Xmx\${JAVA_MAX_HEAP}m"
JAVA_GC_ARGS="-XX:+DisableExplicitGC -XX:+UseAdaptiveGCBoundary -XX:PermSize=\${JAVA_MIN_HEAP}m -XX:MaxPermSize=\${JAVA_MIN_HEAP}m"
source ${OPTDIR}/.install.vars
JAVA_MIN_HEAP=`grep "^${CFG_PARAM}=" "${OPTDIR}/bin/${ENGINE_CFG}" | sed -r "s/^.*-Xms([0-9]+)[Mm] .*$/\1/"`
SYNO_CPU_ARCH="`uname -m`"
case $1 in
start)
#set the current timezone for Java so that log timestamps are accurate
#we need to use the modern timezone names so that Java can figure out DST
SYNO_TZ=`cat /etc/synoinfo.conf | grep timezone | cut -f2 -d'"'`
SYNO_TZ=`grep "^${SYNO_TZ}" /usr/share/zoneinfo/Timezone/tzname | sed -e "s/^.*= //"`
grep "^export TZ" ${DAEMON_HOME}/.profile > /dev/null \
&& sed -i "s%^export TZ=.*$%export TZ='${SYNO_TZ}'%" ${DAEMON_HOME}/.profile \
|| echo export TZ=\'${SYNO_TZ}\' >> ${DAEMON_HOME}/.profile
#check persistent variables from syno_package.vars
USR_MAX_HEAP=0
if [ -f ${SYNOPKG_PKGDEST}/syno_package.vars ]; then
source ${SYNOPKG_PKGDEST}/syno_package.vars
fi
USR_MAX_HEAP=`echo $USR_MAX_HEAP | sed -e "s/[mM]//"`
#create or repair libffi symlink if a DSM upgrade has removed it
for FFI_VER in ${LIBFFI_SO_NAMES}; do
if [ -e ${OPTDIR}/lib/libffi.so.${FFI_VER} ]; then
if [ ! -e /lib/libffi.so.${FFI_VER} ]; then
#if it doesn't exist, but is still a link then it's a broken link and should be deleted
[ -L /lib/libffi.so.${FFI_VER} ] && rm /lib/libffi.so.${FFI_VER}
ln -s ${OPTDIR}/lib/libffi.so.${FFI_VER} /lib/libffi.so.${FFI_VER}
fi
fi
done
#fix up some of the binary paths and fix some command syntax for busybox
#moved this to start-stop-status from installer.sh because Code42 push updates and these
#new scripts will need this treatment too
FIND_TARGETS=
for TARGET in ${SCRIPTS_TO_EDIT}; do
FIND_TARGETS="${FIND_TARGETS} -o -name ${TARGET}"
done
find ${OPTDIR} \( -name \*.sh ${FIND_TARGETS} \) | while IFS="" read -r FILE_TO_EDIT; do
if [ -e ${FILE_TO_EDIT} ]; then
#this list of substitutions will probably need expanding as new CrashPlan updates are released
sed -i "s%^#!/bin/bash%#!${SYNOPKG_PKGDEST}/bin/bash%" "${FILE_TO_EDIT}"
sed -i -r "s%(^\s*)nice -n%\1${SYNOPKG_PKGDEST}/bin/nice -n%" "${FILE_TO_EDIT}"
sed -i -r "s%(^\s*)(/bin/ps|ps) [^\|]*\|%\1/bin/ps w \|%" "${FILE_TO_EDIT}"
sed -i -r "s%\`ps [^\|]*\|%\`ps w \|%" "${FILE_TO_EDIT}"
sed -i "s/rm -fv/rm -f/" "${FILE_TO_EDIT}"
sed -i "s/mv -fv/mv -f/" "${FILE_TO_EDIT}"
fi
done
#an upgrade script that has been launched via the web app will usually have failed until the above
#changes are made so we need to find it and start it, if it exists
UPGRADE_SCRIPT=`find ${OPTDIR}/upgrade -name "upgrade.sh"`
if [ -n "${UPGRADE_SCRIPT}" ]; then
rm ${OPTDIR}/${ENGINE_SCRIPT}.pid
SCRIPT_HOME=`dirname $UPGRADE_SCRIPT`
#make CrashPlan log entry
TIMESTAMP="`date +%x` `date +%I:%M%p`"
echo "I ${TIMESTAMP} Synology repairing upgrade in ${SCRIPT_HOME}" >> ${LOG_FILE}
mv ${SCRIPT_HOME}/upgrade.log ${SCRIPT_HOME}/upgrade.log.old
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
su - ${DAEMON_USER} -s /bin/sh -c "cd ${SCRIPT_HOME} ; . upgrade.sh"
mv ${SCRIPT_HOME}/upgrade.sh ${SCRIPT_HOME}/upgrade.sh.old
exit 0
fi
#updates may also overwrite our native binaries
if [ "${SYNO_CPU_ARCH}" != "x86_64" ]; then
cp -f ${SYNOPKG_PKGDEST}/bin/libjtux.so ${OPTDIR}
cp -f ${SYNOPKG_PKGDEST}/bin/jna-3.2.5.jar ${OPTDIR}/lib
cp -f ${SYNOPKG_PKGDEST}/bin/libffi.so.* ${OPTDIR}/lib
fi
#set appropriate Java max heap size
RAM=$((`free | grep Mem: | sed -e "s/^ *Mem: *\([0-9]*\).*$/\1/"`/1024))
if [ $RAM -le 128 ]; then
JAVA_MAX_HEAP=80
elif [ $RAM -le 256 ]; then
JAVA_MAX_HEAP=192
elif [ $RAM -le 512 ]; then
JAVA_MAX_HEAP=384
elif [ $RAM -le 1024 ]; then
JAVA_MAX_HEAP=896
#CrashPlan PROe server's default max heap is 1GB
elif [ $RAM -gt 1024 ]; then
JAVA_MAX_HEAP=1024
fi
if [ $USR_MAX_HEAP -gt $JAVA_MAX_HEAP ]; then
JAVA_MAX_HEAP=${USR_MAX_HEAP}
fi
if [ $JAVA_MAX_HEAP -lt $JAVA_MIN_HEAP ]; then
#can't have a max heap lower than min heap (ARM low RAM systems)
JAVA_MIN_HEAP=${JAVA_MAX_HEAP}
fi
#reset ownership of all files to daemon user, so that manual edits to config files won't cause problems
chown -R ${DAEMON_USER} ${SYNOPKG_PKGDEST}
chown -R ${DAEMON_USER} ${DAEMON_HOME}
#CrashPlan PROe server will read customized vars from a separate file
eval echo "JAVA_GC_ARGS='\"'${JAVA_GC_ARGS}'\"'" > ${OPTDIR}/.proserverrc
eval echo "JAVA_MEM_ARGS='\"'${JAVA_MEM_ARGS}'\"'" >> ${OPTDIR}/.proserverrc
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} start"
exit 0
;;
stop)
su - ${DAEMON_USER} -s /bin/sh -c "${OPTDIR}/bin/${ENGINE_SCRIPT} stop"
exit 0
;;
status)
PID=`/bin/ps w| grep "app=${APP_NAME}" | grep -v grep | awk '{ print $1 }'`
if [[ -n "$PID" ]]; then
exit 0
else
exit 1
fi
;;
log)
echo "${LOG_FILE}"
exit 0
;;
esac
Changelog:
- 020 added support for Intel Atom Evansport CPU in some new DSx14 products
- 019 update to CrashPlan PROe Server 3.5.5, improved update handling
- 018 update to CrashPlan PROe Server 3.4.1.5, improved update handling, fixes for DSM 4.2
- 017 update to CrashPlan PROe Server 3.4.1, improved update handling
- 016 update to CrashPlan PROe Server 3.3.0.4
- 015 further fixes for the update mechanism
- 014 created a wrapper for the ps command, and a symlink for /bin/bash which should hopefully allow server upgrade scripts from Code 42 to run
- 013 fixed a timezone detection bug
- 012 fixed a bug with the script editing logic which amends Code 42’s scripts to work with busybox shell tools
- 011 updated to CrashPlan PROe Server 3.3.0.3
- 010 intial public release
PC LOAD LETTER 
Hello,
This is working “mostly”. I have Crashplan Pro (not e), running on a DS1010+. It quits frequently and I have to continually stop/ start the service in the GUI. I believe that the problem is (at least in part), related to the Java heap size. I am not great with the command line but was able to get to the correct directory above and tried to vi the file. There is nothing in that file (or perhaps it does not exist)?
Is there any way you can provide more “novice” instruction on how to up the heap? Or, if that is not the issue, some more places to investigate? I have almost 3TB to backup. I have installed 3GB of ram in the DS as well.
Great work on this and thanks in advance for your help.
Best,
Charlie-
Hello Patters,
Since getting the heap-size straightened out, things have been running great. I have never had even 1/2 day of straight runtime let alone the 4 that have the most important things just about backed-up finally.
My next question is that by enabling CP to be the “head”, I was wondering how to backup to another disk as well (critical docs). I run CP on my server and attached via firewire is another local drive that I would like to direct backups to. I believe the problem is that the mod to the CP vars file to point to the DS may not be allowing access to the drive attached to the server.
Syno is a .9 address and the server is .192. I was wondering if there was a way to get both visible by another mod to that file, or if the file needs to be “put back” whenever a “local” backup is to be run, or if none of this is possible because of the current setup?
Thanks,
Charlie-
Patters,
Backups were running (albeit very slowly at ≈1.3Mbps), with something like 90 days remaining. Anyway, I noticed that the client was stopped and could not connect to the server. Went to my 1010+ and saw the service was stopped. Tried to start it and it won’t. Looked under the log tab and saw that it stopped itself because an update was available. It apparently updated itself and now does not run. Any ideas? This just happened.
Best,
Charlie-
Hi Patters,
Thanks for all the hard work on the Synology packages. I have been trying to access http://pcloadletter.comlu.com for a few hours now to no avail. Is there a mirror, or alternative way of downloading the crashplan / java packages required for the ATOM Synology NAS devices?
Thank you,
Adam.
The webhost it’s hosted with has been added to some blocklist which a few ISPs are enforcing. I tried to find out more info but couldn’t. Anyway, here’s what you need:
http://dl.dropbox.com/u/1188556/blog/java1.6.0_32-merged-009.spk
http://dl.dropbox.com/u/1188556/blog/crashplan3.2-merged-010.spk
Hi Patters,
Thanks a lot for all the work on Crashplan packages for Synology.
We’re testing your 3.2.1.2-010 PROe packages on a RS2212+ since July. So far, has proving quite stable and works very well.
Do you plan on updating your packages, following the recent release of the 3.3.0.3 version ?
Cheers
Jean-Laurent
Thanks for the heads up. I’ll take a look.
I have updated the package. Does it work ok (particularly the upgrade)?
Unfortunately, after updating java and updating the package, the server won’t start anymore (the button still display “run”, no process running, nothing listening on ports :428x)
Should I try to uninstall it before installing again ? Won’t I lose my configurations (or worse, the backups) if I do so ?
Thanks
Here is what I did:
1) copy /volume1/@appstore/cpproeserver [containing the application] and @appstore/cpproeserver_data_migration to another volume (to keep configuration, etc..)
2) rename /volume2/cpproeserver/ [containing the backups] to /volume2/cpproserver.bak (cannot move to another volume, too large)
3) uninstall crashplan from DSM — apparently successfull
4) reinstall crashplan — apprently successfull (timestamps indicate that the files in @appstore/cpproeserver were freshly installed)
But no luck, the service still won’t start !
Did I forget something ?
interesting: while the run button in DSM remains without effect, this command line can launch the server:
/volume1/@appstore/cpproeserver/proserver/server/bin:$ ash proserver start
Output:
——————–
Starting CrashPlan PROe Server … ps: invalid option — e
BusyBox v1.16.1 (2012-04-13 04:46:01 CST) multi-call binary.
Usage: ps
Report process status
Options:
w Wide output
Using standard startup
STARTED
——————-
Hoping that I would get back my configuration, I restored all the folders that I “backuped” in the steps described above (post August 21, 2012 at 15:10).
Crashplan prompted me with a “Create your PROe Admin Account”, showing that the conf may have been lost during the upgrade.
Before taking any further step, I’m finally going to copy my backups to another volume, just in case.
It will take a long time (3TB of data)
Let me know if you come with some idea to restore the configuration please.
I’ll take a look in a short while when I get home.
Good news is: all the database dumps are still here. And if I understand well, the configuration is in . So there is hope ;-)
Bad news is: “Unable to import database dump.”
I’ll contact Crashplan helpdesk to see if they have a clue (and continue to let you know about the progress)
Sorry, I didn’t have time to look at this last night. By running it manually you may be running into permissions issues on the various config and datafiles. If you need to return to the previous version you can download it directly here:
http://dl.dropbox.com/u/1188556/blog/old/cpproeserver3.2.1.2-merged-010.spk
I have fixed the bugs (new version on repo), so hopefully it may work for you now.
Hi Patters
Thanks for the update.
However, I still could not import the database dump.
Here are the steps I followed:
1) uninstalled Crashplan PROe server completely
2) fresh install with your new package.
3) created a new admin account, the Settings > Import Database
–> Same issue: “Unable to import database dump.”
I tried with Command Line Tools also:
As root, in the folder /volume1/@appstore/cpproeserver/proserver/server/bin
———
$ ash ./restore_database.sh /volume2/cpproeserver/data/backupArchives/CrashPlanArchive_Default/dbDumps/proserver-db_13328244
01321_2012-08-21_020109.sql.gz
Shutting down PROe Server…
Restore process was not successful, will not restart PROe Server. View ./import.log for details.
———
$ cat import.log
Stopping CrashPlan PROe Server … Monitoring PROe Server for stop …. .. detected stop
sleeping for server shutdown: 30s
———
Not much feedback in the logs, as you can see.. The script is pretty simple (just calling a java method). I’m not skilled enough to tell if the problem comes from the script, the java method, or another issue.
Finally, I reinstalled the old 3.2.1.2 version (with the link you provided). The import apparently worked well (I got all my settings and status back), except that this strange error message appears in the settings screen:
“Database import on server XXXX created a backup that needs to be moved or removed.”
I can’t find anything about this error message on google/crashplan support pages.
I still have to run some checks. Will let you know.
JL
I think the problem is going to be that I can’t really test that aspect of it, since I don’t have a licence for CP PROe server. I can only check that the server starts ok. My initial work on developing the package was done for a company that had paid for a licence, so I had a bit more control then.
Have you tried doing an in-place upgrade (via Package Center) or does that fail too? I guess it sounds from your last post that maybe the only way to upgrade is to use this export/import facility in the application’s admin website. For that I suppose you’ll have to wait for a reply from Code 42 support. However, they’re not exactly known for being accommodating to users who are running on “different” types of server platform.
Actually Jean-Laurent, I’ve just had a look through the documentation (d’oh) and it’s pretty clear – the Server must be manually upgraded using the admin web page!
http://www.crashplan.com/enterprise/support/doku.php/upgrades
I’ll take a look at the contents of one of these upgrades and see how they work. If we’re lucky, they’ll be entirely Java based and should just work. If there are shell scripts it will get complicated…
Hmmm. Ok, the upgrades are just zip files, but they do contain some shell scripts with command syntax that’s incompatible with Synology’s busybox shell. I think I have a fix though.
On your working 3.2.1.2 install try running the following commands as root, restart the package, then apply the downloaded 3.2.1.2 to 3.3.0.2 upgrade file via the admin page:
Let me know how you get on. You should see if it worked in the log (ignore Package Center’s version number).
I’ve re-issued the package so that these fixes are built-in going forward. I also updated the notes on this page.
Hi Patters,
I understand the situation of course (however, note that you don’t need a license to install and use PROe server, only the clients require a license :-) )
I’ll let you know what Code 42 support says (I agree that they are not extremely cooperative once “synology” in mentioned), and try the upgrade function again next week.
However, I don’t think the upgrade will work: if the function was broken on a fresh install, it is very unlikely it will work after an upgrade..
Thanks again
JL
I just saw your newest comment on August 23, 2012 at 16:11 !
Sure, I will try your suggestion.
Unfortunately, this method didn’t work neither.
I created all the links and modified the .profile as suggested.
Then used PROe admin interface to update from 3.2.1.2 to 3.3.0.2 using the package provided by Code 42.
After stopping, the service did not restart. I used the package manager to restart PROe service.
But obviously, the update didn’t work: version 3.2.1.2 was still running.
The history logs are useless:
I 08/24/12 07:59PM Core.stopped
I 08/24/12 07:59PM Server stopped
I 08/24/12 08:10PM Server started – 3.2.1.2 – 1332824401321 (2012-03-27T05:00:01:321+0000)
Nothing in other logs neither…
Is there any way I can launch the update using command line ?
To see if I can get more useful information ..
Download the update to somewhere like /volume1/@tmp
Then switch to the cpproeserver user and run it manually.
su - cpproeserver -s /bin/shcd /volume1/@tmp
unzip CrashPlanPROServer_3.3.0.2_from_3.2.1.2_Linux.upgrade
Then run the upgrade shell script inside. I guess you may get some feedback of what the problem is.
Here is what I found:
1) feedback from Crashplan
“If the upgrade failed, then I recommend that you reinstall the previous version of PRO Server you were on, import your database, and try the upgrade again. You can not import a database file from an older version of PRO Server into a newer version. The upgrade needs to be successful to retain your database and upgrade that along with the PRO Server.”
This explains why I could not use my database dumps in your fresh install of Crashplan 3.3.0.3 !
2) upgrade process
Apparently:
After uploading the upgrade file through the admin interface, the upgrade file is decompressed in this folder:
`/volume1/@appstore/cpproeserver/proserver/server/upgrade/
The upgrade.sh script will create a “upgrade.log” file in that folder, providing some useful information.
In my case, the file content is:
Fri Aug 24 19:59:00 CST 2012 : /volume1/@appstore/cpproeserver/proserver/server/upgrade/1345809524480 Upgrading PRO Server
Beginning PROe Server Upgrade
Disabling any PROe Server processes that still remain
sleeping for template render
./upgrade_impl.sh: line 38: /proserver: No such file or directory
/bin/ps: invalid option -- e
BusyBox v1.16.1 (2012-04-13 04:46:01 CST) multi-call binary.
Usage: ps
Report process status
Options:
w Wide output
sleeping for server shutdown
Backing up the database
copying the database
backing up the database
./upgrade_impl.sh: line 58: /bin/java: No such file or directory
!! Cancelling Upgrade !!
Cause: Unable to redundantly back up the database
Starting PROe Server
./upgrade_impl.sh: line 15: /proserver: No such file or directory
Problem 1:
`./upgrade_impl.sh: line 58: /bin/java: No such file or directory
That solved the problem:
`[ -e /bin/java ] || ln -s /volume1/@appstore/java6/jre/bin/java /bin/java
Problem 2:
`./upgrade_impl.sh: line 15: /proserver: No such file or directory
This file contains 3 lines similar to this one:
`${INITDIR}/proserver stop
The problem is that the variable INITDIR is not properly set.
The script upgrade.sh (calling upgrade_impl.sh) does not set this variable at all.
Any idea how to set this variable properly ?
Do you think that adding this line in upgrade.sh or upgrade_impl.sh would do ?
`export INITDIR=/volume1/cpproeserver/proeserver/server/bin/
JL
I read somewhere that ” ` ” characters at the beginning of a line could replace
in wordpress, seems it doesn’t work that well :)…could replace <code></code>…
I think the most important thing is that you have discovered which folder the upgrades get decompressed to. I can now just adapt the package startup script to check this location for .sh files and amend them correctly, then launch them first if they’re present.
By the way, it seems that the update folder will NOT be cleaned up after the update.
The method to check for .sh files may not work reliably.
Maybe the “best” method would be to let the user do the update through the web interface ?
In which case, you could just modify your install script and add:
[ -e /bin/java ] || ln -s /volume1/@appstore/java6/jre/bin/java /bin/java
(and maybe set INITDIR in the .profile of user cpproeserver ?)
I already have that first point covered in my CrashPlan client package. Look at line 83 of start-stop-status.sh:
The file gets renamed to upgrade.sh.old after it has been run, to prevent it from being detected next startup.
The subfolder with a long version ID is also the same as with client updates, which I have already fixed. Fixing the scripts and having start-stop-status.sh run them is probably a better method really, because Code42 have a habit of using non-universal syntax for stuff like rm, mv and ps which is quite likely to break the update.
In your second point, I think it’s only looking for /bin/java because some variable it uses has a null value when you’re testing (like $JAVA_COMMON).
I would expect that before it invokes upgrade.sh CrashPlan PROe server is quite likely to source /volume1/@appstore/cpproeserver/proserver/server/.install.vars which will fix some of those issues, so my script will also need to do this. But I guess INITDIR is missing though, so I’ll need to add that. I’ll need to inspect the precise workings of Code42’s setup script again to see if it’s something I missed…
Might not be ready today, but I should have something for you to test tomorrow.
Ok, hopefully I have it solved now.
So, firstly use Package Center to upgrade your test 3.2.1.2 server using this newer version of the 3.2.1.2 package:
http://dl.dropbox.com/u/1188556/blog/cpproeserver3.2.1.2-merged-015.spk
Once that’s done, load the 3.2.1.2 to 3.3.0.2 update from Code 42 via the web app. It will fail and stop CrashPlan PROe server in Package Center. Start the package again in Package Center and it should fix that upgrade script, make a log entry, run the update, and start the package. Then you should be able to do the same with the 3.3.0.2 to 3.3.0.3 update. Once both updates have been applied (check the logs for the running version) you should be able to update in Package Center to my latest package, preserving the data and so finally the correct version is reported in Package Center. Can you let me know if it works? I can’t test because apparently I need a master key to even use the web app.
EDIT fixed a stupid mistake in the package at 16:27. If you downloaded before that you’ll need to download again.
Hi Patters,
Sorry to get back to you so late. I was out of town yesterday.
I have one more server running 3.2.1.2. It was a custom install as we could _not_ add your package source (http://pcloadletter.comlu.com) and hence, could _not_ use your packages to make the install few months ago.
Most probably, the problems comes from the “great firewall of China” (that server is installed in Shanghai)
I’m running a few tests to confirm this assumption, and will get back to you asap.
JL
Try using my newly established mirror package source: http://packages.pcloadletter.co.uk
Thanks a million times.
The mirror package source works absolutely fine, and I can see all your packaged software in the Package Center.
But unfortunately, downloading the packages still fails. I guess it is because they are stored on dropbox – and dropbox is currently on the “no go” list of our friends from the CCP…
Problem is: drop box relies on amazon AWS, and the IP of dl.dropbox.com changes all the time. I won’t be able to tunnel the traffic through another location in this case.
Is there any way know where the Package Center is supposed to find the .spk’s, so I can download them myself, and them push them to our Shanghai server ?
PS: if you wonder, the “great firewall of china” uses several techniques to block access to website. In that case, it is obviously a DPI approach. The DNS name resolves well, establishing connections with AWS server works, but as soon as the HTTP request mentions “Host: dl.dropbox.com” … connection reset. This is China…
Hi JL, I have updated the definitions on packages.pcloadletter.co.uk to collect the .spk files from that same hosting environment so those should work in China. You’ll also need to update to the newest 3.2.1.2 package before you attempt the upgrade using the Code 42 updates. This can be found here:
http://packages.pcloadletter.co.uk/downloads/cpproeserver3.2.1.2-merged-015.spk
Let me know if it works finally!
Great news coming !
Steps to change from our “in house” install to your package [3.2.1.2]:
– removed the previous java package (not yours)
– added your java package
– moved previous CP PROe install to a temporary directory
– Installed your 3.2.1.2-015 package
– copied db Dumps from previous install to /volume1/cpproeserver/data/dumps/
– copied backup archives from previous install to /volume1/cpproeserver/data/backupArchives/
– $ chown -R cpproeserver:users …
– created a temporary admin account
– imported latest db dump
–> all data restored ! (although still cannot communicate with master server due to software version difference)
Steps to upgrade:
– went to settings > upgrade
– selected upgrade file from Code 42
–> it works perfectly :)
(could it be easier ?)
Really, thanks for your work on CP PROe server, and helping me (and the 1.3 billion Chinese people eagerly waiting for CP PROe server to work on their Synology servers ;-) ) with my setup.
Little update:
Update from 3.3.0.2 to 3.3.0.3,was possible, but didn’t go as smoothly as 3.2.1.2 –> 3.3.0.2.
After the update:
– CP PROe server didn’t restart
– DSM Package Center run/stop button doesn’t work (it seems it worked well with 3.3.0.2)
Same problem as before in the logs:
./upgrade_impl.sh: line 214: /proserver: No such file or directoryThe content of upgrade_impl.sh looks similar, with this kind of lines raising the error:
${INITDIR}/proserver startUsing the below command line could restart the server properly:
su - cpproeserver -s /volume1/@appstore/cpproeserver/proserver/server/bin/proserver startActive version number is 3.3.0.3, which is good.
Update from 3.3.0.3 to 3.3.0.4 (released today) --> same (update successful, but requires server restart with command line - DSM package center run button is broken)
If you still have time to improve the packages, I have two servers running 3.3.0.2 on which I can tests upgrades.
Cheers,
JL
On your synos that no longer start CP PROe Server using Package Center, check the contents of /volume1/@appstore/cpproeserver/preserver/server/.install.vars. It should look like this:
OPTDIR=/volume1/@appstore/cpproeserver/proserver/serverVAROPTDIR=/volume1/cpproeserver/data
VARLOGDIR=/volume1/cpproeserver/log
ETCDIR=/volume1/@appstore/cpproeserver/proserver/server/bin
INITDIR=/volume1/@appstore/cpproeserver/proserver/server/bin
RUNLVLD=/volume1/@appstore/cpproeserver/proserver/server/bin
INSTALLDATE=20120831
JAVACOMMON=${JAVA_HOME}/bin/java
For the systems on 3.3.0.2, try first updating the spk to the 3.3.0.2 version, then apply the 3.3.0.2 to 3.3.0.3 update.
The one on the repo is 3.3.0.4 but they’re all available directly here:
http://packages.pcloadletter.co.uk/downloads/cpproeserver3.2.1.2-merged-016.spk
http://packages.pcloadletter.co.uk/downloads/cpproeserver3.3.0.2-merged-016.spk
http://packages.pcloadletter.co.uk/downloads/cpproeserver3.3.0.3-merged-016.spk
http://packages.pcloadletter.co.uk/downloads/cpproeserver3.3.0.4-merged-016.spk
You sorted it out again..
My .install.vars were, indeed, missing 2 lines (INITDIR and RUNLVLD). I have no idea why (I did not edit this file for sure – I didn’t even realized it existed !)
Adding the missing lines repaired the Package Center “run” button, and allowed painless updates again.
Updates tested : 3.3.0.2 -> 3.3.0.3 -> 3.3.04, on 3 servers, everything works well.
Thanks again !
That’s great news J-L. Thanks for getting back to me.
Just one thing: the update will be deflated in a subdirectory of …../upgrade/, not in …./upgrade itself.
The name of that subdirectory is a kind of 13-digits timestamp. (in below example, the three folders starting with “134”)
The name does not seems to be important.
The update script will also create an additional folder containing backups of the database (in below example, the three folders starting with “3.3_201208”)
$ ls -al
drwxr-xr-x 8 cpproese users 4096 Aug 27 09:22 .
drwxr-xr-x 22 cpproese root 4096 Aug 27 09:23 ..
drwxr-xr-x 3 cpproese users 4096 Aug 27 09:25 1345808392456
drwxr-xr-x 3 cpproese users 4096 Aug 27 09:25 1345809524480
drwxr-xr-x 2 cpproese users 4096 Aug 27 09:24 1346059341360
drwxr-xr-x 3 cpproese users 4096 Aug 24 11:40 3.3_20120824_194011
drwxr-xr-x 3 cpproese users 4096 Aug 24 11:59 3.3_20120824_195900
drwxr-xr-x 5 cpproese users 4096 Aug 27 09:23 3.3_20120827_172242
-rw-r--r-- 1 cpproese users 3070 Aug 27 09:24 upgrade.log
-rw-r--r-- 1 cpproese users 123 Aug 27 09:22 upgrade.properties
PS: there are three sets of folders because I made 3 upgrade attempts on this server.
JL
Content of a folder after an UNsuccessful upgrade:
$ ls -al 1345809524480/
drwxr-xr-x 3 cpproese users 4096 Aug 27 09:25 .
drwxr-xr-x 8 cpproese users 4096 Aug 27 09:22 ..
-rw-r--r-- 1 cpproese users 3466 Aug 24 11:58 alter.sql
-rw-r--r-- 1 cpproese users 26 Aug 24 11:58 analyze.sql
drwxr-xr-x 14 cpproese users 4096 Aug 24 11:58 files
-rw-r--r-- 1 cpproese users 105 Aug 24 11:59 upgrade.properties
-rwxrwxrwx 1 cpproese users 475 Aug 27 09:25 upgrade.sh
-rwxr-xr-- 1 cpproese users 6500 Aug 27 09:25 upgrade_impl.sh
Content of a folder after a successful upgrade:
$ ls -al 1346059341360/
drwxr-xr-x 2 cpproese users 4096 Aug 27 09:24 .
drwxr-xr-x 8 cpproese users 4096 Aug 27 09:22 ..
-rw-r--r-- 1 cpproese users 3466 Aug 27 09:22 alter.sql
-rw-r--r-- 1 cpproese users 26 Aug 27 09:22 analyze.sql
-rw-r--r-- 1 cpproese users 105 Aug 27 09:22 upgrade.properties
-rwxrwxrwx 1 cpproese users 475 Aug 27 09:24 upgrade.sh
-rwxr-xr-- 1 cpproese users 6500 Aug 27 09:24 upgrade_impl.sh
(notice that the difference is that, after a successful update, the “./files/” folder disappeared – however, the scripts remain)
JL
Just to tell you that I have successfully upgraded a second server (configured as a “slave”) using the above method (create symbolic links and other replacements for “ps”, “bash” and “java”, add PATH in .profile, launch update from the admin web page)
The only (very small) issue is that the service needs to be restarted manually from the Package Center, due to INITDIR not being setup.
Thanks a lot :)
When I initially commented I clicked the “Notify me when new comments are added” checkbox and now each time a comment is added I get
four emails with the same comment. Is there any way you can remove me from that service?
Thanks!
I can’t I’m afraid, but there’s a link in each email I believe which takes you to an unsubscribe screen on WordPress.
This looks fantastic! I’m looking to place an order for crashplan proe soon and will definitely be using your link. One question however. Version 3.4.1 introduced automatic upgrade functionality for storage servers, my synology nas’s will be storage servers connected to a master. Is this something that will work? Thanks for making this available!
Anyone updated from CrashPlanPROe Server 3.3.0.4 to 3.4.1.4?
cpproeserver3.4.1-merged-017.spk was pulled and they are now posting cpproeserver3.4.1.5-merged-017.spk as the only 3.4.1 version. What does it take to get that spk script written?
Can you try the new version I’ve made live on the repo?
Thanks! I can not get the 3.3.0.4 db’s to import, but server 3.4.1.5 does install using the new repo. If you have any suggestions, I would appreciate them. I may have to just re-run my backups and manually remove the old backups.
The action should be:
. Dump databases
. Download upgrade package from Code 42.
. Apply upgrade package via CrashPlan PROe Server web console
. Synology package will stop during this update
. Leave it a few minutes, then start via Synology Package Center
. Leave it a few minutes, hopefully it’s worked
. Finally, apply Synology Package update via Package Center
If you already upgraded the Synology package, but you have a database backup, you could always re-install the 3.4.1 spk package from the download link on this page, re-import your backed up database, then run through those steps again.
Except I am coming from 3.3.0.4. The “Apply upgrade package via CrashPlan PROe Server web console” is where it errors out. I do not have details on the error and have not dug into where the log file is to analyze this.
One thing the I am very mad at Code 42 about is their practice of pulling a production released version from customer availability and not allowing any access to it. The 3.4.1.0 – 3.4.1.4 versions are not available and they would not send anything to me. That is why I had to install 3.3.0.4 I am a software engineer (20+ years) and I would fire someone or be fired for pulling production versions in an environment like this.
I will re-install 3.3.0.4 and get it running again then re-try the upgrade after I figure out where the log file for the apply upgrade package is stored. This may have to wait till tomorrow as I am out of the office soon. Many thanks and happy new year!
The downloads do remain on Code42’s webserver. My spk packages are only a few scripts – they pull the downloads from Code42. You can infer the filenames of the historic ones by inspecting the current downloadable one. It does remain a somewhat risky proposition for you, relying on this unsupported installation, maintained only by me. Don’t stake your business on it. Happy new year!
Hey there!
Great thing I can automatically update your apps in synology package-center via adding your URL http://packages.pcloadletter.co.uk/
How did you set up that “package-server”? I’d love to have that for my app as well :-)
Cheers!
Andi
Hello Patters. CrashPlan has now released CrashPlan PROe 3.5.4. Do we need to wait for you to release a Synology package that corresponds with that version to update a Synology NAS running CrashPlan PROe server or can we just use the latest syno package you have available and install the CrashPlan upgrade file via the Web Interface of the CrashPlan PROe server like I’m used to doing on the other CrashPlan PROe servers I managed (not running on Synology NAS hardware)?
Package updated to support the latest CrashPlan PROe server build.
Patters, Thanks for updating your packages. I really appreciate it!
Patters,
I need some help with the upgrade process. I’m trying to update my install from 3.3.0.4 to 3.1.4.5. I downloaded the linux .upgrade file from CrashPlan and ran it from the admin interface on port 4280 (I have lots of CrashPlan ProE experience). That errored out unitl I symlinked /bin/bash properly like you instructured earlier in the thread but once I did that it did take the upgrade from the admin interface properly and started processing. However after that it stopped the process and it shows “stopped” in the package center. I tried to manually install the 3.1.4.5 spk since I don’t want to go all the way to 3.5.5 yet and it just error out looking for the 3.1.4.5 installer and not paying attention to the fact that I had an upgrade in place. In addion it removed the working install I had of 3.3.0.4. I must be doing something wrong but I’ve been following your steps closely (or at least trying). Can you clarify the upgrade process for me. I thought we didn’t need to do the sum linking anymore in the new packages you created but mine wouldn’t take until I had /bin/bash properly sym linked to the bash executable you included in your package.
Hi Chad, unfortunately I don’t actually use this package so it’s very much ‘at your own risk’ but that said you will still need to install each version’s spk after applying the .upgrade files. This is because the .upgrade is actually just prepping the database, not fully upgrading the whole thing.
Patters,
Thanks for responding. The problem I have when I try to “install over the top” with the new version of the .spk file is that the .spk install looks for the proper version of the CPP installer to be in the /public folder and when it’s not there it actually removes my working CPP install from the Synology device. If I were upgrading CPP on a regular linux machine I wouldn’t have to download the new version of the installer each time I want to upgrade. Do I need to actually download the CPP installer (for instance the 3.4.1.5 installer) of the version on which I intend to upgrade to and place that in the public folder anyway? The .upgrade file that CPP distributes is all you need to upgrade a CPP install on a regular Linux box.
It’s been a long time since I worked on this but yes, I think that for the purposes of the Synology package you will need to get that big 300MB installer for each version you’re incrementing through.
Hi,
After a crash of our hard disks, we lost our administration console (was installed on /volume1, after restoring some data on /volume2 the /volume1 was removed). Now we have 2 volumes (/volume2 – crashplan data and a new /volume3 – that contains other backup storage)
I have uninstalled the package and reinstall it manually (crashplan proe v3.1.4.5) on /volume2/ by using your old package.
After restoring the database thanks to our dump file, I found that the logs are pointing on /volume3/cpproeserver/logs/ instead of /volume2/cpproeserver/logs/. I found in @appstore/cpproeserver/proserver/server/ that 2 files contains this wrong volume information (.install.vars and conf/conf_proe.properties).
Extrat of conf_proe.properties:
“c42.cpc.external.identity.property.path = /volume3/cpproeserver/data/.identity
c42.batchjob.status.dir = /volume3/cpproeserver/data/batch-status
b42.cpc.client.log.file.path = /volume3/cpproeserver/data/client-logs
# no special treatment on linux
b42.cpc.cache.path = /volume3/cpproeserver/data/backupCache
b42.system.migration.file = /volume3/cpproeserver/data/.migrations
b42.system.jobqueue.dir = /volume3/cpproeserver/data/.jobqueue
c42.cpc.default.mount.point.prefix.path = /volume3/cpproeserver/data/backupArchives
b42.export.db.destination.folder.optional = /volume3/cpproeserver/data/dumps
c42.log.path = /volume3/cpproeserver/log”
Extract of .install.vars:
“VAROPTDIR=/volume3/cpproeserver/data
VARLOGDIR=/volume3/cpproeserver/log”
When I tried to modified these two files and start the package, it starts for few seconds or minutes. On the logs, the system refer to log4j logger which is not properly setup:
log4j:WARN No appenders could be found for logger (com.code42.core.impl.Core).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
Do you have an idea, how I can resetup the log on /volume2/ and keep our administration console running?
Temporary all dump files, client and server logs are stored on /volume3/, until I found a solution to this problem.
Thanks for your help.
Any chance to get this updated for 3.6.1.2 or 3.6.1.5? I can throw cash your way. Thanks!
Thanks a lot for the great package.
I would also be very interested in an update to version 3.6.1.5. Can also support you with some funding, if that helps. Please let me know.
Hi Patters, we needed to reinstall the 3.5.5-20 server, but it won’t start. On DSM 5.0 we have Java7 installed, Java6 isn’t available in the needed .tar.gz-format anymore.
Trying to start the server from the commandline shows the error “file not found”. The binary has execute-permission…. no entry in the log found…
Any hints? Many thanks in advance
Java 6 is still available, it’s on an archived versions page:
http://www.oracle.com/technetwork/java/embedded/embedded-se/downloads/default-1934076.html
I think the problem is that the binaries file was moved on my repository when I re-did the regular CrashPlan packages. I forgot that of course the server has this same dependency. I’ve fixed that, so it should work now.
Apologies for the delay, haven’t had much time available for Synology stuff.
Hey there,
Is there a way to install a previous version of the PROe server instead of the latest one in your repository, namely 5.1.1? Trying to get someone back up and running with their database dumps from that specific version. Otherwise, I think their data is hosed, unless I’m missing something.
Thanks for any help in advance!
Hi patters,
I was hoping to install the proe server through your packages site but it is not presented to my DS-1815+. It’s an x86 Intel platform so I’m not sure why it wouldn’t be visible. Any ideas? Thanks!
I stopped updating the CrashPlan PROe Server package as I no longer had access to an Intel NAS. I have one now, so I may revisit it. It’s not a priority though.
Hey Patters,
I’m showing interest in your package if you have time to work on it. So far, I’m getting the install and start_stop script and trying to patch things together without much luck
Thanks,
Frank
Hi Patters,
I am running crashplan pro e server on a Synology and I applied cpproeserver3.5.5-merged-0020.spk so I could update from 3.5.5 to 3.6.1.5 using the file CrashPlanPROServer_3.6.1.5_from_3.5.5_Linux.upgrade . Once I applied the .spk file, I could not connect to the server anymore to do the upgrade. I ended up deleting pro e from the synology and now to reinstall and now I lost all the settings and users. Can you help me recover that. I did run a database backup before I started but when I go to the Server Settings and “Import Database” I get the message “No database dump files were found.”
I was able to recover the backup with the help of code42 support. But I could not get the upgraded file to successfully work so I am still using 3.5.5
I have been having difficulties with the crashplan pro e server ever since I tried and failed to upgrade to 3.6.1.5 fro 3.5.5. I most recently
– uninstalled the crashplan proe 3.5.5
– removed the /var/cpproeserver directory
– removed the /volume1/@appstore/cpproeserver directory
– reinstalled patters crashplan proe server on the Synology
– configured crashplan proe server with my license/product keys
– used a root ssh session to restore the database to before I initially tried to install the newer version using the command: /volume1/@appstore/cpproeserver/proserver/server/bin/restore_database.sh /volume1/cpproeserver/data/backupArchives/CrashPlanArchive_Default/dbDumps/
Everything worked fine for almost a full day. When I logged out of the ssh session, the server interface disconnected immediately. I cannot restart the server from the Synology crashplan proe action menu.
Is this a permission problem? I restored using a root session not an admin session.
Why is the software writing to /var directory (data log) and not on /volume1? The db dump and logs are on /var is this the correct location?