To continue the theme of scary IT-related pictures, this is how a serviced office provides connectivity to a number of its customers.

 no control - anyone can, accidentally or deliberately, disable users by moving or removing cables

no order - anyone able to easily identify which are  phones and which are PC cables?

no security - access to anyone’s switch by anyone getting into this “cupboard”.

It’s an IT support company’s nightmare. We will report back on what we do about it

We get lots of comments from prospective clients about why they are talking to us. It would be interesting to hear what other excuses are used.  Is this the picture you have in your head of your IT support company?

If you needed computing for just a few months, would you rent or buy?
comments please

It has been a while since anything was added to this blog - sorry about that. Over the coming weeks and months, we intend for the blog to become a number of things:

• a source of technical information - postings of unusual or interesting IT support issues that have arisen recently and our solutions to the problem
• how Managed Networks is changing - a way to keep an eye on us if you wish
• how Managed Networks resolves the business problems of our clients.  Mostly the unusual ones rather than everything - that would just get boring

We welcome you to subscribe and comment on our postings.  We dont mind if you agree or disagree with our postings but please be polite as it makes our life easier when editing!

Server racks find themselves, like iMacs and remote control Christmas lights, at the geeky junction of technology and style. Or at least, they can do. Little else has the potential to both lift the spirits, or to sadden the heart like a server rack.

We’ve collected some of our favourite server rack / server room pictures for you.

The Good

A couple of our favourite, well-organised set-ups first.

In 2007, the London Stock Exchange reported they could handle 4,200 orders per second. This photo shows their test/dev server room. The photographer, JonnieW@lker says “The real thing has cameras on tripods and to get in you need 2 signed authorisations in order to gain access (only allowed after 6:00 pm)“

This rack, somewhere in California, gets our vote for its well tidied cables, and a bonus point for emitting just the right amount of blue glow. Good find, Kim Scarborough!

The Bad

Free Geek volunteers repurpose old computers for people that wouldn’t be able to afford them otherwise. Thanks to Skippy13, we can now see inside the FreeGeek server room. We’re going to have a whip-round and donate some cable-ties to them.

Richard explains that the configuration in this test lab changes on a daily basis, though it seems to remain in permanent Spaghetti Hell.  Concerningly, it seems that this photo was taken after the lab was cleaned up. Woah.

It looks like this used to be a server room. Maybe? To be fair, their looming and cable-tidying looked pretty top notch, but we can only imagine that there may have been heat dissipation issues. No hints from Silfverduk, except that it seems to be in Pripyat, Ukraine.

The Funky

A bonus server set-up to finish:

These are the servers for a web service called Backrub. The wiring clearly needs a bit of work, but we particularly like the SCSI drive box built from plastic bricks.

It’s great that the guys who bult it had time to enjoy themselves, whilst building up the service which would later be renamed ‘Google.’

If you find your server is living in Spaghetti Hell, you should talk to us about IT Support. We promise not to take incriminating photos!

The blogosphere was amazed earlier this year when it realised the true size of Google. Think Google is the King Kong of search? Think a million King Kongs and you’re getting close. Google processes 20 Petabytes of a data a day. Don’t know what a Petabyte is? Check this out:

An MP3 is about 3MB. The Beatles recorded 214 singles- that’s close to just one gigabyte. 1024 gigabytes makes a Terabyte and 1024 terabytes makes a petabyte. Lost and confused? We were too.

Our poor mortal minds haven’t been so boggled by the ‘big numbers’ since a legendary wag fooled his elders out of ‘quite a lot’ of rice by using a chess board a few hundred years ago. We’ve used the same unit of measurement – grains of rice – to try to put Google’s electronic brain power into perspective.

Let’s relate a grain of rice to a byte. A byte is normally eight binary bits, eg ‘10011000’. It can also be written as a two digit hexadecimal number. In terms of data, a byte is generally used to store a letter. One byte = one letter = one grain of rice.

Bearing this new representation in mind, we can now look at a kilobyte (1024 bytes) as a small bowl of rice. It’s about half a portion, not enough to fill you up – and in data terms a kilobyte would only be a few paragraphs of text – not much to mentally stimulate you there either.

Next up is the megabyte – which is around the size of all the text on an average website, or a short novel. On the rice scale, a megabyte would be a 25kilo bag of rice; enough to feed over 420 people in one sitting, if you have enough chairs.

1024 times larger still is the gigabyte. Back in 1995, I bought a PC with a gigabyte of hard drive space, and managed to store everything I needed on there for the next few years.

To store a gigabyte of rice I’d have needed a bigger garden…. the size of two shipping containers to be more precise. And I could have treated all of those curry-loving Mancunians to a meal. The equivalent of finding a single word in a gigabyte of text is finding a few grains of rice somewhere inside those two containers.

Moving up the scale again we reach the terabyte, equivalent to 1024 gigabytes. I have a terabyte drive sitting in front of me – it’s the size of a small shoebox. But to search through all that data – even on my most powerful desktop machine – would take longer than my patience could bear.

To transport a ‘terabyte’ of rice we’d need to hire this container ship. We could use its contents to feed everybody in the EU.

