Sunday, 14 June 2015

Fixing a broken windows installation

I recently had a rather sick server that was exhibiting all sorts of weird behaviour. Applications pools under IIS were shutting down as soon as the site was hit. All sorts of weird stuff was happening. Event logs were providing nothing useful. Even trying to install IIS diagnosis tools failed.

Clearly a very sick machine.

Diagnosis


One of the challenges was what to trust. Clearly there were some underlying issues with the operating system. Once you go down that rabbit hole, where do you stop? Is the event log still working?

Where do you start?

I had the following info:

  1. A web application that was working 6 hours before was now failing, without any useful errors in the event log. There was an exit code but I couldn't find any info.
  2. Diagnosis tools were failing to install
  3. A colleague was reporting that some apps wouldn't run

My best guess was that some of the operating system was corrupted in some way.

Solution!


In my extensive research (googling frantically) on this, I came across System File Checker. This runs through all system files and finds any files that might be corrupt.

I also found this rather helpful link that covers how to read the log files.

Resolution


The scan indicated an issue with a specific dll. I passed this onto a colleague who was able to fix the issue by uninstalling and re-installing windows updates. It's a great tool to add to the toolbox.

The 

System File Checker

System File Checker

Thursday, 11 June 2015

Welcome to the nightmare factory

In my earlier post I called software development the dream factory.

Unfortunately the very things that make software the stuff of dreams can also create nightmares.

World without rules

Once you've started to write some software, you are setting up rules for your new world.

Those rules define what you can or can do. Once they are defined, it's often very hard to change them.

There lies the problem. Software is so unbounded by rules that inevitably people make the wrong decisions and are then locked into those decisions.

Once you have created your world you have to live in it. You must live with all the decisions you've made.

Looking into the future

Software changes so rapidly that it becomes a challenge to choose tools and techniques that will stand the test of time. Today's best practice becomes tomorrow's worst practice.

I recall when bitshifting was a clever optimisation. I was there when winforms was the best way to build desktop applications. I saw service locator go from being a best practice to a worst practice, replaced by IoC containers.

Right now, if you wanted to build a SPA, which javascript framework would you choose? How many of the current favourites will still be in use and being maintained just 2 years from now?

Imbalance

One of the problems with software is that is it really, really flexible ... until it isn't. One moment you are defining the rules, then you are bound by the rules. Depending on the choices made up front, some of the flexibility might remain.

