Problem with automatic VMWare upgrade from 9.0.1 to 9.0.2

VMWare Workstation checks upon startup if there are new version of the software, and if it is then it asks you if you want to upgrade. In case automatic checking is disabled, there is an option under the Help menu that allows manual triggering of that process. For some time now I was getting notification about free upgrade from 9.0.1 to 9.0.2 which I would enable, but which never finished for unknown reason. Instead of trying to figure out what was wrong I decided to try to do it manually. In the end, it turned out to be a semi-manual process. Namely, when I received an error message about being unable to upgrade I looked where downloaded files are. It turned out that they are stored in /tmp directory but that they have UUID like names, i.e.:

$ ls -l
total 381768
-rw-r--r--.  1 sgros zemris  66211840 Kol 29 13:28 06dd4484-5c02-4c5d-992c-ff705703e6cb
-rw-r--r--.  1 sgros zemris  11253760 Kol 29 13:29 1cf5e724-f7d4-4f24-b484-30ebb16d593e
-rw-r--r--.  1 sgros zemris  61777920 Kol 29 13:29 2007e14d-3593-416f-b60e-08c4cd18693a
-rw-r--r--.  1 sgros zemris 232693760 Kol 29 13:31 364c998b-8b3b-4cfd-a2dc-67352a3eb082
-rw-r--r--.  1 sgros zemris  13096960 Kol 29 13:31 4b7424a6-e114-4832-be21-f0a3acf8c24b
-rw-r--r--.  1 sgros zemris     81920 Kol 29 13:31 8a8d105f-fd3d-404a-afc9-28411d6566fe
-rw-r--r--.  1 sgros zemris   5795840 Kol 29 13:31 d969898b-30bb-4c6d-bf45-5a7d52918359

Now, using file command it was easy to determine that they are actually tar archives so. So, I created new directory and unpacked all those files there. What I've got was one file with extension bundle and several files with an extension component.

# ls -l
total 390904
-rw-r--r--. 1   201    201      1161 Vel 26  2013 descriptor.xml
-rw-r--r--. 1   201    201  15207519 Vel 26  2013 vmware-tools-freebsd-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  66202162 Vel 26  2013 vmware-tools-linux-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201     76615 Vel 26  2013 vmware-tools-netware-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  13088243 Vel 26  2013 vmware-tools-solaris-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  61771010 Vel 26  2013 vmware-tools-windows-9.2.3-1031769.x86_64.component
-rw-r--r--. 1   201    201  11247429 Vel 26  2013 vmware-tools-winPre2k-9.2.3-1031769.x86_64.component
-rwxr-xr-x. 1 sgros zemris 232680125 Vel 26  2013 VMware-Workstation-9.0.2-1031769.x86_64.bundle

The bundle type file is actually an installer for a new version of VMWare, so I've run it as a root user and it installed new version of VMWare. The component files, on the other hand, have to be installed using vmware-install tool, e.g. to install vmware-tools-windows-9.2.3-1031769.x86_64.component file, execute the following command as a root user:

vmware-installer --install-component=vmware-tools-windows-9.2.3-1031769.x86_64.component

The same command has to be repeated for the other files too. But, note that those files are optional, depending what you've running. You can check which components you have installed using vmware-installer command with an option -t, i.e.
vmware-installer -t
And that was it. Of course, before being able to run VMWare I had to patch it again. But that was it.

Fedora 17 and VMWare Workstation 9...

I just upgraded VMWare Workstation to version 9. Everything went fine except I couldn't start virtual machines. :) Each start crashed the machine with some nasty kernel error. :) A quick googling reviled this link. Basically, you have to download patch, unpack it and run installation script from within.

The only problem I had was that script, somehow, thought that it was already applied:

# ./patch-modules_3.5.0.sh
/usr/lib/vmware/modules/source/.patched found. You have already patched your sources. Exiting

