Strict Standards: Declaration of Doku_Renderer_metadata::table_open() should be compatible with Doku_Renderer::table_open($maxcols = NULL, $numrows = NULL, $pos = NULL) in /home/tinycore/wiki.tinycorelinux.net/inc/parser/metadata.php on line 24

Strict Standards: Declaration of Doku_Renderer_metadata::table_close() should be compatible with Doku_Renderer::table_close($pos = NULL) in /home/tinycore/wiki.tinycorelinux.net/inc/parser/metadata.php on line 24

Warning: Cannot modify header information - headers already sent by (output started at /home/tinycore/wiki.tinycorelinux.net/inc/parser/metadata.php:24) in /home/tinycore/wiki.tinycorelinux.net/inc/actions.php on line 180
wiki:server - Tiny Core Linux Wiki

Welcome to the Tiny Core Linux Wiki at tinycorelinux.net!

Introduction

This article discusses, how tiny core linux can be set up as a file server, for example for home entertainment systems. It covers starting, shutting down, and administrating the server remotely as well as providing file transfer via FTP and SMB for Windows network shares. Further on, the usage of disk arrays is shown.

The server is built up from Tiny Core Linux, software packages (Tiny Core Extensions), and configuration files. This entire set is refered to as the server firmware below and completely stored on a USB pen drive. Doing so separates the server firmware from the data, which is stored on hard drives. This simple encapsulation of the server firmware enhances the following scenarios:

  • Server Firmware Updates are performed by installing a new Tiny Core Linux version and / or software to another USB pen drive. In case, the new firmware proves not to perform well, a downgrade can be achieved by simple replacing the new USB pen drive by the old one.
  • Inter Server Data Transfer is achieved by removing a hard drive from one server and adding it to another.
  • Server Farms can be built up quickly by copying the USB stick containing the firmware.

This document is not supposed to give a detailed insight into each of the technologies discussed. Instead, the intension is, to provide an overview, which is detailled enough, to make an experienced reader understand the internals. For details, refer to the man pages of the commands noted below.

General Considerations

Reboot and Shutdown

There are two useful command line commands in Tiny Core Linux, which are used quite frequently when setting up a server:

  • sudo reboot to reboot the machine and
  • exitcheck.sh to shutdown the machine.

The preferred way of shutting down is calling exitcheck.sh rather than poweroff, as exitcheck.sh executes the /opt/shutdown.sh script before powering down. The /opt/shutdown.sh script is taken advantage of in this article to deinitialize configured servers and raid systems before power down.

Shutting down and rebooting can be initiated remotely, once the telnetd server is running (see below for details).

Data Persistency

USB drives typically only allow a limited number of write accesses. Therefore, if booted from USB drive, Tiny Core Linux typically will only write changes of the user directories and the config files on request. This is achieved by calling sudo filetool.sh -b. The files, which are written back to the pen drive, are listed in /opt/.filetool.lst.

Editing Files

Tiny Core Linux provides a simple, but powerful command line editor vi. Wherever the term editing a file is used below, probably the best choice is to open it by typing

sudo vi <path>

where <path> is the file path. The cursor can be moved within the document using the cursor keys. To change the document, type 'i' (short for insert) or 'a' (short for append) and then keep typing any characters, which should be inserted. To leave edit mode, hit the 'escape' key. To delete a character, either strike 'backspace' or the 'delete' key. To delete an entire line, press 'd' twice. To write the changes to the file, hit the 'w' key followed by 'enter'. To close the editor, type ':q' and hit enter. If changes have to be discarded, type ':q!', followed by enter.

Security Considerations

Security is a serious matter in networks. A network is generally spoken an untrusted environment, where an attacker in the middle between the two endpoints of a connection can read and manipulate the data exchanged. None of the servers discussed in this article use encryption. Therefore, their usage should be limited to non-confidential data or only in applications, where access to network resources is limited by technological precautions. In many cases, such a precaution may be to only use a local network within a well confined area, such as a building, where access is only granted to trusted persons.

Due to the reasons mentioned above, never use passwords in an unsecured network. Passwords may be intercepted and then abused.

Preperations

Installing Required Packages

Packages are installed using the tce-load command as follows:

tce-load -wi <name of package>

Where <name of package> is the name of the package, that shall be installed. The usage of the following packages is discussed in this article:

  • inetutils-servers for remote access to the command line (required for shutting down the server) and for FTP.
  • ethtool for starting the server remotely via Wake-on-Lan.
  • mdadm for creating and using disk arrays.
  • samba3 for SMB network shares.
  • kmaps for using keyboard mapping others than US
  • getlocale for supporting languages others than English

