Whys and Wherefores | Installation | Configuration | Log Files | Tweaks |
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) 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/bootlocal.sh.
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: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCSL0AofxOBKtRvvAwUhE2Tur8cMtG0+JhrU5 a6kV6+xQF4Co06uCUxanHtyeivQTKQPPx4oYeIPqzrT57NK4pgPsM3AZCN3wzN9DEsbNk9I2Rf bYplxjz9/8/vUGt/NW1lWuBuA/nB7DHM9EJMWmu37FCAWdnXOXoj13Q9bq2R7VkjzrrY3LQWnD Tvs/wa18FGwi31FAJPJMR9NwJVK0pbD5U+/QAJxXAEdhUihyxIRflXmG3LxV1ZFWwf911tgLHo r6fPYIL4A7w+XkhV+IVnzb3KyAETmISKKOrlIfeKZ71K/NS9P+8LmV4UYnZiWLux6sYTX3e1SU TTlehKU1Y3 root@mirror 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 p7eeJtyChPdkNpNOzK9decwBwULtMie2a+I90rSJsWIU7BzsWf1Yr+a284Ih6PAnQ/DX/8MlV3 U9bPMkqfSYLxHf2DPOm9pBfBiJJHytzLkOkoaSjc8+cY2jyM0ztPAAAAFQCiHU/PR1CxkU5goO sCo09ArCzysQAAAIADkh22r/B1UF1BL3ngTUsLwFMNlDTOQcXp+4e7kKr1tw0OMP+5tThJxlFY OQVq5J9XuiyLyKgrjjP/D7Dv7JnkNqOTseV86ci44yXpy/3ZTF7Ld5b4iNnzWBf4i3debEDe00 1wDV1pztBO61eJsu54cWOPUj6SXnEC3YqeycmkZgAAAIAUj12GLxn6vhliq/bM1BlnHtWfs18X FszepG+xxZN4kWHtvNwKDboTL6euoSdsn8e0g9jDgTPH8XnAn1wSGARb2ulnF+Zek1QjjjmP7j 6sPsnFqidESy7b2zqjlzJvLtEF+8uM0qbQK1mClVrnof3Du7p3906KFEScD0i0ORACRg== root@mirror Fingerprint: md5 e0:80:d2:bf:af:31:af:9a:11:7f:f8:1b:3e:54:af:b4 Starting SSH server: Dropbear... tc@mirror:~$
...get them to persist....
tc@mirror:~$ echo usr/local/etc/dropbear >>/opt/.filetool.lst tc@mirror:~$ filetool.sh -b Backing up files to /mnt/sda1/tce/mydata.tgz tc@mirror:~$
...and dropbear to start...
tc@mirror:~$ echo /usr/local/etc/init.d/dropbear start >>/opt/bootlocal.sh tc@mirror:~$
As with the other applications what we need to do here is
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:
[global] workgroup = PTOWERS netbios name = mirror security = share [parkytowers] comment = Data path = /home/ptowers force user = ptowers force group = staff read only = no guest ok = yes [idive] 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 bootlocal.sh 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
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/bootlocal.sh.
echo rm -f /usr/local/etc/samba/smb.conf >>/opt/bootlocal.sh echo ln -s /opt/conf/smb.conf /usr/local/etc/samba/smb.conf >>/opt/bootlocal.sh echo /usr/local/etc/init.d/samba start >>/opt/bootlocal.sh
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 shutdown.sh 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 bootlocal.sh startup file.
echo ln /usr/local/bin/perl /usr/bin/perl >>/opt/bootlocal.sh
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/idive.org.uk. 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:
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/ tc@mirror:~$
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 bootlocal.sh 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/bootlocal.sh echo apachectl -k start >>/opt/bootlocal.sh
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:
tc@mirror:~$ ifconfig
wlan0 Link encap:Ethernet HWaddr 00:0D:F0:7C:06:5A
inet addr:192.168.10.18 Bcast:192.168.10.255 Mask:255.255.255.0
.....
The MAC address is HWaddr 00:0D:F0:7C:06:5A and the IP address: inet addr:192.168.10.18.
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 192.168.10.2 through to 192.168.1.50 leaving 192.168.10.51 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 bootlocal.sh to bring up the network connection with your selected IP address.
In this example I just add the three lines to the hosts file:
192.168.10.18 mirror 192.168.10.18 idive 192.168.10.18 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.
...so, 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
</Directory>
</VirtualHost>
<VirtualHost *:80>
DocumentRoot "/home/idive/idive.org.uk"
ServerName idive
ErrorLog "/var/log/idive-error_log"
ScriptAlias "/cgi-bin/" "/home/idive/idive.org.uk/cgi-bin"
<Directory /home/idive/idive.org.uk>
DirectoryIndex index.html
Require all granted
</Directory>
</VirtualHost>
The idive site doesn't use SSI and so is simpler.