So, I have been selected as one of the teaching assistants for Operating systems course and this time we had to give some examples of Named Pipes, demonstrating one form of Inter Process Communication aka IPC to the students. I had never used them before, but its fun knowing and working with them.

I hope all of us have used pipes on Linux systems. Here is a simple pipe example I often use to check if a process is running or not.

[shredder12]$ ps -e | grep firefox

The symbol "|" used here is called pipe(its mostly above the "Enter" key). Just like conventional pipes, UNIX pipes are used to transfer data between processes, aka Inter Process communication. They transfer one program's/process's output to another process as input, ps and grep in our case. The output of 'ps -e' is transfered through pipe as an input to grep. They are called "pipes" because of their FIFO(first in first out) nature. They can be seen as files but with the FIFO property. We will see the reason in a little while.

Difference between Pipes and Named Pipes

In above example, as soon as the message is passed and grep executes, the pipe will no longer exist, i.e. it is a non-persistent thing, gets removed as soon as the task is over. Named pipes, however are persistent, have a name and they exist even after the processes are terminated. I think I might have lost you people here, so lets see a simple named pipe example.

[shredder12]$ mkfifo mypipe

This command creates a pipe. Now, if you do ls -l, you will see something like this

So, as you can see, it has everything similar to a file, but the FIFO property. It can be deleted just like a simple file, using rm.

[shredder12]$ rm mypipe

Lets begin with the usage part. Try running this command in a terminal

[shredder12]$ ps -e > mypipe

This command should have returned to a prompt(thats what you would have expected) but apparently it seems to get hanged in the middle of nowhere, why? The answer is these pipes work exactly like a conventional water-pipe does, i.e. it needs both the end to be open, one serving as an input and the other as output. So, the reason why the above command hasn't returned a prompt is because only one end of the pipe is opened, for the input. Until there is a process at the other end of the pipe to receive the data, the transfer or the communication isn't complete and so the command doesn't terminate.

Now, with the above command running in a terminal, try to run the following in another

[shredder12]$ cat mypipe

Now you will actually see the output of 'ps -e'. And note that this means the communication is done and as a result, both the commands will terminate and return to prompt.

If you have understood the basic working of pipes then you might wonder if we can create an infinite loop using two of them. In a 1997 article of LJ, the writer mentioned this little trick. Using two commands, he hooked up the ouptut of one pipe to other's input and vice versa, thus generating a loop.

However, I couldn't make it work on my system. After running the command, I didn't see any cat processes consuming huge resources. May be I did something wrong or may be the article is too old to work on today's systems, probably some defensive technique in later kernels to escape such accidents.

Anyway, I hope this small introduction to named pipes has given you a new insight into the working of Unix and Linux sytems.

We're going to see how to connect two Linux (debian) PCs together with a wire. The purpose is to share data !

I - Hardware :

• A RJ45 wire ;
• Plug in your ethernet wire to your computers ;

II - Conf :

Our case is : the PC "A" is the master and the PC "B" is the slave. (the B must connected to the A)

In the "interfaces" file (/etc/network/interfaces) of each computer :

PC A :

allow-hotplug eth0
iface eth0 inet static
address 192.168.3.3 # PC A's IP
netmask 255.255.255.0
brodcast 192.168.3.255

You can observe we don't use a gateway.

PC B :

allow-hotplug eth0
iface eth0 inet static
address 192.168.3.4 # PC B's IP
netmask 255.255.255.0
brodcast 192.168.3.255
gateway 192.168.3.3 # a gateway is necessary (PC A's IP)

Don't forget to modify "eth0" if it's needed (and the IPs).

And, you must mount eth0 on each computer (first on PCA and on PCB) :

ifup eth0

That's all ! This way to do is very easy to set up for sharing data, but can be sufficient. You only need, for example, to use Samba to share your data.

Those of you who have not been in such a situation would never know how it feels when you are stuck opening/deleting a file or directory. The more you have been working on the shell, the more it sucks. When I tried all I could to get it work and still ended up with the same error all the time, I just sat on my chair, staring at the monitor for a while, wondering if this is somekind of bash's loophole :P.

