Category Archives: FreeBSD

How I learned to stop worrying and love the powderkeg. #FreeBSD

FreeBSD has grown up a lot in this release cycle.  The most useful tool from the 10.0/11.0 world in a long time, poudriere (powder keg in French) has made my ports usage almost trivial now.

More or less, poudriere is a tool that allows you to build ports packages compatible with the new PKGNG format without contaminating your working system.  It uses a series of jails and build environments to do what a lot of more savvy FreeBSD developers and engineers have been doing for years.

Even using portmaster to maintain my systems seems archaic in comparison, not to mention error prone.  More or less, my 3 or 4 systems have been converted to use themselves as a repository for packages and they build their own packages.  This is a bit redundant to be honest, and it makes the most sense to use one host as a repository and have your other machines pull in packages from it.  My implementation is due to running 11-current and being having machines I control on very different and restrictive networks.

poudriere setup for 11-current (head builds)

Start by install poudriere from ports or a package that you can get your hands on.  Then command poudriere to setup its basejail on FreeBSD SVN HEAD:

poudriere jail -c -j 11-amd64 -v head -a amd64 -m svn

This will create a jail on your local machine based on SVN head at the time of execution (yes, its going to compile everything from source and will take a while, get a cup of coffee, perhaps a sandwich).  The thing is, your machine is still available for other things while this is going on.  You are not going to crash X or other applications while this is happening.  Its building a separate jail for the purpose of creating packages.

Once its build, you can update your jail world trivially via:

poudriere jail -u -j 11-amd64

Now, grab the ports tree via:

poudriere ports -c

Updates to your ports tree via portsnap are easy with a :

poudriere ports -u

At this point, you are ready to configure poudriere to build your package via the “bulk” command.  I copied /usr/local/etc/poudriere.conf.sample to /usr/local/etc/poudriere.conf and made exactly one change to the default settings.  I use ZFS ( which I highly recommend, see my post on the Bacon of Filesystems ) and my ZPOOL is a different name than the default.

Creating your list of ports for your builds is a trial and error endeavor to be honest.  I suspect, there are easier ways to do it, but I determined my list below based on the list I had installed already and some questions to various mailing lists.  I created a /usr/local/etc/myports file with the following in it as a list of ports that I want built.  Poudriere will build all required dependencies for me, build-time and run-time and create nice little packages for me.


At this point, I was read to do the build run via:

poudriere bulk -f /usr/local/etc/myports -j 11-amd64

This builds all the things for me, caching packages when needed for reuse.  Very handy for me to be honest.

Setting up the pkg repo couldn’t be simpler either.  I copied /usr/local/etc/pkg.conf.sample to /usr/local/etc/pkg.conf and made a single change to point the system to use the locally build packages in a locally generated repo:

PACKAGESITE        : file:///usr/local/poudriere/data/packages/11-amd64-default

The final step was to initialize my repository via:

pkg repo /usr/local/poudriere/data/packages/11-amd64-default

I then updated my system via the newly built packages:

pkg update

pkg upgrade -f

This refreshed all the packages on my system with ones that are cleanly built by poudriere.  This allowed me to now audit what I had installed and to see what I could remove or what else I needed to have built:

pkg version -R

Anything with a “=” means that it comes from the repository and is up to date.  Anything with a “?” means it comes from an unknown source.   I learned I had a lot of dependencies installed for builds that I didn’t need for runtime cases:

pkg autoremove

Many, many, many thanks to the FreeBSD portmgr team ([email protected]), Baptiste Daroussin, Bryan Drewery and the others who have deadlifted the FreeBSD ports system into the future. Now I can look at whats left and I have never been more content with FreeBSD ports.  *boom*

*edit* reference to poudriere official docs and such:

*edit* after pkg-1.2.1 release.

The pkg.conf config and locations have moved around and become incompatible with this blog post.  You’ll want to do two things if you are using this as a guide for updates:

1.  Disable the FreeBSD repo configuration in /etc/pkg/FreeBSD.conf

2. Move your local repo config to /etc/pkg/my_repo.conf and give it the following syntax:

