Tiny Core: Web Server 







Whys and Wherefores | Installation | Configuration | Log Files | Tweaks |

Configuring the applications

What & Where

Configuration files live in a number of places in the file system, and when/if you migrate to another platform you'll need copies of them for your new build otherwise you'll have to recreate them from scratch. Having been through the process a number of times I've finally decided to create and store these files in a directory /opt/conf and insert symbolic links to them from where they are expected to be. That way all I need to backup on my system are the /home and /opt directories and be sure in the knowledge I've got up-to-date copies of my data all the custom configuration files. (The rest of the system can easily be rebuilt).


Whenever dropbear is run it checks the directory /usr/local/etc/dropbear for its RSA and DSS keys. If they don't exist it will automatically generate them. When you connect to a host via ssh the ssh client will generally warn you if the keys the host is using are different to last time. To avoid this warning message we have to ensure our keys persist across reboots.

So to configure dropbear we need to do three things:

  1. Generate the key sets.
  2. Ensure the key sets persist across reboots.
  3. Ensure dropbear starts up automatically every time the system boots.

(1) happens when we run dropbear the first time, (2) is solved by adding the dropbear directory to /opt/.filetool.lst, and (3) is solved by adding the startup command to /opt/

Generate the keys...

tc@mirror:~$ sudo /usr/local/etc/init.d/dropbear start
Generating Dropbear rsa key... 
Generating key, this may take a while...
Public key portion is:
Fingerprint: md5 02:e8:61:61:00:bf:d2:0b:05:a1:f4:9f:ea:96:ac:0e
Generating Dropbear dss key... 
Generating key, this may take a while...
Public key portion is:
ssh-dss AAAAB3NzaC1kc3MAAACBAPY0WQLzQ5c8oiLxVAuRq9Jgj124GhDI9SJX3zi5QWkjgW
Fingerprint: md5 e0:80:d2:bf:af:31:af:9a:11:7f:f8:1b:3e:54:af:b4
Starting SSH server: Dropbear... 

...get them to persist....

tc@mirror:~$ echo usr/local/etc/dropbear >>/opt/.filetool.lst 
tc@mirror:~$ -b
Backing up files to /mnt/sda1/tce/mydata.tgz

...and dropbear to start...

tc@mirror:~$ echo /usr/local/etc/init.d/dropbear start >>/opt/ 


As with the other applications what we need to do here is

  • Create our samba configuration file in /opt/conf.
  • Create the symbolic link to it.
  • start samba and check that it works
  • edit the to create the symbolic link to the configuration file.
  • edit the file so samba starts on boot.

We start by either copying /usr/local/etc/samba/smb.conf to /opt/conf/smb.conf and working through that or just creating a new file /opt/conf/smb.conf with contents something like:

workgroup = PTOWERS
netbios name = mirror
security = share

comment = Data
path = /home/ptowers
force user = ptowers
force group = staff
read only = no
guest ok = yes

comment = Data
path = /home/idive
force user = idive
force group = staff
read only = no
guest ok = yes

The settings are pretty self-evident and totally insecure. The workgroup obviously matches up to whatever name your local Windows system uses - WORKGROUP if you haven't changed the default. The next entry creates a share on the network called parkytowers. This is mapped through to the local directory /home/ptowers. If anybody connects to it they can do what they want as they're automatically logged on as the user ptowers in the group staff. (I said there was zero security!).

The same applies to idive.

This works well for me on my local home network behind a firewall but has zero security associated with it. Anyone on the network can access these shared drives - but that's just me (my wife has no interest).

Having created the file we now need to create a link to it and also put the command into so that it is created on boot. Note: You need the link in place before you start samba, so this has to precede the samba start in the file.

To check things out:

sudo rm -f /usr/local/etc/samaba/smb.conf
sudo ln -s /opt/conf/smb.conf /usr/local/etc/samba/smb.conf
sudo /usr/local/etc/init.d/samba start

