EnableCustomStartupScript

From NAS-Central Sitecom Wiki
Jump to: navigation, search

This is now more ore less obsolet, as Sitecom has implemented the package mechanism with Firmware 2.4.15. It is easy to create a simple package which simply calls a script, which is then doing whatever you like. Wait for a package to start a user script.


This page describes how to enable a custom startup script which is usable for example for changing the default fan control settings or enabling SSH. Three methods are described, with the first one not involving any kind of flashing

Contents

Method 0

Note 0: This method maybe looks less risky because it does not involves reflashing. That is probably true, but less risky does not meen safe.

Note 1: The change described here might broke the services page from web interface and/or get disabled after using that webpage.

The only location where changes are not overwritten are the config files in mtd4. And there is at least one file there which is not read but sourced, and sourced during system initialization: /etc/sysconfig/config/service. So any change there will be kept accross restarts, and also executed. Appending a line like

/bin/logger "$0 - service file sourced"

will have visible effects in, for example, /var/log/user. But this file is actually sourced many times, not only at startup, so we need to protect it against this. A very simple flag is enough for this

test -f /tmp/.done || {                                   
  /bin/logger "$0 - service file sourced"                                            
}               
touch /tmp/.done

The main disadvantage of this method is that our own commands run within the system initialization, instead of when standard init finishes, as the methods below. But we can take advantage of the fact that the shell scripts are interpreted ones, and that the file is actually readed instead of loaded. This means in particular that we can usually append commands to a running script. So let's go for a bit more complex block.

test -f /tmp/.done || {
  echo '/bin/logger "$0 - reached end of file"' >> /etc/init.d/rc.sysinit
}
touch /tmp/.done

And now we see the hit in logfiles right when the initialization file executin ends. In a strict sense we don't need to protect about multiple appends, because the initialization usually runs only once, and in case it reruns on a live system, there are many chances that the device get unstable much before finishing the rc.sysinit file. But protection is not bad even when you believe you don't need it.

Method 1

Note: This method assumes you're running a *nix-like system (Linux, ...) The firmware (2.3.24) that can be downloaded from the Sitecom website has the '.bin' extension, but fortunately, is a plain TAR file:

$ file SitecomNas.2.3.24.bin
SitecomNas.2.3.24.bin: POSIX tar archive (GNU)

nice! Let's give it a spin then:

$ tar xvf SitecomNas.2.3.24.bin
uImage.bin
uImage.md5sum
bootfs.bin
bootfs.bin.md5sum
filesystem.bin
filesystem.bin.md5sum

Alrighty, that means kernel image, boot file system and the root file system, or something similar and their md5sums. Let's see what we have here:

$ file bootfs.bin
bootfs.bin: gzip compressed data, from Unix, last modified: Wed Feb  3 04:08:19 2010, max compression

Ok, that's a gzipped something, let's try:

$ mv bootfs.bin bootfs.bin.gz
$ gunzip bootfs.bin.gz
$ file bootfs.bin
bootfs.bin: Linux rev 1.0 ext2 filesystem data, UUID=7f2e7b7d-3b85-4294-b661-18bd61daf8eb

Okidoki, a plain EXT2 loopback, you're making this easy, guys! Let's loopback-mount it, to see what's in there:

$ mkdir bootfs
$ sudo mount -o loop bootfs.bin bootfs
$ cd bootfs
$ ls
bin  dev  etc  home  lib  linuxrc  mnt  proc  root  sbin  sys  tmp  usr  var

Hmm, this is nice, there must be something we can change in /etc and off we go, right? Unfortunately, there is something in the filesystem.bin that makes that harder. Basically, you'd want to modify /etc/sysconfig/config/service to set ssh=Enable, but that didn't work for me (possibly because I was playing around with the firmware, I'm not sure). I tried to loopback-mount filesystem.bin, but that is in some format that I didn't feel like digging into any further.

In short, what I've done, was to modify the /etc/init.d/rc.sysinit to execute a user script as a last stage (rc.sysinit doesn't get overwritten by something from filesystem.bin). First, I formatted the 1TB drive and created a Windows share (PUBLIC). In this share, I put a text file containing shell script commands and added

/bin/logger "==================="
. /home/PUBLIC/do

as last lines of the rc.sysinit file. The logger-line isn't required, but it helps you debugging stuff via the web interface (one of the logging tabs lists all of this). I put a modified of the 'service' file on the share as well:

smb=Enable
ftp=Enable
http=Enable
LANGUAGE=en
btpd=Enable
daapd=Enable
crond=Enable
ssh=Enable 

Notice that last line. Now, in the 'do' file, I put

/bin/logger "Copying services conf back to sys"
cp /home/PUBLIC/service /etc/sysconfig/config

Now, the only thing to do, was to get the rc.sysinit to be executed.

Reconstruct the firmware

