Synology DSM 4.2-3211 Released

Update tiles

Update tilesSynology released an update to DSM 4.2 back on April 18th which I got around to installing this weekend. Overall it is a pretty minor update but only took about 10 minutes oer NAS to install From the release notes:

  1. Fixed an issue where users could not connect to the DiskStation via FTP over SSL.
  2. Fixed an issue which kept the DiskStation from connecting to SNMP (Simple Network Management Protocol) UPS devices.
  3. Fixed an issue where domain users could not obtain an emergency code for 2-step verification.
  4. Improved the compatibility of file sharing via SMB/CIFS with Mac computers.
  5. Improved the stability of generating Disk Usage Reports.
  6. Improved the stability of iSCSI LUN.
  7. Improved the compatibility when backing up data between different versions of DSM.
  8. Improved stability when syncing files between two DiskStations with Shared Folder Sync.
  9. Improved the stability when backing up data to another DiskStation with Time Backup.
  10. Other issue fixes and enhancements.

Items 4, 6 and 8 could potentially help me in these areas although I never really had any problems so far. I had some Mac sharing problems but they want away and I figured it was a network or transient issue. I do sometimes get errors with shared folder sync but when I’ve bothered to track them down they all be files changed or deleted during the sync, The next sync has always worked just fine.

Audio Station, Cloud Station , Photo Station and Video Station packages also received minor updates. My CloudStation clients were automatically updated once the package on the Synology NAS was upgraded, which was nice.

Free Server Upgrade!

When I logged onto my Linode control panel today I noticed a “Free Upgrade Pending” notice. Much to my surprise I found that Linode has been doing a bunch of upgrades. This one was to double my RAM size, from 512 MB to 1 GB of RAM. Although it wasn’t exactly free, they got rid of that habit of ending prices in .95’s. So the monthly price got bumped a nickel to the even dollar amount.

The estimate was that my upgrade would take 19 minutes. Linode provides this estimate prior to the request to enter the upgrade queue so I can decide if I have the time. The reality was it took about 11 minutes from when I clicked upgrade to when it was back online. There wasn’t anyone in the queue ahead of me, if there was my server would have stayed up until it was my turn.

I’m also on hardware that now has 8 cores. Nice! If only I didn’t have to share them.

Screenshot of CPUs on host


I still haven’t gone in and modified my app settings to take advantage of the memory. I’ll have to think about how I want to use it since my server really doesn’t get stressed. I may be better off increasing my PHP cache so more PHP code can be cached in memory rather than simply increasing Apache or MYSQL capability. Back when I was first learning and tuning the Opcode cache I found that eventually the available memory would file up and it would start swapping stuff out so I cut back on what got cached. I may have enough memory now.

I’ve been busy recently, unable to tend to my sites, and I’ve been considering if I should look for a managed alternative for this site (or something like Squarespace) but I really like to have hands on. It just annoying when I don’t have time to go hands on. Plus, problems always occur at the most inopportune time And then something like this comes along and I get excited. Yea, I know. It’s just more RAM that this site doesn’t really need. But hey, I still get excited.

There’s been some pockets of site downtime recently. Don’t blame the server, it’s been me. I’ve been tinkering and some changes have required server reboots or full restarts of Apache. I’ve done it when traffic is low, but apologizes if you got caught in a reboot.

Linode has been writing about the upgrades on their blog (which I didn’t notice until today, bad me). If you want to try Linode I’ll get a small kickback if you sign up through this link or use the referral code: a6b0ae3bcb8e5d87840c56fac5965e763d4363d4 on the signup form. A bare server OS isn’t suitable for everyone, but I’ve been a happy customer since December 2009. If your already a Linode customer be sure to go in upgrade when you get a chance, it’s only a nickel.

Adding A Trusted SSL Certificate

SSL Lock Tile

