Installing and Uninstalling Packages and Activation and Deactivation of Daemons in Fonz fun_plug 0.5

German version of this tutorialAfter installing Fonz’ fun_plug (see tutorial on this), you will probably want additional packages or Daemons like NFS or Torrent.

The commands below are ONLY for fun_plug Version 0.5
Please check here for newer tutorials!


1. Packages

1.1. Preinstalled Packages

The main packages included in the fun_plug.tgz tarball (which was downloaded and installed during the installation of Fonz fun_plug) are:

  • Lighttpd – a lightweight HTTP server for hosting web pages on the NAS
  • OpenSSH – Secure Shell (which you already used to login to the NAS)
  • Mediatomb – a UPnP media server (alternative to the one provided by Conceptronic)
  • NTP – Network Time Daemon (to synchronize the NAS’ clock with accurate time servers on the Internet)
  • UNFS3 – user-space NFS server (a file server protocol which is often used by computers running Linux)
  • NFS-Utils – NFS server (requires kernel support like on the CH3SNAS)
  • RSync – efficient file transfer and synchronization utility

We have already used OpenSSH during the tutorial on installing fun_plug to log onto the CH3SNAS using ssh. In a moment we will use rsync.

1.2. Downloading packages

For you convinience, there is a script available from Uli which provides the functionality for downloading the additional packages by Fonz and Uli:

mkdir -p /ffp/pkg/
cd /ffp/pkg/
wget -O /ffp/pkg/
chmod a+x /ffp/pkg/
sh /ffp/pkg/

Or can do it manually in the following sections:

1.2.1. Downloading additional packages provided by Fonz

Downloading of the ffp packages

Downloading of the ffp packages

First make sure, you entered valid gateway & DNS servers in the CH3SNAS configuration (browser -> enter name or IP address of your CH3SNAS -> Setup -> LAN). Your CH3SNAS needs this information in order to access the Internet. You can fill in these values manually (e.g. by copying them from another computer) or by letting the CH3SNAS fetch them from your router using DHCP.

Login to your NAS using the ssh protocol (e.g. using PuTTY). See tutorial page for details on how to do this.

Download additional packages from fonz’ site using the “rsync” file transfer command. The the “.” at the end of the 3rd line is essential (Linux shorthand notation for the current folder):

mkdir -p /ffp/pkg/
cd /ffp/pkg/
/ffp/bin/rsync -av --delete .

Note that the packages are together over 120 MBytes, so it can take a while. After the last file you get some statistics and return to the command prompt.
This step results in roughly 100 packages being copied (as tarballs) to the folder /ffp/pkg/packages/.

1.2.2. Downloading additional packages provided by Uli

Many packages used in the tutorials on this site were created by Uli and are found in his repository. Before you execute the following commands, please make sure that you meet the prerequisites as described in the previous section.

Download additional packages from Uli’s site using the “rsync” file transfer command. Note: The “.” at the end of the 3rd line is essential (Linux shorthand notation for the current folder):

mkdir -p /ffp/pkg/
cd /ffp/pkg/
/ffp/bin/rsync -av --delete .

After the last file you also get some statistics and return to the command prompt. This step results in a few packages being copied (as tarballs) to the folder /ffp/pkg/additional/ and its subdirectories. See PACKAGES.txt for the available packages.

1.2.3. Downloading packages from other sources

Make sure, you trust the source of any package that you download: a malicious (or just buggy) package can cause your NAS to fail, cause loss of data or worse!

1.3. Package management

Package management is done by a program by fonz called “funpkg“. Typing “funpkg” on the command line lists the flags and options that it supports:

Copyright (c) 2008 Tobias Poschwatta <>
Install:   funpkg -i <packages...>
Reinstall: funpkg -I <packages...>
Upgrade:   funpkg -u <packages...>
Remove:    funpkg -r <packages...>
Other options:
  -D <path>  System root directory (default: /)

Important: once you start using funpkg to install Fonz’ packages, you have to complete the entire procedure described in this tutorial in one session.
In other words, once you proceed with any of the steps beyond this point, you have to complete all steps of the Package management part of this tutorial:

  • initial update for packages
  • install new packages,
  • save any configuration changes that you need to save for existing packages that will be upgraded,
  • upgrade existing packages, and (most important of all)…
  • do a chmod a+x on e.g. /ffp/start/

