A new NAS arrives – meet the Synology DS1515+

The trusty Netgear ReadyNAS 312 has served very well over the past couple of years, and is still doing ok. It has however started to run out of space, and even though the disks could be replaced by bigger ones, it was time to move to something larger.

As much as I have come to like the ReadyNAS products in general, and the support forums in particular, it would be interesting to try something else. The Synology products seems to have a loyal following, the UI seems nice, and said to have good build quality.

The new DS415+, DS1515+ and DS1518+ models came out recently each sporting a quad core Atom C2538 CPU, that was quite tempting… The 415+ has two Ethernet ports, while 1515+ and 1518+ both have FOUR 1 Gbit ports. Nice.
A quick check on the Synology forums indicate that they are very active and at least as extensive as the Netgear/ReadyNAS ones. That’s just at first glance though – time will tell if there is both volume and quality there.

Continue reading “A new NAS arrives – meet the Synology DS1515+”

ReadyNAS RN312 + 8GB RAM = FAIL

My RN312 has worked flawlessly since the upgrade from the standard 2 GB RAM to 4 GB ditto. I would however like to run some memory intensive applications on the NAS, so an upgrade to 8GB would be nice. Turns out this is not as easy – might not even be possible.

I have tried both a Kingston KVR1333D3S9/8G, and a DDR3 1600 from my iMac – no luck. Guess the RN312 just does not support 8GB – too bad.

By the way, the 4GB SODIMM that does work is a Hynix HMT351S6BFR8C.

Netgear RN312 firmware upgrade 6.0.8 to 6.1.2

RN312 6_1_2 available

Seems Netgear just released firmware version 6.1.2 for those products that support the new UI (I believe UltraNAS and other non-Intel based devices does not get the benefits of the new version 6 and above firmware – or maybe they have reconsidered – not sure).

Updating is always a bit scary when you have a smoothly running system, but after reading the release notes they mainly covered more high end devices (as compared to the RN312 that I have), so why not..

I believe the upgrade went well, all the applications I have installed myself (CrashPlan, Monitorix etc) seems to be work ok.

RN312 6_1_2 installed.png

 

 

 

Moving CrashPlan cache and log directories to new locations

As discussed in a previous post, the ReadyNAS might run out of disk space on the 4 GB root partition if you install software other than that provided by NetGear.

In my case it was CrashPlan’s cache and log files that were filling up the root partition, with warning emails every 10 minutes that 81% of the root partition was used, 82%… 83%…, so they needed a new home. Turns out it is not too hard:

ssh into the NAS, then su to become root. Stop CrashPlan (if it is running):

[code language=”bash”]
root@RN312:/home/admin# service crashplan stop
Stopping CrashPlan Engine … OK
root@RN312:/home/admin#
[/code]

Make a copy of CrashPlan’s configuration file, in case something goes wrong:

[code language=”bash”]
root@RN312:/home/admin# cp /usr/local/crashplan/conf/my.service.xml /usr/local/crashplan/conf/my.service.xml.orig
root@RN312:/home/admin#
[/code]

Take a look at CrashPlan’s cache directory:

[code language=”bash”]
root@RN312:/home/admin# ls -lah /usr/local/crashplan/cache/
total 40M
drwxr-sr-x 1 root staff  106 Sep 25 03:00 .
drwxr-sr-x 1 root staff  258 Sep 25 21:31 ..
drwxr-sr-x 1 root staff  170 Sep 25 21:31 42
-rw-r–r– 1 root staff 8.4K Sep 25 21:31 cpft1_42
-rw-r–r– 1 root staff 1.9K Sep 25 21:31 cpft1_42i
-rw-r–r– 1 root staff 2.1K Sep 25 21:31 cpft1_42x
-rw-r–r– 1 root staff  23M Sep 25 21:31 cpgft1
-rw-r–r– 1 root staff 8.8M Sep 25 21:31 cpgft1i
-rw-r–r– 1 root staff 7.9M Sep 25 21:31 cpgft1x
-rw-r–r– 1 root staff  986 Sep 25 03:02 cpss1
root@RN312:/home/admin#
[/code]

Create cache directory in new location:

[code language=”bash”]
root@RN312:/home/admin# mkdir /home/admin/from_root/crashplan/cache
[/code]

Change the config file to point to the new location (using your favourite editor, vim used here):

[code language=”bash”]
root@RN312:/home/admin# vim /usr/local/crashplan/conf/my.service.xml
[/code]

Change
<cachePath>/usr/local/crashplan/cache</cachePath>
to
<cachePath>/home/admin/from_root/crashplan/cache</cachePath>

(Adjust as needed if you have selected some other place for the CrashPlan files.)

Now move the cache files:

