Dispatches from the realm of I.T.

☰ Menu

These instructions should work for just about any APC Network Management card (NMC), but the one I’m using is the AP9631.

Step #1: Navigate to the UPS configuration options

There are two ways to get into the UPS configuration:

Navigate to Services -> UPS in the sidebar, or …

Click on Services at the top of the page, then click the wrench icon next to UPS

It makes no difference which one you choose.

There are two ways to open the UPS configuration options. The end result is the same no matter which you choose.

Step #2: Configure the UPS

As stated earlier, I’m using an AP9631 so I’ll select the driver closest to that model. In this case, it is the APC ups 3 (various) AP9630 monitoring card (snmp-ups privProtocol=AES) driver:

Select the most appropriate driver

… And then continue with the configuration.

UPS configuration options

Identifier is how FreeNAS will refer to your UPS.

Port is the IP address of the network management card

Shutdown mode can be one of the following (you’ll have to decide which one of these is appropriate for your environment):

UPS reaches low battery

UPS goes on battery

Monitor User is the username of the user that exists on the NMC that will be used to issue shutdown commands. The AP9631 ships with a user called “device”, but you need to change the password for this user when you configure your NMC.

Monitor Password is the corresponding password for the NMC user.

Remote Monitor this option allows other servers to monitor the UPS via the NAS. You may or may not need this functionality.

Send Email Status Updates and To email these should be self explanatory.

Once you’ve saved your configuration, start the service:

Start the UPS service

Step #3: Verify the UPS service is communicating with the NMC

Open a terminal and ssh to your NAS and run the following command (where APCNMC is the Identifier you entered in your UPS configuration):

I have this problem occasionally, (read: multiple times, daily) where I’ll be RDP’d into a server and Remmina decides to lock up. When this happens, it simply won’t respond to anything other than a good old-fashioned kill -9. Assuming it didn’t take Xorg with it when it crashed, which also happens sometimes, I normally open a terminal and issue the standard kill -9, restart remmina, log back into any RDP sessions, and anxiously wait for it to happen again. The remmina icon in Unity has a Quit context option, but that never seems to work when this happens.

Remmina’s “Quit” context menu option

So in the interests of eliminating a step, and some keystrokes, I’ve added my own “quit” context menu option that runs the following command:

pgrep remmina | xargs kill -9

Here’s what it looks like, from the context menu:

My custom “Quit” context menu option

Adding this option was surprisingly easy. I saw more than a few examples of how to accomplish this, and they all started with Install ubuntu-tweak as the first step, which feels a bit heavy-handed to me. Here’s how I did it:

Find the remmina.desktop launcher file. Normally it is located here: /usr/share/applications/remmina.desktop

Open it in your favorite text editor, find the following line:

Actions=Profile;Tray;

… and modify it to look like this:

Actions=Profile;Tray;Kill;

Then scroll down to the bottom of the file and insert these lines. The Name line determines how the option is displayed in the context menu. Modify it to your liking; I like it when programs swear at me, so mine looks like this:

The bulk of this post has been pieced together from other bits of documentation on the web (see Additional Sources at the bottom of the post), but most of the available information applies specifically to CrashPlan “home” — not “pro”. Also, the included CrashPlan plugin in FreeNAS 9.10 is quite out of date so this guide will help you install and configure the most recent version of either the home or the pro version of CrashPlan. This how-to assumes that you’ve already installed FreeNAS.

Step #1: Install the included CrashPlan plugin

This will create the CrashPlan jail for you. Login to the admin interface of your FreeNAS box and navigate to Plugins:

Install the included CrashPlan plugin

Click OK to begin the installation

Wait for the install process to complete

Once the installation process has completed, verify that the plugin shows up under the Installed tab of the Plugins menu, but do not attempt to start the CrashPlan service just yet.

The CrashPlan plugin has been installed but is not yet running

