OpenBSD Archive

Printing with CUPS on OpenBSD

Printing on Linux, macOS, and even on Windows seems to be pretty much a solved problem, but what about printing on OpenBSD? Anyway, to do so I would need to set up my HP OfficeJet printer, connected wirelessly to the network, on OpenBSD. I chose to do this using HPLIP and CUPS as they are both in ports, I am familiar with how they work, and my printer is old enough that its PPD (driver) file is included in the slightly older version of HPLIP that is ported to OpenBSD. However, after installing both packages, starting the relevant services via rcctl including Avahi, and launching CUPS and finding the printer, I could not get it to install properly. Either it would error out at the end saying the printer couldn’t be added and advise me to check the CUPS error log, or it would seemingly successfully add the printer but I couldn’t print anything and couldn’t adjust the printer settings. ↫ Morgan at his blog Only very tangentially related, but my personal crowning achievement in computing is somehow making it possible for my PA-RISC c8000 workstation running HP-UX 11i v1 to print to my modern all-in-one HP printer thing, some random HP consumer junker we bought on a whim because it was a returned item and cheap. It took some messing around, but ever since I’ve been able to just print stuff right from any application on HP-UX over the network, wirelessly. Note that the c8000 and HP-UX 11i v1 are almost two decades out of date compared to the printer, but by trying out promising device files included in HP-UX I managed to get it all to work. I never need it, but I am fairly sure I’m one of the very few people in the world who can reliably print from an HP-UX 11i v1 workstation to a modern throwaway HP junker over Wi-Fi. Put that on my tombstone.

OpenBSD 7.9 released

The world’s best BSD (I’m kidding, I love them all equally) has released version 7.9, now available through your update tools and on mirrors the world over. OpenBSD 7.9 brings a ton of changes, fixes, and improvements, such as delayed hibernation support on amd64. This will allow OpenBSD laptops to briefly wake up from sleep, to then immediately drop into hibernation. A small but incredibly welcome change is that sysupgrade will now handle low space on /usr more gracefully, which will make quite a few people who once hit that limit very happy. OpenBSD 7.9 also brings VA-API and open Widevine support to its Chromium (and derivatives) port, and OpenBSD can now run as a guest under Apple’s hypervisor for M-series Macs. There’s initial low-level support for the FUSE API, the maximum support processor count on amd64 has been raised from 64 to 255, there’s improved support for managing complex core configurations in the scheduler, and many more changes. There’s also the usual new versions of LibreSSL and OpenSSH, of course, but that’s a given.

OpenBSD and slopcode: raindrop to a torrent?

Every single software product is dealing with the question about what to do with “AI”-generated code, but the question is particularly difficult to answer for open source operating systems like Linux distributions and the various BSDs, which often consist of a wide variety of software packages from hundreds to thousands of different developers. On top of that, they also have to ask the “AI” question for every layer of their offering, from the base install, to the official repositories, to community-run ones. As users, we, too, are asking these same questions, wondering just how much “AI” taint we’re willing to spread across our computers. I understand the difficult position Linux distributions are in with regard to “AI”. I mean, when even the Linux kernel itself is tainted by “AI”, a no-“AI” policy is basically an empty gesture for them at this point. Personally, I find a policy of “we don’t do ‘AI’ in our work, but we don’t have control over the thousands of components we consist of” to be an entirely reasonable, if deeply unsatisfying, position to take. What else are they going to do? You can’t really be a Linux distribution without, you know, the Linux kernel, which is, as I’ve already said, utterly tainted by “AI” at this point. Still, in the back of my mind, I always had a trump card: if all else fails, we’ll always have OpenBSD. Its project leader Theo de Raadt is deeply principled, every OpenBSD user and contributor I know hates “AI” deeply, and the project routinely sticks to their principles even when it’s difficult or inconvenient. Yes, this makes OpenBSD not the most ideal desktop operating system, but I’d rather use that than something that embraces the multitude of ethical, environmental, quality, and legal concerns regarding “AI” code completely. Imagine my surprise, then, to discover that OpenBSD already contains slopcode in its base installation, with the project’s leaders and developers remaining oddly silent about it. My friend and OSNews regular Morgan posted this on Fedi a few days ago: Nearly six weeks later, and the question of whether “AI” generated code in tmux — not tool-assisted bug finding, not refactoring, actual LLM-generated slop with questionable license(1) — that was consequently merged into OpenBSD base, is considered acceptable by the lead devs, remains unanswered. Despite Theo de Raadt’s concrete stance against any code of questionable license origin polluting the project — and the tmux merge was indeed questionable — it seems this is being swept under the rug. This makes me extremely uncomfortable; it’s like seeing a fox in the henhouse but the farmers are all looking the other way and no one can convince them to admit they can see it and root it out. I really don’t know what to do being just a user; I feel like even if I tried to chime in on the mailing list I would just be ignored like the others trying to raise the alarm. I hope, as they do, that this is being discussed internally, away from the public list, and that a positive outcome is near. Maybe they are waiting for the 7.9 release before setting anything in stone. Or maybe the “AI” disease has infected one of the last pure operating system projects we have left and there’s no going back. ↫ Morgan on Fedi I obviously share Morgan’s concerns, and like him, I’m also afraid that opening the door to a few drops of slop in base will quickly grow into a torrent of slop as time goes by. Yes, it’s just a patch to tmux, but it’s in base, and the “base” of a BSD is almost a sacred concept, and entirely the last place where you want to see code that raises ethical, environmental, quality, and legal concerns. For all we know, this patch of slop or the next one contains a bunch of GPL code because it just so happens that’s where the ball tumbling down the developer’s pachinko machine ended up. GPL code that would then be in the base of a BSD. I echo the call for the OpenBSD project to address this problem, and to set clear boundaries and guidelines regarding “AI” code, so users and developers alike know what level of quality and integrity we can expect from OpenBSD and its base installation going forward.

