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! 🙂

Installing Debian from USB thumb drive

For some years now I have tried to improve my Linux skills. I just don’t have the time to do Linux deep dives at work, so I figured I would set up a physical Linux box here, in addition to the VMs I use from time to time.

Anyway, without further thought about the pros and cons of VMs vs physical machines, creating the installation USB thumb drive turned out to be a bit of a challenge, until UNetbootin and LiLi came along. The former supports Windows, Linux and OS X (I am on OS X), while LiLi is Windows only.

LiLi looks good, but given my OS X preference I went with UNetbootin. After creating a Debian Wheezy installation thumb drive, I tried booting it in a Dell laptop. No luck, it booted straight into the Windows 8 that was on the hard drive.

When repeating the procedure on the Dell laptop (running Win 8) it worked like a charm, the Debian installer started after the USB drive had been created, and the laptop rebooted. I recall reading somewhere that there are issues with UNetbootin on OS X, I guess that’s still the case..

So, now onto the actual installation – nice!

Allowing ssh access to ReadyNAS RN312

After creating a few new users on the RN312, using the web interface provided with the device, I noted that none of the users could ssh into the NAS.

Turns out the new users are created without a default shell, resulting in a successful ssh login, followed by a terminated connection. No good.

For example, a user named charlie would have something like the following entry in the /etc/passwd file. Note the final bold characters:

charlie:x:100:102:charlie@yourdomain.com:/home/charlie:/bin/false

Change this to

charlie:x:100:102:charlie@yourdomain.com:/home/charlie:/bin/bash

 

Charlie should now be able to ssh into the NAS. By the way, you HAVE set up ssh keys for your users, right… Way more secure than plan text passwords, and a lot more convenient…

 

 

 

TI LaunchPad Stellaris and Anaren CC2530 Zigbee BoosterPack kit

I recently got the chance to evaluate the Anaren AIR CC2530 BoosterPack Kit, which is a ZigBee eval platform for TI’s LaunchPad products, i.e MSP430 and Stellaris.
Kudos to the good folks at element14 for providing the kit as part of their RoadTest program.

The review is found at element14’s site, but also here for completeness. I will also post further developments using the kit here on the blog, as described in the review I have some ideas around a cat-detector… So many projects, so little time.

The review follows below.
Continue reading “TI LaunchPad Stellaris and Anaren CC2530 Zigbee BoosterPack kit”

Netgear RN312 firmware upgrade 6.0.6 to 6.0.8

Firmware 6.0.8 just became available for the x86 based Netgear NASes. Interestingly enough, it is called “firmware” version, but to me (and others familiar with electronics and embedded systems) a firmware is low-level software running directly on the CPU/MCU. Maybe there are such components in the Netgear firmware too, but most part seems to be just updates to the NAS’ Linux environment (or more specifically: to the Debian Wheezy packages).

Anyway, that’s mainly semantics. My worry was that the upgrade would overwrite the 3rd party software I had previously installed (htop, tmux and CrashPlan).

Turns out there was no need to worry. All three works flawlessly also after the “firmware” upgrade. Nice.

Onwards!

tmux on Netgear RN312 NAS

If you spend any time at all at the Linux command line, you need tmux. Period. It makes you orders of magnitude more effective, there’s just no excuse for not using it.

Given that the RN312 NAS is x86 based and using Debian Wheezy, there’s an already compiled package for it. Installing it is trivial. Just ssh into the NAS, then issue:

apt-get intall tmux

That’s it. Copy in your favorite ~/.tmux.conf file, and you are set.

 

htop on the Netgear RN312

Just a quick post on how easy it is to set up the invaluable htop package on the Netgear RN312.  For those not familiar with htop, it’s a super-powered process monitor, way way better than the old legacy top command. Nice stuff, must have.

Turns out the pre-built package for htop is borked though (apt-get install htop fails) . Bummer.  Time to pull out the command line magic..

ssh into the NAS, then set up a build environment and a couple of dependencies. Compile and install (set the debconf to dialog and medium level):

dpkg-reconfigure debconf

apt-get install build-essential

<wait for looooong time>

cd /root/dl

wget http://downloads.sourceforge.net/project/htop/htop/1.0.2/htop-1.0.2.tar.gz

tar -xvzf htop-1.0.2.tar.gz

./configure; make; make install

Fail:

checking for refresh in -lncursesw… no

configure: error: You may want to use –disable-unicode or install libncursesw.

Ok, so let’s fix that, we need dev libs:

apt-get install libncursesw5-dev

./configure; make; make install

Fail 2, we need another set of ncurses dev libs:

apt-get  install libncurses5-dev

./configure; make; make install

… and that does it. Enjoy htop on your x86 based Netgear ReadyNAS!

CrashPlan on Netgear ReadyNAS RN312 – hello!

Edit: Installing according to the instructions below works, but it does place CrashPlan’s log and cache files on the very size constrained root partition of the ReadyNas. Especially the cache files will quickly fill that partition of you have lots of files.
It is however easy to move those cache and log files to a better location, so once done with the instructions below, check out this post for details on how to move cache and log.

 

I’ve been using CrashPlan for a couple of years now, it’s a great service. In particular I like the peer-to-peer backup feature, where I can configure my parents’ (or friends) computer to back up to my small headless server during the night, making sure they don’t loose their pictures due to some unfortunate keyboard sequence.. The paid-for service is very reasonably priced too, giving me unlimited backup space for $4.79/month, given a 2-year signup period. Nice.

