Førstesiden Nyheter Bli medlem Kontakt Informasjon Kalender Vedtekter Dokumenter Styredokumenter Mailinglister Wiki NUUG brosjyre Kart NUUG i media webmaster@nuug.no
Powered by Planet! Last updated: May 19, 2024 20:03

Planet NUUG

May 17, 2024

Peter Hansteen (That Grumpy BSD Guy)

What every IT person needs to know about OpenBSD

How to have fun with the world’s most important free software project

"Functional, free and secure by default", OpenBSD remains a crucial yet largely unacknowledged player in the open source field. This talk aims to highlight the project's signature security features and development practices -- razor sharp focus on correct and secure code coupled with continuing code audit -- as well as the project's role as source of innovation in security practices and 'upstream' source for numerous widely used components such as OpenSSH, PF, LibreSSL and others.

If you only have a few minutes to spare, the highlights are:

Note: If you are more of a slides person you will be happy to hear that indeed the presentation I used for this when given as a talk is available here with the main highlights and little to no geek jokes. Also available from blog.apnic.net as a three part series, starting with Part 1.

Now with that out of the way, let's step back to  where it all started.

OpenBSD: How it all started

OpenBSD's history is to a large extent the history of the Internet itself. You may have heard of the time back in the 1980s when the likes of IBM and Digital were slugging it out in the corporate IT sphere and the US department of defence paid for experiments in distributed, device independent networking.

That's when a loosely organized group of hackers somewhat coordinated by researchers at University of California's Berkeley campus rose to prominence with "BSD Unix", which by a sequence of happy accidents became the home of the reference implementation of the TCP/IP internet protocols.

By the early 1990s, commercialization of the Internet had started, and the Berkeley Computer Science Research Group (CSRG) that had coordinated the efforts was set to be disbanded. In addition to the net itself, the main tangible product out of Berkeley was the Berkeley Software Distribution (BSD), often distributed on tapes in the mail but also available on the net itself, which had started as a collection of software for AT & T's Unix but had over the years been extended become a full featured Unix operating system.

Several different groups wanted BSD to go on even if the CSRG did not, and several things happened in fairly rapid succession:

The lawsuit was eventually settled -- only six files of several thousand in the tree were 'potentially encumbered' and had to be replaced, leaving both NetBSD and FreeBSD with a rush to replace the code which if I remember correctly was at least in part fairly central to the virtual memory subsystem.

OpenBSD came into existence a couple of years later, from a fork of the NetBSD code base in October 1995, with the initial release in July 1996.

From the very start, the OpenBSD project has been running a code audit of the entire tree, focusing on code correctness and security. We want secure, correct code that makes up a usable system with sane defaults and complete and readable documentation. And we want that code to be available under a free license and actually available to the world as soon as it is committed to the project's version control.

One of the early achievements of the OpenBSD project was anonymous CVS, which makes it possible for anyone on the internet to get the code with changes in near real time. This was a major break with the normal practice of most projects of the time, which would typically work in relative isolation on private mailing lists and at quasi-random intervals issue a release as a tarball on an FTP server somewhere.

You are already an OpenBSD user!

It is probably useful at this point to reveal that even if you do not know it, you are more likely than not using code with an OpenBSD origin right now. Your Apple product, be it iPad, iPhone or Mac, your Android device, your Cisco router, Solaris, Linux or other Unix or even your Microsoft product has some or a lot of OpenBSD originated code in it. We will get back some detail on that later.

OpenBSD: Code audit and security evolution

But about the code audit. The activity runs roughly like this: 

Read the code, understand what it does.

Look for unsafe behaviors, assume a hostile environment.

When you find a bug and fix it, look for similar code elsewhere in the tree and fix everywhere.

You will be amazed how much different programmers think alike and make the same mistakes. Wash, rinse, repeat.

That may sound somewhat unexciting, but careful study of how the code actually performs in real life situations lead to a number of innovations over the years, with a strong slant for being proactively secure, making it harder for bugs to actually do damage:

All of those features have been integrated in the OpenBSD source tree, and with the developers admonished to adhere to the rule

"where it is possible to spot damage, fail hard".

-which means that poorly written software will crash a lot more often on OpenBSD than elsewhere. That in itself should make the platform attractive to developers. Exposing your code to a hostile environment and see it perform or fail can be quite entertaining and enlightening.

Usable, portable and secure

To complete the picture, it is useful to keep in mind that OpenBSD runs on a total of fourteen platforms. All platforms are self-hosting. Cross-compiling is only used in the early phase of porting to a new platform.

And of course, in addition to purely maintaining existing code to run on diverse platforms, users and developers have real world needs that are addressed by developing new software, extending the features of existing programs, adding new functionality or even replacing programs or entire subsystems.

Security is a many-faceted topic. Early on, OpenBSD stood out as the system that included real crypto in the base system, to the extent that exporting OpenBSD source code from the United States was technically illegal under that country's munitions export restrictions as they were defined at the time. 

Fortunately for us, the project was always coordinated from Canada by undisputed project leader Theo de Raadt who lives in Canada. There is anecdotal evidence that US based developers would trek across the border for hackathons with clean slate equipment to install OpenBSD while in Canada and hack, that is, work on the system and would then legally bring the result back with them.

One early application of crypto in OpenBSD was when a full IPSEC stack was included in the system in 1997. OpenBSD was the first free system to include IPSec by default in its base install.

In a prime example of hacker humor of the time, a T-shirt featuring one of the early appearances of Puffy the blowfish that would become the project mascot touted the Blowfish password hashing algorithm which remains the default on OpenBSD both with the picture caption "So long and thanks for all the passwords" just below Puffy on the front, along with the full source code of the blowfish function on the back. 

The expectation was that the T-shirt would be illegal to re-export from the US.

In addition to attention to security and code correctness, one other important feature of OpenBSD is attention to intellectual integrity and insisting on clearly worded and unambiguous license to use and modify code and documentation that forms part of the system.

So why use OpenBSD? What is it like?

So what is OpenBSD like for a user or developer, and why is it better?

I'd say the short version is that it's a real Unix. Unlike the Linuxes of the world that spent years muddling through an evolutionary succession of init systems and have ended up more or less settling on the ever expanding systemd which seems to have tentacles into everything and is on a clear course to replacing most of what we have traditionally thought of as the base system, OpenBSD has stayed with and refined the traditional BSD init so can have both uncluttered services management and a base system that consists of programs that for the most part adhere to the classical Unix philosophy that every program should do exactly one thing, and do that thing well.

If you are a developer, you will also appreciate hearing that the base system of well designed programs that all have a readable and useful man page already contains basic Unix developer tools along with a C and C++ compiler -- clang where supported and gcc where necessary -- plus perl and a host of tools. Basically, everything that is needed to build the base system from a fresh checkout of the source code is contained in the base system on a default install.

Ported software goes under /usr/local

Once you have the thing installed on whatever hardware you have, keeping in mind that you can run a selection of 14 platforms ranging from fairly ancient kit to modern hardware, you will likely turn to installing ported third party software from packages, using pkg_add(8) which will suck in whatever you tell it to fetch from the same mirror you installed from or what appears to be the most local one.

More software is available on the more popular platforms than on the more, dare we say exotic ones.

For the OpenBSD 6.9 release, the most mainstream platform amd64 came with 11310 prebuilt and installable packages, while mips64 had only 8182 and the mips64el platform is marked as (still building).

Installing pre-built packages is almost always more convenient and is recommended in most cases, but if you for one reason or the other want to build your own from a cvs checkout of the ports tree, you are free to do so at the cost of your own time watching the process.

Whichever route you choose to go, you will see that installing packages does not land you with any files in the directories used by the base system outside of a few that drop their configuration files in subdirectories under /etc and add their combined startup/shutdown scripts to the collection in /etc/rc.d. Anything else ends up under /usr/local, and you can see why the installer by default sets up that file system on a separate and fairly roomy partition. My previous article You've installed it. Now what? Packages! is a few years old, but gives you the main motivations and some background along with some pointers on packages practice.