Running a Plan 9 network on OpenBSD

This guide describes how you can install a Plan 9 network on an OpenBSD machine (it will probably work on any unix machine though). The authentication service (called “authsrv” on Plan 9) is provided by a unix version: authsrv9. The file service is provided by a program called “u9fs”. It comes with Plan 9. Both run from inetd. The (diskless) cpu server is provided by running qemu, booted from only a floppy (so without local storage). Finally, the terminal is provided by the program drawterm. The nice thing about this approach is that you can use all your familiar unix tools to get started with Plan 9 (e.g. you can edit the Plan 9 files with your favorite unix editor). I’m assuming you have read at least something about Plan 9, for example the introduction paper Plan 9 from Bell Labs. ↫ Mechiel Lukkien If you’re running OpenBSD, you’re already doing something better than everyone else, and if you want to ascend to the next level, this is a great place to start. Of course, the final level, where you leave your earthly roots behind and become a being of pure enlightened energy, is running Plan 9 on real hardware as the universe intended, but let’s not put the cart before the horse. One day, all of humanity will just be an endless collection of interconnected cosmic Plan 9 servers, more plentiful than the stars in the known universe.

The OpenBSD init system and boot process

In recent weeks, systemd has both embraced slopcoding and laid the groundwork for age verification built right into systemd-based Linux distributions, there’s definitely been an uptick in people talking about alternative init systems. If you want to gain understanding in a rather classic init system, OpenBSD’s is a great place to start. OpenBSD has a delightfully traditional init system, which makes it a great place to start learning about init systems. It’s simple and effective. There’s a bit of a counter movement in the IT and FOSS worlds rebelling against hyperscaler solutions pushing down into everyone’s practices. One of the rallying cries I’ve been seeing is to remind people that You Can Just Do Things™ on the computer. The BSD init system, and especially OpenBSD’s is something of a godparent to this movement. init(8) just runs a shell script to start the computer, and You Can Just Do Things™ in the script to get them to happen on boot. ↫ Overeducated-Redneck.net My main laptop is currently in for warranty repairs, but once it returns, I intend to set it up with either OpenBSD or a Linux distribution without systemd (most likely Void) to see how many systems I can distance from systemd without giving myself too much of a headache (I’m guessing my gaming machine will remain on systemd-based Fedora). I’m not particularly keen on slopcoding and government-mandated age verification inside my operating systems, and I’m definitely feeling a bit of a slippery slope underneath my feet. I have my limits.

OpenBSD: anatomy of bsd.rd

Every OpenBSD admin has booted bsd.rd at least once — to install, upgrade, or rescue a broken system. But few people stop to look at what’s actually inside that file. It turns out bsd.rd is a set of nested layers, and you can take it apart on a running system without rebooting anything. That’s what we’ll do here. We’ll go from the raw gzip file all the way down to the miniroot filesystem, exploring each layer with standard tools. Everything is documented in the man pages — we’re just following the trail. ↫ Wesley Mouedine Assaby What am I supposed to add here?

Audio on hp300

