A n00b's adventure in the wonderful realm of BSD.

Shiki-colors for Xfwm4

Ever since I’ve read this blog post about customizing FreeBSD, I loved the Shiki Colors appearance. Tried replicating the looks on Xfce, but wasn’t very successful, due to the fact that you’ll need to replace xfwm with metacity, and that will bring a lot of unwanted dependencies on your system. So we won’t go on that road.

Fortunately, the guys from Debian made a package called shiki-colors-xfwm-theme and this can help us a bit. It’s not the real deal, but it improves the looks of Xfce.

So first, we need to download the Debian package. For this, just a mirror from this site and you will get a .deb package. Now, we want to extract the files from this .deb archive, and we can do this by typing:

ar vx shiki-colors-xfwm-theme_4.6-1_all.deb

This command outputs three files: debian-binary and two more archives: control.tar.gz and data.tar.gz. We are only interested in the latest one (you can discard the rest), so let’s go and deflate that:

tar -xzvf data.tar.gz

You will get an usr folder that contains a bunch of other folders that you have to navigate trough and finally you’ll reach the ones we need: Shiki-Colors-Easy-Metacity and Shiki-Colors-Metacity. Just copy these two folders under /usr/local/share/themes. You will see here other folders with themes, so make sure you are in the right place by recognizing a few. To test them, run:


and search the two news themes under Style tab. You’ll find them among others xfwm4 themes that you may like. Now remember, this is the theme only for the xfwm, tuning your desktop appearance can be done also from Settings menu, Appearance. I settled for Rezlooks-Sydney. You can get this one by installing the following:

pkg_add -vi gtk2-rezlooks-engine

In the end, it all looks like this. And I like it.

Installing Xfce 4.10 on OpenBSD 5.4

Things got pretty easy since I last tried this. There’s no need to remember long lists of packages needed to be installed for the latest Xfce on the newest OpenBSD. Simply type:

# pkg_add -vi xfce

and you’re good to go, thank to the xfce meta package. You’ll have a full Xfce 4.10, but if you want some fancy stuff, like weather or keyboard layout applets, or some pretty gtk-engines and xfwm themes, you’ll still have to type some more commands. But enough for today. We’ll do some make-up in the following days, stay tuned.

The bridge pool

Before you can easily use ZFS pools in both OS X and FreeBSD, you have to make sure they belong to the same user and group.

So, if you install ZFS on OS X and you put FreeBSD after that, it’s quite easy, just create the same username as you have on OS X and add him to the staff group. After that, while still in FreeBSD (it’s easy from here), you’ll have to change your user ID to 501 (or whatever you have in OS X, but 501 is the default one). If you don’t know your user ID (UID), just run

% ls -aln

in your home folder folder.

If you had FreeBSD already installed, you’d probably have UID 1001. Let’s change that to 501.

% sudo pw <username> 1001 -u 501

Now add your user to staff group, but be sure not to stay in wheel group:

% sudo pw usermod <username> -G staff,wheel

Almost set. Just take ownership of the file from the pool

% sudo chown -R <username>:staff /STORAGE

My pool is called STORAGE and it’s mount on /. Your details may differ, but you got the idea. That’s pretty much it. Now you can enjoy read an write access from both OS X and FreeBSD, as God indented to.


Perfect timing to get on-board with FreeBSD: 9.2 was just released today! Upgrade from RC4 was quick and painless:

freebsd-update -r 9.2-RELEASE upgrade

It went smooth, it required a reboot then i had to run again

freebsd-update install

to finish up the process.

OS X with ZFS

One of the best things about FreeBSD is ZFS. One of the best things about ZFS is that it can be used as a bridge between FreeBSD, OS X, Linux and any illumos distribution (like OpenIndiana). And we all know ZFS is great (this isn’t the place to blabber about its advantages), so why not use it?

One (and probably the only) reason to not use ZFS is its complexity. I’m a n00b and I find ZFS a little tedious to setup and maintain, but I think at the end of the day, it’s worth it. I’ll cover FreeBSD and ZFS in another post, but here’s how you can benefit from the latest OpenZFS on OS X. Well, there was ZEVO and now there’s also MacZFS (an effort which predates both ZEVO and OpenZFS projects), but we’ll just cover OpenZFS because MacZFS people may eventually adopt this new initiative, so why anchor ourselves in the past when we can use the newest and shiniest tools? So you won’t find an old MacZFS (74.x) tutorial in here, but there’s actually no reason for me to use that anymore, better think about OpenZFS and all its benefits. Also, if you have the old MacZFS 74.x installed, you must uninstall it before proceeding further. Also, a reboot is mandatory if you’re uninstalling ZEVO.

