Rotate nginx logs on FreeBSD with newsyslog

I’ve moved from using Apache as a web server to nginx for various projects. The machines I’m running these projects on are a somewhat resource constrained and nginx deals with low resource machines much better than Apache does and tends to serve content faster in those circumstances. For example switching the machine that hosts this WordPress blog from Apache and mod_php to nginx with php-fpm improved the pingdom load times on this blog by about 30% with no other changes.

The last piece of the puzzle was to get newsyslog to rotate the nginx logs. The instructions on BSD Start suggest they’re for FreeBSD 10, but they work fine on FreeBSD 9.x as well.

Building Emacs on OS X using homebrew

I’ve recently switched to using Homebrew as my source for Emacs on OS X  after seeing this blog post by Philip Ingram.

It’s a simple way to install a current Emacs once or twice a year. I don’t use beta versions or other pre-release versions on “productivity” machines, only released versions. My editor is too important a tool for me to risk using pre-release versions.

Good analysis on the Android security ecosystem

I recently blogged about Google and Samsung starting to offer regular security patches for their Android devices.

Over on ars technica, Ron Amadeo has an interesting article describing why the current Android ecosystem is not conducive to the quick and widespread distribution of security fixes and why this needs to change, urgently.

At this point in time it seems that in order to be halfway secure, one has to basically root the phone and run well-tested and well supported distribution like CyanogenMod. While I – and presumably most, if not all, readers of this blog – certainly have the technical know how and abilities to root a phone, that’s a poor approach to security because most people either will not or cannot root their phones.

An elegant way to extract keys from a C++ map

I’ve been doing a reasonable amount of Clojure development recently and like a lot of other Lisp dialect have marveled at the ease of separately pulling out the keys and values from a map. This is a very common operation after all, but C++ does only appear to support manual key or value extraction from a std::map.

Obviously the code isn’t hard to write. In C++11, the following function will return a vector of all keys in a map:

std::vector<std::string> extract_keys(std::map<std::string, std::string> const& input_map) {
  std::vector<std::string> retval;
  for (auto const& element : input_map) {
    retval.push_back(element.first);
  }
  return retval;
}

Same goes for the values:

std::vector<std::string> extract_values(std::map<std::string, std::string> const& input_map) {
  std::vector<std::string> retval;
  for (auto const& element : input_map) {
    retval.push_back(element.second);
  }
  return retval;
}

This being C++, we most likely don’t want to go and write the code every time, so we turn it into a set of templates:

template<typename TK, typename TV>
std::vector<TK> extract_keys(std::map<TK, TV> const& input_map) {
  std::vector<TK> retval;
  for (auto const& element : input_map) {
    retval.push_back(element.first);
  }
  return retval;
}

template<typename TK, typename TV>
std::vector<TV> extract_values(std::map<TK, TV> const& input_map) {
  std::vector<TV> retval;
  for (auto const& element : input_map) {
    retval.push_back(element.second);
  }
  return retval;
}

The code above is reasonably efficient under most circumstances. Yes, you can improve it by calling retval.reserve() to make sure we don’t have to reallocate memory for the vector and make some other small tweaks, but overall, the couple of lines above do the job.

They’re also a lot better than finding the above for loop in the middle of a function. That requires me to scratch my head for a couple of seconds before the usual dim light bulb appears over my head and tells me, “hey, someone’s trying to pull the keys out of a map”. Why is this?

Because just having the loop floating around in the middle of your or my code doesn’t document intent, all it documents is that, well, we have a loop that copies stuff. Even if you wrote the code and then come back to it six months later, this is likely to give you a bit of a pause until you remember what it does. Of course you can put a comment right next to it, but that is also a poor attempt at documenting intent. Not to mention that the comment will go out of date faster than the code itself will. Using a function with a descriptive name is much better as you can then read the code and the function name gives you a reasonable expectation what the code is supposed to do.

Of course, if you use Boost, you can just write this piece of code using the boost range libraries:

boost::copy(input_map | boost::adaptors::map_keys,
            std::back_inserter(output_vector));

It’s probably not going to do Good Things for your compile time, but it’s succinct, readable and documents intent.

Why I’m suspicious of car insurance dongles

Some security researchers from UCSD showed a proof of concept exploit via one of the dongles that appears to be also used by car insurance companies to monitor your driving “to give you discounts for good driving”. I’m not really a fully paid up subscriber of the tin foil hat brigade but stuff like this makes me glad that I’m still opting for the old-fashioned way of paying for car insurance. Of course the fact that over half our fleet is too old to be OBD-II compliant may have some bearing on that as well…