In the late 1980s, with the expansion of the Internet (even though it was not open to commercial activities yet) and the slowly increasing capabilities of workstations, some people started to imagine the unthinkable: that, some day, you may use your computer to record voice messages, send them over the Internet, and the recipient could listen to these messages on his own computer. That was definitely science fiction… until workstation manufacturers started to add audio capabilities to their hardware. ↫ Miod Vallat A great story detailing how the audio hardware in the HP 9000/425e was made to work on OpenBSD and NetBSD.

OpenBSD-current now runs as guest under Apple Hypervisor

Excellent news for OpenBSD users who are tied to macOS: you can now run OpenBSD using Apple’s Hypervisor. Following a recent series of commits by Helg Bredow and Stefan Fritsch, OpenBSD/arm64 now works as a guest operating system under the Apple Hypervisor. ↫ Peter N. M. Hansteen at the OpenBSD Journal If you have an M1 or M2 Mac and want to get rid of macOS entirely, OpenBSD can be run on those machines natively, too.

OpenBSD on the Sharp Zaurus SL-C3100

OpenBSD on a Sharp Zaurus Linux-based PDA from 2005? Of course, why not? Installing OpenBSD was easy. The instructions in INSTALL.zaurus are pretty straightforward. My 5.6 install was smooth. Installing sets took ~10-15 minutes. The Microdrive is really slow. I’ll replace it with a CF card soon, which should be slightly faster (and more reliable). ↫ goldfish Of course, it includes a working X desktop, which is neat and makes the device a lot more useful. I have a slightly older Zaurus PDA, and this post has made me interested in doing something similar to it.

The scariest boot loader code

It shouldn’t be surprising that the HP-UX FAQ eventually grew an entry for “how can I make a 712 run headless”. It was possible, and to do it you had to change the firmware “console” path. The 712 firmware would not allow you to do this, to keep you locked to a keyboard and frame buffer console, but some of the HP-UX standalone tools could be used to change this without the firmware getting in the way, so the FAQ recipe was roughly “abort the boot sequence, at the BOOT_ADMIN> prompt, do not start the HP-UX kernel but some diagnostic tool, and then at the tools prompt, type a magic sequence without any mistake or you’ll be very, very, very sorry”. There was no exaggeration in these words: the magic sequence is conspath 2/0/4.0x283, which is everything but intuitive and easy to remember. ↫ Miod Vallat What a great story.

Big news for small OpenBSD /usr partitions

Ever ran into issues using sysupgrade on OpenBSD because /usr ran out of space? OpenBSD developers are trying to address this issue. Firstly, Stuart Henderson (sthen@) modified the installer to increase free space prior to installing. Theo de Raadt (deraadt@) modified sysupgrade(8) so that, if space is too tight, it will fail gracefully rather than risk leaving the administrator with a broken system. ↫ OpenBSD Journal These are very welcome additions.

Configuring cwm on OpenBSD

For those unfamiliar, cwm is the Calm Window Manager. It’s part of the OpenBSD base distribution as one of the native window managers, along with an old version of fvwm and the venerable twm. It’s pretty simple but surprisingly powerful, a floating window manager with some basic manual tiling. It’s keyboard-centric, has an application launcher and highly configurable menus. It uses groups rather than workspaces which provides a lot of flexibility. My configuration isn’t particularly groundbreaking, but it’s comfy and suits me well. I can happily live in it indefinitely, though I do split my time between cwm and Xfce with occasional forays into other window managers or Wayland compositors. This has nothing to do with cwm limitations and everything to do with me being curious and craving novelty. It’s cwm that I return to, because it’s entirely unsurprising and very capable, and also because it’s part of OpenBSD’s base so I know I’m dealing with software that’s been refined and audited and refined again. ↫ Antony Fox-Bramwell If you opt for a default installation of something like OpenBSD, without any additional desktop environments like Xfce, when you start X, you’ll be served with the default OpenBSD window manager: cwm, or the calm window manager. At first glance, it looks incredibly basic and, to most people, archaic and unusable, but what it lacks in sparkles and boondoggles it more than makes up for in flexibility and configurability. The problem, however, is that it’s not exactly intuitive to mold cwm into something that works for you. Articles like this one, by Antony Fox-Bramwell, function as great springboards into the world of configuring cwm. If you do an internet search for similar articles, you’ll find tons of other examples that can help you become more capable at configuring cwm. Most of us are probably just fine accepting something like KDE or Xfce, but if those just don’t scratch your itch, diving into cwm could be just what you’re looking for.

OpenBSD 7.8 released