Up until now I’ve only used SSL on my web server to encrypt my WordPress admin traffic. A self-signed certificate was fine for that since I wasn’t worried about confirming the identity of my server. But recently I’ve had a couple situations where I wanted integration that required a trusted certificate (one issued by a recognized certificate authority). I’ve been able to implement work arounds but they seemed to compromise security, if only by a little. So I decided to go out a get an “official” SSL certificate.

I’ve been considering it for awhile. I’d basically decided on DigiCert to provide the certificate long ago. They came to my attention, along with a lot of information about certificates in general, while listening to Steve Gibson’s Security Now! podcast. In 2011 he was shopping for a new certificates provider and talked about it over several episodes over a couple months. They aren’t a bargain basement shop, but they aren’t outrageous either.

What I Have Now – What I Want

I have a VPS server with Linode with one IP address and a self-signed certificate used by all sites on that IP address. I want to get to a configuration where one of those sites uses a trusted certificate and the others continue to use the self-signed certificate.

Implementation – Pulling the Parts Together

1. First step is to add an IP address to my server for the new certificate. There are certificate types that can secure multiple websites on one IP address, but I’m only buying the certificate for one site. So I need one IP address for the self-signed certificate and one for the trusted certificate. Linode requires a support ticket to justify the new IP address. There were some forum threads that said this was a difficult process. Maybe it’s because I only need 1 extra IP, but it was fast and simple. I just said I was adding a SSL certificate. I had the new IP address about an hour later (on a Sunday).

2. I followed these instructions to add my second IP address once it was assigned. The only difference from the instructions was I did list the gateway for the second IP address and I needed to reboot the server to recognize the new IP address. Cycling network services wasn’t enough and in fact displayed a message that it might not work.

3. Next I needed to get the SSL certificate. I removed domain privacy on the domain for which I was getting the certificate in order to streamline the proof of ownership. I did restore privacy once the certificate was issued. I followed DigiCert’s instructions on Apache. Those instructions include a tool to create the Certificate Signing Request (csr). When I used the tool it recognized I wasn’t their customer and offered a 30% discount along with an extra 60 days. So if your planning multiple purchases be sure to try the big one first, the offer hasn’t come up since I bought my certificate. The tool generated a command line I had to run on my server to create the csr. After running the command I copied the generated .csr file to my local computer, opened in in a plain text editor and pasted the contents into the DigiCert certificate order form. Since it was Sunday, and DigiCert says they don’t offer support on Sunday (except for emergencies), I didn’t expect a response. Instead I go one a short time later asking for supporting documentation to prove who I am and I sent that along. I had the certificate about 2 hours after submitting the order.

Implementation – Adding the SSL Certificate

1. At the time I generated the CSR (step 3 above) it also generated my private key which needs to be protected. I’ll keep the private keys in /etc/ssl/private which is the default location on my Debian 6 server. So I copy the file there and make sure it’s only accessible by root.

sudo mv /path/to/file/www_mydomainname_com.key /etc/ssl/private
sudo chown root:root /etc/ssl/private/www_mydomainname_com.key
sudo chmod 600 /etc/ssl/private/www_mydomainname_com.key

2. I’ll keep the actual certificates in /etc/ssl/certs which is also the default location on my Debian 6 server. Once I received the certificate from DigiCert I copied it to my home directory on the server then moved it to the /etc/ssl/certs directory and made it accessible only to the root user.

sudo mv /path/to/file/www_mydomainname_com.crt /etc/ssl/certs
sudo chown root:root /etc/ssl/certs/www_mydomainname_com.crt
sudo chmod 600 /etc/ssl/certs/www_mydomainname_com.crt

So now the certificate is in place. It’s time time set up networking. I now have two IP addresses on the server, I’ll call them and where is the original IP that everything is configured to use. I use named hosts and use as the host that all my sites run on. I’ll want the newly trusted SSL site on and for convenience I’ll move the regular website to But since DNS takes time to propagate I’ll want the regular site to listen on both IP addresses for awhile.  Servers differ so your server may differ but this is how I did it.

1. Change the /etc/apache2/ports.conf file with configurations to listen on both IPs individually and both simultaneously.

