Modern-day package requirements

A little rant first: Many thanks to the EU (and all the people who decide on topics related to tech without having any idea on how tech stuff actually works). Their GDPR is the reason for me having been really occupied with work this month! Email being a topic that I’m teaching myself while writing the series of posts about it, I have to get back to it as time permits. This means that for May I’m going to write about a topic that I’m more familiar with.

Benefits of package management

I’ve written about package management before, telling a bit about the history of it and then focusing on how package management is done on FreeBSD. The benefits of package management are so obvious that I don’t see any reason not to content myself with just touching them:

Package management makes work put into building software re-usable. It helps you to install software and to keep it up to date. It makes it very easy to remove things in a clean manner. And package management provides a trusted source for your software needs. Think about it for just a moment and you’ll come up with more benefits.

Common package management requirements

But let’s take a look at the same topic from a different angle. What do we actually require our package systems to do? What features are necessary? While this may sound like a rather similar question, I assure you that it’s much less boring. Why? Because we’re looking at what we need – and it’s very much possible that the outcome actually is: No, we’re not using the right tool!

Yes, we need package management, obviously. While there’s this strange, overly colorful OS that cannot even get the slashes in directories right, we can easily dismiss that. We’re talking *nix here, anyway!

Ok, ok, there’s OmniOS with its KYSTY policy. That stands for “keep your software to yourself” and is how the users of said OS describe the fact that there’s no official packages available for it. While it’s probably safe to assume that the common kiddies on the web don’t know their way around on Solaris, I’m still not entirely convinced that this is an approach to recommend.

Going down that road is a pretty bold move, though. Of course it’s possible to manage your software stack properly. With a lot of machines and a lot of needed programs this will however turn into an abundance of work (maybe there are companies out there who enjoy paying highly qualified staff to carefully maintain software while others rarely spend more than a couple of minutes per day to keep their stuff up-to-date).

Also if you’re a genius who uses the method that’s called “It’s all in my head!” in the Linux from Scratch book, I’m not going to argue against it (except that this is eventually going to fail when you have to hand things over to a mere mortal when you’re leaving).

But enough of those really special corner cases. Let’s discuss what we actually require our package systems to provide! And let’s do so from the perspective not of a hobby admin but from a business-orientated one. There are three things that are essential and covered by just about any package system.

Ease of use

One of the major requirements we have today is that package management needs to be easy to use. Yes, building and installing software from source is usually easy enough on *nix today. However figuring out which configure options to use isn’t. Build one package without some feature and you might notice much later that it’s actually needed after all. Or even find that you compiled something in that’s getting in the way of something else later! Avoiding this means having to do some planning.

Reading (and understanding!) the output of ./configure –help probably isn’t something you’re going to entrust the newly employed junior admin with. Asking that person to just install mysql on the new server will probably be ok, though. Especially since package managers will usually handle dependencies, too.

Making use of package management means that somebody else (the package maintainer) has already thought about how the software will be used in most of the cases. For you this means that not having to hire and pay senior admins for work that can be done by a junior in your organization, too.

Fast operations

Time is money and while “compiling!” is a perfectly acceptable excuse for a dev, it shouldn’t be for an admin who is asked why the web server still wasn’t deployed on the new system.

Compiling takes time and uses resources. Even if your staff uses terminal multiplexers (which they should), thus being able to compile stuff on various systems at the same time, customers usually want software available when they call – and not two hours later (because the admin was a bit confused with the twenty-something tmux sessions and got stuck with one task while a lot of the other compile jobs have been finished ages ago).

Don’t make your customers wait longer than necessary. Most requests can be satisfied with a standard package. No need to delay things where it doesn’t make any sense.

Regular (security) updates

It’s 2018 and you probably want that new browser version that mitigates some of the Spectre vulnerabilities on your staff’s workstations ASAP. And maybe you even have customers that are using Drupal, in which case… Well, you get the point.

While it does make sense to subscribe to security newsletters and keep an eye on new CVEs, it takes a specialist to maintain your own software stack. When you got word of a new CVE for a program that you’re using that doesn’t mean the way you built the software makes it vulnerable. And perhaps you have a special use-case where it is but the vulnerability is not exploitable.

Again this important task is one that others have already done for you if you use packaged software from a popular repository. Of course those people are not perfect either and you may very well decide that you do not trust them. Doing everything yourself because you think you can do better is a perfectly legitimate way of handling things. Chances are however that your company cannot afford a specialist for this task. And in that case you’re definitely better off trusting the package maintainers than carelessly doing things yourself that you don’t have the knowledge for.

Special package management requirements

Some package managers offer special features not found in other ones. If your organization needs such a feature this can even mean that a new OS or distribution is chosen for some job because of that. Also repositories vary greatly in the number of software they offer, in the software versions that they hold and in the frequency of updates taking place.

“Stability” vs. “freshness”

A lot of organizations prefer “stable”, well-tested software versions. In many cases I think of “stable” as a marketing word for “really old”. For certain use-cases I agree that it makes sense to choose a system where not much will change within the next decade. But IMO this is far less often the case than some decision makers may think.

The other extreme is rolling-release systems which generally adapt the newest software versions after minimal testing. And yes, at one point there was even the “Arch server project” (if I remember the name correctly), which was all about running Arch Linux on a server. In fact this is not as bad an idea as it may seem. There are people who really live Arch and they’ll be able to maintain an Arch server for you. But I think this makes most sense as a box for your developers who want to play with new versions of the software that you’re using way before it hits your actual dev or even prod servers.

Where possible I definitely favor the “deliver current versions” model. Not even due to the security aspect (patches are being backported in case of the “stable” repositories) but because of the newer features. It’s rather annoying if you want to make use of the jumphost ability of OpenSSH (for which a nice new way of doing it was introduced not too long ago) and then notice you can’t use it because there’s that stupid CentOS box with its old SSH involved!

Number of packages

If you need one or a couple of packages that are not available (or too old) in the package repository of your OS or distribution, chances are that external repos exist or that the upstream project provides packages. That may be ok. However if you find that a lot of the software that you require is not available this may very well be a good reason to think about using a different OS or distribution.

A large number of packages in the repository increases the chance that you may get what you need. Still it can very well be the case where certain packages that you require (and which are rather costly to maintain yourself) are available on another repo.

Package auditing

Some package systems allow you to audit the installed packages. If security is very important for your organization, you’ll be happy to have your package tool recommend to “upgrade or deinstall” the installed version of some application because it’s known to be vulnerable.

Flexibility

What if you have special needs on some servers and require support for rarely needed functionality to be compiled into some software? With most package systems you’re out of luck. The best thing that you can do is roll your own customized package using a different name.

The ports tree on *BSD or portage on Gentoo Linux really show their power in this case, allowing you to just build the software easily and with the options that you choose.

Heterogeneous environments

So most of the time it makes perfect sense to stick to the standard repository for your OS or distribution. If you have special needs you’d probably consider another one and use the standard repo for that one. But what about heterogeneous environments?

Perhaps your database product only runs on, say, CentOS. You don’t have much choice here. However a lot of customers want their stuff hosted on Linux but they demand newer program versions. So a colleague installed several Ubuntu boxes. And another colleague, a really strange guy, slipped in some FreeBSD storage servers! When the others found out that this was not even Linux and started protesting (because “BSD is dying”), they were already running too damn well to replaced with something that does not have as good ZFS support.

A scenario like that is not too uncommon. If you don’t do anything about it, this might lead to “camps” among the employees; some of them are sure that CentOS is so truly enterprise that it’s the way to go. And of course yum is better than apt-get (and whatever that BSD thing offers – if anything). Some others laugh at that because Ubuntu is clearly superior and using apt-get feels a lot more natural than having to use yum (which is still better than that BSD thing which they refuse to even touch). And then there’s the BSD guy who is happy to have a real OS at his hand rather than “kernel + distro-chosen packages”.

In general if you are working for a small organization, every admin will have to be able to work with each system that is being used. Proper training for all package systems is probably expansive and thus managers will quite possible be reluctant to accept more than two package systems.

Portability

There’s a little known (in the Linux community) solution to this: Pkgsrc (“package source”). It’s NetBSD’s package management system. But with probably the most important goal of the NetBSD project being portability, it’s portable, too!

Pkgsrc is available for many different platforms. It runs on NetBSD, of course. But it runs on Linux as well as on the other BSDs and on Solaris. It’s even available for commercial UNIX platforms and various exotic platforms.

For this very nature of it, Pkgsrc may be one answer for your packaging needs in heterogeneous environments. It can provide a unified means of package management across multiple platforms. It rids you of the headache of version jungle if you use different repositories for different platforms. And it’s free and open source, too!

