Configure Syncrify Client (x64) on Linux

I’ve already written up a how-to on the server portion of the Syncrify suite, so here’s the follow-up to that post regarding the client portion.

Before you get started, please note that these instructions assume that the user is ssh’d to the server. You will need X forwarding capability… if you ssh to the server using the following command, you’ll do just fine:

ssh -XC root@server

Step #1: Configure Java

Follow the instructions for Step #1: Configure Java, on the server how-to post.

Step #2: Download the Syncrify client for Linux

wget http://www.synametrics.com/files/Syncrify/SyncrifyClientJava.zip

Step #3: Unzip the archive and “install” the software package

unzip SyncrifyClientJava.zip
mkdir /opt/Syncrify
mkdir /var/log/syncrify
mv SyncrifyClient.jar /opt/Syncrify/
mv SyncrifyClient.sh /opt/Syncrify/

If your server does not have Xorg installed, you’ll need to install it:

apt-get install xorg

This will not make your server have a gui… you just need Xorg’s libraries in order to run the Syncrify client interface. I’m assuming you’re logged into the server via ssh, from a machine that has a gui (X server + desktop manager), and you’ve enabled X forwarding by using the -X command line argument. Any X session data will be forwarded through your ssh connection to your local X server. If your server has a gui (X server + desktop manager) then you can safely ignore this.

Step #4: Configure Syncrify scripts & crontab

Create a new file: /opt/Syncrify/Backup.sh and insert the following lines:

#!/bin/sh
java -jar /opt/Syncrify/SyncrifyClient.jar -console my_backup_profile.syncrify

Where my_backup_profile is the name of the profile you’ll create in step #5. Save and exit this file, then create a new file: /etc/cron.d/syncrify and insert the following lines:

#Run syncrify backup every Sunday, Tuesday, Thursday, and Saturday @ 2100hrs
00      21      *       *       0,2,4,6         root    /opt/Syncrify/Backup.sh >> /var/log/syncrify/syncrify.log

Save and exit.

Change permissions:

chmod 0755 /opt/Syncrify/Backup.sh
chmod 0755 /opt/Syncrify/SyncrifyClient.sh
chmod 0644 /etc/cron.d/syncrify
chown root.root /etc/cron.d/syncrify
chown -R root.root /opt/Syncrify

Step #5: Configure a backup profile

Start the Syncrify Client:

cd /opt/Syncrify
./SyncrifyClient.sh

Be patient… after a few seconds the client will appear (Note: this will not work if Xorg is not installed as per step #3):

Syncrify Client (main)

Configuring individual backup profiles is beyond the scope of this document… if you’ve made it this far then you should be more than capable of configuring a backup profile :-)

Notes:

  • Be aware that Syncrify stores settings in ~/.syncrify. It’s likely that you’ll never need to mess with anything in that directory, but you should at least know that it exists.
  • Make sure that when you create a new backup profile (File -> Add Profile…) that you give it the same name that was specified in the line #2 of /opt/Syncrify/Backup.sh. In the example contained within this post, the backup profile is named my_backup_profile and the settings for this profile are stored in ~/.syncrify/my_backup_profile.syncrify.

Saving autocomplete history in Outlook 2010 (and later)

Anyone who has had to transfer a user’s MS Outlook data from one computer or another has probably heard this question before:

“Where are all my addresses?”

Of course, you transferred the contacts so, confused, you ask the user what they’re talking about. The user then shows you that whenever they try to compose an e-mail, addresses do not “auto-fill” — hence “Where are all my addresses?”

Worse: in older versions of Outlook, there was no “Suggested Contacts” functionality so this sometimes lead to users completely disregarding the use of their address book, instead opting to depend solely upon autocomplete history.

Explaining to a user why this is bad practice will often get you nowhere. Luckily, most of the time you could just locate the *.nk2 file in their old profile and copy it to their new profile to restore their autocomplete history. This process has become slightly more complicated in Outlook 2010, but it’s still a simple thing to recover, provided you still have access to the original user profile.

  1. Locate the data file that contains the old autocomplete history. It will be in %userprofile%\AppData\Local\Microsoft\Outlook\RoamCache
  2. It will be named something like: Stream_Autocomplete_0_2CB1C400532AC94FAA6D3387E44FAE5B.dat … make a backup copy of this file and keep it in a safe place. If there are multiple similarly named files, backup all of them. Note that the largest file is likely the most important one.
  3. Locate the autocomplete file in the new userprofile; it will be in the same location but it will have a different name.
  4. Make a backup copy of the new one just in case it also contains autocomplete data that the user doesn’t want to lose and/or does not already have.
  5. Replace the new file with the old one from the old profile. Usually this just means that you overwrite the new file with the old one, ensuring that you change the name of the old file (the one containing all the data) to the filename of the new one. Make sure Outlook is not open when you do this. Alternatively, you can use NK2Edit to merge these files.
  6. Open Outlook and try to compose a new e-mail; your autocomplete history should be restored.

Configuring Syncrify Server (x64) on Linux

As far as diy offsite backup software goes, Syncrify is pretty neat. I do have one complaint though; the documentation covering the x64 version for Linux is lacking (read: damn near nonexistent). In addition, you have to write your own startup script. This post intends to clear this up a bit–mainly for my own sanity–and hopefully be of some help to others who might want to deploy a Syncrify server. This post assumes that you are using some flavor of Debian, in a 64 bit environment. These instructions have been tested on Ubuntu 12.04 (x64).

Step #1: Configure java

This is the simplest way I’ve found to get java configured for use with Syncrify. There are many ways to do this, feel free to deviate from this step.

apt-get install python-software-properties
add-apt-repository ppa:webupd8team/java
apt-get update
apt-get install oracle-jdk7-installer

