A little while ago (and again more recently) I updated my kernel to 3.7.3-101 and was stumped as to why VMware Workstation was unable to find the matching kernel headers, despite confirming they were indeed correct and installed. After lots of searching and some reading, I found the following command:

ln -s /usr/src/kernels/3.7.3-101.fc17.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.3-101.fc17.x86_64/include/linux/version.h

This basically creates a symbolic link in the /usr/src/kernels/<version>/include/linux/ directory for the version.h file that the VMware Workstation compiler is looking for. After running this command, I started VMware Workstation again and was greeted by the GUI compiling the necessary modules to run VMware Workstation.

I suspect the requirement for this command has something to do with re-arrangement of kernel source files in recent releases. It seems likely that VMware will update the compiler in new releases of their Workstation product.

Here’s a more recent upgrade, using the same step:

ln -s /usr/src/kernels/3.7.9-101.fc17.x86_64/include/generated/uapi/linux/version.h /usr/src/kernels/3.7.9-101.fc17.x86_64/include/linux/version.h

So long as you have the matching kernel headers installed, the above command should work for you just fine.

Note: On the second time around, I had troubles when running VMware Workstation as a normal user (just the compiling step, afterwards it was fine). For some reason there was an issue elevating the user to root (this happened to me on Fedora 17 x86_64) to complete the compiler process. To work around this, I simply opened a console/terminal, became root (sudo, or su – , whatever suits you) and then typed just: vmware – The compiler GUI appeared and completed, followed by VMware Workstation starting. I then closed ‘that’ VMware Workstation and started it my usual way (KDE menu for me) and it worked just fine.

Update (2013-03-25): VMware has recently released VMware Workstation 9.0.2 (2013-03-07) which has the above issue resolved. I am currently running VMware Workstation 9.0.2 build-1031769 on Fedora 17 (Kernel 3.8.3-103) and I did not have to carry out any additional steps to compile the kernel modules.

Update 2 (2013-07-10): I updated my kernel today, all the way up to 3.9.6-200-fc18 – Afterwards I was unable to compile the module again. After much searching, trouble-shooting and attempts to roll back to previous kernels, I checked something a little more fundamental; was gcc installed? Nope! It wasn’t! A quick browse through my yum logs showed it removed as a dependency when I removed something else earlier in the year. After installing gcc again, the kernel module compiled normally again 😉

Update 3 (2013-08-30): I updated my kernel again today, just a standard yum update with all the usual packages. My kernel ended up on 3.10.9-200.fc18.x86_64 (I haven’t upgraded to Fedora 19 yet). This time, the vmware kernel modules kept failing to compile (different to the previous issues). I did a quick google search for “vmware kernel 3.10.9-100” and found this article. If you follow the instructions, verbatim, the issue is solved straight away. For reference, I’ve copied the main content of the article below. Kudos to the author at http://guide.ecsmy.com/ for getting this one out there!

# tar xf /usr/lib/vmware/modules/source/vmnet.tar
# cd vmnet-only
# wget  http://communities.vmware.com/servlet/JiveServlet/download/2239207-108590/procfs.patch
# patch -p1 < procfs.patch
# cd ..
# tar -cvf vmnet.tar vmnet-only/
# cp vmnet.tar /usr/lib/vmware/modules/source/

This will patch the procfs interface.

Secondly download the vmnet patch from http://mysticalzero.blogspot.com/2013/07/vmblock-patch-for-linux-310-vmware.html. The link of the patch is here.

Or you can use the following command:

# tar xf /usr/lib/vmware/modules/source/vmblock.tar
# cd vmblock-only
# wget  https://sites.google.com/site/mysticalzerotmp/vmblock.3.10.patch
# patch -p1 < vmblock.3.10.patch
# cd ..
# tar -cvf vmblock.tar vmblock-only/
# cp vmblock.tar /usr/lib/vmware/modules/source/

Then, issue this command to compile and install the vmware player module

# sudo vmware-modconfig –console –install-all

I know it says ‘vmware player’ but trust me, it works for VMware Workstation just the same.

Update 4 (2013-10-20): I updated my kernel again today, just a standard yum update with all the usual packages. My kernel ended up on 3.11.4-101.fc18.x86_64 (I haven’t upgraded to Fedora 19 yet). This time, the vmware kernel vmblock module kept failing to compile (similar but different to the previous issue). I did a quick google search for “vmware kernel 3.11” and found this article. If you follow the instructions, verbatim, the issue is solved straight away. For reference, I’ve copied the main content of the article below. Kudos to the author (dibl) at siduction.org for getting this one out there!

The VMware module source needs to be patched to build on kernel 3.11. If you have already patched for 3.10, then only a single patch is needed. Here is the procedure:

Download the “vmblock.3.11.patch” from here.

In a root terminal, give these commands:

# cd /usr/lib/vmware/modules/source
# tar xvf vmblock.tar
# cd vmblock-only
# patch -p1 < /path/to/vmblock-3.11.patch
# cd ..
# tar cvf vmblock.tar vmblock-only/
# vmware-modconfig –console –install-all

You should see an error-free completion of the build.

Update 5 (2013-12-14): While still on Fedora 18 (I know, Fedora 19 is well and truly out, and Fedora 20 (celebrating 10 years of Fedora Linux!) is less than three weeks away from release!), I just upgraded to Kernel 3.11.10-100. I also upgrade from VMware Workstation 9.0.2 to VMware Workstation 10.0.1 – After a reboot, no additional work required. VMware Workstation 10.0.1 simply worked ‘straight out of the box’ so to speak 😉

