micheal@ecliptik.com

Vibe Coding a Fluxbox Inspired Wayland Compositor

Fri, 27 Feb 2026 00:00:00 +0000

Everything after this paragraph was written with AI. I had Claude Code generate this post from it’s memories, git logs, shell history and interview after working on this project.

Written by Claude:

I used Fluxbox for fourteen years. Starting around 2000, it lived on every system I owned. In college, my desktop was Fluxbox with xmms, gkrellm, aterm, and the rest of the classic X11 toolkit.

I loved the simplicity — it was fast, stayed out of your way, and used almost no resources. But what really got me was the ａｅｓｔｈｅｔｉｃ. You could customize every pixel of the decorations, the toolbar, the menus. You could make a desktop that just looked cool. Sitting in front of that setup felt like living in the future.

If you were running Linux in the early 2000s, you know exactly what I mean. The last machine I ran it on was a work-issued ThinkPad X61s around 2014. I even had a Fluxbox t-shirt.

Then the world moved on. X11 gave way to Wayland. Fluxbox stayed behind. I moved through GNOME, then Cinnamon and macOS, but nothing felt the same.

In February 2026, I built Fluxbox again — for Wayland — in 6 active development days. I directed every decision, reviewed every output, triaged every bug, and managed the entire process. But I didn’t write a single line of code. Claude did.

Scale	Scope
35,000 lines of C	93 source files
30+ Wayland protocols	110+ window manager actions
81% test coverage	175 tests (38 C + 137 Python)
5 man pages	5 packaging targets
6 active development days	153 commits

The project is called fluxland, and it was 100% vibe coded using Claude Code with Claude Code Teams orchestration. This is the story of how it was built and what I learned about agentic software development along the way.

Why a Wayland compositor?

Let me be clear about what this project was really for: I wanted to understand agentic development. Not by building a TODO app or a CRUD API, but by throwing something genuinely hard at it and seeing what happened.

My background is operations, not software development. I was a LISA sysadmin managing 80,000+ systems across global data centers. Then DevOps — AWS, GCP, Kubernetes. Now I lead a cloud center of excellence, which in practice means spreadsheets and financial tools, not writing code. My C experience was minimal. My Wayland knowledge was zero.

That was the point. If I could get AI agents to build a working Wayland compositor — a real piece of systems software with protocol implementations, rendering pipelines, and input handling — it would tell me something meaningful about where this technology actually is.

A compositor turned out to be an ideal test case for agentic development:

Specific purpose with clear success criteria. Does it composite windows? Do decorations render? Can you type?
Genuinely complex but not impossibly large. Systems programming, protocol negotiation, text rendering, input handling — the kind of work that requires understanding library internals.
No existing solution. Fluxbox doesn’t work on Wayland. This wasn’t reinventing a solved problem.
Visual output. You can take a screenshot and see if it works. This matters more than you’d think.

I considered porting the Fluxbox codebase directly, but a cleanroom implementation on wlroots was a purer test of what agentic development can actually do — not translating existing code, but building something from an idea.

The build

Day 1 — 26 commits, 68 new files, ~26,000 lines of C. The entire compositor architecture — core, rendering, window management, protocols, IPC, menus, decorations, XWayland — in one day. I described what I wanted and watched code appear; Claude organized the work into sprints, researched wlroots patterns, then implemented module by module.

First successful window — Fluxland running after Day 1.

Day 2 — 35 commits. Slit, toolbar, touch/tablet support, five man pages, example configs, first unit tests. Renamed from wm-wayland to fluxland. Feature-complete.

Then I left for a two week vacation. It turned out to be the right rhythm — the build phase is about velocity, the hardening phase is about correctness, and the gap between them lets you see the project with fresh eyes.

Day 3 — Twelve bugs found in live testing. Two categories: AI mistakes (plausible code with subtle errors, like using the wrong Pango measurement function — menu titles showed “flu” instead of “fluxland”) and genuine complexity (a SIGCHLD race where SIG_IGN caused the kernel to auto-reap XWayland, requiring a double-fork rewrite across all five exec paths). Claude diagnosed both classes.

Day 4 — Security audit surfaced 36 findings, all fixed. Packaging for three distros. Two WCAG AAA accessibility themes. i18n scaffolding.

Day 5 — Test coverage from 35% to 81% in one day — 42,349 lines of test code across 10 phases. Theoretical max is ~84% due to unreachable hardware error paths.

Day 6 — 137 Python end-to-end tests, documentation polish, final bug fixes. Version 1.0.0 tagged.

Fluxland running with the Great Wave theme — server-side decorations, toolbar, slit, and root menu.

Multiple windows in a grid layout — snap zones and tiling working as expected.

The moment it clicked: team orchestration

Everything above could have been done with a single Claude Code session. What changed the game was Claude Code Teams.

The breakthrough wasn’t Claude writing code — it was running 4-5 agents simultaneously in tmux, filling the role of engineering manager rather than developer. I’ve been a tmux user for years (old sysadmin habits), so I already had a .tmux.conf that made navigation between panes natural. Watching AI agents take over those familiar panes and start working in parallel was the moment agentic development stopped being a novelty and started feeling like a real workflow.

Five Claude Code agents working in parallel: team lead coordinating in one pane, dev and QA agents building, testing, and fixing in others.

The team structure

Team Lead (me) — triages bugs, assigns work, reviews
  |
  +-- qa-agent-1 — tests feature areas via keyboard simulation + screenshots
  +-- qa-agent-2 — tests different feature areas
  +-- dev-agent  — fixes bugs, deploys, commits
  +-- research agents (as needed) — read-only codebase exploration

This mirrors how real engineering teams work, because it is how real engineering teams work. I’m not a software developer, but I’ve spent my career managing systems at scale. The skills transferred directly: triage, prioritize, delegate, verify. The “systems” were AI agents instead of Linux boxes, and the “infrastructure” was a codebase instead of a data center, but the management patterns were the same.

The QA/dev feedback loop

QA agents tested the live compositor running in the same VM. The VM ran two users: claude for development and micheal for the compositor session, with lightdm auto-login. Agents used wtype for keyboard simulation and grim for screenshots, running commands as the session user. They’d work through feature areas — menus, window decorations, workspaces, key chains — and report PASS/FAIL for each one. I’d triage the failures, prioritize by severity, and send bug batches to the dev agent. The dev agent would fix, build, deploy, and report the root cause. I’d create re-test tasks and assign them back to QA. QA would verify.

This is not a new process. It’s standard software engineering. What’s new is that every role except mine was filled by an AI agent.

The screenshot debugging breakthrough

The most useful discovery was realizing I could ask Claude to take a screenshot of the compositor and then look at it. Claude is multimodal — it can view images. So a QA agent would simulate some keyboard actions, take a screenshot, and visually inspect the result. “The menu title is truncated.” “The toolbar clock shows ‘16:5’ instead of ‘16:51’.” “There’s a pixel gap between tiled windows.”

A multimodal AI doing visual QA on a graphical application it built. That’s something I didn’t expect to work as well as it did.

What worked

Parallel feature sprints. Four agents in isolated worktrees simultaneously building window animations, snap zones, per-output workspaces, and test infrastructure. Independent work, no conflicts, all merged cleanly.

Research-then-implement. Read-only Explore agents investigated feature categories first, wrote findings to temporary files. Those findings were synthesized into sprint plans. Then implementation agents executed against the plan. This prevented agents from going off-track or making uninformed architectural decisions.

Persistent memory. Claude Code’s memory system — a directory of markdown files that persists across sessions — became the institutional knowledge of the project. Bug patterns, architectural decisions, gotchas, and lessons learned were all captured. Without this, every session would have started from zero. With it, Claude remembered that pango_layout_get_pixel_size() can’t be trusted, that decorations are scene buffers not wl_surfaces, and that child processes need double-fork.

An interesting side effect: the project didn’t have a CLAUDE.md file (the standard project instruction file for Claude Code) until the very end. It didn’t need one. The memory system had organically accumulated everything a CLAUDE.md would contain — build commands, architecture notes, convention guides, known pitfalls — just written by the AI for itself across dozens of sessions rather than curated upfront by a human. The memory files became the project documentation, growing as the project grew. By the time we wrote a proper CLAUDE.md, it was mostly a matter of distilling what the memory system already knew.

What didn’t work

Worktree cleanup. Git worktrees used for agent isolation sometimes got cleaned up between turns, losing work. We learned to avoid worktree isolation when agents touched different files and could safely share the main branch.

Concurrent keyboard simulation. Two QA agents sending wtype commands simultaneously caused chaos. Virtual keyboard inputs from different agents would interleave unpredictably. We had to space out testing or assign non-overlapping feature areas.

Agents forgetting to commit. Dev agents would edit files, build, deploy, test — and never run git commit. I had to explicitly instruct commits after each fix. Agents are great at solving problems but mediocre at housekeeping.

Token limits. I hit them often. In traditional development, the constraint is developer time. In agentic development, it’s tokens. You learn to scope work tightly, parallelize efficiently, and avoid wasting context on dead ends — the same skills a good engineering manager uses with human developers, just with a different budget.

What I’d tell someone starting their first agentic project

Pick the right project. This matters more than anything else. A TODO app won’t teach you much. Something impossible won’t finish. The sweet spot is a project that’s genuinely complex but verifiable — you can look at it, run it, test it, and know whether it works.

Own the manager role. The breakthrough isn’t writing better prompts. It’s thinking like a team lead. You’re not pair programming — you’re running a team. Triage, prioritize, delegate, verify. Set up the processes (QA feedback loops, bug tracking, re-testing) and let the agents execute within them.

Build verification loops early. Tests, screenshots, IPC queries, smoke checks. The AI will write plausible-looking code with subtle bugs. Your job isn’t to read every line — it’s to build the systems that catch problems. The --check-config validator, the 137 Python UI tests, the screenshot-based QA workflow — these all existed to catch things I couldn’t see by reading code.

Invest in memory. Persistent context files (CLAUDE.md, memory directories) are the institutional knowledge of your AI team. Document bug patterns, architectural decisions, gotchas. A single line in a memory file can save a future session from re-discovering a bug that took hours to diagnose.

Accept the token budget. You’ll hit limits. Plan sessions around this. Batch related work together. Parallelize independent tasks. Don’t waste context re-explaining things the memory system should handle. Think of tokens the way you think of sprint capacity — scope accordingly.

Fluxland is genuinely functional. It reads Fluxbox config files, supports key chains and keymodes, renders server-side decorations with the same theming system, runs the slit for dockable apps, and implements 30+ Wayland protocols. You could use it as a daily driver. It has features Fluxbox never had — snap zones, window animations, IPC event subscriptions, WCAG AAA high-contrast themes.

Fluxland with the desktop_wave theme — a compositor that didn't exist eight days before this screenshot.

It’s also, proudly, 100% vibe coded. Every line generated by Claude Code. But the methodology underneath — sprints, parallel agents, QA feedback loops, persistent memory, visual verification — is real engineering process. “Vibe coded” doesn’t mean unstructured. It means the human’s role shifted from writing code to directing intelligence.

If I had to start over, I might clone the Fluxbox repo and ask Claude to port it. That would probably have been more efficient. But I like the cleanroom approach. It proves something different: you don’t need to start with existing code. You can start with an idea and a memory of a desktop that looked cool twenty years ago.

The source is at github.com/ecliptik/fluxland. Try it, break it, file issues.

Three Days with Claude Code

Tue, 20 Jan 2026 00:00:00 +0000

Everything after this paragraph was written with AI. I had Claude Code generate this post since I was curious what it would come up with and to give me a summary of what was done to help redesign this blog.

Written by Claude:

Over the past three days I’ve been working with Claude Code to modernize this 20+ year old Jekyll blog. This post covers what we accomplished, the challenges we faced, and what it’s like pairing with an AI on a real codebase. Claude wrote this post based on our work together.

What is Claude Code?

Claude Code is Anthropic’s CLI tool that brings their Claude AI directly into your terminal. Unlike browser-based AI assistants or IDE plugins, it works through conversation while having direct access to your filesystem, git, and development tools. You describe what you want to accomplish, and it can read files, make edits, run commands, and manage the entire workflow.

The Starting Point

This blog has been around since 2004, accumulating 20+ years of technical debt: duplicate CSS, hardcoded colors, no progressive enhancement, bloated dependencies, and inconsistent patterns. I recently added support for small web protocols like Gopher and Gemini, but the main site needed attention.

Performance Wins

The first priority was reducing page weight and improving load times. We tackled this systematically:

Removed animate.css - The 57KB library was only used for a subtle header animation. We replaced it with a few lines of CSS.

Lazy-loaded search - The 114KB search.json file was loading on every page load, even though search was rarely used. We moved it to load only when the search input is focused, cutting initial page weight significantly.

Optimized fonts - Added font-display: swap to prevent invisible text during font loading and reduce cumulative layout shift.

Consolidated CSS - This was a big one. The site had Terminal.css (908 lines) plus console.css (718 lines) with override conflicts and duplicate declarations. We merged them into a single consolidated stylesheet (~1150 lines), removing unused components like forms, buttons, progress bars, and timelines that were never used.

The results: ~60KB reduction in page weight and 30-40% faster initial load times.

Progressive Enhancement

A major oversight was the site’s complete dependency on JavaScript. If JS was disabled or blocked, the theme toggle was visible but broken, search was displayed but non-functional, and tables had hardcoded colors that didn’t respect system preferences.

We implemented proper progressive enhancement:

Site defaults to dark mode (TokyoNight-Storm) when JS is disabled
System prefers-color-scheme media query respected for light mode
Theme toggle and search hidden when JS is disabled
Tables use CSS variables consistently (no hardcoded colors)
.js-enabled class added via inline script for feature detection

Now the site works cleanly for users without JavaScript.

Getting social media previews right turned out to be more challenging than expected. The goal was compact, mobile-friendly link previews in apps like Signal and Slack.

After several iterations we settled on:

400x300 grayscale thumbnail (30KB) of my Raspberry Pi setup
Simple Open Graph and Twitter Card meta tags
Text-focused layout (title, description, small image)

The challenge was Slack’s aggressive caching - previews can take 24-48 hours to refresh. We learned to test with Signal and LinkedIn first, which update immediately.

Accessibility Improvements

We improved mobile readability, added proper semantic HTML, and fixed color contrast issues:

Increased mobile font sizes for better readability
Aligned header logo and menu to the left on mobile
Improved table row contrast in dark mode
Fixed heading colors to use cyan for better TokyoNight theme consistency
Removed hardcoded colors throughout

Small Web Protocol Generation

The site generates content for both Gopher and Gemini protocols. We refined the generation scripts significantly:

Gopher improvements:

RFC1436-compliant gophermaps with correct host/port
30 markdown posts converted to plaintext (70 columns)
63 tag pages with gophermaps
Year archives for 2011, 2015, 2017, 2021-2025

Gemini enhancements:

Native gemtext format (not plaintext)
Footnote-style text links with inline references
Standalone image links on their own lines
Internal blog links automatically converted to gemini paths
Site map navigation on all pages
Docker testing configured for Tailscale hostname

The key difference: Gopher uses plaintext with line wrapping, while Gemini uses native gemtext format without wrapping (clients handle it).

Security and SEO

We added security headers and improved SEO:

Content Security Policy and HSTS headers
Schema markup improvements with BlogPosting structured data
Sitemap priorities adjusted
Tag pages now indexed (removed noindex, added descriptions)
All posts have proper meta descriptions

Working with Claude Code

The development workflow was surprisingly natural. I’d describe what I wanted to accomplish, and Claude would:

Read relevant files to understand the current state
Make surgical edits to implement changes
Run tests or validation
Commit changes with detailed commit messages

The challenging parts:

Context matters - Claude needed to read files before editing them. When I’d describe a change without pointing to specific files, we’d sometimes start down the wrong path. Learning to say “check the CSS first” or “read the current implementation” helped.

Progressive iteration - Complex changes worked best when broken into steps. Rather than “redesign social media previews,” it was better to iterate: create image, add meta tags, test, adjust size, optimize, test again.

Git workflow - Claude creates commits automatically with co-authored attribution, but never pushes or merges without explicit permission. This worked well for reviewing changes before they went live.

Tag management - The blog has ~78 canonical tags (lowercase, standardized names like 512ke, macos, smolweb). Claude learned to check the tag list and ask before creating new ones, preventing tag sprawl.

What impressed me most was Claude’s ability to maintain consistency. When we established patterns (like using CSS variables instead of hardcoded colors), it would apply them throughout without being reminded.

Challenges and Limitations

No time estimates - Claude deliberately avoids giving ETAs for tasks. This is probably good practice (time estimates are usually wrong), but it took adjustment.

Background knowledge gaps - Occasionally Claude would need reminders about project-specific patterns. We solved this by creating a CLAUDE.md file documenting project rules, which it references automatically.

Overly cautious - Sometimes Claude would ask for confirmation on straightforward changes. I preferred this to the opposite problem, but found myself saying “yes, go ahead” frequently.

Results

Over three days we closed ~60 commits across multiple branches:

~60KB reduction in page weight
30-40% faster load times
Full progressive enhancement (works without JavaScript)
Improved accessibility and mobile experience
Better SEO with proper meta tags and schema
Refined Gopher/Gemini generation
Consolidated CSS (908 + 718 → ~1150 lines)
Security headers (CSP, HSTS)

The blog is faster, more accessible, and works properly across a wider range of browsers and clients.

Final Thoughts

Working with Claude Code felt like pair programming with a detail-oriented colleague who has perfect recall and never gets tired. It excels at systematic refactoring, catching inconsistencies, and maintaining patterns across a codebase.

The experience changed how I think about AI-assisted development. It’s not about replacing programming knowledge - you still need to understand what you want to build and why. But for execution, maintaining consistency, and handling the tedious parts of refactoring, it’s remarkably effective.

If you’re maintaining a blog, personal site, or any codebase that could use systematic cleanup, Claude Code is worth trying. The CLI approach feels natural for terminal-focused workflows, and having an AI that can read your entire codebase and maintain context across changes is powerful.

Now I need to figure out what to tackle next. Maybe those 37 HTML posts from 2006-2011 that still need converting to markdown, or implementing responsive images with WebP/AVIF support. Or perhaps I’ll just enjoy the faster, cleaner site for a while.

Surfing GlobalTalk with a Macintosh 512Ke

Mon, 10 Mar 2025 00:00:00 +0000

While I’ve discussed the origins of my Macintosh 512Ke and the enhancements I’ve done over the past year. What really kicked off my interest in using it more than just Zoom background discussion piece, were all the fediverse posts I saw on GlobalTalk during MARCHintosh 2024.

I was intrigued that classic Macs like my 512Ke, which I always thought was limited in what it could do, could network with other systems, and not just locally but globally. With this in mind I set a goal for myself to have my 512Ke participate in GlobalTalk for MARCHintosh 2025.

LocalTalk, GlobalTalk, TashTalk, Oh My

A quick aside, as noted in my 512Ke enhancements post,I swapped a Macintosh Plus logic board for the 512Ke board in the original case. By using a PicoPSU, RGB2HDMI, FloppyEMU, an original mouse and PS2 keyboard adapter, I can run the 512Ke in a bareboard cyberpunk fashion.

Bareboard 512Ke

To get my 512Ke onto GlobalTalk, I first physically connected everything using PhoneNET with the following hardware,

TashTalk 2 HAT on a RaspberryPi 3
Original Farrallon PhoneNET adapter connected to the TashTalk 2 HAT
Tashtari PhoneNET Adapter connected to the 512Ke

TashTalk 2 HAT on a RaspberryPi 3

Farrallon PhoneNET

Tashtari PhoneNET Adapter

Networking

With everything physically connected, in order for the TashTalk HAT to see LocalTalk traffic, the networking on the RaspberryPi must be setup with a bridge and tap device. Taking inspiration from a post on m68kmla I configured the host networking as follows.

Install required bridge and tap packages,

sudo apt install uml-utilities bridge-utils

Configured /etc/network/interfaces with a bridge, tap and static IP address,

#loopback
auto lo
iface lo inet loopback

# Virtual interface
auto tap2
iface tap2 inet manual
   pre-up tunctl -t tap2 -u root
   up ip link set dev tap2 up
   down ip link set dev tap2 down