Step #2: Configure a gateway IP address for the CrashPlan jail

Navigate to Jails -> crashplan_1 -> Edit

Edit the crashplan_1 jail configuration

Configure the jail’s network settings

You’ll notice that FreeNAS has already assigned an IP address to this jail. You can change it now to suit your needs, or leave it alone. Click on Advanced Mode so that we can configure a gateway.

Configure your gateway and/or any other desired network settings

Configure any other settings you need and then scroll down to the bottom of the dialog box and click Save.

Step #3: Enable SSH

We’re actually going to enable SSH on both the NAS and the crashplan_1 jail. Navigate to Services and click the wrench icon next to SSH

Navigate to “Services”

Click the wrench icon to configure SSH Settings

Check the option to Login as Root with password and click OK. Later on, we’ll change this to only allow public key authentication.

Allow root logins with password

Then start the SSH service:

Click the toggle switch to start the SSH service

If everything went well, you should be able to use secure shell to connect to your NAS.

Step #4: Enable SSH on the crashplan_1 jail

Connect to your NAS as root via ssh

Login to the NAS as root via ssh, then drop into the crashplan_1 jail via jexec

To drop into the crashplan_1 jail, you need to run jexec followed by the number of the desired jail from the output of the previous command:

jexec 1

After you’ve executed that last command, your shell should look something like that last screenshot. Now we can continue with configuring ssh on the jail:

vi /etc/ssh/sshd_config

We need to change the value of the PermitRootLogin setting to without-password and verify that the value of PasswordAuthentication is set to no. Additionally, we need to ensure that the values of AllowTcpForwarding and PubkeyAuthentication are yes. The only option that you should have to change is the first one; the latter three should have the correct setting by default, but check them just in case. Make sure they match the following:

Save and quit, but whatever you do, do not reboot or restart the ssh service — not yet. Next, you’ll need to create an authorized_keys file just like you did for the crashplan_1 jail:

cd
mkdir .ssh
vi .ssh/authorized_keys

Once again, paste your public key into this file and then save and quit and execute the following command:

chmod -R 600 .ssh

… And then either restart the ssh daemon:

service sshd restart

Or, reboot the NAS via the web interface or by executing the reboot command.

Reboot. This step isn’t strictly necessary, but you may receive the following error: “CrashPlan data did not validate, configure it first” when attempting to start the service (even after accepting the java EULA.) If this happens to you, reboot before proceeding.

Step #5: Install the FreeNAS CrashPlan Plugin

Login to the web interface and navigate to Plugins -> CrashPlan.

Navigate to “Plugins” -> “CrashPlan”

As soon as you click on the CrashPlan icon, an EULA for Java will appear. Scroll all the way down to the bottom and Click “Yes, I accept”:

Accept the EULA

And then click the X icon (cancel) on in the upper-right corner of the next window that appears.

Now we need to download the most recent version of CrashPlan (4.8.0 at the time of this writing.) There are two versions we’re concerned with: Home and Pro. I’m using the Pro version but the steps to install and configure either version are mostly the same. Download whichever version you require:

In the following steps, I will refer to the tarball as CrashPlan-<version>.tgz.

Make sure to download it to your local machine as it will need to be installed locally as well. Once it’s downloaded (assuming you saved the file in ~/Downloads) use scp to copy it to the crashplan_1 jail. In the following example, my pool is named tank, my crashplan jail index is 1, and the IP of my FreeNAS box (not the jail) is 10.0.2.218, so be sure to modify the following steps to suit your environment.

Execute the following commands from a terminal on your local machine; make sure you type the correct filename:

Step #6: Update Java

