Template:ARM9 Freelink

=What to do after FreeLink is installed= Now that your LinkStation has successfully rebooted, there are some further tasks to do.

Login
Find your LinkStation on the network and open up an SSH session to it. In windows PuTTY is a good client


 * login:root
 * password: lspro

or


 * login:admin
 * password: admin

Please NOTE that if the linkstation re-starts itself 3 times then it goes into EM mode and therefore you will need to re-start it again before you can proceed. otherwise you may think that the process hasnt worked.

You should then see the following welcome screen:

_sudZUZ#Z#XZo=_        DDDD   EEEEEE BBBB   IIIIII  AAAA   NN   NN       _jmZZ2!!~---~!!X##wa       DD DD  EE     BB BB    II   AA  AA  NNN  NN    .     -]Xb/    ~    __#2(    One ARM ARM926EJ-Sid(wb) rev 0 (v5l) Processor, 128M RAM  -Zo;       +!4ZwaaaauZZXY'      266.24 Bogomips Total   *#[,        ~-?!!!!!!-~        LS-GL7D6    XUb;.                            )YXL,, +3#bc, BUFFALO INC. LinkStation series LS-GL(IESADA) admin@LS-GL7D6:~$

Cleanup / Fixes
Unfortunately there are some small issues with the ARM9-1.0rev2 release, but these are easy to fix. Some of the following changes are mandatory and are marked accordingly.

Don't forget to check out the Debian articles.

Emergency backdoor
For safety and also to provide a 'back-door' entry in the event of a problem, edit the file /usr/local/bin/initsw.sh and add the following lines to the file:

rm -f /etc/hddrootmode rm -f /boot/hddrootmode reboot

Fix hostname and /etc/hosts (mandatory)
Edit /etc/hostname to set your LinkStation Hostname, and make sure /etc/hosts is correct. The default Buffalo hostnames are LS-GLXXX (Pro) or HS-DHGLXXX (Live) where XXX are the last three characters of the MAC address (LS-GL7D6 is the default hostname of the system the FreeLink distribution was developed on). You will find the MAC address on a label on the bottom of the LinkStation.

You must also make sure that /etc/hosts contains the alias "localhost" for 127.0.0.1, i.e., a line: 127.0.0.1 localhost.localdomain localhost

or

127.0.0.1 localhost.localdomain localhost $HOSTNAME

where $HOSTNAME is what you put in /etc/hostname (if the alias localhost is missing, the scripts /etc/init.d/kernel-server-nfs and /etc/init.d/openbsd-inetd will not work properly, because they call rpcinfo -u localhost .... .  A consequence is that nfs v3 gets disabled, and you unexpectedly only get nfs v2 which has limits on file sizes when files are transferred.)

See the Debian Manual for more details about /etc/hostname (e.g. domain is set via /etc/resolv.conf).

Activating your changed hostname without rebooting:

hostname --file /etc/hostname

Allow root login on serial console (if you use it)
root login on console is blocked if /etc/securetty is world-writable chmod 0744 /etc/securetty

Fix kernelmon script (mandatory check)
There can be an issue with the kernelmon script, that may cause a significant amount of system resources being used and/or having a non-working shutdown button.

This issue mostly occurs when using a newer Linux kernel from Buffalo (e.g from 2.10 Stock FW).

To find out if the kernelmon script is eating up your NAS performance, call "top" and check if the kernelmon script is always at the top of the list with a high CPU load. Normally the script has a CPU usage of 0%.

To determine whether you can fix it, compare the output of "ls /proc/buffalo" and "ls /proc/driver".

If the subdirectory kernevnt is in /proc/buffalo, make this change; if it is in /proc/driver, do not. (Without it, things like the shutdown button might not work.)

This is to ensure that the micon interrupt device is pointing to the correct location in the /proc virtual filesystem that is created by the kernel when it is running.

To fix the script do the following: The 2.6.12.6 buffalo kernel (the 2.06 LSLIVE firmware and the Freelink-supplied kernel) uses /proc/driver/kernevent while the 2.6.16.16 kernel (the 2.10 LSLIVE firmware) uses /proc/buffalo/kernevent
 * look in the file /usr/local/sbin/kernelmon script: find a line containing "cat /proc/driver/kernevnt", and change it to "cat /proc/buffalo/kernevnt".
 * if you needed to make this change, reboot your NAS for the change to take effect

