Tim's blog (Posts about openbsd)

Old Computer Challenge

Tim Chase — Mon, 10 Jul 2023 13:52:33 GMT

History

This is the third year in which Solene has run the Old Computer Challenge and I've tried to participate in each of them.

Participating in these requires a little flexibility since I work remotely for $DAYJOB. The low-end computer challenges posed less issue since neither the VPN nor rdesktop required much in the way of resources. Using the smaller screen-dimensions on the older laptops made it a bit more challenging, but I made it work.

None of these challenges shifted any usage to my phone. I prefer not to use my phone for anything beyond the barest of essentials: phone-calls, texting, podcasts, timers, lists, and weather.

First year (2021)

The first year and third year both focused on limited hardware,

I chose a Gateway Solo 1200 as my primary machine for the first year. Boasting an 800MHz Celeron processor, a 120GB spinning-rust HDD, a 10mbit wired LAN connection (it also had an internal wi0 wireless card and a PCMCIA Intel wifi option, but both only supported WEP rather than WPA2 so I stuck with the wired option), and upgraded to its maximum of 320MB of RAM. This machine infamously arrived on 9/11 with the UPS driver delivering it as I watched the twin towers fall on TV.

The machine ran the latest release of OpenBSD without issue. The limited CPU & RAM limited my choice of software notably. Fortunately, other than web-browsing, much of what I do happens at the command-line.

Email: I had used Claws Mail (a GUI mail program) for many years but it started using more and more system resources. So I had aspired to switch to mutt or neomutt. The Old Computer Challenge gave me the kick I needed. Dealing with multiple accounts and catch-all mailboxes posed the worst pain-points. Otherwise, it ran fine within the limited system resources. And they provide a lot of power to mow through piles of email.
Music: I've long used cmus for playing my music collection, and pianobar for streaming. Both ran fine even on this ancient hardware.
Calendar: I've moved my calendaring to remind and it runs fine at the CLI. It did have a noticeable lag on startup but I suspect that my 3000+ reminders/events cause that. When I winnow it down to a much more sensible volume of reminders, it runs in a blink.
Coding: All my coding happens at the CLI using a mix of vi, vim, and ed for editing, and doing version-control with git or rcs so not much changed here. I did find notable startup lag both in starting vim and executing Python code. It made me appreciate the fast startup times for utilities that compiled down to native code. I also found myself using awk in a lot of places since it had a faster startup time than Python.
RSS: I've long used rss2email to gather my RSS feeds and deliver them to my inbox, reducing the RSS-reader issue to a mail issue. I experienced no disruption here, since mutt let me keep reading my feeds just as I had done in Claws.
Social media: I accessed Twitter with Rainbowstream, Mastodon with Tootstream, and rtv (now obsolete) for Reddit. For text posts and commenting, I loved them all. But for image/video posts, they fell short. I wish I had a quality CLI interface for Facebook to keep in touch with friends & family who only share things there.
Office stuff: Thankfully, I don't have to deal with Office documents often. And almost never outside of $DAYJOB so I could use Word or Excel remotely. I did install Abiword for the occasional MS-Word document and Gnumeric for the occasional spreadsheet. Both provided reasonable fidelity and speed while running within the confines of the limited hardware.
Gaming
: I don't game much, so this didn't impact me much. I think I played a couple rounds of cribbage(6) and atc(6) as a proof-of-concept, but certainly no high-end FPS games here.

Web browsing hurt the most. Firefox & Chromium? Completely unusable without gobs of RAM. For some basic browsing, lynx and dillo provided lightweight options, while Epiphany clocked in at barely-usable (but still better than Firefox & Chromium) for sites requiring JavaScript.

Second year (2022)

The second year focused more on limiting network usage (both total-time and bandwidth).

I had to segregate life here since $DAYJOB requires remoting into my work machine so I didn't count that time against my allotted 1hr.

I didn't know how to count my cron job that downloads my podcasts nightly since I don't have much control over how long they run or how much data they download. I decided that, since the challenge only ran for a week, and I batch podcasts roughly every three weeks, I could load a fresh batch to my player before the challenge, disable the cron job for the week, and then re-enable the cron job after completing the challenge. Not quite the spirit of the challenge, but also a lot like how I would download things in high-school, where I would walk to the local campus library to download large files and bring them home.

Email didn't pose a great concern, since OfflineIMAP let me batch download my emails from the server, and my local MTA would batch up outbound emails until I reconnected, sending them all to my smart-host mail-server in one go.

