Those of us in the sensible quadrant of the graph are rather worried about the distance that some people are from us. I mean, they must be total nutters :-)
To help them understand the incorrectness of their ways, Jonathan suggested that we write up our choices and reasoning. I haven’t read anyone else’s reasoning yet, but here is my reasoning for each choice in the test. It might well be different to the last time I did it, but that’s probably caused by me thinking about my choices rather than the embarrassment of publishing them. (I’m right, remember). On
#clug, we acknowledge that peoples’ views change and keep a history of past scores, although the graph doesn’t display that (nudge nudge Michael).
If you haven’t done this test, and are interested, maybe take it before you read any further. It’ll take you less than half an hour, and promises a little food for thought.
Economic Left/Right: -4.62
Social Libertarian/Authoritarian: -6.26
I’ve moved fractionally up since I last took the test (-4.62, -6.41) that’s it. Now I can go and read other peoples’ justifications for their choices.
My post on split-routing on OpenWRT has been incredibly popular, and led to many people implementing split-routing, whether or not they had OpenWRT. While it's fun to have an exercise as a reader, it led to me having to help lots of newbies through porting that setup to a Debian / Ubuntu environment. To save myself some time, here's how I do it on Debian:
Background, especially for non-South Africa readers: Bandwidth in South Africa is ridiculously expensive, especially International bandwidth. The point of this exercise is that we can buy "local-only" DSL accounts which only connect to South African networks. E.g. I have an account that gives me 30GB of local traffic / month, for the same cost as 2.5GB of International traffic account. Normally you'd change your username and password on your router to switch account when you wanted to do something like an Debian apt-upgrade, but that's irritating. There's no reason why you can't have a Linux-based router concurrently connected to both accounts via the same ADSL line.
Firstly, we have a DSL modem. Doesn't matter what it is, it just has to support bridged mode. If it won't work without a DSL account, you can use the Telkom guest account. My recommendation for a modem is to buy a Telkom-branded Billion modem (because Telkom sells everything with really big chunky, well-surge-protected power supplies).
For the sake of this example, we have the modem (IP 10.0.0.2/24) plugged into eth0 on our server, which is running Debian or Ubuntu, doesn't really matter much - personal preference. The modem has DHCP turned off, and we have our PCs on the same ethernet segment as the modem. Obviously this is all trivial to change.
You need these packages installed:
You need ppp interfaces for your providers. I created
unit 1 makes a connection always bind to "ppp1". Everything else is pretty standard. Note that only the international connection forces a default route.
/etc/ppp/pap-secrets I added my username and password combinations:
You need custom iproute2 routing tables for each interface, for the source routing. This will ensure that incoming connections get responded to out of the correct interface. As your provider only lets you send packets from your assigned IP address, you can't send packets with the international address out of the local interface. We get around that with multiple routing tables. Add these lines to
Now for some magic. I create
/etc/ppp/ip-up.d/20routing to set up routes when a connection comes up:
That script loads routes from
/etc/network/routes-local-dsl. It also sets up source routing so that incoming connections work as expected.
Now, we need those route files to exist and contain something useful. Create the script
/etc/cron.daily/za-routes (and make it executable):
It downloads the routes file from cocooncrash's site (he gets them from
local-route-server.is.co.za, aggregates them, and publishes every 6 hours). Run it now to seed that file.
Now some International-only routes. I use IS local DSL, so SAIX DNS queries should go through the SAIX connection even though the servers are local to ZA.
/etc/network/routes-intl-dsl contains SAIX DNS servers and proxies:
Now we can tell
/etc/network/interfaces about our connections so that they can get brought up automatically on bootup:
For DNS, I use dnsmasq, hardcoded to point to IS & SAIX upstreams. My machine's
/etc/resolv.conf just points to this dnsmasq.
So something like
If you haven't already, you'll need to turn on ip_forward. Add the following to
/etc/sysctl.conf and then run
sudo sysctl -p:
Finally, you'll need masquerading set up in your firewall. Here is a trivial example firewall, put it in
/etc/network/if-up.d/firewall and make it executable. You should probably change it to suit your needs or use something else, but this should work:
I apologise for my last post on this topic, it probably wasn't very interesting :-)
I've done the Drupal 6 upgrade, and it was relatively painless. Most modules ported smoothly, a few required me to learn how to port modules to Drupal 6, and one I just gave up on.
On the whole, the porting is simple, Druplal.org has a pretty good howto on the topic. A few APIs have changed, and that's about it. A great tool to help with this is the coder module, which knows about the API changes, as well as Drupal's coding standards.
I've added the GeSHi module for code syntax highlighting (apologies for the planet-spam caused by this), and I've moved from marksmarty to markdown + typogrify (which I had to port to Drupal 6). I'm not too happy with the geshi colour-scheme and indenting, but it does a good enough job. I should write a "command prompt" mode for it, but that can wait for now...
Akismet is currently totally broken for Drupal 6, even if it's labelled as being in beta. I got about half way through porting it before giving up and switching to mollom, which looks like a pretty good replacement (and it takes care of the sign-up form too).
Finally, the subject of input-filters. Drupal lets you define a "default filter", but that filter has to be available for everyone, even comments. So your default filter has to protect against XSS. I'd much prefer it if commenters used a simple, locked-down input-format, and I used a nice markdown format.
I'm not the only one to notice this, and it seems like it'll be fixed in Drupal 7. Until then, I'm using remember-filter which remembers that I use markdown, and all the commenters use the default, locked-down filter. (Again, ported.)
For those of you who are wondering what my recent Google Reader shared item comment was all about, here you go. I’ve explained it over IM twice, and I think it deserves a proper blog post:
We all like having RSS-feeds for everything, right? That way we can catch up with the world in one place.
So Facebook have RSS feeds for friends’ status updates, notes, and shared posts. These feeds look something like
http://www.facebook.com/feeds/friends_status.php?id=530720481&key=0dead0beef&format=rss20. And all the feeds have the same key.
Yes, we’d rather they used HTTP-Digest password authentication, but not many RSS readers support that, and you’d never give anyone that feed url, right?
Well, no. If I read something cool in one of these Facebook-feeds in Google Reader and I share it with my Google Reader friends, they’ll all get the full feed URL. Now they can read all my friends’ status updates, notes, and shared items.
One of my Facebook friends might be paranoid, and writing about very personal stuff on Facebook. As a Facebook user, he could have set his privacy settings so that only his friends can read his notes. However, now all my Google Reader friends can too.
In this case, this isn’t a big problem, because there’s very little interesting content on Facebook, and hopefully no trade secrets. Obviously these problems apply to services besides Facebook and Google Reader, but these are good examples. Also a friend of mine shared his key recently ;-)
But it gets worse, Google Reader has a feed directory and feed discover page. Searching it reveals lots of such ID, key combinations. And generally Googling reveals 30-odd such pairs that have leaked onto the general Internet.
So. If you are implementing RSS feeds with private data in them, please don’t use an in-URL key. Rather submit patches to all your favourite feed-readers adding support for HTTP-authentication (and in the case of Google Reader, maybe don’t use it for private feeds).
I had to patch a few modules for Drupal 6 support, but it’s really easy to do. I only waited this long because most of the modules I used took a while to get Drupal 6 support, but in retrospect, I needn’t have.
I host a few websites for various people and causes using Drupal, as described here. Now I’m feeling the urge to work on Drupal stuff again, and hope to make some big improvements to this site soon. I’m thinking Activity Stream type stuff for a start (thanks Vhata).
In other news, I have been helping a house-mate set up a website for his magazine in WordPress. I’m amazed how much PHP you need to mangle to get wordpress to do what you want. Watching someone who has no programming experience at all do this stuff can be both entertaining and depressing. What a terrible introduction to programming… The WordPress API scares me, it uses URL-encoded parameters to many functions for a start. And php isn’t exactly a well-designed language.
Well, I suppose I learned to program in BASIC 2.0 - everyone has to start somewhere…