Exploring FreeBSD (3/3) – a tutorial from the Linux user’s perspective

This is the third and last post of a series of introducing FreeBSD to Linux users. You might want to take a look at the first post (talking about some things different from Linux) and the second one (about binary updating and package, user and service management) if you have not done so already.

If you’re all new to FreeBSD (or the BSDs in general) I tried to sum up the most important things to know about this OS family in another post. And if you want to know how to install FreeBSD (and what disklabels are as well as some other *BSD specific stuff), there’s yet another post dealing with it.

So what are we up to this time? There are a few topics left that I want to write about (and quite some more that I would like to touch on, too – but it doesn’t make sense to try and put too much into too little space): Updating binary packages, the ports system and updating “world” (the OS itself) from source.

Updating packages

In the last post we installed bash via FreeBSD’s port system (pkg). About one month has passed since then and a new version of bash has been released in the mean time (just as I hoped it would!). So let’s see how to update packages, right?

The most common case is that you want to update all your packages. There are two commands you should know in this regard:

# pkg update

This updates the repository catalogue so that the system knows which package versions are available in the remote repo. You don’t normally have to run this explicitly since FreeBSD will automatically fetch the latest catalogue if it thinks that the local one is too old.

# pkg upgrade

This will tell you which packages can be updated and perform the actual update if you choose to do it.

Updating binary packages

In this case, a new version of the package management tool was also released. Pkg must be updated before any other updates can happen but other than that it works just like any other update does.

The ports system

What are “ports”? The process of making a software (for which the source code is available) build on a system that it was not necessarily meant for is called porting. Depending on the piece of software this can be easy (the program builds out of the box) or extremely challenging (a lot of code needs to be patched to make it work). In order to make things easier for everybody, FreeBSD developed the ports system which is basically a directory for each application that was ported and a Makefile as well as some support files in it. These contain everything needed to build the respective application on FreeBSD simply by issuing make inside that dir. The directories make up what is known as the ports tree.

Fetching a port snapshot

The ports system originated in early FreeBSD and quickly spread to the other BSDs as well. And even on Linux there are people who like concept: Gentoo Linux for example is based on portage which builds on the very same concept (but works rather differently in the end). Well, since I told you to deselect the ports tree during the installation you do not have it on your system. So let’s first get it in place!

Getting the ports

All newer versions of FreeBSD offer the portsnap command which makes that very easy:

# portsnap fetch

If you do not have the ports tree on your system this downloads a snapshot, verifies it and also fetches any patches for ports changed after the snapshot was created. You can use the same command to fetch the newest patches if you already have a ports tree and receive any changes made in the meantime.

# portsnap extract

With this command you tell the system to actually unpack the snapshot and populate the ports tree. Only use this the first time you install the ports tree to your system. It doesn’t make sense to use it afterwards!

# portsnap update

You do not need this if you have just installed the ports tree for the first time. It is used to update the local ports tree after downloading any patches with fetch. If you wish you can also combine the two parameters to update the ports tree (portsnap fetch update).

Extracting the ports tree

You could also get the ports tree via Subversion. But portsnap is just so convenient to use that there’s barely any reason to do so.

Finding your way around the ports tree

So now let’s take a look at it! Where are all the files? They are in subdirectories of /usr/ports. We’ve installed bash in the last post using binary packages. Where would we find it in case we wanted to build it from ports? Being a shell, /usr/ports/shells/bash is quite a logical place, don’t you think? And where would you look for, say, the ruby interpreter? You’ll find multiple versions of it in /usr/ports/lang/ruby2x (ruby 2.0, 2.1, 2.2).

If you work with the ports tree for a while you’ll get at least an idea where things belong to. But what is the best way to locate a specific port? You can use the whereis command followed by the program name and it will tell you where the port lives! Just make sure you type in the right name. You won’t find php for example. But you will find the port if you look for php55 or php56 instead.

Finding applications in the ports tree

Still having trouble? Perhaps the page FreshPorts can help you. You can search there and chances are good that you find what you are looking for and can find out the category and port name that way.

Building from ports

The first question is of course: Why should you build programs from ports? The ports system was invented to automate the build process when there were no binary packages available and you had to build every program from source. Today you can easily work with FreeBSD without ever touching ports.

But when does it make sense to use ports? The simple answer: If you have special needs! The binary packages are pre-build and there’s no way to change any compile-time options. If you’ve ever manually build a program on e.g. Linux, there’s a good chance that you have met configure which takes options like –prefix=/usr –without-package-xz –enable-newest-feature and so on. If you need some program feature that the pre-packaged program does not come with on FreeBSD, you can use ports. Or if you do not want a certain feature built-in which is selected by default, you can also use ports.

Selecting build options for a port

For packages that can be built with different options which the author of the port thought were interesting, you will be given a nice dialog window in which you can select or deselect certain options. Just navigate into the directory of the ports tree where the files for the application you want to build live and issue make.

This will bring up the configuration window if there are any options to set. Please note that your selection will be saved so you are not asked the next time you build the port. If you changed your mind and want to reconfigure the options, you can use make config.

Building links from ports

If you order the port to “make”, the source code will be downloaded from a known location (you do not have to do this yourself), decompressed, probably applied some patches and then built. Once the build is complete, you can use make install to install the program and make clean to clear the build directory of files remaining from the built.

It is also possible to combine several commands which the program make takes (these are called targets and are defined in a file called Makefile). So you can build, install and clean up one port by issuing make install clean.

You also don’t have to worry about dependencies. If a port needs other programs (or libraries) which are not present on the system, they will automatically be built from ports, too. And one more important thing: Don’t hesitate to mix binary packages and ports on your system. You don’t have to choose one and stick with that all the time. In fact the ports produce custom binary packages which are then installed using the normal package system. That’s why pkg is aware of any program that you installed via ports and can for example remove it from the system if you tell it to. You could also go to the port’s directory and use make deinstall.

Recursive operations

If you want to build a complex program that has lots and lots of dependencies (like e.g. Libre Office), it is a good idea to let FreeBSD build it overnight. There is, however, a big problem that you’ll face if you try out large unattended builds: Every now and then, when a new port is built as a dependency, FreeBSD displays the configuration window and pauses until you make your choice…

This is why there are recursive targets: You can use make config-recursive and the ports system will go through all the dependencies and display the configuration. So you can select all the options that you need at once before you use just make to build all those programs.

Recursive source fetching

Mind one thing, though: If you enable more options, you may want to run config-recursive again. Why? Because the options that you selected may have pulled in new dependencies which are not yet configured. Running config-recursive will only display the configuration dialog for ports that were not configured previously. If you need to re-configure all ports, you can use the make rmconfig-recursive target to delete the stored configuration for the port and all dependencies and configure them again afterwards.

And in case you want to pre-load all source tarballs before starting an unattended build, there are the make fetch and make fetch-recursive targets. In very rare cases it can happen that all the sources that one port knows for its tarballs are no longer available (this is more likely to happen if you’re using a no longer supported version of FreeBSD and/or an out-of-date ports tree). You can fix this if you simply find another source of the needed file on the net and download it to the /usr/ports/distfiles/ directory where all those source tarballs for the ports live.

Updating the system from source

Just like with ports the first question ought to be: Why should you? And in this case the answer is even more: You probably shouldn’t. There are people who like to build from source and that’s ok. But if binary updates work for you, in general you should stick to them.

When do you need to compile the system from source? Well, obviously this is the method of choice if you are a developer who needs to build the absolutely newest code. But if that’s the case you’re probably not reading this tutorial anyways, right?

So – why should you do it? There are basically three main cases:

  • To have it done once
  • Because you want to aim for the stable branch
  • You want to customize e.g. your kernel configuration