Only packages are required, which are used. For example, mdadm does not need to be installed for a setup without disk arrays.

Registering Configuration Files for the Persistency Mechanism

For the purpose of this document, the /opt/.filetool.lst requires the following entries:

/etc/passwd

/etc/group

/usr/local/etc/samba/smb.conf

Configuring Network Access

A server is typically identified by two different properties: its name and its IP address. Both of them affect the kernel boot options required to boot the kernel from the USB pen drive. The server name is defined by the host=<name> argument, where name is the name of the server within the network. Tiny Core Linux will retreive an IP address dynamically from a DHCP server, unless the nodhcp option is provided. As servers should always be found under a known IP address, the usage of the nodhcp option is strongly encouraged. The kernel boot options, are contained in the /mnt/<drive>/boot/extlinux/extlinux.conf file, where <drive> is the system name of your USB pen drive.

Look for the line, that starts with ASSIGN and add the nodhcp and host=<name> options, if not already present. The static IP address must be assigned to the server on every startup. Therefore, the following lines are added to the /opt/bootlocal.sh file:

ifconfig eth0 192.168.0.2 netmask 255.255.255.0 up

route add default gw 192.168.0.1

echo nameserver 192.168.0.1 » /etc/resolv.conf

The ifconfig command starts the network adapter eth0 (you may need to adopt the number of the network adapter to your needs) and assigns it to the given IP address and netmask (again, the numbers given above are just an example and may need to be changed). The route line defines the default gateway. The echo command adds the line nameserver <IP> to the file /etc/resolv.conf, which is looked up, every time a URL is resolved. This line is required, as changes to the /etc/resolv.conf file are lost on every reboot of Tiny Core Linux.

The Super Server

The super server is a program, which listens in the background for incoming connections. Once a connection is established, it is passed on to a dedicated server, depending on the port of the connection. The super server is contained in the inetutils-servers package (see above) and used by the FTP server and the telnet server. To start the super server on startup, edit the /opt/bootlocal.sh and add the following line (preferably after the initialisation of the ethernet adapter, see above):

inetd /opt/initd.conf

This will start the super server using the configuration file /opt/initd.conf. For examples of configurations, refer to the sections, that describe the telnetd server and the ftp server, below. For shutting down the super super on system halt, edit the /opt/shutdown.sh and add

killall -9 inetd

Mounting the Hard Drives

An important design consideration of the server is, wether a disk array or a single disk is used. Refer to one of the following sections on information about how to prepare the hard drive(s). After preparation, the hard rives need to be formatted by invoking

mkfs.ext4 <name>

where <name> is either the name of the disk (for the single disk approach) or of the raid volume (for the disk array approach). To mount the disks on every boot, the following lines must be added to /opt/bootlocal.sh:

mkdir /mnt/server

chmod 777 /mnt/server

mount <name> /mnt/server

To unmount on power down, add umount /mnt/server to /opt/shutdown.sh. In case of the disk array approach, the line mdadm –assemble –run /dev/md0 –force <device1> <device2> has to be added to /opt/bootlocal.sh before the mount command.

Alternative 1: Single Disk

Using a single disk is the simplest possible approach. It must be configured using sudo fdisk <name>, where <name> is the name of the disk. To list all available disks, type fdisk -l. A typical sequence of key strokes in fdisk is:

  • 'o' + enter (create new partition table),
  • 'p' + enter (for the primary partition),
  • '1' + enter (for partition number one),
  • enter (to use the default start cylinder),
  • enter (to use the default end cylinder),
  • 't' + enter (to change the partition type),
  • '83' + enter (for Linux native partition),
  • 'w' + enter to write the partition table to the hard drive.

Alternative 2: Disk Array

Disk arrays can either be used for redundancy (i.e. to improve reliability) or to increase storage space, or both. The term raid is a common abbreviation for redundand array of disks. Among others, the following raid levels can be distinguished:

  • 0: all hard drives are combined to a huge logical hard drive. The total capacity is the sum of the capacities of each drive.
  • 1: all hard drives are used as safety copies of each other. The total capacity is the capacity of the smallest drive.
  • 5: a minimum of three drives is required. Parity information is schattered accross all drives. The total capaicity is the capacity of the smallest drive times the number of drives less 1. The parity information is used to restore damaged data.