I was trying to grep through some pidgin facebook chats when I was stuck for a while trying to open a directory with the name starting with a hyphen("-"). I tried all I could think of, but I always ended with the same error.

[shredder12]$ cd -directory
bash: cd: -d: invalid option
cd: usage: cd [-L|-P] [dir]

[shredder12]$ cd \-directory

[shredder12]$ cd *directory

[shredder12]$ cd "-directory"

As you can see the trouble is that the alphabets after a "-", hyphen, are being considered as the command attributes/options but they are not, so what we need here is:

• a way to tell the command that its not an option
• or, make the command start with something other than a hyphen

The first method is to use a double-dash "--" before the name. A double-dash means the end of options to that command.

[shredder12]$ cp -- -directory/

For the other way, we need to start the command with something other than a hyphen and still make sure that its the same file.

[shredder12]$ cp ./-directory

While using Wget in scripts or otherwise, mostly when there is a lot of content to be downloaded, we need to set wget's network usage and bandwidth parameters. They both default to unlimited and when there is a lot of download involved, its always a good practice to set the limits. In this article, we will see how to control the bandwidth rate and total usage(quota).

Limit the download bandwidth rate using Wget's --limit-rate option

Just like any other application, wget will try to use the maximum amount of bandwidth available. If you want to control the download rate of wget, then use the --limit-rate flag. Lets say you want to download some video.

[shredder12]$ wget --limit-rate=60k http://foo.bar/video.ogv

This will limit the download rate to 60 KBps. Use "m" for MBps. Wget even accepts a decimal value, e.g. 2.5. This flag is beneficial only for large files. Thats because the implementation of the rate limitation feature takes sometime to achieve the concerned limit. So, it might not appear to be working for small files.

How to Wget: limit network bandwidth usage/quota using Wget's -Q option

The network quota or the total bandwidth usage can also be limited using wget's --quota or -Q attribute.

[shredder12]$ wget --quota 10m http://foo.bar/file.tgz http://foo.bar/otherfile.tgz

Please note that, if quota overflows while downloading a file then further downloading will be stopped once the current file is successfully downloaded. So, if the size of both the files are 8 and 5 MB then it will download both of them. Just like --limit-rate we can use m for Mega Bytes and similarly others. 0 sets the value to be unlimited.

Here is an error message logged in /var/log/user.log and found on a linux box running Ubuntu 9.10

auditd: /sbin/audispd permissions should be 0750

Auditd is a daemon which belongs to the auditd package. This package contains a bunch of user utilities to store and analyze all what it is being logged by the audit subsystem in the Linux 2.6 kernel.

The only thing to do for this release version of Ubuntu :

root@localhost:~# ls -l /sbin/audispd
-rwxr-xr-x 1 root root 96020 2009-09-10 00:52 /sbin/audispd

root@veronique-desktop:~# ls -l /sbin/audispd
-rwxr-x— 1 root root 96020 2009-09-10 00:52 /sbin/audispd

root@veronique-desktop:~# dpkg-reconfigure auditd
update-rc.d: warning: auditd start runlevel arguments (S) do not match LSB Default-Start values (2 3 4 5)
update-rc.d: warning: auditd stop runlevel arguments (0 6) do not match LSB Default-Stop values (0 1 6)

A foreword: some people might think that I’m writing this just to banter about what I did; my sincere reason to write, though, is to point out an example of why I dislike 5-minutes fixes as I wrote last December. It’s also an almost complete analysis of my process of ebuild maintenance so it might be interesting for others to read.

For a series of reasons that I haven’t really written about at all, I need Quagga in my homemade Celeron router running Gentoo — for those who don’t know, Quagga is a fork of an older project called Zebra, and provides a few daemons for route advertisement protocols (such as RIP and BGP). Before yesterday, the last version of Quagga in Portage was 0.99.15 (and the stable is an old 0.98 still), but there was recently a security bug that required a bump to 0.99.17.

I was already planning on getting Quagga a bump to fix a couple of personal pet peeves with it on the router; since Alin doesn’t have much time, and also doesn’t use Quagga himself, I’ve added myself to the package’s metadata; and started polishing the ebuild and its support files. The alternative would have been for someone to just pick up the 0.99.15 ebuild, update the patch references, and push it out with the 0.99.17 version, which would have categorized for a 5-minutes-fix and wouldn’t have solved a few more problems the ebuild had.