1.3.1. Initial package updating

After the Installation you need to upgrade the installed packages ”’before”’ installing new packages. This is especially important for the funpkg tool itself, as new packages may require new features in funpkg. This is done by the parameter -u for the funpkg-tool. It updates any installed packages, but doesn’t install new ones.

cd /ffp/pkg/
funpkg -u packages/funpkg*.tgz
funpkg -u packages/*.tgz
funpkg -u additional/*/*.tgz

Now you can proceed with the next steps.

1.3.2. Package installation

After a package has been downloaded (as a tarball or .tgz file), you can install it with by changing to the respective directory, e.g. /ffp/pkg/packages:

cd /ffp/pkg/packages
funpkg -i packagename.tgz

If you want to install a number of packages, you can simply add a list of packages to funpkg:

cd /ffp/pkg/packages
funpkg -i packagename1.tgz packagename2.tgz packagename3.tgz ...

If you want to install all packages in a folder, you can use “*” as a wildcard (all files ending with .tgz):

cd /ffp/pkg/
funpkg -i packages/*.tgz
funpkg -i additional/*/*.tgz

We recommend this route, although it should be done carefully (see below). The reason why Fonz recommends this route, rather than letting you install only what you want, is that some packages require other packages or updated versions of these packages to run correctly. Such dependencies are not automatically resolved by funpkg. Thus, for example, you can get into trouble if you update to the latest version of OpenSSH without updating the uclibc package (a library of utilities used by OpenSSH): if the SSH daemon fails to launch properly the next time you reboot the CH3SNAS, you will be “locked out”. Which in turn means that you cannot use PuTTY to login and fix the problem (Hint: Turn on Telnet before updating SSH).

The file /ffp/pkg/packages/MANIFEST.TXT contains a list of all the files installed by each package. You may want to have a look to get a feel for where all these roughly 20,000 files go.

1.3.3. Package configuration

During the installation, certain packages tend to add an ASCII file with configuration settings to the folder /ffp/etc/. This can be viewed from Windows using WordPad or a programming editor like NotePad++. The latter can edit ASCII files with the Linux end-of-line convention. Alternatively, you can use the Joe editor provided as one of these packages. Any modifications can obviously lead to “interesting” results, so be careful, especially with important daemons.

Some packages place example configuration files into folder /ffp/etc/examples/ instead of putting actual configuration files into /ffp/etc/. Such files are ignored by the application: you are expected to read them and copy them (possibly after renaming or even editing) to folder /ffp/etc/ yourself. Examples for a package called PHP as listed in the MANIFEST.txt:

drwxr-xr-x root/root         0 2008-05-29 13:00 ./ffp/etc/examples/
-rw-r--r-- root/root     45030 2008-05-29 13:00 ./ffp/etc/examples/php.ini-dist
-rw-r--r-- root/root     48619 2008-05-29 13:00 ./ffp/etc/examples/php.ini-recommended

1.3.4. Package updating

Note that the names of the tarball files for packages end in an (often elaborate) version number. When you use funpkg -i packagename.tgz to install a package, instead of the normal

Installing package lighttpd-1.4.19-4.tgz ...

you may thus get a response like

Skipping lighttpd-1.4.19-4.tgz (already installed)

if that exact version of Lighttpd is already installed. Or you may get

Skipping lighttpd-1.4.19-4.tgz (installed: lighttpd-1.2.3-4.tgz )

if an older (or newer) version is already installed.

You can force funpkg to install a different version (upgrade or downgrade) with the -u option:

root@NAS:/mnt/HD_a2/ffp/pkg/packages# funpkg -u rsync-3.0.3-1.tgz
Installing package rsync-3.0.3-1 ...
Removing package rsync-3.0.2-2 ...

You probably want to manually upgrade all the packages that were skipped during funpkg -i *.tgz. Again, this can be important because other installed packages may require this upgrade.

But please beware of a number of pitfalls:

  1. This may overwrite any changes you made to configuration files (probably in folder /ffp/etc/). So you may want to create a copy of these first.
  2. This may overwrite access privileges you made to files (particularly to the scripts that start daemons in folder /ffp/start/).

We will discuss the role of the -x flag below (when discussing how to enable/disable daemons) and now only concentrate on avoiding a very real pitfall which happens when you run