Note: If you are more of a slides person than a fulltext person, you may be relieved to hear that you can find the slides for the talk this article is based on (and vice versa) here.

The installer was always good, got better

When I found OpenBSD more than twenty years ago, my main Unix exposure was from working with Linuxes and FreeBSD. What attracted me to OpenBSD and finally had me buy an OpenBSD 2.5 CD set was the strong focus on security and code correctness. When the CD set and the classic wireframe daemon T-shirt finally arrived in the mail, I set about at first to install it on whatever spare hardware I had lying around.

OpenBSD wireframe daemon head

If I remember correctly, the first machine I tried installing OpenBSD on was an 80386/33MHz with 8MB RAM and I think a 100MB IDE hard disk. Which I can report sounded pretty crappy even then, but the thing did work.

The initial install was fairly straightforward, and when I started poking around I found two things about myself and the new system: Everything made sense, and everything I could think of had a readable man page. So the first change I am aware of that made the world better with OpenBSD was the decision to enforce the "No commit without documentation" rule, which came into being early in the project's life, probably roughly at the same time the OpenBSD developers gave us a real-time view of development via anonymous CVS. You can see things happening in almost real time.

It is worth mentioning that the installer has remained famously non-graphical, text only. The reason the installer remains text-only is that this is a major advantage that enables the developers and the users to handle the fairly diverse collection of hardware platforms that OpenBSD runs on with the same portable, familiar and compact code everywhere.

The installer was always scriptable and extensible, and over the years the installer has added automatic, repeatable and scriptable installs (dubbed autoinstall(8) which appeared in OpenBSD 5.5 in 2014) and the sysupgrade(8) extension (first found in OpenBSD 6.6 in 2019) that automates snapshot to snapshot or release to subsequent release upgrades for all not too hacked-up configurations. Each of these moments, or more specifically when the new code started appearing in snapshots, had me appreciate the OpenBSD system a bit more, and made me feel quality of life had improved.

Now something for your laptop - hardware support

Fast forward some twenty-plus years and the last article I published, and even got into Norwegian mainstream IT news site Digi.no, centers on a few moments involving new OpenBSD developments. It took some interaction with OpenBSD developers, but those interactions lead to my new laptop with an 11th generation Intel Core chipset working even better with OpenBSD. Yes, OpenBSD developers and a significant subset of their user base actually run OpenBSD on their laptops. I do use a Mac and a work-issued Thinkpad with Ubuntu Linux too, but life is not complete without an OpenBSD laptop.

Now to be honest, what I saw within the space of a few days was development that had me going from "Oh, sh*t, the SSD isn't recognized" -- the controller was set to a RAID-ish mode by default -- through this kernel panic:

OpenBSD 6.9-current panic message

-- to seeing it all fully supported.

The SSD problem turned out to be simple to fix: Simply find the "Advanced" BIOS option that turned the pseudo-raid feature off and let the operating system speak directly to the storage device.

For the rest there was a period of a couple of weeks I had to run with not yet commited patches in a home baked kernel built from checkouts from Jonathan Grey's git repo. When the code was committed to -current, I could resume my normal sysupgrade(8) routine, going from one development snapshot to the next.

The process, even with the need to build custom kernels for a while, was actually quite pleasant, and when the support code went into the main development branch, that too was a a moment when I felt my life had been improved by changes in OpenBSD. The hardware support is now in snapshots and will be in OpenBSD 7.0 which is set to be released on November 1st, 2021.

Why use OpenBSD? IPSEC

As I mentioned earlier, OpenBSD was the first free system to ship with IPSEC -- the tools for enabling encrypted network traffic -- in its base system. The first OpenBSD release with IPSEC was OpenBSD 2.1, which was released in 1997.

The tools worked of course, but in the early days the complaint was that IPSEC was hard and near impossible to debug from an almost-working to a fully working setup.

Further development took a while, but the tools got a major usuability upgrade in OpenBSD 3.8 with ipsecctl and its human-readable configuration file /etc/ipsec.conf to serve as a friendlier front end to the IPSEC tools.

A complete configuration for a minimal setup could look like this:

# Set up two flows:
# First between the machines and
# Second between the networks and
flow esp from to
flow esp from to peer

This was a major step compared to other platforms. One famous example is preserved in a presentation by Mathieu Sauve-Frankel at AsiaBSDCon 2007, where he demonstrated that setting up the equivalent of the config shown here with Microsoft tools took the user through a sequence of no less than 36 dialog boxes, and still there was a distinct possibility that the configuration was not actually a working one.

The problem in both the Microsoft implementation and others was that the developers had not really given any thought to the user experience. The majority of the options the user was required to set had sensible defaults and could easily have been hidden from view.

The standards documents the developers had worked from were fairly unclear, so it is not entirely unreasonable that "it was hard to write, so it should be hard to use" was a factor in how the products ended up from a user experience perspective.

What defaults would be actually sensible would perhaps not be clear to the developer from the specification, and the only way to see what would be the sensible default would be experience with actual use in the field. The OpenBSD developers who wrote ipsecctl came with extensive experience of using IPSEC and decided that IPSEC did not in fact need to be so hard. The defaults should make sense.

The next milestone in IPSEC development on OpenBSD came with Internet Key Exchange (IKE) protocol support in OpenIKED in OpenBSD 3.8 with iked and ikectl. For convenience, ikectl is able to generate configurations for Windows and macOS clients too. That might save you the agony of clicking through dozens of dialog boxes at the client end.

The thing that lured me in

But I hear you ask, what made me turn into an almost all-in OpenBSD user?

Back in 2001 I was still only experimenting with OpenBSD, but my experience with Linux and iptables had made me long for a switch to a saner firewall. I had done some small experiments with the IPF firewall that was in OpenBSD until the 2.9 release. Then, as some of us will remember, the it was discovered that IPF's license was in fact not free, so it needed to be replaced.

There was a distinct rush, not quite a stampede, to replace IPF over the months that followed. Fortunately, the new code that replaced the previous packet filter proved to perform better. The OpenBSD Packet filter, dubbed PF for short, had been born and made its debut in OpenBSD 3.0 in December 2001. The release had originally been planned for November, but was pushed out a month to hack the "working prototype" packet filter into something usable.

Almost needless to say, this turn of events finally pushed me to take the final steps to replace the Linux gateways I had in place with OpenBSD ones. I was pleasantly surprised to find that not only did they perform well, but they also came with complete and reasonably well documented tools so I could understand what was going on. That's how I got started on the process that lead to among other things writing The Book of PF and taking that text through three editions so far. But more about that later.

It is worth noting that the IPFilter copyright episode spurred the OpenBSD developers to perform a license audit of the entire source tree and ports in order to avoid similar situations in the future. This activity ran for some months and uncovered a number of potential problems. Theo de Raadt summed up the effort in a message to the openbsd-misc mailing list on February 20th, 2003.

What they found when they started looking was that there was a significant number of files that were in fact not under a free license, much like the entire IPF subsystem had been. Those needed to be replaced. Other parts had either no license or no copyright stated. In some cases the developers gave explicit permission to continuing use, but quite a few things needed to be rewritten with a free license so OpenBSD and other free software would be able to move forward without copyright problems.

I later heard in a rather informal setting that among the no copyright and/or no license cases, it was usually possible to track down the developers via version control system logs or mailing list archives. In a large number of those cases, the initial reaction was along the lines "Say what? Are people still using that?".

SSH, open and better

PF was written from scratch to replace a subsystem that it turned out was illegal to use in an open source context. But it was not the first time the OpenBSD project had performed a nonlibreectomy, that is, taken on the task of replacing code for license reasons.

A few years earlier it had become clear that the original developer of the secure shell system ssh had commercial ambitions and the license for the software had changed in a proprietary direction. After a bit of deliberation on how to resolve the situation, the OpenBSD developers started digging around for earlier versions of the code that had been published with an acceptable license. Then they forked their version from the last version they found that still had free license. Next came an intensive period of re-introducing the features that were missing in the old code.