me: {
url: file:///usr/local/poudriere/data/packages/11-amd64-default,
signature_type: none,
enabled: yes

The Ports Management Team 2013-11-01 03:43:05

The FreeBSD Ports Management team is pleased to announce a pilot project
called portmgr-lurkers@.  Over the course of the next two years, volunteers
from our group of ports committers will participate in portmgr@ activites
by being added to our mailing list.

At four month intervals, two committers at a time will be brought in to
work on various projects and learn the inner workings of the team.

The first two -lurkers will start on November 1, 2013. They are Mathieu
Arnold (mat@) and Antoine Brodin (antoine@).

The Ports Management Team 2013-10-31 12:55:52

We are pleased to announce that official binary packages are now
available for pkg, the next generation package management tool for FreeBSD.

Pkg allows you to either use ports with portmaster/portupgrade or to
have binary remote packages without ports.

We have binary packages available for i386 and amd64 on
8.3,8.4,9.1,9.2,10.0 and 11 (head).

More at

The Ports Management Team 2013-10-29 04:10:42

In our ongoing series on getting to know your portmgr@, we talk to Bernhard Frölich, the one who brought us


Bernhard Frölich

Committer name 


Inspiration for your IRC nick

decke == blanket in German, mascot: /dev/blanket from ThinkGeek

TLD of origin 

AT (Austria)


Software developer (logistics, fully automated warehouses)

When did you join portmgr@



Inspiration for using FreeBSD

As a software developer I always liked the simplicity and straight
forward way of solving problems.

Who was your first contact in FreeBSD

miwi – high quality automated PR and commit bot

Who was your mentor(s)

miwi, beat

What was your most embarrassing moment in FreeBSD

About two years ago we had an X11 update and my laptop started to
become unuseable on the docking station because the mouse cursor and
X11 windows kept failing in very strange ways. Everything was working
fine when working on the built in laptop display but when docked with
USB mouse it was catastrophic. This situation lasted for a few months
until kdm@ fixed a bug in HAL that turned out to be the cause of this

Boxers / Briefs / other


What is your role in your circle of friends

Don’t have a role. It’s just me.

vi(m) / emacs / other

vi, eclipse

What keeps you motivated in FreeBSD

The FreeBSD community and all the people working on FreeBSD with such
an enthusiasm.

Favourite musician/band

Kosheen, Lamb, Zero 7

What book do you have on your bedside table

Papa To Go

coffee / tea / other

Jasmine Tea (Dragon Pearl)

Do you have a guilty pleasure

I’ve outsourced a lot of stuff to Google services (GMail, Google Apps,
AppEngine, …)

How would you describe yourself

always busy, sometimes grumpy, never too late

sendmail / postfix / other


Favourite webserver


Favourite alcoholic drink

Magners (Irish Cider)

Do you have a hobby outside of FreeBSD

All the usual technical and geek stuff. Not really a hobby but I really enjoy a great barbecue in summer.

What is your favourite TV show

Star Trek: Voyager, Top Gear, The Big Bang Theory, Psych

Claim to Fame

  • helped porting and maintaining VirtualBox for FreeBSD since the beginning
  • creator of and QAT

What did you have for breakfast today


What sports team do you support


What else do you do in the world of FreeBSD

I am also interested in DVB multimedia applications for FreeBSD which
is why I maintain mythtv and recently ported tvheadend to FreeBSD
besides the XBMC PVR addons.

What can you tell us about yourself that most people don’t know

I’m about to become father about the time this is published and I
expect that my little girl will consume all my spare time for quite a

Any parting words you want to share

So Long, and Thanks for All the Fish!

What is your .sig at the moment

Bernhard Fröhlich


The Ports Management Team 2013-10-21 16:15:27

This is the start of an ongoing series profiling members of the FreeBSD Ports Management Team.  In this interview, we talk to longest serving member of the team, Joe Marcus Clarke, aka marcus@


Joe Marcus Clarke

Committer name


Inspiration for your IRC nick

Longish story. Marcus is not my middle name. It’s Michael. When I was
seven, I came up with the nickname myself. I thought it sounded cool.
And there you go.

TLD of origin



Distinguished Services Engineer at Cisco Systems

When did you join portmgr@

Damn, I don’t remember. My email dates
back to 2006, but I think it was before that…



Inspiration for using FreeBSD

Another longish story. I was in college at University of Miami (go
Canes!), and I managed to procure an old x86 PC. We were going to
install Linux on it. I thought having a csh in my own dorm room was
just awesome. A friend ran into my room and said I needed to check out
this thing called, “FreeBSD.” Sure, what the hell. A few days and
about 50 floppy disks later, I was sold. I never looked back.

Who was your first contact in FreeBSD

sobomax (Maxim Sobolev)

Who was your mentor(s)


What was your most embarrassing moment in FreeBSD

Probably the first time I broke INDEX, or my first release song, “Ports
Freeze Baby.”

Boxers / Briefs / other


What is your role in your circle of friends

What are friends?

vi(m) / emacs / other

VIM (what is this “emacs” thing you speak of?)

What keeps you motivated in FreeBSD

I really believe it is the best operating system around. I advocate it
passionately at work (to the point people thought I got paid to say,
“FreeBSD”). I look for any chance to install it. I love it when people
run network tests to my servers at work and comment how amazing the IP
stack is… :-)