Setting timezone (mandatory check)
To get the correct times for your files and schedules you have to set the correct timezone for the system and the users.

a) for the system in general dpkg-reconfigure tzdata # otherwise use tzconfig, which is deprecated

b) for the user (e.g. root, admin, etc.) tzselect
 * 1) then copy/add the given line to the user's .profile in his home directory (e.g. TZ='Europe/Berlin'; export TZ)
 * 2) if .profile is not available for the user, then just create it (check permissions afterwards)

c) UTC check grep -e 'UTC' /etc/default/rcS It should say "UTC=yes" which is the default for Linux/Unix.

Only reason to set it to "UTC=no" is if your machine is running Linux/Unix and a non-UTC-based system (non-UTC-based = local time based). For instance Windows defaults to local time rather than UTC. So if you either use these systems separately side-by-side or via a virtual machine (e.g. Debian on Windows), then "UTC=no" will help having the correct time in both systems.

Update of the Debian repository and packages
You can update your system with APT.

It is recommended, even by the Debian maintainers, to use APTITUDE instead of APT-GET, as it keeps track of automatically installed packages and does smarter and safer decisions when upgrading to a new release. Keep in mind that whenever you are told to use apt-get for maintaining packages, that you replace it with aptitude.

Note as the current UDEV package requires a higher kernel than the 2.6.12.6 kernel of Freelink ARM9 1.0rev2, the UDEV package should not be updated. Therefore hold the current UDEV package back, to avoid upgrades of it.

Holding back for aptitude:

aptitude hold udev

Another way is dselect of the dpkg-package

echo -e "udev hold" | dpkg --set-selections
 * 1) When updating you HAVE to use
 * 2) apt-get dselect-upgrade
 * 3) aptitude dselect-upgrade

A third way would be to pin it via apt.

To get the latest versions of your installed software, first update the package list and then upgrade the packages.

As there are some scripts as left overs from the hotplug package inside the Freelink image, just purge the hotplug package before upgrading. (Maybe when the Freelink image was build the hotplug package was only removed and not purged.)

aptitude update aptitude purge hotplug aptitude upgrade (or aptitude dselect-upgrade if you choosed dselect)

If the internet connection does not work, please check your /etc/resolv.conf and your network settings in /etc/network

If the debian server hangs, you may need to edit /etc/apt/sources.list to change the server, for example from "ftp.uk.debian.org" to "ftp.us.debian.org"

If you did a fresh install of Freelink ARM9-1.0rev2 you will get the following error message when updating via apt:

W: There is no public key available for the following key IDs: B5D0C804ADB11277 W: You may want to run apt-get update to correct these problems

Then you have to retrieve the public key from the pgp server with this command

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys B5D0C804ADB11277

If your behind a firewall, but can access the internet via port 80

gpg --fetch-keys "http://pgpkeys.pca.dfn.de/pks/lookup?op=get&options=mr&search=0xB5D0C804ADB11277"

Next add it permanently to your root keyring with

apt-key add /root/.gnupg/pubring.gpg

You should get an OK message, next retry to update.

To speed up the process of checking for updated packages, you can easily update apt's repository list with a cron job, which is already prepared by Debian. Just add the following lines to /etc/apt/apt.conf, then your NAS will update the list every morning and you can directly use the upgrade command.

APT {  // Options for /etc/cron.daily/apt Periodic {    // same as defining APT::Periodic::xyz Update-Package-Lists 1 ; Download-Upgradeable-Packages 1 ; Autoclean 1 ; }; };

If the file /etc/apt/apt.conf does not exist, then just create it via the following command and add the lines from above.

touch /etc/apt/apt.conf

To undo the holding of UDEV use

aptitude unhold udev

or for dpkg's dselect

echo -e "udev install" | dpkg --set-selections

Set your Locale
You may notice when installing from apt or in other situations that there are some errors about not having the correct locale.

You can fix this with

aptitude install locales

This will give you a few choices on what to set for your default locale.

Static IP address
You can set up a static IP address instead of DHCP. This is done by editing /etc/network/interfaces.

If you also want to state your local DNS server (e.g. your router) and local domain, then you can not directly modify /etc/resolv.conf, as Freelink 1.0rev2 comes with the resolvconf package installed. Instead you have to define all DNS data in /etc/network/interfaces for each interface.

/etc/network/interfaces:

auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.0.100 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 gateway 192.168.0.1 dns-nameservers 192.168.0.1 dns-domain lan
 * 1) iface eth0 inet dhcp