Not knowing much about CAN bus, my assumption is that in order to get access to certain pieces of data, the dongle will have to put commands on the bus and read the responses. That part is blindingly obvious. Good security practices however would suggest that such a dongle would have a built-in mechanism that restricts the commands it can issue to the set of commands it actually needs to issue to fulfill its function rather than just allowing commands through unfiltered, especially if said dongle is connected to the outside world. I mean, with the ability to issue arbitrary commands to a pile of steel weighing a couple of tons and potentially moving at 70-80 miles per hour, what could possibly go wrong?

On the other hand, instead of having to invent one of those EMP devices as “showcased” in Fast & Furious to stop a street racer, all law enforcement has to do is to send the car an appropriate (or rather, inappropriate) text message.

If anybody needs me, I’m over on Hemmings.com looking for a Ford model A. Try texting that one to stop.

Scheduling WordPress posts with org2blog

Another metablogging post, but this may come in handy for people who like to produce blog posts in bulk and schedule them for publication in WordPress at a later date.

In my case, my ability to find time to blog is directly correlated to my workload in my day job. That’s why you see regular gaps in my posting that may last for a few weeks to a month or two.

To counteract this, I try to write multiple blog posts in one sitting when I’ve got both the time and am inspired to write, then schedule them such that WordPress pushes them out automatically over the next few days or weeks. My normal workflow for this was:

  • Write post in org2blog
  • Publish post to WordPress, adjust the publication date
  • Edit the post in org2blog again, push in and then remember to tweak the publication date because org2blog overwrote the publication date

The last two steps of course are unnecessary. See the #+DATE: line in the first line of the screenshot?

org2blog highlighted date entry
Date section in an org2blog post during editing

When you create a new blog post using org2blog/wp-new-entry, just edit the date that org2blog automatically inserts to your desired post schedule and the setting will carry over into WordPress. Easy if you know how.

TLS issues with Emacs and Git for Windows

I’ve recently blogged about adding TLS support to Emacs 24.5 on Windows and improving git performance on Windows by installing an alternative git command line client. The reason I ended up investigating how to add SSL and TLS support to Emacs is that when I originally upgraded from the official git Windows client to the Git for Windows build, I ended up with non-working TLS support in Emacs.

The TLS issues only occur if you tell the git installer to add git and all supporting Unix utilities to the path, which is not the default setting for a git installation on Windows.

However if you do install git with this setting, Emacs ends up finding the openssl libraries on the path. This works fine with the older versions packaged with the installer from git-scm.com but results in TLS issues with SSL/TLS connections failing with the newer binaries shipped with Git for Windows. I didn’t dig deeper into why I was seeing the issue as I was in a hurry to get Emacs working again, so I looked for the quickest way to resolve it.

tl;dr – if you’re running into TLS issues with Emacs on Windows and just installed Git for Windows, follow the instructions in Adding TLS Support to Emacs 24.5 on Windows to get SSL/TLS connection from inside Emacs working again.

Improve git performance on Windows without patching your git install

I’ve blogged about improving the performance of Git on Windows in the past and rightly labelled the suggested solution as a bad hack because it requires you to manually replace binaries that are part of the installation. For people who tend to use DVCSs from the command line, manually replacing binaries is unlikely to be a big deal but it’s clunky and should really be a wakeup call for some people to include a newer base system.

By now there is a much easier way to get the same performance improvement and this is to use Git for Windows instead of the default Windows git client from git-scm.com. Not only does the Git for Windows installer include the newer openssl and openssh binaries that I suggested dropping into the git installation directory in my original post, it is also a much newer version of git.

For me, installing the Git for Windows client kills a couple of birds with one stone.

First, it addresses a large part of my complaint that Windows is a second class citizen to the Git developers. Using git on Windows is still a tad clunkier than using it in its native environment (ie, the Unix world) but a dedicated project to improve the official command line client goes a long way to address this issue. Plus, the client is much more up to date compared to the official client from git-scm.com.

Second, addressing the performance issues that the official client has is a big deal, at least to those of us who need to work with git repositories in the multi-gigabyte size class. With repositories of that size, it does make a difference if your clone performance suddenly is an order of magnitude faster. In my case it also finally allows me to use these large git repositories with Mercurial’s hg-git plugin, which simply was not possible before.

I’ve not tried to verify if the newer openssh and openssl binaries address the issue I described in Making git work better on Windows. My assumption is that it’s not the case as I saw the same behaviour with the manually updated binaries. For use with a CI system like Jenkins I still recommend to use http access to the repository.