Update: This guide has been updated by Apple for Yosemite and El Capitan as well so the title of this post has been updated to reflect that change.

∞ Permalink

If you don’t know who he is, you might recognize him from his home office. As a fellow home office aficionado, it’s always fun to look at all the tech gear. (Yes, obviously I enjoy tech hardware and home office layouts.) This picture from his site gives some idea of how expansive the layout is.

The newest iteration is now at 7.0 and is very impressive. As I’m designing my new home office that will be completed in January or February, it is very interesting to look at his whole design and assembly process.

The hardest part of the office design for me is choosing the right desk and desk layout. In particular, I have hesitated to buy an expensive desk since I tend to change things around frequently or, in the case of moves, change is required. It’s great to see a really good layout for lots of systems and monitors and it gives me great idea for how to better design my own space.

You’ll find the main office pictures at Stefan Didak’s Home Office page and the assembly at the Home Office Version 7 Setup Making Of page. Both are definitely worth a look and a bookmark!

∞ Permalink

The tool is called youtube-dl and simply takes the YouTube URL and downloads the best quality available. It’s hard to beat that. I’ve now downloaded a variety of BSD videos that I want to watch at my convenience or while traveling. (The bsdconferences YouTube Channel is a great place to start.) There are, of course, many other command line options that I have yet to explore.

Fortunately, youtube-dl is available in OpenBSD Ports as well as MacPorts and Homebrew

∞ Permalink

I am using the SSDs I recommend with OS X laptops in external enclosures (reviews coming soon) as well as with OpenBSD, FreeBSD, and Linux systems. All of the recommended models are excellent solutions for high performance and some excellent options for exceptional value as well.

On to my SSD guide.

∞ Permalink

The HP Chromebook 11 has arrived with many similarities to Samsung’s ARM-based Chromebook. What the HP variety adds is an IPS display and what appears to be a higher quality casing. There are some additional accent colors and a clean exterior. The full spectrum of wireless connectivity is available with 802.11a/b/g/n and Bluetooth 4.0 and Verizon 4G LTE will be available in a future version as well.

The HP Chromebook 11 comes in white along with various accent colors or all black. In an interesting move, this is the first Chromebook to charge via Micro USB but at 15.75W, even more than a 4th generation iPad’s 12W. Google is touting the ability of this Chromebook to use the same charger as your Android phone.

The CPU in this Chromebook is the Exynos 5250 GAIA Application Processor, which is either identical or very similar to what Samsung used in its ARM-based Chromebook. Also in line with Samsung, HP has provided 2GB of memory and a 16GB SSD. What’s lacking is any sort of SD card slot and USB 3.0 ports. The latter is really pointless in a device like this but an SD card slot was very useful. All four ports (2 USB 2.0, Micro USB, and combined headphone/microphone) are on the left side. The right side is completely lacking ports.

I like the design in many ways and this might make a good candidate for running Kali Linux or Ubuntu in the future if support emerges as it has for the Samsung ARM-based Chromebook. Chrubuntu or Crouton will likely be feasible before too long. Crouton, in particular, is very promising and provides an easier route than a full-fledged install in place of Chrome OS or on external media. The limiting factor for external media installs on this new Chromebook is the lack of a SD card slot. USB flash drives will have to do instead. The Sandisk Cruzer Fit might be an excellent option although speed may be somewhat lacking.

The HP Chromebook 11 will ship on October 20 and is available for pre-order from Amazon.com for $279.99. Google’s HP Chromebook 11 site also provides additional details on the device. I pre-ordered one and we’ll see how it works out with alternatives to vanilla Chrome OS. Hopefully some day we’ll see OpenBSD support for ARM-based laptops such as this one.

∞ Permalink

A particular program has been created for just this problem called Redshift. A quick look at the options in the man page and I had some good ideas but another search yielded the exact syntax I needed.

1

redshift -O 6500 -g 0.6:0.6:0.6

The idea is that -O manually sets the color temperature in one shot mode. The -g option does gamma correction. If you’re display is out of whack, you would have to adjust these values to whatever looks correct to you. Redshift is more powerful and can adjust the color temperature based on time of day and so forth but, at least for now, I’m only using it as a one time fix in .xinitrc.

If you’re in a purchase quandary, I would suggest purchasing a higher quality IPS display if possible but Redshift may still be useful to you.

∞ Permalink

A few days ago, I started working on setting up an OpenBSD instance in qemu to do some custom package building. I immediately ran into some issues with bridging the qemu network interface to the physical interface. The OpenBSD qemu port’s README file gives some indication of what to do but I couldn’t seem to get it functioning while running as a user other than root. I still plan to get this working right but, for the time being, I am using a simpler method running as root for now.

Before we get started, I should note that qemu provides its own built-in DHCP service and networking but setting up a bridged connection yourself allows for much greater flexibility and control over the process. There is also additional functionality not available with the built-in facilities.