Now, the ebuild (and especially the init scripts) make a point that they were contributed by someone working for a company that used Quagga; this is a good start, from one point: the code is supposed to work since it was used; on the other hand companies don’t usually care for the Gentoo practices and policies, and tend to write ebuilds that could be polished a bit further to actually be compliant to our guidelines. I like them as a starting point, and I got used to do the final touches in those cases. So if you have some ebuilds that you use internally and don’t want to spend time maintaining it forever, you can also hire me to clean them up and merge in tree.

So I started from the patches; the ebuild applied patches from a tarball, three unconditionally and two based on USE flags; both of those had URLs tied to them that pointed out that they were unofficial feature patches (a lot of networking software tend to have similar patches). I set out to check the patches; one was changing the detection of PCRE; one was obviously a fix for --as-needed, one was a fix for an upstream bug. All five of them were on a separate patchset tarball that had to be fetched from the mirrors. I decided to change the situation.

First of all, I checked the PCRE patch; actually the whole PCRE logic, inside configure is long winded and difficult to grok properly; on the other hand, a few comments and the code itself shows that the libpcreposix library is only needed non non-GNU systems, as GLIBC provides the regcomp/regexec functions. So instead of applying the patch and have a pcre USE flag, I changed to link the use or not of PCRE depending on the elibc_glibc implicit USE flag; one less patch to apply.

Second patch I looked at was the --as-needed-related patch that changed the order of libraries link so that the linker wouldn’t drop them out; it wasn’t actually as complete as I would have made. Since libtool handles transitive dependencies fine, if the libcap library is used in the convenience library, it only has to be listed there, not also in the final installed library. Also, I like to take a chance to remove unused definitions in the Makefile while I’m there. So I reworked the patch on top of the current master branch in their GIT, and sent it upstream hoping to get it merged before next release.

The third patch is a fix for an upstream bug that hasn’t been merged in a few releases already, so I kept it basically the same. The two feature patches had new versions released, and the Gentoo version seems to have gone out of sync with the upstream ones a bit; for the sake of reducing Gentoo-specific files and process, I decided to move to use the feature patches that the original authors release; since they are only needed when their USE flags are enabled, they are fetched from the original websites conditionally. The remaining patches are too small to be part of a patchset tarball, so I first simply put them in files/ are they were, with mine a straight export from GIT. Thinking about it a bit more, I decided today to combine them in a single file, and just properly handle them on Gentoo GIT (I started writing a post detailing how I manage GIT-based patches).

Patches done, the next step is clearing out the configuration of the program itself; the ipv6 USE flag handles the build and installation of a few extra specific daemons for for the IPv6 protocol; the rest are more or less direct mappings from the remaining flags. For some reason, the ebuild used --libdir to change the installation directory of the libraries, and then later installed an env.d file to set the linker search path; which is generally a bad idea — I guess the intention was just to follow that advice, and not push non-generic libraries into the base directory, but doing it that way is mostly pointless. Note to self: write about how to properly handle internal libraries. My first choice was to see if libtool set rpath properly, and in that case leave it to the loader to deal with it. Unfortunately it seems like there is something bad in libtool, and while rpath worked on my workstation, it didn’t work on the cross-build root for the router though; I’m afraid it’s related to the lib vs lib64 paths, sigh. So after testing it out on the production router, I ended up revbumping the ebuild already to unhack it — if libtool can handle it properly, I’ll get that fixed upstream so that the library is always installed, by default, as a package-internal library, in the mean time it gets installed vanilla as upstream wrote it. It makes even more sense given that there are headers installed that suggest the library is not an internal library after all.

In general, I found the build system of quagga really messed up and in need of an update; since I know how many projects are sloppy about build systems, I’d probably take a look. But sincerely, before that I have to finish what I started with util-linux!