Do not laugh at the first one. It is a perfectly valid reason. While building FreeBSD from source is extremely easy, it is good to have done it at least once. It will help you to get a little bit closer to your system.

FreeBSD comes in several branches. You can decide to follow another branch and compile the code for it. We’ll talk about that in a minute.

And last but not least if you have special requirements and want to customize your system for that. E.g. you man decide to compile your firewall of choice (FreeBSD offers three of them) into the kernel. In that case you have to build from source.

Getting the source

We cannot discuss scenario three (customizing FreeBSD) here. That would require its own post (or even more). Besides – I’m not too knowledgeable in that field.

Installing the certificate bundle

Let’s assume we want to follow the stable branch. First we need the appropriate source code. FreeBSD uses Subversion for version control and a slimmed version of it comes with the system (“svnlite”).

You may want to install the certificate bundle first so using a secure connection does not result in an error because the certificate is unknown. To do that you can simply use the following command: # pkg install ca_root_nss.

Next we need to checkout the current version of stable code with svn. FreeBSD source code always goes into /usr/src.

Checking out system source with svn

Start the checkout process with

svnlite checkout https://svn.freebsd.org/base/stable/10 /usr/src

and wait for Subversion to finish. This can take quite a while because the source code is quite large.

Once it’s done, you’re set. Go to /usr/src and issue make buildworld. This will build the userland part of FreeBSD (and – depending on your CPU – take a long time to finish).

System source checkout completed

What gets build goes into /usr/obj, btw. So the source code is kept separate from it and anything in /usr/obj can be easily removed anytime before doing a clean new build.

Building the FreeBSD userland from source

When the world build has completed, it’s time to build the kernel as well: make buildkernel – this does not take such a long time to complete.

Now both parts of the system need to be installed with make installkernel and make installworld. Always remember the correct order:

  1. Build world
  2. Build kernel
  3. Install kernel
  4. Install world

The reason is that “buildworld” needs to run first, is that it uses the system compiler to bootstrap the new compiler which is then used to build the whole userland and, after that, the kernel. And the reason that the kernel should be installed first is that after updating the userland you really should reboot. You’ll probably get away without rebooting if you just updated within the same release version but updating to a new release from source will mean that you cannot count on the system to just keep running like before due to incompatible changes made. In theory you are even encouraged to boot into single user mode to do the update! But I have not found that this is really required. Just mind the right order and stick to it.

Building the FreeBSD kernel from source

After rebooting you should find that the system is running on the new kernel. Now we’re on FreeBSD stable. However… That does not at all mean what you’re probably thinking it does!

New kernel is running

FreeBSD branches

I’ve stated before that there are multiple branches of FreeBSD, one of which is stable. Let’s take a look at what they are.

First there’s release. If you followed this tutorial along, version 10.1.0 was the system that we started with. Uname denotes the kernel as 10.1-RELEASE. Release is just that: A certain release. It will stay as-is forever, no changes applied to it.

Then there’s the patch branch or “releng“. This is “release + patches” and in fact the most stable branch available due to error corrections and security fixes. Uname will report something as kernel 10.1-RELEASE-p12. The patch branch is meant for conservative production systems.

We’ve already touched stable and even updated to it. If the patch branch is the most stable version, why is this one called “stable”? Yes, it is a bit confusing, I know. The reason is that this branch receives new features (which the patch branch does not) but the APIs are kept stable. Hence the name. This branch is not officially recommended for production use but the company that I work for has used servers with stable for years and they behaved absolutely fine.

Finally there’s current (called “head” in the repository). This is where the development takes place. If you’re not a developer or somebody who wants to test the newest features as early as possible, this is not for you.

What’s left

I would very much have liked to cover file flags & secure levels as well as jails. I’d liked to have written about tools like portmaster and system components like the three firewalls. But that might or might not happen in a future post…

What’s next?

In exactly one month I’m going to write my final exams to become a qualified IT specialist. So I’ll have to see what topic (if any) I manage to write about next month. Since I’ve always wanted to write the followup to my post about licenses, this may be a good candidate.

Exploring FreeBSD (2/3) – a tutorial from the Linux user’s perspective

This is the second post of the “Exploring FreeBSD” tutorial. If you didn’t do so already, may want to read the first part before this one. And if you are completely unfamiliar with FreeBSD, the posts installing FreeBSD and the general introduction of the OS may also be of interest for you.

In the first part we have configured SSH insecurely to allow root login, set up port forwarding in VirtualBox and briefly explored commands and the default shell on FreeBSD. Now it’s time to continue our journey!

Since some screenshots show a lot of lines I sometimes cut out the relevant part to save a bit of space.

Updating the system

FreeBSD is an operating system well-known for its reliability. But of course just like any other complex systems, it is not perfect – there are bugs and security holes. These are addressed rather quickly since FreeBSD takes those issues seriously. To always have the currently most secure and stable system you need to perform updates. As updating is important, let’s get right to it!

FreeBSD binary update

In FreeBSD there are several branches, but we will ignore this for now and save it for the last part of this series. There are also two supported methods of updating the operating system: Using binary updates and building from source. We’ll just cover the former here and also take a look at the later in the next post.

Updating your system within the current release basically boils down to issuing two commands (well, actually one command and two parameters): freebsd-update fetch and freebsd-update install.

Summary of files to update

Once the fetching is complete, freebsd-update will display a list of changes that will be applied to the system. There you can take a look at which files will be replaced with newer ones. If you agree with the changes, you can install the actual update and – if the kernel was affected as well – reboot.

Installing the update and rebooting

Updating the operating system is actually as easy as that. Keep in mind however, that with the BSDs operating system (“world”) and installed software (“packages”) are things separate from each other! We’ll cover updating packages in the next post.

Release upgrade from 10.1 to 10.2

But what if you want to update to a new release? We’re lucky here: Since this series of articles started with installing FreeBSD 10.1, a new release has happened: 10.2! So let’s update to the new release version, shall we?

Again the freebsd-update command is our friend. It can also do a binary upgrade from one release to another. It’s freebsd-update upgrade this time and with the -r 10.2 option we choose to upgrade to that particular release version.

The release upgrade needs a lot of patches and files!

This process takes a whole lot longer because there are of course far more files affected. But it is essentially the same process: Fetching patches, fetching new files and displaying three lists: files that will be removed, added and modified if the upgrade is installed.

After the upgrade: Rebooting again

After installing the upgrade, just reboot the system. A moment later you should be greeted by your new 10.2 FreeBSD system!

The updated 10.2 system

Adding users

User management is surprisingly easy on FreeBSD. There’s the powerful pw command that can do just about anything user related. And for adding users there’s also the convenient adduser script that makes adding users to the system a breeze.

Adding a new user

Most things are completely self-explanatory. What may however be new to you is the login class concept. Chances are that you won’t need them, but it’s nevertheless good to know that they exist and what they are. On a system with multiple users it could be that some of these users want to use e.g. different locale settings. FreeBSD allows you to create login classes that control localization – only affecting users who have that login class set for their account.

Take a look at the available shells. Missing something? In that case the shell is not installed on the system. If it was, adduser would offer it to you. All shells present on the system are recorded in /etc/shells by the way. Feel free to cat it out and compare it to what adduser offers!

Now let’s switch to the new user and try to become root again. Nope, sudo is not part of the base system. We could install it, but for now we’ll go without it. Fortunately we know the root password. So let’s su to root!

Only “wheel” members are allowed to “su”!

“Sorry”? Now what’s that? Certainly not a very helpful error message! Well, you just met another peculiarity of FreeBSD: You need to be part of the wheel group for su to allow you to become root.

So let’s try that out. And indeed: After logging out, adding the user to the group using pw usermod [username] -G wheel and logging in – su let’s us become root.

Package management

Traditionally programs have been built from source in an automated manner using something called the ports tree. We’ll cover that in the last part of this article series.