The result was introduced as OpenSSH in OpenBSD 2.6 in 1999. Over the next few years OpenSSH grew a portable version that started grabbing market share rapidly. The last I heard OpenSSH's market share is somewhere in the high nineties percent.

With a state of the art secure shell subsystem in place and growing all sorts of useful features, the time finally came to end unencrypted shell login sessions on OpenBSD. OpenBSD's telnetd was moved to the CVS attic in time for OpenBSD 3.8, which was released November 2005.

One other notable thing about OpenSSH is that it was the first daemon to be properly privilege separated, a model practice that debuted with the overhauled OpenSSH in OpenBSD 3.2 in March 2002. Since then privilege separation has been put in place in all daemons where it made sense to do so, and it is now a signature part of the secure by default stance of all newer OpenBSD daemons.

And yes, that packet filter

I mentioned PF, the OpenBSD packet filter, earlier. I must confess that PF has been an important part of my life in various contexts since the early noughties. Over the years, things I have written have contributed to creating the popular but actually wrong perception that OpenBSD was primarily a firewall operating system. There are a lot of useful and fun features that turned up in or in connection with PF over the years and were pioneered by OpenBSD. Some features were ported to or imitated in other systems, while others remain stubbornly OpenBSD only.

So I will touch on some of my favorite PF and PF-attached features, in quasi-random but almost chronological order.

Beating up spammers with OpenBSD spamd(8) since OpenBSD 3.3

When I started playing with OpenBSD in general and PF in particular way back when, I was already responsible for the SMTP mail service for my colleagues. My gateways by then ran OpenBSD, while the mail server rosalita, named after a Springsteen song, was not too badly specced server running FreeBSD with exim as the mail transfer agent that fed the incoming messages to spamassassin and clamav for content filtering before handing off to user mailboxes.

So when it dawned on me that I could set up spamd(8) the spam deferral daemon on the internet-facing gateway and save load on the poor suffering rosalita that was running hot with content filtering, I was quick to implement a setup that sucked in well known block lists.

Going grey, then trapping

The effect was obvious and immediate, the mail server's fans grew noticeably quieter. When greylisting was introduced in spamd soon after, I implemented that too, and witnessed yet another drop in pitch and intensity of the sound from rosalita's fans. Then a couple of releases later greytrapping -- the practice of adding IP addresses of incoming SMTP connections to blocklists if the attempted delivery is aimed at a known-bad address in the target domain -- was introduced, and that sounded like enough fun that I just went ahead and did it.

The idea of detecting spam senders by the bogus addresses they were already trying to deliver to just sounded too good to not try. And we knew that getting started would be pretty easy too. We had seen rejects for addresses that had never existed in our domains in our mail server logs for quite a while, so it was simply a matter of harvesting from a fairly bountiful source and adding stuff that we were sure would never ever be actually deliverable here to the spamtrap list. I think the first setup had only a couple of hundred entries in it, but I did not note the exact number at the time.

By July 2007 I had decided to publish both the list of spamtrap addresses and an hourly dump of the greytrapped addresses. Both remain free to download. The list of spamtraps, harvested from various log sources, by now numbers just over 270,000 imaginary friends, while the number of trapped hosts is typically in the 3000 to 5000 range. We occasionally see the list swell to 20,000 or more when high volume campaigns run with bad address lists fed to them. I am pretty sure it went over 100,000 at one point.

It's fun to watch, and it looks like a significant subset of the spamtraps have made it into the address lists of active spam operations. I frankly never thought I would still be collecting spam traps from logs all these years later. Yes, it all sounds a bit absurd, but it is effective for keeping our mailboxes largely spam free, even though it feels at times like running a weird found object-ish art project. Anyway, a summary of the lists we publish can be found in this article.

The brutes, the password gropers and the state tracking options

If you run an SSH service or really any kind of listening service with the option to log in, you will see some number of failed authentication attempts that generate noise in the logs. The password guessing, or as some of us say, password groping, turned out to be annoying enough that OpenBSD 3.6-current and later OpenBSD 3.7 introduced a set of features to use data that would anyway be available in the state table, to track the state of active connections, and to act on limits you define such as number of connections from a single host over a set number of seconds.

The action could be to add the source IP that tripped the limit to a table. Additional rules could then subject the members of that table to special treatment. Since that time, my internet-facing rule sets have tended to include variations on

table <bruteforce> persist
block quick from <bruteforce>
pass inet proto tcp from any to $localnet port $tcp_services \
        flags S/SA keep state \
	(max-src-conn 100, max-src-conn-rate 15/5, \
         overload <bruteforce> flush global)

which means that any host that tries more than 100 simultaneous connections or more than 15 new connections over 5 seconds are added to the table and blocked, with any existing connections terminated.

It is a good practice to let table entries in such setups expire eventually. At first I followed the spamd(8) defaults' example and set expiry at 24 hours, but with password gropers like those caught by this rule being what they are, I switched a few years ago to at four weeks at first, then upped again a few months later to six weeks. Groperbots tend to stay broken for that long. And since they target any service you may be running, state tracking options with overload tables can be useful in a lot of non-SSH contexts as well.

It is also worth noting that state tracking actions are useful for essentially all services. The article Forcing the password gropers through a smaller hole with OpenBSD's PF queues has a few suggestions on how to handle noise sources with various other services.

One final point I would like to make about the state tracking and actions is that much like the greytrapping feature of spamd, this feature gives you the tools to build a configuration that adapts to network conditions and learns from the traffic it sees. 

While this does not rise to the level of being an actual Artificial Intelligence or AI, this has enough buzzwordability potential that I remain to this day extremely puzzled that none of the other big names at least imitated those features in their own products and marketed for all it would be worth. 

I certainly know what I would have done in their position. But then I am more engineer than marketer and in the contexts where I call the shots, the best option is just to keep running OpenBSD.

We went to modern queueing

OpenBSD has had traffic shaping available in the ALTQ subsystem since the very early days. ALTQ was rolled into PF at some point, but the code was still marked experimental 15 years after it was written, and most people who tried to use it in anger at the time found the syntax inelegant at best, infuriating or worse at most times.

So Henning Brauer took a keen interest in the problem, and reached the conclusion that all the various traffic shaping algorithms were not in fact needed. They could all except one be reduced to mere configuration options, either as setting priorities on pass or match rules or as variations of the theme of the mother algorithm Hierarchical Fair Service Curve (HFSC for short).

Soon after, another not-small diff was making the rounds. The patch was applied early in the OpenBSD 5.5 cycle, and for the lifetime of that release older ALTQ setups were possible side by side with the new queueing system.

The feedback I get is that the saner syntax in the new queueing system lead to more users taking up traffic shaping. Here is the queue setup that I came up with for one of my sites:

queue rootq on $ext_if bandwidth 20M
        queue main parent rootq bandwidth 20479K min 1M \
                                    max 20479K qlimit 100
             queue qdef parent main bandwidth 9600K min 6000K \ 
                                    max 18M default
             queue qweb parent main bandwidth 9600K min 6000K \
                                    max 18M
             queue qpri parent main bandwidth 700K min 100K \
                                    max 1200K
             queue qdns parent main bandwidth 200K min 12K \
                                    burst 600K for 3000ms
        queue spamd parent rootq bandwidth 1K min 0K max 1K \
                                    qlimit 300

while tying the queues into the subsequent rules with a set of match rules just following that block.

This is what triggered the need to write the third edition of The Book of PF. The book includes descriptions of both the new and the old system as well as tips on how to make a smooth transition. The ALTQ code was removed from OpenBSD during the OpenBSD 5.6 cycle, but continues to live on in some form in FreeBSD and NetBSD.

And yes, if you think my queues setup punishes spammers a bit more in addtion to being subjected to spamd(8), you're right.

pflow(4) offers network insights lite