Explorer network view Having started samba you can then check from your Windows system (or whatever) to see if the drives have appeared on your local network.

If you open Windows Explorer and check the network you should be able to see you server on the network (mirror in this example). Click on it to the expand the view and should then see the shared drives you've set up and you should be able to map a network drive to it.

If it doesn't appear, or you can't access them, you'll need to track down what's wrong.

A first check is to run ps to see if samba is running. If it is you'll need to revisit the smb.conf file and play with your settings until you've got it right. (After editing the configuration file don't forget to restart the samba server).

Note: If you have problems you might want to skip ahead to the next section and read the bit about setting up samba's log files.

Once you're happy with it add the command set up the symbolic link to smb.conf and the command to start samba to /opt/

echo rm -f /usr/local/etc/samba/smb.conf >>/opt/
echo ln -s /opt/conf/smb.conf /usr/local/etc/samba/smb.conf >>/opt/
echo /usr/local/etc/init.d/samba start >>/opt/

Note: With the approach we've taken for the configuration file we don't have to add anything to the .filetool.lst file.

For completeness you can add /usr/local/etc/init.d/samba stop to the file.


These days with Tiny Core the perl executable is in /usr/local/bin. With my hosting companies perl sits in /usr/bin. Perl scripts - like shell scripts - always start with the path to the executable needed to run them. The easiest way to handle this is to leave the path in the perl scripts as /usr/bin/perl and to add link to the right executable in our filing system. As usual this goes into our startup file.

echo ln /usr/local/bin/perl /usr/bin/perl >>/opt/


As we're going to set up Apache to serve our web pages we need to make sure there is something to serve. Either 'publish' your website to the server or copy the files over to where you want them in the user file system. In my case I put the website files in /home/ptowers/parkytowers and in /home/idive/ These paths are the 'document roots' in Apache parlance.

Let's get the easy bit out of the way next. As before we need to:

  1. Ensure Apache's configuration file(s) are persistent.
  2. Start up apache when the system is booted.

The default path to Apache's configuration file is /usr/local/etc/httpd/ with additional files in /usr/local/etc/httpd/extra. The latter path with the 'extra' directory is actually spelt out in the main configuration file and it is a simple matter to change that path completely.

The sample main configuration file (httpd.conf-sample) can be found in /usr/local/etc/httpd/original whilst other sample files are in /usr/local/etc/httpd/original/conf.d.

At this stage all we are interested in are the two files httpd.conf-sample and httpd-vhosts.conf. Copy these two files to our chosen (and persistent) directory /opt/conf/

tc@mirror:~$ cp /usr/local/etc/httpd/original/httpd.conf-sample /opt/conf/httpd.conf
tc@mirror:~$ cp /usr/local/etc/httpd/original/conf.d/httpd-vhosts.conf /opt/conf/ 

We also need to get the configuration file to appear where Apache looks for it, which we do with a symbolic link.

sudo ln -s /opt/conf/httpd.conf /usr/local/etc/httpd/httpd.conf

While we're at it let's get the necessary commands into so that everything is as it should be when we next reboot - create the symbolic link to the configuration file and then start Apache:

echo ln -s /opt/conf/httpd.conf /usr/local/etc/httpd/httpd.conf >>/opt/
echo apachectl -k start >>/opt/

When I first wrote this up I glossed over the Apache configuration file - it's a long article in its own right - but a while ago I thought I'd at least document the bit about virtual hosts.

----A small digression here about the capabilities of Apache-----

Apache supports the concept of virtual hosts. After all how do you think hosting companies can host multiple websites on a single ip address? Basically, Apache looks at the website name in the request in order to see what pages to serve in response. If there is no name it recognises , or if there is just an ip address, it serves from a default document root.

To get this all to hang together on my LAN I take the following simple steps to add my new host (mirror) to the LAN:

  1. Run ifconfig on mirror to find out its MAC address and its currently assigned IP address:
    tc@mirror:~$ ifconfig
    wlan0     Link encap:Ethernet  HWaddr 00:0D:F0:7C:06:5A
              inet addr:  Bcast:  Mask:

    The MAC address is HWaddr 00:0D:F0:7C:06:5A and the IP address: inet addr:

  2. Log on to my router and tell it to always issue the same IP address to mirror. The setup screens obviously differ between makes of router but they all work in a similar way. Part of the screen from my Virgin Media (Netgear) router is shown below:

    Router Config Screen

    The router should show you a list of connected machines and their currently assigned IP addresses. If you're lucky all you may need to do is tick a box next to the one you're interested in and the router will automatically fill in the information for you otherwise you'll have to do it by hand. You then click on an 'Add Reservation' button.

    If you have problems with setting the fixed assignment up on your router then an easy alternative is to configure the system you're adding to run with a fixed IP address rather than use DHCP. Just pick an address outside the range that the router has been set up to use. In my case I've set up my router to allocate addresses in the range through to leaving upwards for any static addresses I may wish to use. Add the boot parameter nodhcp to stop Tiny Core asking for an IP address and use the netsh command in to bring up the network connection with your selected IP address.

  3. Having sorted things out so that the web server always uses a consistent IP address I then add that information to the hosts file on my various systems. On Linux systems that's /etc/hosts, in Windows its generally c:\windows\system32\drivers\etc\hosts.

    In this example I just add the three lines to the hosts file:    mirror    idive    ptowers

    The first line means I can just use mirror as a name for applications like putty where I'm only interested in connecting to the host. The last two lines are for the web browsers., having set this up, typing either http://idive/ or http://ptowers/ in a local browser will take me to mirror, but the name I've used lets Apache work out whether to serve pages from the idive website or from the parkytowers website. Neat!

-----end of digression-----


This is really just a matter of working through the file and changing entries where indicated. If you're not doing anything particularly complicated or esoteric then it's straightforward. If you are doing magic things like URL re-writes then you probably know what you're doing.

Here are some of the things to look out for when working through the httpd.conf file.

Around Line 66 is the start of the 'Load Modules' section. The basic ones are already included, others you may need to uncomment. For example I add mod_include (line 113) and mod_cgi (lines 180 & 183).

At lines 206 & 207 I set user to 'tc' and 'goup' to staff.

After that you're into the main server behaviour. Parts of this section will be repeated when we get on to set up the virtual hosts, but what you put in here will be the default behaviour unless it is overwritten by an entry in the vhosts section.

Around line 442 I need to include the cgi handler. Similarly around lines 453/454 I need the handlers for SSI (Server Side Includes).

    AddType text/html .shtml
    AddOutputFilter INCLUDES .shtml

Around line 520 we have the include for Virtual Hosts. We can either put all the virtual host entries directly in here or include a file with the configuration data in it. For now I've picked on:

Include /opt/conf/httpd-vhosts.conf

When you are done the command apachectl -t will test the syntax of your configuration files and report any obvious errors.


The guts of my file looks like this:

<VirtualHost *:80>
    DocumentRoot "/home/ptowers/parkytowers"
    ServerName ptowers
    ErrorLog "/var/log/ptowers-error_log"
    ScriptAlias "/cgi-bin" "/home/ptowers/parkytowers/cgi-bin/"
        <Directory /home/ptowers/parkytowers>
	    Options Includes ExecCGI
	    SSILegacyExprParser On
	    DirectoryIndex index.shtml index.html
	    Require all granted

<VirtualHost *:80>
    DocumentRoot "/home/idive/"
    ServerName idive
    ErrorLog "/var/log/idive-error_log"
    ScriptAlias "/cgi-bin/" "/home/idive/"
    <Directory /home/idive/>
	    DirectoryIndex index.html
	    Require all granted

The idive site doesn't use SSI and so is simpler.



Whys and Wherefores | Installation | Configuration | Log Files | Tweaks | Article Index|


Any comments? email me.    Last update January 2018