After upgrading one of my Kodi media center boxes from a Raspberry Pi B+ to a Raspberry Pi 2, I decided to play with NetBSD on the old Pi B+. Installing NetBSD is a simple process and the install docs cover it well, but here are a few notes that might be useful for completing your post-install configuration. The NetBSD documentation should be your first resource, of course; this just covers a few Pi-specific things I found relevant.

Since the install process is really just writing a disk image to the MicroSD card and then booting the system, you’ll have to manually complete a number of configuration steps that would usually be handled by the installer. Fortunately, it’s pretty straightforward.

First Boot

Expect the first boot to take some time. The system will resize the / partition to use all available space on the MicroSD card (more on this later) and generate SSH host keys. This will not be fast.

You’ll eventually get a login prompt. root has a blank password by default. Hostname will be rpi. The DHCP client is active by default, so you may have a working network connection.

Network Configuration

I wanted a static IP address, so I created /etc/ifconfig.usmc0 with the contents:

inet 192.168.1.25 netmask 255.255.255.0

I also defined my DNS nameserver in /etc/resolv.conf:

domain irascible.net
nameserver 192.168.1.1

NetBSD uses the /etc/rc.conf file as the main system-wide configuration file. The following changes are all made to that file.

I defined my hostname and default route, and disabled the DHCP client:

hostname=raspberrypi.irascible.net
dhcpcd=NO
defaultroute=192.168.1.1

Time Configuration

The Pi has no real-time clock, so you’ll want to use ntpdate to set the clock at boot. The -b option jumps the clock to the correct time, rather than trying to correct it by slewing. I also chose to enable ntpd to keep the clock synched:

ntpdate=YES
ntpdate_flags=”-b”
ntpd=YES

The system will be using UTC time by default. Set it to your preferred timezone instead:

ln -fs /usr/share/zoneinfo/Your/Zone /etc/localtime

It’s not gonna get any bigger!

After the first boot, there’s no need to try to resize the disklabel and root partition on every reboot, so those options can be turned off:

resize_disklabel=NO
resize_root=NO

Enabling PF

NetBSD includes a (rather outdated) version of OpenBSD’s excellent pf firewall, which I wanted to use. Note you’ll also need an appropriate pf.conf file. To enable pf and the pf logging daemon:

pf=YES
pflogd=YES

pkgsrc Configuration

NetBSD uses pkgsrc for package management. Somewhat confusingly, you don’t actually set your $PKG_PATH variable in /etc/pkgpath.conf; it goes in /etc/pkg_install.conf instead:

PKG_PATH=http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/earmv6hf/7.0_2015Q3/All/

You can then pkg_add to your heart’s content. Note that pkgsrc does quarterly releases of binary packages, so the 7.0_2015Q3 portion may need to be updated.

More Power! More memory!

The Raspberry Pi doesn’t have anything like a BIOS interface for setting low-level hardware configuration options. Instead, you can edit the /boot/config.txt file to make changes. On my system, I’m doing a moderate overclock to extract a bit more performance from the anemic hardware. Obviously, do this at your own risk; my Pi has added heatsinks and has been perfectly stable with this mild overclock.

By default, 64 MB of memory will be allocated to the GPU. If you’re planning to run your Pi headless, there’s no reason to dedicate unneeded memory to graphics, so you can crank that down to 16 MB:

arm_freq=800
core_freq=300
sdram_freq=400
over_voltage=0
gpu_mem=16

Unresolved Issues

As mentioned earlier, the first boot process will resize the / partition to use all available space on your MicroSD card. I’m not a huge fan of this, since I really like having at least /var and /tmp on their own partitions. A reasonable approach would seem to be: shrinking the filesystem on /dev/ld0a using resize_ffs, updating the disklabel to match, then adding new partitions and filesystems as desired.

I haven’t actually been able to accomplish this yet due to issues with resize_ffs. I’m using a 32 GB SD card with my Pi, which results in a / partition of 28 GB. If I boot single-user and try to shrink the root partition with resize_ffs, I get the error:

resize_ffs: Can’t map 1936261120 bytes for inodes: Cannot allocate memory

resize_ffs is trying to grab 2 GB of memory on a box with 512 MB total, which obviously isn’t going to fly. I’ll have to circle back to this. I think a better approach would be updating the disk image to NOT resize on first boot.

Version 14.0 of XBMC came out a few days before Christmas, though it’s now rebranded as Kodi (not a fan of the new name). I took advantage of some vacation time to rebuild my setup and update from XBMC 13.1.

Previously, my XBMC systems were Windows-based. Not my first choice, but back when I built them, there were major hassles involved with getting HDMI audio to work properly in Linux. Windows clients meant I needed Samba on my file server, which was also not my first choice.

