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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s