I had talked to Andrew Fresh when we were in Portland in July about some scripts he wrote to launch flashrd instances under qemu. I encouraged him to make them available publicly and he did just that shortly thereafter. Those scripts were very helpful in this process, especially for the idea to use vether(4).

Settings up the interfaces and NAT

The basic concept is that we will have a virtual interface (vether(4)) that has an IP address, NAT that network through my main network interface, provide DHCP addresses to the virtual interface, and then bridge(4) the tun(4) interface to the virtual interface.

If you’re brand new to OpenBSD, I would suggest you familiarize yourself with the system conventions and configurations before getting into all of this but this is the general idea of what is needed.

First, I need to create a vether(4) interface. I’m going to do this by creating a hostname.if(5) for this interface. I picked a private address space range for this purpose in the 192.168.0.0/16 block. The /etc/hostname.vether0 file contains this:

1

inet 192.168.54.1 255.255.255.0 NONE

All of my qemu instances will be running on the 192.168.54.0/24 network which I will then NAT through my main network. I’m using macros in my /etc/pf.conf file but I will leave those out for the purposes of clarity. I added the following lines to /etc/pf.conf on my 5.4-current laptop above the default block and pass rules:

1
2
3
4

ext_if="iwn0"
int_if="vether0"

match out from $int_if:network to any nat-to ($ext_if:0)

These additions to /etc/pf.conf modify the existing rules in order to match all packets from the internal virtual network that are heading to another network. The $inf_if:network statement refers to the network associated with $int_if which is replaces with vether0 in my case. The network ends up being 192.168.54.0/24. The ($ext_if:0) part refers to the first address (referenced by :0) of the $ext_if which happens to be the address of the iwn0 interface. The parentheses around $ext_if:0 tell pf to update the address if it changes because it is a dynamic address. Without the parentheses, pf would statically use the current IP address which will change in the future.

Running pfctl -sr gives the following output:

1
2
3
4

match out inet from 192.168.54.0/24 to any nat-to (iwn0)
block drop all
pass all flags S/SA
block drop in on ! lo0 proto tcp from any to any port 6000:6010

The first line is the only one I added. Lines 2-4 were there by default. The macro definitions are not shown by pfctl -sr but are there in /etc/pf.conf.

The final part of the network interfaces is configuring tun0 and bridge0. I added the following /etc/hostname.tun0 which enables layer 2 operation via the link0 flag:

1

link0 up

I added the following /etc/hostname.bridge0:

1

add vether0 add tun0 up

With this completed, restart your network interfaces with:

1

sh /etc/netstart

DHCP and DNS

After the vether0 and pf.conf configs, the next step is configuring /etc/dhcpd.conf. I simply took the default /etc/dhcpd.conf and modified it according to what I needed:

1
2
3
4
5
6
7
8
9

option  domain-name "example.com";
option  domain-name-servers 192.168.54.1;

subnet 192.168.54.0 netmask 255.255.255.0 {
        option routers 192.168.54.1;

        range 192.168.54.100 192.168.54.199;

}

I then added the appropriate entry to /etc/rc.conf.local to launch dhcpd at startup:

1

dhcpd_flags=""

After getting dhpcd ready to go, the next step is providing a DNS resolver. Although it is possible to use some other resolver on the network, the easiest and most error-proof option is to install unbound from ports and configure it to allow requests on the localhost addresses and 192.168.54.1. I won’t go into the details here but this should be relatively easy once you install the unbound package or build it from ports and then modify /var/unbound/etc/unbound.conf as needed. Finally add unbound to the pkg_scripts line of /etc/rc.conf.local.

With these steps done, we can now move on to working with qemu directly.

Launching a VM

The first step is creating a virtual machine image using qemu-img.

1

qemu-img -f qcow2 first-image.img 10G

In this case, I created a 10GB image in qcow2 format. This is also a good time to download the latest iso image for OpenBSD from any OpenBSD mirror. I used install54.iso from the latest snapshot.

I used the following script to launch the qemu instance of OpenBSD with the intention of installing from the iso image:

1
2
3
4
5
6
7
8

#!/bin/sh

export ETHER=vether0
export BRIDGE=bridge0

qemu-system-x86_64 -m 512 -monitor stdio -vnc :0 -no-fd-bootchk \
   -net nic,model=e1000,macaddr=52:54:00:4e:62:8a -net tap \ 
   -hda first-image.img -cdrom install54.iso -boot d

This script launches an amd64 instance of OpenBSD with 512MB of memory, a VNC server running on port 5900, no floppy, a network interface using the e1000 driver with MAC address of 52:54:00:4e:62:8a (which should be changed), the network interface is bridged using tap, the 10GB image configured as the hard drive, the iso image configured as the cdrom, and the VM will boot from d which is the cdrom.

At this point you should have ssvnc installed from packages or ports and be able to connect to the newly created vm using vncviewer 127.0.0.1:5900 run from the local command line.

After installation, shutdown the VM by typing quit at the qemu prompt after you have done halt -p from the VM’s command line.

