To prevent that bug, i have developed a solution which is based on the idea of KyleK My Package replaces /bin/chmod by a script which checks if it is called with 777 and on a directory of the harddisks (/mnt/USB/USB* or /mnt/HD/HD*). If that happens, this is prevented. If the command is a normal one, it is executed.

Important Note: With Non-Dlink-Devices the installation is simply not executed, on these it is no issue to install that script as it simply doesn’t execute.

Now install the package from my repository (Attention: This will fail on OABI Devices as it is not required there! Simply skip this step then!):

slacker -UaA uli:uwchmod

Thats it

Hint: If you upgrade your firmware, you need to reinstall the script as it is removed during such a upgrade.

Related posts:

• D-Link releases updated Firmware 1.02 for the DNS-325
• D-Link releases updated Firmware 2.02 for the DNS-320
• Beta Firmware 2.01 Build 01 for the D-Link DNS-320 was released
• Beta Firmware 1.02 Build 01 for the D-Link DNS-325 was released
• Conceptronic CH3SNAS

slacker -UaA uli:uwcron
[[ -f /ffp/start/uwcron.sh.new ]] && mv /ffp/start/uwcron.sh.new /ffp/start/uwcron.sh

As soon as this is installed, you can start with the configuration. The configuration files should be created in /ffp/etc/cron.d/. These could look like this:

*/5  * * * * /tmp/uwfancontrol.sh

When all configuration files are created, the service can be started. This works as with all other services:

chmod a+x /ffp/start/uwcron.sh
/ffp/start/uwcron.sh start

Now you should see your entries in crontab:

crontab -l

If the device is rebootet, all entries from these files in /ffp/etc/cron.d/ would be copied into crontab. if you made a change to a file, you could also just restart the service instead of the complete NAS:

/ffp/start/uwcron.sh restart

Questions?

Related posts:

• Tutorials
• Fixing the NTP Time Synchronization with Fonz funPlug 0.5 for CH3SNAS, CH3MNAS, DNS-323 and many more
• Syntax Highlighting with nano – nanorc for log-stuff
• Installation of the Conceptronic fun_plug on the Conceptronic CH3HNAS
• Removing the Fonz fun_plug

Download

Go to the Oracle Page and choose “ARMv5 Linux – Headless”. Now you will be redirected to a survey, where you have to enter Name, Prename, Mail, Organization and Role. Then you will receive the download-Link via E-Mail. Click on this Link and accept the license agreement.

Copy the downloaded file (in my case its name was ejre-7u6-fcs-b24-linux-arm-sflt-headless-10_aug_2012.tar.gz, but that is subject to change) to the NAS. I’ve copied it to /mnt/HD/HD_a2/, please adapt the following commands if you copy it elsewhere.

Installation

First create a directory:

mkdir -p /ffp/opt/java

Then unpack the archive from before:

cd /ffp/opt/java
tar xvzf /mnt/HD/HD_a2/ejre-7u6-fcs-b24-linux-arm-sflt-headless-10_aug_2012.tar.gz

Now create a link to the unpacked directory (“ejre1.7.0_06″):

ln -s ejre1.7.0_06 jre

Now put it permanently into the environment variables:

echo "export PATH=/ffp/opt/java/jre/bin:\$PATH" >> /ffp/etc/profile.d/java.sh
chmod a+x /ffp/etc/profile.d/java.sh

Logout and Login into the NAS.

Installation-test

Check if it works:

java -version

This should display something like this:

java version "1.7.0_06"
Java(TM) SE Embedded Runtime Environment (build 1.7.0_06-b24, headless)
Java HotSpot(TM) Embedded Client VM (build 23.2-b09, mixed mode)

Related posts:

• Tutorials
• Syntax Highlighting with nano – nanorc for java
• Installation of the Conceptronic fun_plug on the Conceptronic CH3HNAS
• Updated Tutorials for the Installation of fun_plug 0.5 on the D-Link DNS-320 Sharecenter Pulse
• store-passwd.sh for the D-Link DNS-320 Sharecenter Pulse

Related posts:

• Twitter Updates for 2012-01-10
• Twitter Updates for 2012-06-25
• Twitter Updates for 2012-06-27
• Twitter Updates for 2012-01-08
• Twitter Updates for 2012-06-17

Related posts:

• Twitter Updates for 2012-01-10
• Twitter Updates for 2012-06-25
• Twitter Updates for 2012-08-12
• Twitter Updates for 2012-01-08
• Twitter Updates for 2012-06-17

Related posts:

• Twitter Updates for 2012-01-10
• Twitter Updates for 2012-06-27
• Twitter Updates for 2012-08-12
• Twitter Updates for 2012-01-08
• Twitter Updates for 2012-06-17

Related posts:

• Twitter Updates for 2012-01-10
• Twitter Updates for 2012-06-25
• Twitter Updates for 2012-06-27
• Twitter Updates for 2012-08-12
• Twitter Updates for 2012-01-08

Contents

• Packages
  • Choosing the download sites
  • Package management
    • Initial package updating
    • Package installation
    • Package configuration
    • Package updating
    • Package removals

Packages

Choosing the download sites

