Skip to main content

My first AUR package

So, this is probably not a huge deal, but I prepared and submitted an original new package to the AUR today. The process was a little esoteric, but the wiki page is straightforward if you read closely.

My new package is a simple alternative to the venerable less called les (no joke). I’ve been on the lookout for “new” versions of “old” system utilities, and this one is somewhere in the middle. It doesn’t have fancy auto-coloring capabilities; but does have tabs, a scrollbar, unicode, better searching and gooder keybinds. Give it a try! (it’s super easy to compile yourself if you aren’t on Arch, I’ve been using it a few days on MacOS also.)

You can find the source at github.com/zorgnax/les and my AUR package (les-git) is over here!

Any recommendations on cool “new” system utility projects? Ping me over on Mastodon – https://fosstodon.org/@bhart

A curious case of DNS tomfoolery

Preface: I self-host several web services on a small server inside my home. This leads to some oddness when it comes to accessing those services from within the network, because all of my domain names are pointed to public IP addresses.

The “easy” fix for this is called Split-horizon DNS , or just split DNS for short. Basically, run a DNS server inside the network that returns internal IP addresses for the specified hostnames.

So I did that. First I did it on my pi.hole, but the hostnames still resolved to the external IP. So I tried on my pfSense firewall, and got the same outcome. This was baffling because both pfSense and pi.hole are mature products and this is a very simple ‘well-known’ feature.

I left the settings in place on the pfSense, and queried for the hostname from the pfSense and it worked fine. Eventually I tried several other devices and they all worked fine.

In fact, everything worked fine except for my work Macbook . It always returned the external IP.

I was frustrated and confused, but figured that IT put in some sort of “block and redirect” to their own DNS servers. Eventually I checked /etc/resolv.conf on the Macbook and found that something kept invisibly setting the OS to use 127.0.0.1 (aka localhost) as the only DNS server. Hmph. A few cryptic commands (why no useful netstat, Apple?) later and I was looking at the application that was listening on port 53 (DNS) on localhost: a dnscrypt executable included with the Cisco VPN client.

Well, I guess that makes sense. dnscrypt is a useful open-source application to do exactly this: proxy DNS requests over an encrypted connection to a specified DNS server. Encrypted DNS to known servers for the VPN connection. Except that killing the process it just makes it restart, and closing the VPN client leaves it running. I’m not going to futz with a company installed VPN client. I’ll just admit defeat at this point.

The pi.hole was probably working all along, but by that time I had blown up the config – so I set up pfBlockerNG instead, which is a native pfSense package that has a similar purpose (blocking ads), but also has additional powerful features. A topic for another post.

Scifi Friday: Exhalation

I’m going to try a theme here: posting about scifi on Fridays. It probably won’t be every Friday because.. who has time for that? But I come across really poignant thoughts while reading, hearing, or watching scifi. And I like sharing.

Note that these little thoughts and reviews will contain spoilers. I want to talk about content and ideas, not entice you to read the book. So don’t read on until you’ve read/heard/uploaded the story. (Or… maybe you like spoilers cause TLDR? Thanks, ADHD…)

So, without further ado, I present:

Exhalation

by Ted Chiang

I discovered this book by perusing Escape Pod’s recommended stories for new listeners. Ted Chiang released a compilation of stories under the same name, so finding the individual story (which is presumably the namesake) is a little difficult. That said, the Escape Pod audio version is easy to find and perfect to listen to during a nice cool fall stroll through the park. There is also a full text available , helpfully preserved by the Internet Archive.

As I mentioned in the intro, I found the parallels between this fictional setting character and our real world to be extremely poignant. As the protagonist examines their own “brain”, they realize a couple stark truths:

  1. Though the mechanism by which it’s brain functions is fundamentally and elegantly simple – compressed air directed through a maze of flip-flopping metal leaves – it can never be started again if it stops because it would require a complex configuration of every leaf before the air could make it function. It follows that the function of the brain would depend greatly upon its initial state.

  2. Everything they know is contained inside a gigantic sealed dome, and as they all “exhale” air, the dome slowly pressurizes. Eventually the air source and the dome will read equilibrium and everything will stop.