While I was at it, I fixed the installation to use the more common emake DESTDIR= rather than the older einstall (which means that it now installs in parallel as well); and installed the sample files among the documentation rather than in /etc (reasoning: I don’t want to backup sample files, nor I want to copy them to the router, and it’s easier to move them away directly). I forgot the first time around to remove the .la files, but I did so afterwards.

What remains is the most important stuff actually; the init scripts! Following my own suggestions the scripts had to be mostly rewritten from scratch; this actually was also needed because the previous scripts had a non-Gentoo copyright owner and I wanted to avoid that. Also, there were something like five almost identical init scripts in the package, where almost is due to the name of the service itself; this means also that there had to be more than one file without any real reason. My solution is to have a single file for all of them, and symlink the remaining ones to that one; the SVCNAME variable is going to define the name of the binary to start up. The one script that differs from the other, zebra (it has some extra code to flush the routes) I also rewrote to minimise the differences between the two (this is good for compression, if not for deduplication). The new scripts also take care of creating the /var/run directory if it doesn’t exist already, which solves a lot of trouble.

Now, as I said I committed the first version trying it locally, and then revbumped it last night after trying it on production; I reworked that a bit harder; beside the change in libraries install, I decided to add a readline USE flag rather than force the readline dependency (there really isn’t much readline-capable on my router, since it’s barely supposed to have me connected), this also shown me that the PAM dependency was strictly related to the vtysh optional component; and while I looked at PAM, (Updated) I actually broke it (and fixed it back in r2); the code is calling pam_start() with a capital-case “Quagga” string; but Linux-PAM puts it in all lower case… I didn’t know that, and I was actually quite sure that it was case sensitive. Turns out that OpenPAM is case-sensitive, Linux-PAM is not; that explains why it works with one but not the other. I guess the next step in my list of things to do is check out if it might be broken with Turkish locale. (End of update)

Another thing that I noticed there is that by default Quagga has been building itself as a Position Independent Executable (PIE); as I have written before using PIE on a standard kernel, without strong ASLR, has very few advantages, and enough disadvantages that I don’t really like to have it around; so for now it’s simply disabled; since we do support proper flags passing, if you’re building a PIE-complete system you’re free to; and if you’re building an embedded-enough system, you have nothing else to do.

The result is a pretty slick ebuild, at least in my opinion, less files installed, smaller, Gentoo-copyrighted (I rewrote the scripts practically entirely). It handles the security issue but also another bunch of “minor” issues, it is closer to upstream and it has a maintainer that’s going to make sure that the future releases will have an even slicker build system. It’s nothing exceptional, mind you, but it’s what it is to fix an ebuild properly after a few years spent with bump-renames. See?

Afterword: a few people, seemingly stirred up by a certain other developer, seems to have started complaining that I “write too much”, or pretend that I actually have an uptake about writing here. The main uptake I have is not having to repeat myself over and over to different people. Writing posts cost me time, and keeping the blog running, reachable and so on so forth takes me time and money, and running the tinderbox costs me money. Am I complaining? Not so much; Flattr is helping, but trust me that it doesn’t even cover the costs of the hosting, up to now. I’m just not really keen on the slandering because I write out explanation of what I do and why. So from now on, you bother me? Your comments will be deleted. Full stop.

I have written last week of the good feeling of merging patches upstream – even though since then I don’t think I got anything else merged … well, beside the bti fixes that I sent Greg – this week, let’s start with the opposite problem: how can you handle backports sanely, and have a quick way to check what was merged upstream? Well, the answer, at least for the software that is managed upstream with GIT, is quite easy to me.

Note: yes this is a more comprehensive rehashing of what I posted last December so if you’ve been following my blog for a long time you might not be extremely surprised by the content.

So let’s start with two ideas: branches and tags; for my system to work out properly, you need upstream to have tagged their releases properly; so if the foobar project just released version 1.2.3, we need to have a tag available that is called foobar-1.2.3, v1.2.3, or something along these lines. From that, we’ll start out a new “scratch branch”; it is important to note that it’s a scratch branch, because it means that it can be force-pushed and might require a complete new checkout to work properly. So we have something like the following:

% git clone git://git.foobar.floss/foobar.git
% cd foobar
% git checkout -b 1.2.3-gentoo origin/v1.2.3

