Tip: mark your wireless mouse and USB dongle

We have several identical wireless rodents (Logitech M525, they are nice). This means we also have several identical USB receivers.

To prevent mixups, I’ve color-coded the USB receivers as well as the CE-markings on the mice, using different permanent markers:

Synology network bonding with LACP

These are my notes for configuring my HomeLab NAS for LACP (“Link Aggregation“, “network bonding” etc.) to increase bandwidth.

My home lab consists of a couple of Intel NUCs running the free edition of VMware vSphere 6U2, each with 16GB RAM and 256GB SSD. For additional storage, I use a Synology DS1815+ NAS.

As the NUCs have only one 1Gbps network interface, I configured them as a ‘trunk’, carrying all VLANs. The Synology NAS has multiple network interfaces; I started out with a single connection.

To improve NAS bandwidth (and for my own amusement), I decided to upgrade the single 1Gbps connection to 2x 1Gbps using the “LACP” (Link Aggregation) protocol. I use NetGear smart switches with VLAN and LACP support, so this should be easy…

HomeLab setup

  • Step 1: enable bonding on the Synology; log on to the web admin panel and go to Control Panel, Network, Network Interface, Create -> Create Bond. Choose LACP, select the interfaces to bond (I use a static IP address).
  • Step 2: log into the NetGear switch, create a Link Aggregation Group (LAG) consisting of both ports. I used LAG1, with ports 7 and 8.
  • Step 3: connect both network cables, check if everything works.

At this point, I ran into trouble. I couldn’t reach the NAS anymore. Turns out I made a couple of mistakes in my NetGear configuration. The fix was:

  • Specify Jumbo Frames (9216) on the LAG;
    not (just) on the physical interfaces.
  • Specify VLAN settings on the LAG;
    check the VLAN membership as well as the PVID settings.

The NetGear interface doesn’t show LAG settings by default – you need to explicitly select “LAG” or “All” settings. I overlooked this at first:


Incorrect VLAN settings caused the NAS to drop off the network; LAG traffic wasn’t tagged even though both physical interfaces were properly configured. It took me a while to realize and fix.

So, here’s a couple of screenshots:

Step 1: Synology – Create bond, set IP and Jumbo Frames on the bond

Synology bond settings


Step 2: Netgear – Create LAG, set VLAN and Jumbo Frames on the LAG

Create LAG, select members:


Configure VLAN membership and PVID for the LAG as well:



Step 3: Connect and enjoy 2Gbps network bandwidth

I tried copying a couple of large files from the NAS to two different vSphere hosts – bandwidth clearly exceeds 1Gbps now.


Synology DSM 6 – rebalancing BTRFS

I recently upgraded my Synology from 4x 3TiB to 4x 6TiB disks (WD Red).

I could have simply installed the new disks and created a BTRFS volume (which would have become /volume2) but I decided to take a different route:

  1. Install 2x 6TiB disks and format as RAID-0 (mounted on /volume2).
  2. Copy all relevant data from the old disks to the new disks, and verify.
    If anything were to go wrong, I still had my data on the old disks.
  3. Remove the old /volume1 4x 3TiB disks for safekeeping, insert 2x 6TiB disks and create a new /volume1 using BTRFS.
  4. Copy all data from /volume2 (RAID-0) to /volume1 (BTRFS), and verify.
  5. Destroy /volume2 and add the remaining disks to /volume1.

Now, all my data is effectively stored on the first 2 disks in the new volume. BTRFS can rebalance the data chunks across all spindles. Open an SSH connection to the Synology NAS, and issue the following command:

command: btrfs balance start /volume1

This operation took several hours to complete – it had to rebalance about 6 terabytes of data… I opened a second SSH session to monitor progress:

btrfs balance status -v /volume1

SELinux fix: allowing write to /var/lib/mod_security/

There’s a long-standing bug that prevents mod_security from writing to /var/lib/mod_security/.

According to Red Hat Bugzilla this bug should been fixed around May 2013, but it still exists – on fully patched CentOS 6.5. From /var/log/audit/audit.log:

type=AVC msg=audit(1411718594.811:7017): avc: denied { write } for pid=28144 comm="httpd" name="global.dir" \
dev=dm-0 ino=1577960 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file

type=AVC msg=audit(1411718594.812:7018): avc: denied { write } for pid=28144 comm="httpd" name="ip.dir" \
dev=dm-0 ino=1577962 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file

To relabel this directory with the proper “httpd_var_lib_t” context, run the following as root:

semanage fcontext -a -t httpd_var_lib_t "/var/lib/mod_security(/.*)?"
restorecon -Rv /var/lib/mod_security

Running the Archiveteam Warrior on ESXi

The Archiveteam Warrior is available for download as an OVA virtual appliance for use with VirtualBox, VMware Workstation/Player etc.

To use this virtual appliance on VMware ESXi 5.1, you need to make some changes related to unsupported virtual hardware.

The instructions below are for Windows – the VMware vSphere Client doesn’t run on my Mac or Linux boxes, so I keep a Windows VM around just to run the vSphere client.

Download the .OVA file and extract its contents

An OVA file is a TAR file. You can use 7-Zip to unpack the OVA file (to your Desktop). After unpacking, you should see 3 new files:


Modify the .OVF file to make it compatible with ESXi

Open the .OVF file in a text editor (use Notepad or Notepad++). It is an XML formatted file, describing the virtual appliance.

First, change the Virtual Machine type (line 38):




Next, locate the virtual SATA storage controller (starting at line 75):

 <rasd:Description>SATA Controller</rasd:Description>

This virtual SATA controller is not supported by ESXi 5.1, so replace the item with the following:

 <rasd:Description>SCSI Controller</rasd:Description>

Save the OVF file.

Import the Virtual Appliance

  1. Start the vSphere Client and select File > Deploy OVF Template.
  2. Browse to the .OVF file (on your Desktop) and click Next.
  3. Now, vSphere Client will display a warning that the “Debian” OS is unknown, and was remapped to “Other (32-bit)”. You can ignore this warning. Deployment should complete successfully.

Power on the Virtual Machine and follow the instructions on the Console window – happy Archiving!