Is it the only solution out there? No. Is it the best one? That certainly depends on what you are looking for specifically. But it’s definitely something that you should be aware of.

What’s next?

The next post will be about a relatively new alternative to traditional package management systems that tries to deliver all the strong points in one system while avoiding their weaknesses!

Advertisements

Introduction to email (pt. 2): Mail dialog / the “mail” command

The first post of the series discussed some fundamental general knowledge about email (daemons involved, protocols, etc.). It also covered building a test system for actively trying out mail-related things. (I had to update it, however, since I discovered some problems with building the VM.)

I assume that you’ve built the test system with Vagrant to follow along. If you haven’t, please refer back to the previous post to learn how to do this. You’re free to use any FreeBSD system of course. Using vagrant has a few advantages, though. The most important is that it allows you to save the state so you can continue to play with your VM while still being able to return to the clean state anytime to follow the next parts of this series. This post will demonstrate how to send mail from the console and point out a few important things involved.

Sending mail with… “mail”

Change to the appropriate directory where you keep your Vagrant file for the mail-vm. If you’ve tinkered with the VM after the first post, reset it to the last state (if it hasn’t changed, you may issue vagrant up instead of restoring the snapshot) and enter the VM:

% cd ~/vagrant/mail-vm
% vagrant snapshot restore mail1
% vagrant ssh

Thanks to the changes we made to the config in the previous post, you should be directly logged in as root. Let’s see if root has any mail. As part of FreeBSD’s base system comes the mail utility which is a very basic MUA able to compose and view messages. Execute it without any parameters for now:

# mail

No mail for root

Ok, so root does not currently have any messages. On an average FreeBSD system there’d probably be mail there as by default the system reports in for e.g. a daily security run output. But on this system there’s nothing so far. So let’s send a message now! We can also use mail for that. With the -s parameter we can specify the subject and of course we need to tell it who we’re sending the message to! When we did that, the program will let us type in the actual message. To indicate that we’re done, we need to place a single period (.) in line all by itself and hit the return key:

# mail -s "Test mail 1" root
This is a test message!
.

EOT

Mail acknowledged the action by printing EOT (end of text). Congratulations, you’ve just sent an email from root to root! And yes, this is the same kind of email that you know from writing to other people, only done locally in this case.

Hard to believe? Let’s do it again and make use of something else that you know from email: Sending a carbon copy (cc) to another user:

# mail -s "Test mail 2" root -c vagrant
This is another test message!
.

EOT

All done! But did it actually do what we wanted it to? Let’s become the vagrant user and check our mail real quick:

# su -l vagrant
% mail

>N 1 root@mail-vm.local Fri Apr 20 20:56 19/719 “Test mail 2”

Nice: There it is! Mail obviously found a message with the subject “Test mail 2” that was sent by root@mail-vm.local. Looks good so far. Let’s quit the mail utility by pressing CTRL-D or issuing the command x.

Sending and checking mail with – mail

The mail dialog

What’s next? How about sending an email message back to root – and this time tell mail to be verbose?

% mail -v -s "Test mail 3" root
And yet another!
.

EOT

This time our mail utility shows what’s usually happening in the background:

The mail dialog! This is basically what the MUA and the MTA are talking to make mail delivery happen.

Beginning of a mail dialog

Let’s take a closer look at some snippets:

[…]
root… Connecting to [127.0.0.1] via relay…
220 mail-vm ESMTP Sendmail 8.15.2/8.15.2; Fri, 20 Apr 2018 20:59:15 +0200 (CEST)
>>> EHLO mail-vm.local
250-mail-vm.local Hello localhost [127.0.0.1], pleased to meet you
[…]

Here we can see the beginning of the dialog: Our MUA (mail) connected to the MTA (Sendmail in this case), said “hello” (or rather EHLO according to the protocol rules) and was greeted by tho MTA, too. We’ll skip the next bits; client and server agree on various parameters to upgrade their connection to use encryption instead of plain text. While encryption is definitely an important topic when it comes to mail, it also makes things a fair bit more complicated and we’ll ignore it for now.

MAIL From: SIZE=48
250 2.1.0 … Sender ok
>>> RCPT To:
>>> DATA
250 2.1.5 … Recipient ok
354 Enter mail, end with “.” on a line by itself
>>> .

The MUA announces the sender and the MTA acknowledges it. Then the MUA tells the MTA the recipient as well as the actual message and the latter acknowledges it again.

250 2.0.0 w3KIxFbt000881 Message accepted for delivery
root… Sent (w3KIxFbt000881 Message accepted for delivery)
Closing connection to [127.0.0.1]
>>> QUIT
221 2.0.0 mail-vm.local closing connection

Finally the MTA tells the MUA that it accepted the message and will take care of delivering it. And that concludes the mail sending action from the perspective of the MUA. The MTA has taken over and will do something with the message.

What you’ve been reading here is an example of what an SMTP dialog looks like. If the MTA figures that the message cannot be delivered locally, it will try to connect to another MTA and pass it on using the same protocol. And if it cannot deliver the message at all (e.g. the remote MTA rejected the message, probably because the recipient user does not exist), the MTA is probably configured to send a message to the original sender, letting him know that the message was lost.

Using mail to view messages

We’re done with the vagrant user for now so let’s exit back to root:

% logout

Root should have received three mails. We can use the mail command again to look at our mailbox:

# mail

The result will look like on the bottom of this picture:

Second part of the SMTP dialog & checking root’s unread mail

Right, all three were received and are there. Sendmail obviously did its job after taking over the messages from our MUA! Mail also tells us that we have three messages in total of which three are new. And it mentions /var/mail/root. What’s that? Well, it’s a file. But let’s quit the MUA again and take a closer look:

# less /var/mail/root

Messages in the inbox file

What we’ve stumbled across here is the root user’s mailbox for incoming mail (“inbox”). It’s just a file holding the text and headers of all unread messages. Alright, all the messages are there and can be accessed by all means that you typically access text files with. But what about mail? Can you use it to view the messages, too?

You bet that’s possible. Let’s run mail again:

# mail

Do you see a difference? No? Look more closely! Last time all three messages had an uppercase “N” in front of them, meaning new. Now there’s a “U”: Those messages are still unread, but they were already in the inbox last time we checked our mail.

The greater-than sign hints that mail 1 is selected. To read it, issue the command “print” (or use the abbreviation “p”). The plus character selects the next message, while minus does the opposite. If you’d like to play around with the mail MUA a little, you should know that there are many more commands like e.g. “f” to print the current message header. Should you want to know more, the manpage is your friend.

Viewing messages with mail

If we exit now, this is what mail tells us:

Saved 2 messages in mbox
Held 1 message in /var/mail/root

What does that mean?

Inbox and mbox

If you like analogies, think of /var/mail/root as the mailbox outside of your house. If you get new mail, it’ll be put into there. Let’s say you got three letters. The analogy to what we did a minute ago was going to the mailbox and take only two of the letters out to read them. After we read them we put them somewhere were we use to stash our letters as long as we think that we might need them again. The same thing happened here: There’s one message “held” in /var/mail/root because we didn’t bother to touch it, yet. The other two were moved to the “mbox”.

Ok, what’s the mbox? It’s another file that holds email messages. Actually there’s not much different about it compared to the inbox. It’s just used differently: To locally store your mail whereas your inbox is typically on a remote system. In our case both are on the same system and so it’s just removing a message from one file and putting it in another.

# head -21 ~/mbox

Here you can see the first message and the beginning of the second one (in line 21):

Contents of our mbox

Replying to and deleting messages

If we start mail again we know how to view the one remaining message. What else could we do with it? Well, we could reply to it (“r”) and delete (“d”) it then:

Replying to and deleting a message

That wasn’t too hard, was it? Asking mail for the headers returns a no applicable messages. Now root’s inbox should be empty. Let’s run mail again. What? A new message? Checking back at what we just did, it looks like we sent the reply to both vagrant and root. We didn’t mean to receive this message so let’s delete it, too.

Alright. Our inbox should now really be clean. Is it? Let’s put it to the test:

# mail

No mail for root

It is!

Emptying the inbox again

Excellent. But… How do we access the mails that we didn’t delete which were moved to the mbox? As I said before, the mbox really is only functionally different from the inbox. In fact the inbox is merely a special mbox. On our system it’s special in being the default that mail works with unless told otherwise!

Of course we can tell mail to operate on root’s mbox instead. This is done by using “-f”:

# mail -f /root/mbox

And there are our messages. No magic here.

Accessing root’s mbox

Intermission