Finally, we arrive at the mighty petabyte. At this stage, we’re well beyond the size of data that most individuals or small companies handle, and into the realms of some of our Enterprise clients. It’s the same as 210 of the largest container ships that have ever been built, EIGHTY bowls of rice for every person on the planet, or…

…what you’d need to cover central London in 1 metre of rice!

Remember, Google processes 20 petabytes of data every day; or if you prefer – over 4,000 gigantic ships bursting with rice, 1,600 bowls for everyone on the planet, or central London drowned in 20 metres of the stuff. This is spread over 72,000 jobs each taking an average of 7 minutes to complete. Their data processing capability is a big contributor to their position at the top of the online world, and also no doubt to their estimated £1million monthly electricity bill.

If you have a data network – whether it’s projected to carry giga-, tera-, or petabytes – then drop us a line to find out how our IT Support services can help your business. We could even treat you to a bowl of rice.

Meet the gang: Wayne, Tracy, Maxine and Leslie. They all love the Internet and use it to (legally) download all types of files, particularly movies.

…Wayne’s a bit bored and really feels like watching a movie as soon as possible. This short video explains how BitTorrent can make it happen. It also touches on BitTorrent etiquette, to help you avoid any potential embarrassment and achieve the best possible download results (please don’t be a leech).

If, for some crazy reason, you don’t feel like watching the whole video, here’s what basically happens (WARNING: spoiler below): - Wayne (the client) feels like watching a movie.

• He sends a file request using BitTorrent software on his computer via the Internet to a Tracker
• The Tracker accepts the file request and then finds some other computers (peers) that have the file and are willing to share it.
• There always needs to be one computer with the whole file on it, but other computers can be downloading and uploading a torrent of bits in any order.
• Once the Tracker has linked up all these computers the file sharing begins in earnest, and it really is the more the merrier!
• So (deep breath): Maxine (who has 100% of the file) shares an F with Wayne, then Leslie shares an I, then Wayne sends an F back, then Tracy shares an E and Wayne shares an I with Tracy and an E with Leslie, then Maxine shares an L with Wayne (which means Wayne’s FILE is complete), finally he shares an L with Leslie.

Did you get all that? No? Well, that’s why we made a video…

For those that are interested, Howstuffworks has a much fuller description of how BitTorrent works

Music: Radio Martini - Kevin MacLeod

Welcome!

Managed Networks is an IT Support company based in London. We have offices around the UK including London, Manchester, Liverpool and Birmingham

This blog was set up to give a light hearted look at Managed Networks and the IT Support Industry. Have a look around and check out the various videos we have posted.

Obviously, if you are unhappy with your current IT support setup, then we would love to hear from you.

Isn’t it easy to get confused about nameservers, registrars, domain names, ICANN, whois and so forth? The underlying concepts for building a resilient distributed network might not be too tricky, but as soon as you actually start making that network resilient, distributed and public, it can get mighty complicated.

To make it all simple, we have put together a video that explains how navigating to a URL works, behind the scenes.

To make it all even more simple, we’ve done it with tennis balls. Everyone understands tennis balls.

If you can’t be bothered to watch the whole video, here’s the basic sequence of events (without the tennis balls, though, so you might want to go watch the vid). If we want to get the homepage for www.google.com:

• First, the PC sends a request to ICANN in order to find the registrar for Google.com.
• The answer comes back that we need to be talking to the server at whois.enom.com
• Behind the scenes, the PC then needs to find out which nameservers can tell where www.google.com is hosted (whois -h whois.enom.com google.com)
• Once the PC discovers that the answer is ns1.google.com (among others) - with an IP address of 216.239.32.10, we can then dig 216.239.32.10 www.google.com to find out which host we should approach for the web page
• The answer is 64.233.187.99 (among others - I think they might do a bit of load-balancing!).
• This means we now have all the information required to send a GET request to that IP address and receive back the information we need to display the page

Music: Walking the dogg

Security on the Internet is full of buzzword terminology and endless acronyms: Public keys, private keys, key exchange, SSL, SSH, PGP. In an attempt to clear up at least a little bit of the mess, we have put together a video that explains basic Diffie-Hellman key exchange using tennis balls.

Everyone understands tennis balls.

If you can’t be bothered to watch the whole video, here’s the basic sequence of events (without the tennis balls, though, so you might want to go watch the vid):

• We start with our own private key that we want to use to swap secret messages. This is something only we know and that can be used to encrypt messages between us
• We encrypt this with our own ‘padlock’ - a private encryption method that only we know. It is important that this is commutative with the other party’s encryption method (I.e. that they can be applied and removed in any order) as we’ll see below
• We send this message to the other party, who encrypts it with their own ‘padlock’ or private encryption method. They send the doubly-encrypted package back to us
• We now remove our ‘padlock’ or decrypt using our private decryption method leaving our private key protected only by the other party’s encryption and send it back to them
• By decrypting at their end, they finally securely receive the private key we have been trying to send them all along
• At any point in the future, message can now be encrypted in such a way that the private key can decrypt them and sent safely between us in the knowledge that only these two parties have access to the private key for decryption

It should be noted that the scheme described above has no checking of authenticity of either the other party of the message and so real-world encryption uses more sophisticated algorithms to avoid ‘man in the middle’ and other attacks, but this demonstrates the basic elements of key exchange.

Music: Electricity