NameVirtualHost *:80
Listen 80

2. Then for SSL I configure the SSL hosts as follows.

NameVirtualHost *:443

The NameVirtualHost *:443 statement is so that multiple sites can share an IP address with my self-signed certificate.

Then it’s time to edit the host file for the domain.

1. I change the <VirtualHost> statement to <VirtualHost *:80> so it runs on both IP addresses.

2. I change the SSL host statement from <VirtualHost *:443> to <VirtualHost> so it runs only on the new IP address. I will not be able to administer the WordPress site until DNS propagates but this isn’t a big deal.

3. I then add the necessary statements to the host file in order to enable the certificate:

SSLCertificateFile /etc/ssl/certs/www_mydomainname_com.crt
SSLCertificateKeyFile /etc/ssl/private/www_mydomainname_com.key
SSLCertificateChainFile /etc/ssl/certs/DigiCertCA.crt

The first two lines are the certificate and key files that I added earlier. That last line is the DigiCert intermediate certificate that needs to be added to the certificate chain. DigiCert provided the certificate when mine was sent. If I had multiple certificates from DigiCert they would all use this same certificate as the intermediate certificate.

5. Now it’s time to reload apache. At this point it will run the regular site on both IP addresses. WordPress administration (which uses port 443 for SSL) will only listen on the new IP address so I won’t have access to the admin console.

sudo /etc/init.d/apache2 reload

6. I update DNS to point the domain to the new IP address. I wait a little while for the DNS to propagate. DigiCert has a tool that will check the certificate installation. I ran it and it confirmed a valid installation. I could access the regular site and the SSL site without a problem.

7. I wait another day to allow the DNS change to propagate and then I change the regular site to only run on the new IP address by editing the Apache configuration one more time. I change the /etc/apache2/ports.conf file to listen on both IPs individually but not simultaneously.

Listen 80

I remove the ability to list on both IP address for the regular websites. I don’t change the SSL port configuration.

8. Then I edit the site file for the domain so that it runs on the new IP address.  I change the <VirtualHost *:80> statement to <VirtualHost> in the site file for the domain.

9. I reloaded Apache one last time.

sudo /etc/init.d/apache2 reload

At this point my trusted certificate is running on my website. I know longer get the untrusted site or invalid certificate warnings.

One benefit over the free certificates offered by some is that all my browsers already recognize DigiCert as a valid certificate authority that issues these certificates. No need to load another certificate in my browser.

While not a cheap process, it was surprisingly fast and easy.

Dropping Feedburner on July 1st

Feedburner has been suffering from neglect for what seems like years.  I’ve decided that July 1, 2013 will be a good time to cut the Feedburner connection for my RSS feed. That’s when Google shutters Google Reader which will no doubt cause a decrease in subscribers and some chaos all by itself. I’m going with the native WordPress RSS feed, rather than be at the mercy of another service again.

I already updated the RSS subscription link on the top of this blog so you can update your subscription if you’re already a subscriber (Thanks!). Or just click this link which is the new RSS link. I haven’t picked a new email subscription service yet so that link is unchanged. Sorry for the annoyance of having to re-subscribe, but I figure a Feedburner death is inevitable and it adds no value to this website since it’s frequently broken.

Alternately you can follow me on Twitter, also linked at the top of this page.



WordPress and Other Security Concerns

Security ShieldThere’s been a lot of press recently about increased attacks on WordPress sites, and I run WordPress. At first I considered it BS since it seemed ike a standard brute force attack. Not that I didn’t think attacks were going on, a view of logs on my own small servers shows attacks all the time.  But Brian Krebs published an article about it and I figure he has a better BS detector than me in these matters. So maybe there has been an increase. I figure I’m pretty safe, I don’t use the default accounts and I do use long, complex unique random passwords.

Some reading I did also indicated that the volume of logon attempts could cause resource problems on the server, so I decided I would try to specifically block them. After a few other attempts I decided to go the plugin route and used the plugin Limit Login Attempts. It’s a nice simple plugin that does what its name says. I dislike adding plugins to WordPress but I made a exception in this case. Eventually I hope to figure out a way to block this at the server level. But this will give me some protection and any easy way to get stats on whether or not my site is actually being attacked this way.