This gives us the 1.2.3-gentoo branch as the scratch branch, and we’ll see how that behave in a moment. If upstream fails to provide tags you can also try to track down which exact commit a release corresponds to – it is tricky but not unfeasible – and replace origin/v1.2.3 with the actual SHA hash of the commit or, even better as you’ll guess by the end of the post, tag it yourself.

The idea of using a scratch branch, rather than an actual “gentoo branch” is mostly out of simplicity to me; most of the time, I make more than a couple of changes to a project if I’m packaging it – mostly because I find it easier to just fix possible autotools minor issues before they actually spread throughout the package and other packages as well – but just the actual fixes I want to apply to the packaged version; cleanups, improvements and optimisations I send upstream and wait for the next release. I didn’t always do it this way, I admit.. I changed my opinion when I started maintaining too many packages to follow all of them individually. For this reason I usually have either a personal or a “gentoo” branch where I make changes to apply to master branch, which get sent upstream and merged, and a scratch branch to handle patches. It also makes it no different to add a custom patch or a backport to a specific version (do note, I’ll try to use the word “backport” whenever possible to stress the important of getting the stuff merged upstream so that it will be present in the future, hopefully).

So we know that in the upstream repository there have been a few commits to fix corner case crashers that, incidentally, seem to always apply on Gentoo (don’t laugh, it happens more often than you can think). The commits have the shorthashes 1111111 2222222 3333333 — I have no fantasy for hashes, so sue me.

% git cherry-pick 1111111
% git cherry-pick 2222222
% git cherry-pick 3333333

Now you have a branch with three commits, cherry-picked copies (with different hashes) of the commits you need. At this point, what I usually do, is tagging the current state (and in a few paragraphs you’ll understand why), so that we can get the data out properly; at this point, the way you name the tag depends vastly on how you will release the backport, so I’ll get to that right away.

The most common way to apply patches in Gentoo, for good or bad, is adding them to the files/ subdirectory of a package; to be honest this is my least preferred way unless they are really trivial stuff, because it means that the patches will be sent down the mirrors to all users, no matter whether they use the software or not; also, given the fact that you can use GIT for patch storage and versioning, it’s also duplicating the effort. With GIT-stored patches, it’s usually the easiest to create a files/${PV}/ subdirectory and store there the patches as exported by git format-patch — easy, yes; nice nope: given that, as I’ll say, you’ll be picking the patches again when a new version is released, they’ll always have different hashes, and thus the files will always differ, even if the patch itself is the same patch. This not only wastes time, it makes it non-deduplicable and also gets around the duplicated-files check. D’oh!

A more intelligent way to handle these trivial patches is to use a single, combined patch; while patchutils has a way to combine patches, it’s not really smart; on the other hand, GIT, like most other source control managers, can provide you with diffs between arbitrary points in the repository’s history… you can thus use git diff to export a combined, complete patch in a single file (though lacking history, attribution and explanation). This helps quite a lot when you have a few, or a number, of very small patches, one or two hunks each, that would cause too much overhead in the tree. Combining this way bigger patches can also work, but you’re more likely to compress it and upload it to the mirrors, or to some storage area and add it to SRC_URI.

A third alternative, which is also requiring you to have a storage area for extra distfiles, is using a so-called “patchset tarball”; as a lot of packages already do. The downside of this is that if you have a release without any patch tarball at all, it becomes less trivial to deal with it. At any rate, you can just put in a compressed tar archive the files created, once again, by git format-patch; if you add them as a subdirectory such as patches/ you can then use the epatch function from eutils.eclass to apply them sequentially, simply pointing it at the directory. You can then use the EPATCH_EXCLUDE variable to remove one patch without re-rolling the entire tarball.

Note: epatch itself was designed to use a slightly different patchset tarball format, that included the use of a specification of the architecture, or all to apply to all architectures. This was mostly because its first users were the toolchain-related packages, where architecture-dependent patches are very common. On the other hand, using conditional patches is usually discouraged, and mostly frown upon, for the rest of the software. Reason being that’s quite more likely to make a mistake when conditionality is involved; and that’s nothing new since it was the topic of an article I wrote over five years ago.

