Unattended Ubuntu installs, part 2

In my initial post about unattended Ubuntu installs, I made the less-automated choice of hacking at the Ubuntu installation ISO and baking my preseed configuration right into the ISO. This proved to be incredibly inefficient and prevented a lot of the customization and quick-spin-up potential of what I interested in. In other words, if I wanted to spin up five identical VMs differing only by their hostname, was I really expected to bake five custom ISO’s whose preseed file only differed by their specification of the hostname?

Solution: With a bit of Internet poking, I found that you can specify the URL of a preseed file, accessible via HTTP, for your VM to read during OS installation as a kernel boot parameter. Given all this, there really was no reason to bake my own ISO in the first place. I had to test using virt-install specifying all these parameters on the command line, including using a straight Ubuntu install ISO. Results? Success!

For those curious of the command-line I used:

Preseed file: This file can live on any accessible-from-your-VM http server. During the install process, it is retrieved via wget as part of the install procedure. But how do you specify the URL for the preseed file?

The only one modification I did have to make to my preseed file had to do with selecting a mirror. I was constantly prompted to select a mirror hostname. After another couple Google searches, I was left with what seems to work, by default picking a US-based HTTP mirror for Ubuntu packages:

Enjoy!

Look ma’, no hands with Ubuntu installs.

In my day job, it’s all about automation. Automate what is repeatable, and move on to more interesting and not-yet-automated tasks. For a while, I’ve run a KVM/libvirt setup at home, running various iterations and distributions of Linux, OpenBSD and FreeBSD for various pet projects. Going through each distribution’s install procedure was getting old, requiring me to input the same parameters, set up the same users and passwords, over and over again. Given I use Ubuntu mostly as a VM guest, I dug into their preseed infrastructure, to be able to automate the installation and get me past the drudgery of adding another VM. Below are the steps and a bit of sample configuration that got me through the process.

I did find some examples of automating this all the way from virt-install (libvirt’s way of adding a VM instance to your cluster), but that is for another time.

[Update 2014-09-13: Even more unattended. Part 2]

Continue reading

i3wm, i3bar, and rhythmbox

I was interested in customizing my i3wm setup a bit more, and wanted to display the current song playing in Rhythmbox while running the i3wm window manager.  It turned out to be just a few lines of configuration to my i3bar config.

First, I grabbed a copy of the Python wrapper around i3bar, wrapper.py. This wrapper merely takes the output of a command, wraps it in compliant JSON, and returns in a way that i3bar uses it generate its output. The wrapper allows the user to add on an arbitrary number of additions to their status bar, although you don’t want to overwhelm what is supposed to be just a status bar.

My own code I added to wrapper.py:

This function executes rhythmbox-client. Command line flags include purposely not starting Rhythmbox if it is not started, and displaying a custom format of output related to the current song being played. This output is the artist name, track title, and elapsed time of the current track. If Rhythmbox is not started, no output is present in the i3bar. If Rhythmbox is started but no song is playing, “Rhythmbox: Not Playing” is displayed.

in the ‘main function’, I modified the line which inserts an entry in the JSON object:

Inside my i3wm config’s bar specification, my status_command line looks like the following:

After reloading your i3wm environment’s config, a screenshot of my i3bar looks like:

i3bar screenshot

If your i3bar updates on an interval, you will see the current elapsed time of the song update as it plays.

FreeBSD on the desk, another try

After several years of mindlessly running Ubuntu on the desktop, I am attempting to dive (back) into running FreeBSD on the desktop. Considering that the majority of applications I use on the desktop are a browser (Firefox/Chrome), an ssh terminal, and Rhythmbox, how hard could this be?

Some of the hurdles

Given I still wanted to keep Ubuntu around and not redefine my default setup, I kept Grub2 as my bootloader on the MBR. I still needed a way to boot into FreeBSD at-will. I had installed FreeBSD on hd0a. Grub2 from Ubuntu makes finding the FreeBSD boot files incredibly easy:

Considering it has been a while since I ran FreeBSD for anything serious, I had always debated between ports and packages. In my distant memory, packages were not built for every piece of software I wanted, and building ports has the downside of long compile times, and potentially hairy dependency issues. With FreeBSD 10.0-RELEASE, ‘pkg’ has become the default package manager, and thus far, I have had no issues finding packages for any software package I’ve wanted. Upon install, update the package repository:

and use the various ‘pkg search’ and ‘pkg install’ variants to search for, and install the various applications.

I’ve always been curious in the various tiling window managers. i3wm seems to have the most-sane configuration structure among the various other tiling window managers (xmonad, awesomewm, etc). My i3wm configs up on Github.

I am still working on making the tiling-window manager thought process more second-nature. One instance I’m still attempting to wrap my head around, is when I fire up a full-screen window from Chrome, which ends up ‘under’ my main Chrome window. This makes the refrain ‘where the heck did my window go’ quite common. Alongside the fact that there is a lot of font configuration and xorg.conf hacking required to make the desktop what I consider ‘pretty.’

I find myself booting back into Ubuntu more often than not, given I’m more comfortable with the Unity window manager workflow. But I do boot into FreeBSD when time permits to try and hack on making it an actual usable desktop OS. The journey continues.

Wireless, now with more 802.11’s…

With nothing else to do around here tonight while the whole state is shut down thanks to a blizzard, I should catch up on some blog posts.

On my list of home network upgrades for the past several months was the wireless. As my wife and I add to our collection of smart phones, laptops, tablets, and wireless streaming devices (I am looking at you EOL Logitech Revue with Google TV) the amount of latency and available bandwidth started to show signs of strain. I had been running the wireless for several years on an Asus WL-500G Premium v2 router/wap, which only ran 802.11b/g over 2.4Ghz. It was time for an upgrade.

Welcome our new Asus RT-N66U 802.11b/g/n router/wap that handles dual channel 2.4Ghz and 5Ghz wifi.

I did some very unscientific comparisons before and after I performed the hardware upgrade. I pushed and pulled a ~763MB Ubuntu ISO across the wireless, through a 10/100Mb switch, via rsync over SSH from a server on the LAN. The following table shows rsync’s average speed and transfer duration from the point of view of a 15″ Macbook Pro connected via the wifi.

Old Wifi New Wifi 2.4Ghz New Wifi 5Ghz
Upload  1.87MB/s (6:46)  7.69MB/s (1:39)  5.57MB/s (2:17)
Download  2.61MB/s (4:51)  10.81MB/s (1:10)  10.39MB/s (1:13)

Needless to say, I am keeping the new router.