Showing posts with label linux. Show all posts
Showing posts with label linux. Show all posts

Friday, January 14, 2011

Selective load balancing with Squid and iproute2

Recently I was asked by a client to develop a load balancing solution over two of their ADSL lines, but only for http traffic, and only for specific users. Sounds like a pain in the ass, right? Well, it was.

Essentially they've got four ADSL links:

  • eth0: 111.111.111.111 (main uncapped line)
  • eth1: 100.100.100.11
  • eth2: 100.100.100.22
  • eth3: 100.100.100.33

eth0 is the default route where all traffic goes through, and eth3 is used for something else.

They're using Squid as their proxy server, and want all traffic for a specific Squid ACL (let's call it "employees") to be load balanced between eth1 and eth2.

My biggest worry was in how to set this up without having to alter the default route on the system, but - as is always the case with Linux - there is a way if you look hard enough.

My first thought was to use iptables to mark packets, then set up an iproute2 rule to pick up on those packets and forward them to the relevant routing table. Unfortunately, the best one could do with this method is manipulate all http traffic, however, as mentioned, only the traffic for specific users must be load balanced.

Obviously, this method won't work.

The key to the solution is Squid's TCP_OUTGOING_TOS configuration directive. This directive allows one to set the TOS value in outgoing IP packets on a per-ACL basis. What this means is that if you have an ACL called "employees", you can have all traffic generated by the users in that ACL have the TOS set to an arbitrary value. You can then use an iproute2 rule to pick up on all packets with that value set and do whatever you want with them. Bingo!

Firstly, we need to create three routing tables: ADSL1, ADSL2 and BALANCE. This is usually done in /etc/iproute2/rt_tables.

Then we begin adding routing information:

# Assumes 100.100.100.10 is the address of the router on eth1
ip route add 100.100.100.9/29 dev eth1 src 100.100.100.11 table ADSL1
ip route add default via 100.100.100.10 table ADSL1

# Assumes 100.100.100.21 is the address of the router on eth2
ip route add 100.100.100.20/29 dev eth2 src 100.100.100.22 table ADSL2
ip route add default via 100.100.100.21 table ADSL2

Now we add some rules

# eth1 traffic goes to table ADSL1
ip rule add from 100.100.100.11 table ADSL1

# eth2 traffic goes to table ADSL2
ip rule add from 100.100.100.22 table ADSL2

# Squid sets desired traffic TOS. Marked traffic goes to table BALANCE
ip rule add tos 0x0c table BALANCE

And finally we create the multilink route in the table BALANCE.

ip route add default scope global table BALANCE nexthop via 100.100.100.10 dev eth1 weight 1 nexthop via 100.100.100.21 dev eth2 weight 1

Then finally, in your Squid configuration, simply add the configuration directive

tcp_outgoing_tos 0x0c employees

That's pretty much it. iptraf confirms that all http traffic for the desired ACL gets balanced over eth1 and eth2. Obviously the load balancing won't be perfect due to route caching, etc. But it probably is the most beautiful solution possible without splashing out on a pricey Cisco router or some such.

For more information, be sure to read the Linux Advanced Routing & Traffic Control HOWTO.

Friday, September 11, 2009

Proposal for a new source code measurement unit

Preface.

With the pace and scale of modern software development being what it is, it is very rare to find any application beyond university projects and weekend hack-jobs that amount to fewer than hundreds of thousands of lines of code in source form.  The truth is that the measurement Source Lines Of Code has become about as efficient and logical as measuring the distance between stars, not in parsecs, but in kilometers.

Proposal.

What, then, could we use as the programming equivalent of the astronomical parsec?  I propose the unit torvalds, uncapitalised to differentiate it from the name, to represent 200,000 lines of code.  Shortened to Tr with an initial capital to differentiate it from the Unix tr command.

Rationale:

Linus Torvalds, the creator of the Linux kernel, and an outspoken man in his own right, has many critics.  Recently, there's been a trend among those wishing to criticize the quality - or worse, the magnitude - of his contributions of pointing out the fact that only 2% of the kernel source code was actually written by him.  This may be true by certain estimates, but invariably they leave out the context:  that the kernel currently (as of version 2.6.30) comprises 11,637,173 lines of source.  That's almost twelve million lines of source code.  Since the first mention I could find of this fact references an unspecified minor revision of the 2.6 kernel, I'd say a safe estimate places the then-current kernel size at 10 million lines.

