Author Archives: Christer

Running Dell DSET 3.2 on CentOS 6.2

Earlier today I was working with Dell Support to gather information about a broken system. It was suggested that I use their DSET utility to gather data and return a report. The problem is, DSET doesn’t natively support CentOS, so some tweaks were needed in order for it to run properly. In this post I’ll outline the changes I needed to make in order to run DSET on CentOS 6.2.

Step 1: Download the DSET utility using wget.


Step 2: Create a working directory and extract the archive
mkdir ~/dell
tail -n+20 dell-dset- | tar -xzv -C ~/dell

Note: If you get an error saying that the file is not in a valid archive format, you may need to alter the tail command slightly. Use the following command to determine the line at which the archive begins:
awk '/^__ARCHIVE_BELOW__/ {print NR + 1; exit 0; }' dell-dset-

Step 3: Trick the installer into thinking you’re running a supported OS
The installer uses the /etc/issue and /etc/redhat-release files to determine the operating system. The trick here is to update those files on your system to match one of the supported operating systems listed in the included archive. Look at the support_os_list file found in your working directory (~/dell), and update your files to match one of the listed systems. For CentOS 6.2 I used the Red Hat Enterprise Linux Server release 6 x86_64 entry.

cp /etc/issue{,.bak} && echo 'Red Hat Enterprise Linux Server release 6 x86_64' > /etc/issue
cp /etc/redhat-release{,.bak} && echo 'Red Hat Enterprise Linux Server release 6 x86_64' > /etc/redhat-release