For the rebuild, I chose OpenELEC, which is essentially a very stripped-down, appliance-like Linux distro that runs on multiple hardware platforms. Being Linux-based, it can speak native NFS, which allowed me to ditch Samba.

Server configuration

My OpenBSD file server uses MariaDB for the SQL back-end and the native NFS server for presenting the media library. NFS configuration on OpenBSD is simple and well-documented. Configure your exports in /etc/exports and enable the portmap,mountd, and nfsd daemons; that’s all there is to it.

Minor annoyance: portmap and nfsd bind to consistent ports, but mountd picks 2 random privileged ports. Annoying, but that’s how the protocol is supposed to work, per RFC 1094. If you use PF on the NFS server, you’ll need some ugly rules like:
pass in on $lan_if inet proto udp from <kodihosts> to $lan_if port < 1024
pass in on $lan_if inet proto tcp from <kodihosts> to $lan_if port < 1024
Or, if you want to be more thorough, dynamically update the ruleset via a script and anchor.

OpenELEC clients

OpenELEC installation is straightforward; just follow the docs. I replaced one of my old (and increasingly noisy) PCs with a Raspberry Pi. I mildly overclocked it and added an MPEG-2 license to get hardware-accelerated playback of DVDs.

OpenELEC works very well as installed, but one area needed some attention: by default, it allows ssh access to root, with a hardcoded, publicly-published password. No, seriously:

How do I change the SSH password?

At the moment it’s not possible to change the root password as it’s held in a read-only filesystem. However, for the really security conscious advanced user, you can change the password if you build OpenELEC from source.

This is utterly insane and indefensible. While you wouldn’t want to expose one of these systems to the Internet in the first place, this kind of total disregard for security is just appalling. And their suggested solution is to recompile everything with a different hardcoded password.

A much better solution is to set up ssh keys and then disable password logins, which can be done from within the GUI.

Library Sharing

Setting up Libary Sharing is well-documented and straightforward, assuming you have a bit of SQL familiarity. I’m not thrilled by their suggestion to GRANT ALL ON *.* TO 'xbmc';, but since nothing else is using that SQL instance, I won’t squawk too loudly about it.

Once the initial setup is done, additional clients just need the advancedsettings.xml file to connect to your database and find your library. Fairly slick.

The Inevitable Snag

Every IT project has one…

I installed the Kodi .apk on my Android tablet, added my advancedsettings.xml file, and promptly found that I couldn’t play any videos on the tablet. A few minutes of troubleshooting ran down the issue.

Kodi insists on using unprivileged ports for NFS:

Your NFS server on your NAS needs to be able to allow connections on so-called unprivileged ports, which are port numbers higher than 1023. However, most NAS’s are set up by default to deny incoming NFS connections on these unprivileged ports.

And OpenBSD’s mountd does not allow them:

The -n flag historically allowed clients to use non-reserved ports when
communicating with mountd. In OpenBSD, a reserved port is always used.

So… that simply won’t work. Fun.

Just some quick notes, for later reference…

Background: some recent 9mm Glocks (both Gen3 and Gen4) have been plagued with erratic ejection, including a tendency to throw empties straight back at the shooter’s face (the problem is often abbreviated as BTF, for “brass to face”). Glock introduced a revised ejector that’s supposed to help. It’s standard equipment on new Gen4 guns, and reportedly is often retrofitted to Gen3 guns that are sent back to Glock due to BTF complaints. The old ejector is stamped with “336”, the new one with “30274”.

It’s straightforward to install the new ejector in a Gen3 gun. Bare ejectors are not sold as replacement parts, so you’ll need to order part 30275, which is a Gen4 trigger housing with ejector. Here’s a Gen3 trigger housing on top, a Gen4 below. Note that they are NOT cross-compatible, so you can’t just drop in the whole assembly.

comparisonAnd a close-up of the ejectors:

inhousings

You’ll have to use a small punch or screwdriver to push the ejector forward and out the front of the trigger housing. Remove the 336 ejector from your Gen3 housing and the 30274 from your Gen4 housing, swap ejectors, and reinstall. Here’s the bare ejectors, Gen3 on top, Gen4 below.

bareejectors

The 30274 has a much larger contact surface at the tip and a very different angle. It’s also canted in farther toward the center line of the gun (excuse the lousy focus; you get the idea).

fromfront

Does it work? I don’t know yet. I swapped out the ejectors today but haven’t had a chance to take it to the range. Stay tuned, I suppose…

shortround

Last week I shared this photo with some friends and got several questions in response. So, I figured I’d offer a few words of advice on sanity-checking ammunition prior to hitting the range.

