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 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+xon e.g.
Initial package updating
After the Installation of uwsitedownloader you need to update the repository data using slacker:
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”:
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.
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
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
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
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:
But please beware of a number of pitfalls:
- 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.
- This may overwrite access privileges you made to files (particularly to the scripts that start daemons in folder
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 you want to (e.g. temporarily) disable execution of a server package, see the discussion on Daemons. To remove a package completely, use:
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
# PROVIDE: sshd # REQUIRE: LOGIN
suggests that you shouldn’t remove the
LOGIN package because it is required to run the sshd (=OpenSSH) package.