OpenDNS blocking is working on the iBurst network

Pulled a few strings over at iBurst and OpenDNS blocking is now working. Security and web filtering for free!
OpenDNS is a configurable option on the Tomato firmware for the Linksys WRT54GL. There is no agent or extra configuration required on the networked PCs.

A data centre where you can flush with pride

My mate Mike, IM'd this pic to me. I have some ideas now for my upstairs loo!

Don't Panic

Thapelo Ntlhabo writes in OF 'FIRST BLACKS',GOOD SOUTH AFRICAN BOOKS,AND 'GOODWILL PAYMENTS': "My finally getting to read the book-DON'T PANIC-by Allan Knott-Craig(the MD of iBurst). I had heard so much about this book. Of how this one email sent by Allan to his staff, highlighting the good and positives about SA, had triggered an avalanche of more reasons why SA 'rocks' from the general public. And indeed in this book South Africans of all shades do sing the praises of our country. They write about the beautiful weather,the thriving and stable economy, the wonderful landscapes etc, etc. At the same time everyone admits that we do have our challenges. For example,things like crime.On this issue we all need to chip in as citizens to help our police force, most of the the contributors in the book seem to be saying. I was particularly heartened by how most of my white countrymen love this country.They are staying,and some are coming back from foreign lands. DON'T PANIC is a must read for all South Africans."
DON'T PANIC is available from kalahari.net.

iBurst connection in Douglasdale

This weekend I installed my iBurst desktop modem and cancelled my Telkom ADSL. After I had finished and fired up iGoogle, where I have my Google Reader dashboard, I saw that one of the Meerkat's favourite podcasts over at IT Management podcast had a new episode.

I decided to test the download speed. The file came down at a good clip, given that it was from the States. My router is a Linksys WRT54GL and has Tomato loaded. Tomato is a real nifty version of software for the router as it has good graphing as shown above. It even stores the historical graphs to my StorageBird.

Death blow or storm in a tea cup?

Alex Kayle writes in Nortel SA survives storm: "The local Nortel branch, which employs 20 people, says it will be business as usual."

Is this realistic or extremely optimistic?

Disorder as a cause of major incidents

Previously I wrote about the NBWT, and today Guy Kawasaki pointed me towards new research that supports the theory.

An IT environment that has visible disorder, like limited documentation, litter or messy infrastructure is more likely to experience a major incident. This does not relate to the reliablity of the technology or its use but the pollution of process. Disorder leads to and is a trigger for poor process which results in a higher rate and probability of major incidents.

A meerkat in London

Ashlee Vance writes in A Software Populist Who Doesn’t Do Windows: "All the fuss at the meeting centered on something called Ubuntu and a man named Mark Shuttleworth, the charismatic 35-year-old billionaire from South Africa who functions as the spiritual and financial leader of this coding clan.*"

Shuttleworth Meerkat is from the Flatmountain burrow in a neck of the Kalahari that has water so damn cold that if they where able to desalinate it, it would be perfect for Pina Amarula Coladas.

But I digress, this is supposed to be a problem management blog and all. Shuttleworth Meerkat adds: "It feels pretty clear to me that the open process produces better stuff." The meerkat who now tunnels at the Canonical burrow, which is not in the Kalahari, but across the pond. Shuttleworth is now a meerkat in London. The conclusion he draws is that if you use ubuntu you are less likely to experience tunnel collapse problems in your infrastructure. I wonder if 2009 will be the year that burrows stop using windows? Every self-respecting meerkat knows that windows are an open invitation to become lunch for lurking eagles and cobras!

* A group of meerkats is called a mob, gang or clan.

The Right Stuff!

Best video of the year! The Meerkats were impressed! They haven't seen anyone jump that high since Pikkewyn Meerkat backed out of a burrow bolt hole on his Vespa chased by a Rinkhals!

Checklist of proximate causes for programming related outages

Bob Martin writes in Experts Announce Agreement on the 25 Most Dangerous Programming Errors - And How to Fix Them: "What was remarkable about the process was how quickly all the experts came to agreement, despite some heated discussion. "There appears to be broad agreement on the programming errors," says SANS Director, Mason Brown, "Now it is time to fix them. First we need to make sure every programmer knows how to write code that is free of the Top 25 errors, and then we need to make sure every programming team has processes in place to find, fix, or avoid these problems and has the tools needed to verify their code is as free of these errors as automated tools can verify.""