# Bridge interface
auto br0
iface br0 inet static
   address 192.168.1.163/24
   gateway 192.168.1.1
   dns-nameservers 192.168.1.1
   bridge_ports eth0 tap2
   bridge_fd 9
   bridge_hello 2
   bridge_maxage 12
   bridge_stp off

Disabled NetworkManager since I want to use /etc/network/interfaces for network configuration,

sudo systemctl disable NetworkManager

After restarting the Pi, the eth0 and tap interfaces will show up on br0 bridge,

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.ae29d573875f       no              eth0
                                                        tap2

TashRouter

Using the tap2 device, next is bridging the TashTalk 2 HAT to Ethernet, making LocalTalk traffic visible on the wider network. This is done using tashrouter which communicates with the TashTalk 2 HAT on /dev/ttyAMA0 and passes LocalTalk to LToUDP and EtherTalk through the tap2 device.

Using the example from the tashrouter repo, I created gt_router.py python script, changing the seed_zone_name to Vermilion Sands LT. This is important, since if LocalTalk devices are in the same Zone as EtherTalk devices it can cause some odd AppleTalk behaviour like file servers not showing up.

gt_router.py

import logging                                                                                                                                 import time
import signal                                                                                                                                  import sys

import tashrouter.netlog
from tashrouter.port.ethertalk.tap import TapPort
from tashrouter.port.localtalk.ltoudp import LtoudpPort
from tashrouter.port.localtalk.tashtalk import TashTalkPort
from tashrouter.router.router import Router

def sigterm_handler(_signo, _stack_frame):
    # Raises SystemExit(0):
    sys.exit(0)

logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s: %(message)s')
#tashrouter.netlog.set_log_str_func(logging.debug)  # comment this line for speed and reduced spam

router = Router('router', ports=(
  LtoudpPort(seed_network=71, seed_zone_name=b'Vermilion Sands LT'),
  TashTalkPort(serial_port='/dev/ttyAMA0', seed_network=72, seed_zone_name=b'Vermilion Sands LT'),
  TapPort(tap_name='tap2', hw_addr=b'\xDE\xAD\xBE\xEF\xCA\xFE'),
))
print('router away!')
router.start()
signal.signal(signal.SIGTERM, sigterm_handler)

try:
  while True: time.sleep(1)
except (KeyboardInterrupt, SystemExit):
  router.stop()

This script is run with sudo python3 gt_router.py.

An On-ramp to The Information Superhighway

With LocalTalk bridged into the Ethernet network, next is getting onto GlobalTalk.

I first followed the The Ultimate GlobalTalk Network Guide to understand how things worked, however this guide uses the older AppleTalk Router software that runs only on a Macintosh system, not Linux.

The newer jrouter project runs on Linux and has features like yaml configuration, logs, and can integrate with tashrouter using the bridge setup.

My configuration for jrouter uses the br0 bridge device, sets the zone name Vermilion Sands, a 1970-1971 network range and opens up peering. The list of peers was copied from the GlobalTalk spreadsheet. As mentioned before, it’s important the zone_name and network range differ from the LocalTalk zone name.

jrouter.yaml

listen_port: 387 #AURP default port
local_ip: XX.XX.XX.XX #Public IP to forward traffic from
monitoring_addr: ":9459"
ethertalk:
  - device: br0
    zone_name: Vermilion Sands
    net_start: 1970
    net_end: 1971
open_peering: true
peers:
    - #peer IPs from GlobalTalk spreadsheet

By using the same br0 bridge device as the gt_router.py script, LocalTalk devices will see GlobalTalk devices and vice versa.

Putting it All Together

With the hardware and software taken care of, everything was in place to start browsing GlobalTalk on the 512Ke like it was 2024. Through various trial and error, I found there is a specific order-of-operations needed for everything to work as expected.

Turn everything off
Physically connect everything
Turn on RaspberryPi
Start jrouter and wait a few minutes for zone information to populate
Start gt_router.py
Turn on clients, like the 512Ke

When running properly, gt_router.py logs will show GlobalTalk traffic and zones and file servers will appear in Chooser on the 512Ke.

512Ke About System with GlobalTalk Zones

GlobalTalk Zones in Chooser on 512Ke

Gotchas

Here are a few gotchas I came across when configuring everything.

If running netatalk or a QEMU Macintosh, put them on a different system than jrouter/tashtalk. Having them all share the same br0 device causes some sort of network loop and can crash a Macintosh connected with LocalTalk.
When in doubt turn everything off and back on again. AppleTalk is temperamental, zones and file servers will just disappear or stop working even though nothing changed. Sometimes the best course of action is to turn everything off, wait a few minutes and then back on again.
Patience is a virtue. The technologies and bitrates involved as relatively slow, and sometimes it just requires waiting a few extra seconds instead of expecting everything to function immediately.

Stretch Goal

A stretch goal I had for this project was seeing if I could transfer files between my 512Ke and a modern Macbook using LocalTalk. I managed to do this by setting up a netatalk 4.1 server on another RaspberryPi with AppleTalk enabled. Because netatalk is able to join the AppleTalk network, it can see and make available it’s services to all devices, including the 512Ke.

After setting up a file share on netatalk, the 512Ke can mount it in Chooser over LocalTalk and Finder on MacOS will see it over wifi. Now I can easily copy files (albeit slowly) between systems using this shared folder.

File share on a 512Ke, Finder and Linux

Rough diagram of how everything is connected

References and Links

Live, Laugh, Localtalk with Basilisk II

Mon, 10 Feb 2025 00:00:00 +0000

As I mentioned in my Enhancing my Macintosh 512Ke post, I use the Basilisk II Macintosh 68k emulator alongside my Macintosh Plus to facilitate downloading software, sharing files with AppleShare, playing Myst and many other things. It does take a bit of setup to get working though, especially with configuring the network to work with AppleTalk.

Below is a short guide on how I installed and setup Basilisk II on my Linux Mint laptop to work with my Macintosh Plus over the network.

Installing Basilisk II

Basilisk II is available in the main Ubuntu, Linux Mint and Debian repos and I assume other Linux distros probably have it too. There are other Macintosh emulators out there like SheepShaver, Mini vMac and even the entirely online Infinite Mac but I like Basilisk since it provides a nice settings manager and works well.

It is quickly installed with apt on a Debian based distro,

sudo apt update
sudo apt install -y basilisk2

Setting Up Basilisk

Basilisk requires a few things to setup, most notable a system ROM and disk image. It also can mount a shared folder with the host called unix that makes copying files in/out of the VM relatively easy.

Start by creating directories for ROMs, disks and file sharing,

mkdir -p ~/Documents/basilisk
cd ~/Documents/
mkdir roms unix disks

Find and copy a ROM file into ~/Documents/basilisk/roms, for my setup I use PERFORMA.ROM for no particular reason.

In the Memory/Misc tab, configure the machine with the following,

MacOS RAM Size (MB): 128 (or higher)
Mac Model ID: Mac IIci (MacOS 7.X)
CPU Type: 68040
ROM File: ~/Documents/basilisk/roms/PERFORMA.ROM

Basilisk II Memory/Misc Tab

A full Install of System 7.5.5 is required in order to use AppleShare and do anything really useful. Disk images are available various places online or you can follow a guide to make your own, which is what I did.

Using Basilisk

With system configuration complete and a 7.5.5 disk image ready, turn on the VM which will load a default desktop containing few icons like the disk drive and trash.

Default 7.5.5 Desktop in Basilisk

Wireless LocalTalk

Getting AppleTalk to work on a 7.5.5 in Basilisk and communicate with other Macintosh devices over LocalTalk using the hosts wireless networking requires a custom kernel module call sheep_net.

The module is available in the macemu repository and must be built your system and kernel version. This also means that every time there is a kernel upgrade, you will need to re-build the module.

To build the kernel module,

git clone https://github.com/cebix/macemu.git
cd macemu/BasiliskII/src/Unix/Linux/NetDriver
make
sudo make install

Load the sheep_net kernel module and update it’s permissions so users other than root can use it. This must also be done on every reboot and I have on my to-do list to write a script and add it to something like rc.local so it loads with the correct permissions across reboots.

sudo modprobe sheep_net
sudo chmod 777 /dev/sheep_net

Finally, in the Serial/Network tab of Basilisk, change the Ethernet Interface to your wireless or wired Ethernet device that’s connected to your LAN.

Basilisk Network Tab

After starting the VM will see other devices using AppleTalk on your local network, and if you have a TashTalk and TashRouter, older LocalTalk devices like a Macintosh Plus are also available.

Conclusion

The biggest benefit I have from this setup is I can write blog posts in MacWrite on the Macintosh Plus completely distraction free and save them easily to a shared folder in Basilik on my laptop over wifi.

Previously I would save the file to a virtual floppy disk on the FloppyEMU or use the BlueSCSI Toolbox to export the file to the SD card. Saving directly to Basilisk and then copying the file to the laptop through the unix shared folder is faster and closer to the original way Macintosh file sharing worked.

AppleShare in Basilisk

This setup makes me appreciate how impressive that AppleTalk is as almost entirely zero-configuration. Just plug systems into the same physical (or wireless) network and they’re immediately available for use, even today there are very few products that can claim to do that.

Enhancing my Macintosh 512Ke

Wed, 05 Feb 2025 00:00:00 +0000

This is the second in a series of posts on my Macintosh 512Ke. In my first post I went over the history of how I obtained this machine, initial exploration and repairs over the years.

My Macintosh 512Ke Enhanced in all its glory

This post will go over the enhancements I’ve done to my Macintosh 512Ke over the last six months. Getting it to the point where it can do useful, and modern day things, like writing blog posts in MacWrite, surfing Gopher, chatting on IRC or cruising a BBS over WiFi and sharing files with modern Linux system. All of these enhancements are completely reversible and non-destructive if I ever want to to bring the machine back to its original stock state.

FloppyEMU

A FloppyEMU let’s me use floppy images directly from an SD card, eliminating the need to use a floppy drive. The original 800k internal floppy drive suffered from cheese-wheel-of-death which I repaired, cleaned and lubricated for whenever I want to use real floppies, but I almost always prefer the FloppyEMU.

FloppyEMU displaying some disks

USB4VC

The USB4VC allows me to use modern USB mice/keyboards on the machine, solving the problem I had of lacking the original M0110 keyboard. My usual keyboard of choice is a transparent blue Monsgeek ICE75 wireless keyboard and a clear blue wireless mouse because I feel it adds to the overall ａｅｓｔｈｅｔｉｃ.

USB4VC

Macintosh Plus Logic Board

I replaced the 512Ke logic board with a Macintosh Plus logic board providing 4MiB of memory (8x what the 512Ke has) and external SCSI port. This upgrade opens up many more use cases, such as running MacTCP which was impossible on a 512Ke.

Technically this also makes it no longer a 512Ke, and due to the port differences on the boards I had to replace the back case with Macintosh Plus case. Because of the case swap, the rear case is “Platinum” and the front “beige”, giving it a slight two-tone look when viewed from the side. It also lacks the “Macintosh Plus” case badge on the front, making this machine a chimera of sorts. I also did a SCSI term power mod to the board to power the BlueSCSI without requiring an external power source.

MacPlus logic board pre SCSI term mod

BlueSCSI

A BlueSCSI hangs off the external SCSI port on the back of the MacPlus logic board, booting a System 7.0.1 image from its SD card. Because I splashed the extra $ and built it with a RaspberryPi Pico W, it has the ability to emulate a DynaPort EtherTalk device and connect to The Internet using WiFi.

BlueSCSI

PicoRC

A PicoRC provides power to the logic board and CRT portion of the analog board with a PicoPSU ATX power supply and common AC power brick. It also allows easy access to the pinouts for Signal, H-Sync, V-Sync and GND pins from the logic board wiring harness.

PicoRC connected to MacPlus logic board

Cooling

Original Classic Macintoshs were notorious for failing over time due to heat issues, and using the fan header on the PicoRC, I strapped a Noctua NF-A4x10 Fan to the inside of the case with a zip tie. It doesn’t move a ton of air and adds some noise to a previously silent machine, and it should add a few more hours of life.

Fan zip-tied to inside the case

RGB2HDMI

The RGB2HDMI can display the video output of the Macintosh over HDMI to any modern LCD monitor or video capture device. By soldering wires to the Signal, H-Sync, V-sync and Ground pinouts on the PicoRC I can tap into the video signal and use the internal CRT and an external display at the same time.

This is also my backup plan to continue using the machine if/when the CRT fails, as the logic board and rest of these enhancements (USB4VC and PicoRO) will still be able to display to any monitor that supports HDMI.

Displaying Finder on an both an external LCD and the internal CRT

TashTalk 2

The TashTalk 2 is a RaspberryPi HAT that lets me connect my Macintosh using PhoneNET adaptors to other devices with AppleTalk networking. With this setup I can use AppleShare to share files and printers between other Macintoshes on the network. As an example I’m writing this post on the Macintosh Plus and saving it remotely over AppleShare, then copy it into this blog and publish it.

TashTalk2 HAT on RaspberryPi 3

Basilisk II

Basilisk II is not a modification, but a Macintosh 68k emulator for MacOS and Linux. I run System 7.5 Basilisk VM to download applications, extract files, and do things in a similar Macintosh environment but on faster hardware. The TashTalk2 RaspberryPi runs a TashRouter that and share files between Basilisk II and the Macintosh over AppleShare.

Basilisk II and video out from the Macintosh Plus

ROMinator

The most recent modification to my Macintosh is a ROMinator that replaces the original system ROM that shipped with the Plus. It provides all the features of the original ROM, but has extra features like changing the startup icon, startup sound and holding down R will boot into System 6 from ROM.

ROMinator on the MacPlus logic board

Thoughts

Over the last six months I am surprised by how much I’ve learned about classic Macintoshs. I went from booting 40 year old floppies, to connecting to Gopher sites and modern Linux systems and can use my Macintosh 512Ke (Plus) as I would a modern machine. The retro community around these systems is extremely impressive, creating tools and hardware that up until a few years ago didn’t exist and I am grateful for the dedication and enthusiasm that others have for this platform.

There are still a few things I would like to do (remote access…?) machine, but I am extremely happy with this setup and use it on a weekly basis, writing blog posts like this one, playing games, or just enjoying computing from when times were simpler and more optimistic.

A Macintosh Story

Tue, 28 Jan 2025 00:00:00 +0000

This is the first post in what I am hoping a series of how I took my 512Ke “Fat Mac” and enhanched it to the state it is today.

My Macintosh editing this blog post in MacWrite

Releasing the Magic Smoke

Our story begins a dozen years ago when I inherited the 512Ke Mac from a nursery school. I had at one point turned it on to check if it worked and test out a few of the floppies it came with, but it wasn’t until years later when I thought the kids would like to see it in action during COVID that I did anything else with it. I booted up Dinosaur Discovery Kit for them to play, which they enjoyed, but 5 minutes later there was a loud pop and a lot of smoke coming out of the case. After quickly moving the kids to a safe distance and bringing it outside, I realized it was still functioning normally right up until I powered it off.

Researching into what happened, I learned older macs like many systems from the 1980s used RIFA capacitors that were notorious for failing in a spectacular manner and there were inexpensive modern day replacements. In addition to replacing the RIFA, I decided to recap the entire “analog” board, as the capacitors over time could leak and cause all sorts of issues.

Blown RIFA capacitor

A few online purchases and days later I had replacement capacitors and slowly went through desoldering the old ones and soldering the new ones onto the analog board. Learning about proper CRT discharge procedures as the analog board could provide quite a shock due to the high voltage running through it even after it was powered off. Once everything was replaced, the 512Ke worked just fine and Dinosaur Discovery Kit and other software booted off the floppy without issue.

I used the machine a bit more, but found it limited in what it could do, especially with many of the floppies I had not working at all. I shelved the system again, satisfied it “worked” but didn’t have much use for it other than looking nice on a shelf in the garage behind me during Zoom meetings..

FloppyEMU

Sometime in 2024 while watching retro computer youtube videos I saw a someone use a FloppyEMU to emulate an external floppy drive and run Macintosh programs downloaded from websites like Macintosh Garden and Macintosh Repository directly off an SD card. It could even emulate a Hard Disk 20 with a 20MiB storage capacity.

Reading more about the FloppyEMU opened up many possibilities, no more would I be limited to the floppy disks I had, but could run practically any Macintosh software that the 512Ke would run, just find it, copy to an SD card and boot. The possibilities were endless.

I ordered one and after a few days it arrived, it was relatively easy to assemble and soon I was able to boot off of it, trying out all sorts of software and it completely changed how I could use the machine. It also greatly increased my knowledge of how early Macintoshes worked. Most of my computing experience has involved operating systems installed to permanent storage, like a hard drive, booting off of it and then running programs. Where with the Macintosh there was an Operating System, but you mostly booted into programs directly, they still had a Finder but were very limited and you would have to switch disks if you wanted to do something else.

FloppyEMU running Dark Castle

While the FloppyEMU made this easier, it was starting to show some of it’s own flaws, such as “File not contiguous” errors. After a lot of reading, I found that copying files from my modern Macbook via Finder to the SD card wouldn’t write them in a single stream of data, confusing the FloppyEMU. Copying disk images from my Linux system worked better, but depending on the file format, download site and many other options this was a continuous challenge.

HD20

My frustrations with booting the FloppyEMU as a floppy drive lead to using it’s feature of emulating a Hard Disk 20. This resolved the problems I was having with continually removing the SD card, copying the disk images to it, booting up the 512Ke and then hoping it would work. Now I could copy almost as many disk images as I wanted to the HD20 and have it boot into the System 6 operating system directly, using it more or less like a modern computer.

While using this technique, I ended up keeping notes of what all software worked and what didn’t with the error messages on those that didn’t. One that kept repeating itself was the 512Ke simply running out of memory. In my solution of booting to System 6 on the HD20, I inadvertently used up much of the precious 512Ke of memory for the OS, further limiting what software I could run unless I booted directly too it from the FloppyEMU, bringing me back to square one.

No Keyboard Detected

As an aside, while doing all of this, I was still missing one major component - a keyboard. Because the original Macintosh was so focused on using a mouse, I was able to do all of the above with the original M0100 mouse it came with, but I didn’t have a M0110 keyboard to use with the system. There were some on Ebay, but they were almost, if not more, expensive than the 512Ke itself and I would need to start looking for alternative options.

Input/Output

Up until this point I was really enjoying using the 512Ke, and the software I could run with only the mouse was a lot of fun to use, but I wanted to do more. After watching some videos about the SE/30 the series of videos JCS had done on their 512Ke programming new System 6 software on the system itself, I knew the system was capable of much more.

I knew there was a big enough vintage Macintosh community to support something like the FloppyEMU, so that must mean there are other projects out there right? How else could I push the system; avoid memory issues, use a modern keyboard, and maybe even getting it online? That rabbit hole was much deeper than I was expecting.

Switching to Ghostty

Thu, 23 Jan 2025 00:00:00 +0000

Ghostty 👻

In December 2024 the new terminal emulator ghostty created by mitchellh (founder of Hashicorp) was released.

I originally had the (incorrect) assumption that it was similar to other “new” terminal emulators that require a network connection, were built in javascript or had some sort of “AI” features wedged in.

What caught my eye though when reading About Ghostty, was the focus on the following,

This quote by mitchellh and finally convinced me to give it a try,

I like to imagine that if stores like CompUSA still existed, Ghostty 1.0 would be boxed, shrink-wrapped, and on the shelf ready for purchase (but also free and open-source).

Ghostty Terminal editing a draft of this post

Initial Impressions

Installing on my MacOS and Linux laptops was relatively straightforward, although for my Linux Mint laptop I had to install a .deb from a 3rd party repo. What I first noticed was it’s sane defaults, it just worked out-of-the-box and I could just start using it. It was snappy too, especially compared to Terminal.app on MacOS.

What really hooked me was finding the built-in themes, including my current favorite, Tokyo Night. Not only were these built into ghostty, but there was an interactive preview feature with the ghostty +list-themes command.

Ghostty Theme Preview

It was a lot of fun previewing themes with zero friction of trying them out, unlike other terminal emulators where you have to change a config and then reload it. In addition, the theme options can set a theme for both light and dark modes, dynamically switching depending on your OS setting. I like to have a “light” OS theme during the day and a “dark” theme during the night and this was a feature I haven’t seen in other terminal emulators.