By this measurement, Linus' contribution of 2% amounts to roughly 200,000 lines of code which, by any individual standard, is substantial.

Examples.

  • The Debian 4.0 distribution, at 283 million lines of code, amounts to 1415 torvalds (Tr).
  • Mac OS X version 10.4, at 86 million SLOC, equals 430 Tr.
  • The FreeBSD operating system which totals 8.8 million lines, comes to 44 Tr.

Thursday, September 10, 2009

Linux 2.6.31


Linux 2.6.31 has been released.  Read Linus' announcement on the Kernel Mailing List.

Important updates include:
  • USB 3.0 support.
  • FUSE extension that can be used to, for example, "proxy" OSS audio through the ALSA userspace layer allowing it to be used as a replacement for the in-kernel ALSA OSS emulation layer.
  • ATI Radeon Kernel Mode Setting support.
  • Improved desktop performance under memory strain.
  • 802.15.4 support
  • Fsnotify.  A backend for filesystem notification.
  • Preliminary NFS 4.1 client support
  • Context Readahead algorithm and mmap readahead improvements.  Benchmarks show cooperative IO performance gains of up to 40%.
  • Much more!
Personally I'm happy to see some updates to the aes-ni crypto module, and improvements to Radeon and Intel graphics support.  Soon we'll see open source drivers with great performance for all graphics hardware.  If only Nvidia would stick its binary blob up its ass, and follow Intel's example of releasing an open source driver.

Saturday, September 05, 2009

Bash prompt fun

Like your sexual preference, your taste in wine, or your favourite Backstreet Boy, your shell prompt is a very personal thing and can say a lot about you.

Some old-school hackers prefer the minimal '$' you get by default with, for example, pdksh, and whine that any information displayed by the shell prompt is better gleaned from running a relevant command when needed.  For example, instead of having the current working directory on your screen at all times, just type pwd when the need arises.  This is perfectly fine if it suits your needs and circumstances, but these differ from user to user.

Unix users can generally be divided into two groups when it comes to their taste in shell prompts: the putter-inners and the taker-outers.  The taker-outers go minimal; removing what they see as cruft from their shell prompt.  They feel that maximum screen real estate should be given to the output of commands, and anything that diminishes this or distracts from the output - such as escape sequences and colours - should be removed.  When taken to the extreme, this results in a user who needlessly types commands from time to time when he could have comfortably fit the relevant information into his shell prompt.

The putter-inners, however, are in danger of adding so much needless crap into their shell prompts that they're in danger of melting their CPU everytime they hit Enter.  I am a putter-inner.

My shell of choice is Bash, and due to my personal requirements there are some elements I insist on having in my prompt.  Before we get to that, though, an obligatory screenshot of my prompt in action:



Okay, it's not pretty but I like it and it gets the job done.

Firstly, I like having a colour prompt.  Some people find it distracting, but to me the colour neatly separates the prompt itself from the output of a command.  I use a multi-line prompt because, even on the rare occasion I'm not in X, I'm using framebuffer console so my terminal window is always large, thus there's no shortage of screen space.  This allows me to have a lot of information in my shell prompt without constantly having to flick my eyes from right to left on the screen.

As for the contents of the prompt, I'm always on the network so I like having my user@host visible.  I use history commands so I want the history number visible, too.  The next number is the number of jobs the shell is currently running.  Since I use Emacs and Ctrl-z a lot, this is quite important to me.  Similarly, I am often using GNU Screen, so I have the current TTY echoed as well.  The red exclamation mark only shows if the previous command exited with a non-zero status.  Since I'm often debugging code, this is crucial.  The last element on the next line is, obviously, the current working directory.  I need this as I am always moving around in my directory tree.

Some common prompt elements I don't use are the time and/or date (if you need to be reminded of the time - or even worse, the date - each time you hit enter, your shell prompt is the least of your problems), and the familiar UID character ('$' or '#') as I am very much a sudo advocate.

The code in my .bashrc for the above prompt follows:

# Multi-line prompt to display: 1. user@host; 2. history number
# of the current command; 3. number of jobs; 4. tty;
# 5. exit status of previous command; 6. working directory
#
# "\033(0" drops term into line-drawing mode. "\033(B" takes it out.

