Synology NAS: Running CrashPlan in Docker Container

BACKGROUND

The reason to run CrashPlan in Docker container is to prevent any future Synology’s DSM updates from breaking the CrashPlan app.

Let’s assume the Synology NAS IP address is 1.2.3.4.

STEPS

Diskstation Manager

Log into Diskstation Manager: http://1.2.3.4:5000

Install Docker.

Package Center -> Utilities -> Third Party -> Docker

Mac

SSH into Synology NAS.

ssh admin@1.2.3.4

Install CrashPlan Docker container.

sudo docker pull jrcs/crashplan

Run CrashPlan Docker container. In this example, we want to backup photo and video directories.

sudo docker run -d --name CrashPlan \
 -p 4242:4242 -p 4243:4243 \
 -v /volume1/photo:/volume1/photo -v /volume1/video:/volume1/video \
 jrcs/crashplan:latest

Back to Diskstation Manager

Get authentication token from the running CrashPlan.

Docker -> Container -> CrashPlan -> Details -> Terminal -> Create -> bash

Run command:-

cat /var/lib/crashplan/.ui_info

The following text are printed:-

4243,########-####-####-####-############,0.0.0.0

Copy ########-####-####-####-############ to somewhere first.

By default, CrashPlan allocates 1GB of memory. The recommendation is to allocate 1GB of memory per 1TB of storage to prevent CrashPlan from running out of memory. In this example, we are going to increase it to 3GB.

Edit /var/crashplan/conf/my.service.xml.

vi /var/crashplan/conf/my.service.xml

Change the following line:-

<config ...="">
	...
	<javamemoryheapmax>3072m</javamemoryheapmax>
	...
</config>

Edit /var/crashplan/app/bin/run.conf.

vi /var/crashplan/app/bin/run.conf

Change the following line:-

SRV_JAVA_OPTS="... -Xmx3072m ..."
GUI_JAVA_OPTS="..."

Stop CrashPlan Docker container.

Docker -> Container -> CrashPlan -> Action -> Stop

Enable auto-restart on CrashPlan Docker container.

Docker -> Container -> CrashPlan -> Edit -> General Settings -> Enable auto-restart -> OK

Start CrashPlan Docker container.

Docker -> Container -> CrashPlan -> Action -> Start

Back to Mac

Download and install CrashPlan software.

Disable CrashPlan service since the UI acts as a client.

sudo launchctl unload -w /Library/LaunchDaemons/com.crashplan.engine.plist

Edit /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties.

sudo nano /Applications/CrashPlan.app/Contents/Resources/Java/conf/ui.properties

Uncomment serviceHost and update Synology NAS IP address.

#Fri Dec 09 09:50:22 CST 2005
serviceHost=1.2.3.4
#servicePort=4243
#pollerPeriod=1000  # 1 second
#connectRetryDelay=10000  # 10 seconds
#connectRetryAttempts=3
#showWelcome=true

#font.small=
#font.default=
#font.title=
#font.message.header=
#font.message.body=
#font.tab=

Edit /Library/Application Support/CrashPlan/.ui_info.

sudo nano "/Library/Application Support/CrashPlan/.ui_info"

Replace the authentication token with the value from above step. Replace IP address with Synology NAS IP address.

4243,########-####-####-####-############,1.2.3.4

Finally, run CrashPlan app to view the backup process.

Maven: Bundling and Unpacking Native Libraries

Introduction

Steps to bundle the native libraries to be pushed to Nexus, and to unpack the native libraries on mvn package.

Bundling Native Libraries into a JAR File

Let’s assume we have the following native libraries for multiple platforms:-

tree native

native
├── linux
│   ├── x86
│   │   └── libnative_synchronization.so
│   └── x86_64
│       └── libnative_synchronization.so
├── macosx
│   └── libnative_synchronization.jnilib
└── win32
    ├── x86
    │   └── native_synchronization.dll
    └── x86_64
        └── native_synchronization.dll

Create a jar that contains these native libraries. The -C options prevents the native folder from being created in the JAR file.

jar cMf my-project-native.jar -C native .

Pushing JAR to Nexus

When pushing this native JAR file to Nexus, make sure to use the natives-* classifier. In this example, I called it natives-all.

<dependency>
	<groupid>my.project</groupid>
	<artifactid>native</artifactid>
	<version>1.0</version>
	<classifier>natives-all</classifier>
</dependency>

Configuring pom.xml

First, add LWJGL and the native JAR dependencies.