The other choice obviously is to use binary packages. FreeBSD has used what is used the pkg_*tools for a long time. Up to the still supported FreeBSD 9.x, these are the default package management utilities. You use pkg_add -r to add packages to the system, pkg_info to display information about them, pkg_delete to remove them, and so forth.

On FreeBSD 8.4 and 9.x the new pkg-ng tool could be optionally used. Since release 10.0 it is the new standard tool for dealing with packages. It is however not part of the base system and thus does not come installed by default.

It will however be binary-bootstrapped (a package manager is needed to install the first package, too, right?) if you first try to use it. For that process it doesn’t make a difference if you provide any parameters to pkg or not.

Bootstrapping the pkg binary package manager

Pkg-ng uses just the unified pkg binary which allows for subcommands. Once you have it on your system, you can use pkg install to add packages to your system, pkg info to view package-related information and so on.

Let’s just install the BASH shell for now. It is as easy as typing pkg install bash. Pkg will list the package and its dependencies and ask for confirmation. If you give it, it will download and install the packages. That’s really all there is to it.

Package management is of course an important topic. The new pkg-ng tool is so easy to use however, that I won’t make any additional examples here. Be sure to have a look at the man pages or read the handbook article.

Installing a familiar shell: Bash

User management again

Ok, we have BASH installed now. Just a moment ago I told you that it should now be available if you add a new user. Now what to do if our already created user should get it as the default shell?

What we could do is pw userdel on it and then re-create it. We could even manually mess with the /etc/passwd file. But this is not the best way to do it. In fact it is much simpler than that.

About to change the shell for the current user

There’s a program that let’s you conveniently change user information of existing users. It goes by multiple names and allows editing different user information. In our case we want to use chsh – “change shell”. It will fire up an editor and let’s you edit the user’s login shell among other things.

DO MIND that FreeBSD keeps packages separate from the base system! There is no /usr/bin/bash! If you enter that as the path to your login shell, the user won’t be able to login anymore. In FreeBSD you’ll find it in /usr/local/bin/bash. The same is of course true for other shells that are not part of the base system and for any other software that is installed from packages in general!

Altering user information

It is also noteworthy that you should NOT change the login shell for root. Leave it as it is and start bash manually if you really have to. On a toy system it may not be much of an issue, but there is no need to grow bad habits in the first place. If you ever need to repair a damaged system and you have changed the default shell for root, you have a good chance that it will bite you.

BASH is now the new shell for my user

System services

We have one more topic to deal with in this article. Knowing how to manage users and adding packages is nice, but being unable to mess with services kind of makes FreeBSD useless for you. So let’s take a brief look at how FreeBSD works with services.

You can simply ps -aux like on linux to take a look at what is running on your system. But how to manipulate daemons properly?

For a while now (it was introduced sometime in the 8.x release versions, if I remember correctly) FreeBSD comes with the service command. It is a valuable tool that you should start using right away. Sure, you can use the init scripts by hand, too. But service has the advantage that you don’t have to think if something belongs to the base system (and is thus located in /etc) or not (in which case you’d have to look in /usr/local/etc)!

Taking a look at services

It also provides a few more nice features. First let’s have a look at which system services are currently enabled (run automatically on startup). To do this, simply type service -e.

If you want to know all services on the system (which you could start), use service -l. This produces a long list, so it might be a good idea to use a pager like less or grep for something if you already know what you are looking for. In our example let’s look for the ntp daemon: service -l | grep ntp. No surprise: It’s called ntpd.

It won’t keep running without the right parameter because my clock difference is too big. But we’re not covering ntpd here, right? It’s just an example and you can of course use other services as well.

How to enable a service?

First let’s ask the system about ntpd’s status: service ntpd status. Now that error message tells us that ntpd is not enabled in the system configuration. It could still be started manually but as long as it is not enabled in the rc config file, FreeBSD keeps reminding you of that fact (which is actually a good thing).

Just like it suggested, we can use service ntpd onestatus. Truthfully it tells us that the daemon is not running. We can start it despite not being enabled in rc.conf using service ntpd onestart. Now onestatus lets us know that it’s running. Keep in mind however that such a manually started process will not be started when the system boots!

We could stop the daemon again using the service command. But to show off the init script way we’ll do it without it one time: /etc/rc.d/ntpd onestop.

And now finally let’s take a look at the configuration file and how we can enable any service. Fire up any editor on /etc/rc.conf and add the line ntpd_enable=”YES” to it. That’s all in fact. In case you want to give any parameters to the daemon, you can do so by adding an optional line like the following: ntpd_flags=”-x”.

Where services are configured: The “rc.conf” file

There’s a lot more to know about services and I encourage you to take a look at the FreeBSD handbook on that topic. But for our short introduction of the very basics, that’s it.

What’s next?

The next post will be the last one of the FreeBSD introduction. It will deal with the ports system, updating from source and a few other things.

Exploring FreeBSD (1/3) – a tutorial from the Linux user’s perspective

The previous blog post detailed the FreeBSD installation and the one before introduced the OS in general.

This one is going to show you around a little bit. There’s a lot to see here – so let’s jump right in!

Convenient access

Let’s start the VM with the fresh FreeBSD installation and login as root. The Virtualbox graphical console does allow you to work with your VMs but it is not a convenient way: You cannot copy just some lines of configuration into the buffer or paste a longer command to execute. Also if you’re like me and use an optimized keyboard layout, chances are that in VBox you’ll have to use US or any standard keymap.

Or maybe you want to scroll up your terminal when you need to see what that strange output five minutes again was. Sure, you can do that in a Virtualbox console, but it’s much more comfortable using the mouse. When you’d try SHIFT-PG UP or SHIFT-PG DOWN like on a Linux system it won’t work BTW. FreeBSD has its own scrolling mode which you can enable/disable pressing the scroll lock key.

And of course it’s always nice if you can see multiple logins at once – say with split-screen tmux. You can switch to another TTY with CTRL-ALT-Fx on FreeBSD just like in Linux. In Virtualbox you use right CTRL and one of the Fx keys. That works but you can’t see two or more logins at the same time.

Anyways: There are more than enough perfectly valid reasons to get rid of Virtualbox’s graphical console. So let’s just do that. But first we have to edit the configuration file for the ssh daemon:

# vi /etc/ssh/sshd_config

Find the line #PermitRootLogin no, remove the comment sign and change it to yes. Save and exit vi.

Now we’d have to restart the ssh daemon for the changed config to be applied. But we won’t do that. Instead we’ll just power down the machine. You can do that as you’re most likely used to from Linux:

# halt

A moment later you’ll see something like this:

All buffers synced.
Uptime: 50s

The operating system has halted.
Please press any key to reboot.

This is FreeBSD’s way of saying: “Alright, I’ve finished. You can safely power off the machine now”. Close the VM. Now click on settings for your VM, choose network and click on advanced. Then click the button labeled Port Forwarding. In the new window add a new rule and enter 22 (the default port for SSH) as the guest port. Redirect it to any free port (higher than 1023) on your host machine – I’m using 20022 here.

Port forwarding rules for Virtualbox

Now let’s start the machine again. But since we don’t want the graphical console, let’s start the VM without it. Virtualbox offers something called headless mode which does just that: Start a VM in the background without a console for it. You could do so on the command line – but did you know that more recent versions also allow you to do this by double-clicking a VM while holding down SHIFT? Try it out!

Look at what Virtualbox calls the “preview” to watch the boot process and see that it is really starting. When it has booted up, it’s time to connect. User your favorite terminal to issue the following command:

$ ssh root@localhost -p 20022

You’ll then be prompted for the root password and then – there we are!

Alright! I don’t have to tell you that in general it is a very bad idea to enable root login for SSH – even more so if you allow logging in with password. But here for our purpose of just playing around on a non-production system it’s fair enough.