(WARNING: doing this and trying to flash it into your NAS is done AT YOUR OWN RISK, YOU HAVE BEEN WARNED. I take NO RESPONSIBILITY for bricked devices, don't water your plants, feed your pets etc.)

Unmount the file system, gzip it, md5 it, tar it and off you go. In teeny-tiny steps:

$ sudo umount bootfs
$ gzip --best bootfs.bin
$ mv bootfs.bin.gz bootfs.bin
$ md5sum bootfs.bin > bootfs.bin.md5sum
$ tar cvf MyOwnFirmware.bin uImage.* bootfs.bin* filesystem.bin*

Now you should have a MyOwnFirmware.bin that you can serve via the web interface of the device. If the MD5SUMs don't match, the web interface will complain. Remember, you're on your own if you do this!

Taken from http://md253.blogspot.com


Method 2

As the startup scripts are located in the nonwritable area of the bootfs, we need a vehicle to start anything we like.

For this purpose, I created a new directory in /etc/sysconfig/config called custom. Inside of this directory I placed a new startup script called rc.local.

The complete path of this file is:

/etc/sysconfig/config/custom/rc.local

So with this script we can do literally anything we like with the NAS, for instance - tuning the fan speeds or enabling swap space.

Here is a short example of such a script for tuning the fan speed:

#!/bin/sh
#rc.local file. Will get executed after normal startup.

#Fan Control
#Silent Settings.
echo 1 > /sys/module/mp_thermAndFan/parameters/output_flag
echo 50 > /sys/module/mp_thermAndFan/parameters/cold_limit
#echo 1 > /sys/module/mp_thermAndFan/parameters/hot_limit
#echo 1 > /sys/module/mp_thermAndFan/parameters/min_fan_speed_ratio

Okay - this is only for example and for testing, if it works. You will recognize that it works if the fan now is silent :)

Okay, now we need to find a way to run this rc.local file. And this is a little bit dangerous. You have to do it with every new firmware from SiteCom, as the firmware overwrites the files you changed with new ones.

WARNING: I DO NOT TAKE ANY WARRANTY THAT THIS WORKS. YOU ARE CHANGING THE SYSTEM AT YOUR OWN RISK AND MAY LOOSE THE COMPLETE NAS AND WARRANTY FROM SiteCom. SO PLEASE BE VERY CAREFUL!

Okay, the normal startupscript is /etc/init.d/rc.sysinit. Unfortunately we cannot change the file directly, as it is in a nonwritable filesystem. Anything you change will be lost after the next reboot.

What do we need to prepare everything?

1. The official Firmware from SiteCom. You need the same release which is running on your NAS right now. Do not try to patch a newer Firmware with an older running system. 2. A gzip compatible software (like 7zip) 3. A folder accessible from your PC

Okay ... then lets go :)

1. Create a directory on your NAS, which will contain your patched firmware.

mkdir /home/PUBLIC/flash

2. extract the contents of the firmware file to that directory with 7zip

You will get a file with a name like SitecomNas.2.3.33.bin. This file is a tar file containing the different parts of the flash rom.

3. untar the bin-file

tar -xf SitecomNas.2.3.33.bin

The result would look something like this:

/home/PUBLIC/flash/2.3.33 # ls -l
-rw-r--r--    1 nobody   nogroup    577564 Aug 10 12:56 bootfs.bin
-rw-r--r--    1 nobody   nogroup        45 Aug 10 12:56 bootfs.bin.md5sum
-rwx------    1 nobody   nogroup   5136384 Aug 10 12:56 filesystem.bin
-rw-r--r--    1 nobody   nogroup        49 Aug 10 12:56 filesystem.bin.md5sum
-rw-r--r--    1 nobody   nogroup        52 Aug 10 12:56 project.txt
-rwxr-xr-x    1 nobody   nogroup   2036524 Aug  9 06:18 uImage.bin
-rw-r--r--    1 nobody   nogroup        45 Aug 10 12:56 uImage.md5sum

4. unzip the bootfs.bin file The bootfs.bin file contains a compressed image of an ext2/ext3 filesystem. It contains the root filesystem of the nas.

Unfortunately, the sitecom NAS does not offer a gzip tool, so you have to use anything on your PC to uncompress ist. I used 7zip. Rightclick on the bootfs.bin file, choos 7zip->extract here.

You will get a new file bootfs.

5. mount the file, so that we can change the contents.

mount -o loop bootfs /mnt

Now we have the root filesystem mounted on /mnt and can play around.

6. edit the /etc/init.d/rc.sysinit file, that it will start our rc.local script

vi /mnt/etc/init.d/rc.sysinit

Add the following lines to the script, after the line "service_mount_hdd"

[ -f /etc/sysconfig/config/custom/rc.local ] && \
   /etc/sysconfig/config/custom/rc.local

Then save the file.

This enables to run the rc.local script, if it exists. The complete procedure enables us to easily change back to the factory settings of the device, by renaming the rc.local file to something else. If it is not there, the NAS will carry on with its normal startup sequence.

7. unmount the /mnt filesystem again

umount /mnt

8. gzip the bootfs file

Use 7zip again to add the bootfs file to a new archive. The archive must be of type gzip with normal compression settings.

7zip will create something like bootfs.gz

9. flash the changed bootfs.gz to the flash

The last step is to write the changed version of the bootfs to the flash partition 2.

WARNING AGAIN - if you did anything wrong, it will brick your NAS. Also make sure to write the correct partition AND make also very sure, that the size of the bootfs.gz is not bigger than 576k. Otherwise you will overwrite parts of the /usr filesystem.

THIS IS DANGEROUS IF YOU ARE NOT FAMILAR WITH SUCH PROCEDURES.

Okay - you want it, here we go:

/bin/flashcp bootfs.gz /dev/mtd2

This will copy the changed bootfs to the correct partition of the flash chip.

After this completed correctly, reboot and hope the best