# Tag Archives: freebsd

Anything related to FreeBSD

# Unbound unable to read root zone

After upgrading various ports on my FreeBSD system and days later a full world and kernel, a reboot showed me that unbound didn’t start. The system reported that:

error: reading root hints
/usr/local/etc/unbound/named.cache 88: Empty line was returned

It turns out that from ldns 1.6.13 to 1.6.14 there is an API change that caused problems for unbound. After upgrading ldns you also need to recompile unbound to pick up on these changes. If you do not, you will run into the problem above.

# FreeBSD, p0f, and USB pcap

If, like me, you had a working FreeBSD system with amavisd-new and p0f set up, you might find that p0f suddenly stopped working at some point. The cause for this is that it tries to use pcap on the USB bus, which it cannot do. The solution is to put hw.usb.no_pf=1 in your /boot/loader.conf.

# Mercurial 1.7, cacerts, and FreeBSD

So with recent Mercurial 1.7 releases HTTPS support was tightened, so you are bound to encounter a warning in the form of: warning: bitbucket.org certificate not verified (check web.cacerts config setting).

Now, on http://mercurial.selenic.com/wiki/CACertificates there are details on what to configure for certain operating systems. Given I use FreeBSD, I altered my $HOME/.hgrc as follows: [code] [web] cacerts = /etc/ssl/cert.pem [/code] For OpenBSD this should be in the same place since release 3.8. But apparently NetBSD does not have such a file in base. # FreeBSD 7 to FreeBSD 8 update quite painless So last night I updated my machine to the latest FreeBSD 7-STABLE and from there updated to FreeBSD 8-STABLE (although it’s named PRERELEASE still in the repository). Aside from some minor kernel configuration file revamping the entire effort was just like a regular update. # sendfile() mishandling As I said in http://www.in-nomine.org/2009/02/22/tinymce-in-wordpress-271-not-working-on-freebsd/ I had problems making TinyMCE work. After some digging I discovered that the tiny_mce.js file was being oddly truncated and repeated when fetched. Subsequent tests showed that md5 hashes differed every single time with the original file. During these fetch tests my kernel crashed twice in the network stack. Since my lighttpd configuration uses kqueue and the likes I suspected that perhaps something was not right in lighttpd 1.4.21, which was only released a couple of days ago. So I downgraded to 1.4.20. ‘Lo and behold, the problems disappeared. To be absolutely sure, I recompiled lighttpd 1.4.21 as well. And at first it seemed to work, but then the corruption kicked in again. After talking about it on the #lighttpd channel on FreeNode I found out it was a problem with lighttpd 1.4.21′s handling of sendfile() on FreeBSD. The fix is now also in the lighttpd port of FreeBSD, so other people should not encounter this problem. # TinyMCE in WordPress 2.7.1 not working on FreeBSD? Discovered today that with both Firefox 3.0 and Opera 9.63 on FreeBSD, TinyMCE within WordPress 2.7.1 is not allowing me to use the visual editing mode. I tried the example of TinyMCE and it works without problems. Based on this and the fact it works on Windows, there must be something weird in either WordPress or its included version of TinyMCE with FreeBSD. I logged a post over at the WordPress forums. # Zotero and PDF indexing on FreeBSD For a while now I have been using Zotero on Firefox to handle researching topics. It also allows PDF indexing, but for this you need to set some things up first. Start by installing xpdf from ports, it’s located under graphics/xpdf. This will install pdfinfo and pdftotext amongst others. Next go to your Zotero data directory, by default this is the zotero directory under your profile directory in $HOME/.mozilla/firefox, and create two symbolic links pdfinfo-uname -s-uname -m and pdftotext-uname -s-uname -m which will point to /usr/local/bin/pdfinfo and /usr/local/bin/pdftotext, respectively.

Now, when you restart Firefox, Zotero should be able to pick up the files. Check by going into Zotero’s preferences and navigate to the Search tab. It should state something to the effect of pdftotext version UNKNOWN is installed.