That’s it for this article on mail. You should now have a much better understanding of what is happening when a message is being sent – and what a message actually is. Also you’ve met an old Unix tool that probably isn’t going to become your favorite MUA but still gets the job done after several decades. And while it’s not very intuitive, it just helped you to get started in better understanding email. Also it might actually still well suffice for some simple tasks. In fact we’ve only scratched the surface of the mail utility. It can do much, much more. But that’s too special a topic and way beyond the goal of this series on email.

You’ve come to the end of part two. If you’ve been following along with your Vagrant VM, stop it now, make sure that it’s powered off and create a second snapshot:

# shutdown -p now
% vagrant status
% vagrant snapshot save mail2

Until next time!

Introduction to email (pt. 1): Email basics

[update: Seems like the maildir patch for the Alpine mail client does not currently work with the newest version… So we need to get an older version of the ports tree – this is not ideal, but fortunately this is only a test VM where we can do bad things]
[update2: More changes… A necessary patch is no longer available from its previous location]

Email – short for electronic mail – is one of the things of modern life that we all are familiar with… Or are we? We know how to use it and probably have a rough idea of what’s going on when we press the send button. But email is actually a surprisingly complicated topic. You probably won’t notice that until you think about setting up your own mail server for the first time. Once you do however, you’re in for quite some reading.

I thought to write this mail mini series in late 2016 when I had to debug an issue with a customer’s mail system and thus figured that I really, really could use a bit more knowledge when it comes to email. I quickly went on with other tasks, but I’m still interested in the topic – and maybe I’ll find some time for it this time. This series of posts is intended as a summary of things that I found noteworthy about email.

Daemons & Terminology

When it comes to email, various daemons are involved. Daemons? Why of course! Email is native to Unix; it had precursors, yes, but it was on Unix that things really took off. That’s why for understanding email it really helps to understand Unix.

The part of the mail system that’s visible to the user is called Mail User Agent (MUA or just UA) in mail terminology. That’s what most people just call the Email client: Programs like Thunderbird, Sylpheed or Outlook. It can be used to compose messages (that’s the correct term – you’re actually sending messages not emails) and hand them over to an email server or to retrieve messages from there.

The server-side of the mail system consists of multiple daemons. First there’s the Mail Transfer Agent (MTA) that’s responsible for accepting incoming messages (e.g. from the MUA), process it and either send it to a second MTA on a foreign server or to save it locally (if the message’s recipient has an account on this server). To store a message locally, the MTA can pass it to a Mail Delivery Agent (MDA).