[code language=”bash”]
root@RN312:/home/admin# mv /usr/local/crashplan/cache/* /home/admin/from_root/crashplan/cache/
root@RN312:/home/admin#
[/code]

Time to move CrashPlan’s log files. They are originally stored in /usr/local/crashplan/log/, let’s move them to /home/admin/from_root/crashplan/log.

[code language=”bash”]
root@RN312:/home/admin# ls -lah /usr/local/crashplan/log/
total 111M
drwxrwxrwx 1 root staff  346 Sep 23 04:41 .
drwxr-sr-x 1 root staff  258 Sep 25 21:31 ..
-rw-r–r– 1 root root   33K Sep 25 21:31 app.log
-rw-r–r– 1 root root   23M Sep 25 21:31 backup_files.log.0
-rw-r–r– 1 root root   26M Jul 12 19:50 backup_files.log.1
-rw-rw-rw- 1 root root     0 Aug 15 15:21 engine_error.log
-rw-r–r– 1 root root  6.4K Sep 25 21:31 engine_output.log
-rw-r–r– 1 root root  180K Sep 25 21:31 history.log.0
-rw-r–r– 1 root root  501K Sep 17 13:47 history.log.1
-rw-r–r– 1 root root  501K Aug 25 08:10 history.log.2
-rw-rw-rw- 1 root root     0 Aug 15 15:24 restore_files.log.0
-rw-r–r– 1 root root   13M Sep 25 21:31 service.log.0
-rw-r–r– 1 root root   26M Sep 23 04:41 service.log.1
-rw-r–r– 1 root root   26M Sep 17 14:35 service.log.2
root@RN312:/home/admin#
root@RN312:/home/admin# mkdir /home/admin/from_root/crashplan/log
root@RN312:/home/admin#
[/code]

Find the fileHandler tags (there are 4 of them dealing with log files), modify them so they point to the new log directory. So, once again edit /usr/local/crashplan/conf/my.service.xml.orig, part of mine looks like this after moving the log files. Change the paths as neeed for your choice of new directories:

[code language=”bash”]
<serviceLog>
    <fileHandler append="true" count="2" level="ALL" limit="26214400" pattern="/home/admin/from_root/crashplan/log/service.log"/>
  </serviceLog>
  <serviceErrorInterval>3600000</serviceErrorInterval>
  <historyLog>
    <fileHandler append="true" count="10" level="ALL" limit="512000" pattern="/home/admin/from_root/crashplan/log/history.log"/>
  </historyLog>
[/code]

Start CrashPlan again:

[code language=”bash”]
root@RN312:/home/admin# service crashplan start
Stopping CrashPlan Engine … OK
root@RN312:/home/admin#
[/code]

And finally check free disk space on /:

[code language=”bash”]
root@RN312:/usr/local/crashplan/log# df -h
Filesystem      Size  Used Avail Use% Mounted on
rootfs          4.0G  1.7G  1.8G  49% /
tmpfs            10M  4.0K   10M   1% /dev
/dev/md0        4.0G  1.7G  1.8G  49% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           2.0G  5.8M  2.0G   1% /run
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
tmpfs           2.0G     0  2.0G   0% /media
/dev/md127      2.8T  1.1T  1.7T  39% /data
/dev/md127      2.8T  1.1T  1.7T  39% /home
/dev/md127      2.8T  1.1T  1.7T  39% /apps
root@RN312:/usr/local/crashplan/log#
[/code]

49% – nice!

Add more RAM memory to ReadyNAS RN312

4GB RAM in Netgear ReadyNAS RN312
4GB RAM in Netgear ReadyNAS RN312

The 2GB of RAM that is standard in the RN300 series of NAS from NetGear might seem like a lot to begin with, but if you install additional applications such as media servers or backup software (see this post for instructions how to install CrashPlan), memory might become a scarce resource. For example, CrashPlan needs about 1 GB of RAM if you have lots of files to backup (> 1 TB I believe).

As I had a 4 GB DDR3-10600 SODIMM laying around, I figured I would try it. Maybe it would work… and it did! Turned out to be a 1 minute operation. Just turn off the NAS, pop off the left sida panel (seen from the front), exchange the 2 GB module for a 4 GB one, put the panel back, and start the NAS.

After logging in again we can see if the system picked up the new memory:

[code language=”bash”]

cat /proc/meminfo

[/code]

Success! Looks like we have 4 GB RAM in the system now – nice!

[code language=”text”]

