DNS-323 based home security camera

Quite some time ago, I bought a wireless IP camera from Amazon UK, intending to set it up at home as a DIY security camera. Whilst it was great value for money, the web based user interface was quite limited and basically I wasn't able to do what I wanted.

After some googling, I found out about 'motion', motion detection software, seemingly designed for the job. I figured if I could run 'motion' on my DNS-323, I could make a workable solution.

EasyN FS-613A-M136 Wireless Pan & Tilt IP Camera
Motion

Recently I got around to trying it, and am pleased with the results so far, his how I did it -

Download and install development tools (thanks fonz) necessary to build motion using -

wget http://www.inreto.de/dns323/fun-plug/0.7/oabi/packages/
funpkg -i

for each of the packages below -

autoconf-2.68-oarm-2.txz
automake-1.11.3-oarm-1.txz
binutils-2.22-oarm-3.txz
gcc-4.5_20120202-oarm-1.txz
gcc-solibs-4.5_20120202-oarm-1.txz
libjpeg-8c-oarm-2.txz
linux-libc-headers-2.6.12.0-oarm-2.txz
make-3.81-oarm-2.txz
mpfr-3.1.0-oarm-2.txz
uClibc-0.9.30.3-oarm-1.txz
uClibc-solibs-0.9.30.3-oarm-1.txz

Download motion source, configure, and make -

motion-3.2.12.tar.gz

./configure --without-v4l

make

A small patch afterwards, to get it to link properly -

gcc  -o motion motion.o conf.o draw.o jpegutils.o video.o video2.o video_common.o netcam.o netcam_ftp.o netcam_jpeg.o netcam_wget.o track.o alg.o event.o picture.o rotate.o webhttpd.o webcam.o  -lm  -ljpeg -lpthread

root@dlink-EEF76A:/mnt/HD_b2/tmp/motion-3.2.12# cat motion.conf 

netcam_url http://192.168.0.111:81/videostream.cgi?showlength=1
netcam_userpass admin:password
locate on

framerate 2

And voila -

root@dlink-EEF76A:/mnt/HD_b2/tmp/motion-3.2.12# ./motion -c motion.conf 

[0] Processing thread 0 - config file motion.conf

[0] Motion 3.2.12 Started

[0] Thread 1 is from motion.conf

[1] Thread 1 started

[1] Resizing pre_capture buffer to 1 items

Works nicely!

DNS-323 Updates

As the drives are getting old in my DNS-323, I started to look at updating the oldest one to a 2TB drive. After some reading about Advanced Format Drives, I decided it was time to a firmware and ffp upgrade. This I did in steps.

Firmware from 1.06 -> 1.08
- minor issues related to ffp installation on USB
- otherwise smooth

FFP 0.5 -> 0.7
- smooth

transmission
- Smooth with ffp-0.7 (oabi)

Firmware from 1.08 -> 1.10
- smooth

NFS apkg install

- smooth

OpenVPN on the DNS-323

There are times I want to grab files from my trusty DNS-323 when not at home. Recently I found time to try opening up access to it using OpenVPN.  This post shows the steps... and it really is simple to setup. I tested the process with Linpus, Fedora 12 and Windows XP as a client, and all went smoothly.

Tomcat on DNS-323

Given my lack of success with bridging for VirtualBox, I thought I'd try starting Tomcat on the DNS-323.

Starting with hope provided by this post.

The process was remarkably easy. Follow this post to get optware setup.
Then install the jamvm optware package.
Next, follow this post to install Tomcat.

It's a bit of a memory hog,
Mem: 60260K used, 1644K free, 0K shrd, 11220K buff, 8916K cached
CPU: 1% usr 0% sys 0% nice 97% idle 0% io 0% irq 0% softirq
Load average: 0.03 0.06 0.18
PID PPID USER STAT VSZ %MEM %CPU COMMAND
30766 30688 root S 40204 65% 1% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30687 30686 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30767 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30835 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30824 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30836 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30690 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30691 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30689 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30768 30688 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak
30688 30687 root S 40204 65% 0% jamvm -classpath /opt/share/classpath/glibj.zip:/opt/jak

and painfully slow -
INFO: Server startup in 151671 ms

but it seems to be reasonably functional... although trying to run a database as well on the DNS-323 would be a stretch.

autofs #3

Ok, I weakened... again this isn't a pretty solution, and it seems NetworkManager is becoming my friend...

[user@localhost ~]$ cat /etc/NetworkManager/dispatcher.d/03-autofs 
#!/bin/sh
if [ "$2" = "up" ]; then
 AUTOFS=/etc/init.d/autofs

 if [ ! -x $AUTOFS ]; then
    exit 0
 fi

 $AUTOFS start > /dev/null
fi

DAR backup

Well I started looking at the different file base alternatives, but relatively quickly put many of them on hold. They each have there benefits, and I'll try to get back to them soon - but here in bugwhine style, I'll just explain why I put them on hold.

unison
Interesting file synchronizing tool.
Unfortunately on hold, as it's written in Objective Caml, so building for Linpus may require a bunch of work, I don't have time to follow this path right now.

rdiff-backup
In brief - File based backup directory -> directory. Hard links and special files, permissions etc. are preserved.
Incremental diffs are preserved in a special directory.
rpm available at livna (rdiff-backup.i386)

Why on hold -
- requires own server on NAS
- backup to/from cifs/samba mount not recommended
- file based

rsnapshot
A filesystem snapshot tool, using rsync.
rpm available at livna - rsnapshot.noarch
Why on hold -
- snapshots may become 'messy' on the backup filesystem
- written in perl (*)

duplicity
Uploads encrypted tar volumes to remote system. Uses librsync.
rpm available at livna - duplicity.i386

