Ben Tasker's Blog

A Bad Boss Can Ruin Your Job

We've all, almost certainly, had a boss we didn't necessarily get on with at some point, but that doesn't necessarily make them a bad boss.

People are different, and sometimes view points collide, it's an inavoidable risk of putting distinct personalities into a group and asking them to spend their days together.

What makes a true bad boss is when the power/influence they exert is mis-used. 

In my career, I've had one particularly bad boss (I hasten to add - I'm not working there anymore!), not only did their behaviour ruin my enjoyment of my role, but they (in my opinion) deliberately went out of their way in an (ultimately unsuccessful) attempt to severely tarnish my reputation and my name. Their attempt could also have had a devastating effect upon my quality of life.

In this post, I'll be taking a broad overview of what happened, and examining what I learnt from the experience, and (with the benefit of hindsight) what the early warning signs were.

The events I'm going to discuss occurred a number of years ago and I always planned to write about it, but wanted to leave it long enough that I could be truly objective. As a result, I never quite got around to writing about my experiences.

Being a denizen of a number of internet forums, I've seen others post about experiences they're currently going through, and some of them really ring alarm bells for me - so it seems like the right time to get around to writing about it.

I'm not going to name names, as that isn't the point in this piece. I've tried to keep it as brief as possible, but being quite complex it's not as short as I had originally hoped.

Read more ...

My Own Little HeartBleed Headache

When the HeartBleed bug was unveiled, I checked all of my servers to see whether they were running vulnerable versions. They weren't, but once the patched versions were released it seemed a good juncture to test and roll out the update to one server.

What followed was something of a headache, initially with all the markings of a serious compromise.

Having now identified and resolved the root cause, I thought I'd write a post about it so that others seeing similar behaviour can get something of a headstart.

In response to threats such as CDorked, I run PHP Changed Binaries on all my servers, so any file in PATH is checked (daily) for changes, based on a cryptographic checksum. If any changes are detected, an alert is raised so that I can investigate the cause of the change.

The day after I updated OpenSSL, I started receiving alerts for a wide variety of files (I'd updated hashes following the update of OpenSSL)

Read more ...

Falling Out Of Love With Siteground

In the past, I've really rated Siteground Hosting very highly, and recommended them to anyone asking about US Based dedicated servers (Heart would be my first choice for UK Based Dedicated Servers or VPS). Unfortunately experience has worn me down.

To be clear, I'm not, and never have been, a Siteground customer. However, some of the people I do some work for are, so I occasionally have to escalate things to Siteground, or step in when Siteground have asked their customer to take some action.

I've been quietly sitting on some of these frustrations for a little while, but in the last week some have been added, tipping the balance in my mind.

Read more ...

NTPD Refusing to accept time from GPSD

One of the (minor) drawbacks of the Raspberry Pi is the lack of a hardware clock. Normally, you'd work around this by configuring a good pool of NTP servers to connect to. What do you do though, if you can't guarantee there will be an Internet connection available when needed?

The solution is obvious, so obvious that many have already done it - use the time provided by a cheap GPS dongle. The gpsd daemon helpfully pushes the time to Shared Memory Segments (SHM) so it's a simple adjustment to the NTP configuration file to have NTPD pull the time from the dongle.

Except, it seems on Raspbian, it isn't quite so simple. You've followed all the instructions (simple as they are) but are still seeing an entry like this

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
SHM(0)          .GPS.            0 l    -   16    0    0.000    0.000   0.001

No matter what you try, reach stays at 0.

Frustrating, and there's very little to give you a guide. This post will tell you what the issue is, as well as how to go about finding it should it re-occur

Read more ...