CrashPlan PROe Server package for Synology NAS

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!

CrashPlan-PROe-dashboard

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.

CrashPlan-PROe-server-info

 

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
 
 
About these ads

64 thoughts on “CrashPlan PROe Server package for Synology NAS

  1. Charlie Pendleton

    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-

    Reply
  2. 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-

    Reply
  3. 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-

    Reply
  4. Adam

    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.

    Reply
      1. Jean-Laurent

        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

  5. Jean-Laurent

    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

    Reply
  6. Jean-Laurent

    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 ?

    Reply
  7. Jean-Laurent

    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
    ——————-

    Reply
  8. Jean-Laurent

    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.

    Reply
  9. Jean-Laurent

    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)

    Reply
      1. Jean-Laurent

        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

      2. patters Post author

        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.

      3. patters Post author

        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…

      4. patters Post author

        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:

        [ -e /bin/bash ] || ln -s /volume1/@appstore/cpproeserver/bin/bash /bin/bash
        echo "#!/bin/bash" > /volume1/@appstore/cpproeserver/bin/ps
        echo "ps -w" >> /volume1/@appstore/cpproeserver/bin/ps
        su - cpproeserver -s /bin/sh -c "echo export PATH=/volume1/@appstore/cpproeserver/bin:$PATH >> .profile"

        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.

  10. Jean-Laurent

    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

    Reply
  11. Jean-Laurent

    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 ..

    Reply
    1. patters Post author

      Download the update to somewhere like /volume1/@tmp
      Then switch to the cpproeserver user and run it manually.
      su - cpproeserver -s /bin/sh
      cd /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.

      Reply
      1. Jean-Laurent

        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

      2. Jean-Laurent

        I read somewhere that ” ` ” characters at the beginning of a line could replace in wordpress, seems it doesn’t work that well :)

    1. patters Post author

      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.

      Reply
      1. Jean-Laurent

        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 ?)

      2. patters Post author

        I already have that first point covered in my CrashPlan client package. Look at line 83 of start-stop-status.sh:
        http://pcloadletter.co.uk/2012/01/30/crashplan-syno-package/
        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.

      3. patters Post author

        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.

      4. Jean-Laurent

        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

      5. Jean-Laurent

        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…

      6. Jean-Laurent

        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.

      7. Jean-Laurent

        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 directory

        The content of upgrade_impl.sh looks similar, with this kind of lines raising the error:
        ${INITDIR}/proserver start

        Using the below command line could restart the server properly:
        su - cpproeserver -s /volume1/@appstore/cpproeserver/proserver/server/bin/proserver start

        Active 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

      8. patters Post author

        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/server
        VAROPTDIR=/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

      9. Jean-Laurent

        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 !

  12. Jean-Laurent

    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

    Reply
    1. Jean-Laurent

      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

      Reply
  13. Jean-Laurent

    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 :)

    Reply
  14. Leandro

    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!

    Reply
  15. Blaine

    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!

    Reply
  16. mike

    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?

    Reply
      1. mike

        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.

      2. patters Post author

        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.

  17. mike

    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!

    Reply
    1. patters Post author

      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!

      Reply
  18. Chad McDonald

    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)?

    Reply
  19. Chad McDonald

    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.

    Reply
    1. patters Post author

      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.

      Reply
  20. Chad McDonald

    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.

    Reply
    1. patters Post author

      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.

      Reply
  21. Benoit

    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.

    Reply
    1. Pascal

      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.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s