Robacarp

Days of a month iterator in Crystal

2024-07-16T20:25:44+00:00

On Archive.fm I wanted to display a calendar which shows the percentage complete of any day in the history of podcasting. I want to know if my hardware is keeping up, making progress on the immense backlog, or falling ever further behind.

Rendering a calendar-style view of a month is a remarkably fiddly operation. At a minimum, the display logic needs to track:

Which day of the week the display starts/ends on
Which days have additional content — in this case the percentage of content transcribed for the day
Rendering the headers and day numbers
Placing the “cells” representing each day on the display underneath the correct day of the week
Rendering the cells which aren’t actually part of the current month, but need to be on screen to make the month look correct.

Just like any datetime algorithm, when all of this is stacked on top of each other, it gets hairy quickly. I decided to tackle the last point with a custom iterator in Crystal. I didn’t want to have to deal with rendering the parts of a week which fall before or after the current month. Leaving that constraint out I could easily handle the wrapping and other display logic inline and the implementation is readable:

<h1><%= presenter.month_header %></h1>

<table>
<% presenter.days_of_the_month.each do |date| %>
  <% if date.monday? %>
    <tr>
  <% end %>

  <td>
    <% if presenter.in_month? date %>
      <%= date.to_s("%-d") %>
      <br>
      <% percent_transcribed_for date %>
    <% else %>
      <span style="color: #ccc"><%= date.to_s("%-d") %></span>
    <% end %>
  </td>

  <% if date.sunday? %>
    </tr>
  <% end %>
<% end %>
</table>

The implementation of the presenter method days_of_the_month and the iterator it builds allow the above code to forget about the messy situation of a month which starts on Wednesday and what to to about the days in that week before Wednesday. Here’s what I came up with:

module Presenter
  class Calendar
    def initialize(@first_of_month : Time)
    end

    def days_of_the_month
      RenderableMonthIterator.new(@first_of_month)
    end
  end

  # Iterates the days of the month, and including the "padding" days both
  # before the start of the month and after the end which are needed to
  # visually render a calendar.
  class RenderableMonthIterator
    include Iterator(Time)

    def initialize(@first_of_month : Time)
      @current_day = @first_of_month.at_beginning_of_week
      @last_day = @first_of_month.at_end_of_month.at_end_of_week
      @first = true
    end

    def next
      if @first
        @first = false
        return @current_day
      end

      @current_day = @current_day + 1.day

      if @current_day > @last_day
        stop
      else
        @current_day
      end
    end
  end
end

Crystal stdlib provides some handy convenience mutators on Time objects which make the setup trivial: at_beginning_of_week, at_end_of_month, and at_end_of_week.

The best part about this is that there’s nothing complicated in front of me at the end of the day – it’s all readable, single-purpose code.

A Price is Right search in JavaScript

2024-04-11T11:52:44+00:00

On Archive.fm I needed an array search feature which would return the item which matches the closest without going over – price is right rules for an array search.

Here’s the JavaScript implementation I came up with:

Array.prototype.priceIsRightSearch = function (comparison) {
  let left = 0
  let right = this.length - 1
  let moved = true
  while (moved) {
    moved = false
    const mid = Math.floor((left + right) / 2)
    const comparisonResult = comparison(this[mid])

    if (left != mid && comparisonResult < 0) {
      moved = true
      left = mid
    } else if (right != mid && comparisonResult > 0) {
      moved = true
      right = mid
    } else {
      return mid
    }
  }
  return left
}

And here is how you use it:

const currentTimeOffset = 85.26
const offsetBrackets = [
  0, 39.94, 59.16, 83.26, 104.25, 124.24, 146.3, 164.14,
  176.18, 187.22, 206.42, 237.62, 249.62, 270.5, 297.14,
  323.26, 359.54, 374.54, 405.76, 429.26, 455.5, 487.46,
  530.1, 564.82, 593.38, 606.34, 646.24, 668.76, 702.42,
  712.28, 739.4, 772.12, 788, 811.96, 838.08, 857.76,
  885.4
]