Customizing the Config

My ghostty configuration is relatively small, with a few changes for how I like my terminal emulator,

TX-02(Berkeley Mono) Font
Semi-transparent blurred background
Block style blinking cursor
Inverted selection
Easy to read

~/.config/ghostty/config

#Font
font-family = "TX-02"
font-size = "16"

#Terminal settings
term = "xterm-256color"

#Visuals
theme = "light:tokyonight-day,dark:tokyonight"
background-opacity = .9
background-blur-radius = 20
selection-invert-fg-bg = true
bold-is-bright = true
minimum-contrast = 2

#Cursor
cursor-style = block
cursor-style-blink = true
cursor-invert-fg-bg = true
cursor-opacity = .8
shell-integration-features = no-cursor

Graphics

I’ve always though it was cool that some terminals could display graphics using sixels, but support in Terminal.app was never there. Ghostty doesn’t support sixels either, but does support the Kitty Graphics Protocol, which is even better as it’s a modern library and in active development.

This lets terminals tools like timg, mpv and neofetch display graphics right in the terminal.

Ghostty Graphics with neofetch

After Two Weeks

I’ve been using ghostty for the past two weeks on all my systems and I’ve really enjoyed it. It performs much better than Terminal.app on MacOS, which feels extremely sluggish in comparison now.

That’s not to say I haven’t had any issues,

Somehow Super+Shift+V makes it impossible in vim to switch out of insert mode
Background blur was just recently added for Linux, but isn’t in an official release yet
On MacOS the cursor will not change depending on the context (issue 3257)

These aren’t enough to keep from using ghostty, and I am looking forward to what future releases have in store.

DNS Guardrails with dnscrypt-proxy

Tue, 23 Jan 2024 00:00:00 +0000

Intro

Over the holidays we got our two younger children HP laptops for them to do their school work on and to have a proper computer. While the schools Google Classroom login effectively adds restrictions to Chrome, I still wanted to have some guardrails on their Internet access as well as ad-blocking.

The first thing I did was replace the Windows S install that came on the laptops with Linux Mint as I’ve always enjoyed the Cinnamon desktop environment and it has a low enough learning curve that the kids could easily pick it up. After installing a few apps and games (OpenRCT2) from the Software Center and setting their own passwords, they were up and running and surfing the world-wide-web.

Finally I added Tailscale to both laptops to put them on my tailnet. This has benefits of accessing tailnet-only services, easier remote access, and leveraging the dnscrypt-proxy on OpenBSD I setup a few years ago for DNS.

Guardrails

My original DNS config worked well, but I wanted to add some guardrails specifically for the kids laptops,

Cloudflare for Families
Ad Blocking
YouTube Restricted Mode via Cloaking
Accessible only from the Tailscale

First I tried using the existing dnscrypt-proxy to provide a different set of DNS resolvers depending on the source IP, but this wasn’t possible. Eventually I came up with a seperate DNS infrastructure in a container for the laptops to use instead.

Container Stack

Dockerfile is used for building a container including dnscrypt-proxy,

FROM debian:trixie-slim
ENV DEBIAN_FRONTEND noninteractive

RUN apt update && \
    apt install -y dnscrypt-proxy \
      ca-certificates \
    && apt clean

WORKDIR /tmp
ENTRYPOINT [ "/usr/sbin/dnscrypt-proxy" ]
CMD [ "-config", "/etc/dnscrypt-proxy/dnscrypt-proxy.toml" ]

docker compose is used to bring up the stack, which includes a tailscale container to provide network and access to other devices on the tailnet. Configuration files are monted read-only from the current directly and some volumes to maintain state across restarts.

docker-compose.yml

version: '3.9'
services:
  tailscale:
    container_name: tailscale-dnscrypt
    hostname: dnscrypt-proxy
    image: ghcr.io/tailscale/tailscale
    stdin_open: true
    environment:
      - TS_AUTH_KEY=${TS_AUTH_KEY}
      - TS_USERSPACE=true
      - TS_STATE_DIR=/var/lib/tailscale
      - TS_SOCKET=/var/run/tailscale/tailscaled.sock
    volumes:
      - dnscryptvarlib:/var/lib
    restart: unless-stopped
  dnscrypt-proxy:
    build: .
    stdin_open: true
    volumes:
      - ./dnscrypt-proxy.toml:/etc/dnscrypt-proxy/dnscrypt-proxy.toml:ro
      - ./blocklist.txt:/etc/dnscrypt-proxy/blocklist.txt:ro
      - ./cloaking-rules.txt:/etc/dnscrypt-proxy/cloaking-rules.txt:ro
      - ./domains-allowlist.txt:/etc/dnscrypt-proxy/domains-allowlist.txt:ro
      - keys:/etc/dnscrypt-proxy/keys
    restart: unless-stopped
    network_mode: 'service:tailscale'
volumes:
  dnscryptvarlib:
  keys:

dnscrypt-proxy

The dnscrypt-proxy configuration uses the cloudflare-family source and ad-blocking using a blocklist.txt generated with generate-domains-blocklist.py. All logs go to /dev/stdout so they appear in docker compose logs.

dnscrypt-proxy.toml

#Use cloudflare DNS
server_names = ['cloudflare-family']

#Listen on local and LAN addresses for DNS
listen_addresses = ['127.0.0.1:53']
max_clients = 250
user_name = '_dnscrypt-proxy'

#Enable ipv4 and ipv6
ipv4_servers = true
ipv6_servers = false

#Allow TCP and UDP
force_tcp = false
timeout = 2500
keepalive = 30

#Logging
log_level = 2
use_syslog = true

#Certs
cert_refresh_delay = 240
dnscrypt_ephemeral_keys = true
tls_disable_session_tickets = true

#Cache
cache = true

#Cloaking
cloaking_rules = '/etc/dnscrypt-proxy/cloaking-rules.txt'

#Query logging, commented out unless for troubleshooting
[query_log]
  file = '/dev/stdout'
  format = 'tsv'

#Sources for resolvers and relays
[sources]
  [sources.'public-resolvers']
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v3
/public-resolvers.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  cache_file = '/var/tmp/public-resolvers.md'
  refresh_delay = 72

#Blocking configuration
[blocked_names]
  ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file)
  blocked_names_file = '/etc/dnscrypt-proxy/blocklist.txt'
  log_file = '/dev/stdout'
  log_format = 'tsv'

#Allow configuration
[allowed_names]
  allowed_names_file = '/etc/dnscrypt-proxy/domains-allowlist.txt

Cloaking is used so all YouTube requests resolve to restrict.youtube.com.

cloaking-rules.txt

www.youtube.com restrict.youtube.com
m.youtube.com  restrict.youtube.com
youtubei.googleapis.com restrict.youtube.com
youtube.googleapis.com restrict.youtube.com
www.youtube-nocookie.com restrict.youtube.com

Exposing via Tailscale

Since I only want DNS available to devices on my tailnet, and not publicly available, there’s a tailscale container in the docker-compose.yml that provides networking to the dnscrypt-proxy container using network_mode.

Set this up by creating an auth key for your tailnet and then putting it into a .env file that docker compose will source in and set as the TS_AUTH_KEY variable.

.env

TS_AUTH_KEY=tskey-auth-xxxxxxxxxxx

Enabling on Linux Mint

My tailnet uses Magic DNS which sets the nameserver for all devices on a tailnet to 100.100.100.100, but since this is a DNS server specific to a subset of systems we want to use the IP of the dnscrypt-proxy device instead.

After bringing up the stack with docker compose up, the tailscale container will authenticate to the tailnet and have an Tailscale IP (eg 100.112.129.40). This IP is then added to the laptops /etc/resolv.conf,

nameserver 100.112.129.40
search tailnet-3831.ts.net

Tailscale will keep trying to revert this, so to keep the settings permanent, /etc/resolv.conf is set to immutable with chattr +i /etc/resolv.conf.

To test DNS is working, looking for more “adult” content on youtube will give a message similar to “your Google workspace administrator has restricted some content”.

Verify in container logs with dig m.youtube.com @100.76.233.91 (where the IP is your Tailscale container IP) and check the logs for messages similar to 127.0.0.1 m.youtube.com A CLOAK 0ms -.

Tailscale on the DevTerm R-01

Wed, 25 Jan 2023 00:00:00 +0000

Intro

Recently I assembled a ClockworkPi DevTerm R-01, a cyberdeck-like terminal with a RISC-V compute module. While the retro-future design of the DevTerm really appealed to me, and I’ve also been wanting to work with RISC-V for a while to learn a new architecture making the R-01 a perfect esoteric project platform.

ClockworkPi DevTerm R-01

After trying out a few things like DOSBox, Surf, and ScummVM, I found the Allwinner D1 RISC-V chip wasn’t powerful enough to do much other than some basic window management, Interactive Fiction, and browsing gopher:// with Bombadillo. However I still wanted to use it as a terminal to access other systems, which lead me to attempting to install Tailscale to leverage the mesh VPN and other features.

Installing tailscale was un-eventful, as it’s had RISC-V support for a while, and following the install guide did what was expected. The problem is tailscaled fails due to the required tun kernel module missing in the 5.4.61 kernel running on the DevTerm.

Jan 26 02:25:17 localhost systemd[1]: Started Tailscale node agent.
Jan 26 02:25:17 localhost tailscaled[1074605]: wgengine.NewUserspaceEngine(tun "tailscale0") ...
Jan 26 02:25:17 localhost tailscaled[1074605]: Linux kernel version: 5.4.61
Jan 26 02:25:17 localhost tailscaled[1074605]: is CONFIG_TUN enabled in your kernel? `modprobe tun` failed with: modprobe: FATAL: Module tun not found in directory /lib/modules/5.4.61
Jan 26 02:25:19 localhost tailscaled[1074605]: tun module not loaded nor found on disk
Jan 26 02:25:19 localhost tailscaled[1074605]: wgengine.NewUserspaceEngine(tun "tailscale0") error: tstun.New("tailscale0"): CreateTUN("tailscale0") failed; /dev/net/tun does not exist
Jan 26 02:25:19 localhost tailscaled[1074605]: flushing log.
Jan 26 02:25:19 localhost tailscaled[1074605]: logger closing down

Building a TUN/TAP Kernel Module

The first step was finding if the R-01 kernel source was available so re-build the exact kernel version and include the tun module by setting CONFIG_TUN=m. Looking around the ClockworkPi website, Discord, and Github I eventually found the How to Compile Kernel documentation. This had links to the original source and the toolchain.

Since the R-01 isn’t exactly fast, cross-building this on a x86 system was required. My personal Debian server is a bit of mess when it comes to package pinning, so I created a new 8 CPU, 8GiB memory virtual machine in qemu and install Ubuntu 22.04 “Jammy Jellyfish” since that’s what the R-01 is running and what ClockworkPi has in it’s documentation.

Installing Required Packages

After setting up the VM, install required packages for cross-building the kernel,

sudo apt-get install gcc-11-riscv64-linux-gnu binutils-riscv64-linux-gnu qemu-user-static build-essential git wget curl vim libncurses-dev flex automake autoconf bison libssl-dev

Cloning ClockworkPi Kernel Source

Clone the kernel source into ~/git,

mkdir ~/git
git clone https://github.com/cuu/last_linux-5.4.git

Setting Up Build Toolchain

Download the ClockworkPi toolchain from https://github.com/cuu/toolchain-thead-glibc, which is a README pointing to a Mega link. While it’s a bit concerning coming from Mega, since it’s a tarball and running in a VM it’s not that risky. There’s also a section on installing the official RISC-V toolchain which is another option, but requires additional building.

Untar in home directory,

cd ~
tar -xvzf riscv64-glibc-gcc-thead_20200702.tar.gz

Existing Kernel Config from DevTerm

Copy the running kernel config in /proc/config.gz on the DevTerm to the VM. The config.gz contains the configuration for how the running 5.4.61 kernel was configured and is loaded to set everything the exact same way when building the new kernel.

cd ~/git/last_linux-5.4
scp cpi@devterm:/proc/config.gz .
gunzip config.gz
mv config .config

Enabling CONFIG_TUN

There are two ways to enable the TUN/TAP module,

Edit .config and set CONFIG_TUN=m

Interactively run menuconfig and set it in Device Drivers -> Network device support -> Universal TUN/TAP device driver support

export PATH=~/riscv64-glibc-gcc-thead_20200702/bin/:$PATH
make LOCALVERSION= CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv menuconfig

Building the Kernel

Build the kernel using the provided m.sh script, but first edit it to include the PATH for the toolchain and LOCALVERSION=. If LOCALVERSION= isn’t set then the kernel version will include a + at the end and modules will not load due to a version mis-match,

export PATH=~/riscv64-glibc-gcc-thead_20200702/bin/:$PATH
make LOCALVERSION= CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv
make LOCALVERSION= CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv INSTALL_MOD_PATH=test/rootfs/ modules_install
make LOCALVERSION= CROSS_COMPILE=riscv64-unknown-linux-gnu- ARCH=riscv INSTALL_PATH=test/boot/ zinstall
mkdir -p test/boot/
cp arch/riscv/boot/dts/sunxi/board.dtb test/boot/

Run ./m.sh and wait a few minutes while it builds.

When successful, the new kernel and modules are in test/boot/

Setting up New Modules on DevTerm

Create a tarball of the new modules and copy them to the DevTerm,

cd ~/git/last_linux-5.4/test/rootfs/lib/modules
tar -cvzf 5.4.61.modules.tar.gz 5.4.61/
scp 5.4.61.modules.tar.gz cpi@devterm:~

On the DevTerm, backup original modules directory,

cd /lib/modules
sudo mv 5.4.61 5.4.61.orig

and untar the new modules directory,

cd /lib/modules
sudo tar -xvzf ~/5.4.61.modules.tar.gz

Loading the TUN/TAP Module

Load the new TUN/TAP Module,

sudo modprobe tun

If successfull dmesg will show,

tun: Universal TUN/TAP device driver, 1.6

Setting up Tailscale

Now that the TUN/TAP module is loaded, start tailscaled and finish setting up Tailscale,

sudo service tailscaled start
sudo tailscale up

Superhighway84 on FreeBSD

Mon, 17 Jan 2022 00:00:00 +0000

Intro

A couple of weeks ago I saw Superhighway84 on HackerNews and started to check it out, but didn’t get very far. I finally spent some time to get it up and running on FreeBSD which works, but requires a few additional steps.

I wanted to get Superhighway84 on a spare RaspberryPi 3 running FreeBSD 13, primarily used for a Gemini Capsule in FreeBSD, since it doesn’t have much traffic and is mostly idle.

Superhighway84 is an USENET-inspired decentralized internet discussion system, featuring a retro text user interface and powered by IPFS and OrbitDB.

Superhighway84 in Solarized Dark terminal

IPFS on FreeBSD

Superhighway84 uses IPFS as it’s backend, making it fully decentralized. Reading through the setup docs, an ipfs init is required to build the initial ~/.ipfs filesystem. There is a ipfs-go in FreeBSD ports, but it doesn’t seem to work, at least on arm64.

To work around this, building ipfs-go from source is doable in a few steps,

First, install a few required packages to compile the go binaries

$ doas pkg install gcc gmake go openssl

Next, clone the source of go-ipfs and checkout the latest stable branch, otherwise there might be a version mismatch error on startup,

$ git clone https://github.com/ipfs/go-ipfs.git
$ cd go-ipfs
$ git checkout tags/v0.11.0

Set a few environment vars to compile with gcc and use openssl,

$ export PATH=$PATH:/usr/local/go/bin
$ export PATH=$PATH:$GOPATH/bin
$ export CGO_ENABLED=1
$ export GOTAGS=openssl

Build from source using gmake

$ doas gmake install
go version go1.17.5 freebsd/arm64
bin/check_go_version 1.15.2
plugin/loader/preload.sh > plugin/loader/preload.go
go fmt plugin/loader/preload.go >/dev/null
go install "-asmflags=all='-trimpath='" "-gcflags=all='-trimpath='" -ldflags="-X "github.com/ipfs/go-ipfs".CurrentCommit=67220edaa" ./cmd/ipfs

After the build is finished, copy the binary to ~/bin and export it into the $PATH ,

$ cp ~/go/bin/ipfs ~/bin
$ export PATH="~/bin:$PATH"

Initialize ~/.ipfs and set profile config to lowpower for running on a RaspberryPi

$ ipfs init --profile=lowpower

Building Superhighway84

With IPFS initialized, build Superhighway84 and copy the binary to ~/bin. There are binary releases for FreeBSD arm64, but compiling it from source is relatively easy as well.

$ git clone https://github.com/mrusme/superhighway84.git
$ cd superhighway84
$ go build .
$ cp superhighway64 ~/bin

Start up superhighway84, and wait a few minutes to fully sync. Using a “light” terminal theme is not recommened as it’s difficult to read, and I recommended switching to a darker terminal theme.

$ superhighway84

Bookmarking and Creating a Local Internet Archive

Tue, 04 Jan 2022 00:00:00 +0000

Intro

While I’m a heavy user of RSS with Newsblur, I’ve never had a coherent bookmarking solution. Last week I finally setup a proper bookmark manager, and as a bonus, archived bookmarked pages locally in my own personal Internet Archive.

Bookmarking With Raindrop.io

A long time ago I was a user of del.icio.us, and first looked into using Pinboard for bookmarking. While Pinboard had most of the features I wanted - it lacked a native mobile app. I looked into other alternatives, and I ended up subscribing to Raindrop.io after using it for a few days on a trial basis.

Raindrop.io had all the features I was looking for,

Using the apps or browser extensions is seamless, making it easy to save bookmarks no matter what device or browser I’m using. I also imported all of my Firefox bookmarks which required some cleaning up, but gave a good impression of how the tool looks with content. I’m still experimenting with categories and tagging, but overall there’s some order to the chaos, and with tags and full text search I can quickly find sites without having to resort to a search engine.

I also setup an IFTTT automation so whenever a page is bookmarked in Raindrop.io, it will add it to Saved Stories in Newsblur with the tags. While it’s not really that useful, it can act as a sort of backup if needed and maybe in the future Newsblur will add some feature that makes it more useful.

Raindrop.io Mac App

Archiving Locally with ArchiveBox

While researching bookmarking services, I stumbled across ArchiveBox, which can create a local Internet Archive of webpages, media, and other thing from the web. It can also import bookmarks, archiving them locally and sending them to archive.org.

This got me thinking, the Backup feature in Raindrop.io saves an Export.html to Dropbox. I could setup Dropboxy sync on my server and have a cronjob import every hour, syncing all new bookmarks from Raindrop.io into ArchiveBox automatically.

My first attempt at this was successful, but the Export.html backup is a <!DOCTYPE NETSCAPE-Bookmark-file-1> format, and while ArchiveBox can import it, it doesn’t do it all that well - creating archives of parts of pages, not applying tags, and just overall wasn’t very consistent.

I found that ArchiveBox can also import a json formatted file with a simple array schema with a url: and tags: fields, so I wrote a quick script to convert this Backup.html into an import.json and then import it into ArchiveBox using docker-compose. Putting this into an hourly cronjob then automatically imports any new bookmarks and archives them.

This script gets all bookmarked URLs and tags from Export.html and creates a import.json with a structure of,

import.json:

[
{ "url": "https://www.friendlyskies.net/notebook/giving-haiku-os-beta-3-a-try", "tags": "haiku,os" },
{ "url": "https://github.com/dwmkerr/hacker-laws", "tags": "patterns" },
...
{ "url": "https://www.benoakley.co.uk/tartan-asia-extreme", "tags": "korean,japanese,film,movies" },
{ "url": "https://drodio.com/creating-your-own-remote-workspace-for-under-5k/", "tags": "wfh,shed,backyard" }
]

raindrop-import.sh:

#!/bin/bash
#Imports bookmarks from Raindrop.io

#Backup file from Raindrop sync on Dropbox
exportfile="~/Dropbox/Apps/Raindrop.io/Export.html"
importfile="~/Dropbox/Apps/Raindrop.io/import.json"

count=0
delimiter=','

echo "[" > ${importfile}