The downside is that you must keep your computer on at all times. Sure, that might be fine, but given that I try to reduce the carbon (and energy, in general) footprint around here, I’d rather put my computers in sleep or hibernation when not used. The one exception I am willing to make is a good NAS, and possibly also a jump host that will give me ssh access to my home network. Maybe the two combined in a single server – or the jump host in a very small and low power server. Anyway, after years of trying out different setups, mainly focused around a) my iMac with an external USB drive, and b) headless servers (I have all of the Bubba servers, http://www.excitostore.com/sv/frontpage, awesome servers, but even the B3 is today slightly underpowered. Tough challenge keeping up with all the new hardware architectures coming to market. So when the Atom powered dual core Netgear RN 312 was announced it seemed like a nice platform. The java powered CrashPlan application should not be a problem (others have successfully installed it on other x86 powered Netgear NAS:es), it supposedly also nicely handles lots of UPS:es, including (I hope!!) the slightly uncommon Bluewalker UPS that I use. Anyway, getting CrashPlan up and running on the ReadyNAS was top prio. Turned out that some changes were needed, compared to the walk-throughs for earlier ReadyNAS versions. First, the usual disclaimer: One or more of the suggestions in this blog post and related posts on this blog may very well void the warranty of your NAS devices. So. Enough. Given the risk of myself having to re-do this at a later date, or for the benefit of others having the desire for the same setup, here we go:

  1. www.shasam.net has been invaluably helpful, providing general ideas on how to approach CrashPlan on ReadyNAS:es. Still, as the instructions there doesn’t work for the RN312 series, I feel it might be useful with some additional comments.
  2. On the RN312 (using the standard web UI), create a share named “Crashplan”. It will be stored under /data/Crashplan Enable ssh root access (once again, using the standard UI).
  3. ssh into the NAS, using something like ssh root@192.168.1.x, adjust the IP address as needed. Use the pwd of the admin user, that you set when configuring the NAS.
  4. create a working directory, I use /root/dl (as in “download”):
    [code language=”css”]
    cd
    mkdir dl
    cd dl
    [/code]
  5. Install Java:
    [code language=”css”]
    apt-get install openjdk-6-jre-headless
    [/code]
  6. Get CrashPlan (adjust as needed to get latest version):
    [code language=”css”]
    wget http://download.crashplan.com/installs/linux/install/CrashPlan/CrashPlan_3.5.3_Linux.tgz tar -xvzf CrashPlan_3.5.3_Linux.tgz
    [/code]
  7. You need to install some packages to get things working:
    [code language=”css”]
    apt-get install dialog
    dpkg-reconfigure debconf
    [/code]
  8. Set the debconf level to “dialog” and “medium”. It turns out the pre-installed version of cpio doesn’t quite cut it.. Replace it:
    [code language=”css”]
    apt-get remove busybox-cpio
    apt-get install cpio
    [/code]
  9. With Java installed and some environment changes in place, time to install CrashPlan:
    [code language=”css”]
    cd /CrashPlan-install
    ./install.sh
    [/code]
  10. Just press enter to use the default settings, except for where to store the CrashPlan data. Full conversation follows (with EULA slightly shortened). Also, line breaks were lost in copy-paste process, so what’s shown on screen probably differs a bit from the below:
    [code language=”css”]
    Welcome to the CrashPlan Installer.
    Press enter to continue with installation.
    Validating environment… detected root permissions 49581 blocks
    You must review and agree to the EULA before installation. Press enter to read the EULA.

    <EULA>
    Do you accept and agree to be bound by the EULA? (yes/no) yes
    What directory do you wish to install CrashPlan to? [/usr/local/crashplan]
    What directory do you wish to link the CrashPlan executable to? [/usr/local/bin]
    What directory do you wish to store backups in? [/usr/local/var/crashplan] /data/Crashplan
    What directory contains your SYSV init scripts? [/etc/init.d]
    What directory contains your runlevel init links? [/etc/rc5.d]

    Your selections:
    CrashPlan will install to: /usr/local/crashplan
    And put links to binaries in: /usr/local/bin
    And store datas in: /data/Crashplan
    Your init.d dir is: /etc/init.d
    Your current runlevel directory is: /etc/rc5.d
    Is this correct? (y/n) [y]

    Unpacking /
    ./CrashPlan_3.5.3.cpi … 49581 blocks
    /usr/local/crashplan/bin/CrashPlanEngine: line 113: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8.UTF-8): No such file or directory
    Starting CrashPlan Engine …
    Using standard startup OK
    CrashPlan has been installed and the Service has been started automatically.

    Press Enter to complete installation.

    Important directories:
    Installation: /usr/local/crashplan
    Logs: /usr/local/crashplan/log
    Default archive location: /data/Crashplan

    Start Scripts:
    sudo /usr/local/crashplan/bin/CrashPlanEngine start|stop
    /usr/local/crashplan/bin/CrashPlanDesktop

    You can run the CrashPlan Desktop UI locally as your own user or connect a remote Desktop UI to this Service via port-forwarding and manage it remotely. Instructions for remote management are in the readme files placed in your installation directory: /usr/local/crashplan/doc
    To start the Desktop UI: /usr/local/bin/CrashPlanDesktop

    Installation is complete. Thank you for installing CrashPlan for Linux.

    root@RN312:~/dl/CrashPlan-install#
    [/code]

     

  11. Reset debconf to non-interactive (using “noninteractive” and “medium” as settings):
    [code language=”css”]
    dpkg-reconfigure debconf
    [/code]

With this, it should be a smooth ride following the previously mentioned blog post to set up CrashPlan. Worked for me, a few hours later the RN312 has now backed up a few GB and progressing nicely. The full backup will take weeks or more, but that’s fine – the summer is long and I have other backups in place meanwhile.