Everybody who has been tasked with looking after a network has at some point been at least a little curious about what actually moves around there. At times we will see situations where it is essential for troubleshooting purposes to see the traffic flows with data about endpoints, packets and bytes transferred, protocol and so forth.

If you do not need to see the data itself, but rather the metadata, the NetFlow standard and its close cousin IPFIX offers just that. Netflow tools existed as packages on OpenBSD already, but from OpenBSD 4.5 PF has the pflow state tracking option, paired with the pflow(4) virtual network interface which together offer a full netflow sensor package.

Set up one or more pflow interfaces to send data to one or more collectors, and add the pflow option to specific rules or as a state default and you have started your collecting. You can even have metadata for traffic matching specific rules going to separate pflow devices and collectors.

My field notes in Yes, You Too Can Be An Evil Network Overlord - On The Cheap With OpenBSD, pflow And nfsen offers some practical examples and insights, including how we used a pflow setup to track down a noisy machine on a somewhat critical network as well as some pointers to valueable further reading.

LibreSSL, the great deobfuscation

People tell me they think that the reason LibreSSL was created was the Heartbleed bug, but no, actually not, just damn close.

The LibreSSL project was in fact started a few weeks before heartbleed became common knowledge. LibreSSL is the result of a group of OpenBSD developers taking the existing OpenSSL code and starting to fix it.

This time it was not a matter of a bad license. No, this was the result of the number of OpenBSD developers who took a look at the OpenSSL code that had been part of the OpenBSD base system since quite early on, and turned away in disgust and with symptoms of physical pain, reached a critical mass of sorts. I had heard OpenBSD developers complain about the absolute horror of the OpenSSL code for at least ten years. The code quality was just that bad.

What happened next was that a group of hardened OpenBSD developers grabbed the OpenSSL code and started two activities in parallel. One was looking in the OpenSSL request tracker for bugs that had not been addressed. The other was reformatting the OpenSSL code into something resembling the OpenBSD style of readable and maintainable C.

With the code in more readable form, discovering what it did became easier. In addition to a few obvious eye-stinging bugs the LibreSSL developers found a number of oddities, including, but not limited to

It is worth digging out the various articles and presentations made by LibreSSL developers over the years, with specific emphasis on Bob Beck's BSDCan talk on the first 30 days of LibreSSL (available on youtube), which is the original source of the term code flensing.

Since the OpenBSD 5.6 release in 2014, LibreSSL has been the default TLS library in OpenBSD. LibreSSL has been ported elsewhere based on the -portable variant.

For my own part I can only attest to not ever running into a TLS problem that was LibreSSL's fault. It probably still has bugs, but it is a lot more of a healthy choice than its predecessor.

This was my list of life improving OpenBSD events - I'd love to hear yours

As I warned earlier, this has been about my personal list of OpenBSD events that I remember fondly.

I am sure your list is at least a little different. I am sure there are things from the innovations page that I have simply forgotten about.

Each release comes with a detailed list of changes, such as this one for OpenBSD 6.9, and the page has pointers back to the equivalent pages for previous releases.

I would love to hear about your favorite OpenBSD moments.

More items for your OpenBSD reading

www.openbsd.org is the official OpenBSD web site. If you want to donate, go to the donations page and find the most appropriate option. Corporate entities may prefer to donate via The OpenBSD Foundation, which is a Canadian non-profit corporation.

undeadly.org is the OpenBSD Journal news site.

bsdly.blogspot.com My rant^H^H^H^Hblog posts

https://flak.tedunangst.com/ Ted Unangst (tedu@) on developments

Michael W Lucas: Absolute OpenBSD, 2nd edition

Peter N. M. Hansteen: The Book of PF, 3rd edition

Henning Brauer: OpenBSD sucks (… least)

Addendum 2021-11-06

The original statement in the article that the two groups (NetBSD and FreeBSD) were only vaguely aware of each other in the early days has been disputed by at least one patchkit era participant, Tom Ivar Helbekkmo, who wrote in to say,
"That is not entirely true.  When Bill Jolitz didn't include patches from the Internet community in 386bsd 0.1, and then again not in 0.2, Chris Demetriou took the initiative to fork the project, and call ours NetBSD.

 It soon became apparent, however, that there were divergent goals for further development.  This led to the creation of FreeBSD.  So we had one community that amicably divided itself into two separate groups."

In my own experience, however, those who joined in the post-patchkit era of both projects frequently seem to be unaware of this aspect of the early days. 

by Peter N. M. Hansteen (noreply@blogger.com) atMay 17, 2024 15:46

May 14, 2024

NUUG news

Tabbe i driftsgruppen

I NUUG har vi en driftsgruppe som gjør sitt beste for å holde maskinparken i fungerende stand, og oppgraderer ting som trenger oppgradering.

En av oppgavene er å sørge for at medlemsregisteret er synkronisert mot e-postlisten «medlemmer».
I dag skulle en av våre driftsteknikere synkronisere e-postlisten «medlemmer» mot medlemsregisteret, og kom i skade for å synkronisere mot en utdatert utgave av medlemsregisteret.
Dette førte til at flere betalende medlemmer ble utmeldt av denne medlemslisten og havnet over i interesserte-listen i stedet.

Dette er nå rettet opp i.
De som fikk e-post om utmelding kan se bort fra dette.

Dersom noen fremdeles har spørsmål kan de kontakte sekretariatet, se kontaktsiden vår for kontaktopplysninger.


May 14, 2024 10:20

May 01, 2024

Peter Hansteen (That Grumpy BSD Guy)

Fun Facts About the April 2024 Cisco Attack Data

A commendable attack data dump, lightly analyzed.

In the morning hours (CEST) of April 17, 2024, I found in my social media stream a reference to an Ars Technica article titled UNDER SIEGE — Attackers are pummeling networks around the world with millions of login attempts.

NOTE: A version without trackers but “classical” formatting is available here.

Articles about recent or ongoing attacks are not uncommon, but this time I was delighted to see that the report included a link to the actual data, provided by Cisco subsidiary Talos Intelligence.

When I downloaded the data approximately 09:15 CEST, the data consisted of

5243 unique IP addresses
2105 unique user names
71 unique passwords

I was initially a bit annoyed that the each group of data had apparently not been sorted, so I was a bit worried about possible duplicate entries, but closer inspection showed that I had not needed to worry.

Returning readers will be aware that at nxdomain.no (aka bsdly.net) we have been collecting data on attacks and attackers for some time already, as described in Badness, Enumerated by Robots (also available with nicer formatting but with trackers here) and various material linked from that article.

So naturally my impulse was to see whether there was any overlap between the data Cisco provided and the data collected here.

A few quick rounds for sorting and diffing (or very close equivalents), the results were clear:

of the 5243 unique IP addresses, none were in the currently trapped ssh bruteforcers set or the historical pop3 gropers set.
of the 2105 unique user names, a total of 1595 were not already included in the existing spamtraps list

of the 71 unique passwords, 34 or almost half of the total were not already in the spamtraps list.

If the last item made you chuckle, I am not surprised. But I have also observed at various times that bot herders (or possibly bot feeders) have managed to feed the data the wrong way around to their charges.

The biggest surprise here is that there was no overlap in hosts participating in the campaign against the Cisco customers and hosts that had participated in password guessing against my (for all practical purposes) honeypot system.

One possible explanation could be that the attackers here were targeting only specific products, possibly based on previous intelligence gathering. An alternative explanation could be that they were specifically avoiding certain hosts, such as those running the rather security oriented operating system OpenBSD that we use at this site.

The overlap in user names and passwords mistakenly used as user names with previously collected data here is less surprising.

After this very lightweight analysis, I went to the next logical step and added the offending IP addresses to the bruteforcers list and appended a @bsdly.net suffix to the user names and passwords, and added them to the spamtraps list.

I would like to thank Cisco-Talos for sharing the data on this incident freely.

If you found this article useful, interesting or even annoying, I would like to hear from you.

Good night and good luck.

NOTE: If you follow the references in the various other articles, please keep in mind that the command examples there were written from an OpenBSD perspective. Details of command syntax may be different from the implementations on other Unixlikes.