What happened actually is that previous patches I applied left this file and because of some error (I didn't investigate details) the script was confused. So, I simply removed offending file (/usr/lib/vmware/modules/source/.patched) and restarted script.

VMWare Workstation on Fedora 17...

Today, when I started VMWare Workstation, it notified me that there is a free security update. Since it is advisable to update whenever there are security issues, I approved it, but of course that after update I had a problem starting VMWare workstation. Since there are constantly problems with VMWare and Fedora I finally decided to track everything I had to do in this post. In other words, this post will be updated whenever I have to do something to VMWare Workstation to get it to work.

Ok, as I said, on a fully updated Fedora 17 (kernel-3.4.2-4.fc17.x86_64) when a new VMWare Workstation 8.0.4 is installed (or updated) it can not configure itself because of errors in kernel modules. As I wrote this I wasn't able to find a patch that fixes everything in one step, but I managed to combine two fixes that allowed VMWare to start. First, I had to apply patch for 8.0.3 that fixed vmnet.tar file. To do that I also had to modify a bit the script distributed with patch so that it accepts the fact that I'm using a newer version of VMWare (i.e. 8.0.4 instead of 8.0.3). Then, I had to apply a small fix for vmblock.tar that I wrote about in other post. Finally, I tried to start VMWare Workstation but it failed again?! After a bit poking, I realized  that there were dangling processes/modules so I had to kill all VMWare processes, remove modules, and that start succeeded. Of course that I could also restart the laptop, but because of the number of open windows I have, that wasn't an option. :)

When I did all that, then I found out that there is a patch that does all this, i.e. those two steps but combined, but it is for VMWare Workstation 8.0.2, which means you still have to poke a bit in script that applies a patch. And finally, this blog seems to be a good place to look when you have some problems with VMWare (and VirtualBox) and newer versions of kernel.

Compiling OVALDI for CentOS 6

Note: Take a look at the newer version of this post. Things are simpler now.

I described in one earlier post the purpose of OVAL and the benefits it gives to a user. Here I'm going to describe how to setup OVAL interpreter on CentOS 6. The problem is that there is no prepackaged Oval interpreter for CentOS 6. Actually, there is but it's only for 32 bit version of CentOS 4 and 5, an it is an older version, not the latest one. So, here I'm going to describe how to build it from source. The build process consists of building XML processor Xalan, then XSLT processor Xerces and finally in building interpreter itself. There are certain prerequisites you need to have in order for Oval to build, I'll mention those also.

I'll assume that you created working directory for this purpose and that you run all the following commands within that directory. When necessary, I'll reference that directory as $WORKDIR and when you see that string replace it with full path of your working directory. Also, I'm going to install oval interpreter into directory /opt/oval. The reason I'm not placing it into some of the "system" directories like /usr/bin, /usr/lib and similar is to avoid clash with versions of xalan and xerces shipped with distribution itself.

In case you trust me enough, here is archive of final content of directory /opt/oval, so you can unpack it and skip to the Running ovaldi section.

Installing prerequisites

Xerces
Download version 2.8.0, or whatever is the latest version of Xalan 2. Don't use Xalan 3 because API was changed with respect to version 2 and OVAL won't work with it! In the following text, I'll reference version 2.8.0 and if there is a newer one replace version numbers as necessary.

After downloading some package it is a good practice to check MD5 sum (or SHA1). In this case md5 sum will give the following output:

$ md5sum xerces-c-src_2_8_0.tar.gz
5daf514b73f3e0de9e3fce704387c0d2  xerces-c-src_2_8_0.tar.gz

which matches the one given on the dowload page.

Now, unpack the archive using the following command:

$ tar xzf xerces-c-src_2_8_0.tar.gz

and you'll get directory xerces-c-src_2_8_0/. Go into that directory and then into src/xercesc subdirectory. Before configuring distribution set the environment variable XERCESCROOT to the top level directory of the unpacked archive, i.e.

export XERCESCROOT=$WORKDIR/xerces-c-src_2_8_0

now, start configuration process:

./runConfigure -p linux -c gcc -x c++ -b 64 -P /opt/oval

In that command option p specifies platform on which you are performing build process, option c specifies compiler to use, x specifies c++ compiler, option b determines bit width of the platform (32 or 64 bit) and option P specifies installation directory. All the other options have appropriate default values. Note that you must specify c++ instead of g++! If you specify g++, then while building Xalan, you'll get the following errors:

$XERCESCROOT/lib/libxerces-c.so: undefined reference to `stricmp(char const*, char const*)'
$XERCESCROOT/lib/libxerces-c.so: undefined reference to `strnicmp(char const*, char const*, unsigned int)'

The problem is that the configuration process misidentified that GNU's compiler is used that doesn't have stricmp and strnicmp functions and it didn't include replacement functions!

If everything went without an error, start build process by issuing make command:

make

and finally, install xerces (you should switch to root user to run the following command):

make install

Xalan
Go to the download page and take most recent version of Xalan. I was using 1.10 which was the latest one at the time this post was written. So, after download it, and checking signature(!), unpack it with the following command:

tar xzf Xalan-C_1_10_0-src.tar.gz

This will create new directory, xml-xalan/. Before building Xalan, you should apply a patch to it. The problem is that gcc developers made some changes to header files (removed unnecessary includes) in recent version available on CentOS and that means that some prerequisite includes have to be explicitly specified. The problem is manifested with the following error messages:

home/zavod/sgros/work/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp: In member function ‘xalanc_1_10::XalanDOMString& xalanc_1_10::XalanDOMString::assign(const xalanc_1_10::XalanDOMString&, xalanc_1_10::XalanDOMString::size_type, xalanc_1_10::XalanDOMString::size_type)’:
/home/zavod/sgros/work/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:251: error: ‘memmove’ was not declared in this scope
/home/zavod/sgros/work/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp: In static member function ‘static xalanc_1_10::XalanDOMString::size_type xalanc_1_10::XalanDOMString::length(const char*)’:
/home/zavod/sgros/work/xml-xalan/c/src/xalanc/XalanDOM/XalanDOMString.cpp:780: error: ‘strlen’ was not declared in this scope

So, download the patch and enter into xml-xalan directory. Then, run the following command:

$ patch -p1 < ../xml-xalan.gcc-4.4.patch
patching file c/src/xalanc/TestXPath/TestXPath.cpp
patching file c/src/xalanc/XalanDOM/XalanDOMString.cpp
patching file c/src/xalanc/XalanExe/XalanExe.cpp
patching file c/src/xalanc/XMLSupport/FormatterToHTML.cpp
patching file c/src/xalanc/XSLT/ElemNumber.cpp

this assumes that you've downloaded patch into the same place where you downloaded Xalan itself (i.e. $WORKDIR).

Now, enter into subdirectory named c/. Before configuring the build process, define the variable XALANCROOT. You should set it to $WORKDIR/xml-xalan/c with the following command:

export XALANCROOT=$WORKDIR/xml-xalan/c

Also, note that Xalan depends on Xerces and to be able for Xalan to find Xerces you need to set the environment variable XERCESROOT, or Xerces has to be in some system directory that is searched by default (e.g. /usr/include and similar directories).  If you followed this post withouth interruption, you probably have it defined already. Now, initiate configure process using runConfigure command:

./runConfigure -p linux -c gcc -x c++ -b 64 -P /opt/oval

the options used are same as for Xerces. Initiate build process using make, and after build finishes, install it using 'make install' command switching before to root user.

Necessary development packages
As a final prerequisite you should check that the following development packages are installed. The simplest way to do that is to initiate install process and yum will react appropriately: pcre-devel, libgcrypt-devel, rpm-devel, openldap-devel, libblkid-devel, and libselinux-devel.

Building and installing Ovaldi
Go now to the download page of Ovaldi and download the latest version. Version 5.10.1.1 is the latest one at the time of writing this post. So download it and upack it. This will create directory ovaldi-5.10.1.1-src. Also, download the following patch. Note that this patch is made so that ovaldi can be compiled on CentOS 6 and it is not applicable for other distributions, neither it will allow ovaldi to be compiled on other platforms (though, very unlikely it might :)).

