Lowe's OC821 Iris Outdoor Video Camera

Some quick links to help others find information about using the Lowe's OC821 outdoor video camera without paying for the overpriced Lowe's security monitoring system.

• Lowe's setup guide
• User manual
• As described here, you can hit the reset button and login to the web interface with "administrator" and no password.
• Terence reported success getting the motion-triggered email of video to work. It didn't work for me.

Honestly though it looks like this camera was designed to be used via the API from the Iris hub, which I don't want to pay for. I'm going to replace it with something (Dropcam or similar) that doesn't require ongoing fees and has a better phone app.

Bash default value environment variable that can be overridden

Often in bash scripts I want to have a constant that is overridable. It's something I expect people to want to change but isn't worth creating commandline options for.

Here's how to do it:

#!/bin/bash

: ${OVERRIDABLE:="thedefault"}

echo ${OVERRIDABLE}

And it works like this:

$ bash ./temp.sh 
thedefault
$ OVERRIDABLE="overridden" bash ./temp.sh 
overridden

launchd ThrottleInterval

Apple's documentation of the launchd options leave a lot to be desired.  It leaves out important details and is fairly ambiguous about lots of things. Various people are trying to document it themselves, so here's another addition for ThrottleInterval.

The launchd.plist man page says:

ThrottleInterval:  This key lets one override the default throttling policy imposed on jobs by launchd. The value is in seconds, and by default, jobs will not be spawned more than once every 10 seconds. The principle behind this is that jobs should linger around just in case they are needed again in the near future. This not only reduces the latency of responses, but it encourages developers to amortize the cost of program invocation.

What it really means is this:

By default jobs are expected to run for at least 10 seconds. If they run for less than 10 seconds, they will be respawned "10 - runtime" seconds after they die. Exit code is ignored, all that matters is runtime. If a job runs for more than 10 seconds then exits, it will be respawned immediately (assuming all other restart conditions are met).

So instead of just throttling how often a service gets restarted, ThrottleInterval also implies minimum runtime. Which is surprising to more than just me.

You'll see a message like this in the logs if the service dies inside the ThrottleInterval:

com.apple.xpc.launchd[1] (com.apple.mdworker.shared.03000000-0000-0000-0000-000000000000): Service only ran for 3 seconds. Pushing respawn out by 7 seconds.

Python check compilation flags: CFLAGS

Here's a handy command to print the CFLAGS that python was compiled with:

$ python-config --cflags
-I/usr/local/Library/Taps/homebrew/homebrew-core/PYTHON_ENV/include/python2.7 -I/usr/local/Library/Taps/homebrew/homebrew-core/PYTHON_ENV/include/python2.7 -fno-strict-aliasing -fno-common -dynamic -march=core2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes

pip and distutils setup.py cheatsheet

Download source for version 2.1:

pip download somepackage==2.1

Make a source distribution and stick it in another directory:

python setup.py sdist --dist-dir="${HOME}/dist-out"

Build wheels:

python setup.py bdist_wheel

you'll find them under dist/

Building a debian package for PPA distribution

Before you start packaging for PPA you should know two things:

1. Packages must be built from source only. PPAs do not accept built .debs. Only source tarballs are allowed for security and opensource licensing reasons.
2. All dependencies must be satisfied from the ubuntu repo or other PPAs. No internet access for build due to security and build repeatability.

Those two things basically made it impossible for me to use a PPA, but here's the notes anyway.

1. Create a launchpad account.
2. From your account page you can click "Create a new PPA".
3. Add your gpg key to your account as explained here. Use this to get the fingerprint:

gpg --fingerprint

4. Update your debian/changelog file for the new version by running:

dch -i

5. Build your source package. Personally I found creating a Dockerfile was a nice way to do it that avoided having to install all the build dependencies on my own system (although this may not be worth it if you are just going to build the source package). Pbuilder is also an alternative. Inside your Dockerfile you will run this to get an unsigned .changes and .dsc:

dpkg-buildpackage -S

6. Sign your .changes with debsign. You only need to specify -e here if your keyname is different to the package maintainer email in your control file.

debsign -e myemail@mydomain mypackage_3.1.0-2_amd64.changes

7. Upload to the PPA:

dput ppa:myusername/testppa mypackage_3.1.0-2_amd64.changes

Changing virtualbox dhcp address range for vagrant VMs

It seems to be impossible to change the default vagrant address range from 10.0.x.0/24 to anything else for virtualbox VMs. This is virtualbox's fault. You can change the address range for individual VMs like this, note you need to shut it down first:

$ VBoxManage list vms
"ubuntu-xenial-16.04-cloudimg" {ea0e8dfd-55b9-48c7-b568-e933d0853762}
$ VBoxManage modifyvm "ubuntu-xenial-16.04-cloudimg" --natnet1 "192.168.23.0/24"

But that's just that VM, when you tear it down or create a new one with vagrant it will still come up with 10.0.x.0. You can of course also specify a specific IP in your Vagrantfile, but then you need to do that for every box.

I think you should be able to use this feature to create a new nat network with the new address range, and then tell vagrant to use that network in your Vagrantfile. But I haven't actually tried this because it means everyone using your Vagrantfile has to then have the same setup.

Really what needs to happen is that VirtualBox should have a global setting for their inbuilt NAT that allows you to change the address range.

Detecting prelinking breakage

A long time ago RHEL made a bad decision to have prelink enabled by default. This has caused various forms of hard-to-debug heartache for people including me, as a maintainer of a pyinstaller package. The performance gains are dubious, and it causes problems with ASLR and rpm verify (since binaries are modified post-install). Thankfully I believe it is off by default in new versions of Red Hat.

Here's a quick troubleshooting guide to see if prelinking is causing unexpected modification of your binaries.

First check to see if it is enabled:

grep ^PRELINK /etc/sysconfig/prelink

You can also check to see if the binary itself is prelinked using readelf.

To disable it system-wide set "PRELINKING=no" in /etc/sysconfig/prelink and run /etc/cron.daily/prelink as root.

The symptoms are that the binary changes size and hash, but passes rpm --verify (since verify knows about prelinking). In my case the error message looked like:

Cannot open self /usr/lib64/mybin or archive /usr/lib64/mybin.pkg