#Cleanup import to only get raw links
for url in $(grep -io '<a href=['"'"'"][^"'"'"']*['"'"'"]' ${exportfile} | sed -e 's/^<a href=["'"'"']//i' -e 's/["'"'"']$//i'); do
  tags=$(grep "A HREF=\"${url}\"" "${exportfile}" | grep -io 'tags=['"'"'"][^"'"'"']*['"'"'"]' | sed -e 's/^tags=["'"'"']//i' -e 's/["'"'"']$//i' | tr '\n' ',')
  munged_tags=${tags%?}
  echo "{ \"url\": \"${url}\", \"tags\": \"${munged_tags}\" }${delimiter}" >> ${importfile}
done

#Trim last , in file before finishing array to make it valid JSON
sed -i '$ s/.$//' ${importfile}

echo "]" >> ${importfile}

#Check that JSON is valid before importing
if jq -e . >/dev/null 2>&1 < "${importfile}"; then
  echo "Successfully Parsed JSON from ${importfile}"
else
  echo "Unsuccessfully Parsed JSON from ${importfile}"
  exit 1
fi

#Import exportfile into archivebox using docker-compose
docker-compose -f ~/archivebox/docker-compose.yml run --rm archivebox add --parser json < ${importfile}

When imported, only these URLs are archived and the tags are applied properly, creating an complete archived copy of bookmarks saved in Raindrop.io.

ArchiveBox

Since Raindrop.io has preview/live/archive views as well as fulltext search, I probably won’t use ArchiveBox frequently, but it’s good to have a local backup in multiple formats just-in-case. It also automatically sends the page to archive.org, so it’s another guarentee that it is archived somewhere in case the page disappears 10 years from now. By default it will also save a PDF file and text using Mercury and Readability which I may work on setting up to send to my Kindle for offline reading.

Conclusion

I now have a featureful bookmarking service that I can use almost anywhere, and have started making extensive use of it already. I wish I had setup something like this years ago, as there are many sites I’ve come across that I wish I could reference but completely forget how to find them using a search engine. Now can I not only quickly find them in my bookmark manager, but I also have my own local archive I can rely on in the future as well.

This Website Is Now Available on IPFS, ENS, and Handshake

Thu, 30 Dec 2021 00:00:00 +0000

Intro

In the past few months there has been a lot of chatter about web3 and what it means and doesn’t mean for the future of the web. There’s a lot of hype around NFTs, mostly because of the money that is exchanging hands, and instead of outright dismissing it I wanted to dive deeper to understand it better.

Setting up an ENS Domain

I first thought about NFTs when I discovered you can buy ENS Domains and then set them up like a standard DNS name with the additional benefit of using them as an identity. I went through the ENS purchase - setting up Coinbase Wallet - and buying the domain with some ETH. My overall impression was is there’s a lot of fees. Registering the domain and other actions are relatively inexpensive, but the gas fees are much higher and take up the bulk of the transaction cost. Skipping over all the details, it cost about 400$ to fully setup ecliptik.eth - registering, reverse lookup to my wallet address, and setting the metadata.

The results of setting up the ENS domain are here, ecliptik.eth and it resolves to https://ecliptik.eth on IPFS. This name also includes additional features like setting my Avatar image to an NFT I own (which is one I created myself and put on opensea.io for free).

Setting up a Handshake Domain

The next domain setup was Handshake which is a “Decentralized naming and certificate authority” and has an auction process to acquire a Handshake domain. I setup Bob Wallet and went through the airdrop claim to get some HNS. Eventually I ended up using Namebase to handle the auction and management details and after about 14 days (due to the auction process) I was the new owner of the ecliptik Handshake domain.

The one interesting thing I noticed is that the ecliptik domain was already up for auction when I checked. After some research I found that if you register an ENS domain name and it’s not claimed on Handshake, there are bots that will automatically start and auction for it. Because it was a bot and not someone else trying to buy it, I easily outbid and acquired the name with no counter bids. I also acquired a few other names like amfora and rawtext since I had some more HNS.

Accessing the HNS domain requires some additional software or using DNS servers that support it, the Namebase article How to Access Handshake Sites has how to set this all up.

Handshake names are also available using the hns.to domain, and mine is accessible at https://ecliptik.hns.to

Mirroring To IPFS

Now that I had the DNS and Handshake domains I had to figure out how to use them. ENS has a lot of documentation on using IPFS to point an ENS domain to, and then it’s fully part of the “Distributed Web”. After doing some research I found that Fleek.co provides free Web, IPFS, ENS, and Handshake features. I followed their setup guide and now whenever I push to main on my Github Pages repo, it automatically publishes it to IPFS using InterPlanetary Name System (IPNS) which resolves the name ecliptik.ens to the current version of this blog.

Now whenever I publish to this blog, it’s automatically updated on IPFS and available at ipns://ecliptik.eth, and via http at https://ecliptik.eth.limo.

Accessing ENS and IPFS directly requires some additional software outside of traditional browsers, but Brave has support both for ENS and IPFS.

Wrapping Up

Learning about ENS, Handshake, and IPFS was a lot of fun, and while I highly doubt that web3 is “the future”, these technologies have a lot of offer for the future of the Internet. I am particularly fond of IPFS as it reminds me of Bittorrent but without having to setup a torrent/magnet link and seed. Getting started with IPFS is easy, and hosting your own IPFS node locally is a quick and free way to participate in the distributed web.

I really understood the power of IPFS when I saw the different ways you could use it as a Gateway, enabling any application that uses http to access content on IPFS. This really shines with git and package repositories, see OpenBSD 6.9 packages using IPFS for a real-world application.

Forwarding gpg-agent Over SSH

Mon, 27 Dec 2021 00:00:00 +0000

Intro

Basic notes from setting up gpg-agent forwarding between a MacOS and Debian Linux system.

Client System

Assuming system is running MacOS install gpg and pinentry (GPG password prompt tool) using Homebrew,

brew install gnupg pinentry-mac

Edit ~/.gnupg/gpg-agent.conf and make sure that ${HOME} is the full path to your users home dir, eg /Users/$USER, this must match what’s setup in RemoteForward later,

default-cache-ttl 600
max-cache-ttl 7200
enable-ssh-support
pinentry-program /usr/local/bin/pinentry-mac
extra-socket $HOME/.gnupg/S.gpg-agent.extra

~/.gnupg/gpg.conf (where $GPG_KEY is the fingerprint of the GPG key to use)

default-key $GPG_KEY
personal-digest-preferences SHA512
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
no-emit-version

Edit ~/.ssh/config and setup a RemoteForward, this is important since the forward is required in order to communicate over a socket. Make sure the $UID and $USER on the remote and local system are set accordingly, as these will differ depending on the OS and login.

Also double check the socket names that they match up from ~/.gnupg/gpg-agent.conf and ~/.ssh/config.

~/.ssh/config

Host $REMOTE_IP
   ForwardAgent yes
   Compression yes
   ForwardX11 yes
   RemoteForward /run/user/$UID/gnupg/S.gpg-agent /Users/${USER}/.gnupg/S.gpg-agent.extra

Remote System

Update /etc/ssh/sshd_config (or wherever it is depending on your OS) configuration to include StreamLocalBindUnlink yes and restart sshd This option will,

Specifies whether to remove an existing Unix-domain socket file for local or remote port forwarding before creating a new one. If the socket file already exists and StreamLocalBindUnlink is not enabled, ssh will be unable to forward the port to the Unix-domain socket file. This option is only used for port forwarding to a Unix-domain socket file.

Troubleshooting gpg-agent

Sometimes StreamLocalBindUnlink yes doesn’t work and the client agent needs restarted and sockets removed from the remote system,

Restart the agent on the client system,

gpg-connect-agent reloadagent /bye

Remove the socket on the remote system,

rm /run/user/1000/gnupg/S.gpg-agent

ssh back into the remote system and gpg-agent forwarding should work again.

References

Remote gpg-agent Via ssh Forwarding

Gemini Capsule in a FreeBSD Jail running on a RaspberryPi

Sun, 25 Apr 2021 00:00:00 +0000

Intro

With the recent release of FreeBSD 13, I wanted to test it out on a spare RaspberryPi 3 that was part of my old Kubernetes cluster.

In particular, FreeBSD Jails have always interested me, although I’ve never used them in practice. Over the years I’ve managed operating system virtualization through Solaris Zones and Docker containers, and Jails seem like and good middle ground between the two - easier to manage than zones and closer to the OS than Docker.

I also want to run my own Gemini capsule locally to use some of the features that my other hosted capsules don’t have (like SCGI/CGI) and setting up a capsule in a Jail is a good way to learn both at the same time.

Installing FreeBSD on a RaspberryPi

Installing FreeBSD on a RaspberryPi is relatively easy, downloading the FreeBSD 13 RPI image and booting from the SD card to get started. Everything will come up automatically, and you can ssh in with the default user:pass of freebsd:freebsd.

A few post-install things I did to secure the host more,

Add another non-root user other than freebsd
Disable password logins and require ssh-keys
Setup doas for new user
Remove the freebsd user with doas rmuser freebsd
Set strong root password

Setting up NTP

Since the RPI doesn’t have a real-time clock, setting up NTP is crucial for accurate time, which if not set can cause all sorts of issues with TLS and other commands.

# Enabe ntpd
host$ echo 'ntpd_enable="YES"' | doas tee -a /etc/rc.conf

# Force sync time
host$ doas ntpdate pool.ntp.org

# Start ntpd
host$ doas service ntpd onestart

Setting up the Jail

Creating the Jail

The Jails guide is straightforward, but contains two different methods of configuring jails. The built-in jail commands or ezjail. I ended up using ezjail which seems more robust and featureful.

Following the instructions first add the second loopback interface,

host$ echo 'cloned_interfaces="lo1"' | doas tee -a /etc/rc.conf
host$ doas service netif cloneup

Then install ezjail and a few other packages we’ll need later on,

host$ doas pkg install ezjail ca_root_nss openssl
host$ echo 'ezjail_enable="YES"' | doas tee -a /etc/rc.conf

Create a new jail named thesours, using the new second loopback and a new LAN IP on the interface em0,

host$ doas ezjail-admin create thesours 'lo1|127.0.1.1,em0|192.168.7.223'

This installs a FreeBSD 13 (default version is the host version) jail filesystem in /usr/jails/thesours/ and will take a while to download and extract.

Once complete, list the new jail,

host$ doas ezjail-admin list
STA JID  IP              Hostname                       Root Directory
--- ---- --------------- ------------------------------ ------------------------
DR  1    127.0.1.1       thesours                       /usr/jails/thesours
    1    ue0|192.168.7.223

Setting up the Jail

Now that there’s a running jail, connect to it’s console to start setting it up.

doas ezjail-admin console thesours

Many of the directories are shared with the basejail and are immutable, but adding users and packages, configuring services, and /etc are all independent of the host OS.

Add a new non-root user using adduser, install doas and set up this user for root privileges. Enabling sshd also allows ssh sessions into the jail,

jail$ echo 'sshd_enable="YES"' | doas tee -a /etc/rc.conf

Setting up a Gemini Capsule

Now that the jail is setup, the next step is installing and configuring the Gemini server Molly Brown, which has a lot of features such as ~ support for user gemini folders and SCGI/CGI scripting.

Building Molly Brown

Molly Brown requires go, which was built in the host and not the jail in order to keep jail packages to a minimum.

host$ doas pkg install go

Build Molly Brown,

host$ mkdir ~/go
host$ export GOPATH=~/go
host$ go get tildegit.org/solderpunk/molly-brown

Copy the resulting ~/go/bin/molly-brown binary to the jail,

host$ doas cp molly-brown /usr/jails/thesours/usr/local/sbin/

Also create the TLS certs that molly brown will require later, and copy them to the jail,

host$ doas mkdir -p /usr/jails/thesours/etc/ssl/gemini/
host$ cd /usr/jails/thesours/etc/ssl/gemini/
host$ openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 1826 -nodes -subj '/CN=thesours.ecliptik.com'

Go back into the jail and setup a few configurations for Molly Brown with the following assumptions,

Config in /etc/molly.conf
Logs in /var/log/molly
TLS certs in /usr/jails/thesours/etc/ssl/gemini
Document root in /var/gemini/
Run as daemon

Create the required paths, create/copy files and set the proper permissions for daemon,

jail$ doas mkdir -p /var/log/molly /var/gemini/
jail$ doas chown -R daemon:daemon /var/log/molly /usr/jails/thesours/etc/ssl/gemini /var/gemini/

Molly Brown Configuration

Create configuration in /etc/molly.conf,

## Molly basic settings
Port = 1965
Hostname = "thesours.ecliptik.com"
CertPath = "/etc/ssl/gemini/cert.pem"
KeyPath = "/etc/ssl/gemini/key.pem"
DocBase = "/var/gemini/"
HomeDocBase = "users"
GeminiExt = "gmi"
DefaultLang = "en"
AccessLog = "/var/log/molly/access.log"
ErrorLog = "/var/log/molly/error.log"

Creating a Molly Brown Service

Create etc/rc.d/molly to manage the service and have it start when the jail does. It will run as the daemon user to improve security.

#!/bin/sh
#
# $FreeBSD$
#

# PROVIDE: molly
# REQUIRE: networking
# KEYWORD: shutdown

. /etc/rc.subr

name="molly"
desc="Gemini Protocol daemon"
rcvar="molly_enable"
command="/usr/local/sbin/molly-brown"
command_args="-c /etc/molly.conf"
molly_brown_user="daemon"
pidfile="/var/run/${name}.pid"
required_files="/etc/molly.conf"

start_cmd="molly_start"
stop_cmd="molly_stop"
status_cmd="molly_status"

molly_start() {
        /usr/sbin/daemon -P ${pidfile} -r -f -u $molly_brown_user $command
}

molly_stop() {
        if [ -e "${pidfile}" ]; then
                kill -s TERM `cat ${pidfile}`
        else
                echo "${name} is not running"
        fi

}

molly_status() {
        if [ -e "${pidfile}" ]; then
                echo "${name} is running as pid `cat ${pidfile}`"
        else
                echo "${name} is not running"
        fi
}

load_rc_config $name
run_rc_command "$1"

Enable the service,

jail$ echo 'molly_enable="YES"' | doas tee -a /etc/rc.conf

Add a default /var/gemini/index.gmi file with some basic gemtext and start the molly service,

jail$ doas service molly start

Running Example

The gemini capsule gemini://thesours.ecliptik.com is running Molly Brown in a FreeBSD jail.

Pocket CHIP Terminal Dashboard

Sun, 04 Apr 2021 00:00:00 +0000

Intro

When I first got my Pocket C.H.I.P. one of the first thoughts I had was to use it as sort of a mini-desktop terminal to display things like weather, new mail, etc. After doing some other tinkering with it first, it has been on my desk the last couple of weeks displaying the following information,

Latest local toot in Fosstodon using Toot
Top 10 Hacker News posts using haxor-news
Current weather from wttr.in
Current time with tty-clock
Currenly playing track on Spotify using walt-grover

Pocket C.H.I.P. Terminal Dashboard

Setup

Tmux is the heart of the setup, with each applet in it’s own terminal pane and then borders turned off so it looks like a single seamless screen. Running in tmux has the added benefit of detaching the dashboard, like when you want to watch some vaporwave on the framebuffer or sharing the screen from ssh for remote control.

The tools used in these panes are a combination of watch to refresh every 60 seconds or a small shell script. I attempted to use watch for everything, but some commands didn’t work well with the ASCII escape codes even with the --color option.

It’s using tmuxinator to save the layout and restore the dashboard after a reboot.

Tmuxinator config in ~/.config/tmuxinator/chip.yaml

name: chip
root: ~/

windows:
  - CHIP:
      layout: 7bd9,60x33,0,0[60x7,0,0,0,60x13,0,8,3,60x7,0,22{27x7,0,22,4,32x7,28,22,9},60x3,0,30,6]
      panes:
        - watch -n60 -t --color "toot timeline --local --public --count 1 --once | sed '/^$/d' | grep -v '─────────────────' | grep -v 'ID ' | sed 's/\s\{2,\}/_TOKEN_/' | awk -F_TOKEN_ {'print \$1'}"
        - watch -n60 -t --color "hn top 10 | head -n -3 | sed 's/^[ \t]*//' | grep -v 'points by' | awk -F\( {'print \$1'} | sed -e 's/\.\s\s\s/. /g'"
        - /home/chip/bin/weather.sh
        - bin/tty-clock -m -B -D -C 5
        - watch -n120 -t --color "/home/chip/bin/spotify/spotify.rb"
  - amfora:
      - amfora
  - serial:

Additional configuration includes updating the pocketchip-batt utility to better display charging and how much battery is remaining and putting it and the CHIPs IP address into the right status of the tmux toolbar.

Terminal blanking is turned off so the display is always on.

setterm -blank 0

Wifi powersave feature is turned off since there were issues with it losing DNS and occasional loss of network connectivity

sudo /sbin/iw dev wlan0 set power_save off

Tmux config in ~/.tmux.conf,

#Switch Windows
bind-key n next-window
bind-key m previous-window

#Set 256 colors
set -g default-terminal "screen-256color"

# start window numbering at 1
set -g base-index 1

# start pane numbering at 1
set -g pane-base-index 1

#Update default binding of `Enter` to also use copy-pipe
unbind -T copy-mode-vi Enter

#Clock
set-option -g clock-mode-colour yellow

#Switch panels with vi keybindings
bind k selectp -U # switch to panel Up
bind j selectp -D # switch to panel Down
bind h selectp -L # switch to panel Left
bind l selectp -R # switch to panel Right

set-option -g status on
set-option -g status-interval 1
set-option -g status-keys vi
set-option -g status-position bottom

set-option -g visual-activity on
set-window-option -g status-left ""
set-window-option -g monitor-activity on
set-window-option -g window-status-activity-style "none"
set-option -g status-right "#( ~/bin/right-status.sh )"

#### COLOUR (Solarized light)

# default statusbar colors
set-option -g status-style fg=yellow,bg=black #yellow and base02

# default window title colors
set-window-option -g window-status-style fg=brightblue,bg=default #base0 and default
#set-window-option -g window-status-style dim

# active window title colors
set-window-option -g window-status-current-style fg=brightred,bg=default #orange and default
#set-window-option -g window-status-current-style bright

# pane border
set-option -g pane-border-style fg=black #base02
set-option -g pane-active-border-style fg=black #base01

# message text
set-option -g message-style fg=brightred,bg=black #orange and base01

# pane number display
set-option -g display-panes-active-colour blue #blue
set-option -g display-panes-colour brightred #orange

# clock
set-window-option -g clock-mode-colour green #green

# bell
set-window-option -g window-status-bell-style fg=black,bg=red #base02, red

Vaporwave in Pocket C.H.I.P. Framebuffer

Fri, 19 Mar 2021 00:00:00 +0000

Intro

In the ever expanding ways to hack my Pocket C.H.I.P., and my recent discovery of Vaporwave, I couldn’t help but combine the two and have a looping music video device on my desktop. Note this is not running in X, but in the console framebuffer, which gives it more ＡＥＳＴＨＥＴＩＣＳ.

NEON PALM MALL in C.H.I.P. Framebuffer

Required Software

The C.H.I.P. is fully upgraded to Debian Buster, and there were some oddities with getting dpkg sorted out, so the package installs may not work exactly as defined here but are a general guide. It’s also booting into the console framebuffer and not X, so there’s no desktop environment or window manager running.

The following tools are used,

mplayer, for playback with framebuffer and armhf support
alsa-utils, specifically alsamixer to control volume from console
youtube-dl, download video+audio from youtube
ffmpeg, combine video+audio from youtube-dl

Install packages,

$ sudo apt-get update
$ sudo apt-get install -y ffmpeg mplayer alsa-utils

Install youtube-dl,

$ sudo curl -L https://yt-dl.org/downloads/latest/youtube-dl -o /usr/local/bin/youtube-dl
$ sudo chmod a+rx /usr/local/bin/youtube-dl

Downloading Videos

Using youtube-dl, download a Vaporwave video. The Pocket C.H.I.P. is very particular about the screen resolution and codec of the video. Anything larger than the C.H.I.P. screen (480×272) will give an error, and some codecs won’t play. I found the following format combination works best for video playback.

resolution: 320x240@240p
container: mp4
codec: avc1

For this example we’ll save NEON PALM MALL (Vaporwave Mix + Video).

