[tag]Thin-client[/tag] [tag]technology[/tag] has massive advantages in many usage cases. Pretty much everybody knows I think that. [tag]Linux[/tag] also has enormous power to do things which would generally not even be possible on (most) other [tag]operating systems[/tag]. Combine the two (as with [tag]LTSP[/tag])  and you have one sweet solution for many tasks.  Call-centers, schools, [tag]cybercafe[/tag]s and community centers are primary examples of what people regularly use this for – and with good reason.

But thin-clients do have some pitfalls as well (the same applies to many similar technologies such as [tag]4-in-1[/tag] style setups). The advantages of running all the apps on a central powerful server are many, but they come at a price – all the apps are running on a central powerful server. This isn’t usually any problem at all, but it does become one when you are dealing with more advanced networking issues. Most specifically, you cannot do per-station firewalling for example. Even that is of no real concern, after all – the kind of environment where thin-clients work tend to have pretty much identical use-cases for all the machines anyway. But one thing does get lost, which has been an essentially unsolved problem for many people for a long time now is to do traffic accounting for LTSP users.

The core problem is this: on LTSP all your network apps appear to have a single source address and interface – this makes traditional traffic accounting tools useless as they cannot differentiate the origin.

Luckily, there is an answer, which I found after several months of struggling. In short, to do traffic accounting for  LTSP you have to force your network packets to come from a different source. Specifically, from the LTSP box itself.

Here’s how (this is a conceptual explanation – the exact implementation will vary from site to site and is left as an exercise for the reader).  I did one so I know it works, but there are several variations you could do.

1) Get the redir package for slackware 9.1 from linuxpackages. The reason we use this older package (not version) is to make sure the glibc version will
 match that of LTSP. Extract the tarball and copy the /usr/bin/redir file into your LTSP tree.

2) Set up squid on the LTSP server, listening on port 3128.

3) Copy redir into your /opt/ltsp tree and write an ltsp bootscript to start it, listening on port 8080 and forwarding to port 3128 on your LTSP servers’s internal IP.

4) Set up your browsers to use a proxy at the LTSP client’s IP, on port 8080 (you may have to use static IP assignments in DHCP to do this).

5) Voila, you can now do source based traffic accounting for all your web protocols.

6) Other protocols are easier, just set up a redir to listen on the port for the service, and forward to the provider of the service (for example a jabber server) on the same port. Then modify the clients to  connect to their LTSP client addresses instead.

The approach is far from complete as here, it works by the source IP which has to be set up in clients on the user level – not perfect, so there is much room for expansion and improvement (in the site where I have done it the terminals have automatic logins so this is not an issue), but it at least gives a viable way to overcome the ‘same source’ problem.