However, the second year really cut into social-media usage. Its model simply doesn't accommodate offline use well.

Third year (2023)

Similar to the first year the tools remained largely the same. However this year I did the challenge while on vacation. Cheating? Maybe. But also enforcing since I didn't take any other laptop. This time I took a Dell Mini10 netbook with me. This hand-me-down came to me with 2GB of RAM, but I'd made a few upgrades:

replaced the 120MB HDD with a 60GB SSD giving a bit of extra pep
replaced the rubbish Broadcom wireless half-height PCI card with an Atheros chipset
installed OpenBSD 7.3 in place of Windows Vista

The netbook has no fan, relying on passive cooling instead. This meant that using apm -L kept the system running cool. I could manually apm -H to get the full 1.x GHz but it came with a warm price, discouraging me from doing so.

The tiny 1024×600 screen resolution gave even greater constraints when remoting into $DAYJOB but, that helped me stay in vacation-mode rather than try to sneak in hours. Additionally, X seemed to think the display offered 1024×768 resolution, so everything rendered with a squishing/scaling that ruined friends' pictures. And equally bad, the Poulsbo chipset lacked support in X, so it rendered very slowly using VESA. But I had times where I could watch text render character-by-character, and could type full paragraphs of text before the first couple words appeared on the screen. With better graphics-support, I suspect it would have felt notably snappier.

Future challenges

After returning from that vacation, I purchased a new laptop for travel, and got rid of four of my old junker laptops (my beloved rejoices at fewer laptops on my desk). I still have the Mini10 and a PPC iBook G4 running OpenBSD, so I can participate in future challenges.

chrooted SFTP

Tim Chase — Mon, 30 Aug 2021 19:35:08 GMT

Creating `chroot` SFTP accounts

For $DAYJOB I had to create user accounts for customers and give them access to SFTP files to/from secured areas of our server. We wanted to use chroot functionality to ensure that no customer could see other customers' data, and prevent them from poking around potentially sensitive areas of the server. After a bit of trial-and-error, I've listed the lessons-learned here in a cook-book fashion so that in case I ever have to do it again, I have the steps documented.

This post was spurred to exist thanks to this Reddit post asking about creating an encrypted FTP server on OpenBSD so my reply there became the basis for this post.

Steps to reproduce

create the "sftp users" group, which I'll refer to here as customers
```
root# groupadd customers
```
create the new user. For this example, I use "acmecorp" but I define the variable $NEWUSER and use it throughout the rest of this post:
```
root#  adduser
root#  NEWUSER=acmecorp
```
add them to the customers group when prompted for the "other groups" or, if you have a pre-existing user, use
```
root# usermod -Gcustomers $NEWUSER
```
to put them in their own chroot we need to create a fake hierarchy in /home/$NEWUSER/ so we'll end up with /home/$NEWUSER/home/$NEWUSER/

make a temporary "user" directory and create the fake /home inside that

root# CHROOT="$(mktemp -d -p /home)"
root# mkdir -p "${CHROOT}/home/"

set the permissions & ownership on that fake hierarchy:

root# chown -R root:wheel "$CHROOT"
root# chmod -R 0755 "$CHROOT"

move the user's old home directory under the chrooted /home
```
root# mv -v "/home/$NEWUSER" "$CHROOT"/home/
```
and then rename the chroot back to the original /home/$NEWUSER directory
```
root# mv -v "$CHROOT" "/home/$NEWUSER"
```
while a bit confusing, I found that some users expected to have $SFTP drop them in / and be able to do a relative cd home/$USER while others expect to be dropped in their $HOME so by adding a fake home/$USER that points to the right place, it allows for both of these. This might be optional, but helps me stave off customer script breakage:
```
root# mkdir -p "/home/$NEWUSER/home/$NEWUSER/home"
root# ln -s .. "/home/$NEWUSER/home/$NEWUSER/home/$NEWUSER"
```
It might also stave off issues with the next step, since the home directory in /etc/passwd can point to /home/$NEWUSER/home/$NEWUSER regardless of whether in the chroot or not and still point to the right place.
we've messed with their home directory, so update /etc/passwd to reflect where things should find the home directory now
```
root# usermod -d "/home/$NEWUSER/home/$NEWUSER" "$NEWUSER"
```
now the user is configured properly, so let sshd know how to treat members of the customers group. Edit your /etc/ssh/sshd_config to include this block at the end:
```
Match Group customers
   ChrootDirectory /home/%u
   ForceCommand internal-sftp
   PermitTunnel no
   AllowTcpForwarding no
   AllowAgentForwarding no
   X11Forwarding no
```
/etc/ssh/sshd_config
I don't know whether ForceCommand kills off the ability to do PermitTunnel, AllowTcpForwarding, AllowAgentForwarding, X11Forwarding, but I prefer to be explicit in my "just in case, no, you can't do that either".
Send a SIGHUP to sshd to pick up the new configuration:
```
root# kill -HUP $PIDOFSSHD
```
or use your system's reload configuration utility like rcctl on OpenBSD to pick up the new configuration:
```
root# rcctl reload sshd
```

