For whatever reason, I sometimes have problems with Synology’s VPN package, specifically when using OpenVPN. There may be issues with the L2TP/IPSec or PPTP, but I don’t use them so I can’t specifically comment.

Anyway the nature of the problem is that no matter what settings I change — for example the dynamic IP address or Authentication methods — it doesn’t seem to change the configuration settings properly. It’s happened a handful of times where I change the IP range or when I need to give remote clients access to the local network, and it simply and inexplicably doesn’t work. Or to be more specific, the VPN may connect but will not bridge to the rest of the network. Bridging would be necessary to give remote users access to the local network because the VPN service by default uses a 10.8.0.1/24 network and most networks are in the 192.168.x.0/24 range.

When changes are made to the OpenVPN configuration through DSM, it is supposed to make changes to this file:

/var/packages/VPNCenter/etc/openvpn/openvpn.conf

I’ve found that I need to manually edit this file instead of letting the limited GUI do it for me, especially since the GUI lacks advanced functionality like if there are multiple subnets on a given network (though to be fair, if your network is large enough to have multiple subnets, you probably aren’t using a Synology as your VPN appliance).

It’s happened enough times that I’ve had to refer back to some technical notes I keep, so I hope this is useful to other people too.

#pushing a route is necessary to bridge dissimilar networks, so both the VPN
#network and the intranet network(s) need to be defined here.
#intranet network:
push "route 192.168.1.0 255.255.255.0"
#vpn network:
push "route 10.8.0.0 255.255.255.0"

#force clients to use remote gateway (force all traffic through VPN)
#optional, and can be configured/overridden in the client connection script
push "redirect-gateway def1"

#force Intranet DNS servers (so that remote clients can use intranet hostnames)
# this assumes you have an internal DNS server. If you don't, you can simply use
# the intranet default DNS settings (192.168.1.1 in this case, if the router does it)
push "dhcp-option DNS 192.168.1.10"
push "dhcp-option DNS 192.168.1.11"

dev tun

management 127.0.0.1 1195

server 10.8.0.0 255.255.255.0

dh /var/packages/VPNCenter/target/etc/openvpn/keys/dh3072.pem
ca /var/packages/VPNCenter/target/etc/openvpn/keys/ca.crt
cert /var/packages/VPNCenter/target/etc/openvpn/keys/server.crt
key /var/packages/VPNCenter/target/etc/openvpn/keys/server.key

max-clients 5

comp-lzo

#encryption method. I usually prefer strong AES encryption as it's yet to be defeated
cipher AES-256-CBC

persist-tun
persist-key

verb 3

#log-append /var/log/openvpn.log

keepalive 10 60
reneg-sec 0

plugin /var/packages/VPNCenter/target/lib/radiusplugin.so /var/packages/VPNCenter/target/etc/openvpn/radiusplugin.cnf
client-cert-not-required
username-as-common-name
duplicate-cn

status /tmp/ovpn_status_2_result 30
status-version 2
proto udp6
port 1194
auth SHA256

Now just to be clear, this is by no means the only way to set up the VPN, and perhaps not even the best way, but I’ve found it to be a great starting point to tweak as needed.

A few days back I phased out an old iSCSI backup repository, which I was using as a temporary measure while I worked on a more robust backup solution. It did the job alright but iSCSI gets a bit finicky with latency, so WBADMIN backups to an iSCSI volume can take a lot longer unless everything is ideal as in lab conditions. In general I don’t recommend it. At least not long-term.

Anyway so part of the phase-out process involved deleting the iSCSI target and LUN from the Synology NAS, which is easy enough to do. But today I noticed that the Storage Manager still claimed the LUN was still consuming the same amount of space it always did. I had expected it would take a while for the DSM software to reflect the new available storage, but it should have updated this long before now. Some recommendations out there was to simply reboot the unit, which I had already done more than once in the interim, which obviously had no effect.

A quick search on the Synology forum revealed a nice quick solution — though it’s still unclear why the space wasn’t automatically recovered to begin with, here’s the method to delete the LUN manually (thanks to Synology forum user mugz):

• Enable SSH service via the Terminal & SNMP tool in the Control Panel.
• Log into the Synology as user “admin” using the appropriate password.
• ‘sudo -s’ for root shell
• Confirm there are no iSCSI LUNs in Storage Manager.
• Stop the iSCSI service:
  /usr/syno/etc/rc.sysv/S78iscsitrg.sh stop
