Skip to main content

That's When I Reach For My Resolver

So, the primary nameserver is down but luckily /etc/resolv.conf has been equipped with a secodary nameserver entry - great! And nslookup works like a charm too, heh! But all the other useful tools are waiting for ages until they'll get a response from the backup server - why is that?

$ time ping eve
eve is alive

real    0m30.045s
user    0m0.007s
sys     0m0.018s
Other than e.g. nslookup, the normal applications have to use the the resolver(4) to get their name requests answered. Now, we could cheat and put our backup server before the faulty one, but let's see if we can tackle this from a different angle. resolv.conf(4) was most helpful, of course:
   Allows certain internal resolver variables to be modified.

timeout:n / retrans:n
   Sets the amount of time the resolver will wait for a response from a remote 
   name server before retrying the query by means of a different name server.
   Measured in seconds, the default is RES_TIMEOUT. See 

attempts:n / retry:n

   Sets the number of times the resolver will send a query to its name 
   servers before giving up and returning an error to the calling application.
   The default is RES_DFLRETRY. See .
In our resolv.h (Solaris 10) we have :
$ egrep 'RES_TIMEOUT|RES_MAXRETRANS|RES_DFLRETRY' /usr/include/resolv.h
#define RES_TIMEOUT         5      /* min. seconds between retries */
#define RES_MAXRETRANS     30      /* only for resolv.conf/RES_OPTIONS */
#define RES_DFLRETRY        2      /* Default #/tries. */

So, let's tweak those options:
$ grep options /etc/resolv.conf 
options timeout:1 retry:1

$ time ping eve
eve is alive

real    0m7.794s
user    0m0.007s
sys     0m0.018s
Whooha, not bad.
Note: in Linux the retry: parameter is called attempts:

Let's tweak the retry: parameter a bit more:
$ grep options /etc/resolv.conf 
options timeout:1 retry:0

$ time ping eve
eve is alive

real    0m2.100s
user    0m0.007s
sys     0m0.018s
Even better. Of course, one has to realize that with zero retries the resolver will jump to the next nameserver on the first failure - so, if our backup server is a bit sleepy we won't get a reply at all. If you enable nscd, subsequent requests to the same name will be answered instantly:
$ sudo svcadm enable svc:/system/name-service-cache
$ time ping eve
eve is alive

real    0m3.218s
user    0m0.007s
sys     0m0.018s

$ time ping eve
eve is alive

real    0m0.198s
user    0m0.007s
sys     0m0.017s

VMware Server & Ubuntu 10.04