Like clockwork, every six months, we have a new OpenBSD release. OpenBSD 7.8 adds support for the Raspberry Pi 5, tons of improvements to sleep, wake, and hibernate, the TCP stack can now run in parallel on multiple processors, and so much more. DRM has been updated to match Linux 6.12.50, and drivers for the Qualcomm Snapdragon DRM subsystem and Qualcomm DisplayPort controller were added as well. The changelog is, as always, long and detailed, so head on over for the finer details. OpenBSD users will know how to upgrade, and new users can visit the download page.

NLnet sponsors development of WPA3 support for OpenBSD

The NLnet foundation has sponsored a project to add WPA3 support to OpenBSD, support which in turn can be used by other operating systems. This project delivers the second open-source implementation of WPA3, the current industry standard for Wi-Fi encryption, specifically for the OpenBSD operating system. Its code can also be integrated by other operating systems to enable modern Wi-Fi encryption, thereby enhancing the diversity and resilience of the global IT ecosystem. ↫ NLnet foundation announcement WPA3 support in Linux seems to be the only other open source implementation of WPA3, so this is great news not only for OpenBSD, but also for other operating systems who rely on BSD network drivers through compatibility layers, like Haiku. FreeBSD, meanwhile, is planning to build its own WPA3 implementation, so they, too, might benefit form the work that’s going to be done through OpenBSD. October is listed as the start of this project, so work is probably already underway.

“My OpenBSD home network setup”

I recently moved to an area with more internet provider options, all of which were not satellite-based. This change allowed me leave my current provider (Starlink) and also freed my network from being locked behind CGNAT. The jump from ~150Mbps to 1Gbps has been fantastic, but the real benefit in this switch has been the ability to overhaul my home network setup. ↫ Bradley Taunt OpenBSD is generally the way to go for custom router setups, it seems, and if it wasn’t for my own full Ubiquiti setup, I’d definitely consider this too.

Why are you (still) using OpenBSD?

Last week-end, I was invited to the UNIX Social Camp in Dijon, France to talk about the reasons I still use OpenBSD these days and why should others do so; or at least, have a look at OpenBSD. ↫ Joel Carnat Here’s my short pitch as to why you should use OpenBSD: it’s the closest you’ll get to a traditional, classic UNIX, while still using a modern and maintained operating system. OpenBSD just makes sense, and every time I run into some issue or I want to know how something in OpenBSD works, the answers always make me go “well that makes sense”. That’s rare in modern computing, and we need to cherish it.

OpenBSD gets CDE

Adjusted for the inevitable progress of time, the Common Desktop Environment or CDE is the best desktop environment of all time, and no, I will not be taking question at this time. OpenBSD wasn’t yet graced by CDE’s presence, but this is currently changing as the first commit for porting CDE to OpenBSD has appeared. It’s still rough around the edges and very slightly tested. I wouldn’t use is as a daily driver, it’s old unsecure code but it’s fun if you want to bring back memories. ↫ Antoine at the openbsd-ports mailing list On top of that, this being the initial commit also means there’s probably bugs and other issues lurking in the code, so caution is definitely advised.

When root meets immutable: OpenBSD chflags vs. log tampering

ISO 27001 is like that careful lawyer who never says exactly what they mean – it tells you what needs to be achieved, not how to do it. When it comes to logging, this is particularly telling: Control A.12.4.2 simply states that “logging information and logging facilities shall be protected against tampering and unauthorized access.” Period. How? That’s your problem to solve. ↫ Rafael Sadowski It turns out OpenBSD has a few relatively simple tools to make logs immutable, in a way that not even root can delete or modify them, or change any of the logging schedules. Reading through the blog post, you don’t even need a ton of intricate knowledge to set this up, thanks mostly to just how much innate sense OpenBSD tends to make, and how excellent the documentation is. I have no need for this level of security, but if you do, you can set this up in a few minutes.

Building a simple router with OpenBSD

I’m hardly a “networking” or system admin expert. Even still, I’ve always been interested in the concept of building out my own home router with OpenBSD. It seemed so “hacky” and cool! The problem is that most of the tutorials I stumble across on the internet seem so daunting. I normally read through the guides (maybe even poke around the core man docs for a bit as well) but always end up returning to my default ISP setup. But that all changes today! Best of all, you can come along for the ride! ↫ Bradley Taunt Exactly what it says on the tin.

Crosscompiling for OpenBSD arm64

Following on from OpenBSD/arm64 on QEMU, it’s not always practical to compile userland software or a new kernel on some systems, particularly small SoCs with limited space and memory – or indeed QEMU, in fear of melting your CPU. There are two scenarios here – the first, if you are looking for a standard cross-compiler for Aarch64, and the second if you want an OpenBSD-specific environment. ↫ Daniel Nechtan Exactly what it says on the tin.