If you export the patches as multiple files in filesdir/, you’re not really going to have to think much about naming the tag; for both other cases you have multiple options: tie the name to the ebuild release, tie it to the CVS revision indication, and so on. My personal preferred choice is that of using a single incremental, non-version-specific number for patch tarballs and patches, and mix that with the upstream release version in the tag; in the example above, it would be 1.2.3-gentoo+1. This is, though, just a personal preference.

The reason is simple to explain and I hope it makes sense for others than me; if you tie it to the release of the ebuild (i.e. ${PF}), like the Ruby team did before, you end up in trouble when you want to add a build-change-only patch – take for instance the Berkeley DB 5.0 patch; it doesn’t change what is already installed on a system built with 4.8; it only allows to build anew with 5.0; given that, bumping the release in tree is going to waste users’ time – while using the CVS revision will create quite a few jumps (if you use the revision of the ebuild, that is) as many times you change the ebuild without changing the patches. Removing the indication of the upstream version is also useful, albeit rarely, when upstream does not merge any of your patches, and you could simply reuse the same patchset tarball as previous release; it’s something that comes handy especially when security releases are done.

At this point, as a summary you can do something like this:

• mkdir patches; pushd patches; git format-patch v1.2.3..; popd; tar jcf foobar-gentoo-1.tar.bz2 patches — gets you a patchset tarball with the patches (similarly you can prepare split patches to run add to the tree);
• git diff v1.2.3.. > foobar-gentoo-1.patch — creates the complete patch that you can either compress, or upload to mirrors or (if very very little) put it on the tree.

Now, let’s say upstream releases version 1.2.4, and integrates one of our patches. Redoing the patches is quick with GIT as well.

% git checkout -b 1.2.4-gentoo
% git rebase v1.2.4

If there are compatible changes, the new patches will be applied just fine, and updated to not apply with fuzz; any patch that was applied already will count as “empty” and will be simply removed from the branch. At that point, you can just reiterate the export as said above.

When pushing to the repository, remember to push explicitly the various gentoo branches, and make sure to push --tags as well. If you’re a Gentoo developer, you can host such repository on git.overlays.gentoo.org host a few of them already; lxc, libvirt, quagga …); probably contributors, even not developers, can ask for similar repositories to be hosted there.

I hope this can help out other developers dealing with GIT-bound upstreams to ease their overweight.

So, at the moment I start writing this (and that’s unlikely to be the time I actually post this, given that I see now it could use some drawings) it’s early in the morning in Italy and I haven’t slept yet – a normal condition for me especially lately – but I have spent a bit bouncing ideas around with ferringb, Ramereth and Craig for what concerns Linux Containers (LXC). Given that, I’d like to point point out a couple of things regarding networking and LXC that might not have been extremely obvious before.

First of all, of the four networking types supported by LXC, I only could try two, for obvious reasons: phys is used to assign a particular physical device to the container, and only works if you have enough physical devices to work with, vlan requires a device able to do vlan tagging. This leaves us with veth (virtual ethernet), and macvlan (mac-address based virtual lan tagging). The former is the most simple setup, and the one I’ve been using; it creates a pair of devices, one of which is assigned within the container, and the other which is assigned to the host; you can then manage that device exactly like any other device you have on your system, and in my case that means it’s added to the br0 bridge where KVM instances are also joined. LXC allows for defining the bridge to join directly in the configuration file.

The macvlan mode is supposed to have smaller overhead because the kernel knows the mac address assigned to the single interfaces beforehand; on the other hand setting it up is slightly harder; in particular, there is one further mode parameter that can be set, in either vepa (Virtual Ethernet Port Aggregator) or bridge mode; the former isolates the container, like they were a number of different hosts connected over to the network segment, but disallows the various containers from talking with one another; on the other hand the latter mode actually creates a special bridge (not to be confused with the Linux bridge used above with virtual ethernet devices), that allows all the containers to talk with one another.. but isolates them from the host system

You end up having to choose between the performance of network-to-container and that of host-to-container: in the first case you can choose macvlan, reducing the work the kernel has to do, but requiring you to route your own traffic to the container with an outside router; in the second case you use veth and make the kernel handle the bridge itself. In my case, since the containers are mostly used for local testing, and the workstation will still be using the in-kernel bridge anyway, the choice is obvious for veth.