And what if you did something funny to your host’s ssh configuration and it won’t connect? Well, SSH problems are a special topic of their own. But here’s one not to miss: Whenever you run in trouble, be sure to include the “-v” switch for verbose output. This is bound to give you some hint at what is happening (and an idea what to search for with your preferred search machine if don’t know at all).

Welcome to FreeBSD!

That’s what your terminal is probably saying right now (if you’re just reading this post without following along, have a look at the screenshot).

Connected to the headless VM using SSH

Release notes and security advisories are probably not of too high importance for you if you’re new to FreeBSD. But I cannot recommend the handbook enough. It covers a large part of the system in detail and starts at a rather low-level (even for people without much command line experience). It is extremely helpful if you want to find your way around with FreeBSD. Have a look – and take your time reading. Really.

Don’t just jump at the forums. You are not ready for them, yet. Sure you’ll face problems. But this is Unix not Linux. kindergarten’s over. Learn to stand on your own feet and use your brain when you run into trouble. People in the forums will probably be happy to help you if you’ve read the handbook, FAQ, did some research on the net and still have no clue how to solve your problem. Do NOT consider it the first place to look for help! If the information you need is on the net and can be found easily then you’d steal everybody’s time asking stupid questions (and make yourself look like a dumbass at the same time).

Oh, and you may want to get used to consulting the man pages if you haven’t already. You may know that those exist from Linux but you may just have lived happily without them. They are a great resource of information. Embrace them and immediately benefit from the knowledge that they hold (without having to ask somebody and wait for an answer)!

Console commands

Use CTRL-L to clear the screen. Let’s see what FreeBSD can do! whoami, pwd, etc. You know the score. They all work and do what you’d expect.

Now let’s create two directories:

$ mkdir -p test/directories

Works like a charm. But perhaps we don’t really want them so let’s delete them again:

$ rm test
rm: test/: is a directory

Ah, stupid me. That command does not remove directories if it’s not given the -r switch! So let’s try again; the up-arrow key brings back the previous command so I can just append the missing switch. Now that should work, shouldn’t it?

$ rm test -r
rm: test/: is a directory
rm: -r: No such file or directory

What the…?! Why is stupid rm interpreting the switch as a file? This should work, right? Nope, rm is reacting just fine, it’s really my bad. But it does work on Linux, doesn’t it? That’s correct. So what’s happening here? In fact the above line is syntactically wrong. You should always state: 1. command, 2. option(s), 3. parameters. When rm met the first parameter (“test”) here, it stopped expecting options and thus treats “-r” as another parameter. And that’s fine – there could be a file “-r” after all as that’s a perfectly legitimate file name!

$ rm -r test

No surprise here: This works.

Lesson 1: FreeBSD is much more strict while Linux (with its GNU tools) lets you get away with a lot of strange things. Some people say that this makes GNU/Linux more “friendly” but that totally depends on how you look at it. What if you want to remove the files “test” and “-r” in GNU-land? It’s possible there, too. But you have to type this:

rm -r -- test -r

The double dash tells rm to stop parsing options and treat every following input as a parameter. Works just as well, for sure. But you need to know how to use the double dash or you can run into pretty bad edge cases without a clue what’s going on. The BSD way of doing things is not aiming at this kind of “friendliness” but just doing things right in the first place.

Mind the syntax!

Let’s take a look at what df can tell us. Except for the device name there’s nothing too strange here. If you wonder how that device naming works, you may take a look at my previous post, where I explained it in section “Excursion: Partitions and *BSD”.

But there is one special thing about df which you might run into if you decide to do some *BSD: Capacity can go over 100%! Yes, you can come across e.g. the root partition being at 105% or something like that. This is not an error in df – it is something that is conceptionally different. FreeBSD reserves 8% of disk space for the OS and root and df considers the complete space minus the reserved space to be 100%.

The shell

Now let’s try to play a little with environment variables. Setting and displaying one should be easy, no?

$ export ALL_FINE=”sure!”
export: Command not found.

Uh, what’s happening here? The system doesn’t know about export! Do you know what it belongs to? Try running which export on any Linux system. You won’t find it there either. What a mysterious case! Ok, not really. Export is an internal command provided by bash, the standard shell of most Linux distributions. FreeBSD uses another default shell, so let me introduce: The C-Shell (csh)!

Different shell: csh.

The most important thing that you need to know about the C-Shell is that it is fundamentally different in many ways. I’ll just show setting an environment variable here to show off something; the whole topic is huge and if you care enough, you should easily find something helpful to read. But we’ll simply be installing bash later in this tutorial. Why? Because there’s enough to learn for FreeBSD anyway and it doesn’t hurt if people can at least explore with a shell they know and feel comfortable with.

$ setenv ALL_FINE “sure!”

This is what the csh expects if you want to set an environment variable. Mind the missing equals sign! And if you want to display all the variables currently present, just run setenv without any parameters.

What’s next?

This post tried to give some very basic information for you to get along on FreeBSD systems. In the next two parts we’ll have a look at user, package and service management, system configuration, ports and updating the system.

Installing FreeBSD – a tutorial from the Linux user’s perspective

This article deals with installing FreeBSD. It’s meant for the first time FreeBSD user who has a bit of Linux background.

The installation process is actually quite simple and straight-forward. I’ll guide you through in some
detail, anyways, because I think that there are a few things that are good to know even if they are not strictly necessary.

On a side note: My blog turned three a few days ago. I decided not to write a birthday post this year. Let’s just get on with some real content!


The easiest way to try out a new operating system these days is to run it in a virtual machine. I’m using VirtualBox to create the screenshots and you are invited to create one, too, and follow along. Just reading the post is also fine, though. And of course nobody will stop you if you decide to dedicate a real machine to this project because you have some spare hardware around.

If you opted for VirtualBox, you just need to create a new VM first. Select FreeBSD as the OS and give it a bit more RAM and far more disk space (since we’re actually going to put our new system to some use) than VirtualBox suggests. Other than that, you’re set up. You should not need to make any other changes (though you can of course adjust things if you feel like it).

Now download an ISO image if the installer CD from here.

We’ll be using FreeBSD 10.1-RELEASE. Pick the right one for your CPU architecture – if you’ve got a PC then i386 means “32-bit” and amd64 means “64-bit”. It doesn’t matter if you’ve got an Intel or an AMD. Make sure you choose an installer image and not a virtual machine image since we want to install FreeBSD after all!

The smallest image is fine; that’s FreeBSD-10.1-RELEASE-amd64-bootonly.iso for a 64-bit system (or the .xz one which you need to decompress after the download). If you were going to install FreeBSD on several machines or on one that is not connected to the net, it would make sense to choose a bigger one which actually includes the OS you want to install. But for our purpose the bootonly (which will download the OS files) suffices.

Got everything? Excellent. Start up your VM and put the installer image into the virtual drive. Then you’re set to go.

Installing FreeBSD: Keyboard and file sets

You should be greeted by the bootloader. Either wait ten seconds or just press the Enter key (we don’t want to set any special options at this early stage).

The FreeBSD bootloader screen

Now the kernel will probe your hardware and the system will come up. Once everything is done, the installer will be started automatically. It’s not the most beautiful installation program ever, but it does the job. And it actually makes the installation really easy. Until FreeBSD 8 there was the old installer, BTW. It was more powerful but the installation was also more complex (and it was even more ugly! ;)).

Meet the FreeBSD installer!

After choosing “install” you can select a keymap or go with the default one (US). It’s all up to you here.

Keymap selection in the installer

Then we have to give the virtual computer a name. I decided to call the machine beastie which is the name of FreeBSD’s mascot (the little red daemon with the fork).

Setting the hostname of the machine

