Nov. 27 — Managing passwords in 9front

In what is now a three‐part "series" on various aspects of migrating to 9, I've been writing more little scripts that utilize third‐party utilities to add a bit more flair to my daily experience. Some of those tools have been simple graphical menu widgets like dmenu and fm. While they both do essentially the same thing, there are some minor differences such as the inability to change the prompt of the latter.

Both my home and mobile grids run a secstore(1), and this allows me to easily retrieve arbitrary files through a password‐protected connection to a running factotum(4). While I can already store passwords for certain websites and services in the file that is sourced by default at startup, I find myself needing to type in passwords manually when using others. I decided to use the aforementioned menu widget to make a sort of bastard imitation[1] of a password manager like KeePassXC. It stores a simple text database with the following tab‐separated fields:

dom=http://example.com user=jdoe pass=$up3r$3kr1t

Adding new entries is as simple as running:

% ipso pass

Multiple accounts can be defined for the same domain. Now running passmenu will give me a nice little menu[2] of available domains with the associated usernames in parentheses. Selecting one will inform the user that the password has been snarfed and after a delay will clear the snarf buffer. I run it in my riostart or equivalent like so:

window ‐r 968 633 1568 833 ‐hide 'LABEL Passmenu; rc ‐c ''while(){ passmenu ‐n >[2]/dev/null }'''

This will create a persistent hidden window with a label of Passmenu that will just sit there until I need it. It's been working well enough for the past few weeks, so take that for what it's worth.

1. /rc/passmenu
2. /img/passmenu.png

Nov. 17 — Managing third‐party packages in 9front

I've been growing tired of manually handling random software, so I decided to find a simple way to automate the process and ended up making a sort of "package manager" for 9front. It's really just a set of shell scripts that act as a frontend for git(1) and keep a simple database of package names and URLs.

Running the pkginit script[1] will ask for a location to store the source files for installed packages (/sys/pkg by default) which will then be created if non‐existent.

And that's it! No, really. Now you can provide a URL for a git repository to pkg/add like so:

% pkg/add gits://shithub.us/bubstance/gridchat

This repo will then be downloaded to the package store, built/installed/cleaned with mk(1), and added to .pkglist. Multiple URLs can be provided to download multiple packages at once.

Removing packages is handled by pkg/del using package names instead of URLs:

% pkg/del gridchat

This will perform mk uninstall followed by removing the source directories and purging entries from .pkglist.

Managed packages can be listed with pkg/ls. Adding the ‐c flag will show a count of packages instead.

Finally, updating packages is handled by pkg/up, which fetches the latest version of the repository and performs the same mk operations as pkg/add.

Notes:

• Packages without an uninstall target in their mkfile will cause pkg/del to exit without removing sources or purging the .pkglist entry. Tell the authors that they should add one. ☺
• Entries in .pkglist that lack a corresponding source directory in the store will be pulled automatically when running pkg/up. This means that a pre-generated[2] .pkglist can be placed in the store after initialization to quickly install the entire list of packages with a single incovation of pkg/up.
• Packages are updated in the order in which they were installed. For this reason, a package like npe should be installed before packages that depend on it; e.g., uxn.

Future:

• Find way to skip building packages that have no updates.
• Find way to silence output from mk for a quiet option.

1. /rc/pkginit
2. /lib/example_pkglist

Feb. 9 — Managing my RSS feeds in 9front

After getting by for the most part with only the most basic 9front cpu server setup, I recently decided to start exploring the different capabilities of auth‐specific systems like secstore(1) and cron(8). Article on secstore to come, but in the meantime I figured I would write about what I've learned regarding using 9front's cron system to schedule basic tasks.

In my search to transfer even more of my day‐to‐day computing tasks over to my 9front machine, I realized that there was one key piece of software that I was still missing: an RSS feed reader of some kind. In the search for options, rrss(1) and rssfill came up repeatedly while searching.

While rrss looked to be very slick and robust with its full browser‐based feed, I didn't really need all of the bells and whistles for the time being. I instead went with the rssfill approach, mostly because it seemed like it could be easily reproduced without much fuss involved by using the built‐in functionality of the news(1) program. It also is written in C as opposed to Go, which can be nice if one doesn't wish to install an entire extra language on their machine — not a jab at Go, of course; I love Go.

Once I had downloaded and compiled the program, I looked at the provided example script for fetching feeds. It was perfectly suitable, but I wanted to split things up a bit and have a separate list of feeds that would be easier to edit in the future. I cobbled together my own little newsup script[1] in a minute or two and went about setting up cron.

The cron daemon (auth/cron) needs to be run on an auth server. My current testbed system is a Thinkpad T420 running as a combination auth+cpu+fs server, so it was as simple as adding the following to the file /cfg/$sysname/cpurc:

auth/cron >>/sys/log/cron >[2=1] &

and rebooting. This was followed by running auth/cron ‐c to create the appropriate file for my user in /cron/$user/cron and opening trusty ol' sam to add another single line:

1 1,3,5,7,9,11,13,15,17,19,21,23 * * * local cron/newsup

This will run my newsup script every two hours every day of the week. The local bit runs the specified command on — you guessed it — the local machine as opposed to an alternate known host, which is another great example of the flexibility found throughout the system. After placing newsup into a new $home/bin/rc/cron directory and writing out my feedlist[2] as $home/lib/feeds, I waited a few minutes and then ran news. It worked first try — a nice list of articles and git commits to browse along with the joy of knowing that I can now ditch yet another aspect of my non‐9 computing.

1. /rc/cron/newsup
2. /lib/feeds

Jan. 2 — A brief story about an eclipse

I was looking through some old boxes today and found something interesting.

During the "Great American Eclipse" of 2017 I was working at a horrible job in a state where we only saw around 70% coverage. I wasn't able to take a proper photo for various reasons, and right at the time that we were going to get the best view I was completely swamped with paperwork deep in a room with no windows.

While I was scribbling away, my coworker — a man who on every other day hated my guts more than any other person I have ever met — put his hand on my shoulder from behind, motioned for me to follow him, and made me walk outside. He then handed me a viewer[1] he had made by taping together some scrap cardboard and a piece of welder's glass.

I was in a particularly bad place mentally at the time, so it meant a lot to me that he went out of his way to do something like that, no matter how seemingly insignificant it may have been.

In lieu of that eclipse photo I wasn't able to take, here's a plot[2] made using astro(7) and scat(7) of the view as I would have seen it from my house.

1. /img/alex_mask.jpg
2. /img/2017‐08‐21_plot.png