We’ll need to fetch the latest source from github and then compile it. For this, we’ll need some prerequisites, like Xcode (from Mac App Store), Xcode Command Line Tools (use the Downloads pane of Xcode preferences) and Homebrew (you can use MacPorts, but I wanted to try something new this time). Oh, and you need to be an administrative user to follow the next steps successfully, but if you own the machine, you’re probably already an administrative user.

To get Homebrew, I used the following line:

ruby -e “$(curl -fsSL”

Quick and painless. Once Homebrew is installed, we need a couple of things first:

brew install automake
brew install libtool

Other stuff is needed, but Homebrew will take care of it, as dependencies. Now go to your home directory and create a folder called ‘Developer’. We’ll need it further on.

cd ~
mkdir Developer

For cloning the GitHub repo and building ZFS, we’ll need this precious script. Save it on your home folder and call it zfsadm

Edit the script and modify lines 4 and 6, by providing your username. It won’t work otherwise, so this is an important step!

Since it’s a script, it needs to have its mode changed to allow execution:

chmod +x zfsadm

All set. Let’s go cloning and building ZFS:


It should take a couple of minutes, not more. Disregard the warnings you may notice on the screen during build, it should be fine. The extensions were built, but not loaded yet. Let’s load them, using again zfsadm:

./zfsadm -k

You can always check if they are loaded with 

sudo kextstat

If you get something similar to 

0xffffff7f80b52000 0xc000 0xc000 net.lundman.spl (1.0.0) <7 5 4 3 1>
0xffffff800b070a00 0x180 0x180 net.lundman.kernel.dependencies (10.0.0)
0xffffff7f8129a000 0x1f3000 0x1f3000 net.lundman.zfs (1.0.0) <92 91 16 7 5 4 3 1>

then everything worked out well. But before using it, there’s still some housekeeping to be done. Let’s install the binaries:

cd ~/Developer/zfs
sudo make install
cd ~/Developer/spl
sudo make install

This will create required binaries in /usr/local/sbin. If, by some reason (say, a dreadful kernel panic), you would like to manually load the extensions after each reboot, just remove them from /System/Library/Extensions (in safe-mode, if necessary, by pressing Shift after reboot) and run:

./zfsadm -k

to load them. Also, for unloading, run:

./zfsadm -u

Moving on. Fix permissions, so that you can use zpool as normal user:

cd /usr/local/sbin
sudo chmod +s z*

Put this in your  ~/.bash_profile (if the file doesn’t exists yet, create it):

export PATH=$PATH:/usr/local/sbin

Now you can try running


to see if everything is installed and configured properly. You can go ahead and create your pools and play with them from now on. Also, please don’t miss the official FAQ of OpenZFS.

If in the future you need to update from GitHub, here’s a quick overview of things you need to run from your home folder:

cd ~/Developer/zfs
sudo make install
cd ~/Developer/spl
sudo make install
cd /usr/local/sbin
sudo chmod +s z*

Also, before update, be sure to export your pools by running 

zpool export poolname

for every pool you have, before running zsfadm -k, to avoid any pool hangs or kernel panic.

Occasionally a reboot will be necessary after the update because the  net.lundman.kernel.dependencies has been updated but cannot be unloaded. This would be evident if the kexts fail to load after zfsadm -k.

To smooth things up a little, you could create a bin folder in your home directory:

mkdir ~/bin

and move the zfsadm script to it:

mv ~/zfsadm ~/bin

and add this to your ~/.bash_profile:

export PATH=$PATH:/Users/<username>/bin

From now on, if you do this, you can simply run zfsadm from Terminal, without the need to be in your home folder.

Many thanks to ilovefs on #mac-zfs channel on Freenode for provinding step-by-step instructions regarding this tutorial and to grahamperrin for useful observations.

OpenBSD on iMac G3

Since I moved my website on a virtual server (running Debian) and since my OpenBSD desktop project was an expected failure, this blog was dormant. Until I found a new use for OpenBSD: I’ve recently bought an old iMac G3 (summer 2000) and after playing with Mac OS 9 and Mac OS X Tiger on it, now it’s time to install some OpenBSD. Because why not.

Getting the macppc port was easy. Installation was pretty straightforward. The only difference from any other installation was that the installer asked me if I want a MBR or a HFS partition and, since I plan to have only OpenBSD on the machine (no dual-boot for the time being), I answered MBR.

After installation, if you want to boot your newly installed OpenBSD, you’ll have to enter Open Firmware by pressing Command+Option+O+F at boot, and then issue the following command:

boot hd:,ofwboot /bsd

Because OpenBSD is the only operating system on the machine, you’ll probably want to boot directly into it, without manually going trough Open Firmware. To do this, enter in Open Firmware again and type this:

setenv boot-device hd:,ofwboot /bsd

Your iMac should now reset and boot directly into newly installed OpenBSD.

If you want to run X, check if machdep.allowaperture is set to 2 in /etc/sysctl.conf. This will allow X to run accelerated. More info, in here. Getting X to run is another story that will follow soon.

Edit: I dropped all plans to run OpenBSD on iMac, due to the Xorg issue.

Simple password generator

While reevaluating my security practices, I came up with the conclusion that my password system is a mess. For obvious reasons, I won’t talk about it much, but I realized that having a handy password generator will be a good idea. While searching a few minutes for hints and solutions, I came up with two methods that works out-of-the box on a OpenBSD machine, without needing any extra package to be installed than the default base system.

Here’s the first one:

dd if=/dev/urandom count=200 bs=1 2>/dev/null|tr “\n” ” “|sed ‘s/[^a-zA-Z0-9]//g’|cut -c-16

It’s a little cryptic for a newbie (due to sed), but what you have to remember is that it generates passwords with a length of 16 characters and modifying the last argument will modify your password length. It’s based on /dev/urandom device, so it should be safe enough.

The second method uses OpenSSL:

openssl rand -base64 16

Careful, sometimes the last two characters would always be “==”. if you use this command, but you can get rid of this by adjusting the length of it.

Now, you can use any of this commands to have a pretty secure password. But to increase the randomness of it, I use a bash script that generates a two strings, one with each method, and I’ve placed a special character between them (it can be “@”, “#”, “$”, “%”, anything you like). 

Here’s my script:

part1=`openssl rand -base64 6`
part2=`dd if=/dev/urandom count=200 bs=1 2>/dev/null|tr “\n” ” “|sed ‘s/[^a-zA-Z0-9]//g’|cut -c-9`
echo $part1%$part2

You can easily tweak the length of the each two strings and the special character between them. The example from above gives you a 16 (6+1+9) characters password, with the “%” characters between the two strings.

The value of good documentation

One of the strengths of OpenBSD is its documentation. I’m really glad that developers really takes it seriously, since a good manual page can save you a lot of time and troubles. Here’s an example: I was trying to sort out a text file and remove duplicates. The file was above 200 MB.  My first approach was the following:

cat list.txt | sort | uniq > list_m.txt

But after a few seconds, I received the following error:

sort: /var/tmp/sort.G2bEcvsPlX: Too many open files

Let’s break is down:

$ sort -o list_s.txt list.txt

Same error. So it’s related to sort, not to cat or uniq. First impluse: search if other had the same error. No relevant answers in the first minutes. Should I ask this on a forum? Maybe on the mailing list? That was my second impulse. But wait, let’s read the manual for sort. Tried with the following arguments:

$ sort -o list_s.txt list.txt

Same error.

Ok, let’s keep reading. The last paragraph reads:


To sort files larger than 60Mb, use sort -H;
files larger than 704Mb must 
be sorted in smaller pieces, then merged.

There I have it! Good documentation doesn’t just provide a quick fix for a problem but in the same time reduces pollution and cacophony on forums and mailing lists. And it feels good finding out the answer all by yourself.

Setting your dpi

For a pleasant desktop experience, it’s generally a good idea to have your X server run with 96 dpi (dots per inch). Other values might work as well, but I found this to be the perfect choice for my machine. Usually, the system would set this dpi value correctly, but if it doesn’t or if you want to make sure it will not miss, look at your /etc/X11/xdm/Xservers file and find the line that looks something like this:

:0 local /usr/X11R6/bin/X :0 vt05

Modify it, to look like this (basically just insert the ‘-dpi 96’ switch, as shown):

:0 local /usr/X11R6/bin/X -dpi 96 :0 vt05

Restart your X server. Now you’ll surely have a desktop manager with 96 dpi resolution. Nice, isn’t it?

Permalinks and .htaccess

If you host a Wordpress blog, like I do, you may want to enable those pretty permalinks. Wordpress documentation will tell you what kin of .htaccess file you need in your base folder (meaning the same fodler where your index.php is located for your Wordpress webiste). That’s helpful, but you still need to do a few tricks to have it running on OpneBSD, if you don’t want to end up seeing 404 Errors all the time.

First of all, check if mod_rewrite is enabled for your httpd, by making sure that you have uncommented the following line from your /var/www/config/httpd.conf file:

LoadModule rewrite_module       /usr/lib/apache/modules/

Now you need to tell httpd to let you use .htaccess files on your webiste folder. You can do this by searching for this block:

AllowOverride None

and change it to 

AllowOverride All

Make sure you are within <Directory “/var/www/htdocs”> directive when you do this.

Now restart (or reload) your httpd. Change your permalinks settings from Wordpress and see the results.