Next, modify the script by removing the -cdrom and -boot flags:

1
2
3
4
5
6
7
8

#!/bin/sh

export ETHER=vether0
export BRIDGE=bridge0

qemu-system-x86_64 -m 512 -monitor stdio -vnc :0 -no-fd-bootchk \
   -net nic,model=e1000,macaddr=52:54:00:4e:62:8a -net tap \ 
   -hda first-image.img

This will launch your OpenBSD instance. Access it via vncviewer as above and you are off and running. You can copy the script to make additional instances but create a new disk image and change the MAC address for each new instance.

Aftermath

I’m hoping that bhyve will support OpenBSD eventually. Although qemu works for now, it is very slow. I compiled dovecot and associated packages inside the qemu instance and it took hours. I was surprised at how long it actually took. Where qemu is especially useful is to test router configs and such like Andrew Fresh is doing as I mentioned above. Another idea I’ve had is to run a qemu instance of Debian and then rsync from it to OpenBSD in order to use Dropbox with OpenBSD. It would probably work fine but is a hack at best.

Until bhyve or other solutions are faster, I’m going to use SmartOS in the datacenter in order to facilitate OpenBSD VMs. I have been using it for about six months in brief stints and it seems to work quite well. OpenBSD also runs just fine under VMware ESXi with local datastores but I would rather focus on open source alternatives even though I am a VMware Certified Professional. If VMware completely moves away from its Windows requirement I would be more interested and it seems things are heading that direction.

In particular, thanks to Andrew Fresh for his scripts and Michael Dexter for keeping me up to date on bhyve and its progress.

∞ Permalink

I have always liked ARM devices due to their low power usage and, as I previously mentioned, I am very interested in running Ubuntu 13.04 on the ARM Chromebook once it is released on April 25. This new development makes the ARM Chromebook far more interesting for home use. Netflix is the best source of documentaries we have found and being able to play them on a compact device that is relatively inexpensive is a great option.

As another benefit, our daughter enjoys playing some educational web-based games that don’t work on an iPad or similar and the ARM Chromebook might just be a good solution for this as well. Using Mommy’s MacBook Air while Mommy needs to work doesn’t really work out.

It seems that the $249 ARM Chromebook is getting more and more potentially useful.

∞ Permalink

“With LTE, you can burn through a 5 GB data cap in an hour if you’re downloading big video files, and it would be easy to burn through the cap in just a few days if you’re streaming HD video — which, in 2013, is commonplace.”

Back in January, I had some major problems with my Verizon FiOS business connection where only the Verizon-provided ActionTec router would work. The rest of the details are for another post but I ended up using my Verizon 4G LTE USB data card as a stopgap until Verizon could do a truck roll. I only had the 4G LTE USB data card and router as our connection for about 36 hours and many of those hours were while we were sleeping. Using YouTube and a little bit of Netflix from our Apple TV units during that time we easily burned through 8GB of data. I had to upgrade our Share Everything plan with another 2GB so we didn’t go over that month.

I have been using 3G EV-DO since around 2005 just like Marco. The advent of 4G LTE has really transformed the way I use cellular data. I would absolutely love to have it built-in to a MacBook of any sort. As it is, I currently either have some sort of router in the car, occasionally use a MiFi device, or tether (actually using Personal Hotspot via WiFi for the most part) to one of our 4G LTE iPads. Marco also makes some good suggestions about what could be done.

“To start, Apple could just put cellular-connection detection and responsible-usage logic into iTunes and Software Update. That would be sufficient to launch with new 4G MacBook models at WWDC, then they could have a session on the new API and start enforcing responsible practices in the Mac App Store. Along with maybe working something out with Netflix, they’ll have addressed the biggest accidental bandwidth hogs that most people will face.”

It would be very disturbing to have the latest HD TV show episode, which easily tops 1.5GB, download in the background. Unlike with 3G, you might not even notice because 4G LTE is so fast. As Marco points out, it would also be essential to disable automatic software update downloading. As a technical professional, I would be willing to deal with these issues manually but most consumers would not want to be bothered and would not have any idea there would even be an issue until they started receiving data usage alerts or, even worse, a massive cell phone bill.

Built-in cellular connectivity in laptops is also mostly aimed at business users except in the case of the various Chromebook models. The Chromebook is unique in that everything is web-based and not very much data is transferred except for streaming media. Apple may not be including cellular data because of the focus on consumers rather than business users. In any case, I think Apple needs to create a new API for OS X as Marco suggested sooner rather than later. Apple can obviously implement 4G LTE cellular data just fine in the iPhone and iPad lines so I hope the MacBook lines are the next frontier. The next generation MacBook Air seems like the perfect candidate to me.

∞ Permalink

Due to my use of iOS devices like the iPhone, iPad, and iPad mini, I have not been interested in any Android devices. None of the available devices have had any advantages over whatever iOS devices I have been using at the time. That appears to be changing but it has nothing to do with Andriod. I still have no interest in Android at all but I do have an interest running Ubuntu on a tablet. As was announced a couple of weeks back, Ubuntu is pushing into the phone and tablet markets.

