no DNS resolution client tools inside OpenVZ containers

[chaos@bbn.com]

The host OS on pc5.utah.geniracks.net contains the standard DNS resolution client tools:

vhost1,[~],10:01(0)$ ls -1 /usr/bin/{host,dig,nslookup}
/usr/bin/dig*
/usr/bin/host*
/usr/bin/nslookup*

However, these tools seem to be missing from inside my container, virt1.ecgtest2:

[chaos@virt1 ~]$ ls -1 /usr/bin/{host,dig,nslookup}
ls: cannot access /usr/bin/host: No such file or directory
ls: cannot access /usr/bin/dig: No such file or directory
ls: cannot access /usr/bin/nslookup: No such file or directory

[chaos@virt1 ~]$ type host
bash: type: host: not found
[chaos@virt1 ~]$ type dig
bash: type: dig: not found
[chaos@virt1 ~]$ type nslookup
bash: type: nslookup: not found

This seems unexpected. I would think experimenters might want to be able to do DNS lookups, e.g. to download tools on the control network.

[chaos@bbn.com]

I was in fact able to install the bind-utils package in my container:

[chaos@virt1 ~]$ sudo yum install bind-utils
fedora/metalink                                          |  20 kB     00:00     
fedora                                                   | 4.2 kB     00:00     
fedora/primary_db                                        |  14 MB     00:01     
updates/metalink                                         |  13 kB     00:00     
updates                                                  | 4.5 kB     00:00     
updates/primary_db                                       | 7.0 MB     00:05     
vz-base                                                  |  951 B     00:00     
vz-base/primary                                          | 2.4 kB     00:00     
vz-base                                                                     6/6
vz-updates                                               |  951 B     00:00     
vz-updates/primary                                       | 2.7 kB     00:00     
vz-updates                                                                  5/5
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package bind-utils.x86_64 32:9.8.3-1.fc15 will be installed
--> Processing Dependency: liblwres.so.80()(64bit) for package: 32:bind-utils-9.8.3-1.fc15.x86_64
--> Processing Dependency: libisccfg.so.82()(64bit) for package: 32:bind-utils-9.8.3-1.fc15.x86_64
--> Processing Dependency: libisccc.so.80()(64bit) for package: 32:bind-utils-9.8.3-1.fc15.x86_64
--> Processing Dependency: libisc.so.83()(64bit) for package: 32:bind-utils-9.8.3-1.fc15.x86_64
--> Processing Dependency: libdns.so.81()(64bit) for package: 32:bind-utils-9.8.3-1.fc15.x86_64
--> Processing Dependency: libbind9.so.80()(64bit) for package: 32:bind-utils-9.8.3-1.fc15.x86_64
--> Running transaction check
---> Package bind-libs.x86_64 32:9.8.3-1.fc15 will be installed
--> Processing Dependency: bind-license = 32:9.8.3-1.fc15 for package: 32:bind-libs-9.8.3-1.fc15.x86_64
--> Running transaction check
---> Package bind-license.noarch 32:9.8.0-9.P4.fc15 will be updated
--> Processing Dependency: bind-license = 32:9.8.0-9.P4.fc15 for package: 32:bind-libs-lite-9.8.0-9.P4.fc15.x86_64
---> Package bind-license.noarch 32:9.8.3-1.fc15 will be an update
--> Running transaction check
---> Package bind-libs-lite.x86_64 32:9.8.0-9.P4.fc15 will be updated
---> Package bind-libs-lite.x86_64 32:9.8.3-1.fc15 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package              Arch         Version                  Repository     Size
================================================================================
Installing:
 bind-utils           x86_64       32:9.8.3-1.fc15          updates       182 k
Installing for dependencies:
 bind-libs            x86_64       32:9.8.3-1.fc15          updates       853 k
Updating for dependencies:
 bind-libs-lite       x86_64       32:9.8.3-1.fc15          updates       617 k
 bind-license         noarch       32:9.8.3-1.fc15          updates        72 k

Transaction Summary
================================================================================
Install       2 Package(s)
Upgrade       2 Package(s)

Total download size: 1.7 M
Is this ok [y/N]: y
Downloading Packages:
(1/4): bind-libs-9.8.3-1.fc15.x86_64.rpm                 | 853 kB     00:00     
(2/4): bind-libs-lite-9.8.3-1.fc15.x86_64.rpm            | 617 kB     00:01     
(3/4): bind-license-9.8.3-1.fc15.noarch.rpm              |  72 kB     00:00     
(4/4): bind-utils-9.8.3-1.fc15.x86_64.rpm                | 182 kB     00:00     
--------------------------------------------------------------------------------
Total                                           333 kB/s | 1.7 MB     00:05     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : 32:bind-license-9.8.3-1.fc15.noarch                          1/6 
  Installing : 32:bind-libs-9.8.3-1.fc15.x86_64                             2/6 
  Installing : 32:bind-utils-9.8.3-1.fc15.x86_64                            3/6 
  Updating   : 32:bind-libs-lite-9.8.3-1.fc15.x86_64                        4/6 
  Cleanup    : 32:bind-libs-lite-9.8.0-9.P4.fc15.x86_64                     5/6 
  Cleanup    : 32:bind-license-9.8.0-9.P4.fc15.noarch                       6/6 

Installed:
  bind-utils.x86_64 32:9.8.3-1.fc15                                             

Dependency Installed:
  bind-libs.x86_64 32:9.8.3-1.fc15                                              

Dependency Updated:
  bind-libs-lite.x86_64 32:9.8.3-1.fc15   bind-license.noarch 32:9.8.3-1.fc15  

Complete!

Now i can do client DNS lookups:

[chaos@virt1 ~]$ host www.google.com
www.google.com is an alias for www.l.google.com.
www.l.google.com has address 74.125.227.147
www.l.google.com has address 74.125.227.148
www.l.google.com has address 74.125.227.144
www.l.google.com has address 74.125.227.145
www.l.google.com has address 74.125.227.146
www.l.google.com has IPv6 address 2607:f8b0:4000:801::1011

Okay, so an experimenter can fix this. I think it will surprise experimenters that it's not there by default. Is there a reason for it not to be? If not, maybe it should be added to the default. If so, the workaround seems to work fine.

[chaos@bbn.com]

Leigh said:

We tend to avoid bloat; no experimenter has ever mentioned needing              
the bind tools inside an openvz container, so we don't add it to the            
base container image.

I think this is a good policy, but I am easy. I will let others decide.

I don't feel strongly about this, so i'll go ahead and close the ticket, and let others reopen it if they think something should be changed.