Vodacom: internetvpn APN

Update This is no longer available, the internet APN has public IPs.

A quick tip for Vodacom 3G / GPRS / EDGE users in South Africa.

There is a special APN called "internetvpn" for laptop users who connect to corporate VPNs. While this probably doesn't interest most readers, it is a useful APN to use because:

  • You get a real Public IP address, not a private NATted one.
  • You get lower latency.
  • The cost is the same. (i.e. regular data bundles work fine)

If you use a VPN, this will probably make it more reliable, and if you don't it will at least make your ssh use more comfortable.

Unfortunately, the following vodacom issues will still be present:

  • No incoming TCP connections (i.e. you can't serve web pages from or ssh into your laptop)
  • Often you get "martian" DNS servers (10.11.12.13 and 10.11.12.14). Either reconnect, or manually set your DNS servers to 196.43.46.190 (SAIX) and 196.207.40.165 (Vodacom).
  • TCP connections are regularly reset. (Overloaded NAT/Firewall hardware?)

How to get it:

  1. Call vodacom customer care (111).
  2. Follow the IVR menu options in the directions of data cards.
  3. Ask them to enable the "internetvpn APN" (you might have to explain it to them)
  4. Reconfigure your phone / chat script / "data card driver" to use "internetvpn" instead of "internet"
  5. Profit! :-)

Aggregator noise and growth

For the bloggers on Clug Park, who don't deign to follow clug-chat or #clug, there have been recent discussions about creating a separate, filtered park for readers with less free time.

The problem is basically that some people post a lot of posts. Sometimes as much as half of the park is dominated by one poster. While this isn't a problem per se (some people clearly have more blogging time), it means readers have more to wade through, and can feel swamped my the prolific posters. Many would prefer something with a higher signal-to-noise ratio, and lower volume.

As communities grow, the signal-to-noise ratio often suffers, and the higher volume is too much for some readers. Rather than lose the readers, we'd like to provide an alternative, filtered park. It's currently being prepared here. Personally, I'll still use the old park, as will many other prolific RSS-feed-followers.

What we need is for all the CLUG Parkers to create a "technical" tag, and tag all relevant posts as such. Then send me the URL of your new tag, and I'll include it in the "park-tech". (Or assure me that you don't post too prolifically, and only tech-related posts, and we'll carry your entire feed).

Lets see if we can make it work.

Easy home transparent proxy

Everyone in South Africa wants to save a little more bandwidth, as low traffic caps are the rule of the day (esp if you are hanging off an expensive 3G connection).

While the "correct" thing to do is to use wpad autodetection, and thus politely request that users use your proxy, this isn't always an option:

  • Firefox doesn't Autodetect Proxies by default
  • Autodetection doesn't behave well for many roaming users (firefox should talk to network-manager)
  • Many programs simply don't support wpad.
  • Your upstream ISP transparently proxies anyway (the norm in ZA), so it's not like we have any end-to-endness to protect.

So, here's how you do it:

  1. Lets assume your network is 10.1.1.0/24, and the squid box is 10.1.1.1 on eth0
  2. Install squid (aptitude install squid), configure it to have a reasonably large storage pool, give it some sane ACLs, etc.
  3. Add http_port 8080 transparent to squid.conf(or http_port 10.1.1.1:8080 transparent if you are using explicit http_port options)
  4. invoke-rc.d squid reload
  5. Add the following to your iptables script:
    iptables -t nat -A PREROUTING -i eth0 -s 10.1.1.0/24 -d ! 10.20.1.1 -p tcp --dport 80 -j REDIRECT --to 8080
    

If you run squid on your network's default gateway, then you are done. Otherwise, if you have a separate router, you need to do the following on the router:

  1. Add a new transprox table to /etc/iproute2/rt_tables, i.e. 1 transprox
  2. Pick a new netfilter MARK value, i.e. 0x04
  3. Add the following to the router's iptables script:

    # Transparent proxy
    iptables -t mangle -F PREROUTING
    iptables -t mangle -A PREROUTING -i br-lan -s ! 10.1.1.1 -d ! 10.1.1.0/24 -p tcp --dport 80 -j MARK --set-mark 0x04
    ip route del table transprox
    ip route add default via 10.1.1.1 table transprox
    ip rule del table transprox
    ip rule add fwmark 0x04 pref 10 table transprox
    
  4. Done: test and tail your squid logs