A couple of days ago I discovered the Ubuntu installation instructions for the Nexus 7 tablet. I’m interested in any feedback from someone who has tried this process. I will probably wait until after Ubuntu 13.04 is released on April 25, 2013 but running Ubuntu on a Nexus 7 might just be worth it.

∞ Permalink

Like Linux Mint 14, quite a few other distros are based on a Ubuntu core. One I had never heard of before is elementary OS.

The above screenshot of a Pantheon desktop sure looks like what I like in Apple’s OS X. The dock at the bottom and menubar at the top is great. I’m tired of the Windows-modeled taskbar at the bottom that KDE, Cinnamon, and most other desktop environments employ. I also just discovered that version 4.10 of Xfce appears to have some similarities to OS X as well.

I am put off somewhat by elementary OS Luna’s status as Beta 1. There still appears to be some work to do to get to a stable release but once it does, elementary OS looks like it might be a very attractive option. If elementary OS interests you, now is a great time to get involved.

∞ Permalink

Google is quite literally targeting business users with the Chromebook Pixel. Most consumers will not spend $1299 for a WiFi Chromebook or $1449 for a Chromebook with LTE. Google Apps for Business is now used by many, many businesses and much of what typical computer users do is covered by a Chromebook and Google’s array of services. Another advantage of the Chromebook Pixel is that companies do not need to worry about lots of software upgrades and system management as would typically be true of a regular PC system.

The hard sell is for power users. I would never buy a Chromebook Pixel for $1299 just to run Google web apps. The latest ARM-based Samsung Chromebook, on the other hand, is a much easier sell for $249. I can definitely understand buying one for the kids or just to do some browsing and writing around the house or out and about. In my opinion, the true interesting use case of the ARM Chromebook will be running Ubuntu 13.04 for ARM when it comes out in April.

Hopefully installing alternate operating systems on the Chromebook Pixel will not be too difficult since it uses a standard Intel Core i5 instead of a different architecture like the ARM Chromebook. I’m glad to see Google making such an interesting Chromebook in the Chromebook Pixel. Perhaps other companies will follow suit with excellent designs that might pose options if you want to run open source operating systems with design similar to Apple’s excellent designs.

∞ Permalink

∞ Permalink

There will also be more articles about photography, videography, camera bags (like Think Tank Photo gear), and related media technology. Storage technologies have been getting better. More articles are coming about SSDs, moving away from hard drives, and offsite backup.

A few months back I became a VMware Certified Professional on vSphere 5 – Datacenter Virtualization, better known as a VCP5-DV. I have been working on some datacenter solutions that I will be writing about shortly. Virtualization also plays a big part in allowing us to embark on our major new project.

Check back for more exciting articles in the pipeline and the launch of a new web site related to the major change. I will also be following up on some questions I have received over the last few months. I think 2013 is shaping up to be an unforgettable year!

∞ Permalink

Which to buy? It’s a hard choice. In every way but the display, I would prefer the iPad mini. I expect that in the next revision or two, the iPad mini will also get a Retina Display. Once that happens it will be no contest and I would definitely recommend the iPad mini for nearly all scenarios. For my uses, the iPad mini will be my choice. I am currently using a 3rd generation 32GB iPad with Verizon 4G LTE. This will shortly be replaced by a 64GB iPad mini with Verizon LTE.

∞ Permalink

Configuration

I configured the X230 with the following options direct from Lenovo:

• Intel Core i7-3520M (2.9GHz with 4MB of Cache, up to 3.6GHz Turbo, HD 4000 Graphics)
• 12.5-inch Premium IPS HD LED Screen (1366x768) with 3x3 Antenna
• 4GB of 1600MHz DDR3 (the minimum)
• Backlit Keyboard
• UltraNav without FingerPrint Reader
• 320GB Hard Drive, 7200RPM
• 9 Cell ThinkPad Battery X44++
• Bluetooth 4.0
• Intel Centrino Ultimate-N 6300 AGN Wireless

As is obvious from my system choices, 4GB of memory will not be enough but astronomical memory upgrade prices from Lenovo make third party memory the only reasonable choice. The hard drive is also likewise useless to me and was never even powered on before its removal from the X230. Due to the slim size of the X230 I also elected not to have a webcam built into the display bezel and instead chose the 3x3 Wireless Antenna option which allowed me to choose the Intel 6300 AGN Wireless card. I have other systems to use for video conferencing and I would rather have better wireless performance.

Memory

I ordered the Corsair Vengeance 1600MHz Laptop 16GB (2 x 8GB) memory kit which maxed out the memory capacity of the X230. This makes more sense for my virtualization projects. I just make it a practice to max out the memory on whatever system I purchase these days.

SSD Storage