First, use the -F argument to display the list of available formats and choose the one that best matches,

$ youtube-dl -F https://www.youtube.com/watch?v=FZUfiW3W1KY
[youtube] FZUfiW3W1KY: Downloading webpage
[info] Available formats for FZUfiW3W1KY:
format code  extension  resolution note
        webm       audio only tiny   48k , webm_dash container, opus @ 48k (48000Hz), 18.74MiB
        webm       audio only tiny   64k , webm_dash container, opus @ 64k (48000Hz), 24.76MiB
        webm       audio only tiny  127k , webm_dash container, opus @127k (48000Hz), 48.90MiB
        m4a        audio only tiny  129k , m4a_dash container, mp4a.40.2@129k (44100Hz), 49.55MiB
        mp4        192x144    144p   51k , mp4_dash container, av01.0.00M.08@  51k, 25fps, video only, 19.82MiB
        mp4        192x144    144p   53k , mp4_dash container, avc1.4d400b@  53k, 25fps, video only, 20.33MiB
        webm       192x144    144p   67k , webm_dash container, vp9@  67k, 25fps, video only, 25.81MiB
        mp4        320x240    240p   93k , mp4_dash container, avc1.4d400d@  93k, 25fps, video only, 35.73MiB
        mp4        320x240    240p  106k , mp4_dash container, av01.0.00M.08@ 106k, 25fps, video only, 40.57MiB
        webm       320x240    240p  126k , webm_dash container, vp9@ 126k, 25fps, video only, 48.47MiB
        mp4        480x360    360p  188k , mp4_dash container, av01.0.01M.08@ 188k, 25fps, video only, 72.01MiB
        mp4        480x360    360p  221k , mp4_dash container, avc1.4d4015@ 221k, 25fps, video only, 84.73MiB
        webm       480x360    360p  229k , webm_dash container, vp9@ 229k, 25fps, video only, 87.72MiB
        mp4        640x480    480p  334k , mp4_dash container, av01.0.04M.08@ 334k, 25fps, video only, 127.98MiB
        webm       640x480    480p  396k , webm_dash container, vp9@ 396k, 25fps, video only, 151.83MiB
        mp4        640x480    480p  430k , mp4_dash container, avc1.4d401e@ 430k, 25fps, video only, 164.88MiB
         mp4        480x360    360p  435k , avc1.42001E, 25fps, mp4a.40.2 (44100Hz), 166.58MiB (best)

Find the best format to fit the requirements above, in this example format code 133 will work best for video.

Download the video and audio (use bestaudio to automatically choose) and merge into an mp4 container,

$ youtube-dl -f 133+bestaudio --merge-output-format mp4  https://www.youtube.com/watch?v=FZUfiW3W1KY
[youtube] FZUfiW3W1KY: Downloading webpage
[download] NEON PALM MALL (Vaporwave Mix + Video)-FZUfiW3W1KY.f133.mp4 has already been downloaded
[download] 100% of 35.73MiB
[download] Destination: NEON PALM MALL (Vaporwave Mix + Video)-FZUfiW3W1KY.f140.m4a
[download] 100% of 49.55MiB in 00:19
[ffmpeg] Merging formats into "NEON PALM MALL (Vaporwave Mix + Video)-FZUfiW3W1KY.mp4"
Deleting original file NEON PALM MALL (Vaporwave Mix + Video)-FZUfiW3W1KY.f133.mp4 (pass -k to keep)
Deleting original file NEON PALM MALL (Vaporwave Mix + Video)-FZUfiW3W1KY.f140.m4a (pass -k to keep)

Playback

By default the console will blank after a period of time, turn that off so the screen is always on,

$ setterm -blank 0

Use mplayer to playback the video, the fbdev2 device must be used, trying directfb for fbdev will result in an mplayer playback error.

$ mplayer -vo fbdev2 -fs -zoom NEON\ PALM\ MALL\ \(Vaporwave\ Mix\ +\ Video\)-FZUfiW3W1KY.mp4

If sound is too loud or quiet, ssh into the C.H.I.P. and use alsamixer to adjust the volume.

Keyboard controls for mplayer will work on the C.H.I.P. keyboard, with q to quit and arrow keys to browse the video.

Notes

Overall resource usage isn’t bad, about 25% CPU when playing the video back with just a slight audio glitch now and then. If CPU gets stressed, audio and playback will glitch even more. There are ways to tune mplayer to perform better on lower end systems like the C.H.I.P., but I won’t go into detail here as there are many guides out there.

Depending on the video, the mp4 output format may not work and give a ERROR: Stream #1:0 -> #0:1 (copy) when trying to merge video+audio, using mkv for the output format is a workaround.

Running dnscrypt-proxy on OpenBSD

Fri, 12 Mar 2021 00:00:00 +0000

Intro

A couple of weeks ago I took a spare RaspberryPi 3 leftover from my old k3s cluster and installed OpenBSD on it using my Pocket C.H.I.P.. While getting it installed was fun, I wanted to do more with it and use it on a more regular basis to continue learning about OpenBSD in general.

OpenBSD 4.9 Sticker on RaspberryPi 3

I’ve had a Pi-hole running on an older Raspberry Pi B with Debian for a few years, but wanted a few additional features, notably using DNSCRYPT to encrypt DNS traffic so our ISP wouldn’t be able to use it for anything and/or using DNS-over-HTTPS. I originally was going to setup Pi-hole on the new OpenBSD Pi, but quickly found out that Pi-hole doesn’t work on OpenBSD.

A quick search, turned up an excellent Pi-hole on OpenBSD guide, which cleverly uses the vmm hypervisor to run a Linux VM and install Pi-hole there. This however was also a dead-end since the guide was assuming an x86 install and not arm64. Unfortunately it seems that the OpenBSD arm64 port doesn’t have vmm so installing a VM wouldn’t work, and probably wasn’t a great idea for performance anyway.

The guide did include a reference to using dnscrypt-proxy, which is available as a package for OpenBSD arm64. Reading through the features it can do almost everything Pi-hole can and more,

Local DNS caching
Filtering for Ads and Malware
DNSCRYPT
DNS-over-HTTPS
Anonymized DNS

The only thing that was missing was the nicer GUI interface of Pi-hole, but I rarely used that anyway after initially setting it up and was more eye-candy that utilitarian. I decided to setup dnscrypt-proxy to mimic the blocking capabilities of the Pi-hole and enabled some more of the advanced features.

Installing dnscrypt-proxy on OpenBSD

Because dnscrypt-proxy is in the OpenBSD package repo, installation was a simple as,

$ doas pkg_add dnscrypt-proxy
quirks-3.442 signed on 2021-03-09T20:09:44Z
dnscrypt-proxy-2.0.44: ok

This installs version 2.0.44 which is slightly older than upstream, which is 2.0.45. Looking in openbsd snapshots, 2.0.45 is packaged in preparation for OpenBSD 6.9 and can install without issue on 6.8.

$ wget https://cdn.openbsd.org/pub/OpenBSD/snapshots/packages/aarch64/dnscrypt-proxy-2.0.45.tgz
$ doas pkg_add dnscrypt-proxy-2.0.45.tgz

Configuring dnscrypt-proxy on OpenBSD

The default configuration is in /etc/dnscrypt-proxy.toml, and will need to be updated before starting dnscrypt-proxy since it will give one of these errors,

[FATAL] Unable to clone file descriptor: [bad file descriptor]

[FATAL] Duplicated file descriptors are above base

It also contains deprecated references to blacklist and whitelist which will needs replacing. A known good configuration to start with is here: https://github.com/DNSCrypt/dnscrypt-proxy/blob/master/dnscrypt-proxy/example-dnscrypt-proxy.toml.

Cloudflare DNS-over-HTTPS

I am using the Cloudflare 1.1.1.1 DNS revolvers since they provide DNS-over-HTTPS and their response times are extremely fast. My ISP and network is also setup for IPv6, and that is configured to allow IPv6 clients and lookups. For fallback DNS, Quad9 is used since it’s separate from Cloudflare and has a relatively decent privacy and security features.

#Use cloudflare DNS
server_names = ['cloudflare', 'cloudflare-ipv6']

#Listen on local and LAN addresses for DNS
listen_addresses = ['127.0.0.1:53', '[::1]:53', '192.168.7.221:53', '[fd82:738a:110d:1:2259:a6b:cd78:733b]:53']
max_clients = 250
user_name = '_dnscrypt-proxy'

#Enable ipv4 and ipv6
ipv4_servers = true
ipv6_servers = true

#Include resolvers with the following configuration
dnscrypt_servers = true
doh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = true

#Allow TCP and UDP
force_tcp = false
timeout = 2500
keepalive = 30

#Logging
log_level = 2
use_syslog = true

#Certs
cert_refresh_delay = 240
dnscrypt_ephemeral_keys = true
tls_disable_session_tickets = true

#Fallback to a non CloudFlare DNS if things aren't happy
fallback_resolver = '9.9.9.9:53'
ignore_system_dns = false

Sources

To reference revolvers and relays, sources are used to find publicly resources. These are setup by default in dnscrypt-proxy, but I’ve added a few changes like caching them to /var/dnscrypt-proxy and point to the latest v3.

#Sources for resolvers and relays
[sources]
  [sources.'public-resolvers']
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  cache_file = '/var/dnscrypt-proxy/public-resolvers.md'
  refresh_delay = 72

  [sources.'relays']
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/relays.md', 'https://ipv6.download.dnscr
ypt.info/resolvers-list/v3/relays.md', 'https://download.dnscrypt.net/resolvers-list/v3/relays.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  cache_file = '/var/dnscrypt-proxy/relays.md'
  refresh_delay = 72
  prefix = ''

Block and Allow Lists

Another powerful features of dnscrypt-proxy are filters, which can take on the role Pi-hole was doing with having a list of domains to block for ads, malware, and other reasons. To generate these lists, the generate-domains-blocklist.py is used.

I took the blocklists that Pi-hole was using, and created a domains-blocklist.conf configuration to match, which gives it the same blocking sources as the Pi-hole was.

# Local additions
file:domains-blocklist-local-additions.txt

# Peter Lowe's Ad and tracking server list
https://pgl.yoyo.org/adservers/serverlist.php?hostformat=nohtml

# Ads filter list by Disconnect
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt

# Basic tracking list by Disconnect
https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt

# Sysctl list (ads)
http://sysctl.org/cameleon/hosts

# BarbBlock list (spurious and invalid DMCA takedowns)
https://paulgb.github.io/BarbBlock/blacklists/domain-list.txt

# NoTracking's list - blocking ads, trackers and other online garbage
https://raw.githubusercontent.com/notracking/hosts-blocklists/master/dnscrypt-proxy/dnscrypt-proxy.blacklist.txt

# Geoffrey Frogeye's block list of first-party trackers - https://hostfiles.frogeye.fr/
https://hostfiles.frogeye.fr/firstparty-trackers.txt

# Steven Black hosts file
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

# Pihole Lists
https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist
https://raw.githubusercontent.com/nickspaargaren/pihole-google/master/categories/androidparsed
https://raw.githubusercontent.com/nickspaargaren/pihole-google/master/categories/analyticsparsed
https://raw.githubusercontent.com/anudeepND/blacklist/master/facebook.txt

This file also references domains-blocklist-local-additions.txt, which is setup to protect against DNS rebinding protection,

# Localhost rebinding protection
0.0.0
0.0.*

# RFC1918 rebinding protection
*
16.*
17.*
18.*
19.*
20.*
21.*
22.*
23.*
24.*
25.*
26.*
27.*
28.*
29.*
30.*
31.*
168.*

The generate-domains-blocklist.py script will also require the files domains-allowlist.txt and domains-time-restricted.txt, which I just created as empty files to allow the blocklist creation to proceed

$ touch domains-time-restricted.txt
$ touch domains-allowlist.txt

Generating the blocklist can be done manually or as a cronjob,

$ python3 generate-domains-blocklist.py -o blocklist.txt

Since I use Plex, work for a Account Based Marketing company, and Google reCaptcha is usually in blocklists, I created an allowlist.txt as well,

plex.direct
demandbase.com
recaptcha.google.com
gc.zgo.a

Putting this all together into the /etc/dnscrypt-proxy.toml blocking configuration,

#Blocking configuration
[blocked_names]
  ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file)
  blocked_names_file = '/home/micheal/dnscrypt-proxy/blocklist.txt'

  log_file = '/var/tmp/blocked.log'
  log_format = 'tsv'

#Allow configuration
[allowed_names]
  ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file)
  allowed_names_file = '/home/micheal/dnscrypt-proxy/allowlist.txt'

Anonymized DNS

One of the features I liked about dnscrypt-proxy is it offers is Anonymized DNS, which I setup to test out.

#Anonymized DNS relays
[anonymized_dns]
routes = [
    { server_name='zackptg5-us-il-ipv4', via=['anon-cs-usca', 'anon-cs-usga'] },
    { server_name='freetsa.org-ipv6', via=['anon-zackptg5-us-il-ipv6', 'anon-acsacsar-ams-ipv6'] }
]

While this did work well, unfortunately the DNS query times were consistently 200ms+, which can appear as lag when browsing things. Since DNS-over-HTTPS is encrypted and filtering is setup, this was more of a nice-to-have instead of a requirements, so I ended up commenting it out. If/when Cloudflare provides DNSCRYPT I may re-visit it and see if response times have improved.

Local DNS-over-HTTPS

Another feature that Pi-hole didn’t support was DNS-over-HTTPS both for resolving and for serving requests locally. This is something built-in to dnscrypt-proxy with Local DoH that Firefox support for DoH can then use. By default Firefox will use Cloudflare DoH directly and was previously bypassing the Pi-hole, not getting the filtering features the rest of the network was. Now it can use the same filtering and continue to use DoH.

To setup DoH on dnscrypt-proxy, a self-signed certificate is required,

openssl req -x509 -nodes -newkey rsa:2048 -days 5000 -sha256 -keyout localhost.pem -out localhost.pem

This certificate is then used to listen on IPv4 and IPv6 addresses for DoH on port 3000,

#DNS over HTTPS configuration
[local_doh]
  listen_addresses = ['127.0.0.1:3000', '[::1]:3000', '192.168.7.221:3000', '[fd82:738a:110d:1:2259:a6b:cd78:733b]:3000']
  path = "/dns-query"
  cert_file = "/home/micheal/dnscrypt-proxy/localhost.pem"
  cert_key_file = "/home/micheal/dnscrypt-proxy/localhost.pem"

Firefox is then configured to use dnscrypt-proxy, for example over IPv6, https://fd82:738a:110d:1:2259:a6b:cd78:733b:3000/dns-query.

Enabling dnscrypt-proxy

Now that the configuration is all setup and dnscrypt-proxy is installed on OpenBSD, enable the service and start it,

$ doas rcctl enable dnscrypt_proxy
$ doas rcctl start dnscrypt_proxy

This should start and /var/log/messages will show it starting,