Favourite musician/band

I like a lot of musical types, but I’m particular to metal. I’m into
Five Finger Death Punch now.

What book do you have on your bedside table

Print is dead. But I’m reading up on Python online now. when is
Stackoverflow going to publish a book?

coffee / tea / other : Diet Pepsi

Do you have a guilty pleasure

Call of Duty

How would you describe yourself


sendmail / postfix / other


Do you have a hobby outside of FreeBSD

I’m learning to be a pilot.

What is your favourite TV show

I loved House. I thought it was the closest thing on TV to be a network
troubleshooter. Right now, I’m big into Strike Back.

Claim to Fame

Tinderbox, I guess

What did you have for breakfast today

I only eat once per day. Usually at night.

What sports team do you support

University of Miami Hurricanes and Manchester United

What else do you do in the world of FreeBSD

GNOME, Netatalk, wireshark, Tinderbox, and a lot of local sysadmin stuff.

What can you tell us about yourself that most people don’t know

My North Carolina license plate reads, “FREEBSD”.

Any parting words you want to share

What am I, your priest?

What is your .sig at the moment

It’s lame. Don’t ask :-)

Apache 2.2 and Perfect Forward Secrecy (PFS)

Update: apparently (I haven't tested it yet), Apache 2.2.26 finally supports ECDH cipher suites! The remainder of this blog post is not as usable any more and you can simply use some common SSLCipherSuite lines.

Using modern Perfect Forward Secrecy (PFS) cipher suites with #Apache 2.2 and #OpenSSL is not really possible in the general case. The best you can do is enable some DHE suites instead of the faster #ECDHE variants - for those you will need Apache 2.4.


So, FreeBSD on the AR9344? What happened?

I committed a bunch of code a while ago to FreeBSD-HEAD to at least start booting on the AR934x SoCs. The AR934x SoC is a MIPS74k core - a dual-issue superscalar 11-stage pipeline MIPS32r2 CPU. It's slightly different to the existing MIPS24k stuff (which is a single 8-stage pipeline.)

So - first step - it booted up a little, then hit a machine check. At that point the FreeBSD MIPS peeps believed there was hilarity in the TLB exception handling code, so we put it to sleep for a while and I went back to real work.

Then a few weeks ago I decided to finish it off. I brought my developer board to Eurobsdcon in Malta and sat down with Warner Losh, who also has said developer board. We spent a bunch of time going over the TLB code and realised that FreeBSD's instruction/execution hazards are all.. just wrong. Then, on a whim, I read up some more about MIPS32r2 and superscalar stuff and discovered that the correct hazard instruction isn't NOPs or SSNOPs - it's EHB (execution hazard barrier.) It's 'SLL $0, $0, 3' in MIPS parlance which on older CPUs is just a NOP (since register 0 is always 'zero'.) So, this fixed the TLB management and the boot proceeded quite a bit further.

Next - bringing up ethernet and the switch PHY. I was seeing totally crappy and invalid register values when reading/writing the attached switch chips. Even probing didn't work reliably - in fact, I got to the point where I was reading the value I'd expect from the previous register read. So, I wondered if this was another out-of-order behaviour from the MIPS74k superscalar architecture.

After digging into the MIPS bus space code, I found two things:

  1. The MIPS driver(s) don't call bus barrier functions at all - so there's no driver enforced access ordering. It was all assuming that the CPU doesn't re-order things; and
  2. The bus barrier code for MIPS was a no-op. It just plainly wasn't defined.
So, I added read/write memory barriers to the MIPS bus barrier routines and I modified the ethernet driver to use barriers. For good measure, I also added barriers to the SPI driver code as that also has a bunch of register accesses that require ordering.

And with that, the switch PHY probe/attached fine, the SPI driver worked fine and the device started booting userland off of SPI connected NOR flash.

Then, it hung. I dug into that a bit and wondered what the hell was going on. Then after a day of poking, I discovered that the interrupt acknowledgement was not working. It's a quirky thing that I should really fix in the atheros platform support - the AR71xx chips don't require the CPU peripheral interrupts to be ack'ed (eg the uart) but later chips do. I added the AR934x to the list of SoCs that need interrupts to be ack'ed and the system kept booting, all the way to userland.

Next - I haven't yet written the AR8327 support but I started fleshing out the AR934x on-board switch support. I got it probing, attaching.. but not passing any traffic. After more digging, I realised my mistake - I was writing some registers incorrectly. I would mask out the right bits to set, but then I'd always set bit 0. Sigh. So, that came up and things worked.

Then I decided to do the wifi part. This was pretty damned simple. The HAL from Qualcomm Atheros already has support for the AR934x in it and I had already modified it to work for the AR933x SoC (which just required me to 'teach' it the FreeBSD way of exposing the calibration/configuration data from on-board flash.) So, all I had to do was this:

  1. Add the device to the kernel configuration;
  2. Add a hint pointing out where the device is mapped in IO space;
  3. Add a hint pointing out where the calibration data is in the NOR flash;
  4. Reboot.
That's it. No weeks of merging code in from Linux or the internal Qualcomm Atheros driver into the FreeBSD driver. No real debugging required. Just enable it, point it at the right place in memory/flash and .. boot it. I think this again vindicates my efforts to open source the Qualcomm Atheros HAL - I just inherit this working code for free. I don't have to try and merge it into anything.

So, I have a port that's dirty and working. There's a lot of infrastructure changes I need to commit before I can commit this port - lots of new clocking options (there's now variations on the clock rate that the MDIO bus (the MII bus connecting the ethernet port(s) to a PHY or switch), there's lots of new configuration options for how the on-chip ethernet port(s) map to external ports and a bunch of other ancillary stuff that's not really worth mentioning. But it's going to show up in FreeBSD-HEAD soon.

Remko Lodder » FreeBSD 2013-10-09 06:48:09


Tarsnap is an advanced online-backup facility, entirely encrypted. The only copy of the keys used to encrypt and decrypt archives are in your own possession, so things that should be kept safe, are (in the current form) safe. Tarsnap makes extensive use of the Amazon EC2 and Amazon S3 for storage.

Tarsnap is originally written by the FreeBSD Security Officer Emiritus’ Colin Percival, on topics that he periodic gives talks about at various conferences. If you are able, you should seriously attend one of those talks


Recently I rewrote a tarsnap backup script from Tim Bishop to a more suitable script for us.

Tim backups his data via Tarsnap, all via the same way. That works well for him, but for our hosting company that is more tricky. We do not want to keep large amounts of data for our customers (which tend to change rapidly, for example emails that come in and go out and get deleted etc.). Instead we want to keep the minimal amount of data for these customers, and we want to offer them more advanced backup strategies for which we calculate an increased price (the minimal backup strategy is free).

After collaborating, we decided that next to the free strategy, we would like to offer a medium-term backup strategy, and a maximum-term backup strategy, where the former is a month of backups (7 weekdays, 4 weeks), and the latter is three months of backups (7 weekdays, 4 weeks, 3 months), so that going back in time is doable. If customers want to have a customized strategy, that would ofcourse be possible if we add that to the script.

Since we are keen on open source we would like to offer you the option to download the script, and if possible even enhance it more so that we can all benefit from it. Do note that we didn’t try to complicate the script, but instead keeping it as simple as possible. That means that we add more lines then likely needed, but it is very readable. One comment from Colin we got so far is that Tarsnap is capable of removing more files in one go (tarsnap -d -f -f ) and that is not yet implemented in the script. We will consider doing so.. ofcourse :-)

The script can be found here, tarsnap.script.

Updated the script with the update from Tim, this had been tested and works fine for us so far. Thanks Tim ! I shamelessly used the code in our code ;-)