After the memory, the next major upgrade is storage. Since I had already removed the 320GB drive, I needed to put two SSDs into the system. When I removed the 320GB drive I discovered it was a Seagate Momentus Thin drive. This means it has a 7mm z-height. The majority of 2.5-inch drives have a z-height of 9.5mm. Some older, high-capacity drives had a z-height of 12.5mm and a few oddball large storage 2.5-inch drives have a z-height of 15mm.

The 7mm z-height posed an immediate problem. I was planning to install my 512GB Crucial M4 or my 240GB Intel 520 SSD in the X230 but neither would fit properly. The 240GB Intel 520 SSD could be made to fit by removing the plastic bumper but this also required removing the screws which hold the SSD’s cover on. Within the X230’s hard drive bracket this posed no issue but I wasn’t really comfortable with that solution. The Crucial M4 SSDs I had were all 9.5mm. At this point I discovered that there are 7mm versions of the Crucial M4 SSDs in the form of the SSD1 models. The 512GB I had was model CT512M4SSD2. The very similar but 7mm z-height version is model CT512M4SSD1.

At this point, I decided to sell both my Intel 520 SSD and the 512GB Crucial M4. I started researching the best large 7mm SSDs. I came to the conclusion that the Plextor M5 Pro would be a superb option. Plextor has done a great job with their M3 Pro series of SSDs and the M5 Pro would be even better.

I ended up ordering the PX-512M5P SSD which is a 512GB 7mm z-height SSD. I’ll have some followup on this SSD in a future article but so far I think Plextor has done a fantastic job with the M5 Pro series.

I mentioned that I was going to install two SSDs rather than just one. Very few slim laptops support two SSDs but the X230 has the advantage of a Mini-PCIe slot that also supports mSATA SSDs. This slot is normally intended for 3G/4G mobile broadband cards such as the Gobi 3000 or Gobi 4000 cards offered by Lenovo. Since I am not running Windows, the usefulness of such a card would be diminished. I already have several mobile broadband routers from CradlePoint and a MiFi unit as well.

Since the mSATA/mPCIe slot is unused, I decided it would be a perfect place to install a Crucial M4 mSATA SSD. The largest available size is the 256GB size which is model number CT256M4SSD3. I wish a 512GB version were available but perhaps one will come as flash chips shrink.

Operating Systems

I have never been a fan of multi-boot installations on one storage device. The risks of corrupting one or both installations is very high as upgrades are done. On systems where I have been using multiple operating systems, I always dedicate a storage device to each operating system. The ability to install a 2.5-inch SSD and an mSATA SSD in the X230 allows me to do the same thing with this system.

I immediately installed OpenBSD on the 256GB Crucial M4 mSATA SSD. As I’ve noted before, OpenBSD is my favorite open source operating system and the operating system I would use nearly full time if I were able to.

Because of my virtualization work, I need to use an operating system that can run VMware Workstation 9. This means one of the Linux distributions for now. (I wish VMware would support FreeBSD again as they did in the past.) I initially installed Ubuntu Desktop 12.04 LTS which seemed to work all right at this start. Within a few days I started running into problems with system freezes due to the 3.2 kernel not having very mature support for Intel HD 4000 Graphics. This forced me to move to Ubuntu Desktop 12.10 Beta which brought its own sets of problems including an incompatibility with the 3.5 kernel and VMware Workstation 9. This has since been corrected in VMware Workstation 9.0.1.

As is typically expected with a beta, I also experienced many crashes of various programs. After the final release of Ubuntu Desktop 12.10, I erased the SSD and reinstalled. Unfortunately, no matter what I did, I still experienced crashes in various elements of the Ubuntu install. Most were just annoying but I got tired of the dialog boxes popping up indicating a crash had happened. I also found that system settings did not stick across reboots and the init scripts for VMware Workstation stopped the login screen from loading unless I disabled the VMware scripts and started them manually after login.

A few weeks ago I decided enough was enough. I have used Gentoo Linux in the past but wasn’t sure I wanted to sign up for that many hours of compiling. I also didn’t want to put in the time to figure out exactly what optimized set of USE flags I needed. I had briefly installed Arch Linux in a virtual machine but had heard it offered many of the advantages of Gentoo but without quite as much work.

I went ahead and installed Arch Linux with the December install media. This installed kernel 3.6.9 to begin with and has now been upgraded to 3.6.10. One of my favorite parts of OpenBSD is using the cwm window manager and I can do the same with Arch by installing cwm from the AUR.

My OpenBSD and Arch environments are now nearly identical for desktop tasks. My shortcuts are the same, my applications are the same, and everything looks almost identical. My typical environment includes running multiple xterms with vim, tmux, and mutt. Chromium is running in my second workspace and then additional applications in my third and fourth workspaces. VMware Workstation 9 is running in my third workspace with my OpenBSD install on the mSATA SSD running as a VM.

