Upgrade Ubuntu from Hardy Heron to Intrepid Ibex – No Release Upgrade Button in Update Manager

I wanted to upgrade my work machine to Intrepid Ibex (Ubuntu 8.10) from Hardy Heron (Ubuntu 8.04), but the update manager was not showing the distribution/release upgrade button. This is due to 8.04/Hardy being an Long Term Support (LTS) release, and 8.10 (Intrepid Ibex) not. Therefore, you’ll first need to enable distribution upgrades in the ‘Software Sources’ settings applet. I followed the instructions here, but the basic idea is thus:

  1. Open ‘Software Sources’ by following these menu choices: System -> Administration -> Software Sources
  2. In the Software Sources applet, select the ‘Updates’ tab
  3. In the section at the bottom entitled ‘Release Upgrade’, select ‘Normal’ from the dropdown menu.
  4. Click the Close button, and let it update your apt package lists

After following these instructions and opening Update Manager, I was still not seeing the release upgrade button. I ensured that my packages were up-to-date, and upgraded anything that needed it, restarted several times, but still no release upgrade button! Ahhh!

Thankfully the solution is simple, you just need to start update-manager with the -d flag in a shell:

user@box$ update-manager -d

This will open up the manager and after a clicking the ‘Check’ button (to update the package list), the upgrade button was showing. Hooray!

jQuery.com – Those Mouse-over Tooltips are BAD

jQuery is a good thing. It allows you to minimise the amount of Javascript you write, while maintaining elegance and ease-of-use. jQuery.com has recently relaunched with a brand-new design. Feedback from around the web was initially quite negative due to a bizarre decision by someone who thought it’d be great to apply a ‘rockstar’ ethos to the whole redesign. The new landing page initially had a horribly misplaced drawing of a rockstaresque character splattered across the majority of the screen. It was nothing short of embarassing really. It screamed of teenage identity crisis.

Kudos to jquery.com though, who listened to their critics and removed the image. Right now, the site’s looking cool but still a little out of place. This is a Javascript library, not a corporate website. Anyhow, I digress.

Another element of the homepage that thoroughly annoys me is the tooltips on the three links titled “Lightweight footprint”, “CSS 3 compliant” and “Cross-browser”. To me, Web-2.0 (I’m sorry for using that phrase) style UI elements are largely about usability and common sense. jQuery seems to be an embodiment of that, and allows developers to enhance their sites greatly with a small amount of effort.

Shocked and awed I was then, when I moved my mouse around the page while reading only to find these terribly intrusive ‘tooltips’ that show when you hover over the aforementioned links. Right out of how-not-to-do-widgets-school it seems. Those elements on the page go against the original intentions behind underlining text (denoting a hypertext link). Not only are the tooltips pointless, but as widgets they’re very annoying to use. Hovering over them can sometimes show another (unrelated), as well as them hiding text around them – forcing the user to have to move their mouse again, only to find that they’ve set off yet another tooltip. They’re too large, unnecessary and bad-practice.

Whilst I can see the usefulness of such a plugin, I think it’s a perfect example of how not to do it. I can’t sleep at night because it annoys me so much.

Seriously!

Server Benchmarking Diary – Debian, Apache 2 and MySQL

This blog took nearly 7 thousand hits yesterday. At its peak, it took 1.8 thousand an hour. That’s a decent amount of traffic. This was all brought about when I submitted a link to reddit.com regarding a way to crash Google Chrome instantly. Coincidentally, I had spent an hour or so the night before testing the stability of my Slicehost Xen virtual machine (more info here) just out of curiosity. I was using wget, ab (Apache benchmarking tool) and htop to mirror, send concurrent requests and monitor respectively. I’m going to document my findings here.

What I’m Running

Here’s a rundown of what sites I’m running and the software used.

Wget – the Swiss army knife of HTTP command line tools

Wget’s one of those tools you really take for granted. It’s versatile, reliable, simple and most importantly – it does its job very well. One of its nicest features is the –mirror option. This allows you to…mirror a given website. I initially thought of running multiple instances of wget at the same time. I started small at first: one instance running to mirror the entire site. I ran the following in a shell:

alex@prometheus:/tmp$ wget –mirror beplacid.net/

It’s simple: mirror beplacid.net. Watching the processes and CPU usage on the server, it became apparent that  this wasn’t going to do much. The CPU usage didn’t exceed 5% on its first core. I had to rethink. Then ab sprung to mind.

ab – Apache benchmarking tool

This is another useful tool. It’s simple to use and allows you to quickly and easily hit a given hostname with HTTP requests, all tailored to your specific needs. To do all this, however, you need to be running as root. A noble security measure.

I wanted to generate some traffic that would put the server under some strain, so I started with 50 requests and 5 at a time:

prometheus:/root$ ab -n 50 -c 5 beplacid.net/

Now things started to get fun. This peaked CPU usage to 94% on one core, the others were between 60 and 80. I was starting to see some real stats. I doubled things – 100 with 10 per request:

 prometheus:/root$ ab -n 100 -c 10 beplacid.net/

This was a little more representative of a heavy amount of traffic. Perhaps akin to slashdot or a reddit. Put simply, that’s 100 requests with 10 each sent each time. Still nothing major, so I went all out:

