The setup is actually very simple and unobtrusive. It is only necessary to properly configure a local DNS server and then force 127.0.0.1 to be used as the only nameserver instead of the corporate DNS servers.

First you need to configure dnsmasq as follows:

/etc/dnsmasq.conf

# don't use the /etc/resolv.conf file anymore
no-resolv

# OpenDNS nameservers:
server=208.67.222.222
server=208.67.220.220

# Force corporate nameservers for corporate.domain.com lookups
# OpenDNS wouldn't be able to answer such queries correctly
# adjust to suit your network
server=/corporate.domain.com/10.1.1.1
server=/corporate.domain.com/10.1.1.2

# only respond to queries from the local machine
listen-address=127.0.0.1
bind-interfaces

conf-dir=/etc/dnsmasq.d

Then you need to go into NetworkManager and set 127.0.0.1 as the DNS server to be used:

This will result in the following important settings added to your network scripts:

DNS1=127.0.0.1
PEERDNS=no

I’ve noticed two minor problems with this setup:

1. the corporate DNS server names are hardcoded in the configuration. Usually they are determined automatically by the DHCP client.
2. restarting the dnsmasq service sometimes shows this error:

   dnsdomainname: Host name lookup failure

ifcfg-eth0

First, I changed the host’s (auto-generated) /etc/sysconfig/network-scripts/ifcfg-eth0 script from this:

# Attansic Technology Corp. L1 Gigabit Ethernet Adapter
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=00:1D:60:35:A7:64
ONBOOT=yes

to this:

# Attansic Technology Corp. L1 Gigabit Ethernet Adapter
DEVICE=eth0
TYPE=Ethernet
BRIDGE=br0
ONBOOT=yes

This turns off DHCP on the physical Ethernet device and just specifies that it will be connected to or a part of a bridge.

ifcfg-br0

Second, I created /etc/sysconfig/network-scripts/ifcfg-br0, which will be called to setup a bridge device:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
HWADDR=00:1D:60:35:A7:64
ONBOOT=yes
DELAY=0
STP=off

As you can see, most of this configuration is copied from eth0 plus the bridge configuration as per the Qemu Wikibook.

qemu-ifup/down

Third, I shortened the /etc/qemu-ifup and /etc/qemu-ifdown from Wikibooks to get this:

/etc/qemu-ifup:

#!/bin/sh
USER=$(id -un)
sudo /usr/sbin/openvpn --mktun --dev $1 --user "$USER"
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
sudo /usr/sbin/brctl addif br0 $1

/etc/qemu-ifdown:

#!/bin/sh
sudo /sbin/ifconfig $1 down
sudo /usr/sbin/brctl delif br0 $1
sudo /usr/sbin/openvpn --rmtun --dev $1

Here I basically removed all of the configuration that is taken care of in the sysconfig scripts. I also made explicit use of sudo simply because that is my preference.

Final steps

Now I can simply run /etc/qemu-ifup tap0 once to create a TAP device, and use something like: qemu-kvm -hda /virtual-machines/fedora9.disk -m 512 -net nic -net tap,ifname=tap0,script=no to start a virtual machine. When I’m done running the virtual machine, I can run /etc/qemu-ifdown tap0 to remove the TAP device.

All this sounds simple now that it’s working, but initially it took a lot of guessing on my part so I’m documenting it here for the future.

I would appreciate it if someone can point me to the official Redhat/Fedora documentation on editing /etc/sysconfig/network-scripts/ scripts.

$ nmap printer.lan