Security specialists are bureaucratic and miss the boat. This endeavor is an example. This checklist of proximate causes is a great development but it is not the 25 most dangerous programming errors. I suggest they revert to 1931 when H.W. Heinrich in his book, Industrial Accident Prevention: A Scientific Approach, defined the underlying outage prevention process. Typically, there are outages with associated direct causes. These are associated with proximate causes which inherently all have root causes. A single outage usually has multiple causation. SANS has focused on the proximate and not the real error.

However, Mason Brown does highlight one of the potential real errors: "we need to make sure every programming team has processes in place to find, fix, or avoid these problems!" SANS and MITRE have taken a procedural step towards addressing security related outages but it is not root cause analysis.

The programming proximate causes for programming related outages (or what SANS calls the Top 25 errors) is:

• Improper input validation
• Improper encoding or escaping of output
• Failure to preserve SQL query structure (SQL injection)
• Failure to preserve Web page structure (cross-site scripting)
• Failure to preserve operating system command structure (OS command injection)
• Cleartext transmission of sensitive information
• Cross-site request forgery
• Race condition
• Error message information leak
• Failure to constrain operations within the bounds of a memory buffer
• External control of critical state data
• External control of file name or path
• Untrusted search path
• Failure to control generation of code (code injection)
• Download of code without integrity check
• Improper resource shutdown or release
• Improper initialization
• Incorrect calculation
• Porous defenses
• Use of a broken or risky cryptographic algorithm
• Hard-coded password
• Insecure permission assignment for critical resource
• Use of insufficiently random values
• Execution with unnecessary privileges
• Client-side enforcement of server-side security

Lessons from the Railways

My first job was for the Railways. It was fun working there until I was told that I could not be a member of their pension fund because I was disabled. I didn't stay around to argue the point and moved on to work for a little networking company.

There was a two-year probation before an employee was allowed to join the railway pension fund and I slaved away in blissful ignorance in what was to come. I wrote programs in Cobol with embedded SQL. The database was DB2 which was hosted on IBM and Amdahl mainframes. I was assigned to the Information Centre and my boss delegated me to program some MIS systems. The railway wanted some simple reports which they hadn't been able to obtain from the Information Centre for years. The report requests were simple. They wanted:

• Top 20 senders of goods per station
• Top 20 receivers of goods per station
• Consolidated Top 20 senders and receivers of goods per station
• Top 20 types of goods send per station
• Top 20 types of goods received per station
• Consolidated Top 20 types of goods per station
• Everything that wasn't in the Top 20 was aggreated into a 21st item named other.
  

I disappeared into the sunset trying to write these reports with a few hiccups along the way. One memorable run had a logical flaw that resulted in a run of 23 hours and a bill of 250k. Ouch! Finally, I delivered the program.
The next day they phoned me and said great but they wanted additional reports. They wanted the report not by count but by financial value. Within an hour that was done and dusted.
The next request was to group all the stations into branches, i.e. stations were asigned a branch line number and the reporting was done per branch. The program took longer than what I invisaged as I had made a programming fault and couldn't spot it. It was a whole month before I had it working!
After I had delivered this version I never heard from these guys again. A good many years later I was in a remote railway office and immediately recognized my reports laying on a table. I was impressed that my program was still being used!
The lessons I learnt are:

• You do not know what it means to be discrimated against unless you experience it!
• The most important things are limited to a small set. Although there were 12 million shipments per year, most people were interested in only a limted amount which translated to their logistical and financial concerns.
• You can stare for ages at a problem and miss seeing it. It was only when I showed someone else the program to explain the problem, that I was able to fix it.
• The lifecycle of technology is longer that what you are led to beleive!
  

Now in modern network the reports we require are no different than these railway reports. The shipping transactions are netflow data, the senders and receivers are IP addresses, the goods are application types, the stations are routers and the branches are groups of locations or regions. I have seen a number of Netflow applications but none seem to mimic the railway format and although they report on count, none have a concept of reporting on financial value.

MyBroadband.co.za 2008 Report

The MyBroadband.co.za 2008 report is available online here.

Put that in your box and ship it

Chris Kanaracus writes in Cisco: Huge international interest in developer contest: "Routers and other boxes are essentially purpose-driven computers nowadays, so it makes sense to use extra capacity on them, if available, to deploy applications," said Michael Cote, an analyst with Redmonk, in an interview conducted via instant message on Tuesday."

