On FreeBSD, git can’t find the certificate store

When I was playing with git checkout of modules I discovered that git doesn’t know how to set the certificate store for curl when it tries to retrieves a module via https. In general, I don’t recommend using git with https unless you have to. Using git+ssh obviates away a bucket of authentication issues. In this case, https is the better choice. To tell git where to look for certificates, to verify and https website, I had to add the following to my ~/.gitconfig:


The command that does this is: git config --global http.sslCAPath "/etc/ssl/certs". If your operating system uses a CA file rather than a CA directory this is the setting: git config --global http.sslCAInfo "/etc/ssl/cert.pem". You can also make this work by setting an environment variable for curl in /etc/profile.

Mirroring in Gitlab

I normally strongly prefer git+ssh over git+https. If you are mirroring between two gitlab-ce instances over git+https, you can handle your mirroring with a single authentication token.

Turn off arp change noise on FreeBSD

If you run a FreeBSD server on a machine with any Apple infrastructure, Airport, AppleTV, etc then you are probably used to seeing lots of messages like this:

+arp: moved from --- somewhere --- to - somewhere else- on em0
+arp: moved from - somewhere else- to --- somewhere --- on em0

This is the Bonjour Sleep Proxy service in action. A device that provides a sleep proxy attempts to make Bonjour services available on your network at all times by advertising  the proxy’s IP address  as  the service destination while the  true provider is sleeping. For example, if you have an older, non-networked shared printer connected to an iMac Desktop, the sleep proxy will advertise it’s own address as the destination for your share printer. If someone sends a print request to your printer, the sleep proxy intercepts the request, sends a wake up packet to your iMac, and then the printing can actually go on.

This activity looks a lot like an arp poisoning attack. If you want to check for that look at the mac address of the devices in question. You can look up the first three octets of the mac address at Google. Those are a manufacturer ID. If one or both of the devices is from Apple, it’s more likely that you have a Bonjour Sleep Proxy working on your network.

Over time these messages are disruptive on a FreeBSD server because they blow valid information out of the kernel’s dmesg buffer. You can still the kernel’s boot dmesg by groveling through sysctl if you have a disk drive that’s misbehaving, that information will be lost in a day or two.

To turn these messages off, do the following:

$ sudo su -
# ## Fix this for this kernel boot session...
# sysctl -w net.link.ether.inet.log_arp_movements=0
net.link.ether.inet.log_arp_movements: 1 -> 0
# ## Fix this permanently.
# echo 'net.link.ether.inet.log_arp_movements=0' >> /etc/sysctl.conf

Mutt account passwords

First, to give credit where it’s due, I started here. That said, here’s how I store and access account passwords in mutt on Linux.

## -- Passwords: encrypted by gpg --------------------------------------------------------------

source “/bin/gpg -d ~/.keychain/mutt.password.neopost.gpg 2>/dev/null |”

The source line in gpg tells mutt to decrypt a file at startup. The file .keychain/mutt… contains two mutt configuration lines:

set imap_pass = "<my_email_password>"
set smtp_pass = "<my_email_password>"

I created it as follows:

$ cat <<EOF | gpg -r <my_gpg_id> ~/.keychain/mutt.password.neopost.gpg
set imap_pass = "<my_email_password>"
set smtp_pass = "<my_email_password>"

Gpg knows how to decrypt this file and retrieve the plain text configuration. Note well that I used a “Here” document to create the file. This keeps mail password out of the filesystem. Simple stuff, at mutt startup the first time I use it, gpg-agent asks for my gpg key and unlocks the configuration snippet.

Submission brutes

Brush aside vandals attacking my submission daemon with a little sed:

submission_brutes=$(bzcat /var/log/maillog.0.bz2 | \
cat - /var/log/maillog | \
sed -Ene '/postfix\/submission\/smtpd.*errors after AUTH/s/^.*[^0-9]+(([0-9]+\.){3}[0-9]*).*$/\1/p' | sort -u)
[[ ! -z "${submission_brutes}" ]] && pfctl -t blackhole -T add ${submission_brutes}

