2013 Aug 23 - Fri
Text file blogging, such as what blogs based upon Blosxom are, can become
resource hogs after a number of blog entries of accumulted. Over 500 entries in the
case of this blog. So it is time to migrate to a database based blog.
I first had my eye on
Movable Type, it is Perl based, and used to support both
MySQL and PostgreSQL. But the company is deprecating POstgreSQL, which is my
preferred database solution of the two.
A bit more searching resulted in coming across
serendipity, a PHP based blogging tool which stores its data
With that up and running now, I've ported my entriese over to the my new blog at:
Raymond Burkholder - Things I Do. There is still some
house keeping to do regarding categories and linked files, but from now on, it is there where the new content will be created.
Thank you for coming by and I hope to hear from you at the new location, which is now possible, as the new blogging
software has commenting capability!
2013 Aug 17 - Sat
Migrating From Google Reader to Tiny Tiny RSS
RSS feeds have been and still are my primary ways of reviewing current events. I made significant
use of Google's RSS Reader, that is, I was subscribed to quite a few feeds through their service. Then Google
decided to tear down the service. At least they gave warning and provided a means of getting at the raw data.
I was able download my configuration files, which included feed names, categories, as well as starred items.
I read quite a few blog entries relating to replacement services. Most of the suggestions didn't provide the
warm and fuzzies relating to functionality, availability, and interface. A few did refer to Tiny Tiny RSS
as having the ability for me to self-serve my own feed. And it stores its information in PostgreSQL. Cool.
Installing was straight-forward on a Debian platform:
- apt-get install php5-pgsql
- apt-get install php5-cur
- su - postgres
- create user tt login password 'some password';
- create database tt with owner = tt;
- add to /etc/postgresql/9.1/main/pg_hba.conf: local tt tt md5
- /etc/init.d/postgresql reload
- cd /var/www
- wget https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.9.tar.gz
- tar -zxvf Tiny-Tiny-RSS/archive/1.9.tar.gz
- rm 1.9.tar.gz
- mv Tiny-Tiny-RSS ttrss
- start the browser and finish the configuration.
The OPML file can be imported via a preferences menu.
For starred items, there is a Google Reader Import plugin which can be enabled. One enabled, a plugins menu is enabled,
and starred items are easily imported.
2013 Aug 15 - Thu
Bermuda Based Band - Sonique Sanctuary - Releases New Song: Anomaly
Last month, Bermuda rock band Sonique Sanctuary played at Chewstick. As part of their
set, they played an original song called Anomaly. Here is a video of them playing.
2013 Aug 12 - Mon
Linux Containers (LXC) on Debian Wheezy 7.1 With OpenVSwitch
Now that the networking side of things are complete with Quagga and OpenVSwitch, I can start working further up the technology layers.
The next step is to work on virtualization technologies and their management. The focus of this article is to
get Linux Containers (LXC) working within a Debian Wheezy 7.1 environment.
Before getting into the installation steps of lxc, some background first. LXC is not a full virtualization
solution with an independent kernal and bios, such as provided by Qemu/Kvm.
Instead, it runs in a namespace of the host's kernel. As such, it
has very fast startup characteristics. The draw backs are several: a) it doesn't offer the tighter security that
something like OpenVZ offers (another container flavour), b) it is a more recent container solution and has much catching up to do, and c) and one
of things it needs to catch up with is live migration of sessions from one host to another.
János Pásztor goes into some of the
differences between LXC and OpenVZ. The disadvantage of OpenVZ is that it has not been welecomed in to recent versions of the
Linux Kernel. It appears as though the game plan is the passing of the baton from OpenVZ to LXC.
From an LXC perspective, its usefulness is good when using it in environments where the administrator has control over its
integration. It is not a viable candidate when trying to set hosting solutions for third parties. Tighter security for those
scenarios can be supplied with a Qemu/Kvm style solution. Some additional reservations regarding
OpenVZ and LXC.
The basics of installation for LXC are straight-forward:
aptitude install lxc libvirt-bin
The first package deals with lxc directly. If I wasn't using OpenVSWitch, lxc would be all that I require. But in order
to use OpenVSwitch for the networking side of things, I need assistance from the libvirt system. As a side effect of the
libvirt install, the Qemu/Kvm compontents get installed at the same time. However, since I'm focussing on lxc at the moment, Qemu/Kvm will be
discussed in a different entry.
A manual entry into /etc/fstab is required followed by a reboot to resolve a "resource busy problem" as well as taking care of the mount:
cgroup /sys/fs/cgroup cgroup defaults 0 0
There is some explanation for control groups (cgroup) at
Control Groups Resource Management.
Before performing the reboot, one other adjustment is required. The following needs to replace the 'GRUB_CMDLINE_LINUX=""' in /etc/default/grub:
Then run the command 'update-grub'. Then perform the reboot. This is from the Debian Wiki on LXC.
After which, running 'lxc-checkconfig' should result in 'yes' for all items.
We can now move on to creating an lxc container. But even this isn't completely straightforward. Wheezy was released unstable in this regard, no functioning
lxc template. Instead, based upon
Horrors using Debian Wheezy, we need to obtain the
template from elsewhere.
LXC template lxc-debian-wheezy-template talks about the template.
The template uses debootstrap as part of the build process. The supplied script can be easily modified to install additional packages, or to choose
different install configurations.
gzip -d lxc-debian-wheezy.gz
mv lxc-debian-wheezy /usr/share/lxc/templates
chmod +x /usr/share/lxc/templates/lxc-debian-wheezy
Because I am doing this on an amd64 flavour, some lines in /usr/share/lxc/templates/lxc-debian-wheezy needs to be modified:
# the following are commented out, not proper
#1:2345:respawn:/sbin/getty 38400 console
#c1:12345:respawn:/sbin/getty 38400 tty1 linux
#c2:12345:respawn:/sbin/getty 38400 tty2 linux
#c3:12345:respawn:/sbin/getty 38400 tty3 linux
#c4:12345:respawn:/sbin/getty 38400 tty4 linux
# instead use these:
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
The lxc container can now be created:
lxc-create -n debianbase -t debian-wheezy
I am using btrfs as my file system for holding these containers. One interesting feature of the integration between btrfs and lxc is that
the lxc-create command will automatically create a btrfs sub-volume for the new container. These allows the use of snapshots for each container.
Therefore, the one caveat of which to be aware is that when removing a container, the btrfs subvolume delete command is required. For example,
'rmdir -rf /var/lib/lxc/debianbase' will complain that rootfs is on another device. The command 'btrfs subvolume delete /var/lib/lxc/debianbase/rootfs'
will need to be run to remove the subvolme before the remaining elements can be removed with the rm command.
In any case, the creation process will take a few moments to transfer, extract, and configure.
Now that the container has been created, there will be a config file located in /var/lib/lxc/debianbase. This file is used by the lxc-start
commands. But since we are using OpenVSwitch, errors will occur when trying to start with the lxc-start commands. Instead, we will ignore this
file and use libvirt/virtsh to start the container. However, some additional configuration is first required. An .xml configuration file
is required to define the lxc container to be run.
There are a couple of examples located within the libvirt
LXC container driver documentation. There is another sample described as
libvirt LXC container w/ bridged networking (and 2GB RAM).
The key point is that libvirt will only work with OpenVSwitch in bridged mode.
How to Use Open vSwitch with Libvir discusses this a bit.
Be sure to have the bridge device configured in
ovs-vsctl add-br br0
The key line in the libvirt file is to have '<virtualport type='openvswitch'/>' in place. I placed my
in the /var/lib/lxc directory, to keep everything together.
LibVirt Network XML format goes into the fine points of the configuration.
One other consideration is that I am running the amd64 64 bit version. The lxc-create command changed the root partition to be
/var/lib/lxc/debianbase/rootfs/rootfs-amd64 instead of /var/lib/lxc/debianbase/rootfs.
libvirt will take care of the interface creation and integration between OpenVSwitch and the lxc container. But a configuration change will be
required in the container to obtain an appropriate ip address. To use dhcp for addressing, a default dhcp stanza has been added for eth0.
If a static ip address is to be assigned instead, use the normal addressing stanzas associated with that file.
Also, so you don't confuse yourself, set a different hostname in the file at:
LibVirt, the server, also needs to be told about OpenVSwitch. I copied a template from elsewhere in libvirt to use:
cp -p /etc/libvirt/qemu/networks/default.xml /etc/libvirt/lxc/network.xml
Here is an example network.xml file.
The network has to be started in libvirt:
The container can now be started with libvirt:
For some reason, which has been noted by a number of authors, is that ssh is not configured properly, probably becuase the keys
need to be regenerated, which the default debootstrap doesn't deal with. So, the ssh server has to be re-installed. From the console,
a few house-keeping adjustments. The locale and ssh reinstall could be performed from a chroot environment:
# fix some perl locale issues:
echo "en_US.UTF-8 UTF-8" > /etc/locale.gen
apt-get -y --force-yes install locales
apt-get install --reinstall openssh-server
# add some additional tools
apt-get --no-install-recommends install -y adduser apt-utils iputils-ping rsyslog logrotate
apt-get install --no-install-recommends openssh-blacklist openssh-blacklist-extra
apt-get install wget less lsof screen nano inetutils-ping psmisc sockstat
#apt-get install man
The perl locale issues are identified and remedied with
Creating a LXC virtual machine template (from scratch).
LXC HOWTO has some interesting ideas regarding LXC containter initialization.
The ssh reinstall was mentioned at Setting up LXC containers in 30 minutes (Debian Wheezy).
Coruscating Lucubrations talks about
Incremental backups with btrfs
Margaret Bierman talks about
How I Use the Advanced Capabilities of Btrfs.
Dobrica Pavlinusic's Weblog / Blog has an entry discussing
the use of private mac addresses:
You will notice that I'm using prefix AC:DE:48 prefix for my mac addresses, which, to best of my knowledge range for private use and used all over IEEE docs (something like private IP range, but for mac addresses). I also have habit of naming interfaces with last octet of IP adress for internal ones, and last two for external one and same notation for mac addresses. Our brain is good at spotting patterns, and if you can read hex this seems just natural...
A ctrl-d or the command exit will exit and close the container. To disconnect from the container, instead use 'ctrl-a q', or if using screen, use
'ctrl-a a q'. 'ctrl-a ctrl-a' can be used to perform a regular 'ctrl-a' in the session (ie, move to beginning of a line). These commands apparently
won't work in foreground mode, only in background mode.
Once in the container, and an ip address has been obtained, apt-get install iputils-ping can be used to get the ping utility installed.
On a moderately related note, I was wondering how to get by without doing the virsh .xml file first. The last part of
Libvirt 1.0.5 with Openvswitch 1.11.90 provides the clue.
Use the command virt-install like:
# virt-install --connect qemu:///system --name DSL2 --ram 1024 --vcpus 1 \
--disk path=/tmp/dsl2,size=1,bus=virtio,cache=none \
--network=ovs-br0 \ <======= THIS LINE IS CHANGED.
--vnc --os-type=linux --cdrom /dev/sr0
In a follow on article, I have to deal with one level of added complexity, working with vlans with libvirt. The question was brought up with
[ovs-discuss] tag vlan communication inter LXC. The solution supposedly exists at
Open vSwitch Frequently Asked Questions.
However, according to
LibVirt Network XML format, libvirt handles VLAN oriented configurations starting with
libvirt version 0.10.0. Debian Wheezy uses version 0.9.12. The solution to this is supplied via remarks at using
VLANs with Open vSwitch Fake Bridges. This is actually
quite useful as I think that there can be multiple networkxxx.xml files, each supporting a vlan, and as the guest file references a particular network name,
the appropriate vlan can be selected. I haven't tested it yet, but this should also allow multiple interfaces, each connected to a particular vlan.
Some older info on
LXC on Debian Squeeze.
docker: an open source project to pack, ship and run any application as a lightweight container making use of LXC.
2013 Aug 11 - Sun
Understanding OpenVSWitch Configuration
My previous openvswitch article dealt with building a recent release on one system, migrating the .deb files
to another system, installing them, and getting the daemon to run upon reboot. Last year I also wrote about
some useful configuration commands, which dealt with simple access port style interfaces.
This article rehashes some of those commands, adds a few more refinements regarding vlan capabilities, and offers some
For working with vlan style interfaces, the documentation at
is missing a few key information elements, elements I found at other sites. For example, to add an interface
for handling a particular layer2/layer3 network end, something like the following is required:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 vlan201 tag=201 -- set interface vlan201 type=internal
The first command is the well known method for adding a new bridge. As an aside, a bridge in this context
would represent a switch, something which can deal with muliple vlans in the various access port and
trunk port roles. The second command is the way to add an 'internal' interface into Linux.
Ip addressing can be assigned interactively via something like:
ip addr add 10.11.1.20/24 dev vlan210
For persistance through boot cycles, the addresss should maintained in the
/etc/network/interfaces file through the standard iface stanzas.
An article at
covers some trunking commands. The gist is that by using something like the following to set specifically which vlans are
available over a particular physical or tap port. I believe something like the following will work:
ovs-vsctl add-port br0 eth1 trunks=101,102
The trunks aspect can be added as a two step process:
ovs-vsctl add-port br0 eth1
ovs-vsctl set port eth1 trunks=101,102
The author of that same article goes on to explain the philosophy of the ovs-vsctl command structure: it is a structure
closely resembling the commands for updating the database. And when you do a list command, such as 'ovs-vsctl list port vlan201',
you obtain a list of keys which can be updated with specific values. And in actual fact, I just learned by reading a comment
at the end of the article, it is the
ovs-vswitchd.conf.db manual which
describes all the possible parameters and their values. The articles also has some interesting links for sFlow integration and even sFlow auto-configuration.
Some references regarding openvswitch:
Building openvswitch on Debian 7.1 (Wheezy)
openvswitch is a powerful Linux based utility
for working with vlans, traffic filtering, monitoring, and QoS management within a hosted virtualization
The current stable version of Debian, which as of this writing is version 7.1, has an older version
of openvswitch. The version is many versions ago.
To use the most recent version of openvswitch will require manually building. These are the steps I performed
to get the basic system in place.
tar -zxvf openvswitch-1.10.0.tar.gz
apt-get install linux-headers-`uname -r`
apt-get install build-essential
apt-get install libssl-dev openssl pkg-config
apt-get remove bridge-utils
lsmod | grep switch
ovsdb-tool create /etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach
I put the following lines in /etc/rc.local to get things started after a reboot:
ovs-vswitchd --pidfile --detach
Since I have a number of other servers requiring the same treatement, the openvswitch distribution comes
with the meta files necessary for creating suitable Debian packages. The packages can be copied to
the other servers and installed. The packages end up in the parent directory of the source distribution.
Part of the packaging process involves running a series of unit tests, which appear to take more time than the build itself. The
readme files explain options to turn those tests off.
apt-get install fakeroot debhelper
apt-get install autoconf automake python-all python-qt4 python-zopeinterface python-twisted-conch
fakeroot debian/rules binary
apt-get install module-assistant
module-assistant auto-install openvswitch-datapath
When installing the .deb packages, auto-start stuff should automatically be dealt with, unlike the manual start stuff I performed at the beginning of this
There are a number of .deb packages, but only the following are really needed:
These are secondary files. The controller is a simple OpenFlow controller. ovsdbmonitor is a GUI tool for remotely viewing OVS databases and OpenFlow flow tables.
To install on another server, copy the .deb files over and then:
- apt-get install uuid-runtime
- dpkg -i openvswitch-common_1.10.0-1_amd64.deb
- dpkg -i openvswitch-switch_1.10.0-1_amd64.deb
- dpkg -i openvswitch-datapath-module-3.2.0-4-amd64_1.4.2+git20120612-9_amd64.deb
I recieved errors like:
FATAL: Module openvswitch not found.
Inserting openvswitch module ... failed!
Configuring Open vSwitch system IDs.
FATAL: Module openvswitch not found.
Inserting openvswitch module ... failed!
I ran the following commands to get things operational:
- modprobe openvswitch_mod
- dpkg -i openvswitch-switch_1.10.0-1_amd64.deb
- echo openvswitch_mod >> /etc/modules
2013 Aug 08 - Thu
HP Utilities on Debian MultArch amd64 x86_64
HP has utilities for managing hardware on HP Servers running Debian at
SDR Repository Listing.
Even though the files have suffix with amd64.deb, they are still 32 bit files. They have not been built natively for the x64 architecture.
In previous versions of Debian, the solution was to
- apt-get install ia32-libs
This is now deprecated in Debian 7.0, 7.1, Wheezy. The solution is instead to turn on multi-architecture mode:
- dpkg --add-architecture i386
- apt-get update
Now, for example, the HP file
can be installed with the following commands. The first line shows the 32 bit dependencies, the second installs the dependencies, and the third installs the package.
- dpkg --info hpacucli_8.70-8.0.2-2_amd64.deb
- apt-get install lib32gcc1 lib32stdc++6 libc6-i386
- dpkg -i hpacucli_8.70-8.0.2-2_amd64.deb
2013 Mar 30 - Sat
GNS3 206-unable to create UDP NIO
GNS3 has it's benefits in terms of being able to test out reasonably complicated scenarios in
terms of routing. But it does have it's quirks and issues.
One issue with the GNS3 0.8.4-RC2 release is in how it deals with its topology file. Well,
now that I think of it, there are two issues I recently encountered with this build. If others
encounter the same thing, I've included some work arounds.
The first issue I encountered is that when I built a topology, there were a few routers
for which I did not create links. When I saved and then reloaded the topology file, the
unlinked routers did not show up on the diagram. So.... whenever adding routers, ensure
there is at least one link provided. This ensures that router shows up next time in the drawing.
The second issue is somewhat more insidious. A reasonably complicated set of routers
and links can be created. The topology can then be saved. When restarting it a subsequent time,
the following error occurs:
*** Warning: Connecting to resulted in:
206-unable to create UDP NIO
*** Error: errors during loading of the topology file, please correct them
The solution to this is to manually edit the topology file and reorder the sections in
ascending order, something like:
... section content
... section content
... simlar sections
2013 Mar 21 - Thu
GNS3 And OSPF-4-ERRRCV: Received invalid packet: Bad LLS Checksum
GNS3 works quite well for simulating and testing Cisco routed networks. However, when
creating links between routers, there are times when the following message appears on the
console of some interconnected routers:
OSPF-4-ERRRCV: Received invalid packet: Bad LLS Checksum
I am uncertain as to the source of this issue. Some forums recommend applying the command to each interface:
- ip ospf network point-to-point
This did not work for me. Instead I tried the following at the interface level:
- ip ospf authentication message-digest
- ip ospf message-digest-key 1 md5 7
The above md5 digest key settings have stopped the errors from occuring.
2013 Mar 03 - Sun
FOFOA - (Gold) Friend of Friend of Another
FOFOA represents the continuation of
an ongoing interpretation of a very long running
commentary on the shadowy world of gold, oil, and international currencies.
The linked commentaries go back for more than ten years, and provide a whole new
perspective on gold price 'discovery' mechanisms.
One fascinating aspect of reading through some of the 'Thoughts', was that the current
depressed prices of gold producers could be attributed to the fact that world wide aggregate
gold production is declining on a year to year basis. If there are not more inventories,
nothing to sell, and therefore no value for the company. The issues are much
more complex than that.
As well, the gold producers a bit more diversified than the statement suggests.
2012 Dec 07 - Fri
BGP Default-Information Originate
A brief note on the rules for originating a default route into BGP (copied from a posting
made by Mohammed Mahmoud):
- default-information originate + redistribute static (or any dynamic routing protocol having the default route - you may filter only the default route)
- network command but must make sure the default route is present in the routing table
- issuing the neighbor default-originate command. This method does not require the presence of the 0.0.0.0/0 network in the routing table of the advertising router
Additional notes: The configuration of the default-information originate command in
BGP is similar to the configuration of the network (BGP) command.
The default-information originate command, however, requires explicit
redistribution of the route 0.0.0.0. The network command requires only
that the route 0.0.0.0 is present in the Interior Gateway Protocol (IGP)
routing table. For this reason, the network command is preferred.
2012 Oct 23 - Tue
I was having problems with getting a VMWare ESXi 5.1 Host to register properly with vSphere 5.0 (probably something seriously wrong
with that whole concept all by itself). During the install of ESXi 5.1, the local drives were attached and formatted for
Since I couldn't fix the registration problem, I rolled the host back to ESXi 4.1. When it came time to reformat and make the
drives useful for vmfs, I encountered an error along the lines of:
VMware: Call "HostDatastoreSystem.QueryVmfsDatastoreCreateOptions"
for object "ha-datastoresystem" on ESXi "SERVERNAME" failed
The comments of VMPros Virtualization
provided the solution (with an enhancement included by someone in the comments):
- I just did a .ls /vmfs/devices/disks/. from the shell to identify what was the vml I had to use.
- To find the vml I just ran the following command .partedUtil get /vmfs/devices/disks/VMLID. and I got an error with the VMLID corresponding to the new drive.
- After that, I just ran your .dd if=/dev/zero of=./vmfs/devices/disks/VMLID. bs=512 count=34 conv=notrunc. and I was able to add the hard drive.