The reason we use iproute rules rather than iptables DNAT is that you lose destination-IP information with a DNAT (like the envelope of an e-mail).

An alternative solution is to run tinyproxy on the router (with the transparent option, enabled in ubuntu but not debian), use the REDIRECT rule above on the router, to redirect to the tinyproxy, and have that upstream to the squid. But tinyproxy requires some RAM, and on a WRT54 or the likes, you don't have any of that to spare...

Should you need to temporarily disable this for any reason:

  • With all-in-one-router: iptables -t nat -F PREROUTING
  • With the separate router: iptables -t mangle -F PREROUTING

On Eskom

Anybody who resides anywhere near the mother city, will know about the horrific load shedding we are suffering at the moment. (Actually, I think the whole country may be affected, but I haven't read any local news recently).

This means:

  • Massive traffic jams: All traffic lights turn into 4-way stops, and if that wasn't slow enough, people crash into each other out of anger.
  • At least 2-hours every day of sitting and twiddling your thumbs, while listening to the screech of unhappy UPSs. (Occasionally this overlaps with lunch time)
  • Having to shout over the roar (and cough through through the stench) of generators when you go out to visit any such-equipped businesses.
  • Peaceful, inky-black skys, and no noise of neighbour's TV sets at night (if you are lucky enough to be load-shed at night).
  • Cold supper.
  • A flat laptop, unless you make sure to keep it fully charged against such emergencies.
  • Breakage in various systems, when UPSs don't transfer cleanly, and routers / switches decide to disagree.
  • Various networks (like UCT) become unreachable, because while they have gensets and UPSs, the telkom equipment connecting to the outside world don't.
  • And, generally, a very grumpy tumbleweed.

I've been frequenting computer suppliers in the last week, and seen an insane amount of UPSs first piled up at the dispatch desks, and then vanish. Now is the time to be in the UPS and genset -selling business.

To make things worse, this morning, I decided that I'd have to dismantle my gate-motor, to get out of the driveway. (Because nobody knows where the key for the manual-override lever is. After getting half-way, I worked out that it had a backup battery. Duh!

Gate: 1, Eskom: 1, Geek: 0.

Some Wiki Updates

I've just spent an afternoon and evening on the local wikis I look after: CLUG, Freedom Toaster, and GeekDinner.

They've all been upgraded to MediaWiki 1.11.0, with reCAPTCHA on sign-ups, and OpenID support.

If you are a user of one of these wikis, you can go to Special:OpenIDConvert (CLUG, FT, GeekDinner) to add OpenID to your account.

In the past, the CLUG wiki has had minimal wikispam, because we thought up some clever regexes, that blocked spammers from editing. However spammers would still sign up, before they tried to edit. This has left the wiki with over a thousand bogous users. Not that that is a problem in itself, but it becomes a bore when you want to guess somebody's wikiname to give them "Bureaucrat" status for example.

So jerith talked himself into coding up a quick SQL query to find all these bogus users, and a python script to remove them. Any history they've had has been assigned to the "Spammer" user, and they have been wiped from the wiki. If, in our zealousness, we've deleted any legitimate users who've simply never edited the wiki, we apologise. Maybe if you contribute something, it won't happen again... :-)

Drupal Migration

As should be obvious to non-feed readers, I've migrated my blog to Drupal. This fits in with my greater plan of organising myself and moving into digs this holiday. Drupal is an awesome CMS - or maybe a better description is "the only decent CMS". I've set up and maintained a few drupal sites, and have been very impressed with it.

I've yet to migrate all my previous blog-posts across, but by the time you see this post, that'll be done. Vhata has walked this road before me (albeit from Serendipity), and I intent do follow his advice.

