Sunday, June 30, 2013

Fixed permanent links

I'm embarrassed. I'd started re-using the old Blosxom code from 2003, that I'd heavily modified over the years, to re-post this blog on The one thing that I didn't do was test the links in each of the stories. It was only when someone tried to link to one of my posts (sorry Wim), that anyone noticed they were all broken.

To make it short, I've regenerated the entire site and pushed it back onto If anyone sees any other bugs, please give a shout.

Wednesday, June 26, 2013

Oh puhlease...

It's been awhile since I've discussed anything security related on this blog. This is mostly because I set that ball down every day at 4:30 and don't want to pick it back until 8:00 on the next workday. However, this article on Slashdot has me spun up enough that I'm willing to gripe about it. I can see this being picked up by the mainstream media and yet another bout of fear-mongering making the rounds. Kibo help us if they rediscover that Wemo video.

As a business idea, this is really cool. The service vendor only needs to stand up one web server which accepts commands and sends them back into the user's network. Very little needs to be stored or processed on the web server, yet the vendor gets to pull in $8 or $9 from each "premium" customer. The consumer also hands over money for the hardware.

Those who use cloud based controls to manage electrical appliances, without strong authentication and strong encryption, are taking big risks (and, no, a username and password, encrypted by SSL may not meet those requirements). If you're going to manage environmental controls over the Internet, do it on your own server and require a non-split VPN to access them. Better yet, manage those controls via a network that is entirely isolated from external access.

The primary countermeasure for the mentioned direct attacks on the protocol or the devices is: maintain a baseball bat at each of the exits from your house. Z-wave and Zigbee are very low power, very low bandwidth communications protocols, meaning if there's a direct attack on your components, the attacker is probably within view of your front or back stoop. The technical term "mechanical agitation" comes to mind.

If you want to management your environmental controls and your appliances, avoid the public services. Instead stand up your own controller/gateway, and avoid putting it on the Internet. If you don't like the DIY approach, use one of the Mi Casa Verde products (or similar vendor's product). If you do like the DIY approach, build your own with a Raspberry Pi, a Razberry interface, and an XBee interface. Both approaches are cheaper than what you'll end up paying the public services and, if you're a coder, they're also more expandable/extendable.

dnscrypt-proxy with BIND9 on the Raspberry Pi

Ever since my service provider started injecting data to replace DNS "lookup failed" messages (so that your browser showed one of their ads), I've been looking for a means to avoid using their DNS servers. Initially, it was easy. I just used a different forwarder. The ads returned when my service provider started intercepting those (my guess: via a dnsmasq variant).

This was an issue because I monitor a number of DNS entries for friends, family, and customers (as well as web server front pages and other network services). My service provider removing all "lookup failed" messages, and intercepting outbound queries, limited to what I could watch for via DNS queries.

The next step in this DNS arms race appeared to be dnscrypt-proxy. By default, it encrypts DNS queries and sends them out over port 443, to OpenDNS's name server (which also "speaks" dnscrypt). Note: you are able to change both the port and the name server, if needed.

I've added notes to the wiki for adding dnscrypt-proxy to the Raspberry Pi, including a start up script, using the code from Git Hub (vice the distributed tarball), and getting it to work as a forwarder for BIND9.

There were two drawbacks that I discovered. One is: my service provider has since discontinued the practice of injecting ads into DNS queries, while OpenDNS has taken up injecting their search page info into DNS failed-query responses. The other is: there is an issue with DNSSEC. While dnscrypt-proxy supposedly does work with DNSSEC, OpenDNS currently breaks it.

If anyone knows of a "trustable" public DNS server that works with both dnscrypt and DNSSEC, and doesn't inject traffic, please let me know. In the mean time, I'll continue to use the tool with OpenDNS, 'cause their service has other features that I like having (e.g., filtering of objectionable web sites).

Monday, June 24, 2013

Messing with bleeding edge tech

Spent a sizeable chunk of the weekend playing with the cutting edge. In this case, it was hand gesture recognition and Hadoop.

I'm slowly making my way through the free Hadoop Fundamentals I course, offered by BigDataUniversity. It got off to a slow start because of the VM included with the class. It's only available via a self-extracting RAR set, requiring a Windows machine to rebuild it. I had to install a WIndows VM, extract the RAR, THEN convert it to an ESXi VM so that I could access it. I've managed to work my way into the lab at the end of Lesson 2 so far.

Another part of the weekend was more or less wasted on my trying to get hand gesture recognition up and running. I have this idea that I can get it set up with a modified web cam so that I can gesture in a darkened room and cause the lisghts to come on.