<dependencies>
    <dependency>
        <groupid>org.lwjgl.lwjgl</groupid>
        <artifactid>lwjgl</artifactid>
        <version>2.9.3</version>
    </dependency>
    <dependency>
		<groupid>my.project</groupid>
		<artifactid>native</artifactid>
		<version>1.0</version>
		<classifier>natives-all</classifier>
    </dependency>
</dependencies>

Then, add the following plugin:-

<build>
    <plugins>
		<plugin>
		    <groupid>com.googlecode.mavennatives</groupid>
		    <artifactid>maven-nativedependencies-plugin</artifactid>
		    <version>0.0.7</version>
		    <executions>
		        <execution>
		            <id>unpacknatives</id>
		            <phase>generate-resources</phase>
		            <goals>
		                <goal>copy</goal>
		            </goals>
		        </execution>
		    </executions>
		</plugin>
    </plugins>
</build>

This plugin searches for dependencies with natives-* classifier and unpacks the content to target/natives folder.

Testing

Run mvn clean package.

Inspect target/natives. The native libraries should be unpacked here:-

target/natives
├── META-INF
│   └── MANIFEST.MF
├── OpenAL32.dll
├── OpenAL64.dll
├── jinput-dx8.dll
├── jinput-dx8_64.dll
├── jinput-raw.dll
├── jinput-raw_64.dll
├── jinput-wintab.dll
├── libjinput-linux.so
├── libjinput-linux64.so
├── libjinput-osx.jnilib
├── liblwjgl.dylib
├── liblwjgl.so
├── liblwjgl64.so
├── libopenal.so
├── libopenal64.so
├── linux
│   ├── x86
│   │   └── libnative_synchronization.so
│   └── x86_64
│       └── libnative_synchronization.so
├── lwjgl.dll
├── lwjgl64.dll
├── macosx
│   └── libnative_synchronization.jnilib
├── openal.dylib
└── win32
    ├── x86
    │   └── native_synchronization.dll
    └── x86_64
        └── native_synchronization.dll

Jenkins: Getting Karma Generated Test Results to Appear in Maven Project Job

PROBLEM

Jenkins, for some reason, does not pick up Karma generated JUnit test reports even though they are created in the right directory… and apparently, it is a known problem. While Freestyle project job allows us to manually publish these JUnit reports, my intention is to rely on Maven project job to do the same thing.

PREREQUISITES

ENSURING KARMA GENERATED JUNIT REPORT SHOWS UP IN JENKINS

Instead of manually running karma start command in Jenkins, we will rely on maven-karma-plugin to do this for us. The key here is to specify the correct <phase> so that Jenkins picks up and presents the generated report.

pom.xml

<build>
    <plugins>
        <plugin>
            <groupId>com.kelveden</groupId>
            <artifactId>maven-karma-plugin</artifactId>
            <version>1.6</version>
            <executions>
                <execution>
                    <phase>process-test-classes</phase>
                    <goals>
                        <goal>start</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <karmaExecutable>${basedir}/node_modules/karma/bin/karma</karmaExecutable>
                <configFile>src/test/resources/karma.jenkins.conf.js</configFile>
            </configuration>
        </plugin>
    </plugins>
</build>

CONFIGURING JENKINS

Since Karma test runner requires NodeJS, we will install NodeJS Plugin in Jenkins. This allows us to automatically install NodeJS from Jenkins.

Once installed, go to Manage Jenkins -> Configure System and go to NodeJS section:-

Although this section allows us to specify npm packages to install, I’m having trouble installing certain packages, such as karma-phantomjs-launcher. The phantomJS package invokes node install.js during the installation, however, the node command isn’t available in PATH environment variable at this point. Thus, the installation will always fail. So, the npm packages will be configured at the job level in the next step. Further, it is not a good idea to install Karma-related plugins globally here because every Jenkins job may use slightly different versions of the same plugin (think Spring or Hibernate versions in every job’s pom.xml).

Next, create a Maven project job and configure it.

Configuring Build Environment, Pre Steps and Build

We exposed NodeJS to PATH environment variable so that we can install phantomJS package.

Next, we created a pre-build step to execute npm install, which reads package.json from the job and installs the needed dependencies within the job.

Finally, we will want Maven to invoke test goal so that it runs both Java tests and Karma test runner.

Configuring Coverage Report

We provided the Karma generated coverage report XML file.

OUTCOME

When we run Build Now in Jenkins, both unit test and coverage reports will display both Java and JavaScript execution results.

Since we ran npm install as a pre-build step, the job will now have node_modules directory.