I am actually writing this article from a terminal session in my OpenBSD install that I accessed via SSH from my Arch Linux install. There are a few things to get used to with Arch like systemd but I’m pretty happy with my choice. As I use it more I will get more familiar with its quirks.

I am actually pretty disappointed in Ubuntu. I thought Ubuntu might be a viable alternative to OS X on the desktop but, at least in my case, it is so unstable that I could never depend on it for my work. Perhaps it is because the X230 is using the latest Ivy Bridge integrated graphics rather than a discrete graphics card or an older integrated graphics chipset but, whatever the issue, the constant crashes are a show stopper for me.

Arch, on the other hand, has not crashed in any way since I installed it. Battery life is superb since I’m running a very low resource window manager rather than a complete desktop environment and still everything works great for my needs. No, I don’t have a fancy file manager to drag and drop files in but I don’t need it. The tried and true mv command works just fine for me.

I should note that it is possible to configure an Arch Linux system with a full desktop environment similar to what Ubuntu uses but I have no interest in this configuration since I prefer cwm.

Conclusion

In the end, the ThinkPad X230 is a superb system that I am very happy with. Running both OpenBSD and Arch Linux has turned out to be a great combination. The X230 will not supplant my OS X systems for media and other related tasks but for system administration and writing, the X230 setup works perfectly. VMware Workstation 9.0.1 also works perfectly and allows me to run a variety of other environments without fully committing to the operating system by directly installing it on a storage device. I am especially happy that I can use the same OpenBSD install on the mSATA SSD natively and also through VMware Workstation. I highly recommend the Lenovo ThinkPad X230.

∞ Permalink

I want to wish everyone a Merry Christmas. I hope that all of you have been able to focus on family, friends, and God, the source of all our blessings. In the next few days as 2012 winds to a close, remember the things that have been most important to you over this year and each year before it. Cherish the most important things in life.

We have some amazing new plans for 2013 that we will reveal as the time gets closer. Look for updates over the next three months as everything falls into place. I will continue writing more articles as well. Some personal events in the last few months have kept me from writing very often but that will be changing as we go into 2013.

∞ Permalink

I’m happy that Marco is still planning to be involved in podcasting as he stated in his November 18th post:

After Build and Analyze ends, I’d like to take a few weeks off for the holidays, be a guest on other shows, and then experiment with new shows, topics, and formats to try to figure out what I want to do next in the world of podcasting.

I’m looking forward to what’s next in the new year.

∞ Permalink

I have used OpenBSD for almost 15 years now and have always enjoyed its simplicity, security, and robust feature set. I have also been a Mac user for even longer. Due to my work, I can’t switch to OpenBSD entirely on the desktop but I can use it for much of what I do.

I came across a few different articles on the subject of encrypted softraid(4) for the root filesystem but all seemed to cover aspects that didn’t entirely fit my goals. One softraid article has much of the information needed but does not encrypt the entire system, only one filesystem.

In my own personal, non-server systems, I rarely separate out all of the different directores into their own filesystems like /var, /usr, /home, etc. On my ThinkPad X230, this is further compounded by the fact that I am using a relatively small SLC SSD which means I really don’t want to limit my options with unnecessary filesystem complexity.

My goal is simple. I want the entire root filesystem which encompasses everything on this system to be encrypted with softraid(4). I will have a very small swap partition on the SSD since swap is always encrypted in OpenBSD anyway.

Warning: I should also note that the process of creating an encrypted softraid(4) partition on your drive will destroy whatever data you have on there already so make sure you backup everything before starting this process in a way that you are prepared to restore from. Even better, buy a new SSD and start from scratch.

Choosing the SSD

In a future article, I will cover what configuration of ThinkPad X230 I purchased but for now I will just mention storage. Rather than pick the ridiculously overpriced storage available direct from Lenovo for the X230, I simply purchased the system with the cheapest storage available which was a 320GB 7200RPM 2.5-inch laptop drive. It wasn’t spelled out clearly during the configuration stage but this is a 7mm 2.5-inch drive, not the typical 9.5mm 2.5-inch hard drive form factor that we have become accustomed to for laptops. This doesn’t bother me at all since HGST and Seagate both make plenty of 7mm options now and SSDs are also readily available in the 7mm form factor.

The particular drive my X230 shipped with is a Seagate Momentus Thin 320GB 7200RPM 2.5-inch drive. As I have done with all my non-Apple system for a number of years, I had no intention of using the original drive at all and so without even booting up the system, I removed the 320GB drive and set about installing another storage device. As I’ve covered extensively in past articles on SSDs, I use SSDs exclusively for my main systems and only use actual hard drives for bulk media storage, backups, and server arrays.

SandForce is Out

When choosing an SSD for software encryption, a number of parameters change in how you should pick the best SSD for your system. First off, any SSD that uses a controller that does compression in order to achieve its performance is out of the question. This is because any software encryption solution causes the data written to disk to be essentially random in nature and completely unable to take advantage of any compression.