pf required: pass proto ipv6-frag all

FreeBSD’s pf has serious problems with ipv6 fragment handling. The problems cascade into other issues like named axfr time outs.  Add this, “pass proto ipv6-frag all”, to your ruleset somewhere near your antispoof rules to fix this.

Much of the issue is that the FreeBSD team has diverged their version of the pf firewall so far from the OpenBSD version that they cannot incorporate upstream fixes. I’m not making my situation any better by sticking with FreeBSD 9. Some of this is probably addressed in FreeBSD 10.

While this persists the best course of action is probably to make sure it works on OpenBSD first, then figure out how to deal with any FreeBSD issues.

FreeBSD cross compiling or “Thanks Captain Obvious…”

It would be nice to manage my fleet of FreeBSD machines from one place. But I’ve diversified from i386 only to i386 and amd64 as I start doing more and more stuff with virtual machines; single purpose servers and less power usage for-the-win. The question comes up, do I need build-i386.vindaloo.com and build-amd64.vindaloo.com — Nope:

# env TARGET=i386 MAKEOBJDIRPREFIX=/usr/obj/i386 make buildworld...

bash / ksh / pdksh

Fo my new job I’ve decided to try not to be so old and crotchety and use bash without complaining rather the just changing my shell to pdksh. Today I needed to process options in a shell function which I’ve done in ksh before. It turns out that you have to preface your option processing with OPTIND=1 if you are in a function. Dunno why but I’ll find it out.

FreeBSD’s geom makes life easier.

FreeBSD’s geom is the missing link that I’ve been searching for. Geom is an abstraction for mass storage providers and consumers which really cleans up the mass storage layer in Unix. In geom your disk drive combined with it’s driver is a mass storage provider. The filesystem layer is a mass storage consumer. Geom provides the glue in between providers and consumers which allows greatly enhanced function. Encrypted or compressed storage can be easily built using this framework.

I’m using geom with the automounter, amd to revamp my use of removable media. If you use the new gnome framework gnome’s hald does this also but it requires the user to unmount the drive. I like using amd here. Even though there’s a slight performance penalty amd will automatically unmount the drive for you after a configured period of inactivity. I find that this is an effective way of getting around one of Unix’s quirks. Unix doesn’t react well with a piece of the filesystem just disappears which is what happens when you remove a mounted USB stick. Amd can be configured to unmount the stick 30 seconds after you’ve stopped using it. Doing this almost eliminated the resulting kernel panics and length fscks that I experienced when I first started using USB storage.

The automounter is a utility that was designed to mount storage into the filesystem on demand. It works by providing an NFS look alike storage system. You literally mount the automounter into a directory in the filesystem. The automounter is configured with a map that assigns different directories within it’s filesystem to different pieces of mounted storage. So if amd is providing the directory /Volumes and has a mapping for MyUsbStick when you try to get a directory listing of /Volumes/MyUsbStick, the automounter has all the information needed to do the mount and provide access to the filesystem beyond. So far that’s about even.

Without geom that was a nice enough setup. But when the kernel attaches your usb stick in FreeBSD it gives it a name like /dev/da0s2e or /dev/da1s1. It’s easy enough to figure out what this means. da0s2e is the “e” partition on the second slice of the first “SCSI” drive in the system. USB and firewire drives a psuedo SCSI drives in FreeBSD and in Linux because the SCSI protocol was flexible enough to serve as the model for mass storage. But what happens if you have two systems and one of them has a SCSI controller in it or if you have two USB sticks. SCSI drives are number in the order in which they appear on the system so for the man with two USB sticks the whether they are connected as Drive a is da0s2e and drive b is da1s2e or vice versa depends on the order in which you plug them in. It turns out that geom embraces the concept of a volume label and can create a shadow device based on that label.

To use this feature of geom load the kernel module geom_vol_ffs (Available in FreeBSD from 6.x onwards) then add a label to your FreeBSD filesystems using the tunefs command:

# tunefs -L “MyLabel” /dev/da0s2e

Then you should end up with a device entry for your disk called /dev/vol/MyLabel

Have fun

— Chris