After a few requests i’ve now tried to install Twonky Server 7 on the NAS_Devices and i can tell you that it works. The following article describes the installation. Before you proceed please check here if Version 7.11-Special is still the current version. If not, please add a comment below.
This tutorial requires an installed fun_plug!
Continue reading Installation of Twonky Server 7 on NAS-devices
This tutorial is deprecated, please use the tutorial for the current version.
Since a while there is a new version of the Twonkymedia Server 6 available. Many readers asked me how to update to this version without loosing the configuration of the already installed version. This article describes the update for the following devices:
For other devices, please follow this article. If you are searching for the article regarding the initial installation (not the update), please look here for this.
Continue reading Update of Twonkymedia Server 6 on the Conceptronic CH3MNAS, D-Link DNS-320,DNS-321,DNS-325 and DNS-343
Many people asked me to compile various packages over the last few years. Sometimes i was able to help and sometimes (in rare occasions) i had to reject a request when it was impossible to fulfill it. Then i often told the requestor to install optware which originated from the NSLU2-Project and provides many addition packages. I didn’t have experienc on this, so i had to leave them in the dark. Until recently. Continue reading Installation of Optware on the D-Link DNS-320, DNS-321, DNS-325, DNS-343, DNS-345 and Conceptronic CH3MNAS
Here the output of cat /proc/meminfo on the Conceptronic CH3MNAS:
MemTotal: 61860 kB MemFree: 3760 kB Buffers: 18368 kB Cached: 25940 kB SwapCached: 220 kB Active: 21512 kB Inactive: 27424 kB SwapTotal: 488336 kB SwapFree: 486500 kB Dirty: 20 kB Writeback: 0 kB AnonPages: 4624 kB Mapped: 3948 kB Slab: 7076 kB SReclaimable: 4240 kB SUnreclaim: 2836 kB PageTables: 280 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 519264 kB Committed_AS: 17060 kB VmallocTotal: 450560 kB VmallocUsed: 17256 kB VmallocChunk: 425980 kB
This tutorial is deprecated, please use the tutorial for the current version.
If you need an advanced Mediaserver, Twonky is one of the best choices. The Problem is that the installation of Twonkymedia Server 6 is a little bit more complicated than just running a Setup. Before you go on, please make sure that the Fonz fun_plug is installed. The following article has only been tested on the following devices:
It will definitely not work on the CH3SNAS, CH3HNAS and DNS-323, please use this tutorial for these devices. If you want to update to the newest version of twonky (and if you’ve already followed this article in the past), then check this out.
Continue reading Installation of Twonkymedia Server 6 on the Conceptronic CH3MNAS and the D-Link DNS-320, DNS-321, DNS-325 and DNS-343
Note that this somewhat elaborate procedure is needed if you are running fun_plug. If you do not have fun_plug installed, or it is no running, you can should use the simpler instructions provided by Conceptronic with the firmware file.
You can tell which firmware version you are running by using a web browser:
This should get you to the screen shown in the picture.
An overview of the current stable version, any more recent beta (or “Release Candidate”) versions, or older versions can be found here.
The page contains links to sites where the firmware can be downloaded. After downloading the required version you will need to unzip or unrar it.
funplugIf you are not running fun_plug, you can simplify things by following the instructions in the PDF readme file supplied with the downloaded firmware rather than following the fancier instructions below which assume you may be running various special servers and running with special settings.
So, in the following, we assume that you are running fun_plug.
If you are running funplug, it is likely that you enabled ssh (Secure Shell) and disabled telnet for security reasons. After the reboot, all modifications to /etc/passwd and /etc/group are gone, which is why we need to temporarily reactivate telnet to ensure that we can login after the upgrade:
ssh (e.g. using PuTTY)
telnet daemon so you can easily login later:
cd /ffp/start ls -al telnetd.sh chmod a+x telnetd.sh ls -al telnetd.sh
This means that on the next reboot telnet should be enabled.
If you are upgrading from a pre-1.0.5 firmware version to version 1.0.5 or later, you may decide to replace the special fan control script “fanctl” from Fonz (see the fan control tutorial) with the standard fan control feature built into the Conceptronic firmware.
Which option is better? The firmware version 1.0.5 has a very simple fan control algorithm. The fan only runs when the internal temperature is 43°C or higher. This is a bit high. Furthermore, the fan speed does not depend on the temperature: the fan is either on or off. Fonz’ solution instead increases the fan speed as the temperature rises. This avoids the fan repeatedly turning on and off when the fan needs to spin, but doesn’t need to run at full speed.
If you decide to try the firmware’s solution, you can deactivate Fonz’ control program using:
cd /ffp/start sh fanctl.sh status ls -al fanctl.sh chmod a-x fanctl.sh ls -al fanctl.sh
The 2nd line reports whether the fanctl utility is running. The chmod a-x causes the special fan script to be disabled on the next reboot.
Rename the file fun_plug to fun_plug.bak to deactivate ffp on the next boot. You can easily do this using e.g. Windows Explorer or using the command shell:
cd /mnt/HD_a2 ls fun_plug* mv fun_plug fun_plug.bak ls fun_plug*
Write down any special configurations you have set up in the system.
The main place to look is in the ”Advanced” tab of the Configuration web page. Write down a reminder to set any particular settings such as ”’users”’ who have access, ”’groups”’ you may have created, ”’ftp access”’ you may have given to groups, etc. If you forget to reconfigure these, you will find out later when e.g. an ftp account doesn’t work. Unfortunately there is no simple way to save these settings and later reload them: you will, for example, have to reenter or define new passwords.
The other setting worth saving is any non-default IP address or network name of your CH3SNAS.
Update the firmware via the web interface (see picture above). During the update, you will get a progress bar. Then, after confirmation, the CH3SNAS will reboot.
Next reset the CH3SNAS firmware settings to the factory defaults (the new firmware may interpret settings stored in Flash memory differently that the previous version). This step is mandatory to ensure correct operation!
Tools >> System >> Restore To Factory Default SettingsThis will cause another reboot during which the IP address, group/user information, user privileges will be lost. Your browser may not find the device again if you use a non-default name. Try the default “http://CH3SNAS/” or using Conceptronic’s “Easy Search Utility” to find your NAS in the network.
At this point, the administrator password is empty, so you can log onto the Config web page as admin with an empty password. Then you need to run Setup >> Run Wizard to get the basic settings correct again. These include
This will lead to a restart after which you will also be able to see the CH3SNAS under its original name on the network and the stored data should be accessible.
At this point you cannot access the CH3SNAS via either telnet or ssh because an out-of-the-box CH3SNAS does not enable either daemon:
fun_plug.bak back to fun_plug using SAMBA (e.g. using Windows Exporer)Tools >> System >> Restart).telnet should work again.telnet and set the root password again using this procedure. This ends with running store-passwd.sh to save the password information.telnet again (first be sure ssh is running!) using an ssh session on PuTTY:
cd /ffp/start ls -al telnetd.sh chmod a-x telnetd.sh ls -al telnetd.sh sh telnetd.sh stop
The final line stops the telnet daemon, so from this point on you (only) have access via the much more secure ssh.
You can now redefine any required user- and group settings (e.g. for ftp users).
Note that after updating the firmware, the NAS will spend a few hours reindexing the hard disks (searching for movies and audio-files) for the itunes and UPnP-services. You can stop this activity by deactivating the respective services.
If you only want to temporarily deactivate fun_plug, simply rename the file fun_plug in the topmost directory of your CH3SNAS, reboot, and you are done.
But there could be cases where you want to completely remove fun_plug. Because the folder containing the fun_plug packages is owned by user root, this folder can only be deleted by root. This can be done by a single rm (remove) command in a PuTTY (ssh) terminal session if you are log in as root. You may want to see this article on root user for information about the special role of the root user.
But let’s assume pessimistically that that doesn’t work because the ssh server is not running or because you have problems logging in as root. Fortunately, the fun_plug script is no owned by root can still be modified by non-root users. This enables a trick to remove the folders without using root privileges: simply add commands for the removal of the fun_plug folder and the fun_plug script to the script itself. These commands will be executed under root privileges during the next reboot.
Note that the folder may be named either ffp or fun_plug.d – depending on the version of fun_plug that you have installed.
You have to download the Script for the Removal here
Rename the downloaded script to fun_plug and copy it to the NAS in the topmost directory of Volume_1. This will probably overwrite a existing script file fun_plug.
Reboot the CH3SNAS by holding down the power button 5 seconds or via the web interface (Tools -> System -> Reboot). During the reboot, fun_plug will be completely removed.
This tutorial is outdated and no longer maintained! Please check for the current tutorial here
The Conceptronic CH3SNAS runs an embedded version of the Linux operating system (OS). This includes a kernel and various Linux programs (mainly servers). Because the CH3SNAS (and many others) runs on an ARM processor, the executable version of Linux and the programs are binaries generated for the ARM processor.
The Firmwares includes a very interesting bonus: the user can execute a script (file) named “fun_plug” when the OS is booted. Unlike all the other Linux software which is loaded when the NAS boots, this file is located on Volume_1 of the hard disk rather than within the flash memory. This means the user can easily and safely modify the file because the contents of the flash memory is not changed. If you delete the fun_plug file (see here for instructions), or replace your hard disk, the modification is gone.
Fun_plug allows the user to start additional programs and tools on the NAS. A Berlin-based developer named “Fonz” created a package called “ffp” (Fonz fun_plug), which includes the script and some extra software which can be invoked by fun_plug.
Installation of fun_plug is easy and takes about 6 steps (with two optional more if you want to do some sightseeing rather than just racing over the Autobahn). These steps should be performed carefully, as they depend on typed commands and running with “root” privileges.
Fun_plug is essentially a technique to stepwise turn a NAS with fixed out-of-the-box functionality into an open Linux machine on which you can install additional software packages and, if you want, learn a bit about Linux.
This also implies that you are (temporarily or permanently) turning a stable turnkey system into a system that Conceptronic no longer supports. This is similar to buying a notebook with Microsoft software, and installing Linux on it. The shop where you bought it can no longer help you if you claim the audio no longer works. Although there is a Tutorial on how to disable and even remove fun_plug, and although the authors have tested their recipes, checked the wording and added warnings, these are advanced tools which can, if you experiment more than your own know-how can handle, give advanced problems.
Risks involved in all this are not so much damaging your hardware (shouldn’t be possible), but loss of reliability of the NAS (you bought a file server to reliably store files, didn’t you). This risk may be acceptable because the software was preintegrated and tested by competent people. But you yourself are, at the end of the day, responsible for deciding to use this.
Possibly a less obvious, but more real risk is that some kind of extensions to the NAS (e.g. adding a server) imply that you may decide to open your local network a bit to the outside world. For example, to allow others to view your holiday videos stored on the device. The out-of-the-box NAS can already have this problem (via the ftp server). The point here is that you are responsible for the security of your device and entire network. This site doesn’t even have tutorials on basic security issues like firewalls, etc. because these are all NAS independent and the tutorials would never be foolproof anyway. So when used wrongly, the NAS and firewall obviously do allow others to read more data than you intended. Or to delete your valuable data. Or to replace software by other software (chance is small, but the impact is high).
Conclusion: as the NAS is a powerful networked device, and as these tutorials can help you make it even more powerful, you are responsibility for having the basic understanding of networked security. Again, this also applies to an out-of-the-box NAS. But the more you mess with it, the more you need to apply some common sense. This is incidentally the reason why we provide some explanation on what you are doing in the tutorials, rather than just telling you what to type 😉
The main reason why people go this route is to extend their NAS with servers such as BitTorrent clients and Web servers. Other typical uses are to add extensions which fix current limitations of the device (e.g. time accuracy, fan noise).
In a first step, we install a script named fun_plug that provides a hook to extend the boot process of Linux on the NAS. That hook was intentionally added by the vendor to enable this. But Conceptronic does not document or support all of this.
An initial set of packages (downloaded as a single compressed archive) gives you enough tools to get started and, if you are curious about the machine or its software, to carefully look around.
This set of tools gives you the ability to install even more software packages (typically servers) from trusted sources. These packages should obviously all have been compiled for the ARM-type processor in the CHS3SNAS and should have been tested on the device (or a very similar device) by a software expert.
This Tutorial has been tested on various devices. Other devices may work, please leave a comment in case you have tested an additional device.
Download the latest files from fonz’ fun_plug repository:
Place a copy of both files in the topmost directory of Volume_1 of your NAS using Windows Explorer (see Screenshot of what shared network drives looks like in Explorer, or alternatively use Samba or FTP).
For fun, you may want to open the file fun_plug by left-clicking here. Alternatively you can open it in Windows’ Wordpad or, better, Notepad++ under Windows. Please be careful not to accidentally modify it. Avoid using Windows’ Notepad for viewing/editing Linux text files: Windows and Linux use different end-of-line conventions.
The script fun_plug is an ASCII file with commands which are executed by the Linux command interpreter (sh for “shell”).
Lines starting with “#” are comments (“#!/bin/sh” is a special case).
You might be able to decode that the program creates a log file called ffp.log (an ASCII file used here to capture the lines which start with “echo”).
Firstly, a number of named constants are defined for various file names and fragments of file names (the lines like “FFP_SOMETHING=...“).
You can see that Fonz developed it for a D-Link DNS-323 (rather than a Conceptronic CH3SNAS, but this doesn’t matter as Uli, PeterH and others have tested in on the CH3SNAS).
The command date will copy the current date and time to the log file.
Next, a first script setup.sh is run if it is found in the expected /mnt/HD_a2/.bootstrap/ folder. Initially it will not be found.
Then a new directory “ffp” is created (mkdir) and the fun_plug.tgz file is unpacked (tar) into that directory. This step is a bit more complex than normal due to a problem with the tar version supplied with the NAS. As a workaround tar is run twice (first the older version, and then the tar version which was untarred from fun_plug.tgz).
If all went well, the log file gets an extra “OK” string. And the tarball input file is deleted (rm). This obviously only happens once (the script skips the unpacking if the tarball file is not found using the if [condition]; commands fi construct).
The “chown” is about changing ownership for a program called busybox. And “chmod” is about changing access privileges.
Then, a script file /ffp/etc/fun_plug.init (“containing the ffp-scripts package”) is executed if it is detected.
Next, a script file /ffp/etc/fun_plug.local is executed if it is detected. It can be used to add your own startup commands: it will not be overwritten by package updates.
Finally, a script file /ffp/etc/rc is run if it exists.
Reboot the NAS by holding down the power button 5 seconds or via the web interface (”Tools” -> ”System” -> ”Reboot”). This causes the NAS to go and find the file fun_plug on Volume_1 and execute it.
If you are interested, you will find that the fun_plug.tgz tarball has disapeared, and has been unpacked into the newly created ffp directory.
You will also find the ffp.log file created during execution of the fun_plug script and while executing some of its commands. It is longish (e.g. 47 KBytes) because the tar program generates a lot of warnings about repairing links (this only happens once). You can view the log file with WordPad or NotePad++.
From now on, whenever the NAS is rebooted and thus the fun_plug script is re-executed, the script appends about 15 extra text lines to the end of this log file. These contain the date/time of reboot and the status of various servers which you may enable in the future (see below). This appending of information to ffp.log gives you one way to determine whether fun_plug is really running: if you last reboot of the NAS is listed, fun_plug and any servers that it actives are running.
Note that the end of the initial log file already states that a server called telnetd is already running. We will use Telnet in the next step.
Windows users can use an open-source telnet client called PuTTY. PuTTY is a self-contained program: the PuTTY.exe file can be stored wherever convenient and executed without any prior installation. In the PuTTY configuration screen you need to set the following before pressing Open:
CH3SNAS) or its IP address (the factory default is 192.168.0.20)Now you can press Open (PuTTY can save these settings under a default or name if you want, but you will likely be using ssh instead of telnet later on).
Linux users are “supposed to be” familiar with how to use telnet.
After connecting to the device, the first line telnet will show:
/ #
Now you are logged in. This command “prompt” is where you can type in commands. The prompt shows you are in the root directory. Note that Linux command lines are not very communicative. These Rambo-like social skills are generally attributed to Linux’ resource-deprived childhood.
We proceed with updating /etc/shadow by using the program pwconv. It uses /etc/passwd to generate the necessary lines in the shadow-file.
pwconv
Now we need to change the password of user “root” to prevent unauthorized access.
Run the passwd command and enter a new password twice (note that Linux passwords are case-sensitive):
passwdNext, activate the root-user which is disabled by default:
usermod -s /ffp/bin/sh root
And change the home-directory of root to a permanent one:
mkdir -p /ffp/home/root/ usermod -d /ffp/home/root/ root
Now check if everything went right using:
loginIf this was successful, proceed to the next step, otherwise return to “passwd“.
Store the password in the NAS. This step is essential, otherwise your password will be cleared on the next reboot! Please check the following section before executing the command itself:
Now execute the command:
store-passwd.sh
This invokes another shell (.sh) script which copies the password-related files to data partitions in Flash memory (mtd1 and mtd2).
Now activate SSH (secure shell: telnet has major security limitations). Such lines can best be copied line-by-line or together into PuTTY:
chmod a+x /ffp/start/sshd.sh sh /ffp/start/sshd.sh start
sshd.sh takes a while to execute and generates three pairs encryption keys for secure communication between the CH3SNAS and a remote client (computer). Each pair has a “fingerprint” for the public key and a corresponding graphical “randomart” image. The fingerprint for the RSA encryption algorithm will incidentally show up again in the next step.
As shown in one of the pictures, the first time you connect to this new (as far as ssh is concerned) machine, you will get a stern warning from ssh. This is because ssh expects to be connecting to this machine through an encrypted connection (now and likely in the future). But ssh wants to be sure that you are connecting to the intended machine rather than to an imposter (“man-in-the-middle”) and has no way of knowing if this is the case. Assuming that you are connecting to via your own (safe) LAN, you don’t need to worry whether the presented identification (public-key fingerprint) is the right one. If you need to connect over the internet (very unlikely) or are paranoid (unlikely), you can follow the confirmation procedure described in this website.
Note that this step associates the name and IP number of your NAS with this public key (this is stored on your computer). This means that during future ssh sessions to this machine the confirmation of the public key is done automatically.
Now you can try to login using an ssh session as user root. This involves starting a second copy of PuttY.
Once you were logged in sucessfully, you can deactivate telnet using:
chmod -x /ffp/start/telnetd.sh
Note that at this point telnet is actually still running, but it will stop working the next time you reboot the NAS. Once you have tested that the ssh server and the associated root password, and encryption keys are working fine you can reboot the NAS: from then on your NAS appliance has essentially been turned into a (somewhat) general purpose Linux computer which you can tweak via “normal” (sic) ssh command line sessions.
Congratulations! With the last step, you’ve installed your fun_plug 🙂
You can now install additional packages or (carefully) look around using the command line!
Note that the initial execution of the fun_plug script creates a new usThe Conceptronic CH3SNAS runs an embedded version of the Linux operating system (OS). This includes a kernel and various Linux programs (mainly servers). Because the CH3SNAS (and many others) runs on an ARM processor, the executable version of Linux and the programs are binaries generated for the ARM processor.
The Firmwares includes a very interesting bonus: the user can execute a script (file) named “fun_plug” when the OS is booted. Unlike all the other Linux software which is loaded when the NAS boots, this file is located on Volume_1 of the hard disk rather than within the flash memory. This means the user can easily and safely modify the file because the contents of the flash memory is not changed. If you delete the fun_plug file (see here for instructions), or replace your hard disk, the modification is gone.
Fun_plug allows the user to start additional programs and tools on the NAS. A Berlin-based developer named “Fonz” created a package called “ffp” (Fonz fun_plug), which includes the script and some extra software which can be invoked by fun_plug.
Installation of fun_plug is easy and takes about 6 steps (with two optional more if you want to do some sightseeing rather than just racing over the Autobahn). These steps should be performed carefully, as they depend on typed commands and running with “root” privileges.
Fun_plug is essentially a technique to stepwise turn a NAS with fixed out-of-the-box functionality into an open Linux machine on which you can install additional software packages and, if you want, learn a bit about Linux.
This also implies that you are (temporarily or permanently) turning a stable turnkey system into a system that Conceptronic no longer supports. This is similar to buying a notebook with Microsoft software, and installing Linux on it. The shop where you bought it can no longer help you if you claim the audio no longer works. Although there is a Tutorial on how to disable and even remove fun_plug, and although the authors have tested their recipes, checked the wording and added warnings, these are advanced tools which can, if you experiment more than your own know-how can handle, give advanced problems.
Risks involved in all this are not so much damaging your hardware (shouldn’t be possible), but loss of reliability of the NAS (you bought a file server to reliably store files, didn’t you). This risk may be acceptable because the software was preintegrated and tested by competent people. But you yourself are, at the end of the day, responsible for deciding to use this.
Possibly a less obvious, but more real risk is that some kind of extensions to the NAS (e.g. adding a server) imply that you may decide to open your local network a bit to the outside world. For example, to allow others to view your holiday videos stored on the device. The out-of-the-box NAS can already have this problem (via the ftp server). The point here is that you are responsible for the security of your device and entire network. This site doesn’t even have tutorials on basic security issues like firewalls, etc. because these are all NAS independent and the tutorials would never be foolproof anyway. So when used wrongly, the NAS and firewall obviously do allow others to read more data than you intended. Or to delete your valuable data. Or to replace software by other software (chance is small, but the impact is high).
Conclusion: as the NAS is a powerful networked device, and as these tutorials can help you make it even more powerful, you are responsibility for having the basic understanding of networked security. Again, this also applies to an out-of-the-box NAS. But the more you mess with it, the more you need to apply some common sense. This is incidentally the reason why we provide some explanation on what you are doing in the tutorials, rather than just telling you what to type 😉
The main reason why people go this route is to extend their NAS with servers such as BitTorrent clients and Web servers. Other typical uses are to add extensions which fix current limitations of the device (e.g. time accuracy, fan noise).
In a first step, we install a script named fun_plug that provides a hook to extend the boot process of Linux on the NAS. That hook was intentionally added by the vendor to enable this. But Conceptronic does not document or support all of this.
An initial set of packages (downloaded as a single compressed archive) gives you enough tools to get started and, if you are curious about the machine or its software, to carefully look around.
This set of tools gives you the ability to install even more software packages (typically servers) from trusted sources. These packages should obviously all have been compiled for the ARM-type processor in the CHS3SNAS and should have been tested on the device (or a very similar device) by a software expert.
This Tutorial has been tested on various devices. Other devices may work, please leave a comment in case you have tested an additional device.
Download the latest files from fonz’ fun_plug repository:
Place a copy of both files in the topmost directory of Volume_1 of your NAS using Windows Explorer (see Screenshot of what shared network drives looks like in Explorer, or alternatively use Samba or FTP).
For fun, you may want to open the file fun_plug by left-clicking here. Alternatively you can open it in Windows’ Wordpad or, better, Notepad++ under Windows. Please be careful not to accidentally modify it. Avoid using Windows’ Notepad for viewing/editing Linux text files: Windows and Linux use different end-of-line conventions.
The script fun_plug is an ASCII file with commands which are executed by the Linux command interpreter (sh for “shell”).
Lines starting with “#” are comments (“#!/bin/sh” is a special case).
You might be able to decode that the program creates a log file called ffp.log (an ASCII file used here to capture the lines which start with “echo”).
Firstly, a number of named constants are defined for various file names and fragments of file names (the lines like “FFP_SOMETHING=...“).
You can see that Fonz developed it for a D-Link DNS-323 (rather than a Conceptronic CH3SNAS, but this doesn’t matter as Uli, PeterH and others have tested in on the CH3SNAS).
The command date will copy the current date and time to the log file.
Next, a first script setup.sh is run if it is found in the expected /mnt/HD_a2/.bootstrap/ folder. Initially it will not be found.
Then a new directory “ffp” is created (mkdir) and the fun_plug.tgz file is unpacked (tar) into that directory. This step is a bit more complex than normal due to a problem with the tar version supplied with the NAS. As a workaround tar is run twice (first the older version, and then the tar version which was untarred from fun_plug.tgz).
If all went well, the log file gets an extra “OK” string. And the tarball input file is deleted (rm). This obviously only happens once (the script skips the unpacking if the tarball file is not found using the if [condition]; commands fi construct).
The “chown” is about changing ownership for a program called busybox. And “chmod” is about changing access privileges.
Then, a script file /ffp/etc/fun_plug.init (“containing the ffp-scripts package”) is executed if it is detected.
Next, a script file /ffp/etc/fun_plug.local is executed if it is detected. It can be used to add your own startup commands: it will not be overwritten by package updates.
Finally, a script file /ffp/etc/rc is run if it exists.
Reboot the NAS by holding down the power button 5 seconds or via the web interface (”Tools” -> ”System” -> ”Reboot”). This causes the NAS to go and find the file fun_plug on Volume_1 and execute it.
If you are interested, you will find that the fun_plug.tgz tarball has disapeared, and has been unpacked into the newly created ffp directory.
You will also find the ffp.log file created during execution of the fun_plug script and while executing some of its commands. It is longish (e.g. 47 KBytes) because the tar program generates a lot of warnings about repairing links (this only happens once). You can view the log file with WordPad or NotePad++.
From now on, whenever the NAS is rebooted and thus the fun_plug script is re-executed, the script appends about 15 extra text lines to the end of this log file. These contain the date/time of reboot and the status of various servers which you may enable in the future (see below). This appending of information to ffp.log gives you one way to determine whether fun_plug is really running: if you last reboot of the NAS is listed, fun_plug and any servers that it actives are running.
Note that the end of the initial log file already states that a server called telnetd is already running. We will use Telnet in the next step.
Windows users can use an open-source telnet client called PuTTY. PuTTY is a self-contained program: the PuTTY.exe file can be stored wherever convenient and executed without any prior installation. In the PuTTY configuration screen you need to set the following before pressing Open:
CH3SNAS) or its IP address (the factory default is 192.168.0.20)Now you can press Open (PuTTY can save these settings under a default or name if you want, but you will likely be using ssh instead of telnet later on).
Linux users are “supposed to be” familiar with how to use telnet.
After connecting to the device, the first line telnet will show:
/ #
Now you are logged in. This command “prompt” is where you can type in commands. The prompt shows you are in the root directory. Note that Linux command lines are not very communicative. These Rambo-like social skills are generally attributed to Linux’ resource-deprived childhood.
We proceed with updating /etc/shadow by using the program pwconv. It uses /etc/passwd to generate the necessary lines in the shadow-file.
pwconv
Now we need to change the password of user “root” to prevent unauthorized access.
Run the passwd command and enter a new password twice (note that Linux passwords are case-sensitive):
passwdNext, activate the root-user which is disabled by default:
usermod -s /ffp/bin/sh root
And change the home-directory of root to a permanent one:
mkdir -p /ffp/home/root/ usermod -d /ffp/home/root/ root
Now check if everything went right using:
loginIf this was successful, proceed to the next step, otherwise return to “passwd“.
Store the password in the NAS. This step is essential, otherwise your password will be cleared on the next reboot! Please check the following section before executing the command itself:
Now execute the command:
store-passwd.sh
This invokes another shell (.sh) script which copies the password-related files to data partitions in Flash memory (mtd1 and mtd2).
Now activate SSH (secure shell: telnet has major security limitations). Such lines can best be copied line-by-line or together into PuTTY:
chmod a+x /ffp/start/sshd.sh sh /ffp/start/sshd.sh start
sshd.sh takes a while to execute and generates three pairs encryption keys for secure communication between the CH3SNAS and a remote client (computer). Each pair has a “fingerprint” for the public key and a corresponding graphical “randomart” image. The fingerprint for the RSA encryption algorithm will incidentally show up again in the next step.
As shown in one of the pictures, the first time you connect to this new (as far as ssh is concerned) machine, you will get a stern warning from ssh. This is because ssh expects to be connecting to this machine through an encrypted connection (now and likely in the future). But ssh wants to be sure that you are connecting to the intended machine rather than to an imposter (“man-in-the-middle”) and has no way of knowing if this is the case. Assuming that you are connecting to via your own (safe) LAN, you don’t need to worry whether the presented identification (public-key fingerprint) is the right one. If you need to connect over the internet (very unlikely) or are paranoid (unlikely), you can follow the confirmation procedure described in this website.
Note that this step associates the name and IP number of your NAS with this public key (this is stored on your computer). This means that during future ssh sessions to this machine the confirmation of the public key is done automatically.
Now you can try to login using an ssh session as user root. This involves starting a second copy of PuttY.
Once you were logged in sucessfully, you can deactivate telnet using:
chmod -x /ffp/start/telnetd.sh
Note that at this point telnet is actually still running, but it will stop working the next time you reboot the NAS. Once you have tested that the ssh server and the associated root password, and encryption keys are working fine you can reboot the NAS: from then on your NAS appliance has essentially been turned into a (somewhat) general purpose Linux computer which you can tweak via “normal” (sic) ssh command line sessions.
Congratulations! With the last step, you’ve installed your fun_plug 🙂
You can now install additional packages or (carefully) look around using the command line!
Note that the initial execution of the fun_plug script creates a new user group utmp.
The script that installs the ssh server creates a new user named sshd and adds the user to utmp. This user is for internal use only, and has no ability to login. It is standard procedure when installing OpenSSH, and believed to be safe.
On a NAS, user sshd also shows up as having read-only ftp access to Volume_1. Although it is doubtful that this user really can access ftp, this seems to be a bug and is being investigated.er group utmp.
The script that installs the ssh server creates a new user named sshd and adds the user to utmp. This user is for internal use only, and has no ability to login. It is standard procedure when installing OpenSSH, and believed to be safe.
On a NAS, user sshd also shows up as having read-only ftp access to Volume_1. Although it is doubtful that this user really can access ftp, this seems to be a bug and is being investigated.
Here the output of dmesg on the Conceptronic CH3MNAS.
Linux version 2.6.22.7 (eve@SWTEST1) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #85 Thu Mar 26 09:48:50 CST 2009 CPU: ARM926EJ-S [41069260] revision 0 (ARMv5TEJ), cr=a0053177 Machine: Feroceon Using UBoot passing parameters structure Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 16384 DMA zone: 128 pages used for memmap DMA zone: 0 pages reserved DMA zone: 16256 pages, LIFO batch:3 Normal zone: 0 pages used for memmap CPU0: D VIVT write-back cache CPU0: I cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets CPU0: D cache: 32768 bytes, associativity 1, 32 byte lines, 1024 sets Built 1 zonelists. Total pages: 16256 Kernel command line: root=/dev/ram console=ttyS0,115200 :::DB88FXX81:egiga0:none PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB 0MB 0MB 0MB = 64MB total Memory: 53168KB available (2880K code, 190K data, 124K init) Calibrating delay loop... 332.59 BogoMIPS (lpj=1662976) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 Sys Clk = 166666667, Tclk = 166666667 CPU Interface ------------- SDRAM_CS0 ....base 00000000, size 64MB SDRAM_CS1 ....disable SDRAM_CS2 ....disable SDRAM_CS3 ....disable PEX0_MEM ....base e0000000, size 128MB PEX0_IO ....base f2000000, size 1MB PCI0_MEM ....base e8000000, size 128MB PCI0_IO ....base f2100000, size 1MB INTER_REGS ....base f1000000, size 1MB DEVICE_CS0 ....no such DEVICE_CS1 ....no such DEVICE_CS2 ....no such DEV_BOOCS ....base ff000000, size 16MB CRYPT_ENG ....base f0000000, size 64KB Marvell Development Board (LSP Version 3.0.5_NAS_GDP)-- RD-88F5182-NAS-2 Soc: 88F5182 A2 Detected Tclk 166666667 and SysClk 166666667 Marvell USB EHCI Host controller #0: c1072600 Marvell USB EHCI Host controller #1: c1072400 PCI: bus0: Fast back to back transfers enabled SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 Time: orion_clocksource clocksource has been installed. IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered checking if image is initramfs...it isnt (no cpio magic); looks like an initrd Freeing initrd memory: 8503K RTC registered Use the XOR engines (acceleration) for enhancing the following functions: o RAID 5 Xor calculation o kernel memcpy o kenrel memzero o copy user to/from kernel buffers Number of XOR engines to use: 2 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) squashfs: version 3.3 (2007/10/31) Phillip Lougher io scheduler noop registered io scheduler anticipatory registered (default) Serial: 8250/16550 driver $Revision: 1.1.1.1 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a 16550A serial8250.0: ttyS1 at MMIO 0xf1012100 (irq = 4) is a 16550A RAMDISK driver initialized: 2 RAM disks of 14336K size 1024 blocksize loop: module loaded Marvell Ethernet Driver 'mv_ethernet': o Uncached descriptors in DRAM o DRAM SW cache-coherency o TCP segmentation offload enabled o Checksum offload enabled o Marvell ethtool proc enabled o Rx desc: 128 o Tx desc: 256 o Loading network interface 'egiga0' PPP generic driver version 2.4.2 PPP Deflate Compression module registered PPP BSD Compression module registered PPP MPPE Compression module registered NET: Registered protocol family 24 Intergrated Sata device found scsi0 : Marvell SCSI to SATA adapter scsi1 : Marvell SCSI to SATA adapter scsi 0:0:0:0: Direct-Access SAMSUNG HD203WI 1AN1 PQ: 0 ANSI: 5 scsi 1:0:0:0: Direct-Access SAMSUNG HD203WI 1AN1 PQ: 0 ANSI: 5 scsi 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: Attached scsi generic sg1 type 0 physmap-flash.0: failed to claim resource 0 flash VppMin = "0" , VppMax = "0" cfi_flash_0: Found 1 x16 devices at 0x0 in 8-bit bank Amd/Fujitsu Extended Query Table at 0x0040 cfi_flash_0: CFI does not contain boot bank location. Assuming top. number of CFI chips: 1 cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness. Creating 6 MTD partitions on "cfi_flash_0": 0x00000000-0x00020000 : "MTD1" 0x00020000-0x00040000 : "MTD2" 0x00040000-0x00240000 : "Linux Kernel" 0x00240000-0x00c40000 : "File System" 0x00f80000-0x01000000 : "u-boot" 0x00c40000-0x00f80000 : "Module" ehci_marvell ehci_marvell.4523: Marvell Orion EHCI ehci_marvell ehci_marvell.4523: new USB bus registered, assigned bus number 1 ehci_marvell ehci_marvell.4523: irq 17, io base 0xf1050100 ehci_marvell ehci_marvell.4523: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected ehci_marvell ehci_marvell.167817: Marvell Orion EHCI ehci_marvell ehci_marvell.167817: new USB bus registered, assigned bus number 2 ehci_marvell ehci_marvell.167817: irq 12, io base 0xf10a0100 ehci_marvell ehci_marvell.167817: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver mice: PS/2 mouse device common for all mice md: linear personality registered for level -1 md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 EXT2-fs warning: maximal mount count reached, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing init memory: 124K usb 1-1: new high speed USB device using ehci_marvell and address 2 usb 1-1: configuration #1 chosen from 1 choice sd 0:0:0:0: [sda] 3907029168 512-byte hardware sectors (2000399 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 23 00 10 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA sd 0:0:0:0: [sda] 3907029168 512-byte hardware sectors (2000399 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 23 00 10 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA sda: sda1 sda2 sda4 sd 0:0:0:0: [sda] Attached SCSI disk sd 1:0:0:0: [sdb] 3907029168 512-byte hardware sectors (2000399 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 23 00 10 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sd 1:0:0:0: [sdb] 3907029168 512-byte hardware sectors (2000399 MB) sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 23 00 10 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA sdb: sdb1 sdb2 sdb4 sd 1:0:0:0: [sdb] Attached SCSI disk usbcore: registered new interface driver usblp drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver Installing knfsd (copyright (C) 1996 okir@monad.swb.de). egiga0: mac address changed egiga0: link down Adding 530104k swap on /dev/sda1. Priority:-1 extents:1 across:530104k Adding 530104k swap on /dev/sdb1. Priority:-2 extents:1 across:530104k egiga0: link up, full duplex, speed 1 Gbps ext3: No journal on filesystem on sda4 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sdb4 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sda2 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sdb2 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sda2 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sdb2 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sda4 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended ext3: No journal on filesystem on sdb4 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
Here the output of cat /proc/cpuinfo on the Conceptronic CH3MNAS:
Processor : ARM926EJ-S rev 0 (v5l) BogoMIPS : 332.59 Features : swp half thumb fastmult edsp CPU implementer : 0x41 CPU architecture: 5TEJ CPU variant : 0x0 CPU part : 0x926 CPU revision : 0 Cache type : write-back Cache clean : cp15 c7 ops Cache lockdown : format C Cache format : Harvard I size : 32768 I assoc : 1 I line length : 32 I sets : 1024 D size : 32768 D assoc : 1 D line length : 32 D sets : 1024 Hardware : Feroceon Revision : 0000 Serial : 0000000000000000