Next select which optional sets to install. You won’t need doc. This may have been very useful in the past but today you’ll probably want to simply browse the documentation online instead of locally, anyways. If you really want it, it won’t hurt you, though, but you could just as well save yourself (and the FreeBSD project) some bandwidth.

Games is not what you probably think, BTW. It’s pretty obvious that this won’t install DooM or Quake or the like. But it’s not even something like Solitaire or Freecell that comes with Windows. It’s in fact just a bunch of command-line based games, the most popular being “fortune” mentioned by the installer. It is a “fortune cookie simulator”. Most people probably won’t call any of the programs from this set an actual game. They are more or less just little fun or joke programs. Actually they have a long tradition with Unix and they are very small, too. For that reason they are included in a FreeBSD install by default. You may deselect this set if you really want but they definitely won’t hurt you, either.

Choosing the sets to install

The lib32 set contains the 32-bit libraries which are needed if you want to run 32-bit executables on a 64-bit FreeBSD system. There are actually more cases where you need them than you might think. So if you aren’t really, really short on disk space or know exactly that you won’t ever need them (hint: When you are just starting with FreeBSD, you don’t) just leave this one checked.

For our tutorial please make sure you uncheck the ports and src sets which contain the ports tree and the system source code respectively. We will need both later – but we’ll fetch the current version of both them using different a different means!

Installing FreeBSD: Network

Now you need to configure your network so that the sets can be downloaded. This is a pretty straight-forward thing to do: Select your NIC (chances are you only have one, anyways), select IPv4 and choose DHCP if you wish to automatically receive an IP address (otherwise configure the NIC manually). You probably don’t need IPv6 so skip that unless you’re really actually using it in your LAN. If you selected DHCP, FreeBSD should have received the address of at least one DNS server as well. If it didn’t, make sure to provide one. Otherwise name resolution won’t work and the installer cannot download the file sets.

Selecting the mirror

The next step is to select a mirror server from which to download. It obviously makes sense to choose one that is located in a place near to you as it is more likely to provide a good connection for you.

Installing FreeBSD: Disk layout

All that’s left is setting up the hard disk(s). The basic choice you have to make is which file system you want to use. FreeBSD basically supports two native file systems: The traditional UFS (“Unix File System” aka. FFS or “Fast File System”) and the next-gen filesystem ZFS. The later is a sophisticated FS with a lot of interesting features. For quite some people, fact that ZFS is considered stable on FreeBSD is a killer feature of this operating system and even the main reason why they choose this OS.

ZFS is however well beyond the scope of this post. A dozen of posts like this could be written on that topic (probably not by me, though, since my ZFS knowledge is rather basic, at least at the time being).

So we’ll opt for UFS now. Partitioning a FreeBSD system is a little bit more complex than partitioning Linux. Fortunately there’s the Auto (UFS) option in the installer. We select that and want to use the entire disk.

Disk partitioning

Today there are two partitioning schemes in use on the PC. FreeBSD defaults to the newer one, GPT. You could also use the older MBR instead if you have any reason to do so. And in fact you could even go without any of them! But that’s going deeper than we need right now.

The installer suggests a default partitioning: A boot partition, one for the root file system and one more for the swap space. Depending on what you want to do with your FreeBSD machine, this is most likely not what you want. But for our test system it’s fair enough.

The default partitioning layout

After hitting “Finish” and “Commit” the changes are written to disk and the actual installation begins.

Excursion: Partitions and *BSD

Partitions are a topic which can be highly confusing for the beginner (at least it has been for me before I did some research in this area). The problem here is that in the FreeBSD world a partition is something different what you might think. And to make matters worse, the terminology differs even between the BSD distributions!

Most Linux distros use the old MBR (“Master Boot Record”) partitioning aka “DOS partitioning”. Same thing if you come from a Windows background. You know the score: Up to four primary partitions and extended partitions if you need more than that. Chances are that your Linux distribution uses three primary partitions: One for /boot, one for SWAP and one for /. If they are on the first hard drive (sda) of your pc then they will be called /dev/sda1, /dev/sda2 and /dev/sda3.

These partitions are known as disk slices in the FreeBSD terminology. So it’s just a different name for the same thing, right? That cannot be so bad! Wrong. The MBR partitions are the same thing as the slices, yes. But the fun starts when you learn that the BSD systems use a mechanism called BSD disklabels. These divide the MBR partitions further and if you think in the DOS terminology of partitions, disklabels actually allow for what might be called sub-partitions as that is what they are. Unfortunately these are just called partitions in the FreeBSD context!

So remember this: In FreeBSD a “partition” is what you may think of as a sub-partition and a “disk slice” is what you commonly know as a partition. How come that we have all this confusion? Who’s guilty of causing it? Well, things are not so easy here…

Unix began its life not on the PC but on bigger research computers which did not support partitions at all. So the Unix people came up with disklabels to partition disks into up to 8 partitions. Since that is what they are, it was an obvious choice to call them partitions. Quite some time later the PC platform supported MBR partitions which were also called thus. The real trouble started however when Unix was ported to the PC: Now there were two different things with the same name! For compatibility’s sake, FreeBSD embeds its partitions (sub-partitions, remember) into what they call disk slices (MBR partitions) to be able to distinguish between the two.

As a consequence, FreeBSD needs only one disk slice (MBR partition) because it can create partitions (sub-partitions) on it, e.g. for SWAP.

If you are using the MBR scheme, it leads to a naming like e.g. /dev/da0s1b. This means the first SCSI disk, slice 1 (primary MBR partition 1), partition 2. /dev/ada1s5f means the second SATA disk, slice 5 (extended MBR partition 1), partition 6.

FreeBSD can also do without slices. This is called “dangerously dedicated” mode. The name sounds quite worrying but in fact the only “danger” is that it is highly unlikely non-BSD systems will be able to read any data from it (since they don’t know about disklabels). If you ever come across something like /dev/da1d, you know that it’s the 4th partition (sub-partition) on the “dangerously dedicated” (MBR partition-less) disk da1. If you just have *BSD on your drive, you can use this mode and there’s no “danger” for your data.

Fortunately things became easier with the introduction of GPT (“GUID Partition Table”), a newer partitioning scheme that supports more than the 4 primary partitions of MBR. And since more than enough partitions can be created this way, FreeBSD does not use disklabels to subpartition them further. The good thing is that many other operating systems know GPT partitions, too. The bad thing is that we have another kind of partition that’s just called… Partition.

Newer FreeBSD installations default to GPT partitioning. If you look for your drives then, you’ll probably find them as something like /dev/ada0p1 which means the first GPT partition on the first disk.

If you have to use the older MBR partitioning for some reason, there are a few things you should know about disklabels. Disklabel a is meant to hold the root filesystem (/), b is for SWAP. C is completely special; you cannot use it as a normal partition. It’s always there and covers the whole disk. This is used by some tools to access the disk in raw mode, neglecting any partitions or whatever. Historically d stood for the whole disk and c for the complete slice – but that time has passed.

That’s a lot of information, I know. But you’ll get the hang of it if you want to. It’s not that difficult once you got rid of the confusion.

Installing FreeBSD: Putting the system on the disk

Now lean back for a while; the installer will fetch the distribution packages from the net first.

Fetching the distribution packages

As said before, this step is skipped if you use a bigger image. In that case you’ll also configure the network settings later in the installation process.

Installing FreeBSD: Final steps

When all distribution packages are downloaded and extracted, you are prompted for a password for the root user.

Setting a password for the root user

Then you have to tell FreeBSD about your time settings. If it is the only OS on your machine or it shares it with other Unix-like systems like Linux, go for UTC. If you also have Windows on the same computer, however, be sure to select No here. Windows and UTC is a mess.

Choosing the time setting