Starting Nmap 4.53 ( http://insecure.org ) at 2008-06-22 20:39 EDT
Interesting ports on printer.lan (10.1.1.7):
Not shown: 1705 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
79/tcp    open  finger
80/tcp    open  http
515/tcp   open  printer
631/tcp   open  ipp
5001/tcp  open  commplex-link
8000/tcp  open  http-alt
9100/tcp  open  jetdirect
10000/tcp open  snet-sensor-mgmt

Nmap done: 1 IP address (1 host up) scanned in 0.396 seconds

After a bit of trial and error, I discovered that simply using the http://printer.lan:631 or ipp://printer.lan URI and a Generic PostScript driver worked without problems with E250DN.

Apart from these initial pains I am quite happy to be able to print double-sided black-and-white documents from all of my home computers.

Side Note:

During the investigation process, I noticed that Fedora’s system-config-printer utility prints the following information to the terminal when I tell it the IPP printer hostname:

...
printer.lan: /usr/lib/cups/backend/snmp "${HOST}" 2>/dev/null
printer.lan: hp-makeuri -c "${HOST}" 2> /dev/null
No ID match for device ipp://printer.lan:
<manufacturer>Lexmark</manufacturer>
  <model>E250dn 6216N4G LE.PM.P121 -- Part Number -</model>
  <description>Lexmark E250dn 6216N4G LE.PM.P121 -- Part Number -</description>
  <commandset></commandset>
Using textonly.ppd
...

I wonder how I could get that XML-ish output myself. It doesn’t seem to come from hp-makeuri.

In Fedora 8, Jigdo was easy to install:
# yum install jigdo

From the jgdo manpage I discovered that the command line client version of jigdo is actually called “jigdo-lite”. Using this client turned out to be as easy as telling it which “.jigdo” file to use:

$ jigdo-lite http://www.muug.mb.ca/pub/fedora/linux/releases/9/Fedora/x86_64/jigdo/Fedora-9-x86_64-DVD.jigdo

Jigdo was nice enough to ask me to enter a path to previous installation media (presumably Fedora) to check for files which can be reused. To my amusement it turned out that the Fedora 7 x86_64 DVD contained no such files while the Fedora 8 x86_64 DVD contained 116 of the 2691 files required by the template.

Resuming jigdo was an interesting process. I canceled the first attempt with Ctrl-C. Then I simply re-ran the original jigdo command and it told me:

The temporary directory `Fedora-9-x86_64-DVD.iso.tmpdir' already exists. Its contents
ARE GOING TO BE DELETED (possibly after having been copied to the
image, if they are of interest for it). If you do not want this
to happen, press Ctrl-C now. Otherwise, press Return to proceed.

This puzzled me because it didn’t say what is the meaning of the files in the *.tmpdir directory. Without knowing that I shouldn’t be expected to assess the importance of the directory and make a decision about deleting it. My initial guess was that it contained everything that jigdo has downloaded in the previous session. I checked the “jigdo” and “jigdo-lite” mangpages but they did not mention resuming. Thankfully, the documentation on the website was more helpful. The Downloading Of The ISO section made it clear that I shouldn’t fear to loose Fedora-9-x86_64-DVD.iso.tmpdir after all. Apparently it simply stores files which have just been downloaded but haven’t been merged into the temporary image (which is called Fedora-9-x86_64-DVD.iso.tmp). I checked that currently Fedora-9-x86_64-DVD.iso.tmpdir is much smaller than Fedora-9-x86_64-DVD.iso.tmp so I feel confident in letting jigdo delete that dir:

$ ls -lah
total 3.9G
drwxrwxr-x  3 plouj plouj 4.0K 2008-05-14 15:48 .
drwxr-xr-x 25 plouj plouj 4.0K 2008-05-14 11:16 ..
-rw-rw-r--  1 plouj plouj 314K 2008-05-14 11:30 Fedora-9-x86_64-DVD.iso.list
-rw-rw-r--  1 plouj plouj 3.9G 2008-05-14 15:47 Fedora-9-x86_64-DVD.iso.tmp
drwxrwxr-x  4 plouj plouj 4.0K 2008-05-14 15:47 Fedora-9-x86_64-DVD.iso.tmpdir
-rw-rw-r--  1 plouj plouj 211K 2008-05-12 13:11 Fedora-9-x86_64-DVD.jigdo
-rw-rw-r--  1 plouj plouj  12M 2008-05-12 11:38 Fedora-9-x86_64-DVD.template
-rw-rw-r--  1 plouj plouj 3.0M 2008-05-14 11:30 jigdo-file-cache.db
$ du -sh Fedora-9-x86_64-DVD.iso.tmpdir
7.5M	Fedora-9-x86_64-DVD.iso.tmpdir

Find confirms the same:

$ find Fedora-9-x86_64-DVD.iso.tmpdir -type f
Fedora-9-x86_64-DVD.iso.tmpdir/gulus.usherbrooke.ca/pub/distro/fedora/linux/releases/9/Fedora/x86_64/os/Packages/lucene-contrib-2.3.0-1jpp.0.fc9.x86_64.rpm
Fedora-9-x86_64-DVD.iso.tmpdir/gulus.usherbrooke.ca/pub/distro/fedora/linux/releases/9/Fedora/x86_64/os/Packages/libpng-1.2.24-1.fc9.x86_64.rpm
Fedora-9-x86_64-DVD.iso.tmpdir/gulus.usherbrooke.ca/pub/distro/fedora/linux/releases/9/Fedora/x86_64/os/Packages/lftp-3.6.3-2.fc9.i386.rpm
Fedora-9-x86_64-DVD.iso.tmpdir/www.muug.mb.ca/pub/fedora/linux/releases/9/Fedora/x86_64/os/Packages/glibc-2.8-3.x86_64.rpm

After I pressed “Return”, jigdo happily resumed downloading my Fedora 9 DVD. Some time later, the download finished successfully and the resulting image passed the SHA1SUM check.

In addition to the resuming confusion I noticed a few other problems with Jigdo. Firstly, it just takes a long time to download and check all the files. It has been running for over 3 hours and at 500KB/s (the average speed I get from good servers) the whole DVD image (3970.8 MB) would have been downloaded by now. Secondly, the name is hard to spell correctly. I’ve gone from “Jingo” to “Jidgo” to “Figdo”.

To be fair, I have to admit that the coolness of what jigdo does in the background outweighs its shortcomings and I am happy with it in the end.