Wow, what a ride. Upgrading to Ubuntu 10.04 LTS worked flawlessy, as always (hint: use aptitude -V dist-upgrade this time, it's a bit more sophisticated than apt-get). But VMware Server 2.0.2 (i386) didn't like the new 2.6.32-22-generic-pae kernel too much. Lot's of warnings and the compilation errors were enough to look for solutions elsewhere. Finally, after hours of searching and trying, I propose 4 patches to be applied:

  • 00-vmware-2.6.32_functional.diff - this one fixes the actual compile errors and has been provided by drgr33n back in October 2009.

  • 01-vmware-2.6.32_cosmetic.diff - this one fixes (hides?) all the warnings. The patch is not mandatory (the modules will compile without it) but it makes it a lot easier to catch real error messages when it's applied. This patch is basically just implementing what rbihlmeyer proposed back in September 2009.

  • 02-vmnet-include.diff - while we're at it: I noticed that in vmnet.tar all the header- and source-files were in one directory, while they're located in include/ resp. linux/ for all the other modules. Again, not mandatory, but it's a nice cleanup, maybe the VMware guys will pick it up.

  • - and finally, needs to be patched, so that the vsock.ko module can use the symbols from vmci it requires, otherwise the module fails to build. Thanks again, drgr33n!

With all these patches applied, running should look like this. You can use this script to do all the patching for you (be sure to alter the DIR and PATCHES variables to your needs).

A few more notes on the whole VMware shebang:
  • In my case it helped to boot both the host and the guest with clocksource=acpi_pm, otherwise the clock would skew away. YMMV though.

  • In the /var/log/vmware/hostd.log logfile, the following error message can be seen:
       An error occurred while loading configuration "../vmware-server/lib/vmware/settings",
       not all entries are being read. It is strongly encouraged that you manually 
       inspect the file and fix any corruptions.
    However, /opt/vmware-server/lib/vmware/settings does not even exist. VMware Server and its guests continue to run. Don't know what to make of this error yet...

  • As the old VMware console GUI has been discontinued, one is left with a Web GUI (https://server:8333). To access the actual console, one must install either vmware-vmrc-win32-x86.exe (for IE, but install-privileges are needed) resp. vmware-vmrc-{win32|linux}-x86.xpi (for Firefox, user rights sufficient). Of course, the VMware vSphere Client can also be used to access the VMware installation, but one has to pay for it, IIRC.

Yum & CTRL-C

I can't believe yum still has a problem with CTRL-C. When aborting an operation in F13 it still prints a horrible-looking python-backtrace and then just hangs. It seems to switch to the next mirror rather than "interrupting" the operation as one would expect. Well, not everybody apparently. Oh well, maybe something futuristic like CTRL-C will be implemented in F23 or so :-)

One thing that is cool about yum is presto:

$ sudo yum upgrade
Transaction Summary
Install       0 Package(s)
Upgrade  99 Package(s)

Total download size: 198 M
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Download delta size: 11 M
There's debdelta for dpkg, but I haven't seen it properly integrated yet.

Bigger, better, faster

This blog is kindly hosted by some bigger German ISP, but due to, well, let's say certain circumstances it doesn't provide a MySQL database. I know, s9y can use SQLlite, but we're too cool for this, right? So, this MySQL database has always been hosted by some lonely machine an someone's closet, serving this blog's queries over in incredibly fast (hah!) ADSL uplink.

But not anymore! I'm happy to announce that the database has been moved to a box with 100Mbps uplink, happily awaiting your visits - yay!

Thanks, Malte!

Changing the default column list in Thunderbird

Appaerently Thunderbird 3 now allows the column headings to be set on a per-folder basis. While this is might be a neat feature, it is also quite a pain for all the others wanting one default column list for all their folders. Luckily, there's a workaround to accomplish this:

  • Set layout for the uppermost folder ("INBOX")
  • Quit Thunderbird
  • Delete all but the INBOX.msf .msf files from your profile directory:
    find ~/Library/Thunderbird/Profiles/*/ImapMail -name "*.msf" \
             -a ! -name "INBOX.msf" -exec rm -v '{}' + 
  • Start Thunderbird again, now the default layout should be propagated to all the subfolders.

equivs FTW!

OK, so I really don't get the point why mountall (and cryptsetup) depends on plymouth now. Until this will be resolved (hah!) and with me being stubborn enough not to install plymouth again (after forcefully removing it), I'm left with:

# apt-get install foo
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these:
The following packages have unmet dependencies:
  cryptsetup: Depends: plymouth but it is not going to be installed
  mountall: Depends: plymouth but it is not going to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
Not a nice thing to be stuck with. But equivs is here to help:
$ equivs-control plymouth-dummy
$ vi plymouth-dummy

$ grep -v ^\# plymouth-dummy
Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: plymouth-dummy
Provides: plymouth
Description: plymouth-dummy, see LP# 556372

$ equivs-build plymouth-dummy 
$ ls -lgo plymouth-dummy*
-rw-r----- 1  826 2010-04-08 16:45 plymouth-dummy
-rw-r--r-- 1 2040 2010-04-08 16:47 plymouth-dummy_1.0_all.deb
Then I was able to install plymouth-dummy_1.0_all.deb (via dpkg -i) onto the system in question. Mind you, the equivs thing was done on a Debian/powerpc system, as I couldn't even "apt-get install equivs" on this b0rken Ubuntu/amd64 box. Talk about portability! :-)

Internal Error, Could not perform immediate configuration (2) on mountall

# lsb_release -a 
Distributor ID: Ubuntu
Description:    Ubuntu karmic
Release:        9.10
Codename:    karmic

# apt-get update && apt-get -V dist-upgrade
Need to get 0B/197MB of archives.
After this operation, 239MB of additional disk space will be used.
Do you want to continue [Y/n]? 
E: Internal Error, Could not perform immediate configuration (2) on mountall
Huh? What happened here? I mean, I still had this mountall bug around, so it wouldn't surprise me if apt-get runs some hooks on mountall to make sure we're actually up & running. Let's "fix" mount for now:
# mountall 
swapon: /dev/mapper/swap: swapon failed: Device or resource busy
mountall: swapon /dev/mapper/swap [15521] terminated with status 255
mountall: Problem activating swap: /dev/mapper/swap

# grep swap /etc/fstab 
## /dev/mapper/swap swap       swap    pri=1        0       0

# mountall 
Now mountall returns properly, but apt-get dist-upgrade would still present the same error. Manually installing the package in question helped:
# dpkg --force-all -i /var/cache/apt/archives/mountall_2.10_amd64.deb
# apt-get -f install
# apt-get -V dist-upgrade

one step forward, two steps back

It finally happened: Comcast has signed me up for their Data Usage Meter, as I don't belong to the "vast majority" of their customers:

Your Comcast High-Speed Internet service has a monthly data usage allowance
of 250 gigabytes (GB). If you are wondering whether you are at risk of exceeding
this 250GB threshold, you should know that the vast majority - around 99% - of
Comcast customers use significantly less than 250GB per month.
huh? I thought volume-based contracts are a thing of the past. It's all about flat-rates now, no? It's 2010 now and they're still maintaining this limitation. I've even throttled my RelayBandwidthRate to 90KB/s but I'm still exceeding their 250GB/month:

So, what's next? Their FAQ states:
If you exceed more than 250 GB and is one of the heaviest data users who consume
the most data on our high-speed Internet service, you may receive a call from the
Customer Security Assurance ("CSA") team to notify you of excessive use. At that
time, we will tell you exactly how much data per month you had used. When we call
you, we try to help you identify the source of excessive use and ask you to moderate
your usage, which the vast majority of our customers do voluntarily. If you are
contacted by the CSA team again for excessive use within six months of the first
contact your service will be subject to termination for one year. We know from
experience that most customers curb their usage after our first call. If your
account is terminated, after the one year period expires you may resume service
by subscribing to a service plan appropriate to you needs.
(yes, the spelling errors are really in the FAQ). I like the last senctence the best - as if anyone would subscribe to the ISP again who kicked them out before :-)

Well, let's see when that happens and hopefully I'm already moving out when they're about to terminate my contract - that way I'd save postage sending my cancellation letter :-)

Oh, the reason why they've set up this limit is customer feedback, of course.

Update: I've reduced AccountingMax again, now we're down to 3GB/day, which will be reached after ~15 hours, the remaining hours my Tor daemon will live in hibernation, oh well. I've updated the graph above. It's May 13th now and I just passed 100 GB. For the record, Comcast did not call yet....maybe they're busy sniffing exit nodes, hm?