Building a FreeBSD desktop doesn’t have to take you several days. It doesn’t even have to take longer than an hour.
Of course, you can take your time and compile your own optimized FreeBSD kernel, specifically for your hardware. And, build everything from source using the ports tree. But, many of you, like me, just want to get a graphical FreeBSD desktop up and running before you bother with all of that.
So, for those of you that aren’t familiar with this method, allow me to show you how to install and configure any popular FreeBSD desktop environment, in under and hour (give or take).
Install the FreeBSD Base System
A FreeBSD desktop typically consists of two main parts. Traditionally, you will have a server and a client. The server is usually referred to as your “display manager”, and the client is usually referred to as a “window manager”. These can be a pain in the ass to configure, by hand, if you don’t have the FreeBSD manual to constantly refer to. And, getting all of the various settings just perfect can be nearly impossible without help or lots of time. So, we’re going to do a generic installation, just to get up and running. We can always optimize our FreeBSD desktop later.
Boot the FreeBSD installer from official media
Go ahead and find the FreeBSD installation media appropriate for your architecture. They should be listed on FreeBSD’s official website. I’ll be working with FreeBSD 12.1-RELEASE and the amd64 architecture, for the purposes on this tutorial. I usually use KVM/libvirt/QEMU for virtualization. But, for the purposes of this blog post, I am going to use Oracle’s VM VirtualBox. If the reasons for that aren’t immediately clear, it’s because it tends to be used more frequently.
That, and I’m slightly certain the KVM/libvirt/QEMU crowd don’t need this tutorial.
From Oracle’s VM VirtualBox dashboard, select New to create a new virtual machine. This virtual machine will host our FreeBSD desktop environment.
After selecting New from the dashboard, VirtualBox should open another window. Here you can name your virtual machine. This is where you set your default hostname. You can change it later, if you want. Select ‘Next’
Then it will ask you how much RAM you want to allocate. I have a large amount of RAM, so I allocated 20GB. I don’t expect you to have that much, nor will you need it. But, you should be generous with your RAM and your desktop environment. These days, I’d say, go ahead and give it 4GB or mroe. But, you can certainly get by with much, much less.
After that, you’ll select the type of virtual disk image you’d like, this is your virtual harddisk. I selected virtual disk image or ‘VDI’. And, I allocated a decent amount of space for the desktop software. You’ll need a bit more, if you decide to compile the desktop from source than if you simply install packages from the binary package repository. So, bare that in mind, when you decide how much space to give your machine.
The type of workstation you want should factor in to how much virtual harddrive space you allocate, as well. So, a more full-featured desktop like Gnome or KDE should be allocated more space than their lightweight desktop counterparts, like XFWM, LXQT, awesome, etc..
I selected dynamically allocated, because my hardware isn’t going to see much of a performance boost from being preallocated. Though, in all cases it would help to be preallocated. Once you’ve finished doing all of that, you should find yourself back at the VirtualBox dashboard.
Configure the base system to install FreeBSD
Once you boot into the installation program, go ahead and select ‘Install’. After that you’ll need to tell it your keymap, if it has not automatically detected it. For a lot of you that’s going to be ‘US’ for United States. Next, it’ll ask you to select a hostname for the base system. And finally, you’ll partition your harddrive and select some default packages to have installed.
Partition your hard drive and select FreeBSD packages
FreeBSD has an amazing file system called ZFS that you should checkout. It’s pretty much better than sex. I highly recommend it. But, again, for the purposes of this video, I’m selecting UFS. UFS is also a great file system. FreeBSD has some amazing technology that is all worth investigating.
I also chose to install FreeBSD onto a single partition, which isn’t exactly recommended, but it’s an option. This was for the sake of ease while writing the article. If you’re a first time user or otherwise can’t be bothered to manage multiple partitions, one partition that takes up your entire virtual disk will be fine for you as well.
For my boot partition I chose Master Boot Record or ‘MBR’, BSD and GPT are also acceptable.
Set FreeBSD’s local root password
It’ll now prompt you to set the password for root. Root is what you think, it’s your superuser account. A notable difference between root on linux and BSD is the ‘wheel’ group. Be sure to select a very strong password for your root account. Any compromise of the superuser account would mean that the entire machine was compromised.
Setup networking for FreeBSD
Now, since I chose a network installation, I am required to setup networking or quit. You may be able to continue without doing so. Hopefully it will detect your network device, most of yours will be built-in. If not, you should attach it before proceeding and see if it will detect it.
As well, most of you will want to select DHCP for a dynamically allocated network. If not, you can punch in your static network settings at this time. For IPv6 enabled networks, your DHCP option is likely called SLAAC. Go ahead and enable that, if you need it.
Next you’ll set the system’s timezone. For me, that’s AmericaNew_York. So, I selected North America, United States and then Eastern (most areas). You should select the appropriate timezone as it applies to your system.
Select FreeBSD boot services and hardening options
Now you’ll select which services to start with FreeBSD at boot time. For my purposes, I chose to enable SSHD for remote shell access and ntpdtime so my clock would synchronize with internet time servers at boot. This is a pretty critical stage. But, for building a workstation, you’ll mostly only need to be sure your time syncs appropriately here.
For the FreeBSD hardening options, you can safely enable them. However, some of the options will make debugging difficult, if you’re a developer. Since this is a daily driver, a workstation or otherwise a desktop. I strongly recommend you disable sendmail, as you should only have a need for local mail and remote logging as you shouldn’t need to access your log files on a remote server. Again, if you can justify leaving them enabled, then go ahead.
I find it very useful to clear /tmp at boot time. This is a performance option that I prefer and recommend.
After that, you’ll create your first user and set a password for that account. And you may proceed to create any other user accounts that you think you might need or want. I chose to add my user to the wheel group. At this point the base installation is finished. You’re going to exit the installer and reboot into the system. So you can start building it. We’re going to dive straight in, so when you get a chance be sure to remove your installation media before rebooting. Reboot. :)
Reboot into FreeBSD and perform a distribution upgrade
If you fail to reboot the installation media, it will you boot your back into the installer. It’s okay for that to happen. Just be sure to remove the media at that time and hit CTRL-ALT-DELETE to reboot again. Then select Multi-User at the boot options screen and login with your ‘root’ account to prepare the system for it’s desktop environment.
We have a few small configuration changes to make manually. Actually, for our purposes of getting into a desktop early. We’re just going to install the packages we need to function, make sure the system is up-to-date and configure them..
One you’re logged in, run the following two commands to check for core FreeBSD system updates, download and install them. In the case that you did have available updates to install, follow the instructions on screen and reboot.
freebsd-update fetch && freebsd-update install
Install sudo and FreeBSD’s desktop-installer
pkg install sudo desktop-installer
Now, I kind of let it correct me here. Because, it’ll ask to update your binary package repository for you, when you ask for it to install the first package. You’ll want to accept that, so you have the latest version of the desktop-installer script.
Once that’s complete, edit the ‘/usr/local/etc/sudoers’ file and add the user you created to sudoers. This way, when you’re logged into the desktop shortly, you can login as your user and sudo to root to configure to configure the system or install other desired packages.
If you’re unsure how to add your user account to sudoers, open ‘/usr/local/etc/sudoers’ by typing ‘edit /usr/local/etc/sudoes’, searching for the uncommented like that reads ‘root ALL=(ALL) ALL’ and below it add ‘<your username> ALL=(ALL) NOPASSWD: ALL’
This will enable that user account to use the sudo command and run commands as rootl
After that, run the desktop-installer to begin install your FreeBSD daily desktop workstation.
FreeBSD’s desktop-installer script works very well!
Now, most of this script should be self-explanatory and it actually doesn’t take that long to run (depending on your FreeBSD workstation’s specifications. But, I’ll walk with you through it anyway. Because, perhaps you’re not familiar with “BSDisms”.
Right away, it asks us if you want to install and configure a firewall. As a workstation this is a big yes. It’ll warn you that changing your firewall settings runs the risk of disconnecting your SSH session. Really, this is rarely the case, unless your keep-alive is about to time out or something, between reading here and acting there. The danger would be more along the lines of if you get disconnected. So, if you happen to close the SSH port, or if you’re unsure, be sure to make sure your SSH port is not blocked before you disconnect.
Finally, it should ask if you want to update to the latest and greatest binaries/ports tree or use the quarterly snapshot release. We want the latest and greatest. For one, we want our desktop-installer script to be as current as possible, so that if there’s any quirks in hardware drivers that have been patched, we get the fixes. But, for second, generally we want the latest and greatest on FreeBSD. May the daemon be with you and give you the power to serve! ;)
You can choose either, but when it asks how you’d like to update your copy of the repository, I prefer ‘portsnap’.
Desktop-installer for FreeBSD: Round 2
Once the repository finishes updating, the desktop-installer script will restart. It can take a while, FreeBSD developers release early and often. So, now it should remember our selections and we can jump right through to selecting a desktop environment to work with.
For firewall type, I chose option 5 (protect this machine only using stateful rules). This is likely the option you want, but, as always, if your goals are different from mine, choose the option most appropriate. Take this moment, if you have another machine to verify that your SSH port is still going to be open, if you fear that it has closed. That is, if you are installing over SSH, I mean.
Next it’ll prompt if you want to update. Fuck yeah, you definitely do. Go ahead and agree to that and it’ll restart. This should be the last restart before we’re booting into a desktop. :)
It’s time, finally installing a desktop environment for FreeBSD
When you boot back up, you can run the desktop-installer script for the final time. It will have remembered your earlier selections, but you should still pay close attention to be sure nothing has gone wrong. Remember, again, that when you reach the point of updating your repository to be current instead of quarterly, you should select ‘no’ or else you’ll be back in that loop.
I actually chose KDE this time, just to see if it would successfully pull down my preferred desktop. Generally, when I’m at this stage of a configuration, I go with a smaller desktop environment, just to get up and running quickly. And, the lattest is what I recommend to you.
LXQT, MATE, XFCE4, Lumina, IceWM, WindowMaker and fluxbox are all such options. Among them I favor MATE and LXQT, depending on whether I want GTK or QT respectively.
Fast and easy, proper FreeBSD workstation setup
And there you have it. A proper, fast and easy FreeBSD desktop deployment. Enjoy!
Ever need to upgrade FreeBSD to the next release? It’s not hard! We can compile kernels some other day. Today, we’re just going to do binaries. Quick and easy, FreeBSD is the best.
Go ahead and log in to your machine, elevate yourself up to root (or use sudo). Lets get this show on the road: freebsd-update fetch
freebsd-update fetch & freebsd-update install
freebsd-update fetch && freebsd-update install
This process is not hands off. So, you’ll need to accept a few prompts. Generally, this is the only time you’ll really have to reboot FreeBSD, if you’ve been treating it well. But, in this case, I don’t run into the need for that (heh).
Once the update tool finishes grabbing all of the patches and applying them. We’ll need to update the pkg tool. The pkg tools is used to maintain binary packages on the system. If you’re a sane person, you either use pkg or the ports tree. The sanest people build binary packages from ports and keep a local repository, but that’s for another article.
Upgrading Binary Packages on FreeBSD
This tool keeps things as simple as they can be. So, if you’re familiar with POSIX compliant systems, you’ll recognize this process. Let’s continue to upgrade FreeBSD 11 to FreeBSD 12.
Use the static pkg binary to update the tool and then all of the installed packages. Again, I’m just going to go ahead and bang it one in one line. Any time you see me use &&, you can safely break the command into two commands, if you want. It is two commands anyway, just on one line.
pkg-static upgrade pkg && pkg upgrade
Yeah, that’s a lot of packages. Let’s make sure we’re on the latest FreeBSD 11 release, which should be FreeBSD 11.3
Completing the Upgrade FreeBSD Process
Good. Now we can get back to upgrading the kernel to the next major release. Time’s running out for security updates for 11.3 and we don’t want to still be around, once it does. Back to the freebsd-update tool
freebsd-update upgrade -r 12.0-RELEASE
This one will take a while. It should inspect your system and ask you if you agree with what it has found, then it should go grab a matching FreeBSD 12 image to apply on top. Now we will need to reboot. But, take a walk, if you want, make a sandwich or whatever.
We’re almost done. We need to check some things and that’s about it after this. You can e-mail me if you want me to do any of these things for you. Please do not forget that. It’s how I put food on the table.
Next Time Don’t Wait So Long to Upgrade FreeBSD!
You guessed it! We’re going to go ahead and apply all of those, oh so many, packages. Run freebsd-update install
It goes fast than you’d think. And, since we’ve finished patching away from FreeBSD 12. We now need to reboot and finish the final details of this FreeBSD version upgrade.
Congratulations! See how easy that was? I really love FreeBSD!
Apparently it wants us to run freebsd-update install three times, this time. If you compiled packages from ports. You’ll absolutely need to do this. And, if you didn’t, you’ll want to do this anyway because it removes a bunch of file lint that you’d otherwise have to do yourself.
Either way, welcome to FreeBSD 12.0-RELEASE!
The hackers at Gray Hat Freelancing are here to help you with any project you have that’s IT related. Tell me what you want to do and I’ll tell you how I can help you achieve that end. Have a good one!
I’m going to walk you through a WordPress deployment, using only the terminal. This is mostly because I need to put some content up here. And, once upon a time, this used to be one of my staple articles. Nothing has changed, really. But, I will reiterate the fact that you really should know how to do things manually, because you start plowing ahead and automating them.
Automation is good, it’s absolutely necessary, even. But, when things break, it’s best that you’re able to figure it out how it happened. And, the easiest way to obtain that information is, sadly, the hard way.
WordPress being so evolved.. Please do not expect a WordPress deploy to be something you can’t handle. Deploying WordPress is very straightforward. So, let’s get started.
LAMP: Linux, Apache, MySQL and PHP
WordPress runs very well on almost any web server. But, for the purposes of sticking to the documentation, we’re going to use Apache (not that I always stick to the documentation, mind you). You should familiarize yourself with a “LAMP” deployment anyway, it’s pretty much what powers the entire internet. Please note that MySQL is often replaced with either MariaDB or Percona Server. I won’t go into the differences here.
Go ahead and SSH into your web server, update your software repository and do a full system upgrade. There’s no reason to deploy LAMP without the latest patches. I’m using debian, so your commands may be slightly different for these types of things. Refer to your distributions handbook, if you need to.
Hah! Before, that required us grabbing a whole lot more packages than it does these days. But, don’t worry! We will still need to go get various PHP libraries for our WordPress deploy to be successful (specifically, for it to interact with mariadb). Still, you don’t need to do anything else there on Debian, unless Apache was previously configured with libapache2-mod-php. Then go ahead and issue the following (unexplained):
sudo a2dismod php
sudo a2dismod mpm_prefork
sudo a2enconf php7.3-fpm (at time of writing, 7.3 was stable)
sudo a2enmod mpm_event fcgid cgi proxy_fcgi setenvif rewrite
There’s plenty of other Apache modules that are beneficial for WordPress, but we’re just doing a deploy right now.
Prepare MariaDB for Production
I’m pretty sure that we all knew MySQL shipped with insecure defaults for many years. So, I have no idea, why this tradition has carried through to MariaDB. But, it’s my opinion, that we should damn not be having to still do this bit here. But, set a root password for the SQL db. And, disable remote access. Run ‘mysql_secure_installation’, press Y to everything and set a password.
Install the Minimum PHP Requirements
As I just said about Apache, there’s also plenty of PHP libraries that will benefit WordPress, but they’re beyond the scope of this walk through. So, we’re only going to grab what WordPress requires to install without complaint, as well as what is required to return a green health check.
I, honestly, don’t know what to tell you about PHP modules. Depending on your linux distribution, your PHP package is going to come with different modules. There’s really no telling what was bundled with it and what wasn’t. If you’re on Debian, this will get WordPress up and running, at least. But, on others, the packages will be named differently anyway. So, try to reach this minimum.
WordPress Deployed from Terminal
On Debian, Apache’s default “webroot” is in /var/www/html . Your “webroot” may be in a different location. If you don’t know, check your Apache configuration. It should be located in /etc/apache2 or /etc/httpd – The filename would either be apache2.conf or httpd.conf
Anyway, back to manually WordPress deploying from the terminal. I’ll have to clean this up later. But, for now, I’ll just finish what I started. Jump on over to webroot, grab the latest version from wordpress.org and extract it. All that’s left after that is to create a user for “MySQL”, set permissions and run the installer.
Note: this next part you can ignore. What I am doing is deleting my webroot and moving the folder wordpress extracted to in place of my webroot.If you extracted wordpress into ./html/ then you don’t need to do this.
rm -rf ./html/
mv ./wordpress/ ./html/
Create a MySQL Database, a MySQL User, Marry Them
Now we need to create a MySQL database. Create a MySQL user and grant it privileges to write to the database. Then, fix the file permissions and we’re done with the terminal (the website is technically up, a that point.
mysql -u root -p (perhaps prefix with sudo, if you're not root)
mysql> create database wordpress;
mysql> grant all privileges on wordpress.* to 'wordpress'@localhost identified by 'p@ssword';
mysql> flush privileges;
Let’s set some privileges, first give the user that runs Apache ownership of the files. Then set the directories to read/write, read/write by Apache’s user and group. Finally, give the files read/write to Apache’s user and read/execute to everyone else (since php-fpm needs to read and run them).
At this point, we really need to bust out our browser and complete the install, so we can prevent about a billion zombies from hammering away at our install script and owning the box (just log password attempts on WordPress for a week and you’ll see what I mean). So get your browser out and finish this bitch off! You’re done.
Good luck. Have fun! And, next map. If you’d like this handled for you, drop me a line at Gray Hat Freelancing!
FIN – Our Job Here is Done
There’s plenty more to do. Especially from a security standpoint. I can tell you right now, our file permissions are decent but not perfect. There’s optimizations that need to be made or your blog could become a zombie in a DDoS, etc.. But, those are for another article. For now, enjoy the WordPress deploy!