• Remove files in folder and in subfolder /volume1/@iSCSI/
  rm -rf /volume1/@iSCSI/*
• Start the iSCSI service again:
  /usr/syno/etc/rc.sysv/S78iscsitrg.sh start
• Log out of the Synology

mugz also mentions deleting /var/db/iscsi/EP_JNL, but I could find no record of this file, so I could not say for sure whether it is necessary under normal circumstances. Arguably the DSM should be able to recover the data without having to resort to such brute-force measures, but if computers always did what they were supposed to, I wouldn’t have a job.

I know it’s been a long time since I wrote anything on here. Frankly, I’ve been busy with work, and other personal projects. But it is worth noting that most of those projects were professionally oriented. Specifically, I’ve been teaching myself aspects of vSphere, Docker, and a host of other technologies. Late this summer I invested in a couple of nice Dell R710 servers which I’ve turned into a homelab wonderland.

With my new vSphere system, I now have a dedicated Docker box. I’ve been working with it for a couple of months now, running microservices like my Unifi controller, a CrashPlan container, even a couple of music managers like Headphones and Beets. I have an affinity for the team at linuxserver.io for their oft-updated and very well documented base images.

The problem is, I was playing around with it so much and making so many changes that I neglected to document the “docker run” commands correctly. I didn’t really document them at all. Every once in a while I’d like to perform a “docker pull” to retrieve the latest docker image and update my running containers, so the docker run commands along with the associated mapped ports and volumes would be extremely useful and time-saving.

I was looking for a way to reconstruct the original commands I used to build these containers. A number of possibilities presented themselves, but fortunately because I have a dedicated box (that is, not polluted with a lot of commands for unrelated services), I was able to recover exactly what the run commands were.

I simply made a copy of my bash history. It contained all of the exact commands are used to create the doctor containers from the very beginning. No guesswork, no time-consuming reconstruction of the commands. Just an exhaustive list of the last few hundred commands I’d performed with that user on that box.

I saw a bunch of online questions asking for basically the same thing, and instead of inferring the commands with “docker inspect” and parsing the results using Python, I thought I would offer an alternative.

Hopefully this proves useful to someone other than myself.

My docker host is running Ubuntu 16.04. I’m not sure if this is universal across all linux distros but it worked here:

history -w ~/history.txt


From there I just opened the text file and ran a search for all mentions of “docker run” and copied the last command string for each container.

When I set up my own Synology DS1815+, I created a large hard disk volume for most of my storage requirements. For the heck of it I had also created a RAID1 volume of a pair of 30 GB solid-state drives that I had lying around. I was curious to see whether installing applications to the solid-state drive would improve responsiveness or speed up the boot time. As it turns out, I’m not a demanding enough user to really notice a difference.

As my larger volume started filling up, the real estate taken up by those two small 30 GB solid-state drives became an obstacle. The problem was, I had already installed all of the applications to that volume. So I sought a way to move the applications without having to reinstall them, since I was afraid reinstalling AudioStation, PhotoStation or VideoStation might prompt a whole-volume index which I’m not eager to do – it takes ages.

As it turns out, this is relatively easy for most applications – even third-party ones. Apps like Snapshot Replication, CrashPlan and DownloadStation had to be uninstalled and reinstalled manually, but for the majority of apps this should work. Strictly speaking, DownloadStation didn’t need to be uninstalled manually but there were some remaining temp files in /volume3/@download that I didn’t want so I opted to just reinstall it manually.

I would not recommend this unless you know what you’re doing.

Moving an Application Between Volumes in DSM 5.x or DSM 6.x

Before doing the following, make sure all of the applications that are about to be moved have been stopped. You can do this by opening the Package Center, visiting each application entry under Installed and then clicking Action->Stop. I found it was easier to use my iPhone to login to the DSM console where there’s a handy “Stop” button for each application without having to tediously visit each entry.

You may also opt for the command-line method of stopping these services, since you’ll be digging around in there anyway.

sudo /var/packages/[app_name]/scripts/start-stop-status stop

So the process comes down to three basic commands. In the example below, it assumes that the current installation volume is volume1, and the desired one is volume3:

# Move the app files from the old volume to the desired one.
sudo mv /volume1/@appstore/[app_name] /volume3/@appstore/

# Delete the obsolete Symlink pointing at the old app path
sudo rm -fv /var/packages/[app_name]/target

# Create a new Sim link pointing at the new, correct app path.
sudo ln -s /volume3/@appstore/[app_name] /var/packages/[app_name]/target

Now you can either reboot or simply visit the Package Center and manually start the apps again. Each app entry should now show the correct new installation volume.