The Ports Management Team 2013-10-03 14:05:32

For the sake of being able to have clean working binary packages, pkgng has had to use a dirty hack: origin is used has an identifier instead of the package name.

Why: How to determine than ImageMagick-nox11 and ImageMagick are the same package? and if I don’t know they are the same package how to upgrade them properly? same goes how the package manager can know that mysql-client-5.2.1 is not an upgrade of mysql-client-5.0.1?

How can pkgng determine which subversion is the right version to use: ‘pkg install subversion’ will propose all possible subversion, in that case the higher version is probably the default version, but in perl case, the higher version is probably not the one you want.

Some packages are totally different project but have the same package name… How can pkgng differenciate them?

So please stop using LATEST_LINK to differenciate the different port but directly make _unique_ package names, pkgng will switch back to package name as soon as possible (that will also solve the ugly and stupid pkg set -o).

There is multiple possibility to make sure to properly handle multiple versions of packages:

  1. suffix everything with part of the version (like tcl)
  2. suffix everything but the default with part of the version
  3. have only 2 or 3 different version: project-legacy project project-devel

Please stop renaming the packages based on options! Options are now registered with the package with both pkgng and pkg_install, please stop adding suffix base on options!

Think about the end user, he will try to install a package, it should be as transparent for him as possible.