funpkg -u OpenSSH-versionnumber.tgz

If you look into MANIFEST.txt you find that it creates (or more precisely – overwites) a file called

-rw-r--r-- root/root       971 2008-07-29 16:30 ./ffp/start/

This would be fine if you don’t need to run the SSH server yet. The problem is that, after running funpkg -u for OpenSSH, a next reboot will not start the SSH daemon (server) and you will be locked out of funplug: PuTTY for example cannot connect using the ssh protocol unless there is a running SSH server. This server can only start with the -x (execute) bit on the file set. Remember that we set that bit for exactly this file in the fun_plug tutorial? So we now need to do that again after you have upgraded whatever packages needed upgrading but BEFORE you exit ssh (or worse reboot the CH3SNAS).

So, to ensure that the file will run when you reboot the CH3SNAS in the future:

chmod a+x /ffp/start/
ls -l /ffp/start/*.sh

This gives all users (a) the right to execute (x) the file /ffp/start/ (in particular it enables the fun_plug script to execute it on startup). The folder listing will include

-rw-r--r-- 1 root root  432 Jul 15 14:44
-rw-r--r-- 1 root root  229 Apr 24 20:16
-rwxr-xr-x 1 root root  971 Jul 29 16:30
-rw-r--r-- 1 root root  383 Aug 12 22:17
-rw-r--r-- 1 root root  169 Aug 12 22:17

If the entry for has 3 x-bits set, you have succeeded.

1.3.5. Package removals

If you want to (e.g. temporarily) disable execution of a server package, see the discussion on Daemons. To remove a package completely, use:

funpkg -r packagename.tgz

Again, some packages (like uclibc) may be needed to run other packages, so removing packages using funpkg is not foolproof. Fortunately, application packages which a non-expert is likely to be aware of because they do something for the end user (e.g. servers/daemons) are unlikely to be used by other packages.

Note that the dependency information can be found at the top of the /ffp/start/ files. The example (from the file /ffp/start/

# PROVIDE: sshd

suggests that you shouldn’t remove the LOGIN package because it is required to run the sshd (=OpenSSH) package.

2. Daemons

2.1. What are Daemons?

Many packages can be used as “”Daemons””, which are basically programs running in the background. E.g. lighttpd (a lightweight Web server) shows no output in the shell (e.g. in PuTTY) during its operation and should be started during the bootup-process.

Note that many daemon names end with d. So lighttpd is not a light tpd (whatever that would be), but a light http (protocol) d(aemon) with a few letters mashed together.

Every daemon that is capable of running in the background delivers a “starter file” which is located in /ffp/start/. These starter files are again simple scripts that control the startup and shutdown of the corresponding daemons.

Some starter files provide additional capabilities and options, which are displayed by simply invoking the starter file without any parameters. Copy and paste the following one line at a time, and try a few more:

cd /ffp/start
sh status
sh status

This works because starter files normally expect a “start” or “stop” parameter. Don’t try this trick with just any shell script: it may do something, because that is what it is there for.

2.2. Starting Daemons manually

You can start every daemon manually by executing

sh /ffp/start/ start

2.3. Stopping Daemons manually

You can stop every daemon manually by executing

sh /ffp/start/ stop

2.4. Permanent activation of Daemons

If you want to activate a Daemon permanently so that it gets executed during the bootup-process, you simply set the execution-right:

chmod a+x

To see which daemons really got started during the last boot, see the end of the ffp.log file (in the top folder of your Volume_1 share). It will contain lines like

* /ffp/start/ ...
Starting /ffp/sbin/sshd

for daemons that were started.

2.5. Permanent deactivation of Daemons

Deactivation of a Daemon (no automatic execution during bootup) is done as follows:

chmod a-x

To see which daemon really got started during the last boot, see the end of the ffp.log file (in the top folder of your Volume_1 share). It will contain lines like

* /ffp/start/ inactive
* /ffp/start/ ...
Starting /ffp/sbin/sshd

indicating which daemons were not started (like the telnet daemon) and which daemons were started (like the ssh daemon).

About Uli

Uli bought his first CH3SNAS in May 2007. Now he owns several NAS-Devices for the backup and storage of media data.Feel free to visit his Homepage: (German) Did his posts help you? Please consider buying him a coffee (or two)!