In the past, I mantained my Wordpress blog as an SVN install. This allowed me to install plugins with svn:externals, which made upgrades a doddle. Drupal uses CVS, so this approach wasn't an option. After months of procrastination, I investigated config-manager. With it, I built a recipe for downloading drupal and all the modules I use with it. Then I committed this as a bzr tree, so that I could base all my sites on a common base. To install a module, I bzr mv modules/foo drupal/sites/all/modules/.

Now to update all my drupal sites, I update my config-manager recipe, and build a new master tree. Commit it to the repo, and push to launchpad. And then bzr merge in all the sites. It's pretty quick and painless.

For anyone who's interested, the modules I'm using are:

So far I've had to write a drupal module to support amatomu, and it was a bliss. Drupal's API and code is some of the neatest PHP I've ever had to work with.

I think I'll be happy here :-)

That was *camp

I'm now sitting in Arniston, on a horribly slow GPRS connection, after *camp, which was this weekend, at AIMS. It was a BarCamp-like "unconference", organised by the geekdinner crowd. I put off having the weekend at Arniston for *camp, and for me, I think that was worth it.

The event was really good. I haven't been very involved in the organising, and didn't come prepared with a talk (just equipment). At the start, it felt like there were never going to be enough talks to keep us going, but as soon as it started, it began rolling, and continued for 2 days. The talks were varied, from technical, to psychological, to practical. I was really impressed. The quality of the talks was quite high - I was rarely bored (although I did have IRC distractions).

As usual, I had Jonathan Carter's camera, and videoed everything. I'm going to go home to around 8 hours of video that needs editing, synchronizing, encoding, and uploading to archive.org. It'll take a while, guys, be patient.

Today, I got involved with setting up the lab for practical demos. We had 9 PCs lent, and needed Ubuntu on them. Of course, the natural approach is netinstall - I'm familiar with netinstalling Ubuntu, and it is a great way to set up a pile of computers. However, we ran into problem after problem.

  1. We were using dnsmasq (on my laptop) for DHCP and TFTP, but it wasn't the router. So I set the router DHCP option. This seemed to break dnsmasq - PCs stopped accepting leases and DHCPDECLINED them. I've never seen that before. So I had to route through my laptop - no biggie.
  2. AIMS is behind a 400kbps connection, and while thy have an apt-cacher, it seemed badly seeded, and it looked like it was going to take us hours to install, so I went to my car and collected a set of Ubuntu archive DVDs that I happened to have on hand, and loaded them via a cluster of laptops and rsync ;-)
  3. Of course those DVDs didn't have udebs on them (the debian-installer bits and pieces), so I had to quickly write a script to download all the udebs, and their necessary support structure.
  4. Now the machines netboot installed really fast, but at the very end of the install, it failed, due to some package signature problem.
  5. I ran debmirror, to ensure that my mirror was up to date, and it was. I ran the md5 sum checks, and they passed. I have no idea what the problem was.
  6. Eventually, the lab was installed with 3 install CDs, and then clubbed into shape with clusterssh. 5hrs or so after starting - what a waste of time, we should have started with CDs...

So, lesson for next time, test your netboot setup in advance, don't assume that a mirror will be in working shape. We should have set up the lab on day one, for use on day 2.

The upshot of this is that I didn't see any talks today (excepting a practical in the lab, on scribus, once it was up). I'll have to watch the videos later.

Now, I'm going to enjoy a few days in Arniston, and then come home to graduate.

Multiple IP addresses on Debian

Quick post. If you have multiple IP addresses (i.e. a range) assigned to you server, and you want to listen on all of them (i.e. multiple SSL sites), then rather than using the ancient eth0:1 syntax, you can hack /etc/network/interfaces to use iproute2 properly.

Assuming the IP 10.2.3.4, with the extra range of 10.5.4.110-10.5.4.118 (yes these extra ranges often ignore class-boundries):