Once this is done you can try to run the installer found in your working directory (~/dell/

Announcing: Into The Salt Mine

I’ve started a new blog that I’d like to announce called Into the Salt Mine. This blog will focus solely on using the suite of free software applications developed by Salt Stack. This includes configuration management, remote execution, cloud provisioning and more. The goal is to provide regular tips and updates on managing systems using Salt and related tools.

If you haven’t heard of Salt yet, I’d highly recommend checking out the 30 second summary and consider using Salt to manage your systems.

Creating symlinks with Salt States

This morning I finally found a solution to improving vim-usage on my FreeBSD machines. For the longest time I’ve dealt with little annoyances like arrow-keys entering ABCD characters, and backspace only working in certain situations. As it turns out, all I needed was to import a proper vimrc file. As soon as I had tested the fix, I expanded my vim Salt State to include a symlink to the included example vimrc.

- target: /usr/local/share/vim/vim73/vimrc_example.vim

This state breaks down as follows:

/root/.vimrc – File to create
file.symlink – Use the symlink function (others include file.managed, and
-target: /usr/local/share/vim/vim73/vimrc_example.vim – Path to original file

Finally I applied the state using the state.sls module, applying only the vim state:

[root@starbuck ~]# salt-call state.sls vim
State: - file
Name: /root/.vimrc
Function: symlink
Result: True
Comment: Created new symlink /root/.vimrc
Changes: new: /root/.vimrc

How to enable ccache with OS X MacPorts

I’ve had a 13″ Macbook for about your years now. When I learned about MacPorts I was really happy to know I could run newer software, and compile things to my liking. These days I run a development environment on my Macbook, all built using MacPorts.

This post covers how to leverage ccache in compiling your MacPorts. ccache is a compiler cache utility that increases the efficiency of your compiles by reusing cached build data, often improving build times by 5-10 times!

Step 1: Install ccache

sudo port install ccache

Step2: Edit macports.conf”

Open /opt/local/etc/macports/macports.conf in your favorite editor. Find the line ‘configureccache’ (near line 65)

configureccache no

and change it to

configureccache yes

You’re done! New compiles will now use ccache.

note: ccache stores it’s cached date in your home directory, ie; /Users/$username/.ccache. It defaults to a maximum cache storage size of 1G. You can find out more about the ccache settings via the ‘ccache -s’ command.

Dell Latitude E5500 Wireless Fedora 14

Dell Latitude E5500 Wireless – Fedora 14

I recently needed to send my main work machine in for repairs so I temporarily used a Dell Latitude E5500 while my normal D630 was away. Boy did I have trouble with the hardware on this machine! This blog post is a meagre attempt at outlining what was required of me to get some hardware supported. Hopefully this helps some other poor soul along the way.

Wireless Driver

In order to enable Wireless on the Dell Latitude E5500 (bcm4322), you’ll need to follow the steps below. This requires a “nonfree” driver from the rpmfusion repository, as well as an addition to the kernel parameter in GRUB. It’s not so bad once you know the requirements, the trouble is finding the requirements (again, the reason for this post!)

Install the rpmfusion nonfree repository using the command:

rpm -Uvh

With this repository now added, you’ll be able to install the broadcom-wl package.

yum install broadcom-wl

Kernel Parameters

The last addition you’ll need to make is to append a parameter to your kernel configuration in GRUB.  Append the following to GRUB on the kernel entries:


Reboot your machine, and when you come back up you should be online!

I hope these little tips help someone else get wireless running in Fedora. Lack of wireless sure can be a deal-breaker. Here’s to winning that battle!

Freenode IRC over SSL in Irssi – FreeBSD

I’ve been reconfiguring my Irssi installation this morning and wanted to document the steps I took. I use irssi on FreeBSD 8.0-RELEASE.

Required Certificates

In order to connect securely over SSL to freenode you need to ensure you have the certificate installed. On FreeBSD, this port is ca_root_nss.

portmaster security/ca_root_nss

Configure the Network and Server

/network add -nick 'nick' -realname 'real name' freenode
/server add -auto -ssl_verify -ssl_cafile /usr/local/share/certs/ca-root-nss.crt -network freenode 7000

Note: If the blog wraps the content, there are three commands above, prefixed with /. /network, /server and /save.

Now, when you open irssi, you’ll automagically connect to Freenode over SSL.

Configure Lighttpd for gitweb on FreeBSD

I spent some time this afternoon setting up a public git repository for my project, Origami. I had a little bit of trouble getting the repository set up initially, particularly the cgi aspect of it all. Below outlines the steps I took to configure Lighttpd for gitweb, hosted on FreeBSD.


First, of course, I installed the git port:

portmaster devel/git

I made sure to select the gitweb option, which is de-activated by default. The other options are up to you.


Second, I configured Lighttpd in the simplest manner I could find. This solution uses the existing gitweb files in-place. This is contrary to what the pkg-message prescribes, but I like this idea because it’ll ensure that upgrades are handled automatically. I don’t plan to run any additional repositories either, so using the one central set of files is preferable in my situation. This is my configuration:

$HTTP["host"] =~ "^" {
$HTTP["url"] =~ "/gitweb/" {
server.indexfiles = ( "gitweb.cgi" )
alias.url += ( "/gitweb/" => "/usr/local/share/examples/git/gitweb/" ),
cgi.assign = ( ".cgi" => "/usr/bin/perl" )

Repository Configuration

Lastly, I update the repository configuration in /usr/local/share/examples/git/gitweb/gitweb.cgi to my repository location:

our $projectroot = "/path/to/git/repository/"


I find that Lighttpd configuration, once you get used to it, is much simpler than Apache configuration. It’s all a matter of taking the time to learn the options (and finding examples, like this one) and it gets simpler.

I think this configuration for gitweb is very clean, requires minimal configuration additions, and is hopefully pretty self explanatory. I hope it works for you as well.

Arch Linux 2010.05 Installer Issue [FIXED]

I reinstalled my Dell Latitude D630 this afternoon using the new Arch Linux installer (2010.05) netinstall. I had an issue however where the live image would start to boot and then I’d get a blank screen. I quickly realized what the problem was, and found a fix.

Note: it looks like it is a similar issue to the one found here.

Basically, the fix that I found, was to append the following to the kernel line at the initial boot prompt:


This is done by hitting the [TAB] key at the boot prompt of the installer and appending that text to the end.

I wanted to get this out in hopes that it’d help others with the same problem.

Good luck, and happy Arch’ing.

Configure Serial Console Access on CentOS 5

Today I built some virtual machines on a KVM platform (Ubuntu 10.04 Server as the host). The three virtual machines are CentOS 5, i386 and will be used primarily for internal application testing. One of the requirements for using these machines in a virtual environment was configuring back-end console access from the host. The virtual machine management tools (virsh) provide custom commands to console into your guest machines, but the guest machines need to be configured to output to the proper console. This article outlines what customizations I made to the CentOS 5 virtual machines in order to console into them from the host using ‘virsh console <guest>’


The first modifications that I needed to make were in GRUB. On CentOS the GRUB config file can be found at: /boot/grub/menu.lst. Below you’ll find the changes I made:

serial --unit=0 --speed=115200
terminal --timeout=10 console serial

I’m sure if you compare that snippet with your current configuration you’ll see the changes that I’ve implemented. Primarily the commenting of the splashimage, and the addition of the serial and terminal lines.

In addition to these changes you’ll also need to append some console configurations to each ‘kernel’ line. Here is an example:

title CentOS (2.6.18-164.15.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-164.15.1.el5 ro root=/dev/SLIM/root console=tty0 console=ttyS0,115200n8

Again, compare this to your current configuration. You’ll notice I’ve added console=tty0 console=ttyS0,115200n8


Finally you’ll need to make a change to the /etc/inittab file, which will allow login via the serial console connection:

S0:2345:respawn:/sbin/agetty ttyS0 115200 linux

Once these changes have been applied you should be able to reboot and connect to the console:

virsh console <guest> should then display the GRUB menu, boot output and finally a login.

Lighttpd on FreeBSD : Hard Lock on Upload?

I’ve recently migrated my server(s) to a new VPS, one which offers BSD as a hosting option. I have long been a fan of FreeBSD on my servers, so this was a deal I couldn’t pass up. I did, however, run into one fairly difficult problem based on my combination of FreeBSD and lighttpd web server. I felt it was important to blog about it so that “teh internets” could share the wisdom and, hopefully, others could solve this same issue quickly.


The web server seemed to work great. It was handling traffic efficiently. Logs were going where they were expected. Rewrites were working. All the main things that I would expect to test were working just fine. And then I uploaded a file.

Hard lock. Panic. Do not pass go. Do not collect $200. This was bad.

I was even able to reproduce it. Anytime I would upload a file to the server (in my case via WordPress upload form), the server would hard-lock and I’d have to manually bring it back up.


The solution was to manually define the value, instead of using the auto-detected value. Apparently, at the time of this writing, the auto-detection on FreeBSD is.. less than perfect. The solution that I found was to add the following line to my lighttpd.conf: = "writev"

After restarting the lighttpd service things seemed to perform as expected.


FreeBSD is a great, stable hosting platform. Lighttpd is a lightweight, efficient web server. Together they provide me with a very efficient, stable web hosting environment. The simple detail is to define the right parameters for the platform in the configuration.