The latest version of CrashPlan requires a Java update. Since this CrashPlan will be running in a FreeNAS jail, you will need the 32-bit version of the JRE. Run the following commands (continuing from step #5):

Create a directory for the new version of Java. For example, if the tarball downloaded in the previous step was named: jre-linux-i586-1.8.0_72.tgz, then create a directory named: jre-linux-i586-1.8.0_72 and move the file into that directory.

Next, you’ll need to reconfigure CrashPlan to use this version of Java. Start by editing /usr/pbi/crashplan-amd64/share/crashplan/bin/CrashPlanEngine and inserting the following text, near the very top of the file:

## Point to new version of Java
## See also: "JAVACOMMON" in: /usr/pbi/crashplan-amd64/share/crashplan/install.vars
export LD_LIBRARY_PATH="/usr/pbi/crashplan-amd64/jre-linux-i586-1.8.0_72/jre/lib/i386/jli"

For example, here’s what mine looks like:

Next, we need to edit /usr/pbi/crashplan-amd64/share/crashplan/install.vars and change the path of the JAVACOMMON variable so that it points to our new version of Java:

Now before we start the service, there is an issue you should be aware of. The CrashPlan service may not connect to CrashPlan’s servers. If you tail the log, and then start the service you might see an error about Java not being able to resolve the FQDN of any of CrashPlan’s servers:

I have yet to find an adequate explanation as to why this happens, but here’s how you fix it (from this post in the FreeNAS forums). Basically, you need to add the IP addresses of CrashPlan’s servers to /etc/hosts. Run the following commands (copy paste the following block into your terminal) to do this in a single step:

Step #7: Install CrashPlan on your local machine

Accept all of the default settings when prompted. Since we don’t want the CrashPlan service running locally, we need to disable it on our local machine. This next step is not universal across all distros. For example, I’m using Ubuntu 15.10; to stop and disable (i.e., prevent from starting on boot) CrashPlan, I need to do the following:

As you can see from the method used to disable the CrashPlan service, the init script for CrashPlan on Ubuntu 15.10 is an upstart job. In 15.04 and later, both systemd and upstart are installed by default. Notice to future readers using Ubuntu: this will most likely change in the near future, given Ubuntu’s adoption of systemd as the default init system in 15.04.

Now we need to grab the auth token from the jail. The IP address of my jail is 10.0.2.2; yours will probably be different. Modify as necessary.

You need to modify the port and the auth token in your local /var/lib/crashplan/.ui_info. The port needs to be 4200, and the auth token needs to be replaced with the one from the previous command. You can simply overwrite the local .ui_info:

Any time the CrashPlan service is restarted on the NAS, this auth token could potentially change. There’s nothing you can really do about it except be aware that it happens. If the desktop app has trouble connecting to the backup engine, be sure to check this.

Step #8: Starting the CrashPlanDesktop app on your local machine

First, setup an ssh tunnel. You will need to use the IP address of the crashplan_1 jail in this command. Mine is 10.0.2.2; modify yours as necessary:

ssh -L 4200:localhost:4243 root@10.0.2.2 -Nv

Then, on your local machine, start the CrashPlanDesktop app either by clicking the icon on your desktop (if there is one) or by starting the app from the terminal:

Two ways to start the CrashPlanDesktop app

If everything went as planned, the desktop app should connect to the backup engine via the tunnel, and you should be able to configure your CrashPlan backup.

Step #9: Optionally, create a custom CrashPlan startup command

Remember how I said that the token in the .ui_info file changes occasionally? Do you manage multiple headless CrashPlan instances? The following might be incredibly convenient for you. Simply append the following to your .bashrc. Make sure the value of LOCALPORT is correct for your environment. Optionally, change DEFAULTHOST to the hostname or IP of a CrashPlan jail you connect to most frequently:

Scenario: You need a new staging VM to test out some Group Policy settings for a domain that resides on a different VLAN than the host that will store your staging VM. For example, let’s say that you wanted to run this VM using VirtualBox on your local machine. Your machine is on the I.T. Department VLAN (5), but the target domain resides on VLAN 3.

Your machine is running Ubuntu — any recent version (I used 15.10 for this post) will work for this example. The 10,000ft view of what needs to be done is as follows:

Ensure that the switchport that your workstation is connected to is a member of both VLANs. In my scenario, I have the following settings:

switchport trunk native vlan 5
switchport trunk allowed vlan 3

Install the vlan package on your machine

Configure a virtual interface with the appropriate VLAN info

Configure your VM to use that interface exclusively

This post assumes you already have the VM up and running — in this example we’re using VirtualBox but pretty much any virtualization software should work. Go ahead and install the vlan package:

I did run into some trouble during this configuration, mainly because there are some conflicting instructions on the net. You do not have to use vconfig to create the interface before adding it to /etc/network/interfaces … you can if you like, but it isn’t necessary. During this process, if you run into issues with interfaces not being brought up, you should take a look in /sys/class/net to see which interfaces have actually been created:

you@localhost:~$ ls /sys/class/net
enp9s0 lo vlan3 vlan99

To remove any of your virtual interfaces, simply run the following command (where ‘vlan99’ is the interface you wish to remove):

you@localhost:~$ sudo vconfig rem vlan99
Removed VLAN -:vlan99:-

Now that you have your VLAN interface configured on your local host, we need to tell your VM to use it. This is trivial — in VirtualBox, navigate to the network settings of the VM and make sure that:

“Bridged Adapter” is selected in the “Attached to:” dropdown box

Select the appropriate adapter in the “Name:” dropdown box

Note: the VM can either be running or not … it makes no difference):