NOTE: Do not blindly copy these lines into your file, rather choose the correct IP address and additional information based on your local network settings. If you don't know what these are, then don't modify this file.

To activate your changes without rebooting:

invoke-rc.d networking restart

To see that the change of the domain has occured:

hostname -f

For more information about DNS settings via resolvconf see the README file:

zcat /usr/share/doc/resolvconf/README.gz

Customized Partitions
You may not have enough space to install all the Applications you want to. If you have customised partitions, you will have enough space to install other applications (like webmin) Here you can see, how to do this:


 * Custom Partitions on the LS Pro

or


 * Resizing the system partition with parted magic live cd

Webmin (webbased administration)
Look here for instructions on how to install webmin: You can reach Webmin via: https://YOUR_LINKSTATION_IP:10000/
 * Webmin to remotely administer your LinkStation

Updating your kernel (not always necessary)
For users who want to prepare the Linkstation for an updated kernel:
 * Changing the FS Type of the Root Partition

Limit and/or remove the "guest" account
Note that the Guest account is a common attack point. This account can be used for system testing, but can be compromised due to default password in a Debian install. Further the Guest account by default in Debian 2.6 is capable of executing BASH scripts allowing system reconfiguration.

You can simply lock the Guest account ...

passwd guest -l

Change and protect your passwords
Anyone who can see your NAS on the network can of-course log into it as the root user (=full control!) with the default password, and make it their own.

Therefore change the passwords for the users root and admin using (as root):

passwd passwd admin

Please do not use the same password for both accounts.

As /etc/passwd and /etc/group must be world-readable the passwords in them can be read and cracked. Therefore it is recommended to turn on shadow passwords, so only user root can see the encrypted passwords.

pwconv (for user passwords) grpconv (for group passwords)

You should avoid group passwords, as those shared passwords are a typical security breach.

It is just as important to change the ssh server keys (see section below).

Limit which users and IPs can have access to SSH and su/sudo
If you don't want the trouble of using a ssh key pair (see below) then limit the range of IP and users that can have ssh access vis the sshd configuration file /etc/ssh/sshd_config.

Before your box has an active ssh port open to the internet, initially it is recommended that you basically shut off root access and only allow access via su or sudo for given users. This makes access to the box narrow and root execution via two passwords, via ssh and then su/sudo.

You can add the following line to /etc/ssh/sshd_config to disable root ssh access.

PermitRootLogin no

... and then restrict access to su via execution access of /bin/su.

For sudo - you can restrict user execution access via the sudo configuration file /etc/sudoers.

Create Unique SSH server keys for your machine
Due to the way that Freelink is currently installed, you will be using the ssh server keys that are distributed with the freelink archive. As these are publicly available, unless you change these, then your Linkstation will be vulnerable to both "Man-In-The-Middle" attacks - whereby someone impersonates your machine, and passes data along to the real machine (recording, and potentially altering data as they do so), and eaves-dropping (whereby they can decode the encrypted ssh data, as long as they can read the data that is being exchanged between the linkstation, and the machine which they are logging in from).

rm /etc/ssh/*host*key* dpkg-reconfigure openssh-server

Whereupon you should see:

Creating SSH2 RSA key; this may take some time ... Creating SSH2 DSA key; this may take some time ... Restarting OpenBSD Secure Shell server: sshd.

After this is finished, you can log out, and log back in again. When you try to, you will see a message like:

$ ssh root@linkstation @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @   WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is e2:74:96:43:fd:21:57:9e:94:ca:fa:8b:64:05:0c:23. Please contact your system administrator. Add correct host key in /home/user/.ssh/known_hosts to get rid of this message. Offending key in /home/user/.ssh/known_hosts:56 RSA host key for linkstation has changed and you have requested strict checking. Host key verification failed.

You are seeing this message because you have changed the host key (if someone really was doing a man-in-the-middle attack with the old key, you wouldn't see this message, as they would have the correct key to not-trigger the error report). Remove the old key from your ssh known_hosts file (in this case line 56 of /home/user/.ssh/known_hosts), and log in again... This time it should proceed as normal.

Your Linkstation is now secure - ideally, you should not have placed the Linkstation on an untrusted network before you reach this stage.