In the next screen you can choose which daemons should be started during the system boot process. Unselect dumpdev, it’s of no use to us (if you were able to read crash dumps and debug the applications with this info, you wouldn’t really read this post now, would you?). Keep sshd selected if you want it.

Selecting the daemons for autostart

Choose not to add any users right now. We’ll be doing this later and learn a bit about user management on FreeBSD! Next hit “Exit”, tell the installer that you don’t want to make any final changes.

Exit the installer

Choose to reboot. And that’s it.

Reboot to finish the installation

If you remove the installer image, your machine should boot into your new FreeBSD system. Welcome on board, new BSD user!

What’s next?

The next blog post will deal with some of the very basics of a fresh FreeBSD system.

FreeBSD – from the Linux user’s perspective (introduction)

With this (and the next) post we’re going to take a look at FreeBSD, assuming some basic Linux experience. The goal is to provide an easy introduction and to show where that system behaves differently from Linux. And we’ll also touch the subject of strengths and weaknesses of FreeBSD.

What is FreeBSD?

Linux is a Unix-like Operating system and the same is true for FreeBSD. The difference is that FreeBSD is a direct offspring of BSD-Unix whereas Linux was coded from scratch and did never have any code in common with Unix. So compared with Linux, FreeBSD is clearly “more Unix”. But why don’t we just say that it IS a Unix since it once was? Because of legal trouble…

Technically, FreeBSD is a much improved BSD-Unix. But there’s one problem: UNIX is a trademark. In order to call your system a Unix, it must comply with the Unix specifications. FreeBSD did this and probably still does for the largest part. That’s just the first requirement, though! The other is that you need to have your OS certified – which is not exactly a cheap thing to do. IBM did this for AIX, HP for HP-UX, etc. FreeBSD, being a non-commercial community project, needs the money it receives from donations for other things. And so – for legal reasons – FreeBSD is not a Unix but just a “Unix-like” system.

However it has come from Unix and it feels like Unix (with quite some things a little different from Linux). So if you don’t like the stiff term “Unix-like” you can of course think of your FreeBSD as a Unix system in contrast to Linux.

FreeBSD’s goal as stated by the project, is to provide a general purpose, secure and highly scalable operating system that is available free of charge. Sounds a lot like Linux so far, doesn’t it? Yeah, it does. But please keep in mind that this doesn’t make FreeBSD the boring rip-off. FreeBSD was there first! But even if you’d argue that it’s obsolete, now that Linux does extremely well in just about all areas (and admittedly better in quite some), there’s one more point. FreeBSD is meant to be available free of charge and under a permissive license!

Linux is GPL’ed. That makes it available for free and ensures that the code will always be open, because the license enforces these things. FreeBSD, licensed under the BSD license, does not do this. You are free to do things with it which the GPL does not allow. A whole lot of people don’t care (they have probably never even thought about licensing) and quite some people applaud the GPL’s approach. Others however prefer BSD-style licenses. It’s a matter of taste and a philosophic question that cannot really be decided once and for all.

I’ve written a short post on an introduction to licenses more than a year ago. It was meant to have a follow-up article but I didn’t find the time to write that one, yet.

System structure

The whole operating system is integrally connected. Where a Linux distro is actually “the Linux kernel plus (a lot of) packages”, FreeBSD is different. Programs from upstream are imported into the system repository and often patched. The versions are chosen to play together nicely with all the other components of the system.

This operating system consists of two parts: kernel and world, the latter being the userspace part of it. The actual software you install on top of the OS is separated from it: Files are put into /usr/local so they don’t mix with those that belong to the base system – which is quite a clean thing.

Traditionally FreeBSD has come with the ports system. If you want to install an application which is not part of the OS, you change into the respective directory of the ports tree and run make install clean. The Makefiles (and a few other files as well) then take care that the source code is downloaded, extracted and configured, that patches are applied, the program is compiled and installed. You do not need to know anything about how to get a program to work on FreeBSD. If somebody already wrote a port, it’s as easy as issuing that make command. The port will also ensure that any dependencies needed are present on the system and, in case any is missing, they are automatically built and installed by the ports system, too.

But that’s not all. Ports for many programs are created to allow you to select which features to compile a program with. A simple menu-driven UI let’s you check and uncheck features for each port. And of course it allows for clean removal of installed software using make deinstall. Also the ports tree often offers you various versions of a program to choose from. Want Apache 2.4 or probably rather 2.2? Or perhaps you need gcc. Feel free to choose any of 4.6, 4.7, 4.8, 4.9 and 5.1!

This allows for easy customizing of the software you install: You get exactly what you need and want. If you have no special needs for some programs and don’t want to compile it on your computer, you can of course use pre-built binary packages like on Linux. And the best thing: Since the ports system actually builds packages, you can mix the two as they play together nicely and won’t conflict!

Some strong points

FreeBSD has a world-class network stack – which is absolutely no wonder since TCP/IP was in fact developed on BSD Unix! This is one example where FreeBSD is superior to Linux.

Another nice feature are the so-called secure levels together with the extended file flags. The later open up some interesting possibilities: You could, for example, set the file flag “append only” on a log file. The log is not “read only” – it can be written to. So new log entries can be appended to the file. But it is impossible to either delete the file or remove content that’s already in it! If an attacker (who does not want you to notice that he broke into your system) tries to cover his tracks this can be extremely frustrating as there is no way he can get rid of anything that’s in the log!

That is… As long as he doesn’t just remove the file flag. But to make that impossible as well, FreeBSD has secure levels. You can always add file flags. But you can only remove them when the system is in secure level 0. And here’s the show-stopper: Once set to higher than 0 secure levels cannot be reduced. Not even by root and not even by yourself with physical access to your server! There’s exactly one way to get rid of a secure level greater than 0: Reboot… And a reboot won’t go unnoticed easily, right?