Now, when I decided to seal the tinderbox I wondered about one thing, that LXC cannot do and that I would like to find the time to send upstream. As it is, I want to disallow any access from the tinderbox to the outside, minus the access to the RSync service and the non-caching Squid proxy. To achieve that I dropped IPv4 connectivity (so I don’t run any DHCP client at all), and limited myself to autoconfigured IPv6 addresses; then I set in /etc/hosts the static address for yamato.home.flameeyes.eu, and used that as hostname for the two services. Using iptables to firewall the access to any other thing had unfortunate results before (the kernel locked up without actually any panic happening); while I have to investigate that again, I don’t think much changed in that regard. There is no access to the outside network or from the outside network, since the main firewall is set to refuse talking at all with the tinderbox, but that’s not generally a good thing (I would like, at some point in the future, to allow access to the tinderbox to other developers), and does not ensures isolation between that and the other boxes on the network, which is a security risk (remember: the tinderbox builds and execute a lot of code that for me is untrusted).

Now, assuming that the iptables kernel problem happens only with the bridge enabled (I would be surprised if it failed that badly on a pure virtual ethernet device!), my solution was actually kinda easy: I would just have used the link-local IPv6 address, and relied on Yamato as a jump-host to connect to the tinderbox. Unfortunately, while LXC allows you to set a fixed hardware address for the interface created inside the container, it provides you no way to do the same for the host-side interface (which also get a random name such as veth8pUZr), so you cannot simply use iptables to enforce the policy as easily.

But up to this, it’s just a matter of missing configuration interfaces, so it shouldn’t be much of a problem, no? Brian pointed out a chance of safety issue there though, and I went on to check it out. Since when you use virtual ethernet devices it is the kernel’s bridge that takes care of identifying where to send the packages based on STP there is no checking of the hardware address used by the container; just like the IP settings you have there, any root user inside the container can add and remove IP addresses and change the mac address of it altogether. D’uh!

I’m not sure whether this would work better with macvlan, but as it is, there is enough work to be done with the configuration interface, and – over an year after the tinderbox started using LXC to run – it’s still not ready for production use — or at least not for the kind of production use where you actually allow third parties to access a “virtualised” root.

For those interested, the original SVG file of the (bad) network diagrams used in the article, is here and is drawn using Inkscape.

Guess where did I play Quake III Arena for the first time. Not place, I am talking about the platform/Operating System. Nope! its not windows, its Linux . Surprised, right? I was too when I found this brilliant opensource version of Quake III Arena aka OpenArena.

While looking for a good one man shooting game in the software center, I bumped into this one which says, "a fast-paced 3D first-person shooting game." I decided to give it a try. After downloading around 300 MB of the packages the game was finally installed and while runnning and shooting weird creatures(some almost nude lady warriors too ) I couldn't believe that even such a game could be totally free.

I was indeed dazzled by the brilliance of this game but since I had never played Quake III Arena before, I never realized that it was almost exactly like it. One day co-author Chia saw me playing it and asked where the hell did I get Quake from? Thats when I came to know I had accidently found something really cool.

After gathering a little info about, I found out that it is actually Quake III Arena. Its built upon ioquake3, based on id tech3, the Quake3 game engine which was opensourced by the company, id software, in Aug 2005.

Thats when OpenArena project was established to built an opensource FPS game derieved from Quake III Arena. ioquake3 is a project aimed to improve the opensource engine further.

If you have been a Quake III Arena fan and miss it on Linux then you should give openarena a try. The one thing that sucks is its incompatibility with the propreitary game. I haven't tried coupling the original with openarena but I guess that won't work. However, its being cross-platorm removes most of the hurdles for network gaming. You can find the listing for online openarena servers here.

Install OpenArena

It is available in repos of almost all common distros. You can easily install it using the package manager. Otherwise, try running these commands.

[shredder12]$ sudo apt-get install openarena     #for Ubuntu or Debian based systems

[root]# yum install openarena    #for Fedora or RedHat based systems