I’ve always been good about keeping WordPress and my web server updated with the latest patches, but I decided to reboot it this past Friday to make sure all those updates were really in the running software. Maybe it’s because I come from the windows world where patch reboots are a monthly reboot, but I figured it would be a good thing after having the server online for 220 days. So apologies to anyone trying to access the site this past Friday during a certain 9 minutes (I decided to do a full backup with everything shutdown for good measure).

It’s only been a day, but so far the only lookout has been from my testing

Apple (and other) 2-Step Verification

Apple added 2-step verification to their iCloud and iTunes accounts. I have to admit I like it. I especially like that they turn off any sort of password recovery that could be socially engineered. If I lose all the registered devices and the emergency recovery key then I’m screwed. But I’ve always wanted the option to tell these high-value vendors to disable password resets based on those stupid “pet name” security questions. I usually answer them with garbage, but the fact they exist worries me. Not necessarily for every little account, but for any that protects something of value.

I’ve also been going through and adding two-step verification to my other accounts that support it. Some places have apps that generate a token, or use the Google Authenticator App, but codes sent via SMS seem to be the most common. I guess SMS can be spoofed, but I suspect that doing so would have to be highly targeted and take more effort than I’d be worth.

Synology NAS: UPS Sharing

I recently found myself down one UPS and needing to re-arrange my computer/NAS setup. Based on where I wanted to put my Windows Home Server and two Synology NAS’s I only had the convenience of two nearby outlets. For a third UPS I’d need some long cables which isn’t the best idea. A little digging and I found I could have one NAS tell the other when power went out and trigger a shutdown if it stayed down. It was surprisingly easy and didn’t require any network capable UPS.

Here’s what I have:

  • Synology 1511+ with one expansion bay running DSM 4.2 and with a static IP address
  • Synology 212+ NAS running DSM 4.2 and with a static IP address
  • CyberPower 1500 AVR with a USB cable for NAS to UPS communication and enough battery backup power outlets for both NAS’s and the ethernet switch they share.
  • The ethernet switch is located in the same place as the Synology boxes.

Setting It Up

  1. Hook up one NAS to the UPS normally. I picked the Synology 1511+ for this. Hook the communication cable to the UPS.
  2. Enable the UPS in Control Panel -> Hardware  then the UPS tab. Check Enable UPS Support then pick the shutdown delay you want. I prefer short  waits, just make sure the UPS will have enough juice for both NAS’s. Do NOT check “Shutdown UPS when system enters safe mode” unless you are absolutely sure your other NAS will be shut down before this NAS enters safe mode. I do not use this setting.
    Screenshot showing UPS settingsYou may want to save this and verify the UPS is working. But I’ll move on.
  3. Check “Enable network UPS server”
    Screenshot showing network UPS setting
  4. Click the permitted disk stations button and enter the IP address of the other NAS(es) that will share the UPS. It is strongly recommended that all these NAS’s have their power plugged into this same UPS and that they all use the same ethernet switch (or hub) and that it also be plugged into this UPS.
    Screenshot showing all network settings
  5. Click OK to save everything and move on to the remote UPS. In my case a Synology 212+.
  6. Make sure that the NAS is does not have a data cable connected to a UPS. Go to Control Panel -> Hardware and the UPS tab.
  7. Check enable UPS support.
    Select “Synology UPS Server” as the type
    Enter the IP address of the NAS UPS server (the one we set up above).
    Select the amount of time to wait before entering safe node.
    Screenshot showing remote UPS settingsClick OK to save everything.

As previously mentioned both NAS’s and the ethernet switch they share should be plugged into the same UPS. If the network connection goes down the remote UPS will not get the power loss notifications if the switch doesn’t have power.

This blog has been gathering cobwebs all year. It nice to get back into writing. Hope this was helpful.