Ubuntu 8.04 guest on VirtualBox 1.5.5 on Solaris: a problem with the screen resolution

I just installed an Ubuntu 8.04 guest on top of my VirtualBox 1.5.5 (with guest additions 1.5.6) on Solaris Express Developer Edition. As soon as I logged in, I wanted to change the screen resolution and I realized that the maximum resolution allowed was 800x600. It's not clear to me yet if the problem is related with the guest additions, but it was easily solved by adding:

Driver "vboxvideo"

to the device section. Doing so, Xorg now recognizes 1024x768 as a valid resolution, too. If you need higher resolutions you can add a Display subsection in the Screen section and manually specify the modes, as in:

Section "Screen"
Identifier "Default Screen"
Device "VirtualBox graphics card"
Monitor "Generic Monitor"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "2048x800" "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Solaris Zones on different network interfaces: setting up the routing table

For the reasons I explained here I created a zone to install Blastwave's software. Furthermore, as I usually use ssh to connect to this machine from the outside of my LAN, I'm running the ssh service on another non-global zone. My Sun Ultra 20 M2 has two NICs, and the two zones share a physical NIC (nge1), while the global zones uses both nge0 and nge1, as shown in the following two fragment of the zone configuration file.

Everything was working OK and I usually use zlogin when I connect to a zone. I had no reason, either, to connect to the Blastwave's zone using ssh because I loopback mounted the /opt/csw filesystem so that it's available to desktop users who log in the global zone.

When I tried to ssh a zone, I realized that I couldn't! A quick check with netstat told me why:

bash-3.2# netstat -r

Routing Table: IPv4
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ---------- ---------
default speedtouch.lan UG 1 58 nge0
default speedtouch.lan UG 1 108 nge1
192.168.0.0 solaris.lan U 1 19 nge0
192.168.0.0 Unknown-00-14-4f-80-d6-b1.lan U 1 3 nge1
solaris solaris UH 3 561 lo0

Routing Table: IPv6
Destination/Mask Gateway Flags Ref Use If
--------------------------- --------------------------- ----- --- ------- -----
::1 ::1 UH 1 35 lo0

The zones' IP addresses (192.168.0.132 and 192.168.0.140) are indeed not reacheable. The quick fix was updating the routing table:

route add 192.168.0.132 192.168.0.130
route add 192.168.0.140 192.168.0.130

An OpenSolaris project named Crossbow will solve this kind of problem by fully virtualizing the network interfaces.

Running Windows on Solaris with VirtualBox

Sun Microsystems acquired InnoTek. InnoTek is the creator of VirtualBox, a family of virtualization products.

I'd been wandering how I would have run an instance of Windows (sigh) on top of Solaris Express Developer Edition but because the processor of my Sun Ultra 20 M2 does not have virtualization extensions (is not HVM capable), I wasn't left with many options.

But when I read about VirtualBox, I decided to give it a try and I must say that I was impressed. Installation was straightforward and Windows was installing (sigh) just after few minutes after downloading the package.

I downloaded the OpenSolaris distribution of VirtualBox and installed it with pkgadd. Once the package was installed, I tried to run VirtualBox but it couldn't find some libraries. A quick ldd showed that:

$ ldd /opt/VirtualBox/VirtualBox | grep found
VBoxKeyboard.so => (file not found)
libqt-mt.so.3 => (file not found)
VBoxRT.so => (file not found)
VBoxREM.so => (file not found)
VBoxVMM.so => (file not found)
VBoxXPCOM.so => (file not found)

Finding missing libraries was easy and the script I wrote to solve the problem is the following no-brainer:

$ cat ./bin/prepare-vb-env
#!/bin/bash
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/VirtualBox:/opt/VirtualBox/qtgcc/lib
export LD_LIBRARY_PATH
PATH=$PATH:/opt/VirtualBox
export PATH

Sourcing this script into your shell will prepare the environment and VirtualBox will run. Creating a new virtual machine was straight forward. After pressing the "New" button, this welcome screen was shown:



This is the typical useless welcome screen in which you've no choice but pressing "Next" or "Cancel".



In this screen, you can set the name of the virtual machine and choose the guest operating system from a pretty rich list which includes:

• DOS
• Windows 3.1
• Windows 95
• Windows 98
• Windows ME
• Windows NT 4
  
• Windows 2000
• Windows XP
• Windows Server 2003
  
• Windows Vista
• OS/2 WARP 3
• OS/2 WARP 4
  
• OS/2 WARP 4.5
• Linux 2.2
• Linux 2.4
• Linux 2.6
• FreeBSD
• OpenBSD
• NetBSD
• Netware
• Solaris
• L4

In this screen, you can choose the amount of memory you want to assign to the virtual machine. For a Windows XP instance, 512 MB works pretty well. Please consider that VirtualBox is going to reserve this amount of memory for itself and unless you want your Solaris host and your Windows guest starting to swap (even if long time Windows users may be used to it), check that your machine has a proper amount of RAM available for the virtual machine.



The last step is creating a file which will be used by VirtualBox to mimic hard disks for Windows. You can create a maximum of 4 disks, the typical master or slave disks attached to the primary and secondary IDE bus channels.

The first time the virtual machine is run, it will ask for an installation CD or an ISO image of it and the installation will start.

I really liked VirtualBox ease of installation and ease of management and suggest it to everybody wants to run a Windows instance on its Solaris. As far as it's concerned the other supported operating systems, I just tried a Linux 2.6 installation of both Ubuntu and Slackware with no problem. I'm using this image, instead of a lx branded zone, because I'm an old Slackware user and I wanted to run a 2.6 kernel, whose support is (still) experimental. If a 2.4 kernel is no issue for you and you don't need a desktop installation, I would recommend installing a CentOS image on a Solaris lx branded zone. Even if you need a GUI application, you can connect with ssh -X to your linux zone and user your Solaris Xorg instance as a server.