Now I don’t believe in fate, and (I think) I believe in agency. But it’s helpful to remember that my brain, and everyone else, are just a jello full of neurons that control a bunch of muscles and organs. And each brain is originally formed according to a genetic blueprint, then modified by a life full of fear, greed, joy, and pleasure. It’s easier for me to see mistakes as accidents and insults as unintended consequences with this in mind. On the same hand, it makes me wonder if I have as much control over my future as I think.

As for the second realization, isn’t the parallel dreadfully obvious? We’re burning, eating, chopping, and polluting our way through thousands of years worth of natural resource reserves. Faster than the earth could ever keep up with. The pressure is certainly rising, and we better hope there’s a way out of the dome.

There’s also a more philosophical and less applicable parallel in the thought that everything that sustains life is dependent on energy sources which are not infinite. Heat from the sun, momentum of the planets, heat in the center of the earth, etc. The scale of this is outside of comprehension, but it’s fun to try.

Adafruit ItsyBitsy 32u4 issues on Archlinux

A couple months back I started working on an “Okay to Wake” clock for my son.

Yeah, yeah, honey – I know I could just buy one on [insert website named after rainforest], but that’s no fun.

I decided on an ItsyBitsy 32u4 for a few reasons; inexpensive, more powerful than a Pro Micro, lots of PWM pins, ‘native’ USB, etc. It’s also really tiny.

Anyway, it should just be plug-and-play on any Linux machine, but instead… it’s had issues with all my computers, covering Windows 10, Fedora, and Archlinux. Maybe it’s just a finicky device? I don’t know, but I figured out how to get it working with my Archlinux install after way too long spent on troubleshooting.

The main issue I had was due to permissions on the /dev/ttyACM0 device. In Arch, the default ownership is root:uucp with wr-wr---- , so you would think ‘add your user to uucp and off we go’… but no. After power-cycling into the bootloader mode, for only a short second, the device is set to root:root and wr-------w , so it doesn’t matter which groups my user is in, I can’t access it. That results in this nice error when I try to upload to the board:

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/brandon/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/etc/avrdude.conf"
         User configuration file is "/home/brandon/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyACM0
         Using Programmer              : avr109
         Overriding Baud Rate          : 57600
avrdude: ser_open(): can't open device "/dev/ttyACM0": Permission denied

avrdude done.  Thank you.

I chased a theory for way too long on this: the bootloader enumerates with a difference USB productID , so I figured my system needed a udev rule added to set the permissions correctly for the bootloader device. A couple hours of learning udev rules and I realized that the device, no matter what I did, would always be root:root for a short time after. I finally did get a udev rule to set the user and group, and the permissions to rw-rw-rw- , but it wasn’t instant so the device was still locked off to avrdude .

The easy way

Eventually, I ended up in the #arduino channel on freenode asking, when I realized that I just need the IDE to wait a moment before trying to upload the code using avrdude . I was looking around in the Arduino IDE code for where it calls avrdude, when a moment of clarity came:

replace the avrdude executable with a script that waits a second, then calls avrdude.

Yup, that’s what this whole post leads up to. I hope it’s helpful to someone. Here are the (very simple) two steps to fix this issue if you hit the same problem:

First, move the avrdude binary in the Arduino folder, the path will change with new IDE releases:

$ cd ~/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino17/bin/
$ mv avrdude avrdude-bin

Then, create this script named avrdude instead:

#!/bin/bash

sleep 1
$0-bin "${@:1}"

Now the Arduino IDE will have to wait one second after noticing that /dev/ttyACM0 exists before trying to upload your code, and hopefully the device has settled by then. You can try increasing the sleep duration if you still have issues, but it really shouldn’t require longer than 2 seconds – you likely have a different problem if 2 doesn’t work.