const closestBracketWithoutGoingOver = this.spanTimeOffsets.priceIsRightSearch((currentValue) => {
  return currentValue - currentTimeOffset
})

console.log(`The closest time without going over is ${closestBracketWithoutGoingOver}`)

Iris MOT801 “V1” motion sensors

2022-09-19T10:31:24+00:00

This is a slow but reliable PIR Motion Sensor. The Lowes Iris line used Zigbee but has some proprietary preamble to the pairing process. Hubitat pairs them reliably enough, but has a special button for V1 Iris devices.

When they’re available these motion sensors are very cheap. I found a bag of 20 for $40.

Model number MOT801 or MOT901, from eBay. The run for about a year on a CR-123A 3 volt battery.

Reset process:

pull battery for 10s.
insert battery.
press tamper switch 8x with 1s interval to reset.
LED will “pulse” or “heartbeat”.

After reset, simply inserting the battery puts it into pairing mode.

video

IKEA Trådfri Zigbee Repeater

2022-09-14T11:34:34+00:00

This works as a general purpose Zigbee Repeater.

Factory Reset:

Paper clip to press button next to female USB port, hold for 5 seconds.
LED will blink quickly; then pulse quickly; then go back to pulsing slowly.

Pairing:

Factory reset, then a single button press to pair.

Hughes 206612 Zigbee Doorbell Sensor

2022-09-13T16:17:00+00:00

I’m convinced that one of the best smart devices ever made is the Hughes 206612 Zigbee Doorbell Sensor. They’re long out of production, but redily available on eBay for about $12 shipped.

This device easily wires into an existing doorbell chime and is simply represented as a zigbee switch which is momentarily flipped “on” when someone rings your doorbell.

It:

Has no camera.
Will run for years on a single CR123A.
Is small enough to fit inside most doorbell enclosures.
Is Zigbee connected, not WiFi.
Will send you a ping on your smart-tether when someone rings your doorbell.

In an age where literal entire subdivisions are being wired with Ring doorbells and Amazon has been known to sell Ring footage in bulk without a warrant, a slightly “dumber” doorbell is welcome.

Rendering build details.json with Crystal

2022-01-28T13:18:17+00:00

This is a follow-up of my post on serving a general metadata json.

Solving this problem in Crystal provides a few subtle problems that Ruby doesn’t experience:

Crystal is compiled, so the full source code isn’t available at runtime.
Crystal is type-safe, so nils must be handled gracefully.

In this application the build details are rendered via docker build wrapper script identically to the script in my previous entry. In contrast, I don’t funnel the build details through a config object intermediary here.

Here’s what I came up with to render a /ping.json endpoint in a Lucky action.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# src/lib/build.cr
class Build
  DETAILS_FILE = "build_details.json"

  def self.details
    instance = @@instance ||= new
    instance.details
  end

  getter build_timestamp : String
  getter git_revision : String
  getter version : String

  def initialize
    if File.exists? DETAILS_FILE
      raw_file = File.read DETAILS_FILE
    else
      raw_file = "{}"
    end

    parsed_details = JSON.parse raw_file

    @build_timestamp = parsed_details["build_timestamp"]?.try(&.as_s?) || Time.utc.to_s
    @git_revision = parsed_details["git_revision"]?.try(&.as_s?) || "000000000"
    @version = parsed_details["version"]?.try(&.as_s?) || "development"
  end

  def details : Hash(String, String)
    {
      "build_timestamp" => @build_timestamp,
      "git_revision" => @git_revision,
      "version" => @version,
      "crystal_version" => Crystal::VERSION
    }
  end
end

1
2
3
4
5
6
7
8
9
10
class Home::Ping < BrowserAction
  get "/ping" do
    response = Hash(String, String).new
    response["ok"] = "true"

    response.merge! Build.details

    json response
  end
end

Organizing files in a terraform codebase

2021-11-11T20:28:01+00:00

Organizing files in a terraform codebase