The major SSDs on the market using compression are using the LSI SandForce line of controllers. The list includes many of the popular SSDs and one of my favorites that I highly recommend, the Intel 520 SSD series. While I still use and recommend the Intel 520 SSD series as my laptop, desktop and workstation top choice, they are a poor choice for software encryption.

mSATA and 7mm 2.5-inch SSDs

There are a number of other good choices on the market now but one particular consideration stood out in my mind for this system. The ThinkPad X230 features a single 7mm 2.5-inch hard drive or SSD bay but also has a mini PCIe slot that also accepts mSATA SSDs. In some configurations, the mini PCIe slot is taken up by a 3G or 4G WWAN card such as the Gobi 3000 or Gobi 4000. For this system I elected against a built-in card for now until I have some time to test OpenBSD 4G LTE support.

My plan for the X230 has been to have two different SSDs installed, one in the 2.5-inch bay and another in the mSATA slot. One of the two would house an Arch, Gentoo, or Ubuntu install and the other SSD would contain my OpenBSD install. The 7mm restriction changed my plans somewhat and so far I am only using OpenBSD on my X230.

Since software encryption can be even more write-intensive than typical SSD use and cannot take advantage of compression to minimize write amplification I decided to look for an SLC SSD. The benefits of SLC over MLC flash have been extensively covered by many articles but for the sake of simplicity the major benefits of SLC are exponentially higher write endurance, lower power consumption, and increased speed in similar configurations. The final benefit has been reduced by more and more advanced controller configurations that have allowed MLC to meet or exceed the typical performance of SLC-based SSDs.

I started looking around at my mSATA SSD options and SLC options in general and only one contender emerged as my best choice. Intel has consistently made excellent and very stable SSDs since the beginning of readily available SSDs in the retail market. I have been extremely happy with the Intel 520 SSD series so it was only natural to start looking at the Intel 313 SSD series.

Intel 313 SSD Series

The 313 series is the successor to the 311 series and is designed as a cache SSD for the Intel Rapid Start Technology present in some Sandy Bridge and Ivy Bridge motherboard chipsets. As such, the 313 series uses SLC flash memory since any type of cache drive will see extensive writes. As expected, the 313 series offers relatively small capacities. Only two Intel 313 SSD capacities are available. The first is a 20GB model and the second is a 24GB model. Both capacities are available in both a 7mm 2.5-inch and an mSATA form factor.

This makes for a total of four different configurations available in the Intel 313 SSD series. Since I would prefer to have as much capacity as possible while still using SLC flash memory, I elected to purchase the 24GB mSATA model which, while not particularly large, is quite adequate for my OpenBSD use.

Installing any mSATA SSD in the X230 is a challenge but proved to be quite interesting and enjoyable. I will not cover the details in this article but I am glad to have it installed and will likely not touch it again. One major caveat is that nearly all mSATA slots are SATA 3Gb/s and not 6Gb/s. This means that the Intel 313 SSD’s limitation of SATA 3Gb/s is really not a limitation at all.

The softraid(4) Install

In order to do your softraid(4) crypto install, the first step is to boot into the OpenBSD installer with bsd.rd and select the Shell option. Once in the shell, you need to create the softraid volume but first you need create some additional devices. I should make note that all of this is on OpenBSD/amd64 5.2-current. In the shell, run the following commands assuming your SSD shows up as sd0:

1
2
3

# cd /dev
# sh MAKEDEV sd1
# sh MAKEDEV sd2

Now that you have some additional sd devices, it is time to create partition your SSD for maximum efficiency. In order to boot from any softraid(4) partition other than a RAID 1 on OpenBSD/amd64 5.2 or later, you need a small a partition to hold your kernels. Here are the needed steps to prepare your SSD.

1

# fdisk -iy sd0

This command initializes your MBR with an OpenBSD primary partition in preparation for disklabel(8). The next step allows you to create the needed partitions for OpenBSD.

1

# disklabel -E sd0

At this point using the built-in editor for disklabel(8), you should be able to add several partitions. The first, a, should be large enough to hold the three kernels typically used for any system, bsd, bsd.mp, and bsd.rd. I use 64M for the size of the a partition which ended up being rounded to about 70MB. I added a swap partition of about 32MB and then dedicated the rest of the SSD to the RAID parition. Here are the partitions for my SSD as viewed from disklabel(8):

1
2
3
4
5

#                size           offset  fstype [fsize bsize  cpg]
  a:           144512               64  4.2BSD   2048 16384    1 
  b:            64257           144576    swap                   # none
  c:         46905264                0  unused                   
  d:         46684902           208833    RAID                   

In order to have a softraid(4) crypto root filesystem work at bootup, you must use a keydisk. Unfortunately, there is no way to assemble the softraid volume by prompting for a password. To this end, I used an SDHC card I had lying around. It happened to be a 4GB Lexar Professional SDHC card but any card will do. I added a very small (1MB is fine) partition to it using disklabel(8). I used the rest of the SDHC card for an a partition. In this case, I used the d partition for the keydisk and created it at the beginning of the SDHC card. Here is the output of disklabel(8) for sd1, the device name of my SDHC card.