One more very cool feature are jails. Think of them as hardened chroot environments with a lot of extras (like IP addresses for a jail). They are kept strictly separate from the rest of the system (and from other jails). You have heard about all that “container” stuff that’s currently en vogue in Linux, haven’t you? No need for that on FreeBSD! If you want a secure environment (or several) for single applications – just jail them. FreeBSD offers this possibility for ages now (but to be fair I should mention that they were available on Solaris (where they are called “zones” even earlier).

And perhaps you have heard good things about the ZFS filesystem or about DTRACE. FreeBSD comes with both of them and they are considered stable. And of course there’s much more to it. But let’s leave that for the next post where we’ll get our hands on FreeBSD, right?

For those of you who are interested, here’s a little Unix history (it’s good to know because it helps understand why things are how they are today – but if you don’t care at all you can of course skip it).

Unix history

In 1964 AT&T, GE (General Electric) and the MIT (Massachusetts Institute of Technology) teamed up to create a sophisticated new operating system they called Multics. It was extremely innovative and pioneered many features in computing. A lot of people thought however that it was overly complex and not quite the system they wanted.

Eventually AT&T pulled out of the project and started another one in 1969 which followed the converse idea: Simplicity over complexity! This operating system is known as “research Unix”. In the following years various versions were completed and licensed especially to universities for little money (because AT&T was not allowed to compete on the software market at that time due to their telephone monopoly). During that time it was a matter of course that you got the source code when you bought software. For that reason students of computer science could look at the code – and modify it.

Coded in assembler first, it was soon re-written in the new programming language C which forever remains closely tied to Unix. Thanks to the availability of the code, the universities kept producing patches with new functionality for Unix and gave it away for free to anybody who had licensed the base product (Unix). At the center of this development was Berkeley University which collected these patches and patch sets. They created new Unix releases from those which were called “Berkeley System Distribution” or BSD for short. The first one was 1BSD in 1978 which was based on AT&T’s Unix Sixth Edition from 1975.

The university created the major releases 2BSD, 3BSD and 4BSD over the years. These grew in popularity fast and quite often Unix from AT&T was bought and put aside only to be able to actually use BSD legally! In 1986 4.3BSD was released (based on Unix System V from 1983). The year 1992 saw the release of a short-lived project which nevertheless had a huge impact: 386BSD or Jolix (named after its creators, Lynne Jolitz and William Jolitz). It was an effort to port 4.3BSD to the 80386 PC.

Now the BSD story repeated in a smaller scale: 386BSD enthusiasts created patches for the system and an unofficial patchkit was provided from it. Due to a difference in opinion the patchkit maintainers broke away from 386BSD and founded the FreeBSD project. About the same time another group of 386BSD users started they own project derived from that 386BSD: NetBSD was born.

The original BSD project ended in 1994 with a strange last release called 4.4BSD-lite. It was a crippled release that could not even run on its own! The reason was a lawsuit from the Unix System Laboratories. Formed after AT&T’s forced break-up, they finally could compete on the PC market and began to offer Unix for high prices. It goes without saying that the existence of BSD was a thorn in their side – and they meant to remove it!

But greed is not a good advisor and in the end the case was settled out of court. Why? Because the university proved that over the years almost all of AT&T’s code had been replaced. BSD was almost a system completely of its own! But that’s not all. In fact AT&T had taken the free code from BSD and used it in their newer Unix releases. While there’s nothing wrong with that, they didn’t give the BSD credit for their work. And by failing to do that it turned out that they were violating the BSD licence themselves!

It is the legal struggle and uncertainty that followed from the case which can be seen as one reason why Linux gained more and more attention: If you chose any BSD derivative you never know what might happen some day…

What’s next?

Next in line is a FreeBSD tutorial that puts focus on getting the system installed and exploring what’s different from Linux.

Pacman on OpenBSD (pt. 2)

A bit belated comes the second part of installing Pacman on OpenBSD. The previous post was about the attempt to get Pacman up and running on OpenBSD 5.6. In the end it failed because the OS did not know about the ‘blkcnt_t’ type. This was nothing that a non-programmer could fix easily – but fortunately this new type is available in the upcoming OpenBSD 5.7. So we’re going to continue with that.

Snapshot time

OpenBSD 5.7 was not released when I prepared the pictures for this post. Since it took me far to long to complete this article, it was released yesterday. Anyways: OpenBSD comes in three “flavors”: Release, Stable and Current. Releases (like 5.7) are made twice a year and stay like they are. If any problems with OpenBSD are found, patches are made available. The patched code resides in the Stable branch which you should track to keep a secure and up to date system.

And then there’s Current. This branch contains the latest code. It’s meant for developers, testers and all kind of people who like to live on the edge or who want/need the latest features. You can update a release or stable system to current, but especially in case of bigger changes it’s best to start with a snapshot – and we’ll do just that in a minute.

So far I hadn’t been looking into OpenBSD deep enough to use anything else than release/stable. Time for my first peek at current and thus the upcoming 5.7 release!

Installing the system

Setting up a new system, we’re meeting the installer again. I didn’t notice too many differences from 5.6, so I’ll just show some screenshots from different parts of it.

One thing that I didn’t show in the last post was the creation of the disklabels. If you want to work with *BSD you should get an idea of what this is before thinking about how to partition your drive(s). In short: While the PC allows for 4 primary partitions (a limit which was overcome with the extended partitions later), the systems Unix originally ran on didn’t provide such a facility. To be able to partition disks on those machines, disklabels were invented. On a PC you may think of them as “sub-partitions” since they are created inside “real” partitions to subdivide a drive further.

If you’re new to OpenBSD you may be astounded when you see how many disklabels OpenBSD creates by default. This is in fact a security feature. OpenBSD mounts /tmp with “noexec” for example which means that if an attacker manages to place a binary there, it’s not going to be of much use since no program can be executed on this partition. If /tmp had been part of the / disklabel this would not have been possible. Of course there’s more to the decision for each default disklabel but you get the idea.

Creating disklabels with the installer

Now if you look closely, you can see one difference between 5.6 and 5.7: There are fewer sets to choose from! This is due to the fact that etcXX and xetcXX are no longer separate tarballs but have been moved into baseXX and xbaseXX respectively.

While this is something that OpenBSD veterans will have to mind when updating, for us beginners it is not too exciting a change. And when doing a fresh installation it totally makes sense to have the etc set installed as part of base, anyway.

The etcXX and xetcXX tarballs were removed

While OpenBSD provides cdXX and installXX isos for each release, there’s only one type available for the snapshots. It is equivalent to cdXX which does not contain the installation sets. For that reason they have to be downloaded from the net before they can be installed.

Installation of the snapshot packages complete!

Once the installation process is completed, we can boot into the new system. Upon login the system identifies itself as “OpenBSD 5.7-current” – so we’re there and can resume the work on getting Pacman to run on this system.

My first OpenBSD of the “current” flavor!

Back to Pac!

Alright. From the previous attempt we know that Pacman needs a few things installed so we can build it. This time we just have a slight inconvenience: Using a snapshot there are no pre-built packages available. So that means it’s necessary to build each and every package using the ports system. Especially in case of the compiler this takes quite a bit of time.

I’ll skip over the details here; what I did was to build and install:

  • wget (to fetch the Pacman source)
  • bash (because Pacman needs it)
  • libarchive (used by Pacman)
  • gcc 4.9 (because OpenBSD’s old system compiler (4.2!) won’t build Pacman)
  • gmake (Pacman requires it to build)

After the source has been unpacked it’s time to configure it.

All dependencies built. On with Pacman!

Like last time configure is satisfied with the system. But unlike last time Pacman can actually be built now! So let’s go ahead and install it.

Compilation looks good

Now that it’s installed, it’s time to try and see if it actually works or if it’s going to segfault or anything. Fortunately it only throws an error because I didn’t provide any parameter. This is its expected behavior, so everything is fine so far.

Pacman is working!

Of course there are no packages available for OpenBSD which are compatible with Pacman. So we’ll have to create one ourselves. I’ve installed links via the ports for a little convenience so browsing the Arch Linux pages and getting the first PKGBUILD file is a simple thing.

Getting the first PKGBUILD file with links

What next? With the PKGBUILD file for it we should be able to build and package curl shouldn’t we? Of course we have to tell makepkg to disregard the package’s dependencies because there are no packages installed using Pacman on this system, yet. And since there’s also no gnupg available, we need to skip the checks, too.

Then makepkg is happy. Well, almost. It relies on curl to fetch source tarballs – and since we’re attempting to build curl in the first place this obviously won’t work. So in this case the best solution is to just wget the source and put it into the working directory.

Pacman needs curl to download sources – let’s just wget curl’s source

Next try! Makepkg unpacks the source, runs configure and – fails. Ok, the PKGBUILD file was created for Arch Linux and Linux systems only use GNU make by default and thus simply name it “make”. We’ll have to edit the file and replace “make” with “gmake”.

Much better: Curl is built successfully! However makepkg cannot package it because the fakeroot program is not available on our system. So the next step is to build and install that before trying again.

Curl built, but fakeroot is missing

After fakeroot is present on the system, makepkg is happy again and tries to package curl for us. But we’re in for another error message: This time it’s install complaining. The reason is that GNU install uses some extensions unknown and thus unavailable on *BSD systems. Now we’re really close!
The solution in this case is to modify the PKGBUILD file again, remove the offending parameter and create directories with mkdir. Next attempt!

Incompatible versions of BSD and GNU install

Success! The first Pacman package for OpenBSD was built!

Yay, first package built! :)

Now let’s install the newly built package and see if that works, too. Does it? Sure thing. And even if that’s a pretty short list of installed packages right now, the important first step has been made.

Confirmed: Pacman works

So let’s build another package and see if Pacman can make use of the now installed curl. I chose bash because that’s one more dependency of the package manager. And really: Everything is fine.

