Installing VMWare Tools on Ubuntu Guest Servers

After hunting around on the web for a while, I couldn't find anyone who answered this in a way that people could run step-by-step, so I hope this helps other people in the future.

I used Ubuntu 8.04.2 LTS for the purposes of this example, but a similar, if not identical set of commands should work for any version of Ubuntu Server.

First, you'll need to have installed VMWare on Windows or a UNIX server and have your Ubuntu Guest running, then you can go to "VM / Install VMWare Tools".

Your first problem, because you're not running a desktop system in your guest -- the CDROM is not automounted for you, so you'll need to do:

mount /media/cdrom

Next, you'll need to copy the .tar.gz file to a place on the installation that has write access, like /tmp:

cp /media/cdrom/VMwareTools-*.tar.gz /tmp/

Next, extract the file:

tar zvxf VMwareTools-*.tar.gz

Change to the directory:

cd /tmp/vmware-tools-distrib/

Now, before we actually run the installer, Ubuntu Server needs some packages installed so the new kernel modules can be built successfully.

apt-get -f install build-essential linux-headers-server linux-server

Once they've been successfully installed, you can run:

sudo perl vmware-install.pl

Most of the defaults are fine, when you are asked for "the location of the C header files for your running kernel" you'll need to answer with the include directory from the kernel you are currently running -- from the looks of things, this trips people up sometimes.

(Ubuntu doesn't ship with a /usr/src/linux directory, so if you press [ENTER] here, you'll get a "Directory not found" message and asked to re-enter the location)

As of the time of writing, the kernel is 2.6.24-23-server, so your location would be:

/usr/src/linux-headers-2.6.24-23-server/include

Once you've done that, the configuration routine will continue through to the end normally and you can reboot your guest OS in order for the changes to take effect.

"all zones must be in views", BIND 9 and You.

note: This article is intended for a technical audience -- you should use caution when modifying a production system -- caveat emptor.

An interesting question raised by a client, who was experiencing this error in their daemon.log file and asked me to track it down.

A bit of background:

The client in question runs a "Split Zone" configuration, where a seperate set of DNS entries are published to public users (that are only queried by and cannot be altered in any way by external entities) than are published to their other master or slave servers (which are secured by DNSSEC and various other access controls and can be queried by internal LAN users.)

So:

Apr 10 05:41:17 vampire named[8933]: loading configuration from '/etc/bind/named.conf'
Apr 10 05:41:18 vampire named[8933]: /etc/bind/named.conf:12: when using 'view' statements, all zones must be in views

has been in their logs for about six weeks since the server was commissioned and the new administrator wonders if that's the reason their zone information appears out of date?

Well, no.

First off, that message is not actually an error, it's a warning -- but it's still unsightly.

Second, the file it is complaining about is not /etc/bind/zonefiles/m/[name_of_zone].zone but /etc/bind/named.conf which happens to be the default configuration file for most common Linux distributions.

In fact, if you look at the Debian / Ubuntu configuration file you'll see:

"If you are just adding zones, please do that in /etc/bind/named.conf.local"

Which, in this case -- we did, using internal and external views that look a bit like:

view "internal-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { trusted; xfer; };
notify yes;
recursion yes;
additional-from-auth yes;
additional-from-cache yes;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { any; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { any; };
};
};

and:

view "external-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { any; };
notify yes;
recursion no;
additional-from-auth no;
additional-from-cache no;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { none; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { none; };
};
};

As you can see, we defined the root server hint file for both views, BIND 9.x gets rather tetchy if you don't do that, but will happily continue as long as you do (and, of course -- all your zones verify correctly with named-checkzone)

What, of course -- we failed to do was to define localhost, 127.in-addr.arpa, 0.in-addr.arpa and 255.in-addr.arpa for the internal and external view too.

The error goes away, as expected if you:

Firstly, Comment out the lines for the required zones in the /etc/bind/named.conf file. (Use '//' for commenting in this file)

Then, ammend your zone configuration to look similar to:

view "internal-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { trusted; xfer; };
notify yes;
recursion yes;
additional-from-auth yes;
additional-from-cache yes;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { any; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { any; };
};
};

and:

view "external-in" in {
// This view includes our trusted machines, we perform
// recursion in this view and can cache requests for
// our client machines
match-clients { any; };
notify yes;
recursion no;
additional-from-auth no;
additional-from-cache no;

zone "." in {
// Link in the root server hint file.
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

zone "ministry-of-the-interior.local" in {
type master;
file "/etc/bind/zonefiles/m/forward.zone";
allow-query { any; };
allow-transfer { none; };
};

zone "33.168.192.in-addr.arpa" in {
type master;
file "/etc/bind/zonefiles/m/reverse.zone";
allow-query { any; };
allow-transfer { none; };
};
};

Check your new configuration validates by running named-checkconf, then restart BIND the warning should vanish and your administrators should all go away satisfied.

Web Design Meets Marketing = Fatality

Viral Marketing at it's best.

I laughed ... and I don't think it was even meant as an April Fools Joke.