It’s common that an MTA accepts email that’s destined for another server and hands it over to that server’s MTA. This is called relaying. To know where it needs to send the message to, it looks at the domain part of the recipients address (xyz@example.com). Then it does a lookup for the MX (Mail eXchange) records in the DNS (Domain Name System) for that zone (DNS terminology; think domain for now.

Protocols

To enable the various daemons to interact with each other they need to follow standards in communicating. These standards come in form of so-called RFCs – if you don’t know what that is, do some quick research right now. No matter what, if it has anything to do with the Internet at all, RFCs are what define the standards that every implementation is expected to follow. There are several protocols which allow for various actions:

The MUA needs to speak SMTP, the Simple Mail Transfer Protocol, if it wants to pass a message to an MTA because that’s what this daemon is expecting. The MTA can use make use of MLTP, the Mail Local Transfer Protocol, to talk to an MDA. And if the MUA is expected to retrieve messages from the mailbox it needs to implement the POP (Post Office Protocol) or IMAP (Internet Mail Access Protocol) protocols so it can communicate with a POP or IMAP daemon which will then read messages stored on the server and send them to the MUA.

Other components

And there’s more when it comes to mail. Today’s internet is well-known as a hostile place. However when email was developed, people on the net were few and shared a common passion: Tech. Nobody meant to do the others any harm. This infantile period is far from what we experience today. But the basic principles of email haven’t changed and in fact cannot be changed easily. So the problem arises how to retroactively secure something that was designed in a carefree way and therefore proved to be inherently insecure?

When you think email today, you automatically have to think encryption, too. Otherwise there might always be someone to eavesdrop on you. When you think email you have to think authorisation. If you don’t protect your mail account somebody may break into it, steal your secrets or abuse it. You have to think spam. How do you avoid being flooded with all those useless messages that want you to buy blue pills or the like? And worse: How do you prevent spammers to use your mail server so you don’t get blacklisted? You have to think viruses, phishing, trojans, etc. Have to think security holes in your applications, newer protocol versions being established, and so on.

You can already see that mail is a rather complex topic that requires you to have a fair bit of knowledge on other topics like e.g. DNS, security and more. Fortunately all the knowledge that you need is somewhere out there. You just need some determination, a lot of free time and a bit of luck to find the relevant pieces. I cannot help you with the former two but I’ll try to provide a source that could help you learn some important things about mail without having to search on for a tutorial (even though of course I cannot cover everything).

So much for a tiny bit of theory. It’s merely meant to be enough so we can start doing something and cover more of our topic along the way.

Building a test system

So let’s build some kind of test system to play around with, shall we? Sure thing. I suggest using FreeBSD – it is an excellent choice of OS to get into the topic. No, not because I’ve come to like it quite a bit and base a lot of what I post on my blog on that system. For many things Linux would be more or less an equally good choice. When it comes to getting into mail however, it isn’t.

If you already know the whole topic quite well, you can install all the needed programs on Linux without any problems. If however you’re just starting out, FreeBSD makes the first steps so much easier as it already comes with a working mail solution by default! Setting up mail server software is a very complex and complicated thing to do and FreeBSD really makes your life so much easier in this regard by removing this obstacle for you.

In a previous tutorial on backups with Bacula I used VirtualBox together with Vagrant and it proved to be a very convenient solution. So I’m going to use it here as well. If you haven’t used VirtualBox or don’t even know what Vagrant is, I’ve written this post for you which explains things very detailed and with pictures. For creating the base box that we need, you can refer to this other post that explains everything step by step. Just make sure that you read this section before you build your base box! Because here’s the customization we need for this VM:

This post assumes version we’re using FreeBSD 11.1 – any version of 11 should be fine, though. If at the time you are reading this 12.x or even newer is out, you may want to check if fundamental things (like finally putting Sendmail to rest and importing a different MTA) have changed in between these versions. Starting with version 11.0, FreeBSD has a new installation dialog screen that let’s you choose some system hardening options. While this is a great idea and I’ve recommended to disable Sendmail in the post about building the base box for Vagrant, it would ruin the mail functionality that we’re going to use here. So make sure to not disable Sendmail for this installation!

Selecting hardening options

Ports work

Also don’t install Bacula as described in the customization section for the Vagrant base box – we’re not going to use it here. Instead do the following (if you’re not using a c-shell variant, leave out the “env” for the second command):

# svnlite co svn://svn.freebsd.org/ports/tags/RELEASE_11_0_0 /usr/ports
# env ASSUME_ALWAYS_YES=1 pkg bootstrap
# sed -i.bak -e 's|pkg$|pkg register|' /usr/share/mk/bsd.own.mk 

This downloads an old version of the ports tree which holds a version of Alpine that we’re going to use. It also bootstraps the package manager and makes a change so that it will work with the old tree. Now we need to prepare Alpine; unfortunately one required file is no longer available from the original site. I chose to mirror it since it took me some time to find the right one…

# mkdir -p /usr/ports/distfiles/alpine-2.20
# cd /usr/ports/distfiles/alpine-2.20
# fetch http://elderlinux.org/files/maildir.patch.gz
# cd /usr/ports/mail/alpine
# make makesum

Now we should be good to configure the port:

# make config-recursive

Be sure to check MAILDIR here as we’re going to need it later. Unfortunately this option is not built into Alpine would we install it as a package. So we have to resort to ports. While we’re at it, we can disable IPv6 (which we certainly don’t need), mouse support, NLS and check NOSPELL since we do not require spelling correction in this tutorial either. Configure pico-alpine accordingly. For all the other packages you can generally turn off NLS and DOCS. Then fetch the source for all packages recursively:

# make fetch-recursive

When it’s done change into OpenSMTPD’s port directory and configure it:

# cd /usr/ports/mail/opensmtpd
make config-recursive

Here you want to check the MAILERCONF option. The rest is fine. You don’t need to build the EXAMPLES for m4 and again can generally deselect NLS. Then fetch the sources:

# make fetch-recursive

Then configure dovecot2 (you can keep the default options this time) and fetch the distfiles for it:

# cd /usr/ports/mail/dovecot2
# make config fetch

Then follow the rest of the base box build process.

Preparation

You have your base box built and imported? Good. Create your Vagrant directories if you haven’t and a Vagrantfile in there:

% mkdir -p ~/vagrant/mail-vm
% cd ~/vagrant/mail-vm
% vi Vagrantfile

Put the following lines into it (assuming that your box has the name fbsd11.1-template):

Vagrant.configure("2") do |config|
config.vm.box = "fbsd11.1-template"
config.vm.network "private_network", ip: "192.168.0.10"
#config.ssh.username = "root"
config.vm.synced_folder ".", "/vagrant", disabled: true
end

Now fire up the VM, ssh into it and switch to root. Then edit rc.conf:

% vagrant up
% vagrant ssh
% sudo su -
# vi /etc/rc.conf

Change the line that defines the hostname to:

hostname="mail-vm.local"

Save the file and exit the editor. Let’s do a bad thing next: Let’s configure the VM so that we can SSH into it directly as root. If this just sent a shiver down your spine then you’re having the right feeling. You’re not supposed to do this like… ever! But now and then you feel like doing forbidden things, right? And now’s the perfect opportunity since this is just a private, non internet facing VM. Just remember to never do this on a production machine! Ok, ready? First we need to copy Vagrant’s public key and allow it for root:

# mkdir .ssh
# touch .ssh/authorized_keys
# chmod 0700 .ssh
# chmod 0600 .ssh/authorized_keys
# cp /home/vagrant/.ssh/authorized_keys /root/.ssh/authorized_keys

Now edit the SSH daemon’s config:

# vi /etc/ssh/sshd_config

Look for the line #PermitRootLogin no, remove the comment sign and change it to yes. Save and exit the editor. Then power down the VM:

# shutdown -p now

When you’re back at your host machine, edit the Vagrantfile:

% vi Vagrantfile

Add

config.ssh.username = "root"

to the configuration. Save and exit.

Test the change you just made by starting the VM and ssh’ing into it:

% vagrant up
% vagrant ssh

If everything is correct, you should have entered the VM as root now. Power down the VM again:

# shutdown -p now

Intermission

We’ve now prepared our test environment for trying out all things mail. Use vagrant to create a snapshot now to save your progress so that we can pick up right there next time. But before we do so, we need to make sure that the VM is already powered down:

% vagrant status

If it says running (virtualbox) then wait a moment and issue the same command again. It’s important that the status is poweroff (virtualbox). If you snapshot the VM while it’s powering down, your machine will always power down if you restore the previous state! As soon as it’s off, snapshot it:

% vagrant snapshot save mail1

You now have an idea of what the whole topic email is all about. And you have a test system to try out things and get familiar with mail from the very fundamentals to – perhaps – a fully working mail server. I hope that this was interesting for you and that you’ll follow the next part, too, where we’ll explore sending mail from the console and discuss using a text mode MUA.

[ ! -z ${COC} ] && exit 1

There has been some turmoil about FreeBSD’s new Code Of Conduct lately. While it was meant to maintain peace in the community, it actually lead to the opposite: Two fractions are more hostile towards each other than ever – and the new COC allows to simply get rid of unwanted (by one such group) persons.

Disclaimer: I’m just a FreeBSD user and advocate. I work with my OS of choice, write about it and encourage trying it out. However I’m not directly part of the project – and while that has been a mid-term goal for me for some time, that way is probably blocked for me now.

What’s a Code Of Conduct?

Basically a Code Of Conduct is a set of rules for people to follow. If you join any organization that has a COC, reading and understanding it is essential. It will tell you what you are expected to behave like and which behavior is objectionable.

The idea is to write up rules that make sense for the organization and that everybody can accept. It’s often simple things like: Respect your colleagues, shut the door when smoking outside, try to be helpful if somebody asks you for help, etc. In short: Behave decently.

Why all that fuss about it?

So – if that’s all, why write an article about it (let alone make all that noise about that topic)? Well… That’s not all, unfortunately. The main problem is not “a COC” – it’s FreeBSD’s COC. Scroll all the way down to the end of the COC and you’ll see the attribution. It reads: Geek Feminism Wiki. It’s no surprise that this is like a red rag to a bull to for some people: Feminism?! In tech??

People who overreact when reading the term alone should really calm down. Yes, stay cool. Why? Because it’s actually getting worse…

Feminism

Yeah, everybody knows what feminism means, so why talk about it? Because there’s feminism and there’s… well, “feminism”. While the former is a just cause (unless you’re a true women hater), the latter is a crude ideology. “Feminism” is not about women’s right to vote, to live their lives free from oppression or their right to be an esteemed part of society. It’s about destroying society in the name of a just cause.

“Third wave” feminists will happily taunt married women who chose a traditional family life to be “slaves”. While everybody else knows that it’s a token of appreciation to hold a door open for a woman or help her out of a coat, they will aggressively deny this and state that they can do it themselves. Compliment them and you’re toast. And worse still: Dare to use a word that they deem evil and they will assault you (at least verbally). Plus: They are so obsessed with “minorities” that actual concerns of women come second – at best.

I’ve known a girl who went to an elite school. She spoke Latin fluently (as well as Greek mostly) when she was only 14 (she once corrected me before I even finished a Latin sentence that I read from an old exercise book of mine…). She had a very strong spirit, too, and rejected the religious belief that was expected from her. However she had very humble goals for her own life. When they were asked in school what job they would like to do later, she stated: Housewife and mother. After a moment of shocked silence, she was laughed at. As she told me, that had been the most painful moment in her young life. It’s a shame when a woman cannot become an astronaut if that’s what she dreams of doing. But it’s plain wrong to force women to take up paid jobs if they would prefer to live a traditional life.

Feminism is freedom of choice for women and means that each woman gets to decide for herself. “Feminism” is coercion and doctrine and it means that ideologists decide what women in general have to do (and what not). Feminism is sound, honest and all about emancipation. Whereas “feminism” is cruel, phony and enslaving.

Balance

When thinking about freedom, it makes sense to distinguish between what is commonly called “positive” and “negative” freedom. This does not mean that negative freedom is something bad – both freedoms are valuable. To avoid misunderstandings I prefer to speak of active and passive freedom. Active freedom is the freedom to do something while passive freedom is the freedom from something (e.g. paying taxes).

Those freedoms are in a direct and fixed relation to each other: To increase one you have to decrease the other. Want to give people freedom from the fear to be shot in public? There’s no other means but to take away the freedom to carry firearms with them. Other way around: To give women the right to breast-feed babies in public means to take away the freedom of others to never see any bare breasts by accident.

You will always find people who are easily offended by just about anything. And on the other hand you’ll find die-hard folks who demand that they are allowed to do whatever they feel like. Both are rather extreme stances. It’s not terribly hard to see that some kind of balance is necessary between them.

Making an example often simplifies things. So here we go: I like to listen to music. Various forms of Black and Death Metal are my favorite. It’s also quite common that Metal bands use artwork that’s a bit… special. Some of the clothing that I own displays blood, gore and human innards. Nude women are also not so uncommon nor is blasphemic imagery. What I loathe on the other hand is so-called Hip-Hop music. Monotony is a weapon and whenever I’m forced to listen to something like this, my brain twists in agony as I can physically feel getting more and more dull.

What I’m considering beautiful music is terrible noise for most people. I can live with that. I don’t feel the need to complain loudly that somebody just “disrespected” me with such a statement. On the contrary: Taste is entirely subjective. It’s ok that you don’t like my music. I’m also not going to annoy you with it. And yes, the aforementioned kind of clothing is fine when I feel like going to a club or Metal bar. It’s probably not the right thing to wear when going to church. I won’t show it in public – there’s no need to confront people with something that they find is disgusting. At the same time I’d prefer if people would stop annoying me with loud “rap music” and the like in public. I don’t want to have to listen to that! However I’m not going to demand it. I think that people should care for not offending others. But if they think otherwise (or don’t think at all), I value freedom enough to not go all drama about it.

Tyranny vs. democracy

Let’s talk about minorities next. In ancient Greece democracy was not what we use the term for today. Still it makes sense to look at what terms like that come from and how they evolved. Polis is the Greek word for “city”. But don’t think of today’s modern cities – the poleis were effectively city states (you can still recognize “city” in citizen, even if that refers to a state). That Polis is where the word “politics” is derived from; “politics” basically means anything regarding the rules of the city (or state). Tyrannis was what the rule of a single potentate was originally called and democratica the rule of the demos, the citizens. Neither women, slaves nor metoikos (established strangers) were citizens and thus could not vote or otherwise participate in the state affairs.

The very idea of democracy was that by the means of vote, the majority gets to decide. The modern idea of democracy makes one fundamental difference: Even though they are outvoted, minorities can still be citizens after all and thus – to a certain degree – need protection from the majority. This is a very important concept and protecting the weak is commonly agreed to be a noble thing. Therefore this is not where democracy ends as some people may claim.

There is this point however, where the whole thing is getting completely out of control. This is when the noble idea of protecting minorities is turned into a weapon to terrorize the majority. Sounds absurd? Agreed. But just look around you carefully… There’s this idiot making stupid claims and trying to get you into trouble. However you cannot even call him an idiot – because he’s black/gay/jewish/handicapped. That’s right: Attribute xyz doesn’t have anything to do at all with the fact that he’s an idiot, but in today’s society, sometimes that’s all that counts. And that’s where the most important freedom – which is hard-fought and not a gift at all – disappears: Your freedom of speech is gone. You are no longer free to even say the truth just because… Yeah, just because what? Because otherwise your reputation will be destroyed.

That’s pretty bad, yes. But fortunately we’re one step ahead on the path to complete insanity. People are free to arbitrarily declare that they belong to minority xyz – and you better “respect” that! Also they are free to “feel” discriminated by your behavior – and this can put you into real trouble. Don’t want to lose your job? Bite your tongue! Don’t want your neighbors to scorn you? Keep your trap shut! Oh, and welcome to the dictatorship of “political correctness”.

Embracing the absurd

If you want to protect every thinkable minority (and by “protect” mean to ensure that nobody is allowed to act in a way that could hurt their feelings) this is simply an impossible situation. Just one bitter example: Most people would agree that denying the shoah might hurt a lot of jews. But what about the people who… No, stop, you cannot call them holocaust deniers! They prefer to be called “people with an alternative opinion on the so-called holocaust”. And they are certainly a minority.

What about white supremacists? They are a minority, too. Learn to respect their feelings, will you! Or fundamental christians who are absolutely certain that homosexuals burn in hell. This belief is not exactly one that the majority shares.

And when it comes to “feminism”, some people even believe that it is “fair” to penalize others on account of an asserted privileged position in the past. This is when all ideas of equality vanish and certain people demand that discriminating against men/whites/christians/… and preferring women/blacks/$RELIGIOUS_GROUP is a good thing. But let’s not get deeper into this.

FreeBSD

People shouldn’t hurt each other, that’s something (almost) everybody should be able to agree to. But it’s not a good idea at all to drive this to the point where it gets ridiculous. FreeBSD’s COC hits this point a couple of times, e.g. when

simulated physical contact (e.g., textual descriptions like “*hug*” or “*backrub*”) without consent

is declared “harassment”. This lead to the FreeHugsBSD fork because the original is now “hugs-free BSD”…

FreeBSD is not very often in the news and if it is, not too many people care about it. In this case however, the forums of the German tech community were full of posts (most of them making fun of us FreeBSD users – and mostly rightfully so). Others are sharing pictures like this.

My personal favorite however is the ban of “dead names”. Sorry people, but most of the time somebody wants to change his or her name, I’m not convinced. I don’t care if James comes back from Syria and wants to be called “Abu Khaled” or if Frank decides you should call him Charlotte. Don’t get me wrong, I wish them well. However I’m pretty sure that it would be best for both of them to go and see a psychiatrist.

Do we need a Code Of Conduct?

In short: No. We’re talking about tech here. If you cannot use UFS because it was created by McKusick – who married a man -, that’s your problem. If you use UFS because it was created by a gay person, I’d also not vouch for your mental health, but to each his own, eh?

Same thing for all those other minorities: It simply doesn’t play any role. Maybe you’re an atheist while I’m not. I’m pretty sure that we can get along just fine if we’re both passionate about BSD (and even if we meet in person and discuss religion, I’ve never had a problem with a polite person that doesn’t share my faith). If you have a disability, it might make sense to mention that on the net because it really affects how you use a computer. But why should you care that I’m a vegetarian? And why should I care if you were “born in the wrong body”? If you love a goat that’s of course a different thing in this case! 😉

But still: Why don’t we keep all this nonsense out of the community and learn to actually get along? Yes, there has often been a questionable tone e.g. in the mailing lists. There’s a lot of room for improvement. But does dictating strange rules really solve the problem?

So what now? Should you rage-quit FreeBSD? Stop donating? Yelling at core and cursing whoever proposed this? Certainly not. The best defence against all this madness – is keeping calm and taking it seriously. Stay with FreeBSD if you can and express your rejection of this disgrace. Freedom is never gone for good. It can return.

I’m out – for now

For me personally, joining FreeBSD is currently not an option. I’m a “live and let live” kind of person. Thus I can get along with people who I consider to be weirdos (and with those that consider me a weirdo – at least for my part in getting along!). Again: This is tech. There are a lots of rather special people around, often with their very own quirks. A lot of them are quite brilliant, too, and you wouldn’t want to miss them.

But never ever, under no circumstances am I going to pretend what certain people call “respect” (thus washing away the meaning of this grand word) for quirks that I can live with but definitely won’t approve of.

Oh, and I belong to various minorities, too, BTW. One is the minority of people who don’t speak English natively and whose tortured sense for grammar screams in pain when they encounter the abomination of a “singular they”. Won’t you have mercy with me? Please?

Blessed be the blind
For their conscience won’t collide
With the cruelty of sanity
And the prophetic signs
In the book of life
– Suidakra, Signs For The Fallen

“Permissive licensing is wrong?” – No it’s not! (2/2)

The previous post gave a short introduction into the topic of software licenses, focusing on the GPL vs. BSD discussion. This one is basically my response to some typical arguments I’ve seen from people who seem to loathe permissive licensing. I’ll write this in dialog style, hoping that this makes it a little lighter to read.

Users

GPL fan: “BSD license? Really? You shouldn’t be using that!”
BSD advocate: “Why not? I like it a lot.”
Fan: “It’s a dumb decision. Don’t you even care about free and open source software?”
Advocate: “Oh yes, I do!”
Fan: “Then why not just use the license everyone uses? In contrast to BSD, the GPL ensures that code remains free.”
Advocate: “No, not ‘everyone’ uses that license. You wouldn’t claim that e.g. the Apache foundation doesn’t do anything for open source now would you?”
Fan: “Most of the important projects do. Apache and some others don’t, I’ll give you that. They should adapt the GPL, though.”
Advocate: “Version 2 or 3?”
Fan: “GPLv3, of course. It was updated for a reason after all! The current version offers much better protection for your code.”
Advocate: “Well… I don’t feel any need for this kind of ‘protection’. But for now let’s assume that you convinced me. Changing the license would be quite a bit of work!”

Simplicity vs. Complexity

Fan: “How’s that? Re-licensing stuff to GPL is pretty straight-forward.”
Advocate: “Reading – and understanding! – the license alone takes quite some time… Which is one reason I prefer the much simpler BSD licenses, BTW.”
Fan: “Nonsense! The GPL has been constructed carefully and is advocated by the FSF. You can read it, of course, but you could basically trust their judgement.”
Advocate: “I strongly prefer to work with things that I do understand myself.”
Fan: “The aim of the GPL is not hard to understand at all.”
Advocate “It’s a complex monster. Sure, I understand what it’s all about. But in life in general – and even more so in law – the devil is in the details. Finding out what I am allowed to do and what not is not an easy task – and it got more complicated with every new version of the license.”
Fan “It’s only as complex as it has to. You admitted that law is complicated and details are important. Of course it had to become more comprehensive over time! That’s for our own good.”
Advocate “‘Of course’? I’d doubt that. The BSD license has seen updated versions as well – and it has been shortened with every new revision… Anyway, my focus is on the software. For that reason I prefer a license that doesn’t distract me for quite some time from what I actually want to do.”
Fan: “You said that you care about your code? Fine. Then you really should avoid BSD licenses!”
Advocate: “Uhm… What?”
Fan: “Linus Torvalds put it this way: ‘Over the years, I’ve become convinced that the BSD license is great for code you don’t care about’. And he’s right.”
Advocate: “No he isn’t. It completely depends on what you want to achieve!”

Success

Fan: “It’s common knowledge that the Linux kernel is so successful because of it being GPL’d so that every company using it had to give their changes back for the common good. Let’s see… How popular are your valued BSD-based operating systems today? Oh, nobody uses them anymore…”
Advocate: “Wow, Netflix, Whatsapp and others who exclusively use BSD are ‘nobody’? Not to mention other users and supporters of BSD operating systems like Yandex and VeriSign. The BSDs are less visible compared to Linux, that’s true. But by simply doing their job well and without all the community drama people are talking less about the BSDs is not a surprise at all!”
Fan: “Now you’re trying to make it look like Linux and the BSDs were on par! That’s completely wrong. Linux has a share of 100% on the TOP500 supercomputers since November 2017. Try to beat that!”
Advocate: “And with Android… yeah, I know what you’d point to next. True: Linux has reached a monopoly worse than…”
Fan: “Worse? What’s bad about open source software prevailing?”
Advocate: “Monopolies are not a good thing at all. I’m all for open source operating systems – mind the plural there.”
Fan: “Heh, you only say that because you’re betting on the wrong horse. Face it: Linux is the winner here and for a good reason!”
Advocate: “*mumbles* Yeah, and if only it had adopted the GPLv3 then it’d be at 200% share on supercomputers now…”
Fan: “Excuse me, could you repeat that just a little louder?”
Advocate: “I just doubt that it’s only a license thing that decides on success or failure. For the BSDs, historically it has been a state of legal uncertainty that was the big problem and allowed Linux to rise. And if your point was really valid – why do we need GPLv3 at all if v2 used by Linux to this day is all that’s required to conquer the world?”
Fan: “You’re just jealous! But sure, the GPL is just one key to the success of Linux. The BSD licenses are also one major factor in the demise of the BSD operating systems.”
Advocate: “There is no demise; there are at least four healthy BSD communities who continue to provide quality operating system releases. The claim that ‘BSD is dying’ has about as much truth to it as the prediction of the ‘year of the Linux desktop’! Of course you are free to prove otherwise.”

Freedom

Fan: “Freedom is a good point, too! Permissive licenses may grant the user some rights but only copyleft ensures that nobody can take your freedom away. Isn’t that kind of important?”
Advocate: “Yes, freedom is extremely important – which is why I choose permissive licenses over copyleft ones. But we certainly won’t find a definition of freedom that suits both of us.”
Fan: “So that’s something you don’t want to talk about? Then what are you hiding there? Your weak arguments?”
Advocate: “Not really. The problem here is: I know and understand your point of view. Why? Because I’ve been there when I was younger and promoted the GPL. But now that I have a broader understanding of the matter I have a different view on it.”
Fan: “Yeah, just treat me like a young boy. ‘You cannot understand that now, grow a little older and wiser and you’ll be enlightened like me!'”
Advocate: “I didn’t say that. All that I’ve said is that I know your position and that it’s nothing that can be proven wrong easily enough for us to make sense to discuss it without going in-depth on it. If you insist, we should set aside a couple of evenings for a philosophical debate.”
Fan: “Which philosophical debate? I’m still claiming that you’re trying to avoid the topic.”
Advocate: “Yes, I am – for today. It’s a topic for itself and leads too far off for us right now. But here’s the core of the problem: The point of view you have is that ‘enforcing freedom’ is a good thing. From my point of view it is absurd. Force and freedom contradict each other.”
Fan: “Not necessarily.”
Advocate: “So you claim that it’s possible to force somebody to be free?”
Fan: “Hm. Why not?”
Advocate: “Because force takes freedom away. But the problem is in the term ‘freedom’. We use it differently and mean other things. That’s why this specific debate would require a whole lot more time. So can we agree on a draw for that topic for now?”
Fan: “If it really takes so long to discuss, that may make sense. So back to the characters of the licenses, right? But don’t think that I’ll let you get away with such claims on another topic again!”

Better with Copyleft?

Advocate: “So?”
Fan: “Copyleft is also superior to permissive licenses.”
Advocate: “Didn’t we already cover the topic ‘success’? Or do you mean the fact that it’s overriding the terms of permissively licensed code when the two are combined?”
Fan: “I meant something else, but that’s true, too, of course!”
Advocate: “I don’t think that this is a good thing. It’s virulent in nature.”
Fan: “Oh hello, Mr. Ballmer!”
Advocate: “I didn’t say that it’s cancer, even though that’s probably a valid point of view on it.”
Fan: “Anyway, it’s superior because it guarantees that companies using the code contribute their changes back. It’s pure logic to assume that this makes the software better than a competitor where you don’t have to give back.”
Advocate: “Hm… What about the incompatibilities of copyleft licenses?”
Fan: “What do you mean? And how would that impact the quality of an OS or something?”
Advocate: “Well, take ZFS for example. It’s the world’s most advanced filesystem – and it’s licensed under a copyleft license. However that license is incompatible with the GPL and for that reason cannot easily be included into Linux distros! FreeBSD for example doesn’t have this problem. Due to the permissive license of the main operating system components, including ZFS was no problem from a legal point of view…”
Fan: “Ah, we can do without ZFS, we have BTRFS! And if you really want it, you can use DKMS to build it!”
Advocate: “DKMS is quite an inconvenience in this regard and I won’t even comment on that other FS… But that was just one example that copyleft licenses are sometimes not as cool as you’d like to make them look.”
Fan: “Nah, Sun should have open-sourced ZFS under the GPL or at least made their license compatible with it. Then we wouldn’t have that problem.”
Advocate: “The more complicated licenses get, the more edge cases arise that lead to problems. BTW, have you ever heard the comparison ‘GPL is a license. BSD is a gift’?”

Gift vs. license

Fan: “The large corporations will surely applaud your stance on this matter!”
Advocate: “Oh, let’s stay clear of this childish behavior and refrain from insulting each other with poisoned compliments, shall we? Otherwise I’d reply with something like ‘great attitude! Congratulations on it from the national lawyer’s association’. But that wouldn’t be helpful either, would it?”
Fan: “Lawyers are not nearly as bad as the big companies.”
Advocate: “Right. Some of them are supporting your cause. Others are doing the opposite by helping big business to find new loop holes. Both make quite a bit of money without ever improving the code.”
Fan: “Good lawyers are necessary to help protect software. That’s a win for open source.”
Advocate: “If you say so… I still prefer simple things. I like it being a gift.”
Fan: “Others will surely like that, too. It’s a gift to the large companies that only care for open source when they can make profit with it! For that reason making such a gift is stupid.”
Advocate “Not so fast. It’s a gift to everybody. That makes quite a difference!”
Fan: “No it doesn’t. Greedy corporations will end up taking your code.”
Advocate: “Maybe they’ll actually do. But are you really saying: ‘Don’t give a blanket for a refugee – a terrorist might warm himself with it’? Are good deeds wrong if a bad person might benefit from it?”

Exploitation?

Fan: “*Sigh* That’s not the point. When you use permissive licenses you are actively asking to be exploited.”
Advocate: “Sorry, that’s simply wrong. Software has the advantage of not disappearing when you give it away. I can give it to multiple people and don’t lose anything. When it comes to free software, the only thing that can be exploited are bugs.”
Fan: “Ha ha, very funny – not. You know exactly what I mean: You are asking to be exploited because you invested time into a project and somebody else simply takes it and generates revenue from it while you get nothing.”
Advocate: “I have a very different view on that. I open-sourced my code in the hope that it would be useful to people. If I had intended to make money with it, I would have chosen to commercialize it.”
Fan: “But they did commercialize it! And they make money from your work!”
Advocate: “Relax! Yes, that’s entirely possible. However I didn’t expect to make money with it in the first place, anyway.”
Fan: “But if your code is useful, somebody else surely will!”
Advocate: “And is allowed to do so, if he or she finds somebody who’s willing to pay for something that’s freely available. I’m still not losing anything, right? Besides: Anybody else could also try to sell it. It’s the same rules for everybody. I’d say that’s fair.”

Ethical issues

Fan: “That’s really egoistic thinking. Supporting unfree software is entirely unethical!”
Advocate: “You didn’t really say that, did you? I’m giving something away. For free, no strings attached and without trying to achieve any real benefit for myself. And you are accusing me of acting unethical?”
Fan: “Actually yes. By not making sure that your ‘gift’ remains free, you’re supporting unfree software.”
Advocate: “Wrong. It does remain free! Nobody is losing anything.”
Fan: “You know as well as I do that the BSD license allows closing your code and using it in closed-source software!”
Advocate: “Errr… Sure. But while you are trying to make it sound like that would mean a loss for open source this is not the case. The original code doesn’t disappear! It remains available under the BSD license and continues to be of use to anybody who wants to use it.”
Fan: “Bah, what a short-sighted argument! Yeah, your original code may still be available, but they will make modifications to their copy. And that’s when you’re cut off from good things that resulted from your code!”
Advocate: “I can live with that.”
Fan: “That’s ridiculous. Come on, don’t be an idiot! They are making others pay for something that was free software and now isn’t anymore. And you said that you care for free software?!”
Advocate: “You obviously can’t understand it. Why don’t you ask for my reasons instead of calling me an idiot?”
Fan: “Because there cannot be a legit reason for supporting unfree software!”
Advocate: “Excuse me but that’s a little bit arrogant, don’t you think? Let me give you an example. Think about Microsoft…”

Closed source

Fan: “Ha! You’re not going to defend M$, are you? You advocates of ‘permissive licensing’ are all the same! Why didn’t you start our conversation stating that you love Microsoft? That would have saved me quite some time!”
Advocate: “Please let me finish my sentences, will you? I certainly don’t love Microsoft. In fact I haven’t installed any Microsoft OS or program at home in about 10 years. I’ve been there when they used their market power with Windows 3.x to destroy DR-DOS. I haven’t forgotten the Halloween papers, either.”
Fan: “So? Windows is a terrible OS.”
Advocate: “Yes, for the versions that I know and have used in the past, that’s certainly true. What I wanted to say however is this: The web is a pretty bad place today and even though a lot was done over the last years, much of the software today is still a nightmare when it comes to security. Agree?”
Fan: “Sure!”
Advocate: “Fine. Especially Windows has been notorious for very bad security flaws in the past and all those hacked Windows machines are ruining the net for us all. Now imagine Microsoft couldn’t have taken the well-tested TCP/IP stack from BSD Unix because it had a different license. They would have been forced to write their own – would you really want to claim that would have made the world a better place?”
Fan: “Probably not… But nobody should use Windows in the first place then that problem would be hypothetical.”
Advocate: “In an ideal world we wouldn’t have any of those issues, right?”
Fan: “Correct. In that case we wouldn’t even need the GPL because everybody would be acting ethically anyway. But we aren’t living in such a world and for that very reason need GPL to support the FLOSS movement. You’re quite good at making esoteric objections against the GPL to make your lax license look better, BTW.”

Lax vs. pessimistic

Advocate: “Esoteric? I’d claim that the one case that I mentioned alone had quite some impact on the future of the net. But if you insist on calling my preferred family of licenses ‘lax’, I’m going to call yours ‘pessimistic’.”
Fan: “Why that? There’s nothing pessimistic about the GPL!”
Advocate: “Yes, there is. The whole idea is. Didn’t you say yourself that the GPL wouldn’t be needed in a better world?”
Fan: “In an ideal world! That’s different. But that doesn’t make it pessimistic.”
Advocate: “It does. You’re considering man to be bad – or at least sufficiently bad that instruments as the GPL are necessary.”
Fan: “They are necessary! That’s a fact. Just look around you with your eyes open!”
Advocate: “I disagree. And in fact I’m even going to top it: The GPL is not only unnecessary, it’s actively harmful.”
Fan: “Now you’ve completely lost your mind…”
Advocate: “Have I? Let me make another example. I’ve grown up using closed-source software. When I discovered open source, I was very happy that such a thing existed and completely made the switch.”
Fan: “And now you’re seeking to ruin it all…”
Advocate: “Not really. I’m actually happy enough with it that I developed a feeling of great gratitude and that created a desire within me to give something back.”
Fan: “That sounds great and all but I have no idea why the heck you are acting against open source.”
Advocate: “The point here is: I give back now because I want to. With the GPL I’d have to. The freedom of choice makes the difference here.”
Fan: “How nice for you! But a lot of people wouldn’t give back on their own and that’s why they need to be forced to!”
Advocate: “And by doing so you’re actively making it impossible for people to really grow ethically and make the morally superior choice themselves! You know, I hate that ‘four freedoms’ nonsense! It’s just a disguise for dictating rules that seem to make sense but in fact deny your freedom! All that ‘respects your freedoms’ is utterly cynical if any person’s most basic freedom – our free will – is denied!”

Capitalism

Fan: “Wow, impressive rant!”
Advocate: “That’s all you reply to the points that I make?”
Fan: “You’re a dreamer. All that ‘ethical growth’ and ‘personal development’ stuff is utopistic. Big money rules the world.”
Advocate: “It sure does, but in the form that we’re seeing today that will come to an end.”
Fan: “I doubt it, but if it does, that will be a victory we can only achieve with the GPL. It’s a powerful weapon we can use to defeat the big corporations.”
Advocate: “To found a world that people live in who never learned to make ethical decisions in the first place because it was already decided for them. Not a world I’d like to live in either.”
Fan: “Not a surprise that you’re defending capitalism and corporate power!”
Advocate: “I’m not a capitalist but I’m convinced that there’s a better way out of it.”
Fan: “By letting it all continue as it goes today?!”
Advocate: “As strange as that sounds – yes. And here’s why: Take companies like Juniper for example. They took FreeBSD as the base for their OS because… Well, it was free and allowed them to close the source and keep it for themselves.”
Fan: “And you like that…”
Advocate: “Yes, I do! You won’t believe it, but they hurt themselves by doing so: More and more new versions of FreeBSD were released and they were stuck with their old system which required a lot of maintenance and updating it got harder and harder since the system diverged a lot over the time. If they had given back as much as they could, they would even have saved a lot of money… Today there are already companies who understood this and even from purely capitalistic motivations started to embrace permissive open source: They give back as much as they can because it benefits everyone (including them).”
Fan: “That cannot be many. Otherwise BSD would be far more popular.”
Advocate: “It takes time for companies to learn. Give them the chance to hurt themselves and to eventually come to a good conclusion on how to act.”

Final victory

Fan: “Even if that was true, in your world open source would never succeed. You’d always feed your code to the companies who will improve it a bit and start selling a product that’s superior. We can never catch up with them this way!”
Advocate: “I’m going to claim the opposite: We’re catching up quickly and there’s no way that we’re not going to win.”
Fan: “How’s that? They will always be a step ahead! Code needs to be constantly improved and they have an advantage there.”
Advocate: “That’s today’s story, yes. But we’re rapidly approaching the point where open source software is no longer a somewhat limited ‘alternative’ to commercial software but simply good enough for just about any task.”
Fan: “And then?”
Advocate: “That’s the moment we’ve ‘won’.”
Fan: “Strange definition of winning… The companies will still sell improved products!”
Advocate: “Well, just let them if they find someone who really needs those additional features and is willing to pay for them.”
Fan: “What do you mean? Of course people want the best software possible and will pay for it! We live in a capitalist society. Your strange ideas won’t change anything.”
Advocate: “My ideas? Certainly not. But the very rules of capitalism itself will eventually defeat it. If you don’t believe me, just tell me: How to beat good enough and free from a capitalist point of view?”
Fan: “Oh my. You really are a weirdo. Keep your faith in mankind being able to change its ways. I don’t have it and will stick with copyleft!”

(Sorry for the delay in publishing this, but last month has been really, really chaotic for me. Two of my grandparents passed away just a few days apart, I had a deer accident (I’m fine but the deer and my car not so much) and I’m in the middle of moving houses… So if you comment on this and I don’t immediately respond, please bear with me!)

Spam blacklisting: Its dark side

(GPL vs. BSD II will be posted in January)

No, I don’t want to see pictures of your sexy body, “Tanya”. Not interested in transferring a huge amount of money for you from some Arabian country, “Khaled”, sorry. To “Mr. lawyer Smith”: I understand that you’re pressed for time to find somebody who can claim the wealth, but I’m not a remote relative of the late “Mr. Anderson”. Oh, while we’re at it: I don’t buy blue pills, pal. And no Rolex watches at cheap prices on special offer for me, either…

SpamSpamSpam

Everybody who is using email today is familiar with the phenomenon of unsolicited mails commonly called “spam” today. That it originally meant a meat product and how the term evolved is a story on its own – a story that few people care for when they want to read their mails and are frustrated to find their inbox flooded with useless gibberish.

The rise of spam has been a major factor in ending the days of the once so innocent Internet. You want to run an email server at home? Forget it – or get a static IP from your ISP. No sane person configures any mail server or mail relay server to accept mail from an IP known to belong to the dynamic range of any ISP. Why? Because that would be spammer’s heaven. And we certainly don’t want that to happen. Matters are just bad enough the way they are.

Fighting spam

Spam messages are a major annoyance. They can in fact be vexing enough to motivate people to search for means to end the onslaught of hostile messages (or at least limit it somewhat). Smart people have invented and implemented spam filtering. The filter e.g. checks all incoming emails for certain keywords and calculates the likelihood of it being spam. This is not a solution for the problem, of course. It’s more of an ongoing fight: Programmers improve and tune their filters, spammers think of new methods to trick those filters into believing that a spam message is not spam.

Another method is to use blacklists with IPs of known spammers. This is actually a pretty powerful and effective method to counter spam. In fact it is a major step in putting a stop to the spammer’s game! Just about everybody who sets up a mail server today will check against one or several spam blacklists and reject any mail that comes in from a suspicious IP. Great! Well, not so much actually…

Highwaymen

Think about starting your own blacklist business for a moment. You build your infrastructure and happily start providing a list of evil IPs. Once a lot of companies and institutions start using your list, you have tremendous power at your hands! Put some IP on there (for whatever reason) and someone will de-facto be unable to mail to a lot of people. You could press money from that person. And that’s what some of them try to do. Take a look at “UCE protect” for example. They charge about 100 EUR (!!) for immediately removing a single IP from their blacklist and even threat to pillory people who “dare” to try to take legal action against those thugs. No, that site is not a joke unfortunately and they obviously run a profitable business by robbing people…

Sure, these are the black sheep. A lot of the spam blacklist providers out there are reputable and reliable organizations. If you ever need to mail someone who uses blacklists like the one from “UCE protect” (e.g. the city of Munich), resort to paper and snail-mail. They probably prefer email because it’s easier to work with. Be sure to tell them that you would have simply sent an email but you won’t since they work together with more-than-dubious blacklist providers.

I never had anything to do with said blacklist service so far, but they are target to a lot of jokes among IT people in my country. During my vocational training I was asked to take a look at their website and have a good laugh. And it was certainly shocking enough to stick in my memory to this day.

Overacting

But let’s get to the reputable services – and the actual problem. A while ago the company that I work for ran into trouble with a big blacklist provider (that we’ve been using ourselves ironically). While their goal of reducing spam is just and noble, they are unfortunately crossing the line and abusing their power. What has happened?

There’s this customer of ours who hosts a humble web shop with us. Nothing fancy. Probably even on the contrary. Now the big blacklist provider chose to block the IP for that shop. No problem so far. We notified our customer – and nothing happened for a while. Then the blacklist provider blocked all IPs of that server. Annoying but not tragic. Why? Because the server doesn’t even do mails! Again we tried to get in contact with our customer and over the back-and-forth time passed by.

But then the unthinkable happened: The blacklist provider threatened to block the entire /24 subnet (and would without doubt increase the blocked range beyond that, eventually swallowing all of our IP addresses)! Sounds like our problem, right? We should have reacted earlier and kicked the spammer off. Unfortunately… There was no spamming involved in this case! The shop that is hosted on our servers is mentioned in spam mails that originate from around the world, but not from our network. Still the blacklist provider is effectively blackmailing us and holding all of our customers hostage – their businesses depend on being able to send mail and if our whole network was blocked that would in fact mean threatening the existence of several companies!

What to do?

That’s the point where I feel that the “good guys” with all their commendable intentions have turned into criminals themselves. And in fact much worse criminals than the average spammer. While the latter is “only” a nuisance, the spamlist provider has become a real threat to business.

At first glance it’s clear what to do: Throw that customer out and eat humble pie, begging the spamlist provider for forgiveness. Even that isn’t so easy, however. While the spamlist provider may operate from a country where such cowboy means are acceptable, we aren’t. You cannot just throw out a customer. We are bound by a valid service agreement and since he insists on being innocent, we cannot just terminate the contract at will since we have no proof of illegal actions. If we did terminate the contract, we’d be in legal trouble and the former customer would definitely win the court case (which would mean the loss of a lot of money for us). If we didn’t, we would put the whole company at risk.

But that’s only the business part of it. Honestly: What if the customer is right and in fact is innocent? It could very well be a competitor trying to ruin his business (and obviously successfully so). And what annoys me the most: This only happens because our customer is a small fish. What would happen if somebody started a spam campaign promoting whitehouse.gov? The same thing? You decide for yourself.

No solution?

I would imagine that this is a problem that others have been facing, too. While I wasn’t directly involved in this case (and I’m certainly happy that I’m just a simple admin who doesn’t have to make any such decisions) the whole incident totally violated my sense of justice. I wrote most of this post a few months ago and decided to wait some time to calm down before publishing it. However that hasn’t happened. I’m still upset when thinking about it.

What could be done about things like this? I don’t know. Probably the only way would be setting up a site like “blacklist watchers” where people can share that they have been held at gunpoint by some service provider. Then people who use blacklists could decide if a service is operating decently or resorting to wild-west means (“I’ll keep thrashing your grandma till you give in!”). That could be abused, too, though. But what other means of self-defence are possible? Comments are of course very welcome.

The actual problem is hard to solve: There’s too much power in the wrong hands. And even more gross: The blacklist people actually want to achieve something good. There’s a German saying that fits very well in this case. It roughly translates to “The opposite of well done is not done badly. It’s well-intentioned“.

“Permissive licensing is wrong!” – Is it? (1/2)

A few weeks ago I’ve been attacked by some GNU zealots on a German tech site after speaking in favor of permissive licenses. Unfortunately a discussion was not possible there because that would require the will to actually communicate instead of simply accusing the other side of vile motives. Since I actually do care about this topic and a reader asked for a post about it in comments a while ago, here we go.

This first part tries to sum up the most important things around the topic. I deliberately aim for an objective overview that tries not to be one-sided. The second part will then contain my points in defence of permissive licensing.

Why license software at all?

Licenses exist for reasons of protection. If you’re the author/inventor of some software, a story or whatever product, you get to decide what to do with it. You can keep it for yourself or you can give it away. If you decide for the latter, you have to decide who may use it and in which way(s). In case you intend to give it to a (potentially) large group of people, you may not want to be asked for permission to xyz by everybody. That’s when you decide to write a license which states what you are allowing and explicitly disallowing.

Most of the well-known commercial licenses focus on what you’re not allowed to do (usually things like copying, disassembling, etc.). Open source licenses on the other hand are meant to grant the user rights (e.g. the right to distribute) while reserving some rights or only giving permission under certain conditions – and they usually make you claim responsibility for using the software. For these reasons licenses can actually be a good thing!

If you got an unlicensed piece of code, you’re not legally allowed to do anything with it without getting the author’s permission first. And even if you got that permission, your project would be risky, since the author can withdraw it later. A proper license protects both parties. The author doesn’t get his mail account full of email asking for permission, he’s save from legal trouble if his code breaks anything for you and at the same time you have legal certainty when you decide to put the code to long-term use.

Permissive vs. Copyleft (in a nutshell)

In short terms, permissive licensing usually goes like this: “Here you are, have fun. Oh, and don’t sue me if it does something else than what you expect!” Yes, it’s that easy and there’s little to dispute over.

Copyleft on the other side sounds like this (if you ask somebody in favor of Copyleft): “Sure, you can use it, it’s free. Just keep it free, ok?”. Also quite simple. And not too bad, eh? Other people however read the same thing like this: “Yes, you’re free to use it. Just read these ten pages of legalese and be dead certain that you comply. If you got something wrong, we will absolutely make you regret it.”

The GNU Public license (GPL)

The most popular copyleft license in use is the GPL (in various versions). It got more and more complex with each version – and to be fair, it had to, because it was necessary to react to new threats and loop holes that were found later. The GNU project states that they are committed to protect what they call the four freedoms of free software:

• the freedom to use the software for any purpose
• the freedom to change the software to suit your needs
• the freedom to share the software with your friends and neighbors
• the freedom to share the changes you make

These are freedoms that every supporter of open source software should be able to agree with. So what’s the deal with all the hostility and fighting between the two camps? Let’s take a look at a permissive license, too.

The BSD license

Unlike the GPL, the BSD family of licenses begun with a rather simple license that span four rules (“original BSD license”). It was later revised and reduced to three (“modified BSD license”). And the modern BSD license that e.g. FreeBSD uses is even just two (“simplified BSD license”).

Did you read the GPLv3 that I linked to above? If you are using GPL’d code you really should. In case you don’t feel like reading all of it, at least take a look and grasp how long that text is. Now compare it to the complete modern BSD license.

What’s the problem?

There are essentially two problems that cause all the trouble. The first one is the question of what should be subject to the freedom that we’re talking about. And closely related, the second one is where that freedom needs to end.

Ironically both camps claim that freedom is the one important thing and it must not be restricted. The GPL is meant to protect the freedom of the software and enforces the availability of the source code, hence limiting the freedom of actual persons. BSD on the other hand is meant to protect the freedom of human beings who should be able to use the software as they see fit – even if that means closing down former open source code!

The GNU camp taunts permissive licenses as being “lax” for not providing the protection that they want. The other camp points out that the GPL is a complex monster and that it is virulent in nature: Since it’s very strict in a lot of areas, it’s incompatible with many other licenses. This makes it complicated to mix GPL and non-GPL code and in the cases where it’s legally possible, the GPL’s terms will take precedence and necessarily be in effect for the whole combined work.

Who’s right?

That totally depends on what you want to achieve. There are pros and cons to both – and in fact we’re only looking at the big picture here. There’s also e.g. the Apache license which is often deemed as kind of middle ground. Then you may want to consider the difference between weak (e.g. LGPL) as well as strong copyleft (GPL). Licensing is a potentially huge topic. But let’s keep it simple here because the exact details are actually not necessary to understand the essence of our topic.

In the next post I’ll present my stance on why permissive licensing is a good thing and copyleft is more problematic than many people may think.