I managed to open one of my junk box web cams up and removed the filter over the sensor. It works pretty well, requiring only minimal light in the room. The hard part (still) appears to be the software needed to recognize a hand gesture and get it to run the WeMo software. I did get OpenCV built and am able to track my face (via one of the demos). Getting it to recognize hands and hand shapes still seems to be on a build-your-own level. In short, much more research (on my part) is needed.

Sunday, June 23, 2013

Catching up

Finally had the chance to catch up on some of the wiki notes. The following articles were added (in no particular order):

  • Making an internal web server available on an external server via SSH

  • Adding Festival to Xchat2

  • Anonymous Proxies

  • Slowing down SSH brute force attacks

  • Monitoring the Temperature on a Raspberry Pi

  • Cross-referencing spreadsheets in Excel

  • Counting multiple columns in Excel

  • Macro - Copying data values between Excel spreadsheets

  • Resetting the root password for MySQL

  • Numeric sorting in MySQL

  • Fixing the Ubuntu SSH shutdown script

  • Fixing jerky Flash video

  • What to do if Fedora updates very slowly

  • Turning off Join and Part notices in XChat2

  • Start up script for ZNC

  • Compiling XV on Ubuntu

  • Opening PDFs in Chrome

  • How to add a password to your private SSH key

You can find them in the wiki by searching for an appropriate keyword, or by clicking on "Recent Changes" at the bottom of the page.

Tuesday, June 18, 2013

Setting up ddclient on the Raspberry Pi

Following are my notes for configuring ddclient on the RPi so that it updates Hurricane Electric's dynamic DNS.

First off, my configuration:

  • I run dyndns on my router to update DynDNS (for a dynamic domain). This is independent of the below and exists for other reasons.
  • I run ddclient on the Raspberry Pi (for a dynamic host/IP in a permanent domain) to allow my XMPP server to be "visible" on the Internet.
  • I purchased a domain from and edited the nameserver records so that they point to Hurricane Electric's free DNS servers.

Mathieu Lutfy has a good howto for doing setting up ddclient. It only needed a little tweaking to get it working for my use. Steps:

  1. Point a browser at
  2. Log on (upper left) or register (see opening paragraphs) and then log on.
  3. Set up your domain in the Hurricane Electric DNS server (outside of the scope of this howto).
  4. To add a dynamic record, click on "New A".
  5. Enter the hostname that will be dynamic and check the box (near the bottom) for "Enable entry for dynamic dns". This will populate the IP and TTL entries.
  6. Click submit. This will take you back to your zone listing.
  7. In the DDNS column, you should see a "refresh" icon. Click on that. It will ask you to provide the key to be used for authenticating the host with the service. Near the bottom is a green "Generate" button that will auto-generate the key. This key will be the password in your ddclient.conf file.
  8. Install ddclient via the usual means (for Ubuntu, this would be "apt-get install ddclient"). Immediately, manually kill the ddclient process as the shutdown script does NOT work properly and will not kill the daemon. You will want to wait five minutes (the TTL setting from the above) before running the service again.
  9. In the meantime, use your favorite editor to edit /etc/ddclient.conf. Make it look something like the below:
      # Configuration file for ddclient generated by debconf
    # /etc/ddclient.conf


    With the exception of the obvious hostname entries, the above differs from Mathieu Lutfy's configuration only on the "use" line. His configuration indicates that his box is directly connected to the Internet in that "use=if, if=ppp0" grabs the IP locally and provides it to the DNS server. The configuration above indicates that ddclient is running on an internal box (i.e., behind by firewall). "use=web" causes the server end to determine the external IP.

  10. Start the ddclient service and check your log files (for Ubuntu, this is /var/run/daemon.log). You should see an entry somewhat like:
      Jun 18 05:30:57 pi1 ddclient[15458]: SUCCESS: updating good: IP address set to YourExternalIP

    If you don't see that, ddclient will generate a number of entries which can be used to troubleshoot the error. Please heed any warning to not attempt update before 5 minutes has passed (sending a corrected entry too soon will be ignored).

Thursday, June 13, 2013

Running misc. stuff on the GoFlex

It started as an effort to reduce the house power bill and has grown a bit. The home server draws some serious power and coverts a lot of it to heat (nice in the winter, not so nice in the summer).

I've been playing with various low-end devices (access points, file servers, etc.) to see what's usable. The one that appears to be the most useful (so far) is a converted GoFlex Home, which now runs a variant of Arch Linux.