Why on hold -
- doesn't handle hard links
- written in python (*)

DAR - Disk Archive
In the end DAR was the first utility I made a successful full and incremental backup with (ie. without putting it on hold). It's available at livna -

[root@localhost ~]# yum install dar.i386

My first impressions from the documentation and the command line switches was that it looked a bit primitive, and that maybe I should have not given up so easily on the other tools.

I tried a complete backup first as follows -

[root@localhost ~]# dar -v -z -R / -P dev -P proc -P mnt -P sys -P tmp -c /mnt/nas/aspire/full

and remained skeptical. It took quite some time, but the resulting file was a compact 915MB.
To put it further to the test, I tried an incremental backup -

[root@localhost ~]# dar -v -z -R / -P dev -P proc -P mnt -P sys -P tmp -A /mnt/nas/aspire/full -c /mnt/nas/aspire/diff1
...
--------------------------------------------
59 inode(s) saved
with 2324 hard link(s) recorded
0 inode(s) changed at the moment of the backup
80778 inode(s) not saved (no inode/file change)
0 inode(s) failed to save (filesystem error)
5 inode(s) ignored (excluded by filters)
0 inode(s) recorded as deleted from reference backup
--------------------------------------------
Total number of inode considered: 80842
--------------------------------------------

At this point my skepticism had almost completely died. The incremental backup was very fast, and efficient. Being 'tar' style (single file on the destination device), there aren't issues with cifs/samba permissions. A clean result, but still with the possibility to quickly restore individual files.

[root@localhost ~]# du -h /mnt/nas/aspire/*
3.0M /mnt/nas/aspire/diff1.1.dar
915M /mnt/nas/aspire/full.1.dar

The remaining thing bothering me, is manually specifying the paths to exclude from the backup. Perhaps a small thing, and perhaps something I should tune further.

I need to look further into a backup schedule, recovery methods and management of the archives with dar_manager - but this feels like a good start.

Thumbs up DAR.

(*) Perl and Python fans - I'm not against these languages at all. I just find that scripted solutions tend to be less well integrated than compiled solutions. Output messsages, exception handling etc, is often unprofessional in solutions based on scripting languages - and it was fairly clear that this is true also for rsnapshot and duplicity.

Backup of Aspire One to DNS-323

I want to backup my Aspire One to my DNS-323 NAS, there are a plethora of ways to do this, so I thought I'd evaluate them here.

The following methods came to mind immediately -
- copy the whole hard disk/partition image (ghost style)
- copy at a file level, rsync style

Initially I like the whole image method. It speeds up the recovery process, and with a Linux style implementation, it's probably possible to loop mount the image, if one just wants to recover some files anyway. Or would this require 120GB or RAM? :)

The first obstacle of the image method is that you probably need to have the file system either not mounted or mounted read-only. This could be a hassle - I certainly don't want to have to boot on an external drive to perform a backup... but maybe dropping down to single user mode would be ok.

It's worth noting that the Aspire one comes with a recovery DVD (bootable via external drive or copy to USB key), that can restore the system to it's factory install. This should be a reasonable starting point for then restoring changed applications/data/configuration from the backup mechanisms evaluated here.

Partimage
Well I liked the look of partimage, and decided to start here. Rather than setup partimaged on the NAS, it seems mounting the filesystem was an easier way to go. See below -

[user@localhost ~]$ su - Password:
[root@localhost ~]# modprobe cifs
[root@localhost ~]# mkdir /mnt/nas
[root@localhost ~]# mount -t cifs //192.168.1.10/Volume_1 /mnt/nas
Password:
[root@localhost ~]# wget "http://dag.wieers.com/rpm/packages/partimage/partimage-static-0.6.5-1.rh7.rf.i386.rpm"
[root@localhost ~]# rpm -i partimage-static-0.6.5-1.rh7.rf.i386.rpm
warning: partimage-static-0.6.5-1.rh7.rf.i386.rpm: Header V3 DSA signature: NOKEY, key ID 6b8d79e6
[root@localhost ~]# partimage-static

I then added an fstab entry for the partition
//192.168.1.10/Volume_1 /mnt/nas cifs auto,rw,user=guest,password=guest

but soon wandered off into issues with mounting it as a normal (non root user). For now I'm relying on sudo.
The big challenge is to unmount the root partition, or remount it in read-only mode, such that partimage can be safely used to produce a consistent image.

As the standard Linpus install only has one partition + swap, this challenge stumped me. The only options I see are unfortunately booting off external media, or doing some repartitioning. This is where I give up on this method for now.

Next I'll take a look at unison or rdiff-backup -
http://www.cis.upenn.edu/~bcpierce/unison/
http://www.nongnu.org/rdiff-backup/

D-Link DNS-323 Easy Search Utility

Ok, I've had a DNS-323 NAS box for sometime now, and really like it. It works well, was good value, and provides lots of functions to keep you interested... particularly if you're willing to do some 'hacking'.

Right now I want to start using the bittorrent client on it (that was released together with a firmware update)... to install the bittorrent client you need to use D-Link's Easy Search Utility... and that's where the whine starts.

One of the main puposes of this utility is apparently to find and map the NAS drives in windows.

Why write an application that provides functions that already exist? Particularly if it doesn't work as well as the functions built into Windows/Linux etc already?

In my case, Windows (even a horribly firewalled Vista) can find the device through samba, and through directly specifying it's IP address. The drive can be mapped by right clicking, and map drive. The configuration web page can be accessed through any web browser...

The easy search utility isn't able to find the drive on my network...
It has a dialog box where you can enter the ip address... but apparently, this can only be used if it can already find the drive.

What is the point?

I think I'll give up on D-Link's bittorrent client, and use something freely available on the net... with a more sensible install procedure.