I is really important to change that as quick as possible. This page on the wiki reference all the port with conflicting names.

The Ports Management Team 2013-10-03 14:05:12

You may has notice that staging has hit the ports tree, staging is something really important, all packages system are using that feature for eons, sometime called DESTDIR sometime called FAKEDIR.

Staging is consistent in adding a new step while building packages: install everything into ${STAGEDIR}. Then we can directly create packages out of that directory without having to install into /. What the implementation does is:

With pkg_install (legacy package tools):

  • Create a package from the stage directory
  • Install that package.

With pkgng:

  • Create a package from that stage directory


  • Install to / (pkgng can consider the stage directory as if it is a package)

What it means is, that it is the end of the bad plist, only things in plist are really installed, this is the end of the broken packages that break the system because they fail in the middle of make install as a package will only be installed once we are sure the build process properly pass.

It allows right now to build and create a package without the need to be root.
It gives us new targets:

  • make makeplist (to create the pkg-plist)
  • make check-orphans (to print what is in the stage directory but not in pkg-plist)

It reduces code duplication: in the end the installation is being done via a package installation meaning that PKG-MESSAGE is automatically printed, all pre/post installation scripts are executed.

It reduces patches: no need anymore to patch upstream Makefiles to avoid installing the DOCS just do not list them in pkg-plist or conditionnaly list them in the pkg-plist.

This also allows lots of new features to come:

  • Allow to create sub-packages
  • Allow to create debuginfo packages
  • Allow to do a lot of sanity check in the staging area to improve our QA

To convert your ports refer to:

Along with stage you have noticed that MAN* and MLINKS has gone, and now all the manpages should be added to the plist. BTW MANCOMPRESSED is also not necessary now.

There is 3 reason behind making it go and not being replaced:

  1. The initial goal of those macros was to be able to compress the right manpages and to handle the different hardlinks/symlinks between those pages. Because it was directly installed in / rather than using a stage directory, it was necessary to at a point list them. and to properly track the different links in MLINKS (which wasn’t done properly in most ports btw :) ). With stage, we have a new compress-man which does it properly on its own without the need to get the list of the manpages, without the need of an explicit declaration of the links. This syntax to handle localized man pages was also terrific :) and if you have a port mixing manpages in “non regular” and “regular” localtion, it was totally messing
  2. Consistency, a port is basically: some metadata, a plist and some operations to perform. for metadata all metadata are in the Makefile, all operations are in the Makefile but plist can be a mix of pkg-plist and Makefile, this is inconsistent, it makes sometime hard to figure out why a file has been added to the plist etc. Also this makes us having tons of targets define to handle those extras entries and results in highly inefficient make(1) usage.
  3. Stage is also a first step to go to sub-packages, sub-packages will basically be: 1 port able to produce N packages, to be able to do this we will use multiple plist, having the files properly defined already in plist will help that. Having files defined in macros on Makefile will make it hard todetermine which one should go in which plist.

Last thing I would like to add about it: I don’t see the difference personnaly between listing N lines of manpages into Makefile MAN* macros where btw you have to manually define the categories where to put them and adding those N lines
directly into the plist where make makeplist and/or make check-orphans can help you getting the exact lines automatically?

DNS in FreeBSD 10