Before you can download and install the packages through slacker, you need to activate a “site” from where you can download the site. For your convinience, there is a script available from Uli called “uwsitedownloader” which you can use to download a list of sites through a central tool. Please follow this link
for the installation.

Package management

Package management is done using two programs by fonz called “slacker” and “funpkg“. We will be concentrating on slacker as this tool is easier to use. funpkg is for manual installation of packages, but this is often only necessary for developers as the provided repositories can be used via slacker. Typing “slacker” on the command line lists the flags and options that it supports:

slacker options pattern...
Options:
        -U      Update package lists
        -C      Clear cache
 
        Install, reinstall or upgrade:
         -a     List all available packages
         -I     List available packages that are installed and up-to-date
         -i     List available packages that are not installed
         -u     List available packages that differ from the installed version
 
        Remove packages:
         -r     Remove installed packages
         -o     List installed packages not present at sites
 
        -A      Pre-select all packages in the dialog
        -F      Do not apply ignore list
        -c      Print report to stdout, no menu

Important: once you start using slacker 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/sshd.sh

Initial package updating

After the Installation of uwsitedownloader you need to update the repository data using slacker:

slacker -U

This will lead to a output like this (or similar):

Now you can proceed with the next steps.

Package installation

After the repository data has been downloaded, you can install packages by using slacker again. This time you can choose between various installation modes using the commandline parameters “-a”, “-i” and “-u”. In the following text i will show you how to install new packages using “-i”:

slacker -i

This will show a screen similar to this one:

To choose a package, carefully select the newest version (some providers of repository provide multiple versions of packages) and hit the spacebar to select one. This will then fill the field “[ ]” before the package name to “[*]“. You can select multiple packages. After the selection you can hit “ok” and slacker will download and install the packages.

Personal sidenote: After a new installation of fonz’ funplug 0.7 i first install all packages of fonz to have the newest versions. This can be achieved using:

slacker -aA s:

I then check though the list once and install the packages.

If you want to install packages only from one site you can use a pattern. This pattern can be found in the list of packages:

So to see all packages from fonz simply enter:

slacker -a s:

If you want to install a certain packages you can also use the pattern. For example check for nano:

slacker -a nano

This will show you my and KyLeKs package for nano. Of course this could also lead to different versions and so on.

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

Package updating

From time to time, repository owner update the packages in the repo. You should also check if there are updates to the packages available as these might mitigate security risks. To do the update, you first update the repository data (see above) and then check with slacker for the list:

slacker -u

Be careful: always check if the installed version (which is shown at the bottom of the dialogue) is really older than the version that is shown as “upgrade”.
This dialog will look like this:

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 here 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 sshd.sh:

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

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 NAS).

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

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

This gives all users (a) the right to execute (x) the file /ffp/start/sshd.sh (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 samba.sh
-rw-r--r-- 1 root root  229 Apr 24 20:16 smartd.sh
-rwxr-xr-x 1 root root  971 Jul 29 16:30 sshd.sh
-rw-r--r-- 1 root root  383 Aug 12 22:17 syslogd.sh
-rw-r--r-- 1 root root  169 Aug 12 22:17 telnetd.sh

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

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:

slacker -r

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/somedaemon.sh files. The example (from the file /ffp/start/sshd.sh)

# PROVIDE: sshd
# REQUIRE: LOGIN

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

Related posts:

• Tutorials
• Installation of Optware on the D-Link DNS-320, DNS-321, DNS-325, DNS-343, DNS-345 and Conceptronic CH3MNAS
• Installation of Optware on the D-Link DNS-323 and Conceptronic CH3SNAS
• Installation of Twonkymedia Server 6 on the Conceptronic CH3SNAS and the D-Link DNS-323
• uwcron: Cron for the fun_plug

Contents

• Daemons
  • What are Daemons?
  • Starting Daemons manually
  • Stopping Daemons manually
  • Permanent activation of Daemons
  • Permanent deactivation of Daemons

Daemons

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 telnetd.sh
sh telnetd.sh status
sh sshd.sh
sh sshd.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.

Starting Daemons manually

You can start every daemon manually by executing

sh /ffp/start/desired_daemon.sh start

Stopping Daemons manually

You can stop every daemon manually by executing

sh /ffp/start/desired_daemon.sh stop

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 desired_daemon.sh

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/sshd.sh ...
Starting /ffp/sbin/sshd

for daemons that were started.

Permanent deactivation of Daemons

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

chmod a-x desired_daemon.sh

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/telnetd.sh inactive
* /ffp/start/sshd.sh ...
Starting /ffp/sbin/sshd

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

Related posts:

• Tutorials
• Installation of Optware on the D-Link DNS-320, DNS-321, DNS-325, DNS-343, DNS-345 and Conceptronic CH3MNAS
• Installation of Optware on the D-Link DNS-323 and Conceptronic CH3SNAS
• Installation of Twonkymedia Server 6 on the Conceptronic CH3SNAS and the D-Link DNS-323
• uwcron: Cron for the fun_plug

Related posts:

• Twitter Updates for 2012-01-10
• Twitter Updates for 2012-06-25
• Twitter Updates for 2012-06-27
• Twitter Updates for 2012-08-12
• Twitter Updates for 2012-01-08