An updated (Tiny Core 4.0) version of this description can be found here.
My aim was to create a web server on a Compact-Flash based thin client. This acts as a reference for a couple of web sites that I maintain. Each of the main hosting web sites run a flavour of Linux with Apache as the main server. The reference server sits on my local network and I occasionally add/edit pages on it before testing and then uploading them to the main sites. Editing is actually done using an editor (Edit Plus) running on my main Windows system, with the files of the (local copy of the) web site appearing on a mapped drive.
Originally the server I used was an oldish Shuttle box running Fedora, but the thin client hardware provides the option of using a system that consumes far less power and also is totally silent. A previous incarnation of this project had used a Neoware Capio 620 (300MHz Geode GX1) and Puppy WebServer (Link http://www.browserpuppy.com/server.html currently defunct), but the version of Perl in that distribution turned out to be a cut-down package with various libraries missing. I only discovered this later when I tried to add some sophisticated analysis tools. Trying to add the additional missing bits was starting to become a little messy. A fresh start seemed a good idea.
The Thin Client selected here is an Igel 2110LX which has a 400MHz VIA Eden processor and overall consumes ~15W when running. I'd upgraded the internal RAM to 512Mb so there were no major memory constraints that there might have been had there been only 64Mb or 128Mb of RAM.
This article is the 'How-to' of how I put the new version together.
Having decided to base the solution on Tinycore Linux I also need to add the following extensions:
|Apache||The hosting company's web servers run Apache, so, for compatibility, I do the same.|
|Perl||The Web sites use cgi and some perl scripts. I also have a number of support/analysis tools that I've written in perl. If you want to run any of the W3 validation tools you'll need perl.|
|Samba||By running Samba on the local server I can mount the web site file systems on my main Windows machine and edit/update the web site files from there.|
Once set up and configured I run the server "headless" (no keyboard or screen) and access it via SSH if I need direct access. I use the PuTTY client on Windows and Tinycore includes the DropBear SSH daemon.
The web sites themselves currently take up about 600Mb of disk space.
As stated earlier, this project uses a Compact Flash card as its non-volatile storage. Alternatives are a USB drive or conventional hard disk.
The particular thin client (IGEL 2110LX) I selected for this task conveniently has a compact flash socket on board. and also a 44-pin IDE header. The previous hardware - the Geode GX1 based Neoware Capio 620 - had no card slot, but I used a CF card and a CF card-to-44-pin-IDE adaptor for that project.
I had a spare 1GB Compact Flash card which I decided to use for storage as this would easily accommodate the software and the web sites. We just need to sort out how to partition it. The obvious approach is two partitions: hda1 for Tinycore and its extensions and hda2 for the web sites. There is a mention in the Tinycore documentation of making /opt persistent storage to remove the need for using backup, but the various TCE addons seem to use /usr/local/... as the default locations for their configuration files, so I didn't bother with a third partition for /opt. As to size - having plenty of space to play with I allocated 200Mb to hda1 (Tinycore and TCE files) and the rest to hda2.
Tinycore is designed to run from RAM where the core file system (tinycore.gz) is loaded into a RAM disk. This makes it very responsive but does consume additional memory. The TCE extensions can also be loaded into RAM but now default to the mount option when they are installed where they remain on the storage media and are not copied into RAM. (Note: The previous control file - tcz2ram.lst - that specified which TCE files were to be loaded into RAM has now been renamed copy2fs.lst - the main documentation hasn't caught up with this at the time of writing). The change to defaulting to mount certainly makes sense in my environment where we have the files sitting permanently on CF on an IDE interface. For example the samba daemons (smbd and nmbd) are large and are run (loaded into RAM) at start-up and remain running until the machine is shut down. Having the TCE extension in RAM as well would waste space and deliver no benefit.
Obviously something you need to check before embarking on anything is to check that Tinycore works on your hardware! In my case it did and I'm currently using the kernel straight out of the box and have made no attempt to tailor it explicitly to the hardware I'm using. Maybe some time in the future I'll rebuild the kernel explicitly for my environment. (Build all the needed drivers into the kernel and dump the Modules that aren't required - it would reduce the size of the tinycore.gz file which would be useful where there are memory constraints).
First step is to download the Tinycore ISO and transfer it to your selected boot medium. In my case that is CDROM.
The IGEL BIOS supports booting from an external usb-connected CDROM so I used this approach. The alternative would have been to have connected the CDROM drive via a 40-pin-to-44-pin adaptor to the internal IDE connector and booted it that way. Once Tinycore is installed on the Compact Flash card the CDROM drive can be dispensed with.
The full installation instructions are given on the Tinycore Web site. These are duplicated here to a certain extent, but it's worth having a copy of the original instructions and screen shots to hand.
In what follows the Compact Flash on my system appears as /dev/hda. Adjust to suit your particular setup.
Boot Tinycore from your installation media. Note: If you are doing a 're-install' you need to type:
at the boot prompt otherwise Tinycore will look for and find any existing installation, mount /dev/hda1 and prevent you do anything to it - like reformatting the partition!
Once Tinycore has booted use the Appbrowser to download and install cfdisk and Grub.
Using cfdisk create hda1 - a 200Mb bootable partition and hda2 - the rest (844Mb with my 1GB card).
Next format the two partitions.
mkfs.ext2 /dev/hda1 mkfs.ext2 /dev/hda2
The section in the installation how-to on copying over the TC system files assumes that your drive was already partitioned when the system booted - in which case Tinycore will have found the partitions, entered them into fstab and created the mount points. If you are using fresh media you'll have to do that manually. e.g.:
mkdir /mnt/hda1 mount /dev/hda1 /mnt/hda1However Tinycore will have found your boot media so either ls /mnt or cat /etc/fstab will show you where it is. In my case, with a USB-attached CDROM, there is an entry for sr0 so the command to mount it is:
Now copy over the TC files:
mkdir -p /mnt/hda1/boot/grub cp -p /mnt/sr0/boot/* /mnt/hda1/boot/ mkdir -p /mnt/hda1/tce touch /mnt/hda1/tce/mydata.tgz
Next install GRUB. When creating menu.lst I added the entry kmap=uk to the kernel line as an additional parameter as I'm using a UK keyboard. My menu.lst file looks like:
default 0 timeout 5 title tinycore kernel /boot/bzImage quiet kmap=uk initrd /boot/tinycore.gz
At this point you can test the system by disconnecting your installation media and rebooting. Note: When you reboot the system will still be set up for a US keyboard. We put that right in the following section.
It is actually a simple matter to remaster Tinycore to suit your particular installation and once again instructions can be found in the Tinycore guides. At this stage, as an exercise, I did a few trivial things: (1) Include the UK keyboard layout in the base system. (When you install the kmap TCE file you end up with loads of keyboards you have no interest in!) (2) Added another user to the password file. (Historically I have a specific logon for my web site account. If the user is not in the password file then the Samba network logon doesn't work if you require network username/password logon). (3) Changed the hostname from box to stonefish.
The first step is to extract the contents of the existing tinycore.tgz file. Note: I always do this sort of stuff from a root shell. If you use a normal shell then you'll need to prefix some of the commands with sudo.
mkdir /tmp/extract cd /tmp/extract zcat /mnt/hda1/boot/tincycore.gz | cpio -i -H newc -dTo deal with the keyboard file we first need to use the Appbrowser to install kmaps. We can then copy the uk.kmap file (in my case) from the TCE extension into our base image.
cp /usr/share/kmap/uk.kmap /tmp/extract/usr/share/kmap/Next we can add a new user:
adduser sunstar -G staff Changing password for sunstar New password: Retype password: Password for sunstar changed by root...and copy the relevant files to our base image.
cp /etc/passwd /etc/shadow /tmp/extract/etc/
adduser will have created a home directory for sunstar in /home. We also need to ensure it exists in the tinycore.tgz image. Also, when /dev/hda2 is mounted it needs to be owned by sunstar.
mkdir /tmp/extract/home/sunstar mount /dev/hda2 /mnt/sunstar chown sunstar:staff /home/sunstarWe can also use this opportunity set the hostname if we want.
echo stonefish >/tmp/extract/etc/hostnameIf you do this you'll also need to update the hosts file as well (change box to stonefish).
There may be other changes you wish to make before repackaging the base system. Repackaging is simply:
cd /tmp/extract find | cpio -o -H newc | gzip >../tinycore.gz mv ../tinycore.gz /mnt/hda1/boot/tinycore.gzWe can now delete the installed kmaps file as we have no further use for it.
The final step is to ensure that the second partition - which will hold all the website files is mounted when the system starts up. We add one line to the /opt/bootlocal.sh file:
mount /dev/hda2 /home/sunstarYou can do this with the echo command or by editing the file. Once that's done we need to make sure it persists between reboots by doing a backup. The simple way of doing this is by shutting the system down via the logout box and ensuring the Backup box is ticked, or by running the command:
/usr/bin/filetool.sh backupNow reboot to check all is well - open a shell and you should find that all the keys on your keyboard now return the right characters. Typing mount should show we have /dev/hda2 mounted on our new user.
The next step in our odyssey is to get Samba installed. Once we've done that we can populate the user's file system with the web site files and then move on to getting Perl and Apache to serve them.
Installation is simple, just run the Appbrowser, select samba3.tcz and click on Install.
The Samba3 extension is quite large (30Mb), and, in my particular usage of it, I don't actually need a lot of the package. If space is a premium you can easily more than halve the amount of space taken by the Samba3 TCE extension. The samba3 extension is mounted on /tmp/tcloop/samba3 and so the simple way of 'unpacking' the extension is to copy that directory tree into /tmp:
mkdir /tmp/samba3 cp -r -p /tmp/tcloop/samba3/* /tmp/samba3/Note: You'll end up with 64Mb of files so you might be in trouble if you're working on a system with a limited amount of RAM! If you look in the bin directory you'll find 30 binaries occupying 45Mb:
-rwxr-xr-x 1 root root 976216 Nov 29 16:05 eventlogadm -rwxr-xr-x 1 root root 4596 Nov 29 15:58 findsmb -rwxr-xr-x 1 root root 784972 Nov 29 16:05 ldbadd -rwxr-xr-x 1 root root 784968 Nov 29 16:05 ldbdel -rwxr-xr-x 1 root root 784976 Nov 29 16:05 ldbedit -rwxr-xr-x 1 root root 784972 Nov 29 16:05 ldbmodify -rwxr-xr-x 1 root root 784968 Nov 29 16:05 ldbrename -rwxr-xr-x 1 root root 784968 Nov 29 16:05 ldbsearch -rwxr-xr-x 1 root root 4338504 Nov 29 16:05 net -rwxr-xr-x 1 root root 776452 Nov 29 16:05 nmblookup -rwxr-xr-x 1 root root 1727900 Nov 29 16:05 ntlm_auth -rwxr-xr-x 1 root root 982076 Nov 29 16:05 pdbedit -rwxr-xr-x 1 root root 723080 Nov 29 16:05 profiles -rwxr-xr-x 1 root root 3899380 Nov 29 16:05 rpcclient -rwxr-xr-x 1 root root 727176 Nov 29 16:05 sharesec -rwxr-xr-x 1 root root 3794108 Nov 29 16:05 smbcacls -rwxr-xr-x 1 root root 3834724 Nov 29 16:05 smbclient -rwxr-xr-x 1 root root 788948 Nov 29 16:05 smbcontrol -rwxr-xr-x 1 root root 3769208 Nov 29 16:05 smbcquotas -rwxr-xr-x 1 root root 3847252 Nov 29 16:05 smbget -rwxr-xr-x 1 root root 3773312 Nov 29 16:05 smbpasswd -rwxr-xr-x 1 root root 1883692 Nov 29 16:05 smbspool -rwxr-xr-x 1 root root 772300 Nov 29 16:05 smbstatus -rwxr-xr-x 1 root root 4896 Nov 29 15:58 smbtar -rwxr-xr-x 1 root root 3756800 Nov 29 16:05 smbtree -rwxr-xr-x 1 root root 9808 Nov 29 16:05 tdbbackup -rwxr-xr-x 1 root root 9744 Nov 29 16:05 tdbdump -rwxr-xr-x 1 root root 14100 Nov 29 16:05 tdbtool -rwxr-xr-x 1 root root 727180 Nov 29 16:05 testparm -rwxr-xr-x 1 root root 747860 Nov 29 16:05 wbinfoI'm just running a local file server with no domain controllers, no printers etc. Of all the files listed I need: smbpasswd to add users (if you have password controls), smbstatus to see what's happening and testparam to validate the config file. All the rest can go. Get to work with the rm command to get rid of the rest. We're now down to 25Mb. The final step is to repackage the TCE. For this we have to go back to the Appbrowser and install squashfs-tools-4.0.tcz. Then it's a case of:
cd /tmp mksquashfs samba3 samba3.tcz umount /mnt/tcloop/samba3 mv samba3.tcz /mnt/hda1/tce/The 30Mb extension is now down to a more friendly 11.5Mb. You can go through the procedure of remounting the samba3 extension, or a reboot works just as well.
The final steps are to:
[global] workgroup = PTOWERS netbios name = STONEFISH security = share [mirror] comment = Data path = /home/sunstar force user = sunstar force group = staff read only = No guest ok = YesThis works well for me on my local home network behind a firewall. You might want to tighten things up more in your particular environment as the above configuration does not actually authenticate any users connecting to the server.
/usr/local/etc/init.d/samba startand then check from your windows box. The server should appear as a network resource and you should be able to map a network drive to it. If it doesn't 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).
Once you're happy with it add the startup command to /opt/bootlocal.sh, and the line usr/local/etc/samba to the /opt/.filetool.lst file. (Note the lack of a '/' before the usr). For completeness you can add /usr/local/etc/init.d/samba stop to the shutdown.sh file.
We now have samba configured and working. At this point I copied all my user and website files across to /home/sunstar. The next step is to install PERL and then install and configure APACHE.
Installing Perl is just a matter of using the Appbrowser tool. No additional configuration is necessary.
Once again installing Apache is just a matter of using the Appbrowser tool.
This is not a tutorial in how to configure apache so I leave that up to you. The salient point here is that the httpd.conf is located in /usr/local/conf. Apache itself is run/restarted/stopped using the apachectl utility. (apachectl -k start).
When it is all sorted to your satisfaction we need to ensure that the changes persist. This means adding the line usr/local/conf to the /opt./filetool.lst file and apachectl -k start to the bootlocal.sh file.
dropbear, the ssh server, is part of the base system. We just have to ensure it starts up automatically. The first time you run it it generates the server keys which you may (or may not?) want to persist across reboots. /etc/init.d/dropbear start starts the server and generates the initial set of keys. We then need to add /etc/init.d/dropbear start to the /opt/bootlocal.sh file and etc/dropbear to the /opt./filetool.lst file.
Any comments? email me. Last update December 2009