Here I'm republishing an old blog post of mine originally from September 2015. The article has been slightly improved.
This is the second post of the "Exploring FreeBSD" tutorial. If you didn't do so already, you may want to read the first part before this one. And if you are completely unfamiliar with FreeBSD, the posts on installing FreeBSD and the general introduction of the OS may also be of interest for you.
Exploring FreeBSD (1/3) - a tutorial from the Linux user's perspective
Installing FreeBSD - a tutorial from the Linux user's perspective
FreeBSD - from the Linux user's perspective (introduction)
In the first part we have configured SSH insecurely to allow root login, set up port forwarding in VirtualBox and briefly explored commands as well as 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 irrelevant part to save a bit of space.
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 most secure and stable system available at the time you need to perform updates. As updating is important, let's get right to it!
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 (PNG)
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 (PNG)
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 (PNG)
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-RELEASE__ option we choose to upgrade to that particular release version.
The release upgrade needs a lot of patches and files! (PNG)
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 (PNG)
After the first step of installing the upgrade (kernel), you need to reboot the system, install the userland upgrade and reboot again. A moment later you should be greeted by your new FreeBSD 10.2 system!
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.
Most things are completely self-explanatory. What may however be new to you is the _login class_ concept. Chances are that you won't to mess with need them, but nevertheless it's 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 for example.
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" to root!
"Sorry"? Now what's that? Certainly not a very helpful error message! Well, you just met another peculiarity of FreeBSD: You need to be in 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 again - su let's us switch to root.
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 known as 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 on.
On FreeBSD 8.4 and 9.x the new _pkg-ng_ tool can optionally be used instead. Starting with 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 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 (PNG)
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/master.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 (PNG)
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 KEEP IN 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 instead. 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 (PNG)
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 (PNG)
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/rc.d) or not (in which case you'd have to look in /usr/local/etc/rc.d)!
Taking a look at services (PNG)
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 run _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 here: It's called ntpd.
It won't keep running without the right parameter because my clock difference is large 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? (PNG)
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.conf_ file, FreeBSD keeps reminding you of that fact (which is actually a good thing).
Just as 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 also stop the daemon again using the _service_ command. But to show off the init script way, we'll do it directly this 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 (PNG)
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.
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.