Imagine for a moment if a software project were building a bridge over a canyon (I know it's an overused example). Some of the things that might be completely impossible in the real world are easy, but things that easy in the real world might be close to impossible, depending entirely on the decisions made earlier. For example, it might easy to move the bridge 200m down the canyon, but impossible to add a new coat of paint.

This is terribly confusing for consumers of the software as the rules aren't consistent. In the last 'bridge' they requisitioned, moving the bridge was hard but painting was easy, why is it so hard this time?

Welcome to the nightmare factory

The dream factory also creates nightmares. There are no rules. You are in full control.

You are going to make the wrong decisions with long term consequences.

Welcome to the nightmare factory, enjoy your stay 1.

1 On the bright side, not all dreams turn to nightmares

Wednesday, 27 May 2015

Welcome to the Dream Factory

I've often heard software compared to all sorts of things: construction, engineering, even art.

For me, I always think of software development is the dream factory. Software is so free of any rules, you can do whatever you want to do. It's like a blank sheet of paper. In 3D. Or as many dimensions as you chose to define, because you genuinely can choose how many dimensions you want.

In construction, if someone is building a house, they can't suddenly ask to add another storey. In software this isn't an unreasonable request. Artists are still limited by the materials they use.

When people write games they have to build or use a physics engine. Pause to think about that for a moment. Even the rules of physics don't apply!

Every piece of software is like a whole new world.

Engineering

I originally trained as an engineer. A real engineer, not a software engineer.

Real engineering is heavily restricted by physical limitations. If you are designing a frame, you're pretty sure you are going build it out of steel. Sure more exotic materials might be an option (carbon fibre, titanium, nanotubes etc), but most are too expensive to be viable. So you'll design it to be built out of steel, the same way an engineer 50 years ago might have done.

Engineering means designing and building from known patterns and materials. You'll use the same basic mechanisms, materials and machines. The configuration might change but the basic materials and patterns are the same.

Aren't there limits in software?

Now software does have some real bounds. Compute, latency, bandwidth and storage are all limited. However in the age of cloud computing, only latency and bandwidth are truly limited. Even these limitations change rapidly, compared to other industries.

This is the industry that runs on Moore's Law, where computing performance roughly doubles every 2 years1. Imagine being an engineer, where the materials you work with doubled in strength every 2 years!

Most software is limited only by willingness to spend time or money creating it. The only real bounds are the ones you create yourself.

Welcome to the Dream Factory

This is why I call software the dream factory. It is truly the stuff of dreams, limited only by the skill and imagination of it's creators. Software itself does not impose any real bounds.

Welcome to the dream factory, enjoy your stay.


1 Moore's law is more a measure of the number of transistors on a chip doubles every 2 years, however performance is a rough approximation

Thursday, 6 November 2014

Why would someone hack your 'thing'

This is a follow up to an earlier blog post (Internet of things heading for a trainwreck), where I commented on the security of the internet of thing. An interesting follow up article on this is: 'Things' on the Internet-of-things have 25 vulnerabilities apiece. It's highly unlikely that any of those 25 vulnerabilities will be patched.

But I digress, the question is, why would someone hack your 'thing'?

Reason 1: Because it is there

Someone might not be targeting your thing or even your class of thing when they take control. Your thing might be share vulnerabilities with someone that is being targeted. For example the underlying operating system of the device or hosted applications might share vulnerabilities that are common in web servers running on the internet. Many devices would provide a web interface to manage them, and to do this they are likely to use commonly available webservers, eg ngix or apache.

However simply being available on the internet makes something a target. Someone scanning the internet for something interesting to break into would not necessarily know that the device responding on port 80 is a thermostat rather than a webserver.

Reason 2: For the capabilities

In many ways a thing is mostly a less powerful computer with extra capabilities. It's unlikely that someone would hack your thing for the computing power (although people have produced bincoin mining malware for android). However your thing is every bit as capable as a computer in every other way. It could be used to gain a foothold in your network. It could be used as a spam relay. It could be used in DDoS attacks. It could be used to host malware. The list goes on...

Your thing is generally different though, as it is a computer + something. That something could provide a rich set of capabilities that computers don't currently have. For example, a Nest has sensors to identify whether someone is home or not. Imagine if someone were able to hack into your Nest, prior to breaking into your house to check if you are home. Cameras on 'things' could well be used in the same way that RAT trojans are used for voyeurism and blackmail. Consider that you might not have a laptop with a webcam in every room, but you might well put a 'thing' with a camera each room, including the bathroom.

As the internet of things starts to take off, people are going to work out new ways to exploit the new sensors that it brings to the table.

Reason 3: For the data

Not all 'things' have sensors that would be useful in real time but many of them collect some very interesting data. Something like a fitbit can track your activity. We want that information to run our lives, but it is just as interesting to a third party. Things can provide historical data on heart rate, location or any other information that might be collected.

Conclusion

Security is hard and typically is an afterthought. This should get rather interesting when your lightbulbs and door locks get hacked.

Tuesday, 21 October 2014

Mounting Network Gear

For a while I've been keeping my modem and the voip box sitting on top of the printer. This is a bit of a problem as you tend to knock everything off when you try to scan something.

When I replaced the modem with a new modem and a switch. I decided enough was enough, I needed a better solution. I thought the solution I came up with might be of general interest so I took a few photos on the way through.

Apologies in advance the terrible quality of the photos.

Before - oh the mess!

What you need:
  1. 12mm thick mdf board
  2. Screws to match the depth of the board (I chose 6G x 15mm)
  3. Jigaw to cut it out
  4. Drill + bits to put a nice neat hole in the top to hang it
  5. Sandpaper to clean up
  6. Tape Measure
You need this

1. Mark the board

Measure the items you want to mount. Add a centimetre for the space between each one, and 5cm for space at the top. Mark the board up. Don'r forget: measure twice and cut once.

2. Cut out your board

Using your handy jigsaw, cut out the board.Coffee table and jellybean dropsheet are optional accessories.
Jigsawing

Clean this up with the sandpapaper, jigsaws tend to leave rough edges

Sanding

3. Drill a hole

This needs to be large enough to handle your hook. I'd err on the side of larger holes to handle larger hooks.


It's a hole! In a piece of wood!

4. Start mounting things


First set of screws

Problem 1: The little linksys box didn't neatly handle the screws, so I had to scrape the plastic away a little.
Thank goodness it will all be out of sight in time

First one mounted, blurred for effect

All of them mounted on the board
With the cables wired in
You might notice that I didn't do a great job of spacing these apart very well. The modem on the far left overhangs the end of the board slightly and there isn't a huge gap between that and the switch (in the middle). I should follow my own advice on measure twice cut once.

Conclusion

I've found this useful for getting everything out of the way. I hope this helps someone else.

Tuesday, 2 September 2014

Embedding images in a page - MVC style

I recently had a need to write some images stored in a database to a page. This was something rare enough that I thought it was worth documenting as it meant putting together a few different pieces.

Examples here are for MVC4, but could be easily adapted for somehing else.

In the View:
<img alt="Restaurant Image" class="RestaurantPhoto" src="data:image/png;base64,@Model.Photo">

In the controller:
byte[] photoData
// populate photoData here
model.Photo = Convert.ToBase64String(photoData, 0, src.photo.Length)

This works by encoding the image as a base 64 string, which is supported by most modern browsers. You might need to change the data at the start to handle different image types.

Pair this with the following two pages:

  1. Uploading a File (Or Files) With ASP.NET MVC - Phil Haack
  2. Convert HttpPostedFileBase to byte[] - Stack Overflow
and you've got an end to end solution for uploading and displaying files.

Why would you / wouldn't you do this?

Doing this is a bad idea in many cases as it means that the image can't be cached. Overall this would tend to make your page loads slower.

However it might be worth doing if
  1. If the image is changing often enough and therefore there is no value in caching
  2. It gives you a self contained page, limiting the number of http connections

Sunday, 3 August 2014

Internal Project - implement the API

I've completed the work in implementing the API.

This was surprisingly more complex than expected. I've spent a bit of time working with WebApi and I'd also done the work to design the API, but I still ran into a few unexpected issues, some of which required me to change the design of the API.

Finding the IP address

For some reason I'd decided to include logging the IP address of the client machine when people mark a status as liked and when a status is marked as viewed. This proved to be a bit harder than expected. After poking around in the Request object for a while, I resorted to google, which led to this stack overflow question.

Routing Fun

When I'd designed the API, I'd had planned GET requests to cover retrieving a single status, searching for statuses and retrieving the status history, all hitting the same URL. I'd slightly naively assumed that this would be handled something like function overloading. I'd also confused this with the simple case where you return all and retrieve a single item by id. In that case, this is handled by routing.

Clearly this doesn't work, how would the server resolve the HTTP verb to a single function?

As a result I needed to move this to separate the methods using routing. This meant that search became: /status/search as a GET.

Retrieving values passed in

I ran into a few problems trying to retrieve values passed to the server. Should they go in the body? URL? Headers?

In retrospect, probably the best place for the session id would have been as a header. Ideally the authentication for this could be handled as less of a copy and paste implementation. It would be a bit overkill in the current situation though.

Progress

  1. Document the UI - I've found this tends to make the implementation clearer
  2. Implement in bootstrap, MVC4 with SQL Server backend
  3. Design JSON API to access app
  4. Implement JSON api using WebApi backend
  5. Replace MVC app with javascript client side framework, angular
  6. Swap the SQL Server backend for a No SQL database
  7. Replace the WebApi backend with an F# implementation
  8. Replace the WebApi backend with node.js