Ok this is possibly the easiest thing on earth but I didn’t see any clear documentation on the topic apart from a simple text file which actually helped.
The server runs into a FreeBSD jail, I won’t cover this part as there are plenty of good documentation on this matter already.
The first step is obviously to install nsd, for example using pkg:
# pkg install nsd My master DNS server runs BIND so there’s no specifics regarding nsd, here’s the most basic configuration the slave needs:
FreeBSD
A week ago, I’ve migrated my gateway to a standalone machine running FreeBSD 13.1. The whole process was certainly flawless and soon enough it was forwarding packets to and from my network.
Quite happy with the result, I didn’t expect it to crash less than 2 days after its first production hour. At first I thought it could have been the temperature, the graphic card, the memory… until it crashed again a couple of days after and I saw this:
Because I ran gpart bootcode on the wrong partition of every replacement disk I swapped and because my motherboard is incapable of finding an EFI partition, I basically bricked my FreeBSD NAS / gateway.
It took me a ridiculous amount of time in order to find how to boot into an existing ZFS FreeBSD installation from a FreeBSD LiveCD (I used mini-memstick).
Finally, in a 2014 thread from the FreeBSD questions mailing list, someone mentioned the magic invocation, and from there I deducted the remaining parts.
In the past month, it’s the second time I’m being bitten by FreeBSD in the networking field.
First time with my own gateway, I had this weird behaviour where machines on a different VLAN than the main one would use the Internet at full speed but would struggle to make any transfer from the main VLAN.
Turns out this was a tcp segmentation offload issue, which seems to cause so much problems it is disabled by default in some appliances.
Maybe I can’t read, but I have the feeling that official documentations explain every single corner case for a given tool, except the one you will actually need. My today’s struggle: replacing a disk within a FreeBSD ZFS pool.
What? there’s a shitton of docs on this topic! Are you stupid?
I don’t know, maybe. Yet none covered the process in a simple, straight and complete manner. Here’s the story:
It is possible to run FreeBSD on a MacBook Pro from an USB drive. To achieve this, we will first prepare the USB drive from a GNU/Linux machine and make it UEFI friendly:
# apt-get install parted # parted /dev/sdc (parted) mklabel gpt (parted) mkpart ESP fat32 1MiB 513MiB (parted) set 1 boot on (parted) quit From there, install FreeBSD as you would for exmaple using the kvm virtual machine hypervisor on the GNU/Linux machine.
No, I’m not following the hype, only I like to test things plus I feel there will be a growing demand for docker at ${DAYWORK}. I read here and there that CoreOS was the Linux distribution of choice to play with docker, so while at it, I picked up this one to dive into the container world. Finally, I’ve been willing to put my hands on bhyve for quite a while, so I took this opportunity to learn all those new (to me) technologies at once.
At ${DAYJOB} I’m using a FreeBSD workstation for quite a while. Everything goes smoothly except for the filesystem. When I first installed it, I chose UFS because FreeBSD installer said that root-on-ZFS was “experimental”. I later learned that nobody uses UFS anymore and that root-on-ZFS is perfectly stable. Thing is, I chose UFS and I deeply regret it. Not because of ZFS’s features that absolutely do not matter for me on the desktop, but because FreeBSD implementation of UFS is terribly, terribly slow when it comes to manipulate big files.
I came across an annoying behaviour while trying to connect to a remote KVM hypervisor from a FreeBSD GUI. virt-manager failed to connect to the server and showed the following error message:
In short, virt-manager tries to access to /usr/local/var/run/libvirt/libvirt-sock because it is compiled with a /usr/local PREFIX on FreeBSD. Of course they didn’t plan anything on a plain text configuration file. I figured out this has to be configured in GConf, for example using gconf-editor, simply replace:
A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.