Skip to main content


Welcome to Simuliidae, v2

Four years ago, I started a github project to share my Drupal + CiviCRM container hosting solutions/ideas. It’s called “ Simuliidae ”, because that’s the family name of the species we know as black flies. What’s Happened Like so many open source projects, it was ambitious. I claimed four goals. Four years later, here’s my evaluation of those goals: 1. A simple way for evaluators to launch their own local Drupal/CiviCRM installation. This was my priority and relatively successful, at least for a while. I’d say it was successful as a technology demonstration, but of limited value for a potential CiviCRM evaluator because of weak support for Docker on Windows and Mac projects. It was also a lot of work to keep it up to date, and I didn’t. 2. A standard for generating testing and development copies of production sites. This was not particularly successful as a goal. Although I used some of the ideas here with my hosting services, I never moved beyond an idea stage for trying to come up wit
Recent posts

A Strange Passion for Security

I'm not a computer security expert, but it's been part of my work for many years, in different forms.  A very long time ago, a friend hired me to write up a primer for internet security, and ever since then it's been a theme that's sat in the background and pops up every now and then . But lately, it's started to feel like more than a theme, and but indeed a passion. You may consider computer and internet security to be a dry subject, or maybe you imagine feelings of smugness or righteousness, but "passion" is the right word for what I'm feeling. Here's google's definition: Passion: 1. a strong and barely controllable emotion. 2. the suffering and death of Jesus. Okay, let's just go with number 1. for now. If you followed my link above to other posts about security, you'll notice one from eight years ago where I mused on the possibility of the discovery of a flaw in how https works. Weirdly enough, a flaw in https was discovered shortly

I'm wrestling with a monster

 I consider myself a rational person. By that, I mean that I make important decisions in my life based on weighing pros and cons, similar to a chess game. So what to make of my decision to confront Koodoo over their exorbitant charges for my spouse's mobile phone use? This one .  It would be reasonable to look at the legalities, and the likelihood of them caring what I think, and decide that the work of trying to hold them to account is a pointless waste of time. Certainly, the replies I've had in the forum here: have mostly been of the "sucks to be you" variety. So let me describe in detail what it's like to try and get someone at Koodoo to reverse the charges of a blatantly egregious overuse charge. To talk to someone at Koodoo, you have to talk to a bot for a while to convince them that you need to talk to a person. It's pretty entertaining on

Trust and your mobile phone service provider

Do you trust your service provider? What does that even mean? For an individual with a relationship with a corporation, trust is not the same as trust with a person. Particularly with a complex service model, you have to have some trust in your service provider, even if you are reluctant about that, because you don't have a choice. For example, you don't have a much of a choice about what kind of service plan you get for your mobile phone in Canada, and those plans are constantly being changed by the providers, so trying to keep up with what the best plan for you is, is difficult. But aside from the aspect of "buyer beware" that covers all consumer relationships in Canada, mobile phone service is complicated by the fact that those mobile phone providers are using public resources that they make use of within a regulated system. In other words, they're selling us a package that includes resources that are only leased to them (i.e. the radio spectrum) from us, under

Managed Services: A Creative Tension

What Are Managed Services? " Managed services " is an offering of many businesses that provide Internet services. In the past couple of years, it's a term I've used to describe what I offer in my Blackfly Solutions Drupal and CiviCRM hosting business . You may not know whether you would want such a thing, since it's a very badly named thing.  This post will try and give a reason for why managed services is a thing at all, how it can be a good thing, and why it may be what you want. Here's the short version: managed services exist to fill the gap between what machine automation can reasonably provide and what people actually want. In a subsequent post, I'll explain how containers can be a useful tool for delivering managed services. What Do You Mean by Services? A "service" in the "managed services" context is the consumer-oriented one, i.e. something a consumer wants that they get from a service provider. For example: "hosting for

Successful mass mailing

Happy families are all alike; every unhappy family is unhappy in its own way. - Leo Tolstoy Like happy families, successful mass mailings are easily taken for granted as normal, but they are more an exception than a rule. Most mass mailings fail in one or more ways. And the ways that a mass mailing can fail are probably more diverse and interesting than you think. So when you ask "why am I not receiving my mass mail" or "so-and-so isn't getting my mass mail", it's rarely a simple answer. Even if it used to work fine. To put some perspective on this - if you're getting only 10% of your mass mail opened, it's not bad. Industry-wide, a 7% click through seems to be about average. In this post, I'm going to follow a piece of mass mail and show you all the different ways it can fail to be successful. I use CiviMail for my mass mailings, and but I think most of it will be tool agnostic.  To keep it simple, I won't try and go through all the ways you

An apache OOM (out of memory) emergency in a container

On Sunday last, a (Linux) server in my infrastructure that was running a fairly conservative number of docker containers in production was brought to its knees. The monitoring data (from prometheus) showed that cpu was all gobbled up (from an average of less than 2% to a steady 75%-ish) and remained gobbled up until the server was rebooted. Notably, the disk usage and throughput went down during the event, and memory usage did not change notably, nor was it notable high. On review of the messages log, one of the last entries before the event was documentation of an apache OOM (out of memory) event. On this server, apache is only running inside containers, which are generally limited to 500Mb (by docker). So presumably, a docker container running apache ran out of memory and tried to recover some memory and that was what triggered the event. Reviewing the log of requests before the emergency, it's not clear which container or url or urls might have been generating so much memory u