Here I'm republishing an old blog post of mine originally from August 2015. The article has been slightly improved.

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.

Installing FreeBSD - a tutorial from the Linux user's perspective

FreeBSD - from the Linux user's perspective (introduction)

This one is going to show you around a little bit. There's a lot to see here - so let's dive 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 sessions 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 that reads _#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.

__Note:__ To properly power off your FreeBSD machine, you should use the __shutdown__ command instead of _halt_ or _reboot_ as that will try to stop running services instead of just killing them. Shutdown can take the parameters -p to power down or -r to reboot the machine respectively. Thanks, TK, for reminding me (via comment on my blog) of that as it really is something that a tutorial reader should know!

Now click on _settings_ for your VM, choose _network_ and click on _advanced_. Then pick 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 (PNG)

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 attaching a vga console to 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 emulator to issue the following command:

$ ssh root@localhost -p 20022

You'll 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 a 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 (add more "v"s for even more information). 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 (PNG)

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 with rather low-level topics (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 two 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! Doing so is the wrong attitude. 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 so far. They are a great resource of information, though. 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. Now let's see what FreeBSD can do! Commands like _whoami_, _pwd_, etc. You know the score. They all work and do what you'd expect.

Ok, I'm going to 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! Right, 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 doing just fine, it's really my bad. But it does work on Linux, doesn't it? Yes, 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 (albeit uncommon) 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 on what's going on. The BSD way of doing things is not aiming at this kind of complicated "friendliness" but just doing things right in the first place.

Mind the syntax! (PNG)

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".

gemini://gemini.circumlunar.space/users/kraileth/neunix/eerie/2015/fbsd_installation.gmi

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% (which makes perfect sense for the user).

The shell

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

$ 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 a program 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 (PNG)

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 about 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_ or _env_ 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.

BACK TO 2015 OVERVIEW