Now, enter ovaldi-5.10.1.1-src directory and apply patch:

patch -p1 < ../ovaldi-5.10.1.1-centos6.patch

Three changes are in the patch file. The first one is addition of /opt/oval/include and /opt/oval/lib directories in main Makefile. The second are some changes to RPM part of the code since API has changed in recent versions of RPM. More specifically, I introduced compatibility switch (-D_RPM_4_4_COMPAT) and also replaced int_32 with int32_t types.

Third change resolves the following error message already reported on some forums:

Error running rpm query in child process: blah: -q: unknown option

There is also additional patch that isn't always necessary, and that's why I separated it. Namely, I placed ovaldi in /opt/oval directory, while ovaldi expects by default its shared files to be within /usr/share/oval. So, this patch changes this:

patch -p1 < ../ovaldi-5.10.1.1-sharepath.patch

Since for some unknown reason (I didn't have will/time to investigate further) linker can not find libxalanMsg.so.110 library, even though it has appropriate path in -L option, define LD_LIBRARY_PATH using the following command prior to comilation:

export LD_LIBRARY_PATH=/opt/oval/lib/

Finally, enter project/linux subdirectory and initiate build process:

make

When the build process is over, copy ovaldi binary (you'll find it in project/linux/Release subdirectory) to /opt/oval/bin directory. Also, create directory /opt/oval/share/ovaldi and move there directory xml (you'll find it directly beneath ovaldi-5.10.1.1-src directory).

Running ovaldi
Finally, we are ready to run ovaldi interpreter. Before running ovaldi you should define LD_LIBRARY_PATH and optinally PATH variable. In other words, before running ovaldi execute once these commands:

export LD_LIBRARY_PATH=/opt/oval/lib
export PATH=/opt/oval/bin:$PATH

Then, try to run ovaldi, you should get help message.

This concludes this post. In the next one I'm going to try to run ovaldi using RedHat's provided files. Until I do this note that the patches I provided may turn to have errors that would prevent ovaldi from correctly functioning.

Software patching strategy...

There's much controversy about security flaw found in Windows XP and published by Google's researcher. You can read about it across the Internet, but here's one story. Short version is this: after the researcher found the flaw he gave Microsoft five days to react. But, Microsoft has something called 'patch Tuesday' which means it is delivering patches every Tuesday. I agree that this brings predictability to IT departments, but this is only true if the number of patches is high. So in the end, Microsoft didn't react in the given timeframe and the researcher published exploit. As I sad in one comment, I don't believe that Microsoft didn't react on purpose. It is more likely that they didn't know how to react and/or their procedures are not up to the task. Some are criticizing the researcher's approach, while the others are not. And it is true that this brought some IT managers, CISOs and who knows who else into very dangerous situation. But then, something like this should be made equal to impossible by a responsible company that is producing such a critical piece of a software like OS.

Contrast this researcher's behavior with some cracker that happened to find the same flaw. He could either sell it or devise exploit himself. In either case the exploit would be used at some point and the software producer wouldn't be notified about the flaw. By the time it is clear that there is a flaw, five days to react is huge time frame!

What is my point? The point is that in present times, and in future even more so, it is luxury to react in more than a day, maybe even in more than a few hours. Patches and workarounds have to be available immediately. Of course, someone could comment now that in the complex software it is hard to devise patch in a such short time frame. But, actually, I think it is possible with few changes in how software is developed.

First, software has to be clearly modularized. Each module has to have capability to be disabled or enabled. Obviously, when a flaw is found in a module, the first reaction would be to disable the module. Of course, there are two problems with this. The first one is that there are modules that are absolutely critical for a functional system. For example, in Linux kernel it is not possible to disable kernel locks because kernel can not function without them. But such a critical software should be made small and controllable so that it can be fixed in a matter of hour. The second problem is that some modules are not critical for the system itself, but are critical for the environment in which they are working. For example, driver for a network card. It can be disable, and the system itself will be functional, but it will also be useless. This case should be handled in such way that each user can use predefined functionality definitions and alter them or create a new ones. To return to an example with a driver for a network card. In this case it is common wisdom that no system today can work without network card. So, some profile will define network card as critical and as such it will not be disabled without explicit confirmation from the administrator. But, such modules have to be developed with principles somewhere in between the absolutely necessary modules and modules that aren't necessary at all (like Help system that is the cause of the problem with Windows XP that started this blog entry).