Posts Tagged ‘DSL’

DSL (Damn Small Linux) Diskless boot

Friday, August 31st, 2007

I have come across a requirement to boot a thin client on a very cheap hardware into Linux. Due to the tight hardware requirements, and the tight budget, I have decided to focus on diskless systems, which can be easily modified and purchased to our needs.

Not only that, but due to the hardware configuration (Via 333MHz, 128MB RAM, etc) I have decided to focus on a miniature Linux system.

I dislike re-doing what someone else has done, unless I can do it noticeably better. I have decided to use DSL (Damn Small Linux) as my system of choice, with only minor changes to fit my needs:

Out of the “box”, I was unable to find network-boot DSL. Quickly searching their site, the version which seemed to fit was the initrd-only system. I downloaded it from this mirror, but you can find it as the dsl-x.x.x-initrd.iso file.

Extracting the initrd from the ISO file is quite simple:

mkdir /mnt/iso
mount -o loop dsl-x.x.x-initrd.iso /mnt/iso

And from here you can just copy the contents of the directory /mnt/iso/boot/isolinux/ selectively to your tftpboot directory.

So I got 50MB initrd which worked just fine. Changing this was quite a procedure, because in addition to the steps per the wiki hacking guide, I was required to extract the KNOPPIX file outside of the initrd, and repackage it when done. Quite messy, however, stand-alone as soon as the system has been able to boot.

An alternate I have decided to investigate into was of booting into nfs mount, aka, accessing the KNOPPIX iso disk through NFS and not through CDROM.

I was able to find some leads in DSL forums at this page, which lead to this guide. I was able to download pxe boot image from Knoppix themselves, however, it was based on an old kernel (2.4.20-XFS) which was part of Knoppix 3.3 (cannot find it anymore) and although reached the level of actually booting my nfs, didn’t include enough network drivers (I wanted pcnet32 to be able to “play” with VMware for the task), and was incompatible with my existing DSL.

I had opened the supplied Knoppix initrd, and replaced the modules version to the one supplied with DSL – 2.4.24, per the rest of the system. In addition, I have added my required modules, etc, and was able to boot successfully both on VMware and on the thin client hardware.

To replace the modules, one needs to follow these general-only guidelines (these are not exactly step-by-step instructions):

Mount through loop the DSL KNOPPIX image, for example, in /mnt/dsl
Uncompress the Knoppix PXE initrd
Mount through loop the uncompressed Knoppix PXE initrd, for example, in /mnt/initrd
cd to /mnt/initrd/modules
Replace all modules in the current tree with the ones supplied by DSL, obtainable from /mnt/dsl/lib/modules/2.4.26 directory tree, including the cloop.o module
Umount the initrd image
Compress the initrd image
Boot using DSL linux and the new initrd image.

In order to boot successfully, you need to supply the pxe boot these two instructions:

nfsdir=nfs-server:/path/to/KNOPPIX directory

(since I was quite unsure about the letter case required, I have created a symlink from lower-case to upper case, so I had a link /mnt/KNOPPIX to a directory /mnt/knoppix, and inside this directory, a file called knoppix and a symbolic link to this file KNOPPIX. In my case, the exported path was /mnt/ only. Notice this one!).

BOOT_IMAGE=KNOPPIX – but you can have different KNOPPIX images for different purposes.

Finally it has worked correctly. Changes can be done only to the KNOPPIX iso image, per the hacking guide.

This is my PXE-enabled initrd, based on the text above, which fits DSL-3.4.1: minirt24.gz

Multihomed routing (split access load balancing) and OpenVPN

Sunday, June 25th, 2006

We have one connection via ATM like interface and we have one PPP connection via xDSL (described here), and we want load balancing for this whole party.

Following this specific part of lartc.org guide, we’ve managed to get this to work. The idea goes like this (Centos 4.3):

1. Do not state default route for the machine. Not in /etc/sysconfig/network and not in /etc/sysconfig/network-scripts/ifcfg-ethX

2. Using adsl-setup, we’ve defined our ADSL connection. Verify you have an entry DEFROUTE=no in your /etc/sysconfig/network-scripts/ifcfg-ppp0

3. find a way to start the following script after your network interfaces are up. I assume, in this script, that your ATM interface is eth1. multiroute.txt

The reason for specifically stating SERVER is that our DNS server requires recursive DNS for its settings, and I can use my ISP’s DNS Server only when using the corresponding link. Since both links are for different ISPs, I need to “bind” SERVER to a specific route.

Note that this solution is only temporary. At the moment, it is far from being complete, and many tests should be done yet, before I can call it a working solution. I might combine it with /etc/ppp/ip-up.local script, or I might add it as a seperated service in /etc/init.d, which would start after all interfaces are up and running. Not final yet.

With all this working like charm, we’ve had a huge issue – our OpenVPN server, which worked correctly just until then failed to work smoothly. Sometimes clients were able to connect, and sometimes they were unable to do so…

I got the following error message in my logs: “x.y.z.m:2839 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

The cause, as it seemed to me, was that OpenVPN’s UDP packets were routed via alternate route for each target client. Being UDP, they were not part of an active session, but were stateless, which resulted in a different routing descision each time they were directed at the OpenVPN client. I’ve searched for it, although I was not optimistic, because multihomed routing, with multiple ways out wasn’t very common. I was suprised to find this post, with it’s follow-up, which dealt exactly with my case.

Since I cannot bind it to an internal IP address (although I’ve tried – it didn’t work), I will test TCP based configuration tomorrow morning.

===============================================================================

Update

===============================================================================

I don’t usually update posts but add new posts with links. However, in this case it was important enough for me to update this hot topic so I’ve decided to just add the new stuff.

First – I’ve failed. Since I do not have too much time here, I did not feel confident to leave a system yet untested. Especially when such a router is an essential link in this company.

I’ve tried using TCP based connection, but, still again, one client was able to connect, while the 2nd one did so for only a short while, and failed maintaining a working connection. I went back to UDP…

I came up with the following idea – if I can use some sort of tagging to differentiate the UDP packets sourced at the router, at the OpenVPN application, I could try and set a routing rule which will force them into a specific routing chain, and force them through my interface.

It didn’t work quite well. I was able to do the followin trick, but for no avail:

iptables -t mangle -A OUTPUT -p udp –sport 5001 -j MARK –set-mark 1

and then, using “ip” command:

ip rule add fwmark 1 table T1

which should have redirected all outbound UDP with source port 5001 (this is the one I use for my OpenVPN, due to legacy considerations), to the T1 routing table – a table directed outside with default route via eth1.

I don’t know why it failed. Almost seemed to work, but no…

I returned the system to a single-path setup, with PPP0 only acting as a manual alternate path in case where the primary path is down. Would work for now.