The fundamental laws of human stupidity

I spent half a day figuring how to answer the stupidest email I've ever received. This mail was sent to me by a person I'd been discussing with hours at least three times, and the subject was always the same: covered and hidden below a shelter of slight modifications, the goal this person wanted to accomplish was basically that I said he was right. But right about what?

Let's see. I usually don't spend my precious spare time quarreling with a person I met at most twice in my life, talking about a discussion he had with a friend of mine. Unfortunately, my "education" sort of... obliged me to sit and listen to him, even if he was wounding my friend's privacy. After illustrating my (pretty detached) point of view from the subject, which I'm no way involved with, he sent me a long email. The beginning of the mail was:

"I hope this mail will change your basic ideas about the subject. I think you're wrong."

Well, whether I'm right or wrong it's my problem, and I find pretty "unkind" trying to change my opinions, because this violates the basic assumption of human communication: communicating! I'm not interested to a three-hours one-way "communication", I would rather call it a monologue. A monologue about something which annoys me most.

Fortunately, Carlo Maria Cipolla came to my mind and solved all of my problems. My anger wouldn't let me focus about the biggest problem of all, which unfortunately can't be solved: I was (trying to) communicate with a stupid person. Carlo Maria Cipolla, an eclectic economist, published a collection of essays titled "Allegro ma non troppo". In one of them, "The fundamental laws of human stupidity", Cipolla explores the nature of stupidity. It's a funny and enlightening read, I would suggest this book to every(non-stupid)body.

According to Cipolla, these are the five fundamental laws of stupidity:

1. Always and inevitably each of us underestimates the number of stupid individuals in circulation.
2. The probability that a given person is stupid is independent of any other characteristic possessed by that person.
3. A person is stupid if they cause damage to another person or group of people without experiencing personal gain, or even worse causing damage to themselves in the process.
4. Non-stupid people always underestimate the harmful potential of stupid people; they constantly forget that at any time anywhere, and in any circumstance, dealing with or associating themselves with stupid individuals invariably constitutes a costly error.
5. A stupid person is the most dangerous type of person there is.

Thanks to the fourth law, and because of the golden first law, I recognized the costly error I was going to make! I moved the suffered email draft to the trash, and went out for a beer with a (non-stupid)friend.

Setting up a Solaris zone for Blastwave software

When I first installed Blastwave software on Solaris 10 or Solaris Express, I just installed it on the global zone. I soon realized that this decision would cause some problems. Blastwave packages were replicated in every Solaris zone I created and, letting aside the waste of disk space, the process of upgrading Blastwave's packages was painful because:

• it propagated changes to every non-global zone by default
• it complained about packages dependencies with messages such as:

# /opt/csw/bin/pkg-get -u
## Verifying package dependencies in zone
## Verifying package dependencies in zone

The package depends on package currently
being removed from zone .

The package depends on package currently
being removed from zone .

The package depends on package currently
being removed from zone .

The package depends on package currently
being removed from zone .

Dependency checking failed for package on zones
.

Do you want to continue with the removal of [y,n,?]

One solution to avoid propagating packages to non-global zones would be using the -G pkgadd flag, which Blastwave packages use indirectly, and this can be achieved by setting the ADMINFLAG variable:

export ADMINFLAG=' -G'

Thanks to some suggestion by the LQ guys, I also discovered that, to comply with Solaris/SVR4 standards, Blastwave CSW packages should (but don't) separate configuration files by providing the /var/opt/csw and /etc/opt/csw directories.

The solution I chose was creating a non-global zone to install Blastwave's software and loopback mount /opt/csw in the other zones. I then created a sparse zone and installed all the Blastwave's packages I needed there. The last thing I had to do was loopback mounting the non-global zone's /opt/csw directory into the global zone (to give desktop users access to the software) just adding this line in /etc/vfstab:

/export/home/zones/blastwave/root/opt/csw - /opt/csw lofs - yes

Blastwave's packages are now isolated in their zone and management is straightforward via Blastwave's pkg-get command.

Configuring Squid web proxy server on Solaris Express Developer Edition 01/08

Even if it really is a production machine, it's running Solaris Express Developer Edition 01/08. I decided to deploy a web proxy to save and control access to the network bandwith of my office and started looking for Sun Microsystem's solution: Sun Java System Web Proxy Server. Before downloading, I started to read the official documentation at Sun documentation center when I discovered that Solaris Express Developer Edition 01/08 ships with Squid.

I decided to spare a download and (yet another) setup giving Squid a try. Starting and configuring the service was really easy. The service is disabled by default and can be started with the SMF command:

# svcadm enable svc:/network/http:squid

Before doing that, you must configure Squid. I'm now just testing with the default values but at the very least you must grant access to the client machines. Squid configuration file is not complicated and, with the help of some googling (for example, this old O'Reilly article), I just ended up defining an ACL and granting access to it. I opened Squid configuration file, /etc/squid/squid.conf, with my favorite editor (vi) and added the following lines:

acl our_networks src 192.168.0.0/24
http_access allow our_networks

just before the last "deny all the rest" directive,

http_access deny all

The first line just defines an acl for my entire office network, which happens to be 192.168.0.0/24 and the second line grants HTTP access to all clients on that range. I then started Squid and tested that it worked examining its access log file, /var/squid/logs/access.log. If you see lines like this:

1208657695.111 239 192.168.0.128 TCP_MISS/304 255 GET http://www-cdn.sun.com/share/metrics/metrics_group1.js - DIRECT/87.248.220.12 text/javascript

it means that Squid is serving an unmodified page from its cache. The HTTP 304 status code indicates indeed that a "Not modified" page has been requested.