Yesterday, I wrote about the local caching resolver we now have in FreeBSD 10. I’ve fielded quite a few questions about it (in email and on IRC), and I realized that although this has been discussed and planned for a long time, most people outside the 50 or so developers who attended one or both of the last two Cambridge summits (201208 and 201308) were not aware of it, and may not understand the motivation.

There are two parts to this. The first is that BIND is a support headache with frequent security advisories and a lifecycle that aligns poorly with our release schedule, so we end up having to support FreeBSD releases containing a discontinued version of BIND. The second part is the rapidly increasing adoption of DNSSEC, which requires a caching DNSSEC-aware resolver both for performance reasons (DNSSEC validation is time-consuming) and to avoid having to implement DNSSEC validation in the libc resolver.

We could have solved the DNSSEC issue by configuring BIND as a local caching resolver, but for the reasons mentioned above, we really want to remove BIND from the base system; hence the adoption of a lightweight caching resolver. An additional benefit of importing LDNS (which is a prerequisite for Unbound) is that OpenSSH can now validate SSHFP records.

Note that the dns/unbound port is not going away, and that users who want to run Unbound as a caching resolver for an entire network rather than just a single machine have the option of either moving their configuration into /var/unbound/unbound.conf, or running the base and port versions side-by-side. This should not be a problem as long as the port version doesn’t try to listen on or ::1.

I’d like to add that since my previous post on the subject, and with the help of readers, developers and users, I have identified and corrected several issues with the initial commit

  • /etc/unbound is now a symlink to /var/unbound. My original intention was to have the configuration files in /etc/unbound and the root anchor, unbound-control keys etc. in /var/unbound, but the daemon needs to access both locations at run-time, not just on start-up, so they must all be inside the chroot. Running the daemon un-chrooted is, of course, out of the question.
  • The init script ordering has been amended so the local_unbound service now starts before most (hopefully all) services that need functioning DNS.
  • resolvconf(8) is now blocked from updating /etc/resolv.conf to avoid failing over from the DNSSEC-aware local resolver to a potentially non-DNSSEC-aware remote resolver in the event of a request returning an invalid record.
  • The configure command line and date / time are no longer included in the binary.

Finally, I just flipped the switch so that BIND is now disabled by default and the LDNS utilities are enabled. The BIND_UTILS and LDNS_UTILS build options are mutually exclusive; in hindsight, I should probably have built and installed the new host(1) as ldns-host(1) so both options could have been enabled at the same time. We don’t yet have a dig(1) wrapper for drill(1), so host(1) is the only actual conflict.

Local caching resolver in FreeBSD 10

As of a few hours ago, all it takes to set up a local caching resolver in FreeBSD 10 is:

# echo local_unbound_enable=yes >>/etc/rc.conf
# service local_unbound start

Yes, it really is that simple—and it works fine with DHCP, too. Hold my beer and watch this:

# pgrep -lf dhclient
1316 dhclient: vtnet0
1265 dhclient: vtnet0 [priv]
# cat /etc/resolv.conf
# Generated by resolvconf
# time host is an alias for has address has IPv6 address 2001:1900:2254:206a::50:0 mail is handled by 0 .
        0.02 real         0.00 user         0.01 sys

As you can see, we’re running DHCP on a VirtIO network interface. Let’s work our magic:

# echo local_unbound_enable=yes >>/etc/rc.conf
# service local_unbound start
Performing initial setup.
Extracting forwarders from /etc/resolv.conf.
/var/unbound/forward.conf created
/var/unbound/unbound.conf created
/etc/resolvconf.conf created
original /etc/resolv.conf saved as /etc/resolv.conf.20130923.075319
Starting local_unbound.

And presto:

# pgrep -lf unbound
3799 /usr/sbin/unbound -c/var/unbound/unbound.conf
# cat /var/unbound/unbound.conf 
# Generated by local-unbound-setup
        username: unbound
        directory: /var/unbound
        chroot: /var/unbound
        pidfile: /var/run/
        auto-trust-anchor-file: /var/unbound/root.key

include: /var/unbound/forward.conf
# cat /var/unbound/forward.conf
# Generated by local-unbound-setup
        name: .
# cat /etc/resolv.conf
# Generated by resolvconf
# nameserver

options edns0

We can see the cache at work; the first request takes significantly longer than before, but the second is served from cache:

