1. The PKGBUILD

Long story short, here’s the code, I’ll comment most important choices later on. I’m using eclipse-mylyn as an example.

pkgname=eclipse-mylyn
pkgver=3.0.3
pkgrel=1
pkgdesc="A task-focused interface for Eclipse"
arch=('i686' 'x86_64')
url="http://www.eclipse.org/mylyn/"
license=('EPL')
depends=('eclipse')
optdepends=('bugzilla: ticketing support')
source=(http://download.eclipse.org/tools/mylyn/update/mylyn-${pkgver}-e3.4.zip)
md5sums=('e98cd7ab3c5d5aeb7c32845844f85c22')

build() {
  _dest=${pkgdir}/usr/share/eclipse/dropins/${pkgname/eclipse-}/eclipse

  cd ${srcdir}

  # Features
  find features -type f -name *.jar | while read _feature ; do
    if [[ ${_feature} =~ (.*\.jar$) ]] ; then
      install -dm755 ${_dest}/${_feature%*.jar}
      cd ${_dest}/${_feature/.jar}
      jar xf ${srcdir}/${_feature} || return 1
    else
      install -Dm644 ${_feature} ${_dest}/${_feature}
    fi
  done

  # Plugins
  find plugins -type f | while read _plugin ; do
    install -Dm644 ${_plugin} ${_dest}/${_plugin}
  done
}

2. Package naming and makedepends

Packages should be named eclipse-pluginname, so that they’re recognizable as eclipse-related packages and it’s easy to extract the plugin name with a simple shell substitution like ${pkgname/eclipse-}, not having to resort to the unneded ${_realname} variable. The plugin name is necessary to tidy up everything during installation and avoid conflicts.

I tried using bsdtar instead of unzip to remove the make dependency, but the test was negative: the archives I tried spitted out lots of errors, so I went the easy way. If someone makes it with bsdtar, I’ll be glad to modify the script.
UPDATE: I was noticed that I can directly use jar, which the user already has since it’s part of the JRE. This is great, since it spares a makedepend! However, jar can’t extract to directories other than the current one: this means that, after the directory creation, it’s necessary to cd before extracting. Since there were many occurrences of the destination path I decided to use a custom variable even though somebody might not like it, because there’s a great improvement in readability.

3. File locations

Eclipse 3.4 (Ganymede) introduced a new way of handling plugins: the dropins folder (located in /usr/share/eclipse/dropins). Eclipse scans this folder looking for plugins, and it supports many directory structures. Source archives provide two directories, features and plugins, each one packed up with jar files. The preferred dropins structure should look like this:

/usr/share/eclipse/dropins/pluginname/features/feature1/…
/usr/share/eclipse/dropins/pluginname/features/feature2/…
/usr/share/eclipse/dropins/pluginname/plugins/plugin1.jar
/usr/share/eclipse/dropins/pluginname/plugins/plugin2.jar

This structure allows for mixing different versions of libraries that may be needed by different plugins while being clear about which package owns what. It will also avoid conflicts in case different packages provide the same library. The only alternative would be splitting every package from its libraries, with all the extra fuss it requires, and it wouldn’t even be guaranteed to work because of packages needing older library versions.
Features have to be unjarred since Eclipse won’t detect them otherwise, and the whole plugin installation won’t work. This happens because Eclipse treats update sites and local installations differently (don’t ask me why, it just does).

3. The build() function

First thing to be noticed is the cd ${srcdir} command. Usually source archives extract the features and plugins folders directly under ${srcdir}, but this is not always the case. Anyway, for most non-(de facto)-standard plugins this is the only line that needs to be changed.
Next is the features section. It creates the necessary directories, one for every jar file, and extracts the jar in the corresponding directory. Similarly, the plugins section installs the jar files in their directory. A while cycle is used to prevent funny-named files

4. Conclusions

So here it is. I hope it’s clear why I’m proposing to standardize Eclipse plugins, and why I took certain routes instead of others. I know it looks a bit complicated for a prototype PKGBUILD, but I think it’s the best way to handle all the problems I’ve encountered. Comments, improvements and corrections are, as always, very welcome.

So, what is PBR? And do I need it?

Routers don’t usually need to make difficult choices: they often connect a network to another one, for example your LAN to the Internet, and just need the so-called static routing. In simple words, they just look at the recipient of the packet and forward it to the next router on the right channel.
The problem arises when a router is connected to the same network through two or more different channels, and needs to choose which route is the best one based on some predefined criteria. This is what PBR is about. PBR could act, for example, as a load-balancer for high-demand networks, or to route preferential traffic on dedicated channels. We will cover the latter case, since the former is much more trivial to implement.

The right tools for the job

There are two tools we will need to get the job done, iproute2 and iptables: iproute2 takes care of all the routing part, while iptables, traditionally used as a firewall, has the task to tell iproute2 which packets go to which channel.
For simpler cases the sole iproute2 is needed, since it already allows to define basic rules, like discriminating on the sender of a particular packet, but sometimes this is isn’t enough. We want to be able to decide routing for every single packet without limits on the rule to follow. This is where iptables comes into play: it will use its powerful packet matching abilities to mark packages and help iproute2 taking decisions.

Our setup

We will work with a machine that acts as a firewall/router for a LAN and has two available uplinks. The LAN interface will be eth0, while the WAN interfaces will be eth1 and eth2. Let’s suppose we want to route all the web traffic from the LAN through eth1, while forwarding all the rest through eth2.
For simplicity, eth0 address will be 192.168.0.1, eth1 will be 192.168.1.1 and eth2 will be 192.168.2.1. All networks will have a netmask of 255.255.255.0, and their next hop will be a machine on the same network with an IP address of 192.168.x.2.
The LAN will be masqueraded by the firewall/router with iptables, as this is the most common case in home and company networks.

The hard work

Creating the routing tables

First we need to define two new routing tables, one for every outgoing line. Let’s modify /etc/iproute2/rt_tables and add a couple of lines under the local section, so that it looks this way:

#
# reserved values
#
255    local
254    main
253    default
0    unspec
#
# local
#
100    web
200    rest

Here we have defined two tables called web and rest, respectively with an ID of 100 and 200. IDs are arbitrary, just stay within the 1-252 range. I chose 100 and 200 because they allow for further tables to be added before or after them.

Setting up routing

Next step is explaining Debian which routes are available and how routing should be done. The file we need to modify is /etc/network/interfaces, and these are the relevant parts:

auto lo eth0 eth1 eth2
allow-hotplug eth0
allow-hotplug eth1
allow-hotplug eth2

iface lo inet loopback
post-up ip route add 127.0.0.0/8 dev lo table web
post-up ip route add 127.0.0.0/8 dev lo table rest

iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
post-up ip route add 192.168.0.0/24 dev eth0 table web
post-up ip route add 192.168.0.0/24 dev eth0 table rest

iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0
post-up ip route add 192.168.1.0/24 dev eth1 src 192.168.1.1 table web
post-up ip route add default via 192.168.1.2 table web
post-up ip rule add from 192.168.1.1 table web
post-up ip rule add fwmark 0×1 table web

iface eth2 inet static
address 192.168.2.1
netmask 255.255.255.0
post-up ip route add 192.168.2.0/24 dev eth2 src 192.168.2.1 table rest
post-up ip route add default via 192.168.2.2 table rest
post-up ip route add default via 192.168.2.2
post-up ip rule add from 192.168.2.1 table rest
post-up ip rule add fwmark 0×2 table rest

WARNING: the interfaces file doesn’t support end-of-line comments, so don’t use them or you’ll probably break the setup!
WARNING #2: this is just a minimal setup, it’s missing the post-down commands to clean up routing tables and rules, this means that ‘/etc/init.d/networking restart‘ will only make a mess, and you’ll need a reboot or some commands to make everything work again.

What have we done here? After the usual headers, we told our two tables how to reach the loopback interface and the LAN. Then, the fun part: two similar sections were written for eth1 and eth2. The only real difference is in the default route: we want eth2 to be the default, 192.168.2.2 being the default gateway, while eth1 should be a dedicated channel for web traffic.
Four post-up commands, which will be executed as the relative interface come up, are “shared” between the two interfaces. Taking eth1 as an example, the first command defines that this interface is attached to the 192.168.1.0/24 network, that all packets going to that network should have a sender address of 192.168.1.1 and that they should be routed through the table web. The second one says that the default gateway for the web table is 192.168.1.2.
The first rule forces a packet with a defined sender address to come out on the right interface, while the second one routes all packets marked 0×1 through the web table.

Marking packets

If you got through here and your network was successfully started with all the rules, then the worst part is done. Now let’s see where the magic happens: iptables. Our firewall script will have to contain a couple simple rules:

iptables -t mangle -A PREROUTING -p tcp –sport 80 -j MARK –set-mark 0×1
iptables -t mangle -A PREROUTING -p tcp –dport 80 -j MARK –set-mark 0×1

This will ensure that all traffic coming from or going to port 80 will be marked with 0×1, which corresponds to our web routing table. And this is it: iproute2 will see the mark (which is at operating system level, it doesn’t modify the packet in any way), assign the packet the correct source address and route it through the right interface.

Neat, isn’t it?

Conclusions

PBR is a very powerful tool that allows us to define routing in every little detail. Even though it can be a bit hard to setup, it proves to be invaluable in network environments which need a high level of customization, load-balancing or prioritization or certain kinds of traffic.
I hope you had a nice trip, and if you find something is missing or wrong (very easy) just leave a comment, I’ll try to fix it as soon as I can. Thanks for reading

References

• Linux Advanced Routing & Traffic HOWTO: surely the best PBR source around, a bit out of date, though
• Netfilter.org: official iptables documentation
• Linux Networking 2: a router with port forwarding: very good distro-agnostic PBR howto, goes much more in deep than this one, but it’s less practical

Voglio qui chiarificare le cose sul futuro di due PKGBUILD che mantengo in AUR, tcl-devel e tk-devel, che hanno avuto non poco successo principalmente grazie al supporto all’anti-aliasing dei font, che rende aMSN parecchio più guardabile. La versione 8.5 (stabile) è stata finalmente rilasciata, e al momento si trova in [testing], mentre i lavori per la 8.6 (9.0?) non si sono ancora solidificati in una release alpha. Per questa ragione, nel momento in cui tcl e tk passeranno in [extra], i corrispettivi -devel saranno rimossi dall’AUR, in quanto creerebbero più confusione che altro. Vorrei ricordare a quanti mantenessero pacchetti direttamente dipendenti da questi due di preparare delle nuove release che riportino le dipendenze stabili, in modo da evitare casini.

English version:

I want to clarify here the future waiting for a couple of PKGBUILDs I maintain on the AUR, tcl-devel and tk-devel, which had quite a bit of success, mainly thanks to anti-aliased fonts support that makes aMSN a lot nicer. Finally the (stable) 8.5 version has been released, and at the moment it resides in [testing], while works for a new 8.6 (9.0?) still haven’t solidified in an alpha release. For this reason, as tcl and tk reach [extra], the corresponding -devel versions will be removed from the AUR, since they’d just be confusing. I want to remember to those that maintain packages which directly depend on these two to prepare a new release reporting the stable dependency, thus avoiding any mess up.