Last week, I ordered a dedicated Hetzner server. One click, 28 EUR less
and a couple of minutes later, it was waiting for my commands. Hetzner
servers come with a rescue system that you can enable via the web
interface. After a reboot you can then ssh
into the rescue system to
perform the installation remotely. Unluckily, they do not officially
support DragonFly. Despite this annoying fact, my new Hetzner server now
runs happily the most recent version of DragonFly. If you want to know
how, keep on reading.
Install instructions
To enter the rescue system, you first have to enable it in the web
interface. It then shows you a password. Remember this password, as you
need it to log in via ssh
. I think you have to manually reset the
server, so that it enters the rescue system. Of course this can also be
done from the web interface. You can now log in to the rescue system
with a simple ssh root@your-server-ip
followed by entering the
remembered password.
To install DragonFly on that server we basically have to solve two problems:
How can we boot from the DragonFly installer image?
If we manage to boot the DragonFly installer image, how can we gain access to the console to proceed with the interactive installation?
But before we solve these two problems, the first thing I want to do is
to get a bit more information about the server’s hardware. So we select
the Linux rescue system (the FreeBSD rescue system did not work or more
likely I was just too impatient), reboot and then log in via ssh. Then,
on the console of the Linux rescue system, lspci
tells us that this
server has a Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI
Express Gigabit Ethernet Controller (rev 06) ethernet controller. This
controller is supported by DragonFly’s re(4)
device as we can quickly
verify by looking up the DragonFly man page. This is all we need to
know.
Creating a custom DragonFly installer image usable for remote installation
Let’s tackle the second problem first. The approach I have taken
requires us to build a new installer image using nrelease(7)
. The
alternative would have been to use a pre-existing installer image, mount
it (using vnconfig
…) to then update the relevant files directly on
the mounted installer image. The approach I explain below is a little
bit more complex and requires a DragonFly system already installed
somewhere. On that DragonFly system we perform the following steps (all
as root
):
Check out the source tree:
cd /usr && make src-create-shallow
For building the release image I think we also need dports:
cd /usr && make dports-create-shallow
Then we have to slightly extend the installer configuration, so that it will use DHCP for the
re0
ethernet device and will start up withsshd
. To accomplish that, we add two lines to the installerrc.conf
:echo 'ifconfig_re0="DHCP"' >> /usr/src/nrelease/root/etc/rc.conf echo 'sshd_enable="YES"' >> /usr/src/nrelease/root/etc/rc.conf
We further need to allow remote logins for the root user by copying our public SSH key which is usually stored in
$HOME/.ssh/id_rsa.pub
to the root user’sauthorized_keys
file:mkdir /usr/src/nrelease/root/root/.ssh chmod 700 /usr/src/nrelease/root/root/.ssh cat $HOME/.ssh/id_rsa.pub > /usr/src/nrelease/root/root/.ssh/authorized_keys
Then we are ready to start building the installer image. In doubt, or for more information, read the
nrelease(7)
man page.cd /usr/src/nrelease && make img
After the build has finished, the new installer image can be found in
/usr/ob/release/dfly.img
.
Booting from the installer image
Now let’s tackle the first problem. I solved it by copying the created
installer image to my server, where I made it publicly available via
HTTPS for a short period of time (it might be still there :). Of course
I bzip2
‘ed the file before, as that image is rather large otherwise.
So let’s assume this new image is accessible as
https://www.ntecs.de/dfly.img.bz2
.
Back on the Linux rescue system, we just have to copy that image to the disk and reboot. I did that with:
wget https://www.ntecs.de/dfly.img.bz2 -O - | bzcat | dd of=/dev/sda
Now reboot. Wait, hope, and wait a bit longer, as we forgot to change
the autoboot_delay="10"
in /boot/loader.conf
to some lower value.
But, finally I could connect with ssh root@my-server-ip
to the
DragonFly installer image running on the Hetzner server. And from there
I followed the normal installation path. Note that the server has two
hard disks, so I installed DragonFly onto the second disk first. It’s
important not to forget to update the boot blocks of the first disk (the
installer will ask you for that), otherwise it will continue to boot
from the first disk which still contains the installer image. This can
be quite tricky to notice, as both systems look very similar. Luckily,
the installer also copied the /etc/rc.conf
and our authorized_keys
file to the new installation so that we can log in immediatly as root
via ssh. As I did not liked it to be installed on the second disk, I
performed a second installation from the second disk to the first disk.
But that’s rather cosmetic.
Conclusion
I am sure there is a simpler approach, but this is how it worked for me. A similar approach would probably work for other providers as well. In case I develop a growing demand for Hetzner servers in the future, a script that automates all of the above mentioned steps would be nice to have.