Pacman can now fetch the source itself

All done: The second package has been built. Now we could go on and build any other package. In that case we’d come across a lot of problems getting them to build on OpenBSD. That’s for sure. But that is general packaging trouble. The goal to bring the Pacman package manager to OpenBSD has been successfully reached.

Second package (bash) built

Pacman on OpenBSD – why?

OpenBSD features a package system that is both simple and tried. It does the job. But in some regards a more modern solution could do the job – well, better.

From the Linux perspective it is completely incomprehensible that only the programs which you install on top of the OS are packaged. The operating system itself is installed by unpacking tarballs. There is no package management keeping track of their files. This is the reason why some files have to be deleted by hand on every update. If the OS was managed by a tool like Pacman this would be unnecessary. Point 1: A fully managed system is cleaner.

The ports are a facility that works. But writing makefiles for everything is a rather tedious task, especially since make requires some black magic now and then to achieve special things. Pacman on the contrary uses shell scripting which is both powerful and easy to read. And I’d claim that it’s also far easier to learn than make for people who are not programmers (and package maintainers do not need to be programmers after all!). Point 2: Packaging via shell scripting is easier to write, read and learn.

Updating the OS itself is a special thing without a real need for this. If the system was managed, updating without booting a ramdisk to unpack tarballs would be possible. Point 3: It would make updating the system easier and more consistent (why should the core OS be treated differently from the application programs?).

There are more points in favor of a more modern package management solution but most of them are arguably a matter of taste.

Of course there are a few disadvantages of using Pacman as well. For one it’s not meant to be used for huge packages like the base system. It works well, but the possibility to patch the base system from one version to the next using deltas for all the files instead of removing the old package and replacing the whole thing with the new one, would be even better.

Another issue is the license: The *BSDs prefer permissively licensed applications over “copy left” models. And Pacman is GPL’ed software.

Nevertheless the combination of OpenBSD + Pacman is an interesting one in my opinion. If anybody else thinks the same – feel free to drop me a comment here.

What’s next?

I’ve got yet another *BSD topic in line. Since I was asked by some friends about FreeBSD, I figured that it would be a good idea to write a little tutorial / introduction to FreeBSD from the perspective from the average Linux user.

Pacman on OpenBSD (pt. 1)

It’s April fool’s time! You knew it: There is no ArchBSD/Open in the making (or at least I don’t know about it). But this year’s April fool actually has some real background – both on the technical and the social side.


Well, I had the basic idea for this fool since about the beginning of the year. I wanted to bring ArchBSD to the attention of my readers again since I really like the idea. But there was not too much news about the project. So I had to come up with something. And I thought that the humorous aspect of an April fool was just about the right thing.

There was another reason, however, and a rather strange one actually. A while ago I read somewhere that somebody was to leave Arch Linux (for various and IMO very valid reasons) and use OpenBSD instead. Right in the next post he was told in a condescending tone to enjoy the visit because he’d be back in no time anyways. I immediately hated that arrogance! Having been a visitor to *BSD land myself (and having liked quite some things there), the idea was born if there could be an Arch-OpenBSD blend like there was already ArchBSD for FreeBSD.

Just a joke logo

Behavior and sensivities

There’s a lot of bad behavior in the Linux world. On the forums of the now dead distribution CrunchBang I once read that there were also some Archers “creeping around” (there’s another distro, ArchBang, which follows the same design ideas but is based on Arch Linux). Obviously the poster didn’t have much respect for some of his fellow Linux users because another distribution fits their purpose best.

Another member’s signature made it quite clear why: UDOD (“Use Debian or die!”). I have no problem with such signatures or statements. In fact I think they are funny to some degree. The only problem here is: You never know if people are actually serious and do mean it.

Or have you ever witnessed what happens on the Arch forums if somebody admits to be using Manjaro or any other Arch-based distro? Quite often the reactions are… not exactly friendly. Use a different (even a closely related) distribution and you’ll probably make no friends.

Ironically, a somewhat similar thing can happen to you the other way around, too. Just go to the Gentoo forums and dare to ask a beginner’s question. Chances are that you are told how Gentoo is not for you and you should find another distro.

You really have to grow a thick skin in some cases! Fortunately there are also a lot of friendly and very helpful people around. And on the other side there’s this new trend to replace pronouns with “gender-neutral” ones… This takes every day’s imbecility to a whole new level where endless discussions arise not over technical matters but over real or imaginary sensitivities of some minority.

Pacman on OpenBSD?

But enough of that. The net is the net and people are… what people are. Anyways: I begun to wonder if pacman could be installed on OpenBSD, too. And since I actually I liked the idea, I decided to give it a try.

I don’t have too much experience with OpenBSD, yet, but I’ve been following the releases for about two years now and in fact I think it’s a great OS. So let’s install it first! Just like other free operating systems you can download in ISO image for the installation. There’s just one thing wrong with it: The name! No, it’s not a joke this time; the file is just named ‘cd56.iso’. Now I’m all for short names but it should at least be informative. And ‘cd56.iso’ clearly isn’t.

I’ve hated that with Gentoo: They offer images by the name of ‘install-x86-minimal-20150407.iso’ and the likes. Ok, by now I know that this is a Gentoo image but would it really hurt to state just that somewhere? And with OpenBSD it’s even worse: You cannot even tell whether this file is an ISO of a 32-bit or of a 64-bit system! That’s pretty bad. Now if you have both older and newer computers to deal with and download both, you’ll end up with something like ‘cd56 (1).iso’ which is just ugly. And to tell which file is which version, you have to take a look at the size as the 64-bit one is slightly bigger (or you have to remember which one you downloaded first).

Installing OpenBSD

OpenBSD comes with a simple text-mode installer. Simple in this case means that it’s simple to use. It let’s you choose how to install and does a lot of things for you then. Want to know what it can do? Just have a look at it! It’s a shell script.

Installing the base system actually means fetching and unpacking tarballs. This is a simple and efficient method. And while it means that the files for the base system are not managed by any package manager (the programs we’re going to install later of course are!), it seems that the OpenBSD people can live with that pretty well. Upgrading the system means extracting newer tarballs and removing some obsolete files by hand.

Installing OpenBSD 5.6 tarballs

Version 5.7 of OpenBSD is due next month so at the moment 5.6 is the newest version out and I’m going to use that. After the system was installed on the drive I’m prompted for the root password and a few other things.

Some more choices of the OpenBSD installer

Trying to build pacman

Now we need the pacman sources of course. Let’s install wget to download it. That program is available as a package for OpenBSD but to get that we need to tell the package system the path to a package mirror first.

Fetching pacman source with wget

Ok. After installing some dependencies for pacman (bash and libarchive) configure was happy. So we’re ready to make!

Trying to ‘make’ pacman

Oops. Pacman obviously needs GNU make and cannot be built with BSD make. So let’s install gmake and try again.

Compilation failed – installing a new gcc

Much better. The compilation begins. But then it fails. Looks like OpenBSD’s old gcc is not capable of compiling pacman… Fortunately there’s a newer version (two of them in fact) available as packages. Let’s install one, set CC to egcc (this is what the packaged newer gcc versions are called to distinguish them from the system compiler) and re-run configure before we try to build again.

End of the line: OpenBSD does not know ‘blkcnt_t’ type!

Now that’s not cool. The compilation failed again! And this time it’s not gcc’s fault. OpenBSD simply does not know the ‘blkcnt_t’ type. As there’s no way to fix that easily, we’re stuck. Aren’t we?

What’s next?

Actually we aren’t out of luck. The coming version 5.7 supports this type! In my next post I’m going to install a snapshot and use pacman on that system. Yes, I can already tell you that it works. I’ve already taken these screenshots (and the ones for the next post) mid-march. ;)