As a result I have realized what the minimum IT hardware requirements are for comfortable living.

In no specific order, the following hardware should be deployed:

1. A workstations with 1920×1200 or better resolution.
2. Internet, 3 Mbps or faster.
3. A headset, preferably USB to separate it from speakers as an audio device.
4. A Squeezebox music player.
5. Wi-Fi, preferably 802.11n with simultaneous radios and WPA2.
6. A SIP phone for VoIP.
7. A printer, preferably network attached, color and laser.
8. A scanner.
9. VLAN-capable switches to carry Internet, public and private data around.
10. Plenty of network attached storage (NAS).
11. A proper router, preferably capable of DMVPN (NHRP, IPsec, OSPF).
12. A video player, e.g. WD Live TV or Mac Mini with Front Row.
13. A UNIX-server for DNS, DHCP, PXE, TFTP and other services.
14. A barcode reader, preferably CCD or laser.

It is surprisingly annoying when you suddenly don’t have your usual tools available to you. While a single laptop can go a long way all by itself, it is no comparison for having the proper tools in their proper places.

Turns out that insserv(8) isn’t happy on Ubuntu 9.10 or 10.04, so now vmware-config-tools.pl falls back to using update-rc.d(8). However, since old rc.d links have been left behind, update-rc.d won’t do anything at all. On top of that vmware-config-tools.pl calls it incorrectly.

Before running vmware-config-tools.pl or vmware-tools-upgrader first remove all the rc.d links:

cd /etc
rm -f rc?.d/*vmware-tools

On one of my systems I had multiple links at each run level, with different priorities, left behind from earlier VMware Tools installations. I guess regular manual inspection of the state of the links is warranted.

You may also want to apply this patch to vmware-config-tools.pl before running it:

--- vmware-config-tools.pl.orig 2010-06-06 19:45:49.176241344 -0400
+++ vmware-config-tools.pl      2010-06-06 20:25:56.000000000 -0400
@@ -1495,7 +1495,7 @@
    if ($gHelper{'update-rc.d'} ne '') {
      if (0 == system(shell_string($gHelper{'update-rc.d'}) . " " . $service
                     . " start " . $S_level . " S ."
-                     . " start " . $K_level . " 0 6 .")) {
+                     . " stop " . $K_level . " 0 6 .")) {
        return;
      }
    }

If your Linux kernel is 2.6.32 or later, the vmci module probably isn’t compiling for you either. Unpack the sources:

cd /tmp
tar -xvf /usr/lib/vmware-tools/modules/source/vmci.tar

Then apply this patch:

--- vmci-only.old/vmciKernelIf.c        2010-05-07 00:11:18.000000000 -0400
+++ vmci-only/vmciKernelIf.c    2010-06-06 20:39:40.693377830 -0400
@@ -44,6 +44,7 @@
 #include "compat_page.h"
 #include "compat_mm.h"
 #include "compat_highmem.h"
+#include "compat_sched.h"
 #include "vm_basic_types.h"
 #include "pgtbl.h"
 #include <linux/vmalloc.h>

Then replace the source tar with the patched files:

cd /tmp
tar -cvf /usr/lib/vmware-tools/modules/source/vmci.tar vmci-only

Now run vmware-config-tools.pl and everything should compile fine and you should have good start and stop links in your rc.d directories. Note that a start link is only installed in run level S: that’s okay, as according to the documentation that level is always run on boot. Seems to hold true, as the tools are now loaded fine on my systems.

http://kimmo.suominen.com/stuff/wulffmorgenthaler.xml

The fix is controversial: I’m disabling STUN.

gconftool-2 -s /apps/ekiga/general/nat/stun_server --type=string

However, this means Ekiga won’t work from less “intelligent” networks anymore. Since I’m considering Ekiga for my laptop, this might be a problem. Maybe I should try X-Lite under Wine.

When debugging the issue, I saw that a ping running on the system would often just sit there, not sending more packets, sometimes for seconds on end (I didn’t always wait to see if it would ever continue). Since hitting a key on the keyboard would immediately be echoed back, it wasn’t a problem with the terminal or ssh connection. Pinging the system from another would work without problems. Interrupting ping would report no packet loss (which was true — you can’t lose replies to packets you didn’t send).

My best guess is that the alternative scheduler chosen by the Ubuntu developers for the server kernels doesn’t work as intended on AMD CPUs (or just the Athlon XP, or some other part of the hardware I’m using).

My “fix” was to switch to Debian 5.0 (lenny), which doesn’t exhibit this problem at all.

I could have tried with the desktop edition of Ubuntu, but can’t really spare the time right now. Especially since I now have something that works reliably again.

I did try with different network hardware, though. I was originally using an SMC card based on ns83820 (but for some reason not reporting anything at all with ethtool — works fine with the gsip driver on NetBSD). I then switched to a Netwjork “brand” card based on r8169 (well liked by ethtool). No difference, but stayed with the latter (working ethtool is always nice).

aptitude install asterisk
m-a a-i zaptel
modprobe ztdummy

Also add ztdummy to /etc/modules so it gets loaded when the system starts.

If the m-a command is not found, install the module-assistant package.