I recently had a requirement to remove vmware tools manually from a windows 2003 server. This is what I had to do.

  • Remove any keys with a DisplayName of VMware Tools anywhere in the following keys:
    • HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionuninstall
    • HKEY_LOCAL_MACHINESoftwareClassesInstallerProducts

 

  • Remove the keys with a ProductName of VMware Tools in the following keys HKEY_CLASSES_ROOTInstallerProducts
  • Delete the branch named VMware Tools in HKEY_LOCAL_MACHINESoftwareVMware
  • Delete the "VMware Tools" directory within in the Vmware directory under Program Files
  • Restart the server.

Props to WarOnErrors.

After installing ConfigServer Security and Firewall, many of us try to achieve as many ‘green’ results as possible. The often tricky one (or two) options to achieve, is mounting /tmp and /var/tmp as ‘separate’ file systems. On a bare metal linux installation (no virtualisation) this is easy to achieve by creating a file system (partition or pseudo file system) and mounting it accordingly. Under virtualisation (openvz, virtuozzo etc) this is not so easy, in fact, it’s not actually supported at all. However, there are two things you can try.

  1. Nothing. Just leave it. After all, the message at the bottom of the check security page says ‘This scoring does not necessarily reflect the security of your server or the relative merits of each check’ In other words, getting all green doesn’t necessarily mean your server is secure.
  2. You can set up pretend mount points (this works on bare metal installations as well). Delete the /var/tmp directory and symlink it to /tmp (ln -s /tmp /var/tmp). Next, edit your /etc/fstab file and all the following line: /tmp /tmp   ext3    defaults,usrquota,bind,noauto,noexec,nosuid        0 0 Finally, be sure to change the permissions to 1777 (chmod -R 1777).

The second option above doesn’t really achieve anything except the green ‘OK’ from CSF. Traditionally, the /tmp and /var/tmp directory have been located on a separate file system, due to the volatile nature of the files and content that are temporarily stored there. If the server was compromised via this directory, it could be easy to stop the compromise by un-mounting the file system. Better still, if the file system itself was hacked or damaged, it would only be the /tmp and /var/tmp that was damaged, both of which are easily replaced and can be deleted, removed and recreated all while the system is still running, not to mention that no important data is ever stored in these directories either.

If your server has SUHOSIN installed/enabled, regardless of whether you have cPanel/WHM or not, this should work for you. Disabling PHP functions using the 'disable_functions' section of your php.ini file won’t really work too well if you using SUHOSIN. Instead, comment out the 'function_disable' line and add the following under neath it:

suhosin.executor.func.blacklist = "show_source,shell_exec,passthru,exec,popen,allow_url_fopen,system"

Of course your list of disabled features may not be the same as the example above, so be sure to add or delete the functions you want disabled or enabled from the list. Once you are done, restart apache and check your results with a phpinfo.php file. The following code inside a phpinfo.php file should do it:

<?php
phpinfo();
?>

Save the file and access it via your browser.

Search the page for the following value:

suhosin.executor.func.blacklist

The Local Value and Master Value should contain the following (as per the example in this case).

show_source,shell_exec,passthru,exec,popen,allow_url_fopen,system

Some plugins (cPanel or Other) may still complain that these functions are not disabled. You can rest assured, that they are disabled. In the case of wanting to simply please the software application (content management system etc) you can still add the entries as desired using the 'disable_functions' section of your php.ini file, although they won’t actually have any affect, as the values are overridden by the suhosin line. In some cases, apache may complain about both lines existing, in which case you may have to modify the software application to skip the check instead.

What about if I want to enable a feature for one particular domain?

If you want to enable or disable feature/s for one particular domain, a custom configuration can be set. On a standard server without cPanel/WHM, you would edit the vhost for the domain concerned. This may be the main /etc/httpd/conf/httpd.conf file or it may be an include file. This will depend on your servers configuration. The short of it is, you simply add the following line to the end of the vhost configuration for the particular domain:

php_admin_value suhosin.executor.func.blacklist 'show_source,popen,allow_url_fopen,system'

In the above example, I’ve allowed shell_exec and passthru by not specifying them in the blacklist. If you browse to your phpinfo.php file, you’ll notice the Local Value and Master Value are now different. The local value is the configuration on the domain concerned, the master value is the server wide global configuration. Note: you need to be visiting the phpinfo.php file via the domain or dedicated IP Address of the domain you are making the change for.

The process is exactly the same on servers with cPanel/WHM. The only difference is that editing the /etc/httpd/conf/httpd.conf is discouraged, as future re-compiles of apache and updates of cPanel/WHM can cause the changes to be lost. Instead, each vhost in the /etc/httpd/conf/httpd.conf file should have one or some of the following lines at the end of the vhost section:

Include "/usr/local/apache/conf/userdata/*.conf"
Include "/usr/local/apache/conf/userdata/*.owner-username"
Include "/usr/local/apache/conf/userdata/std/*.conf"
Include "/usr/local/apache/conf/userdata/std/*.owner-username"
Include "/usr/local/apache/conf/userdata/std/2/*.conf"
Include "/usr/local/apache/conf/userdata/std/2/*.owner-username"

Don’t worry if you don’t have all of the above lines, or they don’t look exactly the same. So long as you can see an include line to a directory, that is all you need. Go to that directory (in this example I’m using Include "/usr/local/apache/conf/userdata/std/*.conf" and create a file called domainname.conf or username.conf (so long as it ends in .conf). Edit the file and place the following line in it:

php_admin_value suhosin.executor.func.blacklist 'show_source,popen,allow_url_fopen,system'

Save your file and restart apache

/etc/httpd/init.d/httpd restart

Browse to your phpinfo.php file and compare the Local Value against the Master Value. They should be different!

If you have any feedback, troubles or would like some additional assistance, be sure to let me know in the comments.