MemTotal: 4037724 kB
MemFree: 191668 kB
Buffers: 1192 kB
Cached: 2580404 kB
SwapCached: 0 kB
Active: 1423904 kB
Inactive: 2135604 kB
Active(anon): 718048 kB
Inactive(anon): 263768 kB
Active(file): 705856 kB
Inactive(file): 1871836 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 523964 kB
SwapFree: 523964 kB
Dirty: 1328 kB
Writeback: 0 kB
AnonPages: 977988 kB
Mapped: 39848 kB
Shmem: 3904 kB
Slab: 258404 kB
SReclaimable: 242484 kB
SUnreclaim: 15920 kB
KernelStack: 2472 kB
PageTables: 10800 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 2542824 kB
Committed_AS: 1449504 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 2664 kB
VmallocChunk: 34359730596 kB
DirectMap4k: 3008 kB
DirectMap2M: 4182016 kB

[/code]

I will dig around a bit to see if some other settings need to be updated, but so far so good – everything seems to be working just fine.

Monitorix on ReadyNAS, part 2

The default Monitorix installation (see previous post) puts the log and database files in /var/lib/monitorix/, which is part of the root partition. This partition is only 4 GB in size, and when it is 80% full the NAS sends an email to the admin email address:

System volume ‘root’ usage is 81 %. This condition should not occur in normal conditions. Please contact technical support.

Ouch… Well, it is easy enough to move the log and rrd files to a better location. As this problem is likely to occur for most software installed on the NAS, I decided to make a directory /home/admin/from_root, where things that originally lived on the root partition can be moved.

First su to become root, then stop the monitorix service:

[code language=”bash”]

service monitorix stop

[/code]

Edit /etc/monitorix.conf using your favourite editor (vim, nano, emacs…). The beginning of mine (where the paths are defined) now looks like this:

[code language=”text”]

# Monitorix – configuration file
#
# See monitorix.conf(5) manpage for a detailed description of each option.
#

title = Place a title here
hostname = RN312
theme_color = black
refresh_rate = 150
iface_mode = graph
enable_zoom = y
netstats_in_bps = n
disable_javascript_void = n
temperature_scale = c

base_dir = /usr/share/monitorix/
#base_lib = /var/lib/monitorix/
base_lib = /home/admin/from_root/monitorix
base_url = /monitorix
base_cgi = /monitorix-cgi

<httpd_builtin>
enabled = n
host =
port = 8080
user = nobody
group = nogroup
log_file = /home/admin/from_root/monitorix/log/monitorix-httpd
hosts_deny =
hosts_allow =
<auth>
enabled = n
msg = Monitorix: Restricted access
htpasswd = /var/lib/monitorix/htpasswd
</auth>
</httpd_builtin>
# Log files pathnames
# —————————————————————————–
log_file = /home/admin/from_root/monitorix/monitorix
secure_log = /var/log/secure
mail_log = /var/log/maillog
milter_gl = /var/milter-greylist/greylist.db
imap_log = /var/log/imap
hylafax_log = /var/spool/hylafax/etc/xferfaxlog
cups_log = /var/log/cups/page_log
ftp_log = /var/log/proftpd/access.log
fail2ban_log = /var/log/fail2ban.log
spamassassin_log = /var/log/maillog
clamav_log = /var/log/clamav/clamav.log
cg_logdir = /var/CommuniGate/SystemLogs/
squid_log = /var/log/squid/access.log

<span style="line-height: 1.714285714; font-size: 1rem;">[/code]

Now that this is done, move the existing files to the new location:

[code language=”bash”]

mkdir /home/admin/from_root/

mkdir /home/admin/from_root/monitorix

