💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2019 › openbsd_on… captured on 2022-06-11 at 21:38:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from October 2019. The article has been slightly improved.
In my previous post I described the process of installing OpenBSD 6.0 on a SPARC64 machine and updating it all the way to 6.5. Now it's time to actually do something with it to get an idea of how well OpenBSD works on this architecture!
OpenBSD on SPARC64 (6.0 to 6.5)
The OpenBSD team takes pride in providing an ultra-secure operating system. It's a well-known fact that the project's extremely high standards only apply to the base system. Every now and then critics pop up and claim that this basically defeats the whole idea and even accuse the project of _"keeping their base system so small that it's useless by itself"_ to live up to their defined goals.
There's _some_ truth to it: The base system is kept (relatively) small if you compare it to some of the fatter operating systems out there. But that's about it because actually these allegation could not be further from the truth. The base system includes _doas_, a simpler sudo replacement. It comes with _tmux_. OpenBSD even maintains its own fork of X.org, called _Xenocara_ (not even FreeBSD comes with an X11 server by default) and there's in fact a lot that you can achieve with the base system alone! Let's look at one such possibility.
Since the OpenBSD developers are convinced that a webserver is something to keep around all the time, there's one in base. Originally they used the Apache HTTPd for this. The problem was that at some point, the Apache Foundation decided to give up their Apache 1.0 license and replace it with version 2.0 (they had been criticized a lot for being incompatible with the GPL and the new version solved that problem). The newer version also made the license less simple and less permissive than it had been before and OpenBSD did not like the new one much. For that reason they basically stayed with the old Apache 1.3 webserver for a long time. They maintained and patched it all that time, but the software really began to show its age.
So for version 5.6, OpenBSD finally removed the old Apache webserver in base and replaced it with Nginx. One release later, they did away with that, too, because they felt that it was starting to become too bloated for their needs. They imported OpenBSD HTTPd into base instead: A home-grown, very simple webserver. It evolved over time, but even though it having gotten more features implemented and becoming a fine little webserver, it strives to keep it simple.
The developers resist the temptation to add new features just because they could. Heck, they have even made a list of things that some people might want which however will never be implemented because they would raise complexity to an unacceptable level! OpenBSD HTTPd does not want to be a webserver for everyone. It wants to be a ultra-secure webserver that does enough to be useful to many people. If you have any needs above what it offers - get another one.
Simple static website configuration of OpenHTTPd (PNG)
The simplicity of HTTPd adds a lot to its beauty. I've written some HTML for a test page (see screenshot). All of the configuration that I need to do for HTTPd is as follows:
server spaffy.local {
listen on egress port 80
}
Yes, that's all that is required: I basically define a vHost (or "server" in HTTPd lingo) and have the application listen on the HTTP default port 80 on _egress_ (a keyword which means _whatever interface has the default route_). Let's check if that configuration really is valid by issuing
# httpd -n
And it is! Impossible? No. Remember that OpenBSD comes with _sane defaults_. For that reason there's usually pretty little that you need to configure. You _could_, of course. And we'll be doing that a little later.
Now let's force-start httpd (we need -f since the service is not enabled, yet, and we want to manually start it once):
# rcctl -f start httpd
I've edited the /etc/hosts file on my laptop to be able to use the _spaffy.local_ name. So now I can just type that into the address bar of my browser and reach the test page that the SPARC64 machine hosts. OK, a static page probably doesn't impress you so much. Fortunately that's not all that we can do in just relying on what base offers!
Static test page displayed in browser (PNG)
OpenBSD also comes with _Perl_ as part of the default install. I got the popular "Lama book" several years ago, read through about 2/3 of it and then decided that I didn't like Perl too much. For that reason I never really did anything with it, but here I want to do something with what OpenBSD provides me with. So Perl is a logical choice and I might finally do something with it. Here's what I came up with:
#!/usr/bin/perl
use strict;
use warnings;
my $osname = `uname -s`;
my $osver = `uname -r`;
my $osarch = `uname -m`;
chomp($osname, $osver, $osarch);
my @months = qw( Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec );
my @days = qw( Sun Mon Tue Wed Thu Fri Sat Sun );
my ( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday ) = gmtime();
print "Content-type: text/html\n\n";
print "<html><head><title>Greetings!</title></head>";
print "<body>Hello from <strong>$osname $osver</strong> on <strong>$osarch</strong>!";
print "<br><br>This page was created by Perl $^V on $days[$wday], $months[$mon] $mday";
if (length($mday < 2)) {
if (substr($mday, -1) == "1") {
print "st"; }
elsif (substr($mday, -1) == "2") {
print "nd"; }
elsif (substr($mday, -1) == "3") {
print "rd"; }
else {
print "th"; }
} else {
if ((substr($mday, 0, 1) ne "1") and (substr($mday, -1) == "1")) {
print "st"; }
if ((substr($mday, 0, 1) ne "1") and (substr($mday, -1) == "2")) {
print "nd"; }
if ((substr($mday, 0, 1) ne "1") and (substr($mday, -1) == "3")) {
print "rd"; }
else {
print "th"; }
}
print ", $hour:";
if (length($min) == 1) {
print "0";
}
print "$min (UTC)</body></html>";
Nothing too fancy really, but for a first attempt at writing Perl it's probably OK. After making the script executable, I can run it on the system and get the expected output. Things get a little more complex, though. HTTPd runs in a chroot for security reasons. And just copying the script into the chroot and trying it to execute in a chrooted environment fails with "no such file or directory".
Huh? I just copied it there, didn't I? I sure did. The reason for this happening is that the Perl interpreter is not available in the chroot. So let's copy that one over as well and try again. _Abort trap_! How do they say? Getting a _different_ error can be considered progress...
Perl CGI script failing due to chroot (PNG)
Ok, now Perl is there, but it's not working. It requires some system libraries not present in the chroot. Using _ldd_ on the Perl executable, I learn which libraries it needs. And after providing them, I can run the script in the chroot! There is a new problem, though: Perl is complaining about missing modules. The simplest solution in our case is to just remove them from the demo script as they are not strictly (haha!) necessary.
Providing Perl dependencies in the web chroot (PNG)
On to the next step. Here's a little addition to the HTTPd configuration:
location "/cgi-bin/*" {
root "/"
fastcgi
}
It basically adds different rules for the case that anything below /cgi-bin is being requested. It changes the document root for this and enables fastcgi. Now I only need to start the _slowcgi_ service (OpenBSD's shrewdly named fastcgi implementation) and restart HTTPd. My Perl program makes uses of the system's _uname_ command, so that should be made accessible in the chroot, too, of course.
Finishing the dynamic webpage setup (PNG)
And that's it. The script is executed in the webserver and the expected resulting page generated, which is then served properly:
Dynamically created webpage displayed in browser (PNG)
I think this is pretty cool. Try to do that with just the default install of other operating systems! BTW: Want to make HTTPd and slowcgi start automatically after boot? No problem, just put the following into _/etc/rc.conf.local_:
httpd_flags=""
slowcgi_flags=""
This makes the init system start both daemons by default (and you can of course drop the "-f" flag to rcctl if you need to interact with them).
For OpenBSD 6.5, pre-built packages are offered for 8 of the 13 supported architectures - among them SPARC64. There's just a couple short of _9,500_ packages available (on amd64 it's 10,600 - so in fact most packages are there)!
Package mirror still holding the old packages
Things like GCC 8.3 and even GNAT 4.9 (the Ada part of GCC which is interesting because it's written in Ada and thus needs to be bootstrapped to every new architecture by means of cross-compiling!) are among the packages, as is LLVM 7.0. When it comes to desktop environments, you can choose e.g. between recent versions of Xfce, MATE and Gnome.
Actually, SPARC64 is one of only 4 architectures (the others being the popular ones amd64, i386 and arm64) that are receiving updates to the packages via the _packages-stable_ repository. In there you'll find newer versions of e.g. PHP, Exim (which had some pretty bad remote exploits fixed), etc.
Basic OpenBSD package management (PNG)
I choose to install the _sysclean_ package. Remember when I wrote that I skipped deleting the obsolete files when updating the OS in my previous post? This program helps in finding files that should be deleted. However it's not too intelligent - it just compares a list for a fresh system to the actual system on disk. For that reason it also lists a lot of files that I wouldn-t want to delete. Still it-s helpful to find out obsolete files that you might have forgotten to remove.
Sysclean shows a lot of possible remove candidates (PNG)
While OpenBSD tries its very best at providing a safe to use operating system, there really is nothing both useful _and_ free from errors in the IT. If problems with some component of the system are found later, an erratum is published for it. If you are using OpenBSD in production, you are supposed to keep an eye on errata as they are released. Usually they consist of a patch or set of patches for system source code as well as instructions on how to apply it and recompile the needed parts.
Since version 6.1, OpenBSD comes with a handy utility called syspatch(8), which can e.g. be used to fetch binary patches for all known errata that have not been applied to the OS on the respective machine. This is nice - but it's only available for amd64, i386 and arm64. So on SPARC64 we still have to deal with the old manual way keeping the system secure. However errata patches are also applied to the -STABLE branch and we can use that to get all the fixes.
No syspatch on SPARC64 - tracking -STABLE manually as it used to be (PNG)
To upgrade our installation to 6.5-STABLE, the first step is to get the operating system source of the current release (the _sys_ tarball contains the kernel and _src_ the rest of the base system). After extracting those, CVS is used to update the code to the latest 6.5-STABLE.
Done getting the stable changes from CVS (PNG)
Once that's done, it's time to build the new (non-SMP) kernel:
# cd /sys/arch/$(machine)/compile/GENERIC
# make obj
# make config
# make && make install
# reboot
Building a 6.5-STABLE kernel (PNG)
On my SunFire v100 the kernel build took 1h 20m. I was curious enough to build the userland as well, just to see how long it would take... The answer is: 85h 17m! I think that LLVM alone took about three days. The rest of the system wasn't much of a problem for this old machine, but LLVM certainly was.
BTW, I had problems with "permission denied" when trying to "make obj". After reading the manpage for release(8), I found out that /usr/obj should be owned by build:wobj with 770 permissions which had not been the case on my system.
Having done that, I thought that I might build Xenocara as well, just to compare how long it takes to build. So I got the sources for that, too, updated them via CVS and built it. It took 9h 26m to build and install.
Xenocara built from (-STABLE) source (PNG)
I had left out all X11-related distribution sets when installing OpenBSD. But after having installed Xenocara from source, I had it all available. So I decided to just do something with it. Since the server does not have a graphics card, I cannot run any X program on it directly, because the xserver won't run. I decided to get a graphical application that is not part of Xenocara installed first. After browsing through the list, I settled on Midori, a WebKitGTK-based webbrowser.
Installing the Midori browser via packages (PNG)
It took a moment to install all the dependencies, but everything worked. As the next step I enabled SSH X11 forwarding and restarted SSH.
Midori is installed, allowing X11 forwarding for SSH (PNG)
After connecting to the SPARC64 machine via SSH and checking that the DISPLAY environment variable was set, I could just launch Midori and have it sent over to my laptop that I used to SSH into the other box. So the browser is being executed on the SPARC64 server but displayed on my other machine.
SSHing into the SPARC64 machine and forwarding Midori to my amd64 laptop (PNG)
Everything worked well, I could even visit the OpenBSD homepage and it was rendered correctly:
The webkit-based browser works well on SPARC64! (PNG)
OpenBSD is a fine operating system for people who value quality. The SPARC64 port of it seems to be in pretty good shape: Most packages and even stable-package updates are available. What is missing, is syspatch support - but only three architectures have that right now. Also the system compiler is still the ancient GCC version 4.2 which was the last one before the project switched the license to GPLv3.
OpenBSD 6.6 has been released one day after I finished compiling 6.5-STABLE. On amd64 I could now use sysupgrade(8) to upgrade to the new release even easier than before. This is also not supported on SPARC64. But these two little shortcommings just mean a little extra work that all OpenBSD users on any platform had to do anyway until not that long ago.
For 6.6 there are even more packages available for SPARC64. E.g. the Rust compiler has been bootstrapped on this architecture which definitely is great news. Maybe the system compiler will change to LLVM/Clang one day, too. Right now the SPARC64 backend for Clang is incomplete upstream at the LLVM project, if I understood things right. But we'll see. Maybe it'll become available in the future. I guess I'll really have to get a newer SPARC64-based machine with a faster processor. Luckily OpenBSD supports quite a few of them.