# time host is an alias for has address has IPv6 address 2001:1900:2254:206a::50:0 mail is handled by 0 .
        0.07 real         0.01 user         0.00 sys
# time host is an alias for has address has IPv6 address 2001:1900:2254:206a::50:0 mail is handled by 0 .
        0.01 real         0.00 user         0.00 sys

Finally, let’s see how this interacts with DHCP:

# resolvconf -u
# cat /etc/resolv.conf
# Generated by resolvconf
options edns0

# cat /var/unbound/forward.conf 
# Generated by resolvconf

        name: ""

        name: "."

Note that resolvconf(8) re-added the entry. It doesn’t really matter, as long as comes first.

[ETA: it does matter—see Jakob Schlyter's comment below and my reply.]

[ETA: see my followup about the motivation for importing Unbound.]

The Short List #7: wpa_passphrase on #FreeBSD. Because plaintext passwords are dumb.

If you have configured wireless networks on your FreeBSD laptop/pc. You can use wpa_passphrase to make the password entries more obscure with the use of wpa_passphrase.

For example, given the following network entry in wpa_supplicant.conf:

psk=”Super Secret Plain Text Password”

wpa_passphrase can give you a psk entry that is more obscure:

$ wpa_passphrase BRUNO
# reading passphrase from stdin
Super Secret Plain Text Password
#psk=”Super Secret Plain Text Password”

Just remember to delete the plain text version when you copy paste it into your config.

Cadillac ZFS #FreeBSD

I had an opportunity at work to build up a new machine to do our FreeBSD builds at work this quarter and wanted to see how far I could take ZFS on high end OEM hardware.

After evaluating HP and Dell gear, I settled on the Dell r720xd as my platform to move forward.  Primarily, this was due to the lack of *real* JBOD support on the HP line of SAS controllers.  The Dell H310 has a “SYSPD” option in mfi(4) that allows one to use the raw disks and ignore the RAID capabilites.  I went ahead and modified the FreeBSD mfiutil(4) tool to allow run time configuration into this mode.

I ended up with 64G of RAM and 2x CPU: Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz (2300.05-MHz K8-class CPU).  I stacked 12x3TB SAS drives (really just SATA drives with SAS firmware, but hey, they cost WAY MORE).

Setup the zpool with 2x raidz1 vdevs on this go around.  There was some debate between myself and other colleagues if I should have gone with 1 raidz2 pool.  It theoretically would have some better failure handling since I would have 2x parity disks in the same pool, but it seemed that I should go with 2x vdevs, each with 1 parity drive in this case because of how much write activity building 7 different FreeBSD distributions simultaneously would generate.

I ended up with a zpool that looks like this:

pool: zroot
state: ONLINE
scan: scrub repaired 0 in 0h0m with 0 errors on Wed Aug 21 15:55:09 2013

zroot             ONLINE       0     0     0
raidz1-0        ONLINE       0     0     0
mfisyspd1p3   ONLINE       0     0     0
mfisyspd2p3   ONLINE       0     0     0
mfisyspd3p3   ONLINE       0     0     0
mfisyspd4p3   ONLINE       0     0     0
mfisyspd5p3   ONLINE       0     0     0
mfisyspd0p3   ONLINE       0     0     0
raidz1-1        ONLINE       0     0     0
mfisyspd6p3   ONLINE       0     0     0
mfisyspd7p3   ONLINE       0     0     0
mfisyspd8p3   ONLINE       0     0     0
mfisyspd9p3   ONLINE       0     0     0
mfisyspd10p3  ONLINE       0     0     0
mfisyspd11p3  ONLINE       0     0     0


Performance wise, this machine now spits out our production images in about 95 minutes as opposed to the 255 minutes from before.  Its a complete dead lift of hardware, new cpus, disks, more ram, different F/S, etc.  I’m pretty happy with it, but of course, its Cadillac prices, so your mileage will vary.

GEOM_SHSEC: A shared secret disk drive GEOM module

GEOM_SHSEC is one of the less frequently used GEOM modules from FreeBSD, but it is actually pretty interesting. It combines several drives (or any other entities which are presentable as GEOM devices - including USB memory keys and files) into a single virtual drive which has the property that all its constituent devices must be present and available before its contents can be accessed.

For example, you might have two USB keys which both need to be plugged in before the Very Important Secret stored on them can be read. A very neat concept!