by Peter N. M. Hansteen (noreply@blogger.com) atMay 01, 2024 13:51

April 25, 2024

Petter Reinholdtsen

45 orphaned Debian packages moved to git, 391 to go

Nine days ago, I started migrating orphaned Debian packages with no version control system listed in debian/control of the source to git. At the time there were 438 such packages. Now there are 391, according to the UDD. In reality it is slightly less, as there is a delay between uploads and UDD updates. In the nine days since, I have thus been able to work my way through ten percent of the packages. I am starting to run out of steam, and hope someone else will also help brushing some dust of these packages. Here is a recipe how to do it. I start by picking a random package by querying the UDD for a list of 10 random packages from the set of remaining packages:

PGPASSWORD="udd-mirror" psql --port=5432 --host=udd-mirror.debian.net \
  --username=udd-mirror udd -c "select source from sources \
   where release = 'sid' and (vcs_url ilike '%anonscm.debian.org%' \
   OR vcs_browser ilike '%anonscm.debian.org%' or vcs_url IS NULL \
   OR vcs_browser IS NULL) AND maintainer ilike '%packages@qa.debian.org%' \
   order by random() limit 10;"

Next, I visit http://salsa.debian.org/debian and search for the package name, to ensure no git repository already exist. If it does, I clone it and try to get it to an uploadable state, and add the Vcs-* entries in d/control to make the repository more widely known. These packages are a minority, so I will not cover that use case here.

For packages without an existing git repository, I run the following script debian-snap-to-salsa to prepare a git repository with the existing packaging.

# See also https://bugs.debian.org/804722#31

set -e

# Move to this Standards-Version.


if [ -z "$PKG" ]; then
    echo "usage: $0 "
    exit 1

if [ -e "${PKG}-salsa" ]; then
    echo "error: ${PKG}-salsa already exist, aborting."
    exit 1

if [ -z "ALLOWFAILURE" ] ; then

# Fetch every snapshotted source package.  Manually loop until all
# transfers succeed, as 'gbp import-dscs --debsnap' do not fail on
# download failures.
until debsnap --force -v $PKG || $ALLOWFAILURE ; do sleep 1; done
mkdir ${PKG}-salsa; cd ${PKG}-salsa
git init