function sweet_prompt {
local cur_tty=$(temp=$(tty) ; echo ${temp:5});
local LIGHT_RED="\[\033[1;31m\]"
local LIGHT_GREEN="\[\033[1;32m\]"
local LIGHT_BLUE="\[\033[1;34m\]"
local NO_COLOUR="\[\033[0m\]"
PS1="$LIGHT_GREEN\033(0\154\161\033(B$LIGHT_BLUE($LIGHT_GREEN\u$LIGHT_BLUE@$LIGHT_GREEN\h$LIGHT_BLUE)$LIGHT_GREEN-$LIGHT_BLUE($LIGHT_GREEN\!$LIGHT_BLUE-$LIGHT_GREEN\j$LIGHT_BLUE-$LIGHT_GREEN$cur_tty$LIGHT_BLUE)$LIGHT_GREEN\033(0\161\161\033(B\`if [ \$? = 0 ]; then echo \[\e[34m\]]\[\e[0m\]; else echo \[\e[31m\]!\[\e[0m\]; fi\`$LIGHT_BLUE\033(0\176$LIGHT_GREEN\161\176\176\033(B\n\033(0\155\033(B$LIGHT_BLUE($LIGHT_GREEN\W$LIGHT_BLUE($LIGHT_GREEN\033(0\161\176$LIGHT_BLUE\176\033(B$NO_COLOUR "

PS2="> "
}

Ugly, I know, but I don't have the inclination to de-spaghettify it.

I use rxvt-unicode as my terminal emulator with the Terminus font (the best monospaced font ever.  Perfect for those who stare at the screen for 8+ hours a day).  I can't guarantee that the above code works under different circumstances.

Thursday, September 03, 2009

Why I hate Eric Raymond