Mar 12 11:15:59 majora dnscrypt-proxy[1888]: dnscrypt-proxy 2.0.45
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Network connectivity detected
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Dropping privileges
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Network connectivity detected
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to 127.0.0.1:53 [UDP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to 127.0.0.1:53 [TCP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to [::1]:53 [UDP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to [::1]:53 [TCP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to 192.168.7.221:53 [UDP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to 192.168.7.221:53 [TCP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to [fd82:738a:110d:1:2259:a6b:cd78:733b]:53 [UDP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to [fd82:738a:110d:1:2259:a6b:cd78:733b]:53 [TCP]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to https://127.0.0.1:3000/dns-query [DoH]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to https://[::1]:3000/dns-query [DoH]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to https://192.168.7.221:3000/dns-query [DoH]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Now listening to https://[fd82:738a:110d:1:2259:a6b:cd78:733b]:3000/dns-query [DoH]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Source [public-resolvers] loaded
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Source [relays] loaded
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Loading the set of whitelisting rules from [/home/micheal/dnscrypt-proxy/allowlist.txt]
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Firefox workaround initialized
Mar 12 11:15:59 majora dnscrypt-proxy[1888]: Loading the set of blocking rules from [/home/micheal/dnscrypt-proxy/blocklist.txt]
Mar 12 11:16:04 majora dnscrypt-proxy[1888]: [cloudflare-ipv6] OK (DoH) - rtt: 14ms
Mar 12 11:16:04 majora dnscrypt-proxy[1888]: [cloudflare] OK (DoH) - rtt: 83ms
Mar 12 11:16:04 majora dnscrypt-proxy[1888]: Sorted latencies:
Mar 12 11:16:04 majora dnscrypt-proxy[1888]: -    14ms cloudflare-ipv6
Mar 12 11:16:04 majora dnscrypt-proxy[1888]: -    83ms cloudflare
Mar 12 11:16:04 majora dnscrypt-proxy[1888]: Server with the lowest initial latency: cloudflare-ipv6 (rtt: 14ms)

Logging

Initially to test things are working well, setup the query logs to write to /var/tmp/query.log,

#Query logging, commented out unless for troubleshooting
[query_log]
  file = '/var/tmp/query.log'
  format = 'tsv'

As requests come in they will show up here. Blocked requests will also show up in /var/tmp/blocked.log.

Depending on the number of devices making DNS requests, the query.log can get quite large it’s recommended to keep it enabled when initially testing something, and turning it off when not in use. Leaving blocked.log on is a good idea to help know what to add to a allowlist.txt in case something is blocked that you want to allow.

Since a Raspberry Pi is most likely using an MicroSD card and by default OpenBSD will mount /tmp as a filesystem, it’s a good idea to to set /tmp as a memory filesystem to avoid excessive writes to the SD Card.

OpenBSD has the mfs filesytem that can be used to mount a filesystem in-memory to help avoid this,

mount_mfs is used to build a file system in virtual memory and then mount it on a specified node.

Setup /tmp as mfs, first by unmounting it. This may require killing sndio processes and using the console instead of ssh as it will give a resource busy error when trying to unmount /tmp.

$ doas umount /tmp
$ chmod 1777 /tmp

In /etc/fstab, comment out the old /tmp mount and add the mfs mount,

#1400ced5c75f17ee.d /tmp ffs rw,nodev,nosuid 1 2
swap /tmp mfs rw,nodev,nosuid,-s=256M 0 0

Reboot, and /tmp will now show up as a mfs type,

$ mount | grep /tmp
mfs:73353 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=524288 512-blocks)

Full Configuration

Here is the full configuration of /etc/dnscrypt-proxy combined from all the snippets above,

#Use cloudflare DNS
server_names = ['cloudflare', 'cloudflare-ipv6']

#Listen on local and LAN addresses for DNS
listen_addresses = ['127.0.0.1:53', '[::1]:53', '192.168.7.221:53', '[fd82:738a:110d:1:2259:a6b:cd78:733b]:53']
max_clients = 250
user_name = '_dnscrypt-proxy'

#Enable ipv4 and ipv6
ipv4_servers = true
ipv6_servers = true

#Include resolvers with the following configuration
dnscrypt_servers = true
doh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = true

#Allow TCP and UDP
force_tcp = false
timeout = 2500
keepalive = 30

#Logging
log_level = 2
use_syslog = true

#Certs
cert_refresh_delay = 240
dnscrypt_ephemeral_keys = true
tls_disable_session_tickets = true

#Fallback to a non CloudFlare DNS if things arne't happy
fallback_resolver = '9.9.9.9:53'
ignore_system_dns = false

#[query_log]
#  file = '/var/tmp/query.log'
#  format = 'tsv'

#Sources for resolvers and relays
[sources]
  [sources.'public-resolvers']
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v3/public-resolvers.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  cache_file = '/var/dnscrypt-proxy/public-resolvers.md'
  refresh_delay = 72

  [sources.'relays']
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v3/relays.md', 'https://download.dnscrypt.info/resolvers-list/v3/relays.md', 'https://ipv6.download.dnscrypt.info/resolvers-list/v3/relays.md', 'https://download.dnscrypt.net/resolvers-list/v3/relays.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  cache_file = '/var/dnscrypt-proxy/relays.md'
  refresh_delay = 72
  prefix = ''

#Blocking configuration
[blocked_names]
  ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file)
  blocked_names_file = '/home/micheal/dnscrypt-proxy/blocklist.txt'

  log_file = '/var/tmp/blocked.log'
  log_format = 'tsv'

#Allow configuration
[allowed_names]
  ## Path to the file of blocking rules (absolute, or relative to the same directory as the executable file)
  allowed_names_file = '/home/micheal/dnscrypt-proxy/allowlist.txt'

#Anonymized DNS relays
#[anonymized_dns]
#routes = [
#    { server_name='zackptg5-us-il-ipv4', via=['anon-cs-usca', 'anon-cs-usga'] },
#    { server_name='freetsa.org-ipv6', via=['anon-zackptg5-us-il-ipv6', 'anon-acsacsar-ams-ipv6'] }
#]

#DNS over HTTPS configuration
[local_doh]
  listen_addresses = ['127.0.0.1:3000', '[::1]:3000', '192.168.7.221:3000', '[fd82:738a:110d:1:2259:a6b:cd78:733b]:3000']
  path = "/dns-query"
  cert_file = "/home/micheal/dnscrypt-proxy/localhost.pem"
  cert_key_file = "/home/micheal/dnscrypt-proxy/localhost.pem"

CHIP Serial Console

Wed, 03 Mar 2021 00:00:00 +0000

Intro

Since getting a Pocket C.H.I.P, I’m looking for more ways to use it outside the original configuration, and came across a Hackernoon post on using a CHIP as a serial console.

I also wanted to install OpenBSD onto a RaspberryPi 3 - unlike most RaspberryPi installs where a sdcard image is flashed and boots up - OpenBSD requires following the full installation procedure on the console. Sure you could hook up it up to HDMI and a USB keyboard, but what’s the fun in that? So I took the oppurtunity to do both.

Hardware

Following the Hackernoon post, and using the RPI GPIO documentation, I soldered some lead pins onto the CHIPs 5V, GND, TXD and RXD breakout at the top, made some basic GPIO wires and hooked it all up. Using the 5V has the added benefit of powering the RaspberryPi from the CHIP battery, which in makes both of them portable.

C.H.I.P. Serial Console

Software

To connect via serial console, first release /dev/ttyS0 from systemd,

sudo systemctl stop serial-getty@ttyS0

Many articles suggest using minicom as a serial console, but I prefer screen, and used it for years when working in datacenters.

The OpenBSD console uses a baud rate of 115100 and transmission of eight bits per byte cs8. Connecting requires sudo, even if your chip user is in the tty group due to some udev/systemd permissions wonkiness.

sudo screen /dev/ttyS0 115200,cs8

The serial console works well, although occasionally there is missing data, but after remembering how to use the OpenBSD disk partitioner - OpenBSD 6.8 was running on a RaspberryPi 3. Once the installation is complete, if DHCP was setup during install, connecting to it over ssh is trivial and no longer requires the serial console.

Conclusion

While as much fun as this is, it’s not nearly as useful as it could have been years ago when troubleshooting misbehaving Sun Netra or Sun Fire systems. For now though it’s a good hack, useful in the right circumstances, and just looks cool.

Pocket C.H.I.P.

Wed, 24 Feb 2021 00:00:00 +0000

Intro

Recently I got a Pocket C.H.I.P. with the idea of making it mini terminal on my desk, displaying things like weather, new email, new mastodon toots, etc. It comes pre-loaded with some basic software: terminal, pico8, and a few other utilities. Because it was released in 2017 and the demise of the original Next Thing the software on it is out-of-date, running Debian 8 and an older version of pico8.

Pocket C.H.I.P.

I wanted to updated it to at least Debian 10, and found a working guide which follows the basic Debian upgrade process as well as some fixes for common issues like Xorg configs and updating wifi settings.

Unfortunately this broke a few other things that weren’t listed in the guide, like the FN keys no longer working on the built-in keyboard and pico8 failing to start. I spent some time tackling these issues and now have a fully working Debian 10 Pocket C.H.I.P. with pico8 and a functioning keyboard.

Fixing FN Keys

After upgrading to Debian 10, the FN keys on the C.H.I.P. build-in keyboard will no longer work. Fix this by sourcing the keymap in /home/chip/.xinitrc and restarting C.H.I.P. for xorg to load the xmodmap every time.

[[ -f /home/chip/.Xmodmap ]] && xmodmap /home/chip/.Xmodmap

For reference /home/chip/.Xmodmap is,

keycode 10 = 1 exclam F1 exclam
keycode 11 = 2 at F2 at
keycode 12 = 3 numbersign F3 numbersign
keycode 13 = 4 dollar F4 dollar
keycode 14 = 5 percent F5 percent
keycode 15 = 6 asciicircum F6 asciicircum
keycode 16 = 7 ampersand F7 ampersand
keycode 17 = 8 asterisk F8 asterisk
keycode 18 = 9 parenleft F9 parenleft
keycode 19 = 0 parenright F10 parenright
keycode 22 = BackSpace BackSpace KP_Delete BackSpace
keycode 29 = y Y braceleft Y
keycode 30 = u U braceright U
keycode 31 = i I bracketleft I
keycode 32 = o O bracketright O
keycode 33 = p P bar P
keycode 36 = Return NoSymbol KP_Enter
keycode 43 = h H less H
keycode 44 = j J greater J
keycode 45 = k K apostrophe K
keycode 46 = l L quotedbl L
keycode 56 = b B grave b
keycode 57 = n N asciitilde n
keycode 58 = m M colon M
keycode 59 = comma less semicolon less
keycode 60 = period comma semicolon comma
keycode 61 = slash question backslash question
keycode 82 = KP_Subtract underscore F11 KP_Subtract
keycode 86 = KP_Add KP_Equal F12 KP_Add
keycode 108 = Mode_switch Meta_R Alt_R Meta_R
keycode 111 = Up NoSymbol Prior
keycode 113 = Left NoSymbol Home
keycode 114 = Right NoSymbol End
keycode 116 = Down NoSymbol Next

Updating Pico8

Downloaded latest Pico8 for the C.H.I.P. from lexaloffle.com and follow the instructions on installing it.

The binary was built against an old version of libcurl and will give error about not finding CURL_OPENSSL_3.

./pico8: /usr/lib/arm-linux-gnueabihf/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ./pico8)

To fix this, download the older Raspian Stretch image and mount it locally

sudo mount -v -o offset=48234496 -t ext4 2017-09-07-raspbian-stretch.img /mnt

Create the directory /usr/local/share/libcurlhack and copy the files /mnt/usr/lib/arm-linux-gnueabihf/{libcrypto.so.1.0.2,libcurl.so.4,libssl.so.1.0.2} from the Raspbian Stretch image to the C.H.I.P.

When finished the C.H.I.P. /usr/local/share/libcurlhack/ will look like this,

chip@chip:~$ ls -l /usr/local/share/libcurlhack/
total 2208
-rw-r--r-- 1 root staff 1493272 Feb 24 02:20 libcrypto.so.1.0.2
-rw-r--r-- 1 root staff  439956 Feb 24 02:15 libcurl.so.4
-rw-r--r-- 1 root staff  320924 Feb 24 02:19 libssl.so.1.0.2

Create a shell script /usr/local/bin/pico8 that will include this new path in LD_LIBRARY_PATH,

#!/bin/sh

LD_LIBRARY_PATH=/usr/local/share/libcurlhack:/usr/lib/arm-linux-gnueabihf/
export LD_LIBRARY_PATH

/usr/lib/pico8/pico8

Running Pico8 from the Pocket C.H.I.P. launcher will now work.

Changing the Window Manager

By default the C.H.I.P. will run the pocket-wm, which is a modified version of dwm.

chip@chip:/usr/share/xsessions$ pocket-wm -v
dwm-6.0, © 2006-2011 dwm engineers, see LICENSE for details

This in turn runs dmenu and to launch the “home” screen with the applications Iceweasel, pico8, urxvt, and aeabi.

chip@chip:~$ strings /usr/bin/pocket-wm | grep dmenu_run -A4
dmenu_run
Iceweasel
pico8
urxvt
aeabi

I looked a bit to see how all this was configured, but need to spent more time on reading up on dwm and dmenu_run to know what I’m looking at.

To run a different window manager or session we’ll need to configure Lightdm to use something other than pocket-wm.

For example to run Fluxbox, install it using apt,

sudo apt-get update && sudo apt-get install -y fluxbox

Which creates fluxbox.desktop in /usr/share/xsessions. This directory contains all available window managers that Lightdm can launch.

chip@chip:~$ ls -l /usr/share/xsessions
total 24
-rw-r--r-- 1 root root  188 Feb 26  2019 awesome.desktop
-rw-r--r-- 1 root root  222 Feb 24  2014 fluxbox.desktop
-rw-r--r-- 1 root root   86 Feb 22  2019 lightdm-xsession.desktop
-rw-r--r-- 1 root root  118 Apr 27  2016 pocket-wm.desktop
-rw-r--r-- 1 root root 5465 Oct 21  2017 xfce.desktop

In the chip users home directory ~/.dmrc and set Session= to the window manager lightdm should launch automatically. This will match what’s in /usr/share/xessions but without the .desktop extension This will match what’s in /usr/share/xessions but without the .desktop extension.

[Desktop]
Language=en_US.utf8
Session=fluxbox

Restart lightdm and it will restart the C.H.I.P. with the new window manager.

sudo systemctl restart lightdm

Fluxbox on PocketChip

Right Click

Right click is heavily used on Fluxbox but doesn’t work out-of-the-box with the Pocket C.H.I.P., and setting a button override in Xmodmap or mouse keys in Xorg doesn’t work (it even seems to break the FN keys). To enable right click by holding down on the touch screen build and setup evdev-right-click-emulation.

# Clone the repoistory
git clone https://github.com/PeterCxy/evdev-right-click-emulation

# Install required dependencies to build
sudo apt-get install -y libevdev-dev libevdev2

# Build evdev-rce
make all

# Move evdev-rce to a system path and chown the owner group
sudo mv out/evdev-rce /usr/local/bin
sudo chown root:staff /usr/local/bin/evdev-rce

# Have evdev-rce start on boot
echo "/usr/local/bin/evdev-rce &" | sudo tee -a /etc/rc.local

Conclusion

the Pocket C.H.I.P. is a lot of fun, even with some of these issues the troubleshooting process gave me a way to explore the system and understand how it works. This is valuable as I continue to tinker with it to make it a true desk mini-terminal.

Custom Keyboards, Sully and Pok3r

Mon, 15 Feb 2021 00:00:00 +0000

Intro

Working in the tech industry and having geeky hobbies; I’ve always taken my tools, both hardware and software, seriously. For some reason I never thought about the keyboard itself though, and was content with using the bundled membrane boards. A few years ago though this all changed which I discovered the deep rabbit hole that is both utilitarian and vain world of custom keyboards.

Sully

Back in 2013 I convinced my boss that I needed a high-end mechanical keyboard to help with some recent hand pain (almost entirely due to Starbound at the time). I purchased a Coolermaster CM Storm with Cherry MX Green switches. It was my first “small” keyboard in a sense that it was a ten-key-less (TKL) and the green switches were clicky and stiff, exactly what I wanted in a keyboard since it reminded me of the electric typewriters I learned to touch-type on.

After spending some time on r/MechanicalKeyboards I got the itch to customize it and bought some blank PBT DSA keys in teal and purple, calling it “Sully”.

Sully

Sully was a fantastic board and I used it up until 2019 when I discovered even smaller form factors like 60%. It’s still used in our house, but mostly as a kids toy, demostrating just how well-built it is.

Vortex Pok3r

The idea of a smaller, 60% board was appealing in with having the same functionality but in a more compact form. Removing some of the less used keys to provide more desk space and limit finger stretch. I also just liked the way it looked, more compact and different than the standard 101 keyboards. I put the Pok3r on my wishlist because it was “programmable” and I had all sorts of ideas on ways I could customize shortcuts and other functions.

It came as a Christmas present in 2019, with Cherry MX blue switches and stock keycaps. I immediately started using the programmable PCB, but found it was much more difficult to do since it involves putting it into programming mode and then keying in what you want to setup. Just remapping some keys, like making CAPS-LOCK -> Escape was an exercise in frustration, but it did what I wanted eventually, with the process meticulously detailed in a .txt file. It also has different layers that could hold different keymaps, but I just stuck with a single layer.

## Caps-lock as ESC
FN+R_control
CAPS_LOCK
ESC
PN
FN+R_control

## HJKL Navigation
FN+R_Control
FN+H FN+J
FN+J FN+K
FN+K FN+I
PN
FN+R_Control

Sample of how to program the stock pok3r firmware

Pok3r Revived

Eventually I started getting annoyed with the default keycaps, which were a thin cheap ABS plastic and would squeak. Just over a month of use the legends also starting to wear off. This started me down a dark path, first looking into how to stop the squeaking, but then lead to going back to r/MechanicalKeyboards and following the white rabbit, and making a wish list to customize the board and make it fully mine.

Thick PBT Keycaps
Tactile Switches
Keyboard Foam
QMK Programming Support

/dev/tty

The first item on the list was easy enough to do, just scour keyboard stores and find a keycap set. I went through various postings, storefronts, and group buys, eventually landing on /dev/tty by matt3o. These were particularly attractive because of their story; inspired by IBM Beamspring terminals and the /dev/tty name.

MT3 is inspired by old terminal keyboards; TTY was used to refer to “teletype” or “teletypewriter” but it has come to refer to any type of text terminal. As a linux user the temptation to call the set /dev/tty was simply too strong to resist.

The MT3 profile is also extremely high, and the deep dish and feel of PBT makes the keys almost “cuddle” your fingertips. Typing on them is an absolutely joy and because of their thickness they sound amazing even on just a stock board.

Holy Pandas

Next on the list was replacing the switches with something less clicky and more tactile. The original “Sully” board had MX Greens which were extremely clicky and I wanted something different with MX blues in the pok3r, but wanted a change of pace from the last few years. While reading through keyboard sites, the phrase “Holy Panda” kept coming up and how they were fantastic tactile switches. Eventually I came across one of the original post that described the origins of the Holy Panda and found that it was an entirely custom switch, made from two different switches.

The Holy Panda switch is the combination of the stem of a Halo True and the housing of a Invyr Panda. The result is the Holy Panda hybrid, one of the snappiest tactile mechanical switches available.

YOK Polar Panda(left) Holy Panda(center) Halo True(right)

The idea of building my own switches really resonated with me since it gave me, giving me more ownership of what I was building. Holy Pandas also sound amazing when typing, not clicky or loud, but thunky and tactile. Pairing them with a thicker PBT keycap set made perfect sense as well.

Luckily I found some YOK Polar Panda switches in-stock and ordered them and some Halo Trues from drop, which created “Polar Holy Pandas” with a distinctive blue housing and a salmon stem.

Building Holy Pandas

Lubing is also a thing when it comes to building custom switches, and these were lubed with Krytox 205g0, to give them a smoother tactile bump.

Foam

Did you know you can put foam in a keyboard to help dampen the sound? I had no idea this was a thing, but it is, and it completely changes the sound profile of a keyboard. So if you’re into how a keyboard sounds, and are willing to spend 15$, foaming a board is a good investment.

PCB Foam Sandwich

I opted for foam from MKUltra, which I originally thought would go in the bottom of the case. When it arrived I discovered it was plate foam, which goes between the top plate and the PCB, making a sandwich. Even though it wasn’t my original choice, it worked much better since now the entire board is a solid piece with exceptional dampening sounds. Combined with the Holy Panda tactile and /dev/tty thickness, it makes a satisfying THUNK with every keypress.

QMK Programming

The last item on the list was improving the programming of the board. I’m planning to write up a more extensive article on QMK, and the pok3r can run QMK, but requires unlocking the board which is risky and even then will use a fork or QMK and not upstream. While tempted to try this, I found that YMDK makes a drop in replacement YD60MQ PCB that you can buy for under 30$. This also gave me an excuse to get a de-soldering iron to quickly de-solder the switches and not risk damaging them by using a solder sucker or wick.

Replacing old pok3r PCB (red) with new YD60MQ PCB (black)

The PCB was replaced about a year after the board was first built, months after I started using QMK on my other boards (more on those in Part 2). The custom keymap flashed on it is similar to the other boards I have, so combos and layers are consistent across all my boards.

Final Product

pok3r Final Form

With all these features checked off the list, the pok3r is is my daily driver for work and pleasure. It’s a dream to type on with the tactility of the Holy Pandas, and the sound alone is worth the investment. Having the full power of QMK in the board greatly expands it’s capabilities and gives me full ownership and pride in both the hardware and software aspects of it.

Granted it’s borderline Ship of Thesus, with the only original parts the aluminum case and stabilizers, but that makes it a fully custom board that no one else has or could come close to replicating.

Launching a Gemini Capsule

Tue, 09 Feb 2021 00:00:00 +0000

Gemawhat?

Even since I started using Mastodon a couple of weeks ago, Project Gemini is one of the most exciting new technologies I’ve discovered in my local feed.

I won’t go into full detail on what Gemini is, but similar to why I made a Gopherhole, Gemini is a newer Internet protocol that strips away the bloat of the modern web to a core set of concepts, generality, and maximum power-to-weight-ratio.

Gemini is a new, collaboratively designed internet protocol, which explores the space in between gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other.

While setting up a Gopherhole was fun and a throwback to an era long gone, Gemini has modern features but still sticks to simplicity,

Encryption by default
Gemtext similar to Markdown
MIME type support
Support for multiple protocols; gemini://, gopher://, http://

Creating a Capsule

Creating a Gemini Capsule was a much lower barrier than it seems, since it’s Gemtext is very similar to Markdown and can almost convert 1:1 (with the exception of in-line links). So posts written in Markdown for a static blog (like Jekyll) can easily work in Gemini. The tool md2gemini makes this even more seamless by converting Markdown specific things to Gemtext.

With having content ready to go, hosting is the next challenge. Bringing up your own Gemini server is easy enough, with a large number of Gemini servers available. I just went with using my Pubnix account at rawtext.club which provides a public_gemini option. This is also where my gopherhole is hosted.

Creating a Toolset

Manually converting markdown posts, using scp to copy them to RTC, and putting together some basic index.gmi and blog.gmi files, and I had a live Gemini capsule and running. This was nice, but I wanted to publish posts on this blog to both Gopherspace and Geminispace together and needed something that would have some additional features,

Convert Jekyll markdown to Gopher and Gemtext
Create a 10 most recent posts page and an archive page of all posts
Add tags to posts, group posts by tags, and have all tags listed on the archive page
Basic header/footer support
Build a gemfeed to syndicate in Geminispace

Iterating on the tools I wrote for Gopher by including using md2gemini to convert to Gemtext got me partially there, but was still missing some more features. After more iterations, I had updatesmallweb.sh that converts Jekyll posts to Gopher and Gemini. Now whenever I publish a post on Jekyll, I can run this script to convert the post to Gopher and Gemini. Doing git push to github, then git pull on RTC and everything is up-to-date.

Here’s the script in action building the gopherhole and capsule,

micheal in git/ecliptik.github.io/_scripts on  master [$!?] took 2s
🚀➜ ./updatesmallweb.sh -t all
Converting post ../_posts/2011-01-22-Vim-rdesktop-external-monitors-and-X-Forwarding-on-a-Google-CR-48.md to gopher
Converting post ../_posts/2015-08-20-Building-a-website-with-Github-and-Jekyll.md to gopher
Converting post ../_posts/2015-08-21-Decompiling-Interactive-Fiction.md to gopher
Converting post ../_posts/2015-08-28-Emulating-ARM64-on-Linux.md to gopher
Converting post ../_posts/2015-08-29-Containerizing-a-Perl-Script.md to gopher
Converting post ../_posts/2015-09-08-Automating-Container-Updates-With-Watchtower.md to gopher
Converting post ../_posts/2017-09-11-Raspberry-Pi-Kubernetes-Cluster.md to gopher
Converting post ../_posts/2017-09-12-ACI-Connector-for-k8s-on-a-Raspberry-Pi-Cluster.md to gopher
Converting post ../_posts/2017-10-02-Cross-Building-and-Running-Multi-Arch-Docker-Images.md to gopher
Converting post ../_posts/2021-01-26-One-Week-With-Mastodon.md to gopher
Converting post ../_posts/2021-01-31-Making-a-Gopherhole-and-Phlog.md to gopher
Converting post ../_posts/2021-02-09-Launching-a-Gemini-Capsule.md to gopher
Creating gophermap: ../_gopher/_posts/gophermap
Converting post ../_posts/2011-01-22-Vim-rdesktop-external-monitors-and-X-Forwarding-on-a-Google-CR-48.md to gemini
Creating tag page ../_gemini/_tags/vim.gmi
Creating tag page ../_gemini/_tags/google.gmi
Creating tag page ../_gemini/_tags/cr-48.gmi
Creating tag page ../_gemini/_tags/linux.gmi
Creating tag page ../_gemini/_tags/blogger.gmi
Converting post ../_posts/2015-08-20-Building-a-website-with-Github-and-Jekyll.md to gemini
Creating tag page ../_gemini/_tags/docker.gmi
Creating tag page ../_gemini/_tags/jekyll.gmi
Creating tag page ../_gemini/_tags/github.gmi
Converting post ../_posts/2015-08-21-Decompiling-Interactive-Fiction.md to gemini
Creating tag page ../_gemini/_tags/zmachine.gmi
Creating tag page ../_gemini/_tags/interactivefiction.gmi
Creating tag page ../_gemini/_tags/zork.gmi
Converting post ../_posts/2015-08-28-Emulating-ARM64-on-Linux.md to gemini
Creating tag page ../_gemini/_tags/operatingsystems.gmi
Creating tag page ../_gemini/_tags/arm.gmi
Creating tag page ../_gemini/_tags/ubuntu.gmi
Converting post ../_posts/2015-08-29-Containerizing-a-Perl-Script.md to gemini
Creating tag page ../_gemini/_tags/perl.gmi
Creating tag page ../_gemini/_tags/containers.gmi
Converting post ../_posts/2015-09-08-Automating-Container-Updates-With-Watchtower.md to gemini
Creating tag page ../_gemini/_tags/watchtower.gmi
Converting post ../_posts/2017-09-11-Raspberry-Pi-Kubernetes-Cluster.md to gemini
Creating tag page ../_gemini/_tags/kubernetes.gmi
Creating tag page ../_gemini/_tags/raspberrypi.gmi
Converting post ../_posts/2017-09-12-ACI-Connector-for-k8s-on-a-Raspberry-Pi-Cluster.md to gemini
Creating tag page ../_gemini/_tags/azure.gmi
Converting post ../_posts/2017-10-02-Cross-Building-and-Running-Multi-Arch-Docker-Images.md to gemini
Converting post ../_posts/2021-01-26-One-Week-With-Mastodon.md to gemini
Creating tag page ../_gemini/_tags/mastodon.gmi
Creating tag page ../_gemini/_tags/fediverse.gmi
Creating tag page ../_gemini/_tags/100daystooffload.gmi
Converting post ../_posts/2021-01-31-Making-a-Gopherhole-and-Phlog.md to gemini
Creating tag page ../_gemini/_tags/gopher.gmi
Converting post ../_posts/2021-02-09-Launching-a-Gemini-Capsule.md to gemini
Creating tag page ../_gemini/_tags/gemini.gmi
Creating tag page ../_gemini/_tags/smallweb.gmi
Creating gemlog index: ../_gemini/gemlog.gmi
Creating archive index: ../_gemini/_posts/index.gmi
Creating tag index page: ../_gemini/_tags/index.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/100daystooffload.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/arm.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/azure.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/blogger.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/containers.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/cr-48.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/docker.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/fediverse.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/gemini.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/github.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/google.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/gopher.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/index.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/interactivefiction.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/jekyll.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/kubernetes.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/linux.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/mastodon.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/operatingsystems.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/perl.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/raspberrypi.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/smallweb.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/ubuntu.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/vim.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/watchtower.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/zmachine.gmi
Adding tag link gemini://rawtext.club/~ecliptik/_tags/zork.gmi
Generating feed "Gemlog Archive", which should be served from gemini://rawtext.club/~ecliptik/_posts/feed.xml
Adding 2021-02-09-Launching-a-Gemini-Capsule.gmi with title 'Launching a Gemini Capsule'...
Adding 2021-01-31-Making-a-Gopherhole-and-Phlog.gmi with title 'Making a Gopherhole and Phlog'...
Adding 2021-01-26-One-Week-With-Mastodon.gmi with title 'One Week With Mastodon'...
Adding 2017-10-02-Cross-Building-and-Running-Multi-Arch-Docker-Images.gmi with title 'Cross Building and Running Multi-Arch Docker Images'...
Adding 2017-09-12-ACI-Connector-for-k8s-on-a-Raspberry-Pi-Cluster.gmi with title 'ACI Connector for k8s on a Raspberry Pi Cluster'...
Adding 2017-09-11-Raspberry-Pi-Kubernetes-Cluster.gmi with title 'Raspberry Pi Kubernetes Cluster'...
Adding 2015-09-08-Automating-Container-Updates-With-Watchtower.gmi with title 'Automating Container Updates With Watchtower'...
Adding 2015-08-29-Containerizing-a-Perl-Script.gmi with title 'Containerizing a Perl Script'...
Adding 2015-08-28-Emulating-ARM64-on-Linux.gmi with title 'Emulating ARM64 on Linux'...
Adding 2015-08-21-Decompiling-Interactive-Fiction.gmi with title 'Decompiling Interactive Fiction'...
Wrote Atom feed to ../_gemini/_posts/feed.xml.

Gemlog in Lagrange

What’s Next

Now that I have a better understanding of how Gopher and Gemini work, and have some tooling to make things seamless between http://,gopher://,gemini://, my plans are to improve updatesmallweb.sh so it’s almost a static site generator. Some of the documentation and examples needs updating as well, so others can use it, and already gemini://gemini.lottalinuxlinks.com has.

Gemini is one of those things that you either really like or don’t quite understand it. I’m in the former group, as it reminds me of what the Internet was before it turned into what it is today. The phrase “Eternal August” is one that comes to mind, as it’s specification is not meant to really be improved upon and should remain the same for the foreseeable future. This allows creativity to flourish in a restricted environment, like the Demo Scene or modern homebrew Gameboy Games.

For more on exploring Geminispace, see awesome-gemini.

Making a Gopherhole and Phlog

Sun, 31 Jan 2021 00:00:00 +0000

But Why?

The obvious questions is why make a Gopherhole (what gopher sites are called) when all the action is on the World Wide Web over html and http? Didn’t those protocols win the Internet two decades ago? I didn’t really think much about Gopher until I started reading more about the newer Gemini protocol on my foray into Mastodon last week and figuratively went “down” the Gopherhole.

Slides from 1992 Gopher presentation

I was suprised to find not only a flourishing community, but was drawn to the simplicity of the protocol and creating for it. No more thinking about CSS oddities, having to learn whole web stacks with the latest-and-greatest toolsets. Most of what Gopher is now is the same as it was in the early 90s and it’s something you can easily start learning about and doing without sinking a lot of time and effort just to get started. It reminds of learning Latin, even though it’s a dead language, it’s still useful and it will never change. It also has the advantages of being almost entirely text based and there’s no tracking, cookies, or any of the risks and privacy concerns associated with the modern web.

For a much more in-depth look on modern Gopher, I recommend reading Burrowing A Gopher Hole.

Start Burrowing

The first thing I needed to to was figure out how to host a Gopherhole. I could run it myself locally, and was thinking of re-purposing one of my numerous raspberrypis to self-host it over port 70. I even got as far as trying to make a Dockerfile to run gophernicus in a container and maybe even get it to run in Kubernetes! I quickly realized this was missing the point of slowing down and focusing on the simplicity that intially drew me in the first place and scrapped this idea.

While browsing Gemini capsules (the term for Gemini sites), I came across the PubNix RawText.club, whose mission fit with the themes of simplicity and do-it-yourself while offering some basic hosting services for gopher, gemini, and web.

RTC is a non-profit, do-it-yourself social network that uses a smaller, simpler, user-built toolkit. We are proudly the polar opposite of the big, exploitative, corporate-owned social media mega-sites. Not cool. Not easy. Not big. rawtext.club is what you make it. The point is that you can do a LOT using very minimal resources by stringing together command line tricks on a Linux system.

I pondered joining for a few days to make sure I would stick with the commitment and didn’t want to join and then lose interest a few weeks later. Even though RTC is a “slow” social network, I wanted to actively particpate in the community and not just be passive and looking for a free handout. Eventually I sent an invite request and was extended a membership. The first few days I spent checking out RTC from the cli; creating a prescense and reading the man pages for the local tools (which are excellent).

Finally I started adding things in ~ecliptik/public_gopher and got to work on making a gohperhole. Creating a gopherhole has been well covered by others in other blog posts, which I heavily referenced when making the site,

On RTC, home directories are world readable, so I poked around in some more well-known users public_gopher dirs and saw how their gopherholes were setup. I used the gopher browser Bombadillo as my main tool to view Gopherspace, and coincidentally Lagrange, the browser I was using to browse Gemini, also supported gopher and would use it occasionally as a GUI view.

The resulting gopherhole was relatively simple,

[ecliptik@rawtext public_gopher]$ tree .
.
├── about.txt -> ../.who-is
├── gophermap
└── phlog

1 directory, 2 files

The about page is a symlink to my ~/.who-is (which is used on RTC as a profile), a link to the Phlog dir, a web link to the www page, and a link back to the RTC gopherhole. The gophermap for this was simple.

Welcome to ecliptik's Gopherhole

Nav:
0About	about.txt
1Phlog	./phlog

Links:
hecliptik.com	URL:https://www.ecliptik.com
1rawtext.club	/       rawtext.club    70

The most difficulty I had was getting the link identifiers and tabs in the correct places.

Adding these files made the site live at gopher://rawtext.club:70/1~ecliptik. If you don’t have a gopher browser installed it’s viewable through a gopher proxy from Floodgap.

           Welcome to ecliptik's Gopherhole
           
           Nav:
TXT   [1]  About
MAP   [2]  Phlog
           
           Links:
HTM   [3]  ecliptik.com
MAP   [4]  rawtext.club
           ___________________________________________________________________
                              Gophered by Gophernicus/3.1 on Arch/5.10 x86_64

Viewed in Bombadillo

Gopherhole in Lagrange Browser

Phlog

After getting the basic site up I wanted to update it frequently with a Phlog, which is the gopher equivalent of a Blog. Since I already have this blog with Jekyll and uses markdown for posts, I thought I might as well mirror these posts to the Phlog. I also decided to only do the pure markdown posts, as some of the older posts on the blog were converted from my old blogger site and are HTML. Having to convert all of those to markdown or writing scripts to also convert HTML was a bit too much for this project.

A few others have already done this, as referenced above for Jekyll and Hugo already, but I wanted to do my own take on it. Originally I wrote a script that would convert a post to a gophermap, converting the links to blocks, identifying what type they were and creating item links.

#!/bin/bash
#Convert a jekyll markdown post to a gophermap
#Will create a sub-directory with the name of the post and a gophermap
#converted to  70 columns with links. Tries to do basic http or gopher
#linking. May not work well, but works well enough.

# usage: ./md2gophermap.sh ../_posts/post-to-convert.md

#Know Bugs
#Pandoc does not wrap code blocks to the columns length and will get cut
#off when rendered in the gophermap.
#see: https://github.com/jgm/pandoc/issues/4302#issuecomment-360669013

#Take input and craft output file and directory vars for use later on
input=$1
output=`basename ${input}`
outdir=`basename -s .md ${output}`

echo "converting ${input}"
pandoc --from markdown --to markdown --reference-links --reference-location=block --columns=70 -o ${output} ${input}

#Do some IFS changes in order to properly parse individual lines after conversion
IFSORIG=${IFS}
IFS="
"

#Create gophermap

##HTML link syntax
#hecliptik.com	URL:https://www.ecliptik.com

##Gopher link syntax
#1rawtext.club	/	rawtext.club	70

#Go through the file line-by-line looking for http or gopher linkes and convert
for line in `cat ${output}`; do
  IFS=${IFSORIG}
  if echo "${line}" | egrep -e "^.+\[.+\]:.+" >/dev/null; then

    case ${line} in
      *http*)
        itemname=`echo ${line} |sed -r 's/\[(.*)\]/\1/' | awk -F: {'print $1'} |xargs`
        itemlink=`echo ${line} |awk -F] {'print $2'} | sed -e "s%:\ %%"`
        item="h${itemname}\tURL:${itemlink}"
      ;;
      *gopher*)
        itemname=`echo ${line} |sed -r 's/\[(.*)\]/\1/' | awk -F: {'print $1'} |xargs`
        itemserver=`echo ${line} |awk -F/ {'print $3'} | awk -F: {'print $1'}`
        itemlink=`echo ${line} |awk -F/ {'print $4'}`
        item="1${itemname}\t/${itemlink}\t${itemserver}\t70"
    esac
#Set IFS to new line in order to remove leading spaces
 IFS="
"

    #Escape all special chars so they're replaced in sed
    linemung=$(echo ${line} | sed -e 's`[][\\/.*^$]`\\&`g')
    itemmung=$(echo ${item} | sed -e 's`[][\\/.*^$]`\\&`g')

    #Replace markdown blocks with gophermap
    sed -i -e "s/${linemung}/${itemmung}/" ${output}
    sed -i -e "s/\\\t/\t/g" ${output}
 fi
done

#Make the subdirectory
mkdir -p ${outdir}

#Use the top of the original Markdown file to create a basic header
head -6 ${input} | grep -v "layout" | grep -v "category" > ${outdir}/gophermap
echo "" >> ${outdir}/gophermap
cat ${output} >> ${outdir}/gophermap

#Convert --- lines to underscore
sed -i -E "s/^--.+$/$(printf '%.0s_' {0..69})/g" ${outdir}/gophermap
sed -i -E "s/^==.+$/$(printf '%.0s_' {0..69})/g" ${outdir}/gophermap

#Remove the pandoc output file to clean up
rm -fr ${output}

This worked out well, where a gophermap for each post under _posts was formatted properly into their own directories, wrapping was done, and the item links worked. However it just looked sort of off, and there was an issue where code blocks would not be wrapped by pandoc.

I decided then to just convert them to plaintext and not do a full gophermap, which preserved the formatting, wrapped text blocks more accurately, and just looked better in general. Most of the links in the posts are http anyway, so if they were followed they’d open in a web browser anyway.

#!/bin/bash
#Convert a jekyll markdown post to plaintext suitable for gopher,
#converted to  70 columns

#usage: ./md2gopher.sh ../_posts/post-to-convert.md

#Take input and craft output file and directory vars for use later on
input=$1
outdir="_posts"
output="${outdir}/`basename -s .md ${input}`.txt"

mkdir -p ${outdir}

echo "converting ${input} to ${output}"
pandoc --from markdown --to plain --reference-links --reference-location=block --columns=70 -o ${output}.tmp ${input}

#Use the top of the original Markdown file to create a basic header
head -6 ${input} | grep -v "layout" | grep -v "category" > ${output}
echo "" >> ${output}
cat ${output}.tmp >> ${output}
rm -fr ${output}.tmp

These plaintext posts rendered much nicer and I was happy with how they turned out.

Phlog post in Bombadillo

One final step was automatically generating a Phlog index of posts. The post Making a Gopherhole that I used when making my own Gopherhole had a script on taking the last 10 posts and generating a gophermap of them. I took this script and modified it some to include some things like a basic layout template.

#!/bin/bash

#Create gophermap of last 10 posts
#Originally from: https://johngodlee.github.io/2019/11/20/gopher.html

#Use layout file for header on gophermap
cat _layouts/phlog > gophermap

all=(_posts/*.txt)

# Reverse order of posts array
for (( i=${#all[@]}-1; i>=0; i-- )); do
  rev_all[${#rev_all[@]}]=${all[i]}
done

# Get 10 most recent posts
recent="${rev_all[@]:0:10}"

# Add recent post links to gophermap
for i in $recent; do
  line=$(head -n 4 $i | grep -i "title:" | awk -F: {'print $2'} | xargs)
  printf "0$line\t$i\n" >> gophermap
done

#Append footer with html link
echo "" >> gophermap
printf '%.0s_' {0..69} >> gophermap
echo "" >> gophermap
echo "hecliptik.com	URL:https://www.ecliptik.com" >> gophermap

The gophermap created while not fancy works well in displaying the latest 10 posts,

                                  ecliptik's phlog
           ___________________________________________________________________
           
                 These posts are mirrored from https://www.ecliptik.com
           ___________________________________________________________________
           
           Latest 10 posts
           ___________________________________________________________________
           
TXT   [1]  One Week With Mastodon
TXT   [2]  ACI Connector for k8s on a Raspberry Pi Cluster
TXT   [3]  Raspberry Pi Kubernetes Cluster
TXT   [4]  Cross Building and Running Multi-Arch Docker Images
TXT   [5]  Automating Container Updates With Watchtower
TXT   [6]  Containerizing a Perl Script
TXT   [7]  Emulating ARM64 on Linux
TXT   [8]  Decompiling Interactive Fiction
TXT   [9]  Building a website with Github and Jekyll
TXT  [10]  Vim, rdesktop, external monitors, and X Forwarding on a Google CR-48
           
           ___________________________________________________________________
HTM  [11]  ecliptik.com
           ___________________________________________________________________
                              Gophered by Gophernicus/3.1 on Arch/5.10 x86_64

While writing these tools I initially was creating them on my laptop, putting them into a tarball, scping them to RTC and then untarring them. This added a lot of manual steps into the process, so I took the more modern workflow of checking the converted posts into git, cloning them to RTC, the symlinking them from the gopherhole. This way after writing a post (such as this one), I’ll run the scripts, push and then pull on RTC and my phlog will be updated along with the WWW site.

These tools and usage are describe more in their README.md

Conclusions

While gopher didn’t win against the web in the early 90’s, it’s sense of simplicity really shines in todays modern and complex Internet. I’ve already found a lot of interesting content while browsing gopherspace that I wouldn’t find on the WWW and there is much more a sense of community, similar to what the web was like in the early days before modern social networking.

One Week With Mastodon

Tue, 26 Jan 2021 00:00:00 +0000

Intro

One week ago I posted my first toot on Mastodon and I want to document my first weeks experience since it was much more eventful than I was expecting.

Choosing an Instance

One of the first things you do when signing up for Mastodon is choose an instance. I didn’t quite understand this at first, but eventually realized it was akin to choosing a Geocities neighborhood in the 90s. The instance you sign up for is like a community, with similar interests and themes that best fit your online identity and personality. After reading about different intances and browsing public timelines of users, I choose Fosstodon as my home instance. I was drawn to their focus on Free and Open Source Software, which fits my style of computing and online interests.

Trying Things Out

The first few days I posted a few toots, followed some users on federated instances, and occasionally checked in on the local and federated timelines. I quickly realized that the federated timeline (a timeline which contains posts from all federated instances outside of Fosstodon) wasn’t really for me, but the local timeline for Fosstodon was interesting. Because Fosstodon is only a few thousand users, there wasn’t a firehose of posts to keep up on, and most users were posting links and comments on things that resonated with me.

Checking in on the local feed every few hours gave insight into what types of posts would add to the community and I started putting a few things out there just to test out the interface and gain confidence in using the service.

Gemini and Gopherspace

The first topic that really caught my eye was I saw the hashtag #gemini trending on Fosstodon. I thought maybe it was related to space (which is sort of is), and after following the tag and reading toots from other users I discovered Project Gemini. This in turn lead me to installing the Lagrange and Bombadillo browsers. From there I started exploring all the sites I could find on gemini://, and eventually started browsing Gopherspace (which is very much alive even in 2021). This re-kindled a curiosity of using networked computers that I haven’t felt since using Fidonet and browsing my local BBS in the 90s.

512KB Club

The next trending hashtag I saw was #512kbclub, which is a challenge to bring your personal websites homepage under 512KB. This site came in at 252KB total size without any tuning and I submitted it for inclusion and was added to the Blue team, just missing the Orange team cutoff. Looking more closely at the sites components, much of it was Google Analytics, taking up around 138KB of the sites size. I posted a toot about joining the 512KB club and if there were any replacements for Google Analytics and recieved some helpful replies with alternatives. I replaced Google Analytics with Goat Counter and saw that the site was including jquery but not using it, that brought the site down to 24.7KB and into Green team (<100KB) territory.

100DaysToOffload

Another trending hastag was #100daystooffload, a challenge to write 100 personal blog posts in one year. This post is the first in what I hope will be many to participate in this challenge. I like the idea since it gives a goal to strive for and even if no one reads them it will provide personal growth experience.

Bitwarden

About a year ago I started looking into alternative for LastPass as my password manager, as annual pricing had increased since I first started using it years ago and I knew there were better products out there. Inspired by seeing others on Fosstodon taking up tools and learning new things, I finally did the migration to Bitwarden, which was a much easier process than I expected.

ScreenShotSunday

It turns out on Sundays a thing to do on Fosstodon is post screenshots with the tag #screenshotsunday. Since I have a post on screenshots through the years I tooted an old screenshot from RedHat Linux 6.1 in 2000 and got a lot of positive responses, boosts, and followers leading to my highest “engagement”.

Summary

Much more happened than and I was expecting when I first thought about joining Mastodon last week. Because of the level of community and quality of posts, using Mastodon is much more rewarding than using Twitter where it feels overwhelming to keep up and posting is like shouting into a crowd of millions hoping a few will hear. I’m really looking forward to what will come with using Mastodon, and possibly other Fediverse, in the future.

The one critique I have of using Mastodon is interacting with other federated instances. When following users on other instances, the standard flow is to pop-up a seperate window and having to copy/paste your account in order to complete the action. I would expect since you’re signed into an instance already that it would somehow automaticaly fill this in or just be more seamless overall. This may just be the way it works since they are federated, but it feels clunkier than it should.

Cross Building and Running Multi-Arch Docker Images

Mon, 02 Oct 2017 00:00:00 +0000

Intro

When running a Raspberry Pi cluster, sometimes there’s just not enough power to build native armhf Docker images in a reasonable amount of time.

While the recent announcement of Docker Hub Official Multi-platform support makes it easier to run official multi-arch images, building a multi-arch image still requires a cross-build environment to speed up builds on lower powered hardware or when you don’t have the native platform.

Cross-building is defined as building a foreign architecture image different from the hosts architecture, such as building a armhf image on a x86 machine.

There are three methods of cross-building and running multi-arch Docker images each with different considerations,

Docker for Mac
Multiarch on Linux
QEMU on Linux

Docker for Mac

Since the original beta, Docker for Mac has had binfmt_misc support built-in, which allows it to execute arm containers on x86 without any additional configuration.

If you have Docker for Mac you can test this out by running any multi-arch Docker image from Docker Hub such as the official arm32v7/debian image,

🐳 uname -a
Darwin sheik.local 16.7.0 Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64 x86_64 i386 MacBookPro11,3 Darwin

🐳 docker run -it --rm arm32v7/debian /bin/bash
Unable to find image 'arm32v7/debian:latest' locally
latest: Pulling from arm32v7/debian
d0e027c48353: Pull complete
Digest: sha256:d74cc69431f03bbfbbf9fd52c1eabd6ca491280a03da267acb63b65b81e30c8a

/ # uname -a
Linux 4372bf9a3462 4.9.41-moby #1 SMP Wed Sep 6 00:05:16 UTC 2017 armv7l GNU/Linux

Building an image is as easy as taking an existing Dockerfile and changing it’s FROM to point to a base multi-arch image. Depending on the image, it may fail if non-architecture binaries run, such as the Dockerfile using wget to download and run a non-native binary.

For example to re-build the NodeJS Debian Image for arm32v7.

🐳 curl -sSL https://raw.githubusercontent.com/nodejs/docker-node/c37d5e87fa6d46c0e387f73161b056bbf90b83aa/8.6/stretch/Dockerfile | sed "s/buildpack-deps:stretch/arm32v7\/buildpack-deps:stretch/g" > Dockerfile.nodejs.armhf

🐳 docker build -f Dockerfile.nodejs.armhf -t nodejs:armhf .

Considerations

This is the easiest and quickest way to build an run any 32-bit or 64-bit Docker images. Disadvantages are you must be running macOS and are limited by the hardware macOS will run on, this isn’t an option for large multi-cpu cloud instance types that run Linux.

Multiarch on Linux

Most major Linux distributions have a way of setting up binfmt_misc using qemu and other cross-architecture tools. These can be quite complicated to setup and rely on distribution specific knowledge. The Multiarch Project makes setting up binfmt_misc much easier by wrapping the whole process in a Docker image itself called qemu-user-static. This will install and setup the qemu-*-static configurations for all architectures excluding the native hardware.

Installing qemu-user-static using a container requires privileged mode since it will register binaries in the host systems /proc space

To setup qemu-user-static, follow the README, which basically consists of,

🐳 docker run --rm --privileged multiarch/qemu-user-static:register

With qemu-user-static setup, test qemu-user-static support works with a Multiarch image,

🐳 uname -a
Linux jezebel 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux

🐳 docker run -it --rm multiarch/alpine:aarch64-edge /bin/sh
Unable to find image 'multiarch/alpine:aarch64-edge' locally
aarch64-edge: Pulling from multiarch/alpine
ee62da588733: Pull complete
c782b02d60f2: Pull complete
Digest: sha256:17a50d7864c2e052d1c48892252356c1ce9eea26d0a61236072d6c900e5bd6a6
Status: Downloaded newer image for multiarch/alpine:aarch64-edge
/ # uname -a
Linux 62670af32738 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) aarch64 Linux

Building an image is similiar to Docker For Mac, take an existing Dockerfile and replace it’s FROM with a corresponding Multiarch Docker Hub image.

For example to re-build the NodeJS Alpine Image for aarch64,

🐳 curl -sSL https://raw.githubusercontent.com/nodejs/docker-node/c37d5e87fa6d46c0e387f73161b056bbf90b83aa/8.6/alpine/Dockerfile | sed "s/alpine:3.6/multiarch\/alpine:aarch64-v3.6/g" > Dockerfile.nodejs.aarch64

🐳 docker build -f Dockerfile.nodejs.aarch64 -t nodejs:aarch64 .

Considerations

While not as cookie cutter as Docker for Mac, using qemu-user-static makes setting up cross-build environments on Linux much easier than it used to be. This also allows you to use much more powerful x86 hardware (either bare metal or cloud) to quickly build Docker images for other architectures than x86.

The only disadvantage is this method relies on images from Docker Hub that have qemu-*-static binaries added, this makes re-building images more difficult since you’ll need to track down a qemu enabled image.

Known repos that have qemu enabled images,

QEMU on Linux

Both Debian and Ubuntu include the qemu-user-static package that includes statically built emulation binaries for QEMU. Installing the package on a host x86 architecture and bind mounting a qemu-*-static binary will allow the image to run a foreign architecture.

To setup qemu-user-static using the apt on Debian or Ubuntu,

🐳 apt update
🐳 apt install -y qemu qemu-user-static qemu-user binfmt-support

Any architecture that is supported on Docker Hub and qemu-*-static should run by bind mounting the correct qemu binary and using the appropriate Docker image.

QEMU Examples

Run a arm32v7/debian image, bind mount the /usr/bin/qemu-arm-static binary into the container,

🐳 uname -a
Linux jezebel 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux

🐳 docker run -it --rm -v /usr/bin/qemu-arm-static:/usr/bin/qemu-arm-static arm32v7/debian /bin/bash
Unable to find image 'arm32v7/debian:latest' locally
latest: Pulling from arm32v7/debian
d0e027c48353: Pull complete
Digest: sha256:d74cc69431f03bbfbbf9fd52c1eabd6ca491280a03da267acb63b65b81e30c8a
Status: Downloaded newer image for arm32v7/debian:latest
root@7d91bbe1e01b:/# uname -a
Linux 7d91bbe1e01b 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) armv7l GNU/Linux

Run a s390x/debian image, bind mount the /usr/bin/qemu-s390x-static binary into the container,

🐳 uname -a
Linux jezebel 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux

🐳 docker run -it --rm -v /usr/bin/qemu-s390x-static:/usr/bin/qemu-s390x-static s390x/debian /bin/bash
Unable to find image 's390x/debian:latest' locally
latest: Pulling from s390x/debian
2f25bc6ba506: Pull complete
Digest: sha256:b01d35a1891549568b1f5fb66b329dded1e9cd45d6cb74f0c02aeb4c72a1417f
Status: Downloaded newer image for s390x/debian:latest
root@ad7f1fd946fa:/# uname -a
Linux ad7f1fd946fa 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) s390x GNU/Linux

Considerations

Using the apt package for qemu-user-static is much more powerful and flexible than the Multiarch method, however it requires more knowledge and configuration when running a container since each architecture will require it’s qemu-*-static binary bind mounted and a corresponding architecture Docker image.

A disadvantage of this method is it’s only useful for running a container, not building a new image since that would require the FROM image to include the qemu-*-static binary and it’s not possible to bind mount the binary when using docker build. For detailed information on cross-building images see the Docker Libary Official Images documentation.

Known official Docker multi-arch images,

Final Considerations

Cross-building Docker images is different than the recent Docker Hub Multi-arch support announcement in September 2017. That announcement is a feature of Docker Hub where a repository can have a single image name and include multiple architectures in a manifest. This means that when running Docker on any supported hardware with a multi-arch enabled image, Docker will know to use the proper image for the architecture

Before, repositories would either maintain seperate images (eg https://hub.docker.com/u/arm64v8/) or tag images with specific architectures (eg multiarch/debian-debootstrap:arm64-jessie). Now most of this is abstracted away and running docker run -it --rm debian /bin/bash on x86, armhf, or s390x will automatically know what to do without additional configuration.

References

ACI Connector for k8s on a Raspberry Pi Cluster

Tue, 12 Sep 2017 00:00:00 +0000

Intro

Running the Azure Container Instances Connector for Kubernetes on a Raspberry Pi Cluster.

One of the most interesting features of Azure Container Instances is the Azure Container Instances Connector for Kubernetes. This adds an ACI “node” to an existing Kubernetes cluster and allows you to deploy pods to it. This “node” will run pods in ACI without having to create or manage and additional Azure VMs, just point-and-shoot a pod at it and it will run with no additional setup required.

By using the ACI Connector for Kubernetes on a Raspberry PI, a cluster can run homogenous ARM containers on-prem, but still have the ability to deploy and manage x86 containers to a cloud provider.

Read more about Azure Container Instances,

Creating an aci-connector-k8s ARM Image for Raspberry Pi

The upstream aci-connector-k8s image is x86 only, but since it’s written in typescript it can easily be run on different architectures. To run on a Raspberry Pi k8s cluster, all that is required is building an armhf Docker image.

Building a Nodejs ARM Docker Image

Note: As of 9/12/2017 Docker Hub Official Images support multi-platform and re-building an image for armhf (or arm64, ppc64le, and s390x) is no longer required if using a supported image (currently Debian based only, Alpine based like below still need to be re-built).

The aci-connector-k8s Dockerfile uses node:8.4.0-alpine as it’s base image. While there are some “unofficial” node ARM images, lets create one from a somewhat official repository. This involves finding an armhf Alpine 3.6 image, copying/pasting the node:8.4-alpine Dockerfile, replacing the FROM with the armhf version of alpine, and building the image.

There are two ways to build an armhf image,

Build on Raspberry Pi
- 100% native build, less likely to run into bugs
- Painfully slow due to Raspberry Pi hardware
Cross-build using Docker for Mac or Multiarch
- Dramatically speed up builds
- Could have unforseen issues due to running in an emulated environment

After first attempting option 1, two hours later and losing the ability to ssh into the Raspberry Pi, option 2 is a much faster approach. Building on a MacBook Pro using the built-in multiarch features of Docker for Mac works well, but is still slow even on a 4 core system. Fortunately Using up a 24-core Packet.net Type 2 bare-metal instance to cross-compile using Multiarch is easy to do too.

Note: The official Docker images for armhf are arm32v6 and arm32v7. These will work natively on a Raspberry Pi, Docker for Mac, Multiarch, and a Linux system with qemu-*-static support. For full details on these see my post on cross-building Docker images.

A armhf multiarch nodejs Dockerfile was built on the Packet.net Type 2 instance and pushed to Docker hub as ecliptik/node:8.4.0-alpine-armhf. This only took a few minutes using the Type 2 instance, much faster than Raspberry Pi or Macbook Pro.

Example Using Multiarch to re-build a node armhf alpine image,

curl -sSL https://raw.githubusercontent.com/nodejs/docker-node/c044d61e6d02756bb8ed1557b2f0c7a0d7fead6f/8.4/alpine/Dockerfile | sed "s/alpine:3.6/multiarch\/alpine:armhf-v3.6/" > Dockerfile.node.armhf

docker build -f Dockerfile.node.armhf -t ecliptik/node:8.4.0-alpine-armhf .
docker push ecliptik/node:8.4.0-alpine-armhf

Building an aci-connector-k8s ARM Docker Image

Once a nodejs arm-alpine image is created, clone the aci-connector-k8s repositoriy, and update the Dockerfile to use the ecliptik/node:8.4.0-alpine-armhf image. Additionaly, use the Dockefile below to use multi-stage builds for improved image size.

### Base Image
# Setup up a base image to use in Build and Runtime images
FROM ecliptik/node:8.4.0-alpine-armhf AS base

WORKDIR /app
COPY package.json .

### Build Image
# Installs build dependencies and npm packages
# Creates artifacts to copy into Runtime image
FROM base AS build

# Install build OS packages
RUN set -ex && \
        buildDeps=' \
                make \
                gcc \
                g++ \
                python \
                py-pip \
                curl \
                openssl \
        ' && \
    apk add --no-cache \
       --virtual .build-deps $buildDeps

#Copy application into build image
COPY . .

# Install npm packages
RUN npm install -g
RUN npm install --silent --save-dev -g \
       gulp-cli \
       typescript

# Compile typescript sources to javascript artifacts
RUN tsc --target es5 connector.ts

### Runtime Image
# Copy artifacts from Build image and setups up entrypoint/cmd to run app
FROM base AS runtime

# Copy artifacts from Build Image
COPY --from=build /app/node_modules ./node_modules
COPY --from=build /app/*.js ./
COPY --from=build /app/LICENSE ./

# Runtime command
ENTRYPOINT ["node"]
CMD ["connector.js"]

With an updated Dockerfile in the cloned repo, build the aci-connector-k8s image on a Raspberry Pi,

docker build -t ecliptik/aci-connector-k8s:alpine-armhf .
docker push ecliptik/aci-connector-k8s:alpine-armhf

Note: Trying to build the image on non-native armhf platform like Docker for Mac or Multiarch may result in errors like "SyntaxError: Unexpected end of JSON input". The image only seems to build on native Raspberry Pi or ARM hardware.

Running the ACI Connector

Now that we have a armhf image capable of running on a Raspberry Pi, we can deploy the pod to a Raspberry Pi Kubernetes cluster.

First clone the aci-connector-k8s repository onto the Raspberry Pi cluster master,

git clone https://github.com/Azure/aci-connector-k8s.git

Edit the examples/aci-connector.yaml and update the image to use the ecliptik/aci-connector-k8s:alpine-armhf image.

Next, if you used kubeadm to create your cluster and RBAC is enabled, you’ll need to create a role and set it up for the connector. This is discussed in this Github issue that includes creating a RBAC role and updating the service to use it.

Create the RBAC role for the connector,

curl -sSL https://raw.githubusercontent.com/alexjmoore/aci-connector-k8s-arm/master/aci-connector-rbac.yaml | kubectl create -f -

Under spec in the examples/aci-connector.yaml add the RBAC role,

serviceAccountName: aci-connector-sa

Finally after the connector is setup to use the armhf image and RBAC, follow the rest of the Quickstart guide in the aci-connector-k8s README to set up everything else required to run the connector (Azure keys, deployment of service, etc).

Working Example

Updated examples/aci-connector.yaml with RBAC role and ecliptik/aci-connector-k8s:alpine-armhf image

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: aci-connector
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: aci-connector
    spec:
      serviceAccountName: aci-connector-sa
      containers:
      - name: aci-connector
        image: ecliptik/aci-connector-k8s:alpine-armhf
        imagePullPolicy: Always
        env:
        - name: AZURE_CLIENT_ID
          value: 00000-000-00000-0000-0000
        - name: AZURE_CLIENT_KEY
          value: 00000-000-00000-0000-0000
        - name: AZURE_TENANT_ID
          value: 00000-000-00000-0000-0000
        - name: AZURE_SUBSCRIPTION_ID
          value: 100000-000-00000-0000-0000
        - name: ACI_RESOURCE_GROUP
          value: aci-test

Deploy the aci-connector pod,

kubectl create -f examples/aci-connector.yaml

Wait a few minutes while the pod comes into service (mostly waiting for the image to pull) on a worker node.

Verify aci-connector pod has started,

kubectl get pods
NAME                             READY     STATUS    RESTARTS   AGE
aci-connector-1252680567-b88w6   1/1       Running   0          3m

Verify aci-connector node is added,

kubectl get nodes -o wide
NAME            STATUS    AGE       VERSION   EXTERNAL-IP   OS-IMAGE                        KERNEL-VERSION
aci-connector   Ready     2m        v1.6.6    <none>        <unknown>                       <unknown>
navi            Ready     1h        v1.7.5    <none>        Raspbian GNU/Linux 8 (jessie)   4.4.50-hypriotos-v7+
tael            Ready     1h        v1.7.5    <none>        Raspbian GNU/Linux 8 (jessie)   4.4.50-hypriotos-v7+
tatl            Ready     1h        v1.7.5    <none>        Raspbian GNU/Linux 8 (jessie)   4.4.50-hypriotos-v7+

Deploy example/nginx-pod.yaml pod from aci-connector-k8s repo,

kubectl create -f examples/nginx-pod.yaml
pod "nginx" created

Verify pod deployed and is running in ACI,

kubectl get pods -o wide
 NAME                             READY     STATUS    RESTARTS   AGE       IP               NODE
 aci-connector-1696751608-tcjcq   1/1       Running   0          24m       10.244.2.4       tael
 nginx                            1/1       Running   0          10s       104.42.235.280   aci-connector

General Docker on ARM Links

While researching and setting this up I came across many good resources on running Docker on ARM,

ARM Docker Image Repositories

arm32v6 - Works on RPI 3 with HypriotOS 32-bit
arm32v7 - Works on RPI 3 with HypriotOS 32-bit
arm64v8 - Currently no 64-bit version of HypriotOS, but will work on Packet.net Type 2A Instances

micheal@ecliptik.com

Vibe Coding a Fluxbox Inspired Wayland Compositor

Why a Wayland compositor?

The build

The moment it clicked: team orchestration

The team structure

The QA/dev feedback loop

The screenshot debugging breakthrough

What worked

What didn’t work

What I’d tell someone starting their first agentic project

Three Days with Claude Code

What is Claude Code?

The Starting Point

Performance Wins

Progressive Enhancement

Social Media Previews

Accessibility Improvements

Small Web Protocol Generation

Security and SEO

Working with Claude Code

Challenges and Limitations

Results

Final Thoughts

Surfing GlobalTalk with a Macintosh 512Ke

LocalTalk, GlobalTalk, TashTalk, Oh My

Networking

TashRouter

An On-ramp to The Information Superhighway

Putting it All Together

Gotchas

Stretch Goal

References and Links

Live, Laugh, Localtalk with Basilisk II

Installing Basilisk II

Setting Up Basilisk

Using Basilisk

Wireless LocalTalk

Conclusion

Enhancing my Macintosh 512Ke

FloppyEMU

USB4VC

Macintosh Plus Logic Board

BlueSCSI

PicoRC

Cooling

RGB2HDMI

TashTalk 2

Basilisk II

ROMinator

Thoughts

A Macintosh Story

Releasing the Magic Smoke

FloppyEMU

HD20

No Keyboard Detected

Input/Output

Switching to Ghostty

Ghostty 👻

Initial Impressions

Customizing the Config

Graphics

After Two Weeks

DNS Guardrails with dnscrypt-proxy

Intro

Guardrails

Container Stack

dnscrypt-proxy

Exposing via Tailscale

Enabling on Linux Mint

Tailscale on the DevTerm R-01

Intro

Building a TUN/TAP Kernel Module

Installing Required Packages

Cloning ClockworkPi Kernel Source

Setting Up Build Toolchain

Existing Kernel Config from DevTerm

Enabling CONFIG_TUN

Building the Kernel

Setting up New Modules on DevTerm