auto eth0
iface eth0 inet static
    address 10.2.3.4
    netmask 255.255.255.0
    network 10.2.3.0
    broadcast 10.2.3.255
    gateway 10.2.3.1
    # Extra IPs:
    post-up for last in `seq 110 118`; do ip addr add 10.5.4.$last/32 dev $IFACE; done || true
    pre-down for ip in `ip addr show dev $IFACE | sed -n 's@.* inet \([0-9.]*/32\) .*@\1@ p'`; do ip addr del $ip dev $IFACE; done || true

Yes, it's ugly as shit, but I can't think of a neater way to do it.

Update: Better solution

Graduation isn't straightforward

I haven't blogged in a while, since exams are now over, and I have less urgent procrastination needs. I maintained an average of more than 1 post / day at the hight of my studying :-(. In fact, I've been recovering from exams, and trying to catch up with the rest of life that I had to put on hold all year. And more recently, an insane RSS feed and e-mail build-up from a week of ignoring them while I was catching up with my life.

So, no posts doesn't mean life has been uneventful. I've been:

  • out almost every night last week
  • picked up wall climbing again (thanks Ken) and through it found some people I haven't seen in ages (Hi Chris)
  • elected the Chairman of CLUG
  • involved in a spat with ICTS (the topic of a future post)
  • spending at least a day encoding GeekDinner videos (using Makefiles to allow encode video in parallel on dual core machines, and using a handful of machines to do the work saves a lot of time), and finally
  • almost not graduating. (the rather ranty point of this post)

This was my third your of an Information Technology BSc (specifically Computer Science and Electrical Engineering). I've had good results most of the time, but I'm not class medal material.

In first year, I slept through almost all of my Statistics lectures (3rd lecture in day, after an insanely early start - I was usually exhausted, and well primed for sleeping). Come the end of the year, somehow, I didn't realise how meagre the exam's formula sheet was going to be, and failed the course horribly. I swore I'd never do Stats again, making up the points with another, more interesting course. I didn't get a chance to do this in 2nd year because I failed and had to repeat another course due to bad timing between deadlines and my best friend's tragic death in a hiking accident.

This year, I had a reasonably heavy course load, with the 3rd year CS courses, and a composite EE course made up of two 3rd year, and a 4th year course. On top of this, I had to fit in something extra to make up Stats. The only extra course I could schedule was... Stats. I spent an afternoon running around, and computing schedules, but there was no alternative.

This time around, I actually enjoyed the Stats - it was (partly) very well lectured, and I already knew the basics of the course-work. I read the textbook, crammed the necessary formulae for the exam, and wrote it, all a monstrous 6-hrs-of-exams day. And that, I thought, was that.

I kept myself busy for the next couple of weeks, and then wondered to UCT on results-day, to see what I'd got. I was top of the (admittedly small) class for my EE, and scraped a 1st in CS, great! Next I head to stats, and I see "DPR" next to my name instead of a mark.

DPR means that I didn't complete the require coursework. The list of who got DP (Duly Performed), and who didn't (DPR) goes up a week or so before exams begin. Somehow I hadn't noticed that I hadn't got DP (I'm pretty damn sure that I checked the relevant noticeboard, I'm good like that). DPR means don't write the exam, it won't get marked, you've already failed. But somehow it'd escaped me, and I'd written it, and now I was not going to graduate. I couldn't believe that I was DPRed, but it was possible - I'd screwed it up before, and could have failed all the tests (I'd hadn't seen all the test results yet).

So, the next morning, I raced off to see the Stats course convenor. We sifted through paperwork, and found the problem - I didn't have a mark for one of the tests, and for DP you need to write all the tests. Eventually we found the attendance slip that proved I had written it, which meant either I'd escaped the test venue with my test-paper, or the department had lost it before it was marked. Fortunately, my exam had been marked, I'd passed, and they believed that I'd written the test. So after an agonising day's wait, I heard that the Head of Department had approved passing me, as if I'd missed that test on medical grounds. I've since heard that University policy dictates that the department must take the blame unless they can prove it was me (it wasn't).

Phew.

That doesn't mean everything is solved yet, I was recommended to do an elective in 1st year, that is now no longer sanctioned for my course. It usually causes me hassles during registration, and might come up again now, but I think I can safely assume I'm graduating...