Then check your network settings in the VM (assuming DHCP — if not you’ll have to reconfigure them manually):

If all goes well, you should now have a VM that will act behave like any of the workstations on the other VLAN with regards to networking.

Once you’ve downloaded the package, double click it to extract its contents — do not run the installer after the package has been extracted.

Assuming you’ve extracted the package contents to C:\Users\Administrator\Desktop\Adobe Acrobat, you’ll have a directory within that directory, titled Adobe Acrobat, in addition to some other files that we won’t concern ourselves with for the purposes of this post:

Now start the Acrobat Customization Wizard DC:

Navigate to File -> Open Package and select the AcroPro.msi file.

Configure your deployment options. For example, enter the package’s serial number in the Serial Number field, under the Personalization Options category. Please refer to Adobe’s documentation for details on all of the available configuration options and their uses. One particularly frustrating issue I ran into had to do with the installer looking for Visual C++ x64 2013 Runtime (VC); if this package wasn’t installed, the installation would fail and the only thing logged in event viewer would be a group policy failure. The total lack of useful error messages made this issue a pain to overcome, but after reading every single option and description (more or less) on this page I eventually figured it out. I needed to set an attribute in the Property table via the Direct Editor function in the Customization Wizard.I had to add this attribute manually (just right-click anywhere in the attributes pane), as it does not exist in the Property table by default. The attribute name needed to be IGNOREVCRT64 and it’s value needed to be 1.You can probably guess at what this does but for the official explanation, refer to Adobe’s Documentation on Property attributes and values. The short explanation is that I needed this installation to succeed regardless of whether the target machine already had the Visual C++ x64 2013 Runtime package installed. As of this writing, here is the explanation, for posterity:

Since Acrobat looks for Visual C++ x64 2013 Runtime (VC) by default, set IGNOREVCRT64 to 1 if it is not present AND not needed. IGNOREVCRT64 need only be used when all of the following are true:

Since Acrobat looks for Visual C++ x64 2013 Runtime (VC) by default, set to 1 if it is not present AND not needed. During non-setup.exe installs when VC is not present, installation behavior is as follows:

Command line installs abort if IGNOREVCRT64=1 is not passed.

UI installs display a dialog asking the user whether they would like to continue or cancel.

Setup.exe installs succeed. Installs never abort as the property is passed while spawning the MSI.

For MSI installs, use Require64BitVC10RT in the Setup.ini file under the Startup section.