The Meerkat's are dedicated followers of Cote and they combined their tunnelling expertise to submit an entry. What was telling about this article was not the subject matter, a router is a box connected to some pipes to which we attach fancy items. The interview was via instant message! No wonder VoIP is dying because we first text before we speak!

iBurst down under

Suzanne Tindal of ZDNet.com.au writes in Telstra bought iBurst's wireless spectrum: "Although Telstra had to win a tender process to achieve the frequency band, Warren Chaisatien, research director of analyst firm Telsyte, had previously expressed scepticism that the company would use it. He believed the telco would have acquired the spectrum to take care of competition. "It would be switching off the competitor because the spectrum band is effective for wireless broadband and not for 3G," he said."

Netcordia network audit checklist

Netcordia has a great network audit checklist. It provides a great list of items to research and check when conducting an audit. Obviously made easier if you use their NetMRI box.

Banking spaghetti

Ivan Pepelnjak writes in Flexible Extranet Implementation: "You can achieve maximum flexibility if you isolate each extranet participant in an independent routing instance with its own IP routing table and routing protocol. MPLS VPN technology uses the term virtual routing and forwarding (VRF) table for a routing instance; you would have to create a VRF for each participant on the extranet (exCore) router as shown in Figure 6. The extranet server will be reachable through the global IP routing table."

This solution is often required in banking when there are multiple third party services being used and shared between participants include market feeds, payments, clearing, credit references, card, etc. The large number of interfaces required in banking often makes the network look like spaghetti!

It's about the rugby!

Denise Dubie writes in SolarWinds acquires Kiwi Enterprises: "SolarWinds announced Monday it had acquired for an undisclosed sum the assets of New Zealand-based software maker Kiwi Enterprises, best known for its free management and configuration tools."

I suppose now the Yanks will have someone to teach them Rugga!

2008 Review of TPM!

Meerkat tunnel love

1. Cisco IOS hints and tricks
2. Network World Community
3. Terry's Blog
4. LinkedIn
5. IT Skeptic
6. Wikipedia
7. thwack
8. muti
9. Drunken Data
10. Lijit

Top posts

1. Major incident process
2. Network troubleshooting checklist
3. Standard Operating Procedure template
4. Best practice network design
5. Titsup - the new heathrow T5 (")
6. The leaky VLANs myth?
7. Documentation - the techie curse
8. Blogs that rock
9. Firewall's best practive holy cows
10. Madge Networks

Search hits

1. kepner tregoe
2. problem management
3. standard operating procedure template
4. itil checklist
5. itil implementation
6. tiger teams
7. problem management metrics
8. major incident process
9. incident process
10. incident pyramid

MTN outage

MyBroadband.co.za reports in MTN network crashes: "Giant cell phone network MTN has crashed, leaving thousands of frustrated subscribers without coverage, the SABC reported on Saturday."

Strange I never noticed it and their website has no details about it!

Helen Suzman was a hero

Majola writes at Zoopy about Helen Suzman dies at 91: "Helen Suzman, born Helen Gavronsky, died on 1 January 2009 (born 7 November 1917) and will always be remembered as a staunch anti-apartheid activist and dedicated politician in South Africa."

Growing up as a teenager in that strange ZA decade of the eighties I was one of the brakke at Grey who ridiculed the Groot Krokodil and embraced the views of Suzman. Helen Suzman did well and is a true hero!
Probably as a sign of things to come, I did not read or hear about this on mainstream media or television but on a social networking site!

Dimension Data wins an award!

In this neck of the Kalahari, we have some IT guru Meerkats over at the DiData burrow. They aren't really that bad as far as Meerkats go, if you can overlook the exorbitant prices they charge for their tunnelling. To start the new year, the DiData burrow has won an internationally acclaimed award from the IT Skeptic, the Bell-less Prize for Mathematics. I wonder when the Meerkats at the Campus will learn to put the comma in the right place?

You'll notice on this eagle photo from Google Burrows, that the DiData burrow is in the south-east corner (the upside-down D). The Thinking Problem Management! burrow is not far away in the badlands to the west, on the dodgy end of the N1.

Behind every bush you'll find an ABBA fan

In this neck of the Kalahari, when the Groot Krokodil was around, he used to say that there was a communist behind every bush! Since the commies aren't around in great numbers any more, the new version of the Groot Krokodil's saying is, "behind every bush you'll find an ABBA fan!"

Mark Paradies over at the Root Cause Analysis blog is such a fan. I suppose we are both old enough not only to remember ABBA, but also appreciate them...

BTW: I didn't realize that 2008 had an extra second!