To setup the hard drives for raid, instal mdadm (see above) and type

mdadm –create /dev/md0 –level=<level> –raid-devices=<number-of-drives» <drive1> <drive2>

where <level> is the raid level to be used (see list above), <number-of-drives> is the number of drives to be used in the array and <drive1>, <drive2> and so on is a list of drive names.

Setting Up the Servers

telnetd for Remote Administration

The telnetd server is contained in the inetutils-servers package (see above). It is started by the super server, which is also contained in this package (also see above).

Edit the telnetd configuration /opt/inetd.conf and add the following line:

telnet stream tcp4 nowait root /usr/local/sbin/telnetd telnetd -a off

If you are using IPv6 instead of IPv4, replace tcp4 with tcp.

After reboot (do not forget to write the changes to the pen drive), the server can be accessed using a telnet client. A common command line to invoke the telnet client (under both, Unix, and Windows), is telnet <IP>, where <IP> is the IP address of the server. The login name is tc and no password is required. From now on, every command (including editing configuration files with vi), can be issued from a remote machine.

ftpd for FTP Access

The ftpd server is contained in the inetutils-servers package (see above). It is started by the super server, which is also contained in this package (also see above).

Edit the ftpd configuration /opt/inetd.conf and add the following line:

ftp stream tcp4 nowait root /usr/local/sbin/ftpdd ftpd -A

If you are using IPv6 instead of IPv4, replace tcp4 with tcp. The option -A allows anonymous logins on the FTP server.

To allow the anonymous ftp user to login, the following line has to be added to /etc/passwd:

ftp:x:400:400:Anonymous FTP login:/mnt/server:/bin/false

This creates the user ftp with user id 400, group id 400 and the description “Anonymous FTP login”. The home directory is set to the /home/server directory and /bin/false disables logins. The new group id must be defined in /etc/group:

ftp:x:400:root,ftp

The new group ftp has the id 400 and contains the users root and ftp.

After reboot (do not forget to write the changes to the pen drive), the server can be accessed using a ftp client. A common command line to invoke the ftp client (under both, Unix, and Windows), is ftp <IP>, where <IP> is the IP address of the server. The login name is anonymous and typically the email address is used as password. Howeer, the password is not verified by the server, so any password will do it.

samba3 for Windows Network Shares

The SMB server requires the samba3 package (see above). It is started by adding the following line to the /opt/bootlocal.sh script:

/usr/local/etc/init.d/samba start

and stopped by adding the following line to the /opt/shutdown.sh script:

/usr/local/etc/init.d/samba stop

Unrestricted file access is gained by adding the following section to the /usr/local/etc/samba/smb.conf file:

[public]

comment = Shared Files

path = /mnt/server

browsable = yes

public = yes

writable = yes

guest ok = yes

To create the guest account with user name nobody and without a password, type

smbpasswd -an nobody

From this point, a user nobody without a password can logon to the SMB server and is granted full access.

For Windows clients, it is convinient, to add the following line to the section [global]:

map to guest = bad user

Windows clients will try to logon with their current user information. For these, access rights will typically be denied and Windows will prompt for a user name / password combination. The line above will change the SMB servers behavior to map any unknown user to the guest account, which is by default nobody.

Remote Power On

Unlike in most professional environments, in home entertainment environments servers are only used several hours per day. Shutting them down when they are not needed, greatly cuts into energy costs and therefore is desireable. However, starting the server may become inconvinient, as this can meen an additional user interaction. Furthermore, in many cases, the server may be located in a room other than the entertainment center, putting an additional pain into starting it manually.

This problem is solved with the Wake-on-Lan functionality on modern mainboards. Although most modern mainboards support Wake-on-Lan, in many cases this functionality has to be switched on by the BIOS settings. Refer the mainboard manual for details.

Wake-on-Lan is activated in Tiny Core Linux in the /opt/bootlocal.sh boot script by adding the following line

ethtool -s eth0 wol g

This line must be added after the ifconfig command and again the number of the network interface may need to be adapted. To power on the server, the wakeonlan tool can be used. This can also be called automatically, for example by the boot script of the home theater.

Conclusion

Tiny Core Linux provides a powerful approach for network servers. Installation is easy and the aibility to encapsulate the firmware on a USB pen drive gives a lot of options into the hands of system administrators. Future work to this document may include setting up a web server and setting it up for WebDAV, a secure networking protocol for sharing files over the internet.

Print/export