The two rounds shown in the picture are both 115-grain 9mm cartridges from Freedom Munitions. The one on the left is perfectly normal, while the round on the right has its bullet seated too deeply. This is a potentially dangerous condition, because the deeply-seated bullet will cause elevated chamber pressure if it’s fired. While this particular instance is likely not severe enough to cause damage or injury, the round is still defective and shouldn’t be used.

I caught this defect because I make it a habit to check my ammunition before loading it into magazines. Factory ammo is generally pretty reliable, but the extreme shortages of the past few years have caused some quality-control lapses. Manufacturers have been scrambling to keep up with demand, resulting in more defective rounds slipping past inspection. I’ve personally seen defects from Winchester, Remington/UMC, and several smaller manufacturers. It’s worth noting that I have *not* encountered any bad ammunition from the ATK brands (Federal, CCI and Speer); they seem to be doing better on the quality-control front.

So, how should you examine your ammo before going to the range? Here’s what I do:

Ammunition typically comes in a styrofoam or plastic tray inside a cardboard box. Flip the box upside down…

ammo1

And slide the contents out onto a tabletop.

ammo2

Take the tray off the top and your ammo is neatly arranged for a quick visual inspection:

ammo3

Any rounds that are taller, shorter or crooked will be immediately apparent. Give the table a little nudge; any rounds that wobble probably have primers that aren’t fully seated.

ammo4

if you shoot a lot, you might want to buy a chamber checker like this one from Evolution Gun Works; it’s basically a block of aluminum with chambers machined into it. Loaded ammunition should drop in freely, sit flush with the top surface of the chamber checker, and fall out freely. Any rounds that don’t pass the test should be examined carefully or discarded.

ammo5

This round of reloaded ammo has a case that wasn’t completely resized, preventing it from dropping all the way into the chamber checker:

ammo6

For pistols with removable barrels, you can use the barrel itself as a chamber checker. Field-strip the gun and drop individual rounds into the chamber of the barrel. Again, they should fall in and out freely, and the head of the cartridge should be flush with the rear edge of the barrel.

ammo7This kind of quick inspection adds less than 5 minutes to my prep time and I consider it time well spent. It won’t catch every possible defect, but it’s a sensible and effective way to spot cartridges that are obviously out of spec. Of course, if you have any reason to doubt the quality or safety of your ammunition, don’t shoot it!

SSL Certs… again

Huh, there’s still a blog here. Neat.

After all the fun I had with generating and installing an Android-compatible CA cert, the Android 4.4.2 update for my device decided to throw one more curve my way: a persistent notification that “Network may be monitored By an unknown third party,” thanks to my self-signed root cert.

Sigh. Spend enough time fucking around with self-signed certs and the $9/year for a “real” SSL cert quickly begins making sense. After all, those are trustworthy because no “real” CA has ever been compromised, right? Right?

… under a very loose definition of “fun.”

This one sent me down a rabbit hole for a few hours, so I figured I’d write it up for my own future reference, and maybe spare others from some pain.