It's currently running Apache, PHP, and MySQL, supporting TT-RSS (a RSS feed aggregator/reader), two instances of SemanticScuttle (a bookmark manager)(one for short term storage, the other for long term), and a copy of PmWiki. I'm looking to add OwnCloud, BIND (DNS), WOL (to wake up the big server), knockd (for remote access), and some soft of XMPP aggregator (Bitlbee, maybe?).

So far, it seems to be holding its own, even though it's a little slow in presenting the Ajax interface for TT-RSS. The one thing that I did have to do in support of this was to add a swap partition to beef up the memory.

I'm still undecided if I should host the main wiki on the GoFlex as it has more active content on it than the GoFlex likes (I tried it). Maybe move the active content to it's own page on the big server and post the more-or-less static stuff on the GoFlex? It has a 2TB drive attached to it so it'll at least have a backup copy of all of the kruft that I've gathered since I first started messing with computers in '84 (yeah, CompuServe/pre-Internet days).

Update: Putting the big wiki on the GoFlex didn't work well as there's just too much extra code running in the background (status monitors, presence indicators, etc.).

Wednesday, June 12, 2013

How to open the PogoPlug (v4) case

Not that you'll need it for anything, but if you're ever interested in opening a version 4 PogoPlug, use the following steps:

  • On the bottom, peel back the two rubber feet which are closest to the jacks. The adhesive employed will allow you to stick them back on later.

  • Remove both screws

  • Use a spudger or similar tool to pry the base from the case. Note: the most obvious seam (the one that runs from above the jacks on the back to below the logo on the front) is just decorative. The base piece is only about a quarter-inch thick. Looking at the PogoPlug from the side, try putting the spudger into the tip of the pointy part. (picture below)

  • Work the spudger around the seam. You'll hear various clicks as plastic tabs release (note: some will likely break). Continue working the spudger until you have the case open.


Wednesday, June 5, 2013

Running Openfire on the RPi

It appears that the only extra thing that you need to get Openfire up and running on the Raspberry Pi is patience (lots of it). Mostly it's because the RPi is so much slower than a normal desktop system.

Installing the prerequisites takes longer. There's quite a few if you're installing all of the pre-reqs on a clean install of Raspbian. I cheated a bit and used a MariaDB install running on a nearby GoFlex (also a bit slow).

Performing the configuration piece of Openfire is what takes the longest. Below is a temperature graph of the RPi in use. The spike, just after midnight on Tuesday, is about an hour long. This was only the piece between filling in the administrator's password and clicking next. This is where the install scripts go off and populate the database, add plugins, and generally tie up the processor.


At the time of this post, Openfire has been running about 2 days without issue. According to the "Server Information" page in Openfire, it's running version 3.8.2 on about 15 MB of memory and top is reporting a server load that fluctuates between 0.03 and 0.10. Java being the most active process.

This weekend, I'll need to install all of the other plugins and the two bots which watch the DMS. I'm hoping it doesn't eat up too much more processing cycles.

Sunday, June 2, 2013

Invasion of the Pedants

I've been a member of a certain online community for just about a decade. Admittedly, I was dragged there (kicking and screaming) by a friend. While he eventually moved to focus on other things, I hung around and provided support in the background in the form of research/review, writing/debugging code, and authoring occasional verbiage.

Sadly, I've just let the community know that I was ceasing all active support. While a certain few can still request custom work of me, the remainder of the community should feel free to ignore me as actively, as passionately, and as incessantly as humanly possible. Please!

What had happened was that a pedant announced that specific words should no longer be employed in documentation because it reminds a certain demographic of their disability. Being a member of that demographic, I took offense at the suggestion and pointed out that the logic he used to justify his suggestion implies a certain prejudiced over-sensitivity by the disabled. I publicly responded and noted such.

It turns out that, where I thought that I was dealing with a single pedant, he had compatriots. In short, the community reacted by taking me to task for top posting in email, rather than addressing the offensive logic.

Fewer things can kill a community effort quicker than a couple of pedants, especially if they have any sort of authority within that community. While I wish the overarching project good will, I suspect that the associated volunteer effort will suffer in the coming years.

What triggered the above rant was this post about what appears to be an effort to make a specific pronunciation mandatory. In short, the author has submitted formal suggestions to "standardize" pronunciation. Hopefully, the group will give the suggestion the time it deserves (i.e., none).

So, to the group which I've just left (as a whole): 'Bye. The annual get-togethers were fun/interesting. We even saved a life once.

To the pedants in the group: GFY. You deserve each other. Same goes for any pedant which this post offends.

To the other group (Ubuntu): good luck. I'd considered joining, but it appears that you also have a pedant infestation. Maybe later.