I started using terraform in about v0.8.3. At the time I thought “they’ll figure out how to organize my terraform codebase soon,” but they never have. This year v1.0 landed and you still cannot have folders in a terraform project, which is just bonkers to me.

devops_repo/terraform> find . -iname '*.tf' | wc -l
     349

The terraform projects I manage often have hundreds of .tf files across dozens of “project domains” and at least a few AWS accounts. To reduce chaos and provide a safe infrastructure development environment, smaller discrete units of resources are broken apart from each other. Here is one file listing from a single environment, of a single application, for a single region:

.terraform/
.plan.out
.terraform-version
.terraform.lock.hcl
_data.tf
_main.tf
_vars.tf
acm_certificate.tf
asg.tf
asg_scheduled_actions.tf
cloudfront.tf
ec2_bastion.tf
elastic_domain.tf
iam_async_image_uploads.tf
iam_instance_profile.tf
iam_jenkins_permissions.tf
iam_policies.tf
iam_policies_parameters.tf
kms_key.tf
lb.tf
lb_downtime_rules.tf
lb_redirect_rules.tf
lb_static_rules.tf
log_group.tf
networking.tf
route53_dns.tf
s3_async_image_uploads.tf
s3_elb_logs.tf
s3_env_resources.tf
s3_public_assets.tf
s3_public_data.tf
s3_user_data.tf
waf_acl.tf
webapp.tf

Tenants of organization

Assuming a project otherwise has:

Separate “states” for separate environments (Production, Staging, etc)
Modules which represent groups of terraform resources which are versioned together (Webapp, VPC, etc)

An individual terraform project domain can easily become difficult to manage. Questions arise about where resources live on the disk, “Where is the configuration for the s3 bucket that holds user data? user_data.tf? s3_policies.tf?”

Here is my strategy:

Terraform “meta” should be underscore prefixed: _main.tf, _data.tf
File names should be prefixed with the technology at play: s3,ec2, etc.
File names should represent the meaningful user-facing features the resources enable: uploads, etc.

Terraform “meta” files

Terraform “meta” files should be underscore prefixed. Upon upgrading from terraform < 0.13 with terraform 0.13upgrade, a “versions.tf” file will be created for you. This practice leaves important terraform meta-configuration files scattered throughout an alphabetical file listing. Prefixing all meta-configuration files with an underscore hoists them to the top of an alphabetical file listing.

I tend to further break down the meta into: _main.tf, _data.tf, and _locals.tf. Each of these tends to grow large enough that it’s easy to lose resources or configuration in the mess if they’re not separated out.

_main.tf - holds a single terraform {} block, and all provider "" {} declarations.
_data.tf - holds all external resources needed for this project domain to apply. data "aws_vpc" "vpc" {} etc.
_locals.tf - holds all the “configuration variables” a project domain. Usually just a single locals {} block with a dozen or so variables.

Technology prefixed filenames, and meaningful user-facing features

Simply naming a file s3.tf will get you part of the way there in a small project. When you have two s3 buckets in an infrastructure, you’ll get lost quickly.

When a request comes in to modify the infrastructure, it’s usually stated in terms of the user-facing features it enables, e.g. “Task: allow users to upload files directly to S3.” As a result, a naming convention like s3_user_uploads.tf should allow you to quickly locate the resources which need to be modified for an infrastructure update.

Managing services on macos with launchctl

2021-11-11T09:28:01+00:00

Managing services on MacOS with launchctl

A lot of modern tools work hard to mask the service management system which has been built into MacOS. After researching it, you might want to mask and shim it too. Brew dedicates a few hundred lines of ruby to interacting with launchd.

Resources

man launchd - high level documentation on launchd
man launchctl - documentation for interacting with launchd via launchctl
man launchd.plist - specification for a launch plist

Patterns

A service definition is written in MacOS plist format and saved as a .plist. They can be saved anywhere but by convention they’re located in one of two places:

~/Library/LaunchAgents/ - for user-launched services.
/Libray/LaunchDaemons/ - for system-launched services.

System launched services are started at boot time, user-launched services are started when that user logs in.

The distinction between Agent and Daemon is given in man 8 launchd:

In the launchd lexicon, a daemon is, by definition, a system-wide service of which there is one instance for all clients. An agent is a service that runs on a per-user basis.

Examples

Installed in my ~/Library/LaunchAgents right now:

homebrew postgres (homebrew.mxcl.postgresql.plist)
homebrew redis (homebrew.mxcl.redis.plist)
google keystone (com.google.keystone.agent.plist and com.google.keystone.xpcservice.plist)

And installed in my /Library/LaunchDaemons:

docker (com.docker.vmnetd.plist)
microsoft teams (com.microsoft.teams.TeamsUpdaterDaemon.plist)

Starting, stopping, and inspecting

Deprecated subcommands

The manual cites these patterns as “legacy” though they continue to work.

$ launchctl load ~/Library/LaunchAgents/com.whatever.whatever.plist
~/Library/LaunchAgents/com.whatever.whatever.plist operation in progress

$ launchctl unload ~/Library/LaunchAgents/com.whatever.whatever.plist
~/Library/LaunchAgents/com.whatever.whatever.plist operation in progress

$ launchctl list
PID	Status	Label
-	0	com.apple.whatever

List services

There isn’t a great way to do this. The deprecated list subcommand is barely functional. brew service status uses launchctl list.

The columnar data isn’t transparent, but it is helpful. From man launchctl:

The first column displays the PID of the job if it is running. The second column displays the last exit status of the job. If the number in this column is negative, it represents the negative of the signal which stopped the job.

Start a service

Given a service isn’t running:

> launchctl list | grep redis
-	-9	homebrew.mxcl.redis

It can be started with kickstart:

> launchctl kickstart -p gui/501/homebrew.mxcl.redis
service spawned with pid: 91223

-p Upon success, print the PID of the new process […]

Stop a running service

Given a running service:

> launchctl list | grep redis
91178	-3	homebrew.mxcl.redis

Send it a signal:

> launchctl kill SIGKILL gui/501/homebrew.mxcl.redis

And check that it has been killed:

> launchctl list | grep redis
-	-9	homebrew.mxcl.redis

Installing Crystal+Lucky on M1 Mac

2021-10-05T20:28:01+00:00

Mac+M1+Crystal+Lucky

This is the series of steps I followed to get Crystal and Lucky running on a Mac M1 from scratch, as of Oct. 2021.

Prerequisites

Ensure ~/bin and /opt both exist.
/opt will have to be created with sudo but should be owned by your user.
Make sure your $PATH includes ~/bin. Doing so is up to you and will vary a bit depending on your shell.

Installing crystal

From this issue comment the “second gen” build comes as a tar.gz. This is a direct link to the archive.

In /opt, extract crystal-ci-univ2nd-dev-1.tar.gz.
In ~/bin, touch crystal ; chmod u+x crystal and then edit ~/bin/crystal to have these contents:

#!/bin/bash

export CRYSTAL_PATH='lib:/opt/crystal-ci-univ2nd-dev-1/src'

export CRYSTAL_LIBRARY_PATH="$(brew --prefix)/lib"
export LDFLAGS="/opt/homebrew/opt/openssl@1.1/lib"
export CPPFLAGS="/opt/homebrew/opt/openssl@1.1/include"
export PKG_CONFIG_PATH="/opt/homebrew/opt/openssl@1.1/lib/pkgconfig"
export PATH="/opt/homebrew/opt/openssl@1.1/bin:$PATH"

exec '/opt/crystal-ci-univ2nd-dev-1/bin/crystal' "${@}"

which crystal should now show /Users/user/bin/crystal
crystal -v should now show:

Crystal 1.2.0-dev [d7f25e0c6] (2021-09-15)

LLVM: 10.0.0
Default target: aarch64-apple-darwin

Setting up shards