I have an OwnCloud server with an SSL certificate signed by my own CA cert, and I was trying to set up DAVdroid to sync my calendar and contacts against it. First, I had to get my CA certificate installed on my phone, which goes something like this:

  1. Get the CA cert into DER format, with a .cer or .crt file extension. The magical OpenSSL command-line incantation will look something like: openssl x509 -outform der -in certificate.pem -out certificate.crt (no, I don’t know why Android can’t accept PEM format. Google says you need DER or PKCS#12.)
  2. Get the CA cert onto internal storage. Post it somewhere you can download it, or copy it to an SD card and then to internal storage. (No, I don’t know why you can’t load it directly from the SD card. Because Google, I guess.)
  3. Go to Settings > Personal > Security > Credential storage > Install from storage. Android should find the cert and prompt you to install it.

That all went well enough, and Android told me the cert was successfully installed. Weirdly, though, I didn’t actually see it listed under the user-installed CA list. It also wasn’t actually working. I browsed to my OwnCloud site and got a certificate error. DAVdroid also refused to connect to my OwnCloud server, reporting only “Cannot verify hostname.”

(insert 80s-style montage representing too much time spent researching and reading documentation)

Eventually it became clear that my CA cert was in X.509 v1 format, and Android insists upon X.509v3 format, with the basicConstraints=CA:true extension. This appears to be an Android-specific quirk; I’ve never had a problem importing my CA cert into a web browser.

Solving the problem required regenerating my CA cert with the required X.509v3 extension. That, in turn, required digging into the truly awful OpenSSL documentation to figure out how to accomplish such a seemingly simple task. In the end, I couldn’t find a way to specify the basicConstraints=CA:true extension on the command line; instead I added this stanza to my openssl.cnf file:

[x509v3_CA]
basicConstraints=CA:true

Then, I generated a new CA cert, adding -extensions x509v3_CA to the command-line arguments. Generated a new CSR, signed it with my new CA cert, juggled all the files to the right places, and imported the new CA cert into my phone. Sure enough, it imported successfully, showed up in the list of user-installed certs, and made the Android browser and DAVdroid happy.

It appears that there may be a way to add this extension to an existing CA cert to avoid regenerating everything, but (A) I was already far enough down the rabbit hole, thanks, and (B) I only needed the one certificate for my own personal use.

Google had a bug report opened for this issue, but closed it as “WorkingAsIntended”. If you say so, guys…

I’m told that the process for adding a CA cert to an iPhone is even more tortuous (torturous?), but I have no plans to go down that road.

I did not know that.

I was looking into a MySQL performance issue with one of my teammates when I ran into this odd little quirk.

Older versions of MySQL come with a set of sample configuration files (my-small.cnf, my-medium.cnf, my-large.cnf, and my-huge.cnf) suitable for systems with varying resources and workloads.

The my-large.cnf and my-huge.cnf files set a value for the thread_concurrency variable and suggest, “Try number of CPU’s*2 for thread_concurrency.” Since we were working on a 4-core system, setting a value of 8 seemed like a good idea.

Except, as it turns out, it’s basically worthless. thread_concurrency only works on old versions of Solaris and does nothing at all on other OSes. Which makes one wonder why it’s included in the sample configuration files…

OpenSSL and AES-NI

Playing around with OpenSSL’s built-in speed test today, I discovered that the default ‘openssl speed’ command won’t take advantage of AES-NI acceleration, even if your processor supports it. To get AES-NI goodness on the speed test, you have to specify the ‘-evp’ option along with the AES mode to speed-test.

On a Core i5 M 520, without using AES-NI:

OpenSSL 1.0.0f 4 Jan 2012
built on: date not available
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: information not available
The ‘numbers’ are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc      38655.36k    42473.27k    47143.80k    98004.28k    98783.00k

and with AES-NI:

OpenSSL 1.0.0f 4 Jan 2012
built on: date not available
options:bn(64,64) rc4(8x,char) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: information not available
The ‘numbers’ are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc     356674.40k   379020.78k   416202.59k   418317.61k   418009.73k

This is on an OpenBSD/amd64 5.2 system. Yes, it’s (over-)due for an OS upgrade. But yeah, AES-NI gives you a performance boost of 4x-9x. Nice!

XBMC on Nook HD

The Android port of XBMC seems to work pretty well. After installing the .apk and launching the app once so it could create its config files, I just had to add my advancedsettings.xml and passwords.xml files to get the tablet talking to my Samba/MySQL back-end.

It appears that hardware decoding might not be working; standard-definition content plays just fine, but 720p x264 video stutters badly, and 1080p is hopeless. It’s still early days for XBMC on Android, so this may (hopefully!) improve with the next release.

Sitting with a friend in the in-store coffee bar at a Barnes & Noble this afternoon, getting caffeinated to the gills, an announcement over the PA system caught my attention: Nook HDs (the little Android tablets that had just been discontinued a few days previous) on sale for $99. Hmm.

I’d avoided tablets until now for a couple of reasons: the chaotic and immature market, with dozens of companies seemingly introducting and discontinuing models on a daily basis, and my own lack of a clear need/use for a tablet.

Also, I’d never seriously considered the Nook (or Amazon’s competing Kindle tablets) because I’m really not interested in a specialized tablet designed to channel money directly from my wallet to an e-tailer, all while staying securely confined within their walled garden. But a few minutes of Googling revealed that an unoffical port of the Cyanogenmod open-source firmware existed and could be installed without undue hassle. Hmm again.

A quick review of the specs showed a dual-core processor, a gig of RAM, and a 7″ LED-backlit screen at a rather impressive 1440×900 resolution. For a C-note. And I get to have a little fun hacking it and subverting the manufacturer’s intended use. Alright. Sold.

I found a quick-and-dirty HOWTO on installing Cyanogenmod (downloading cryptically-named ZIP files from a Russian website! This can’t possibly end badly!) and had the OS up and running within a half-hour. Then I loaded the .apk for the F-Droid open-source software repository and had a shiny little 100% open-source tablet sitting on my kitchen table.

Initial impression is positive. It’s snappy and stable so far, though I can’t say I’ve really thrown much of a workload at it yet. Some of the features you’d expect in a general-purpose tablet are missing; notably, there’s no cameras or GPS. Will I miss either feature? Probably not.

It remains to be seen how much use I’ll get out of a tablet. I installed the FBReader e-book reader, along with VLC and a handful of other apps. There’s a not-entirely-polished Android port of XBMC that’s worth playing around with. Tablets are obviously better suited to media consumption than creation (I’m typing this on my laptop right now…) so we’ll start out with books, movies and music. Stay tuned?