You will have to accept the license agreement from line #4 in order to continue. After the installation, you can verify that everything ran correctly by doing the following:

update-alternatives --display java && javac -version

The output of this command should be:

java - auto mode
  link currently points to /usr/lib/jvm/java-7-oracle/jre/bin/java
/usr/lib/jvm/java-7-oracle/jre/bin/java - priority 1
  slave java.1.gz: /usr/lib/jvm/java-7-oracle/man/man1/java.1.gz
Current 'best' version is '/usr/lib/jvm/java-7-oracle/jre/bin/java'.
javac 1.7.0_17

Next, edit /etc/environment and add the following line:

JAVA_HOME="/usr/lib/jvm/java-7-oracle"

Step #2: Configure the upstart script

Copy and paste the following text into a file and save it as /etc/init/syncrify.conf:

# Syncrify - Upstart script for Syncrify

description "Syncrify backup manager"
author "Charles Hamilton <musashi@nefaria.com>"

start on runlevel [2345]
stop on runlevel [016]
respawn

script
        cd /opt/Syncrify
        CP=""
        for i in `ls /opt/Syncrify/lib/*.jar`; do
                CP=$CP:$i
        done
        /usr/bin/java -server -Xmx512m -cp $CP -DLoggingConfigFile=/opt/Syncrify/logconfig.xml com.synametrics.sradef.BootLoader
end script

Step #3: Download and “install” Syncrify

mkdir /opt/Syncrify
cd /opt/Syncrify
wget http://www2.synametrics.com/files/Syncrify/SyncrifyOther.tar.gz
tar -xf SyncrifyOther.tar.gz
chown -R root.root /opt/Syncrify
service syncrify start

At this point, you should be able to browse to http://127.0.0.1:5800. Alternatively, if you are running a server without a gui, you can do the following:

Edit /opt/Syncrify/config/AppConfig.xml and modify this line:

<parameter name="httpIP" type="1" value=""></parameter>

…to look like this:

<parameter name="httpIP" type="1" value="192.168.0.5"></parameter>

Where the IP address: “192.168.0.5″ belongs to the machine on which you’re configuring Syncrify. Save the file and kill Syncrify with a good old fashioned kill -9, then ./run.sh again to restart the service. Now you should be able to browse to http://192.168.0.5:5800. If, for some reason, nothing appears when browsing to that URL, make sure that Syncrify is running. If it isn’t, try starting it with the included “run” script:

/opt/Syncrify/run.sh

Try to browse to http://127.0.0.1:5800 (alternatively, http://192.168.0.5:5800) … if this works then something is probably wrong with the upstart script. Make sure you copied/pasted correctly, then make sure permissions are correct:

chown -R root.root /opt/Syncrify
chown root.root /etc/init/syncrify.conf && chmod 0644 /etc/init/syncrify.conf

Once you’ve managed to browse to the admin page (http://host:5800) you will be prompted to start configuring the server (these should be self explanatory):

1_0

2_0

3_0

4_1

Once you’ve gone through the prompts, login and enable SSL by navigating to the HTTP Configuration page and fill in the text box for “Secure HTTP Port” … it will be -1 by default; change it to whatever you want:

configure_https_1

configure_https_2

configure_https_3

Of course, this means you’re going to be using Syncrify’s bundled certificate with your server. I plan on updating this post sometime in the future with instructions on how to install a real SSL cert. Anyway, now all you have to do is configure your backup clients/user accounts and you’re done.

Problem with using ExpressMaint with Microsoft SQL Express 2012

If you are trying to use ExpressMaint with Microsoft SQL Express 2012, you will most likely run across the following error:

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.Smo, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.

This is easily repaired by installing the following items (as appropriate for your system architecture):

Microsoft® System CLR Types for SQL Server® 2008 R2

Microsoft® SQL Server® 2008 R2 Shared Management Objects

All of these items are part of the Microsoft® SQL Server® 2008 R2 Feature Pack

Sonicwall logs flooded with: destination for 255.255.255. 255 is not allowed by access control

I recently deployed a Sonicwall TZ200 (fw version: SonicOS Enhanced 5.6.0.11-61o) and after setting up SSLVPN access, the logs were being flooded with the following message:

1		03/20/2013 13:13:55.416	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
2		03/20/2013 13:13:51.672	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
3		03/20/2013 13:13:50.896	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
4		03/20/2013 13:13:50.176	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
5		03/20/2013 13:13:46.752	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
6		03/20/2013 13:13:46.016	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control				
7		03/20/2013 13:13:45.464	Info	SSLVPN	destination for 255.255.255.255 is not allowed by access control

I found a few discussion threads pertaining to this issue on the Sonicwall forums and I tried some of the solutions offered but none of them worked. If you have an account on the forums, you can see these discussions here:

https://forum.sonicwall.com/showthread.php?t=25636&highlight=destination+255.255.255.255

https://forum.sonicwall.com/showthread.php?t=24107&highlight=destination+255.255.255.255

https://forum.sonicwall.com/showthread.php?t=27473&highlight=destination+255.255.255.255

Through trial and error, I noticed that the messages stopped appearing in the logs (not immediately after, I might add) after disabling “Communication Between Clients” under SSL VPN -> Client Settings, and adding “WAN RemoteAccess Networks” to the Access List for the SSLVPN Services group (on the VPN Access tab) under Users -> Local Groups. The messages returned upon reversing these changes. I also noticed that whenever I enabled/disabled “Communication Between Clients”, the following error message was logged:

Adding L2TP IP pool Address object Failed.

I’m not sure if they’re related but they appeared to coincide. This doesn’t seem like the best remedy but at the time I wasn’t able to update the firmware on this device, so this was the next best thing. I’ll update this post once when I get a chance to update the firmware.