# Specify branches to override any debian/gbp.conf file present in the
# source package.
gbp import-dscs  --debian-branch=master --upstream-branch=upstream \
    --pristine-tar ../source-$PKG/*.dsc

# Add Vcs pointing to Salsa Debian project (must be manually created
# and pushed to).
if ! grep -q ^Vcs- debian/control ; then
    awk "BEGIN { s=1 } /^\$/ { if (s==1) { print \"Vcs-Browser: https://salsa.debian.org/debian/$PKG\"; print \"Vcs-Git: https://salsa.debian.org/debian/$PKG.git\" }; s=0 } { print }" < debian/control > debian/control.new && mv debian/control.new debian/control
    git commit -m "Updated vcs in d/control to Salsa." debian/control

# Tell gbp to enforce the use of pristine-tar.
inifile +inifile debian/gbp.conf +create +section DEFAULT +key pristine-tar +value True
git add debian/gbp.conf
git commit -m "Added d/gbp.conf to enforce the use of pristine-tar." debian/gbp.conf

# Update to latest Standards-Version.
SV="$(grep ^Standards-Version: debian/control|awk '{print $2}')"
if [ $SV_LATEST != $SV ]; then
    sed -i "s/\(Standards-Version: \)\(.*\)/\1$SV_LATEST/" debian/control
    git commit -m "Updated Standards-Version from $SV to $SV_LATEST." debian/control

if grep -q pkg-config debian/control; then
    sed -i s/pkg-config/pkgconf/ debian/control
    git commit -m "Replaced obsolete pkg-config build dependency with pkgconf." debian/control

if grep -q libncurses5-dev debian/control; then
    sed -i s/libncurses5-dev/libncurses-dev/ debian/control
    git commit -m "Replaced obsolete libncurses5-dev build dependency with libncurses-dev." debian/control
Some times the debsnap script fail to download some of the versions. In those cases I investigate, and if I decide the failing versions will not be missed, I call it using ALLOWFAILURE=true to ignore the problem and create the git repository anyway.

With the git repository in place, I do a test build (gbp buildpackage) to ensure the build is actually working. If it does not I pick a different package, or if the build failure is trivial to fix, I fix it before continuing. At this stage I revisit http://salsa.debian.org/debian and create the project under this group for the package. I then follow the instructions to publish the local git repository. Here is from a recent example:

git remote add origin git@salsa.debian.org:debian/perl-byacc.git
git push --set-upstream origin master upstream pristine-tar
git push --tags

With a working build, I have a look at the build rules if I want to remove some more dust. I normally try to move to debhelper compat level 13, which involves removing debian/compat and modifying debian/control to build depend on debhelper-compat (=13). I also test with 'Rules-Requires-Root: no' in debian/control and verify in debian/rules that hardening is enabled, and include all of these if the package still build. If it fail to build with level 13, I try with 12, 11, 10 and so on until I find a level where it build, as I do not want to spend a lot of time fixing build issues.

Some times, when I feel inspired, I make sure debian/copyright is converted to the machine readable format, often by starting with 'debhelper -cc' and then cleaning up the autogenerated content until it matches realities. If I feel like it, I might also clean up non-dh-based debian/rules files to use the short style dh build rules.

Once I have removed all the dust I care to process for the package, I run 'gbp dch' to generate a debian/changelog entry based on the commits done so far, run 'dch -r' to switch from 'UNRELEASED' to 'unstable' and get an editor to make sure the 'QA upload' marker is in place and that all long commit descriptions are wrapped into sensible lengths, run 'debcommit --release -a' to commit and tag the new debian/changelog entry, run 'debuild -S' to build a source only package, and 'dput ../perl-byacc_2.0-10_source.changes' to do the upload. During the entire process, and many times per step, I run 'debuild' to verify the changes done still work. I also some times verify the set of built files using 'find debian' to see if I can spot any problems (like no file in usr/bin any more or empty package). I also try to fix all lintian issues reported at the end of each 'debuild' run.

If I find Debian specific patches, I try to ensure their metadata is fairly up to date and some times I even try to reach out to upstream, to make the upstream project aware of the patches. Most of my emails bounce, so the success rate is low. For projects with no Homepage entry in debian/control I try to track down one, and for packages with no debian/watch file I try to create one. But at least for some of the packages I have been unable to find a functioning upstream, and must skip both of these.

If I could handle ten percent in nine days, twenty people could complete the rest in less then five days. I use approximately twenty minutes per package, when I have twenty minutes spare time to spend. Perhaps you got twenty minutes to spare too?

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Update 2024-05-04: There is an updated edition of my migration script, last updated 2024-05-04.

Apr 25, 2024 20:00

April 17, 2024

Petter Reinholdtsen

RAID status from LSI Megaraid controllers in Debian

I am happy to report that the megactl package, useful to fetch RAID status when using the LSI Megaraid controller, now is available in Debian. It passed NEW a few days ago, and is now available in unstable, and probably showing up in testing in a weeks time. The new version should provide Appstream hardware mapping and should integrate nicely with isenkram.

As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

Apr 17, 2024 15:00

April 05, 2024

Salve J. Nilsen

Open Source components you depend on are not “third-party components”

When using the term "third-party", we usually refer to someone who is not part of an agreement, but who may still be influencing (or be influenced by) it. When this party is an Open Source project, I propose to use term "second-party" instead. Here's why.

by Salve J. Nilsen atApr 05, 2024 19:49

April 03, 2024

Salve J. Nilsen

A Vocabulary for a Post-CRA Open Source Age

With the EU Cyber Resilience Act (CRA) arriving in 2024, software in general is – for the first time – about to be legislated. This means any business who wishes to place software on the EU market will have to comply to new cybersecurity demands, and by implication this will affect tens of thousands of … Continue reading A Vocabulary for a Post-CRA Open Source Age

by Salve J. Nilsen atApr 03, 2024 10:01

March 01, 2024

Nicolai Langfeldt


So, I'm fiddeling with various stuff at work, and need to retrieve DNS zones.  The suite I'm currently working is in python so 2 minutes later it turns out that dnspython ("import dns") is the powerful choice.

10 minutes later it turns out that it is very poorly documented. The documentation is auto-generated and there seems to be no introductory material to any part of the gargantuan class hierarchy other than some very sparse examples. Printing the objects returned isn't much help, they all seem to be very clever generators and stuff or have as_text methods. This is probably my python newbieness that's shining through, but I just can't seem to find accessor methods for the DNS records (objects) returned even.

As ever on the Internet, someone has felt the pain already, and done a good deed.  Already in 2005 even. So presenting http://agiletesting.blogspot.com/2005/08/managing-dns-zone-files-with-dnspython.html 

(Mumble.  Someone ought to start a wiki to document it, but unfortunately that won't be me)

by nicolai (noreply@blogger.com) atMar 01, 2024 14:49

January 01, 2024

NUUG Foundation


NUUG Foundation utlyser reisestipender Søknader kan sendes inn til enhver tid.

Jan 01, 2024 10:24

November 21, 2023

Espen Braastad

Filebin.net has moved to Hetzner

About the move Yesterday, on the 20th of November 2023, the hosting of the filebin.net service was moved from Redpill Linpro in Norway to Hetzner in Germany. Shout out to Redpill Linpro for providing free hosting for 11 years! Some history Filebin was a hobby project that let me learn the HTML5 File API. The end result made it easy to share photos and videos with friends and family, which was difficult at the time for non technical people.

Nov 21, 2023 22:00

August 29, 2023

NUUG Foundation

ISOC Norge session on cryptography

Experts in applied cryptography will discuss current practices, including key management and quantum key cryptography

Aug 29, 2023 18:06

August 26, 2023

NUUG news

Støtteerklæring til Datatilsynet

NUUG (Norwegian Unix User Group) er opptatt av å beskytte individets privatsfære og personlige integritet i den digitale tidsalderen. Vi anerkjenner viktigheten av å regulere og overvåke bruken av persondata, spesielt når det kommer til adferdsbasert markedsføring på plattformer som Facebook og Instagram.

Datatilsynets beslutning om å legge ned midlertidig forbud mot adferdsbasert markedsføring på Facebook og Instagram i Norge er et viktig skritt for å beskytte norske borgere mot uønsket overvåkning og profilering. Dette tiltaket er i tråd med prinsippene om personvern og datasikkerhet som vi, en forening som støtter fri programvare og åpne standarder, har kjempet for i mange år.

Vi mener at Datatilsynet tar et helt korrekt, og absolutt nødvendig standpunkt for å sikre at innbyggernes personlige data blir behandlet på en rettferdig og lovlig måte. Det er viktig at selskaper som Meta blir stilt til ansvar, følger regelverket og gir brukerne muligheten til å ta informerte valg når det gjelder deres persondata, som et lite skritt på veien mot å få slutt på innsamling og utnytting av privat informasjon.

Vi støtter helhjertet opp om Datatilsynets arbeid med å håndheve personvernregler og opprettholde individets rettigheter i den digitale sfæren.

Med vennlig hilsen,
Peter N. M. Hansteen
Styreleder, Norwegian Unix User Group (NUUG)

Aug 26, 2023 10:30

June 13, 2023

Dag-Erling Smørgrav

DNS over TLS in FreeBSD with Quad9

It has come to my attention that Quad9 have a blog post providing incorrect instructions for how to set up a FreeBSD system to use their service. I have attempted to get in touch with the author and get him to correct it but have received no response. So here, for the benefit of the Great Search Engine Gods, is the correct procedure; see my earlier post on the topic for more details on how it works.

# cat >/etc/rc.conf.d/local_unbound <<EOF
local_unbound_forwarders=" 2620:fe::fe@853#dns.quad9.net 2620:fe::9@853#dns.quad9.net"
# service local_unbound setup
# service local_unbound restart

No need to reboot.

Note that if you only have IPv4, you may experience slightly degraded performance unless you leave out the IPv6 addresses from the local_unbound_forwarders line (and vice versa in the unlikely scenario where you only have IPv6).

by Dag-Erling Smørgrav atJun 13, 2023 18:26

December 05, 2022

Ole Aamot – GNOME Development Blog

Saving GNU Network Object Model Environment 44 on a Network Service

Consider saving the entire sources of https://download.gnome.org/sources/ by uploading the sources of the latest sources to a Network as a Service entity such as gnomevoice.org.

Printing source code saved GNOME 2.0 after the Red Hat, Inc.’s Power Failure in North Carolina during Winter 1999, as GNOME 1.0 is suddenly lost.

A worldwide power failure should be of our greatest concern at the moment.

Never put all of your eggs in the same basket, was the lesson learnt from open source domains such as sf.net, mozillathunderbird.org, and gphoto.fix.no.

We must also be prepared to save Project GNOME Voice like a Network as a Service.

Copyleft Solutions is the current Network as a Service host of gnomeradio.org and gnomevoice.org.

by oleaamot atDec 05, 2022 07:35

Apology regarding mail.gnome.org

I work on Radio, Gingerblue and Voice, and previously I worked on gPhoto in the GNOME Project since November 1998.

While I have written, always as a non-profit, non-paid volunteer for the GNU and the GNOME project, Radio in 2002-2022, Gingerblue in 2018-2022 and Voice in 2022, and I posted org.gnome.Radio during GUADEC 2022 with criticism for posting it publicly from one significant member of the GNOME community, I have always stood up for common and core GNOME values since I took part at the discussion of the GNOME Foundation at ENST in Paris in March 2000. I joined GNOME in November 1998 (24 years ago) after co-launching and working on the GNU Photo project for digital still photography device support in GNOME in November 1998 that turned into gPhoto in 1999.

I have seen a gradual transition of GNOME services away from people.gnome.org since 2020 that I never spoke up on.

GNOME Foundation’s board of directors agreed to the gradual transition away from the mailing lists years ago, so I doubt they’ll suddenly change tack now. Even I’m familiar with the discussions and plans around this planned change, all though I wasn’t an active GNOME contributor between 2004-2014, I disagreed with the GNOME Foundation.

You can view the historic email archives on mail.gnome.org and the GNOME Foundation list at https://mail.gnome.org/archives/foundation-list/

Where will future GNOME Foundation discussions take place? Most likely on https://discourse.gnome.org.

My experience with this platform is vague. I am more familiar with mail.gnome.org. However, the voting of the GNOME Foundation’s board of directors stands.

mail.gnome.org is going stale after 25 1/2 years of service in the project.

Today I am announcing that I am leaving the GNOME Foundation after 25 years of service and will work further on the gnomeradio.org, gingerblue.org, and gnomevoice.org domains, as well as complete my thesis Public Voice Communication about the software Voice (gnome-voice) at NTNU before June 24th, 2024.

Thesis: Public Voice Communication

by oleaamot atDec 05, 2022 00:00

August 04, 2022

Nicolai Langfeldt

Backup of postgres in a kubernetes pod (and a docker container)

Kubernetes is a lot of things, some cool, some vexsome.

One of the things is that it does not necessarily make it easy to make backups of data stored in pods.  And if the data is a database you can't really back it up from the outside in the data storage mount either since the backup is liable to become inconsistent and unusable. You have to deal with the database engine to get a consistent backup.

At work we have a self hosted kubernetes cluster and quite a bit og old fashioned infrastructure too.  Lately some postgres databases have been deployed here with the bitnami helm chart.

We use automation tools to set up backups and all kinds of things.  And in these tools we prefer not to put passwords if we can avoid it.

One _could_ make a backup using pg_dump or similar giving it the pod IP, username and password, but we'd like to avoid that.

Examining the bitnami postgres pod it was set up quite interestingly with postgres running at uid 1001 which does not have a user account associated. This is apparently to accomodate openshift.  It also makes it quite hard to run psql inside the pod:

$ psql  
psql: local user with ID 1001 does not exist

There are additional things that complicate it.  Studying the github issues for the helm chart I found that the makers of this had a workaround.  After experimenting with kubectl I managed to construct a command that does not require us to put the database password into the backup script:

kubectl exec -n $NAMESPACE $PODNAME -- bash -c ". /opt/bitnami/scripts/libpostgresql.sh && postgresql_enable_nss_wrapper && PGPASSWORD=\$POSTGRES_PASSWORD pg_dump $OPTS -c -U postgres $DB"

The magic is in libpostgresql.sh and the postgresql_enable_nss_wrapper, which makes the user "postgres" defined for the commands that follow.

You have to supply the environment variables NAMESPACE, PODNAME, the optional OPTS for options and DB yourself. POSTGRES_PASSWORD is taken from the deployed pod.

by nicolai (noreply@blogger.com) atAug 04, 2022 11:49

October 10, 2021

Dag-Erling Smørgrav

Automatic Let’s Encrypt certificates in Apache with mod_md

Since 2.4.30, Apache comes with experimental support for ACME certificates (Let’s Encrypt et al.) in the form of mod_md (short for “managed domains”). It’s kind of a pain but it’s still better than what I had before, i.e. a mess of shell and Perl scripts based on Crypt::LE, and if your use case is limited to Apache, it appears to be simpler than Certbot as well. Unfortunately for me, it’s not very well documented and I wasted a considerable amount of time figuring out how to use it. Fortunately for you, I then decided to blog about it so you don’t have to repeat my mistakes.

Edit: the author of mod_md, Stefan Eissing, got in touch and pointed me to his own documentation, which is far superior to the one available from Apache.

My starting point is a freshly installed FreeBSD 13.0 server with Apache 2.4, but this isn’t really OS dependent.

First, you will need mod_ssl (of course) and a session cache, and you will need to tweak the TLS parameters, as the defaults are far from fine.

LoadModule ssl_module libexec/apache24/mod_ssl.so
SSLProtocol +TLSv1.3 +TLSv1.2
SSLHonorCipherOrder off
SSLCompression off

LoadModule socache_dbm_module libexec/apache24/mod_socache_dbm.so
SSLSessionCache dbm:/var/db/httpd_ssl_cache.db

You will also need to load mod_md, of course, and mod_watchdog, which mod_md needs to function.

LoadModule watchdog_module libexec/apache24/mod_watchdog.so
LoadModule md_module libexec/apache24/mod_md.so
MDCertificateAgreement accepted
MDContactEmail acme@example.com

The MDCertificateAgreement directive indicates that you have read and accepted Let’s Encrypt’s subscriber agreement, while MDContactEmail is the email address that you used to sign up to Let’s Encrypt.

You will also need mod_rewrite to redirect HTTP requests to HTTPS and mod_headers for HSTS.

LoadModule rewrite_module libexec/apache24/mod_rewrite.so
LoadModule headers_module libexec/apache24/mod_headers.so

By default, Apache only listens on port 80, so you’ll need an extra Listen directive for port 443.

Listen 443

And as always with Apache, you should probably set ServerName and ServerAdmin to sensible values.

ServerName server.example.com
ServerAdmin www@example.com

Next, set up an HTTP-only virtual host that you can use to check the status of mod_md.

<VirtualHost *:80>
  ServerName localhost
  <Location />
    Require ip ::1
  <Location "/md-status">
    SetHandler md-status

(Once Apache is running, you will be able to query it at any time as http://localhost/md-status.)

On to the actual website. First, you need to tell mod_md to manage certificates for it.

MDomain site.example.com

Next, set up a redirect from HTTP to HTTPS for everything except ACME challenge tokens.

<VirtualHost localhost:80>
  ServerName site.example.com
  RewriteEngine on
  RewriteRule "^/(?!.well-known/acme-challenge)(.*)" https://site.example.com/$1 [R=301,L]
  ErrorLog /www/site.example.com/logs/http-error.log
  CustomLog /www/site.example.com/logs/http-access.log combined

And finally, the site itself, including HSTS and strict SNI:

<VirtualHost *:443>
  ServerName site.example.com
  SSLEngine on
  SSLStrictSNIVHostCheck On
  Header always set Strict-Transport-Security "max-age=15552000; includeSubdomains;"
  DocumentRoot /www/site.example.com/data
  IncludeOptional /www/site.example.com/etc/*.conf
  ErrorLog /www/site.example.com/logs/https-error.log
  CustomLog /www/site.example.com/logs/https-access.log combined

Now start Apache and monitor the error log. You should see something like this pretty quickly:

[Sun Oct 10 16:15:27.450401 2021] [md:notice] [pid 12345] AH10059: The Managed Domain site.example.com has been setup and changes will be activated on next (graceful) server restart.

Once you do as it says (apachectl graceful), your site will be up and running and you can head over to the Qualys SSL Server Test and admire your solid A+.

Download the sample configuration and try it out yourself.

by Dag-Erling Smørgrav atOct 10, 2021 18:19

May 31, 2018

Kevin Brubeck Unhammer

Kan samisk brukes i det offentlige rom?

Hvis vi hadde laget et program som oversatte fra norsk til samisk, ville resultatet ha vært en samisk som er minst like dårlig som den norsken vi er i stand til å lage nå. Norsk og samisk er grammatisk sett svært ulike, og det er vanskelig å få til god samisk på grunnlag av norsk. Et slikt program vil føre til publisering av en hel masse svært dårlig samisk. En situasjon der mesteparten av all samisk publisert på internett kommer fra våre program fortoner seg som et mareritt. Det ville rett og slett ha ødelagt den samiske skriftkulturen.

Sjå kronikken: https://www.nordnorskdebatt.no/samisk-sprak/digitalisering/facebook/kan-samisk-brukes-i-det-offentlige-rom/o/5-124-48030

by unhammer atMay 31, 2018 09:00

October 23, 2017

Espen Braastad

ZFS NAS using CentOS 7 from tmpfs

Following up on the CentOS 7 root filesystem on tmpfs post, here comes a guide on how to run a ZFS enabled CentOS 7 NAS server (with the operating system) from tmpfs. Hardware HP ProLiant MicroServer HP ProLiant MicroServer Remote Access Card AMD Turion(tm) II Neo N54L Dual-Core Processor 2x 8 GB 1333 MHZ ECC memory modules 4x 4 TB SATA hard drives (HGST, Western Digital and Seagate) Built-in Broadcom Limited NetXtreme BCM5723 Gigabit Ethernet adapter Preparing the build environment The disk image is built in macOS using Packer and VirtualBox.

Oct 23, 2017 23:20

February 13, 2017

Mimes brønn

En innsynsbrønn full av kunnskap

Mimes brønn er en nettjeneste som hjelper deg med å be om innsyn i offentlig forvaltning i tråd med offentleglova og miljøinformasjonsloven. Tjenesten har et offentlig tilgjengelig arkiv over alle svar som er kommet på innsynsforespørsler, slik at det offentlige kan slippe å svare på de samme innsynshenvendelsene gang på gang. Du finner tjenesten på


I følge gammel nordisk mytologi voktes kunnskapens kilde av Mime og ligger under en av røttene til verdenstreet Yggdrasil. Å drikke av vannet i Mimes brønn ga så verdifull kunnskap og visdom at den unge guden Odin var villig til å gi et øye i pant og bli enøyd for å få lov til å drikke av den.

Nettstedet vedlikeholdes av foreningen NUUG og er spesielt godt egnet for politisk interesserte personer, organisasjoner og journalister. Tjenesten er basert på den britiske søstertjenesten WhatDoTheyKnow.com, som allerede har gitt innsyn som har resultert i dokumentarer og utallige presseoppslag. I følge mySociety for noen år siden gikk ca 20 % av innsynshenvendelsene til sentrale myndigheter via WhatDoTheyKnow. Vi i NUUG håper NUUGs tjeneste Mimes brønn kan være like nyttig for innbyggerne i Norge.

I helgen ble tjenesten oppdatert med mye ny funksjonalitet. Den nye utgaven fungerer bedre på små skjermer, og viser nå leveringsstatus for henvendelsene slik at innsender enklere kan sjekke at mottakers epostsystem har bekreftet mottak av innsynshenvendelsen. Tjenesten er satt opp av frivillige i foreningen NUUG på dugnad, og ble lansert sommeren 2015. Siden den gang har 121 brukere sendt inn mer enn 280 henvendelser om alt fra bryllupsutleie av Operaen og forhandlinger om bruk av Norges topp-DNS-domene .bv til journalføring av søknader om bostøtte, og nettstedet er en liten skattekiste av interessant og nyttig informasjon. NUUG har knyttet til seg jurister som kan bistå med å klage på manglende innsyn eller sviktende saksbehandling.

– «NUUGs Mimes brønn var uvurderlig da vi lyktes med å sikre at DNS-toppdomenet .bv fortsatt er på norske hender,» forteller Håkon Wium Lie.

Tjenesten dokumenterer svært sprikende praksis i håndtering av innsynshenvendelser, både når det gjelder responstid og innhold i svarene. De aller fleste håndteres raskt og korrekt, men det er i flere tilfeller gitt innsyn i dokumenter der ansvarlig etat i ettertid ønsker å trekke innsynet tilbake, og det er gitt innsyn der sladdingen har vært utført på en måte som ikke skjuler informasjonen som skal sladdes.

– «Offentlighetsloven er en bærebjelke for vårt demokrati. Den bryr seg ikke med hvem som ber om innsyn, eller hvorfor. Prosjektet Mimes brønn innebærer en materialisering av dette prinsippet, der hvem som helst kan be om innsyn og klage på avslag, og hvor dokumentasjon gjøres offentlig. Dette gjør Mimes Brønn til et av de mest spennende åpenhetsprosjektene jeg har sett i nyere tid.» forteller mannen som fikk åpnet opp eierskapsregisteret til skatteetaten, Vegard Venli.

Vi i foreningen NUUG håper Mimes brønn kan være et nyttig verktøy for å holde vårt demokrati ved like.

by Mimes Brønn atFeb 13, 2017 14:07

July 15, 2016

Mimes brønn

Hvem har drukket fra Mimes brønn?

Mimes brønn har nå vært oppe i rundt et år. Derfor vi tenkte det kunne være interessant å få en kortfattet statistikk om hvordan tjenesten er blitt brukt.

I begynnelsen av juli 2016 hadde Mimes brønn 71 registrerte brukere som hadde sendt ut 120 innsynshenvendelser, hvorav 62 (52%) var vellykkede, 19 (16%) delvis vellykket, 14 (12%) avslått, 10 (8%) fikk svar at organet ikke hadde informasjonen, og 12 henvendelser (10%; 6 fra 2016, 6 fra 2015) fortsatt var ubesvarte. Et fåtall (3) av hendvendelsene kunne ikke kategoriseres. Vi ser derfor at rundt to tredjedeler av henvendelsene var vellykkede, helt eller delvis. Det er bra!

Tiden det tar før organet først sender svar varierer mye, fra samme dag (noen henvendelser sendt til Utlendingsnemnda, Statens vegvesen, Økokrim, Mediatilsynet, Datatilsynet, Brønnøysundregistrene), opp til 6 måneder (Ballangen kommune) eller lenger (Stortinget, Olje- og energidepartementet, Justis- og beredskapsdepartementet, UDI – Utlendingsdirektoratet, og SSB har mottatt innsynshenvendelser som fortsatt er ubesvarte). Gjennomsnittstiden her var et par uker (med unntak av de 12 tilfellene der det ikke har kommet noe svar). Det følger av offentlighetsloven § 29 første ledd at henvendelser om innsyn i forvaltningens dokumenter skal besvares «uten ugrunnet opphold», noe som ifølge Sivilombudsmannen i de fleste tilfeller skal fortolkes som «samme dag eller i alle fall i løpet av 1-3 virkedager». Så her er det rom for forbedring.

Klageretten (offentleglova § 32) ble benyttet i 20 av innsynshenvendelsene. I de fleste (15; 75%) av tilfellene førte klagen til at henvendelsen ble vellykket. Gjennomsnittstiden for å få svar på klagen var en måned (med unntak av 2 tillfeller, klager sendt til Statens vegvesen og Ruter AS, der det ikke har kommet noe svar). Det er vel verdt å klage, og helt gratis! Sivilombudsmannen har uttalt at 2-3 uker ligger over det som er akseptabel saksbehandlingstid for klager.

Flest henvendelser var blitt sendt til Utenriksdepartementet (9), tett etterfulgt av Fredrikstad kommune og Brønnøysundregistrene. I alt ble henvendelser sendt til 60 offentlige myndigheter, hvorav 27 ble tilsendt to eller flere. Det står over 3700 myndigheter i databasen til Mimes brønn. De fleste av dem har dermed til gode å motta en innsynshenvendelse via tjenesten.

Når vi ser på hva slags informasjon folk har bedt om, ser vi et bredt spekter av interesser; alt fra kommunens parkeringsplasser, reiseregninger der statens satser for overnatting er oversteget, korrespondanse om asylmottak og forhandlinger om toppdomenet .bv, til dokumenter om Myanmar.

Myndighetene gjør alle mulige slags ting. Noe av det gjøres dÃ¥rlig, noe gjør de bra. Jo mer vi finner ut om hvordan  myndighetene fungerer, jo større mulighet har vi til Ã¥ foreslÃ¥ forbedringer pÃ¥ det som fungerer dÃ¥rlig… og applaudere det som  bra.  Er det noe du vil ha innsyn i, sÃ¥ er det bare Ã¥ klikke pÃ¥ https://www.mimesbronn.no/ og sÃ¥ er du i gang 🙂

by Mimes Brønn atJul 15, 2016 15:56

June 01, 2016

Kevin Brubeck Unhammer

Maskinomsetjing vs NTNU-eksaminator

Twitter-brukaren @IngeborgSteine fekk nyleg ein del merksemd då ho tvitra eit bilete av nynorskutgåva av økonomieksamenen sin ved NTNU:

Dette var min økonomieksamen på "nynorsk". #nynorsk #noregsmållag #kvaialledagar https://t.co/RjCKSU2Fyg
Ingeborg Steine (@IngeborgSteine) May 30, 2016

Kreative nyvinningar som *kvisleis og alle dialektformene og arkaismane ville vore usannsynlege å få i ei maskinomsett utgåve, så då lurte eg på kor mykje betre/verre det hadde blitt om eksaminatoren rett og slett hadde brukt Apertium i staden? Ingeborg Steine var så hjelpsam at ho la ut bokmålsutgåva, så då får me prøva 🙂


Ingen kvisleis og fritt for tær og fyr, men det er heller ikkje perfekt: Visse ord manglar frå ordbøkene og får dermed feil bøying, teller blir tolka som substantiv, ein anna maskin har feil bøying på førsteordet (det mangla ein regel der) og at blir ein stad tolka som adverb (som fører til det forunderlege fragmentet det verta at anteke tilvarande). I tillegg blir språket gjenkjent som tatarisk av nettsida, så det var kanskje litt tung norsk? 🙂 Men desse feila er ikkje spesielt vanskelege å retta på – utviklingsutgåva av Apertium gir no:


Det er enno eit par småting som kunne vore retta, men det er allereie betre enn dei fleste eksamenane eg fekk utdelt ved UiO …

by unhammer atJun 01, 2016 09:45

A complete feed is available in any of your favourite syndication formats linked by the buttons below.

[RSS 1.0 Feed] [RSS 2.0 Feed] [Atom Feed] [FOAF Subscriptions] [OPML Subscriptions]