1
2
3
4

#                size           offset  fstype [fsize bsize  cpg]
  a:          8032448            16096  4.2BSD   2048 16384    1 
  c:          8057856                0  unused                   
  d:            16001               64    RAID                   

Now that I have both a prepared SSD and a prepared keydisk, it is time to format the a parition on the SSD for the kernel, and create the softraid volume which will utilize the keydisk.

1
2

# newfs /dev/rsd0a
# bioctl -c C -l /dev/sd0d -k /dev/sd1d softraid0

You should now see output on the screen something like this for your new SR CRYPTO volume.

1
2

sd2 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd2: 22795MB, 512 bytes/sector, 46684374 sectors

At this point you can also format the a volume of your SDHC card but you can always do that later. The next step is to continue with the OpenBSD installer.

1
2

# cd /
# install

Proceed through the whole process but use sd2, or whatever your SR CRYPTO volume shows up as, as the root disk. In my case, I only created an a partition on sd2 that encompasses the entire SR CRYPTO volume since I already have a small swap partition on the SSD itself. Once the install is completed, you have two final steps.

1
2
3

# mount /dev/sd0a /mnt2
# cp /mnt/bsd* /mnt2/
# /mnt/usr/mdec/installboot -v /mnt/boot /mnt/usr/mdec/biosboot sd2

The installboot(8) command will generate output similar to the following:

1
2
3
4
5
6
7
8
9
10

boot: /boot proto: /usr/mdec/biosboot device: /dev/rsd2c
sd2: softraid volume with 2 disk(s)
sd2: installing boot loader on softraid volume
/boot is 3 blocks x 16384 bytes
sd0d: installing boot blocks on /dev/rsd0c, part offset 208913
master boot record (MBR) at sector 0
        partition 3: type 0xA6 offset 64 size 46893671
/boot will be written at sector 64
sd2d: installing boot blocks on /dev/rsd2c, part offset 80
master boot record (MBR) at sector 0

With those steps completed, your softraid(4) crypto install is done and you should be able to boot from your system as long as the keydisk is available. Remember that if you somehow do not have your keydisk, you cannot access your data. It is a good idea to backup your keydisk if possible as mentioned in an older OpenBSD Journal article. In my case I only backed up sd1d and not sd1c like the article suggested.

Final Thoughts

The whole process went rather smoothly once I discovered that a keydisk is required for a bootable softraid(4) crypto root filesystem. Normally, you would have to assemble the softraid volume which then asks for your password by just running the following after booting up your system:

1

# bioctl -c C -l /dev/sd0d softraid0

The keydisk is what makes all the difference for allowing a bootable encrypted root setup. My attempts without a keydisk always ended in a kernel panic. So far performance seems excellent although I haven’t done any major testing. For my needs the system is extremely responsive and everything is encrypted.

I would recommend that you use the softdep and noatime flags in your fstab for your filesystem since softdep will increase your filesystem’s performance and noatime will cut down on unnecessary writes to your SSD. For details of both options and how to use them, read the fstab(5) and mount(8) man pages.

I would caution anyone considering this type of setup to only use it with a machine where the processor supports AES-NI or your processor will have to work very, very hard to do the encryption on the fly. Any recent Core i5 or Core i7 does support AES-NI as do Xeon E3 chips and a few others as well. Celeron, Pentium, and Core i3 chips do not have support for AES-NI as an almost universal rule.

I am enjoying my ThinkPad X230 with OpenBSD so much that I will likely just keep it an OpenBSD-only system instead of the dual-SSD OpenBSD and Ubuntu system that I had originally planned.

Update: tedu@, one of the OpenBSD developers, provided some additional insight in a comment on Lobste.rs. He pointed out that for file sizes less than around 1GB, AES-NI hardware acceleration makes little difference. Essentially, normal desktop tasks without large file copies will not benefit very much from AES-NI. He also pointed out that the buffer cache is not encrypted so frequently used programs do not have to be decrypted each time they are used.

∞ Permalink

I asked Kyle Isom, an experienced C programmer, if he had any recommendations. He suggested a few more good resources. The gold standard for C books is The C Programming Language by Kernighan and Ritchie. This is often abbreviated as C by KNR. Another excellent introduction was put out by Stanford in the form of a 45 page document called Essential C.

Some more advanced books which are excellent are Advanced Programming in the UNIX Environment and The Linux Programming Interface often abbreviated as TLPI. I had already purchased TLPI based on the recommendation of Mitch Haile, another experienced developer. The author of TLPI, Michael Kerrisk, contacted me on Twitter after I discussed the book with Mitch. Michael is very, very nice and I appreciated his comments and suggestions.

Kyle’s final recommendation was the ever useful C Pocket Reference. My intention in this process of learning C is to do some OpenBSD development. I will be documenting this process here all along the way.

∞ Permalink