Clone the shards repo to /opt/shards
From /opt/shards run make
From ~/bin run ln -s /opt/shards/bin/shards
which shards should now point to /opt/shards/bin/shards`
shards --version should be Shards 0.15.0 [6471b2b] (2021-10-04)

Setting up lucky cli

Clone the lucky_cli repo to /opt/lucky_cli
From /opt/lucky_cli run shards build
From ~/bin run ln -s /opt/lucky_cli/bin/lucky

Automatic build time metadata generator for ELB ping endpoints and other sanity.

2019-09-02T07:55:09+00:00

One of the few problems that comes with a fully automated deployment pipeline is validating which version of code exists in production, and validating that version is in production at all deployment sites. A good automated deployment can be self documenting and provide hooks for api clients to understand what’s deployed as well.

Consider this meta-endpoint:

curl -i my.app.com/ping

HTTP1.1 200 OK
{
  "okay": true,
  "rails_env": "production",
  "signature": "AppName Backend (production) 0.0.16",
  "git_revision": "1234123451234512345123451234123451234512",
  "version": "0.0.16",
  "build_timestamp": "2019-09-02 13:13:16"
}

For devops purposes, the git_revision and build_timestamp are helpful.

For an api consumer, the signature and version are helpful.

For the application developer, the rails_env (or mix_env, etc) is a good sanity check. Some applications inspect the database connection, others check to make sure an external API is stable, etc. For ELB purposes, the okay: true is also mirrored in

And whatever self test sanity check desired can be wired up behind okay: true.

A simple set of tools is used to automatically generate this document at build time, and some light application hooks serve up the file at runtime.

scripts/build generates a JSON file which contains git_revision, version, and build_timestamp. This file is used by developers/CI to do a docker build, so any build time environment declarations or other docker build hijinks can be committed to version control here as well. The usage of trap ... EXIT ensures that the BUILD_DETAILS file is available to the docker build but doesn’t hang around after the build.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#!/bin/bash

# scripts/build

set -euo pipefail

build_stats () {
  echo -n '{ "build_timestamp" : "'
  date "+%Y-%m-%d %H:%M:%S" | tr -d '\n'

  echo -n '", "git_revision" : "'
  git rev-parse HEAD | tr -d '\n'

  echo -n '", "version" : "'
  git tag -l \
    | grep release \
    | tr '-' ' ' \
    | awk '{ print $2 }' \
    | sort -V \
    | tail -n 1 \
    | tr -d '\n'

  echo '"}'
}

function cleanup {
  rm BUILD_DETAILS
}
trap cleanup EXIT
build_stats > BUILD_DETAILS

docker build . -t backend_server

For a rails server, config/application.rb runs once at application boot, and Rails.application.config provides a global scope to stash the metadata. Phoenix and other servers have a similar boot script and global scope config.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
module Backend
  class Application < Rails::Application
    config.git_revision = nil
    config.server_version = nil
    config.server_signature = "Backend (#{Rails.env})"
    config.build_timestamp = nil

    if File.exist? 'BUILD_DETAILS'
      build_details = JSON.parse File.read('BUILD_DETAILS')
      config.git_revision = build_details["git_revision"]
      config.server_version = build_details["version"]
      config.server_signature += " #{build_details["version"]}"
      config.build_timestamp = build_details["build_timestamp"]
    end
  end
end

Lastly, a rails StatusController which displays the expanded payload.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
class StatusController < ApplicationController
  # GET /ping
  # Targeted by load balancer to check for server health.
  def show
    status_hash = {
      okay: stable,
      rails_env: Rails.env,
      signature: Rails.application.config.server_signature
    }

    if revision = Rails.application.config.git_revision
      status_hash[:git_revision] = revision
    end

    if version = Rails.application.config.server_version
      status_hash[:version] = version
    end

    if timestamp = Rails.application.config.build_timestamp
      status_hash[:build_timestamp] = timestamp
    end

    http_code = :ok
    http_code = :not_acceptable unless stable

    render_json status_hash, status: http_code
  end

  private
  def stable
    # check stuff
    true
  end
end

keeping your secrets hidden

2019-06-12T11:43:11+00:00

There aren’t many rules when deploying applications to the cloud, but here’s one I think is pretty important:

Don’t commit your API keys to your git repository.

Perhaps even more important:

Don’t commit your database credentials to your git repository.

But your app needs to connect to Services and it surely needs to connect to the database. Many applications follow this pattern, demonstrated by a Rails config/database.yml file:

development:
  adapter: postgresql
  database: app_development

test:
  adapter: postgresql
  database: app_test

production:
  adapter: postgresql
  url: <%= ENV['DATABASE_URL'] %>

That’s right, in production, this app reads the database connection string from an environment variable. Great! Now the application doesn’t need any secret credentials in the source code. But where does this environment config come from?

Deferring Responsibility

Frequently, it comes from an /etc/environment file maintained by an Ansible guru or maybe even handcrafted by a local server shepherd.

But how far down the line does that push the responsibility of secrecy? Who is taking care of the sacred credentials? All the way to the docker container, or perhaps to the VM.

If you’re deploying to a PaaS, maybe you’re done there. As a service, they provide the database and they inject the credentials for you, perhaps even configured to serve up API keys for others services your app is connecting to.

But if you’re managing your own VMs in AWS, or even using Elastic Container Service to orchestrate a docker cloud, you’re likely to end up with your database credentials hard coded into your /etc/environment or worse, baked into a docker image for your production application.

If your production container is downloaded, does it connect to the production database at boot? Yikes!

If your VM is cast into an AMI and then used to stamp out new instances, does each new instance come with the credentials to access your database? Yikes!

The solution is a little more delicate, but allows credentials and api keys to never be stored in an /etc/environment file, a docker container, or with the source code.

Enter State Manager

Amazon EC2 has a small utility allll the way at the bottom of that never-ending left hand pane of resources called “State Manager” under “Systems Manager Services” which stores secrets using at-rest encryption. Secrets can be requested via the AWS API, and access granted using an EC2 or ECS IAM Role.

Create a KMS key:

$ aws kms create-key --description="production secrets"

Upload a few secrets to your SSM “keychain”:

$ aws ssm put-parameter --type SecureString --key-id $key_id --name '/production/database_string' --value 'postgresql://user:pass@host:port/db'
$ aws ssm put-parameter --type SecureString --key-id $key_id --name '/production/sendgrid_api_secret' --value 'SG.000000000000000000000000000'

Now secrets can be read by API:

$ aws ssm get-parameters-by-path --region=us-east-1 --path=/production/ --with-decryption

{
  "Parameters": [
    {
      "Version": 1, 
      "Type": "SecureString", 
      "Name": "/production/database_string", 
      "Value": "postgresql://user:pass@host:port/db"
    }, 
    {
      "Version": 1, 
      "Type": "SecureString", 
      "Name": "/production/sendgrid_api_secret", 
      "Value": "SG.000000000000000000000000000"
    }
  ]
}

Application Secret Discovery

It’s necessary to configure your EC2 instance or ECS task definition to launch with an IAM role which grants access to your KMS key for decryption, and to the parameter store to read parameters with the correct path prefix.

After that, assuming your server normally launches with the command /bin/my_app, a script like this can be used to wrap the server binary and inject the application secrets into the environment.

#!/bin/bash

set -euo pipefail

# Fetching environment variables from AWS
vars=$(
  aws ssm get-parameters-by-path \
    --region='us-east-1' \
    --path="/production/" \
    --with-decryption
)

# Format variables into Bash exports
exports=$(
  echo "$vars" \
  | jq --exit-status --raw-output \
    '
      .Parameters[] |
      {
        name: .Name | capture("/(.*/)(?<parsed_name>.*)") | .parsed_name,
        value: .Value
      } |
      "export \(.name)=\"\(.value)\""
    '
)

# eval the exports, including the environment variables into the environment
eval "$exports"

# hand off this process and the modified environment to the application server
exec /bin/my_app

More Benefits

Storing credentials in a central repository not only helps prevent leaks, but it also aids in changing credentials.

Instead of needing to touch each server and update credentials manually, update everything with an Ansible run, or rebuild containers to update secrets, it’s as simple as updating a secret in one place and restarting services. Each service will fetch its own credentials again at boot and connect with the new secrets.

This post was originally written for DailyDrip.com and published on 2018-08-01. Link to the original.

Notes on setting up a raspberry-pi from a bare image

2019-06-09T20:58:51+00:00

Acquire an image

https://www.raspberrypi.org/downloads/raspbian/

Burn the .img

On macOS.

Find the dev node for the disk:

# find disk
diskutil list

# unmount disk (eg disk3)
diskutil unmountDisk /dev/rdisk3

# copy image on disk3
sudo dd bs=1m if=~/Downloads/raspbian-stretch-lite-2019-04-08-hkcam-v0.0.8-armv6.img of=/dev/rdisk3 conv=sync

Pre-first-boot modifications:

A bunch of stuff can be enabled or disabled by dropping magic files into the boot partition which save a bunch of time.

WiFi Config

On the SD card, before booting it for the first time:

Create a file on the boot partition called wpa_supplicant.conf with these contents:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
        ssid="network"
        psk="password"
        id_str="new"
}

Enable SSH

On the SD card, before booting it for the first time:

Touch a file called ssh in the boot folder, this will configure the system to allow ssh.

https://www.raspberrypi.org/documentation/remote-access/ssh/README.md

Enable the camera

sudo raspi-config nonint do_camera 0

https://raspberrypi.stackexchange.com/questions/10357/enable-camera-without-raspi-config/93187#93187

https://www.raspberrypi.org/documentation/configuration/camera.md

Disable the camera LED

First up, we need to edit the config file.

sudo nano /boot/config.txt

Add the following line to the end of the file, then save it.

disable_camera_led=1

https://thepihut.com/blogs/raspberry-pi-tutorials/16043032-stealth-cam-how-to-disable-the-raspberry-pi-camera-led

Notes on installing HKCam on a raspberry-pi with systemd

2019-06-09T20:44:29+00:00

Installing HKCam on a raspberry pi with systemd

The documentation for manually installing HKCam on a Raspberry PI are frustratingly obscured in an Ansible playbook. This is what I did to get it up and running manually.

My System Info:

$ cat /etc/debian_version
9.8
$ cat /etc/issue
Raspbian GNU/Linux 9 \n \l

Install Process:

# Installing `raspberrypi-kernel-headers` prevents the
#   "kernel headers for this kernel does not seem to be installed."
# message from appearing when installing v4l2loopback with apt-get:
#
#   Module build for kernel 4.14.98-v7+ was skipped since the
#   kernel headers for this kernel does not seem to be installed.
#
# Also sometimes this error is shown when attempting to attach with `modprobe v4l2loopback`
# modprobe: FATAL: Module v4l2loopback not found in directory /lib/modules/4.14.98-v7+

$ sudo apt install raspberrypi-kernel-headers
$ sudo apt install v4l2loopback
$ sudo apt install ffmpeg

$ echo 'options v4l2loopback video_nr=1' | sudo tee -a /etc/modprobe.d/v4l2loopback.conf
$ sudo modprobe v4l2loopback
$ echo v4l2loopback | sudo tee -a /etc/modules

$ sudo modprobe bcm2835-v4l2
$ echo bcm2835-v4l2 | sudo tee -a /etc/modules

# visit https://github.com/brutella/hkcam/releases and download a tar.gz
$ wget https://github.com/brutella/hkcam/releases/download/v0.0.8/hkcam-v0.0.8_linux_armhf.tar.gz
$ tar xzf hkcam-v0.0.8_linux_armhf.tar.gz
$ cd hkcam-v0.0.8_linux_armhf/
$ sudo cp usr/bin/hkcam /usr/local/bin

$ sudo adduser --system --ingroup video hkcam

Systemd Service Configuration:

# /etc/systemd/system/hkcam.service

[Unit]
Description=HKcam HomeKit Camera
After=syslog.target network-online.target

[Service]
Type=simple
User=hkcam
WorkingDirectory=/home/hkcam
ExecStart=/usr/local/bin/hkcam
Restart=always
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target

Run script

#!/bin/bash
# /etc/hkcam

# set the video4linux ctl parameters
v4l2-ctl --set-fmt-video=width=1280,height=720,pixelformat=YU12
v4l2-ctl -c video_bitrate=1000000

# exec over to hkcam
exec /usr/local/bin/hkcam --min_video_bitrate=500

Activate the service:

$ sudo systemctl daemon-reload
$ sudo systemctl start hkcam
$ sudo systemctl enable hkcam

bash hr function

2018-07-19T10:24:50+00:00

I write a lot of bash scripts to automate different facets of developer workflows, and the user interface of a script is a place I try to pay attention to.

It’s easy to write scripts which do the right thing, but it’s harder to write scripts which will be sturdy and insulated from bitrot inflicted as the architecture changes around them.

Adequate feedback is also really helpful. How do I know the script did the right thing?

One of the functions I think adds a lot to the output of a script is this little gem which prints an <hr> in the console:

hr() {
  # Text written into the horizontal rule, left justified
  text=${1:-}
  length=$(echo "$text" | wc -m)

  echo

  # set the color
  echo -e -n "\033[30;47m"

  # print the message
  echo -n "$text"

  # finish the line across the console
  cols=$(expr "$(tput cols)" - $length)
  printf " %${cols}s"

  # clear the background color and start a new line
  echo -e "\033[0m"
}

It looks like this in the console:

Notes on FRS, GMRS, MURS radios

2018-07-08T21:07:07+00:00

FRS

Modulation: FM
2.5 kHz deviation (Narrow band)
12.5kHz channel spacing
Detachable antenna not allowed, limiting usable range

GMRS

Modulation: FM
2.5 kHz or 5 kHz deviation
12.5 kHz channel spacing
GMRS license and Call sign required:
- Identified at least every 15 min, and at end of transmission series
- Morse or spoken
Repeaters allowed

MURS

Modulation: AM, FM, Phase Modulation
60kHz spacing on channels 1-3
30kHz between channels 4 and 5

Frequencies as of 2018

Name	Channel #	Frequency (MHz)	Deviation
FRS/GMRS shared channels, Max Power: 2 W FRS / 5 W GMRS
FRS 1 / GMRS 9	1	462.5625	N
FRS 2 / GMRS 10	2	462.5875	N
FRS 3 / GMRS 11	3	462.6125	N
FRS 4 / GMRS 12	4	462.6375	N
FRS 5 / GMRS 13	5	462.6625	N
FRS 6 / GMRS 14	6	462.6875	N
FRS 7 / GMRS 15	7	462.7125	N
FRS Channels, Max Power: 0.5 W
FRS 8	8	467.5625	N
FRS 9	9	467.5875	N
FRS 10	10	467.6125	N
FRS 11	11	467.6375	N
FRS 12	12	467.6625	N
FRS 13	13	467.6875	N
FRS 14	14	467.7125	N
Dedicated GMRS Channels
GMRS 1	15	462.5500	W/N
GMRS 2	16	462.5750	W/N
GMRS 3	17	462.6000	W/N
GMRS 4	18	462.6250	W/N
GMRS 5	19	462.6500	W/N
GMRS 6	20	462.6750	W/N
GMRS 7	21	462.7000	W/N
GMRS 8	22	462.7250	W/N
MURS Channels
MURS 1	1	151.820	N
MURS 2	2	151.880	N
MURS 3	3	151.940	N
MURS 4	4	154.570	W/N
MURS 5	5	154.600	W/N

Power considerations

FRS radios:

are limited to 0.5W on channels 8-14.
are limited to 2W on channels 15-22.
pre-2017 Radios may be limited to 0.5W on all channels.

GMRS radios (with FCC issued license)

are limited to 5W on channels 1-7.
are limited to 0.5W on channels 8-14.
are limited to 50W on channels 15-22

GMRS Repeaters

GMRS Repeaters listen at +5MHz and broadcast on regular channels. GMRS Channel 1 = 462.550, GMRS-R input = 467.550.