And with that, you should have chrooted SFTP access for $NEWUSER

user$ sftp user@hostname

(if not, check the tail of your /var/log/authlog for hints). However if you try to ssh, scp, or rsync, it should reject your efforts at the point you've entered your credentials:

user$ ssh user@hostname
Password:
Permission denied, please try again.
⋮

user$ echo test > delme
user$ scp delme user@hostname:
Password:
Permission denied, please try again.
⋮

For additional customers, you can repeat steps 2 through 9. I've created a shell-script to do those steps as well as a bit of other administrivia for $DAYJOB but that should give you the basics.

Green terminal theme on OpenBSD

Tim Chase — Tue, 20 Feb 2018 14:23:22 GMT

Inspired by a recent post on Reddit where someone created an amber monochrome theme on OpenBSD running CWM I decided to undertake a similar venture to do a green-on-black theme for CWM on OpenBSD.

Terminal font

First, I wanted a font that looked a bit more like the classic terminal fonts I remembered from the 80s so I found DOS terminal font (direct link) which provides classic VGA fonts.

To install them, first I needed to install unzip with doas pkg_add unzip to uncompress them. Next, create the font directory where X will pick up the new fonts mkdir -p ~/.local/share/fonts/ dump the fonts there, and instruct X to pick up the new fonts:

$ ftp -o dos_fonts.zip https://dl.dafont.com/dl/?f=perfect_dos_vga_437
$ unzip dos_fonts.zip
$ fc-cache -f

Then I configured my ~/.Xdefaults to use green-on-black and my custom VGA font just about everywhere. It also sets a few other preferences like how much scrollback an xterm stores, where it appears by default, and whether the scrollbar is visible.

$ cat ~/.Xdefaults
*Background: black
*Foreground: #00c000
*HiBackColor: green
*HiForeColor: black
*faceName: Perfect DOS VGA 437:size=10
*font: Perfect DOS VGA 437:size=10
XTerm*loginShell:true
XTerm*saveLines: 5000
XTerm*geometry: 80x25-0+0
XTerm*scrollBar: false

Next, I configured my ~/.xinitrc to set either my black wireframe image of Puffy as the background or set it to solid black if feh isn't installed. I usually link ~/.xinitrc and ~/.xsession so that it works whether I launch it from xdm/xenodm or by using startx on the command-line.

$ cat ~/.xinitrc
xrdb -m $HOME/.Xdefaults
#disable the beeper
xset b off
# set the background
feh --bg-fill puffy.png || xsetroot -solid black
# start a few apps
xconsole -geometry +0-0 &
xterm &
# launch cwm
exec cwm

Finally, for the window manager trappings, I set my colors to various greens and blacks.

$ cat ~/.cwmrc
sticky yes
borderwidth 1
# border colors
color activeborder green
color inactiveborder darkgreen
color urgencyborder green
# menu colors
color menubg black
color font green
color menufg green
color selfont black

Restarting my X session brought everything up in a delightful green-on-black that looked a little something like this screenshot.

Configuring `xenodm`

Now, it's nice if your personal X session is green-on-black, but what if you want the xenodm login to also display green-on-black? Well, we can do that too. Before starting, I like to take snapshots of the files I'm editing in case I hose them:

# cd /etc/X11/xenodm/
# mkdir RCS
# ci -l Xresources
# ci -l Xsetup_0

First, all the foreground and background colors in /etc/X11/xenodm/Xresources should be tweaked for various shades of green. Some parts of the file allowed setting the color based on the display's bits-per-pixel, so for high color-depth, I chose more nuanced colors, while for the lower color-depth, I stuck to darkgreen and green. While in there, you can also change the logoFileName properties to point to the green-on-black wireframe image of Puffy if you have one.

Then, in Xsetup_0 above the line that launches xconsole I like to specify xsetroot -solid black to get a black background as well.