cp /var/lib/monitorix/* /home/admin/from_root/monitorix

[/code]

Almost there. Before starting the service again it is useful to monitor the application’s log file. Make sure you have two shells running side by side. In one of them start a tail of the log file:

[code language=”bash”]

tail -f monitorix -n 50

[/code]

Now start the service again, using the second shell. You can now monitor the startup log entries, and if all goes well there will be no (serious) errors.

[code language=”bash”]

service monitorix start

[/code]

Enhanced monitoring of Netgear ReadyNAS RN312 using Monitorix

Edit: Some additional configuration turned out to be necessary to achieve stable operation, see this post.

The built-in monitoring of the RN312 is ok for basic purposes, but still pretty limited.

I am really heading towards a Zabbix setup (I think at least, having tested it in a VM environment it seems pretty nice), but there is A LOT of configuration needed to get Zabbix up and running. That’s actually a downside of Zabbix: In order to get simple things like alarm/notification emails set up, you need to do a lot of configuration in the web UI. Yes, it is very flexible, but also quite demanding.

So what options are there to get started more quickly? Wikipedia lists a whole bunch of NMS systems. Having following (and read good things about) Monitorix for some time, it was worth a try.

Setup was pretty painless, but some extra work was needed (as compared to the installation instructions). Good instructions for Debian can be found here though. Worth noting that I decided to install packages from a repository, rather than as a downloaded package, or from source.

  1. Add the needed sources. Good instructions here. I stored the repo key in /root, there is probably a better place for it… Btw you need to do the following as root, so run “su” to change user.

    Use your editor of choice to edit /etc/apt/sources.list so it looks something like this (the last two lines are what we are after here):
    [code language=”text”]
    deb http://apt.readynas.com/packages/readynasos 6.0.8 updates apps main
    deb http://mirrors.kernel.org/debian wheezy main

    # Monitorix packages
    deb http://apt.izzysoft.de/ubuntu generic universe
    [/code]

  2. Get the key for the repository. This is needed in order to install the package from the repo.
    [code language=”bash”]
    cd
    wget http://apt.izzysoft.de/izzysoft.asc
    apt-key add izzysoft.asc
    [/code]
  3. Install…
    [code language=”bash”]
    apt-get update
    apt-get install monitorix
    [/code]
  4. In spite of what the Monitorix install instruction says about the system running out of the box, I had to do some additional changes:As Monitorix will run on the RN312, but you will access it from some other computer, you need to tell Apache2 that this is ok. Edit /etc/apache2/conf.d/monitorix.conf so that it looks like this (only the Directory section show to keep it short):[code language=”text”]
    <Directory /usr/share/monitorix/cgi/>
    DirectoryIndex monitorix.cgi
    Options ExecCGI
    Order Deny,Allow
    Deny from all
    Allow from all
    </Directory>
    [/code]

    Yes…. You should probably not allow anyone to access via insecure http… Better option might be to use specific IP numbers, instead of all. I.e. “Allow from w.x.y.z” instead of “Allow from all”.

    Edit /etc/monitorix.conf. By default Monitorix’ own http server is enabled, but it will clash with the Apache2 server that is already running on the RN312. We need to disable Monitorix’ http server, and while we are at it, you might also want to change the hostname, as well as decide which graphs to show.
    The first part of my /etc/monitorix.conf looks like this

    [code language=”text”]
    # Monitorix – configuration file
    #
    # See monitorix.conf(5) manpage for a detailed description of each option.
    #

    title = Place a title here
    hostname = RN312
    theme_color = black
    refresh_rate = 150
    iface_mode = graph
    enable_zoom = y
    netstats_in_bps = n
    disable_javascript_void = n
    temperature_scale = c

    base_dir = /usr/share/monitorix/
    base_lib = /var/lib/monitorix/
    base_url = /monitorix
    base_cgi = /monitorix-cgi

    <httpd_builtin>
    enabled = n
    host =
    port = 8080
    user = nobody
    group = nogroup
    log_file = /var/log/monitorix-httpd
    hosts_deny =
    hosts_allow =
    <auth>
    enabled = n
    msg = Monitorix: Restricted access
    htpasswd = /var/lib/monitorix/htpasswd
    </auth>
    </httpd_builtin>
    # Log files pathnames
    # —————————————————————————–
    log_file = /var/log/monitorix
    secure_log = /var/log/secure
    mail_log = /var/log/maillog
    milter_gl = /var/milter-greylist/greylist.db
    imap_log = /var/log/imap
    hylafax_log = /var/spool/hylafax/etc/xferfaxlog
    cups_log = /var/log/cups/page_log
    ftp_log = /var/log/proftpd/access.log
    fail2ban_log = /var/log/fail2ban.log
    spamassassin_log = /var/log/maillog
    clamav_log = /var/log/clamav/clamav.log
    cg_logdir = /var/CommuniGate/SystemLogs/
    squid_log = /var/log/squid/access.log

    imap_log_date_format = %b %d
    secure_log_date_format = %b %e

    # Graphs (de)activation
    # —————————————————————————–
    <graph_enable>
    system = y
    kern = y
    proc = y
    hptemp = n
    lmsens = y
    nvidia = n
    disk = n
    fs = y
    net = y
    serv = y
    mail = y
    port = y
    user = y
    ftp = y
    apache = y
    nginx = n
    lighttpd = n
    mysql = y
    squid = n
    nfss = y
    nfsc = y
    bind = y
    ntp = y
    fail2ban = y
    icecast = n
    raspberrypi = n
    int = y
    </graph_enable>
    [/code]

    Finally, for some reason the rights to Monitorix’ imgs directory were incorrect out-of-the-box. Fix it:

    [code language=”bash”]
    cd /usr/share/monitorix/
    ls -la
    chown -R admin:admin imgs
    ls -la
    [/code]

  5. Almost there… We just need to restart Apache2 and Monitorix to make the new configuration take effect:
    [code language=”bash”]
    service apache2 reload
    service monitorix restart
    [/code]

     

Directing your browser to http://<IP of your NAS>/monitorix should now give you a screen like this:

Place_a_title_here

Clicking ok should now take you to a page looking similar to this one (exactly what is shown will depend on the settings you did in /etc/monitorix.conf):

Place_a_title_here 2

All in all – very nice! 🙂