This tutorial is deprecated and should only be used with fonz fun_plug 0.5! Please check the tutorial page for updated tutorials on this topic!
The CH3SNAS has two internal clocks:
a real-time hardware clock, which is similar to the chip in a wristwatch. It is powered by a battery inside the CH3SNAS and thus never stops.
a software clock, which runs only when the NAS is turned on.
Unfortunately, the software clock drifts from the hardware clock and after a few hours the drift get noticeable (e.g., 16s/hour = 4444 parts per million) and the NAS will show incorrect times for e.g. file modifications. But thanks to NTP (the Network Time Protocol) the clock can be synchronized to one of the atomic clocks on the Internet. The resulting absolute error will be only a fraction of a second (e.g. 10 ms; because of packet delays across the Internet) and the drift will essentially become zero.
Note that this tutorial requires an installed Fonz fun_plug!
Background Information
The time in the Linux Kernel is a standardized value. One day equals 10000 “ticks”, so one tick = 8.64 s. Most of the CH3SNAS drift about 16s/hour, wich equals a drift of 384 seconds or 44.444 ticks/day. This value has to be subtracted from the 10000 Ticks of the Kernel and has to be set as the new number of ticks per day. In our case this 10000-44.444 = ~ 9956 Ticks. As you can see, this value is only an estimation because the drift is an estimation. As it will take a lot of time to get the exact value for the ticks, you can simply estimate them and synchronize periodically with a timeserver to reduce the clock drift.
As you can see below, there are two choices for the synchronization. Regular synchronization via Cron should be chosen over using the NTP-Daemon as the latter seems to cause the following two lines in dmesg reappearing over and over again until the device gets restarted:
kernel: TWSI: mvTwsiStartBitSet ERROR - Start Clear bit TimeOut .
kernel: TWSI: mvTwsiStopBitSet ERROR - Stop bit TimeOut .
The Procedure
Time-Synchronization via Cron
Simply add the following lines to /ffp/etc/fun_plug.local, e.g. with nano:
# This removes firmware cronjobs that interfere with ntpd.
crontab -l|grep-vw'/usr/sbin/daylight'|grep-vw'/usr/sbin/rtc'| crontab -
#Now start the ntp every hourecho"1 * * * * /usr/sbin/sntp -r -P no de.pool.ntp.org">>/var/spool/cron/crontabs/root
# force a cronjob updateecho"root">>/var/spool/cron/crontabs/cron.update
Reboot the device.
Sidemark: If the NTP-Service has been deactivated before the restart.
NTP-Daemon
As described above, this method seems to cause the TWSI-problems and is here only for historical reasons. Probably due to the concurrent access to this Two-Wire-Serial-Interface by the ntp-daemon and the fancontrol.
Edit the /ffp/etc/ntp.conf to change the time servers to servers which are geographically close. You can search for them here.
Quick possibility: Change them to general ones:
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
With this configuration both clocks get adjusted to the German timezone. If you want to change the timezone, you have to edit the /ffp/etc/fun_plug.local.
The string for Germany is (also change the timeserver, as this one is for Germany):
Change it according to your Timezone. You can find possible ones in the appendix
Start the Service
You can now start the service manually or you can perform a reboot (it will be started during the bootup):
/ffp/start/ntpd.sh start
Finetuning
After a few hours you can find a file called /ffp/etc/npd.drift on you CH3SNAS. If the Value is +500 or -500, you have to adjust the number of ticks in the file /ffp/etc/fun_plug.local. fonz has set this to ”tick=9965”, which may be right for your device. If not, try reducing or incrementing this value to reduce the drift.
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.
Script
You have to download the Script for the Removal here
Installation and execution
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.
Responsibility
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 π
Benefits
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).
Technical synopsis
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.
Tested Devices
This Tutorial has been tested on various devices. Other devices may work, please leave a comment in case you have tested an additional device.
fun_plug (this is a text file, you probably have to right-click to save it to disk) Note: If you want to install fun_plug on the D-Link DNS-320/DNS-325/DNS-345, download this file: fun_plug
fun_plug.tgz (this is a 10 MByte “tarball” file, roughly the Linux counterpart of a Zip file)
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).
Option: view the fun_plug script
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
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.
Option: view ffp.log
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.
Connect via telnet
After rebooting, you need to connect to the NAS using a protocol called Telnet. Telnet allows you to “login” on a remote machine via a command line window.
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:
Host name (or IP address): use the name of the share (e.g. CH3SNAS) or its IP address (the factory default is 192.168.0.20)
Select Connection type “Telnet” (which defaults to port 23)
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.
Change root password
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):
passwd
Next, 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:
If 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:
Note: For the D-Link DNS-343, you need a different store-passwd.sh script. See DNS-343 store-passwd.sh
Note: For the D-Link DNS-320/DNS-325/DNS-345, you need a different store-passwd.sh script. See this entry for further details
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).
Activate SSH
Now activate SSH (secure shell: telnet has major security limitations). Such lines can best be copied line-by-line or together into PuTTY:
Note that executing 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.
Logging in using SSH
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
If the login was not successful, please check that you executed all necessary steps from above. If you still cannot login, please contact us in our forums.
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.
Now what?
Congratulations! With the last step, you’ve installed your fun_plug π
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.
Responsibility
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 π
Benefits
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).
Technical synopsis
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.
Tested Devices
This Tutorial has been tested on various devices. Other devices may work, please leave a comment in case you have tested an additional device.
fun_plug (this is a text file, you probably have to right-click to save it to disk) Note: If you want to install fun_plug on the D-Link DNS-320/DNS-325/DNS-345, download this file: fun_plug
fun_plug.tgz (this is a 10 MByte “tarball” file, roughly the Linux counterpart of a Zip file)
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).
Option: view the fun_plug script
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
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.
Option: view ffp.log
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.
Connect via telnet
After rebooting, you need to connect to the NAS using a protocol called Telnet. Telnet allows you to “login” on a remote machine via a command line window.
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:
Host name (or IP address): use the name of the share (e.g. CH3SNAS) or its IP address (the factory default is 192.168.0.20)
Select Connection type “Telnet” (which defaults to port 23)
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.
Change root password
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):
passwd
Next, 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:
If 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:
Note: For the D-Link DNS-343, you need a different store-passwd.sh script. See DNS-343 store-passwd.sh
Note: For the D-Link DNS-320/DNS-325/DNS-345, you need a different store-passwd.sh script. See this entry for further details
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).
Activate SSH
Now activate SSH (secure shell: telnet has major security limitations). Such lines can best be copied line-by-line or together into PuTTY:
Note that executing 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.
Logging in using SSH
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
If the login was not successful, please check that you executed all necessary steps from above. If you still cannot login, please contact us in our forums.
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.
Now what?
Congratulations! With the last step, you’ve installed your fun_plug π
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.
GNU Wget is a simple and powerful computer program that retrieves content from web servers, and is part of the GNU Project. Its name is derived from World Wide Web and get, connotative of its primary function. It currently supports downloading via HTTP, HTTPS, and FTP protocols, the most popular TCP/IP-based protocols used for web browsing.
Its features include recursive download, conversion of links for offline viewing of local HTML, support for proxies, and much more. It appeared in 1996, coinciding with the boom of popularity of the Web, causing its wide use among Unix users and distribution with most major Linux distributions.
Why replace the existing wget?
You may already have a version of wget installed because that was included in busybox , which was installed with fun_plug. But the standard GNU version, however, has a few features which the smaller busybox version doesn’t (such as support for HTTPS or user credentials). This package allows you to use all the features of the standard version.
Installation
In this tutorial we assume that the fun_plug 0.5 is already installed on the NAS and that you synchronized Uli’s repository:
Note that the first ls command will show the original symbolic link from wget to busybox. After installation of the package, ls will show a normal executable program:
-rwxr-xr-x 1 root root 207172 Oct 14 23:46 /ffp/bin/wget
Available commands
Documentation for wget is available at the GNU-Website.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking βAccept Allβ, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.