# Character encoding in mailcap for mutt and w3m

I use mutt on my FreeBSD system to read my mail. To read HTML mail I simply use a .mailcap file with an entry such as

text/html;      w3m -dump %s; nametemplate=%s.html; copiousoutput

This in effect dumps the HTML using w3m to a text file in order to safely display it. The problem that I had is that, because some emails that I receive are from a Japanese translators list, they are in Shift_JIS. When dumped w3m doesn’t properly detect the Shift_JIS encoding and as such the resulting output becomes garbled.

When I looked at the attachments in the mail with mutt’s ‘v’ command I saw that mutt at least knows the encoding of the attachment, so I figured that there should be a way of using this information with my mailcap. Turns out that there is indeed a way to do so, namely the charset variable. It turns out the mailcap format is a full RFC. RFC 1524 to be exact. Mutt furthermore uses the Content-Type headers to pull any specific settings into mailcap variables. So a Content-Type: text/html; charset=shift_jis means that %{charset} in the mailcap file will be expanded to shift_jis. We can use this with w3m’s -I flag to set a proper encoding prior to dumping.

text/html;      w3m -I %{charset} -dump %s; nametemplate=%s.html; copiousoutput

As such you can be relatively sure that the dumped text will be in the appropriate encoding. Of course it depends on a properly set Content-Type header, but if you cannot depend on that one you need to dig out the recovery tools already.

# Slow Terminal with xfce, alpha channel issues

I recently switched to using xfce on my FreeBSD desktop. Window Maker is nice but it was starting to feel a bit dated. Thus far I like xfce, but I had one problem with Terminal. Whenever I tried to resize it or switch desktops to one with Terminal open in it I could see it painstakingly render the window. Xterm and aterm didn’t exhibit this behaviour, my 3d was accelerated, and other screen drawing didn’t show problems either (do note I am using NVIDIA’s binary driver for my GeForce 8800, the nv driver from X.org is unusable at this point).

Someone pointed me at the environment variable XLIB_SKIP_ARGB_VISUALS=1. Once added to .zshenv, properly exported on my shell and an X restart later I find Terminal to zoom along as expected. It turns out that the NVIDIA driver doesn’t properly accelerate alpha channels.

# src.conf on FreeBSD 7 for the average installation

If we consider common available technology and the average use of a FreeBSD installation as desktop or server then I think these are sensible defaults for /etc/src.conf under FreeBSD 7.

WITHOUT_ATM=yes

How many of you run ATM to your FreeBSD box?

WITHOUT_BIND_DNSSEC=yes
WITHOUT_BIND_ETC=yes
WITH_BIND_LIBS=yes
WITHOUT_BIND_MTREE=yes
WITHOUT_BIND_NAMED=yes

Do you really need a full installation of BIND on your machine? In most cases you simply need a caching, recursive resolver. For this just install unbound (found in ports/dns/unbound). Do note that I did not specify WITHOUT_BIND_UTILS so tools like dig and nslookup will still be installed. Only if you need an authoratative nameserver might you want BIND. On the other hand, you might prefer to install NSD (ports/dns/nsd).

WITHOUT_BLUETOOTH=yes

Most systems will probably not use Bluetooth at all.

WITHOUT_I4B=yes

Do you even use ISDN?

WITHOUT_IPFILTER=yes

Most people I know use either ipfw or pf, so little need for ipf.

WITHOUT_IPX=yes

You seriously still use IPX? Even NetWare is IP-native nowadays.

WITHOUT_NIS=yes

I would hope most systems are using some sort of LDAP lookup nowadays. NIS seriously doesn’t scale.

WITHOUT_SENDMAIL=yes

Given the ease of configuring Postfix, why would one want to bother with the archaic syntax of Sendmail? It has served faithfully for many, many years, but its design and configuration are archaic.