Putting the DNS-321 to work as a home server

A short time ago I wrote about my purchase of a D-Link DNS-321 NAS device.

This article will describe how I set the device up as a home server to provide a number of common network services.

Within days of getting my new DNS-321, I was able to use add-on software linked to from the DNS323Wiki wiki site to get it up and running as the primary file, multimedia, web and name server for my home network. This was a real benefit to me because, apart from freeing up my personal workstation from its previous responsibilities as the provider of these services at home, it also provided an opportunity to reduce the amount of power consumed by that workstation by allowing it to be turned off most of the day and night. According to a spec sheet for the D-Link device it draws only 30W on peak load, and 5W when on standby This is significantly less than the 106 to 165W that my Dell Dimension 5150n draws when running.

At the beginning my main goal was to provide a central file storage area for the house that could be accessed over the SMB, NFS, FTP and UPNP (media server) protocols. As it turned out the DNS-321’s nature as an embedded Linux device enabled me to also configure access over SFTP and HTTP, and to offload the DNS and DHCPD services that had been running on my workstation to the new device.

All of this enhanced functionality was possible by installing the Fonz Fun_Plug package and following the instructions in detailed HOWTOs found on the DNS323Wiki. The 1st Steps article is where I started. The fun_plug README provides additional information. An annotated Package List provides information on each package, as well as a download link.

All of the add-on packages installed came from the base, extra packages and additional packages repositories.

After an test setup that ran on an old 250GB SATA drive, I reset everything to factory settings and installed the 1 TB Western Digital WD10000CSRTL “Green” drive that would allow me to consolidate all my existing file shares and backups in one place. I then installed Fun_Plug to get basic telnet and sshd access to the system. From that point forward most system administration was done at the command line rather than in the system’s web based console. The install of the basic package created a symlink /ffp on the root filesystem that mapped to /mnt/HD_a2/ffp, the physical drive.

Be sure to carefully follow the instructions on setting up the root and additional users. Keep in mind that you’ll need to use groupadd and useradd to set up your Linux groups and users, and passwd to set their passwords. If you’ll be accessing the unit from other Linux boxes on your network you should try to assign the gid and uid numbers that each group and user have on your other machines (I maintain a common set of gid and uid numbers on each Unix machine on my network to make interoperability easier, for example group “users” would always get gid 505 and user “ted” would always get uid 1010).

Because of the device’s tendancy to reset the host name and overwrite any changes to /etc/hosts, /etc/resolv.conf and /etc/services on reboot, I created a simple shell script to copy over my preferred versions of these files (kept under /ffp/etc) when the system boots, called /ffp/start/sethost.sh. Here is the code:

#!/ffp/bin/sh
. /ffp/etc/ffp.subr
`hostname host.example.com`
cp/ffp/etc/hosts /etc/hosts
cp /ffp/etc/resolv.conf /etc/resolv.conf
cp /ffp/etc/services /etc/services
run_rc_command "$1"

The dnsmasq package was installed to provide DNS and DHCPD services. Once installed, the service daemon launches from /ffp/start and gets its basic configuration from /mnt/HD_a2/ffp/etc/dnsmasq.conf, /etc/hosts and /etc/resolv.conf. I added a separate /ffp/etc/more_hosts file to hold my internal host list to avoid cluttering the system /etc/hosts. This file follows the same syntax as /etc/hosts. Here’s an example dnsmasq.conf:

# Configuration file for dnsmasq.
	
domain-needed
bogus-priv
filterwin2k
resolv-file=/ffp/etc/resolv.conf
strict-order
addn-hosts=/ffp/etc/more_hosts
domain=example.com
expand-hosts
	
dhcp-range=10.0.0.100,10.0.0.125,255.255.255.0,7d
dhcp-option=1,255.255.255.0 # default subnet mask
dhcp-option=2,-18000 # time offset (EST)
dhcp-option=3,10.0.0.1  # address of internal gateway (router)
dhcp-option=6,10.0.0.225,208.67.220.220,208.67.222.222 # Name servers (local + ISP)
dhcp-leasefile=/ffp/var/lib/misc/dnsmasq.leases
#log-queries
log-dhcp
dhcp-host=99:DD:99:99:CC:FF,host.example.com,10.0.0.15 # client MAC address, IP assigned

[In order to get the right behavior from the server for CNAME records, I listed each CNAME as a separate host, like this:

10.0.0.5 one.example.com one
10.0.0.5 www2.example.com www2

]

Being unimpressed with the embedded NFS server, I turned it off in the web console and installed the unfs3 package, which is configured and behaves just like a “real” NFS server.

The same followed for the ntp service, which I replaced with the ntp package from the base packages.

Finally, to provide read-only access to most files on disk, I installed the lightweight HTTPD server that comes in the lighthttpd package. An extended fun_plug HOWTO provides instructions and explainatory links on how to force the embedded web server to port 81 so that your new lighthttpd server can listen on port 80. The magic is accomplished with this shell script, installed as /ffp/start/kickwebs.sh:

#!/ffp/bin/sh
# PROVIDE: kickwebs
# REQUIRE: LOGIN
# BEFORE: lighttpd
. /ffp/etc/ffp.subr
name="kickwebs"
start_cmd="kickwebs_start"
stop_cmd=:
kickwebs_start()
{
        echo "Kicking webs ..."
        killall webs
}
run_rc_command "$1"

An important point to consider when working with the DNS-321 is that it is basically an embedded Linux server onto which a “user-friendly” administration system has been superimposed. Sort of like C-Panel, but not as hopeless. Unlike C-Panel, the DNS-321 can and is best administered using standard Linux commands and practices. The only exception to this would be the SMB server and disk subsystem. Unless you want to replace the shipping Samba server (something I’m actually considering for a future project), you’ll need to struggle with the web interface for initial SMB share setup. My advice is to keep it simple, share everything you’re going to expose as read/write and rely on filesystem permissions to restrict access. After making any configuration change through the web admin tool for Samba, be sure to reset user passwords with smbpasswd.