Eric Steven Raymond (who likes it when people call him "esr" for pretty much the same reason I'd like it if people called me Optimus Cal) is a self-professed hacker.  I use the term "self-professed" with more than a dash of snark here, because anyone who consciously and unironically refers to themselves as a hacker in today's world is on par with those who publicly label themselves geniuses - presumably because nobody else can do so with a straight face.  In short, something of a sexually unappealing Kanye West.

Eric has been active in hacking circles since the seventies, and has been actively promoting the open source movement since it started, well, moving.  He is also the current maintainer of the legendary Jargon File.  I have a lot of respect for Eric for these - and other - positive contributions.  Unfortunately, this respect is outweighed by the simple fact that Eric is a giant douchebag.

This dislike is born from a number of reasons, mainly Eric's...

1. Overinflated sense of self-importance.

Eric describes himself as one of the most significant figures in the history of free software.  In his own words, "Today I'm one of the half-dozen or so most influential people in that movement; in fact, a lot of people would put me among the top three, with Linus Torvalds and Richard M. Stallman."

That's a very bold statement, and you would expect the person who makes it to be (in addition to an asshole) a talented coder who has authored software that can be listed alongside a kernel estimated to be worth $1.14 billion USD, or one of the most popular compilers on Earth.  However, probably Eric's primary contribution in the form of actual code is originally authoring the fetchmail utility: a mail client whose poor design and security holes have been criticized by, among others, one of my personal heroes, Daniel J. Bernstein.

More hubris: "I either founded or re-invented [...] the open source movement.  If that term means nothing to you, think Linux... "  I just love the subtle implication that Eric's actually had a direct and significant role in Linux development.  That's logic from the Steve Smith school of reasoning: "I've met Linus, Linus created Linux.  By the transitive property, I created Linux.  Algebra's awesome!"

In reality, though, Eric's main attempt at a contribution to the Linux kernel was in the form of CML2, a code configuration system, which was rejected by the kernel development team and the original CML was eventually replaced with LinuxKernelConf.  The possibility that it simply wasn't good enough being incomprehensible to him, Eric blamed the rejection on "politics."

2. Political views.

Eric calls himself an anarcho-capitalist (one of those terms freshman political science students call themselves until the second semester when they actually learn what the fuck they're talking about) and a libertarian.  This is especially rich considering his support for the war on Iraq.  He also called for an "imperialist" campaign to "civilize" the Muslim world.  A rather significant personal stance that is conspicuously absent from the later revisions to his Wikipedia article.

He is also a bit of a gun nut, which I have little problem with, but it does become more than a little creepy when you consider that he privately threatened Bruce Perens to the point where Perens feared for his safety.  Again, suspiciously absent from Wikipedia.

3. Social views.

Eric believes that IQ distribution among women does a better job than cultural sexism of explaining why the high achievers in most fields are male ("get back in the kitchen!"), and - possibly more explosively - that African Americans are responsible for a disproportionate percentage of crimes because they have lower IQs:

"In the U.S., blacks are 12% of the population but commit 50% of violent crimes; can anyone honestly think this is unconnected to the fact that they average 15 points of IQ lower than the general population? That stupid people are more violent is a fact independent of skin color."

His views on homosexuality are equally repulsive, equating homosexuality with pederasty and pedophilia.

I can see why Eric decided to develop fetchmail in the first place: he probably didn't want any mail he sent or received to be touched by a piece of software written by a gay man, so he attempted to author a sendmail replacement, couldn't wrap his head around UUCP, and just gave up and wrote a mail retrieval agent instead.

4. Fucking up the Jargon File.

Many hackers feel that after taking over maintenance of the Jargon File, Eric began to change it to reflect his own warped political views and personal agendas.  He has shifted the tome's focus away from early, pre-Unix hacker culture, added words to the glossary that nobody except he has ever used, and - among other controversial edits - changed the description of hacker politics from being "vaguely liberal-moderate" to the more Eric-centric "moderate-to-neoconservative."  The Holy Bible of hackish culture has been reduced to being Eric's personal vanity document.

In conclusion, I can't say it any better than one of Eric's many fans once did on Wikipedia.  Eric, you are an asshole.

Thursday, September 11, 2008

Brown Ubuntu: It's not that bad, really!

Ubuntu has taken quite a bit of flack from the get go for its, uhm... unique... default colour scheme; mostly because the overarching colour of the theme is brown. Now, I myself am quite partial to it. It's warm, welcoming, and a departure from the same old blue- and silver-based themes with which most other operating systems seem to roll off the assembly line. This default theme has been tweaked throughout Ubuntu's various releases, but the main colour palette still remains based around the colour brown.

My current (at time of writing) Ubuntu Linux desktop.
I've thus far been rather indifferent to this particularly nasty brand of prejudice... Until it made its way onto my own doorstep. Judging me by the colour of my skin is one thing, but judging me by the colour of my desktop? Well, I'm afraid that's just going too far.

A sagacious relative of mine bombasted his corpulent cuerpo into my bedroom on a recent visit, and spied my Ubuntu desktop (sporting a modified, but still very much brown, theme). The first words echoing from out of his abysmal estuary described my desktop as "looking like shit." Not in a metaphorical sense, mind you, but in a very literal, faecal one. I shrugged it off and distracted him by tossing an animal cracker down the hall. Nevertheless, this got me thinking. Why would the first thing someone thinks of, when seeing the colour brown, be shit? There's nothing inherently shitty about the colour brown - though, I concede, there's something inherently brown about shit.

When I think of the colour brown, the first thing that pops into my head is chocolate. Something which is a treat: A delicious luxury to be sampled only by the most deserving. Wouldn't this be a very clever - or at least marketable - way to describe a great operating system? Think of a high quality, free operating system as being analogous to a neverending river of chocolate. The former being as much a pleasure to use as the latter is to eat. Except that Ubuntu won't cause you to get fat (in theory). Nor cause you to become diabetic and lead you to a lifetime of health problems and an early death. Okay, come to think of it, maybe chocolate isn't such a marketable analogy, but hey, at least it's not shit.

Another thing that comes to mind when I think of the colour brown is coffee. A delicious beverage with a history as rich as its flavour, and with as many varieties as it has fans; one for every palate. A universally beloved infusion which is welcoming enough to be accessible to the casual drinker, yet still full and complex enough to please the connoisseur. A drink equally at home and appropriate in a professional atmosphere as in a casual one, a pot of which not being out of place in either a cosy room with a few close friends, or the boardroom of a Fortune 500 company.

Wouldn't that last paragraph, awkward though it may be, describe Linux with equal comeliness? Of course it would, because it does.

What it comes down to is that those who attack Ubuntu for adopting a brown default theme for their Linux distribution are really just highlighting their own short-sightedness. Clearly, they feel the need to beset those who dare deviate from the norm of cold, sparse themes which are about as homely as an operating theater.

Your choice of themes, much like your choice of sexual partner, is an individual thing and entirely your own business, but it seems irrational to attack Ubuntu for using a brown default theme, given its warmth, neutrality and individuality.

Mark Shuttleworth has written a great defense of the choice of brown for the default Ubuntu theme, clearly explaining the motivation.

As requested, here's a link to the GTK Dust theme.