Concurrency Level:      10
Complete requests: 1000
Total transferred:      4856792 bytes
HTML transferred:       4687792 bytes
Requests per second:    4.99 [#/sec] (mean)
Time per request:       2002.453 [ms] (mean)
Time per request:       200.245 [ms] (mean, across all concurrent requests)
Transfer rate:          23.69 [Kbytes/sec] received

To summarise, the server took 1000 requests with an average of 5 per second, each returning just over 2 seconds. Not bad, considering what I’m running.

I’m pleased with my setup. It can take a punch and it’s still running. My next task is to hit both beplacid.net and the blog, with perhaps some traffic mirroring readingbeerfestival.org.uk too.

Tasty Google Chrome Bug – So Much For Isolated Tabs/Processes

Update: it seems this bug was already reported, but the amusement value seemed to escape most of the web.

The web’s abuzz with talk of Google’s new venture – Chrome. My workplace is no exception; in fact we’ve had numerous discussions about it, spanning from “should we support it” to adoption paths.

One of Chrome’s highlights is its isolated tabs. The idea is that tabs run as separate processes, so if one lags, the rest still operate correctly. Therefore, it was quite a surprise when a colleague emailed me with this nifty trick to crash Chrome:

 Type this into a Chrome tab’s address bar
:%

No need to press enter, it happens as soon as you hit %. Here’s a screenshot:

Google Chrome Crash

Again: so much for isolated tabs.

Note: I’ve submitted a bug report here

- atc

Pyela – Python Eternal Lands APIs

Some time ago, I began hacking away at a simple API (Application Programming Interface) for Eternal Lands written in Python. I intended to write something that was quick and concise, and that would be easy to reuse. Using a typical OO approach, I finally came up with ‘Pyela – Python Eternal Lands API’.

Pyela is an object oriented (OO) API for communicating with an Eternal Lands server. It aims to be a simple wrapper for socket operations and messages that pertain to the undocumented Eternal Lands Network Protocol. A demonstration of the API is easy to see in the Pyela – GUI application, which is a Eternal Lands chat client written using Pyela. You can download that here.

Pyela is released under the GPL3 and is open to patches and any suggestions you may have and is hosted by Google code – pyela.googlecode.com.

Best Image Ever?

I found the following image while scouring the web one day. Has to be the funniest image manipulation I’ve seen in a long time…

Duck to Crocodile hybrid

Debian & Ubuntu – SSH Via an HTTP Proxy

So you’re sitting at work, and your much-loved VPS with hosting company X has gone down. You need to bring it back up, but you’re an hour away from getting to a PC.

Fear not, fellow hacker – SSH over an HTTP proxy is here! Well actually, it’s been here a while. Ahem.

Before you do this, I must stress that you should check with your network’s usage policy before continuing. You may be breaking your networks rules, and I cannot & will not be held responsible for anything that arrises from using these instructions. You are on your own.

Installing Corkscrew

To quote its package details in Debian & Ubuntu repositories, Corkscrew “is a simple tool to tunnel TCP connections through an HTTP proxy supporting the CONNECT method. It reads stdin and writes to stdout during the connection, just like netcat“. Put simply, it’s a way of sending traffic that would normally go via alternate means (say, over port 22), through a proxy server that may block the original routes.

We’ll need corkscrew, or a similar TCP tunnel package, to send the info via the proxy. Fire up a shell and execute the following:

sudo apt-get install corkscrew

This will install corkscrew. Don’t worry, it doesn’t run as a daemon, but instead on a per-connection basis (that is, it reads from stdin), so it’s not going to hog many resources. Once that’s done, we’ll configure ssh to use corkscrew instead of a direct connection.

If your HTTP proxy uses authentication, then you’ll need to tell it about the username and password to use. This is where the concept of ‘auth-file’ comes into play. All you have to do is put your username & password, separated by a colon, into a textfile. Once you’ve done this, you just have to tell corkscrew where to find the auth-file. Create a file called .corkscrew-auth in your home directory and place your username and password in the following format:

username:password

Save the file and get ready for the next bit… :)

Configuring ‘ssh’ For Tunneling

Now we’ll tell ssh what to do when connecting to all or specific hosts. Open up ~/.ssh/config (that’s /home/yourusername/.ssh/config) in your favourite text editor (vim > *) and add the following lines:

Host *
ProxyCommand corkscrew proxyhostname proxyport %h %p /home/username/.corkscrew-auth

Note: replace proxyhostname and proxyport with the equivalents for your network.

Note: you won’t need to add the last section, ‘/home/username/.corkscrew-auth’, if your HTTP proxy doesn’t use authentication.

What we’ve just told ssh to do is for all hostnames (‘Host *’), use the following proxy command to route the connection. The text after ProxyCommand is all specific to your HTTP tunneling software, except %h and %p which are ssh config variables for the hostname and port respectively.

This should work out of the box. It did so for me. Test it out in a shell by doing the following:

ssh somehost.com

I think you’ll be pleasantly surprised…Any issues, please post below and I’ll be happy to help out.

Cheers for reading,

Placid