VMWare Workstation 11 can not be installed under Ubuntu 15.04

VMWare communities thread again gives a quick for this issue here:

Find the solution below:


Step 1: log in as root (e.g. sudo -s)

Step 2: Enter your Root password.

Step 3: Enter these commands:


curl http://pastie.org/pastes/9934018/download -o /tmp/vmnet-3.19.patch

cd /usr/lib/vmware/modules/source

tar -xf vmnet.tar

patch -p0 -i /tmp/vmnet-3.19.patch

mv vmnet.tar vmnet.tar.SAVED

tar -cf vmnet.tar vmnet-only

rm -r vmnet-only

vmware-modconfig –console –install-all


VMware will now compile the vmnet module for Kernel 3.19. (please make sure you have DKMS installed)

Datawrapper: Mails not delivered

I use my own instance of DataWrapper (An open source data visualization platform helping everyone to create simple, correct and embeddable charts in minutes. http://datawrapper.de) to quickly build some data visualizations.

For some strange reason, my login’s stopped working and I didn’t see the forgot password working for any of the users. I didn’t find a quick work around and I kept trying many trial and error methods.

Some how I jumped into a conclusions that I should install plugins of datawrapper again as this issue was never found to have been discussed elsewhere.

This is what I did inside the datawrapper installation directory. It went ahead and installed a plugin called email-native.

#php scripts/plugin.php install “*”
Re-installed plugin core-vis-options.
Re-installed plugin d3-bubble-chart.
Installed plugin email-native.
Re-installed plugin export-image.
Re-installed plugin export-static-png.

Strange as it should have been installed while I had installed datawrapper first time as I don’t remember facing any issue verifying my accounts earlier.

Now, I was able to reset the passwords for my account and login to regain access on all charts I have built so far.

Next Steps: Need to figure out if there has been any automated updates as we have few cron’s running with datawrapper and keep track of plugin errors and installation issues.

Fix: Strange cPanel errors with missing RPMs

Installing git on cPanel server gave a strange missing RPMs error though the rpm was existing in the CentOS 6 repo.

Error: Package: git-1.7.1-3.el6_4.1.x86_64 (base)
Requires: perl-Git = 1.7.1-3.el6_4.1

cPanel is known to create these issues as it won’t allow many of the RPMs to be installed and it also excludes major software RPM’s in yum configuration files.

To get rid of the error related to git I had to forcefully disable the main excludes as follows:

yum install git –disableexcludes=main

This indeed resolved the problem.

Fix: openvz, iptables, csf and errors

CSF has been one of the first choice for years now for me to secure server with a easily usable iptables manager. More than that it works as “A Stateful Packet Inspection (SPI) firewall, Login/Intrusion Detection and Security application for Linux servers”.

While using csf on OpenVZ vps systems we end up facing lots of issues with respect to iptables modules. If you’re a sysadmin managing hardware nodes it might not be easy though it has got to do something quite simple. I’m pasting the similar issue once again here for a reference and let us recheck what we normally oversee.

Error received during csf test:

:~# /etc/csf/csftest.pl
Testing ip_tables/iptable_filter…OK
Testing ipt_LOG…OK
Testing ipt_multiport/xt_multiport…OK
Testing ipt_REJECT…OK
Testing ipt_state/xt_state…OK
Testing ipt_limit/xt_limit…OK
Testing ipt_recent…FAILED [Error: iptables: No chain/target/match by that name.] – Required for PORTFLOOD and PORTKNOCKING features
Testing xt_connlimit…FAILED [Error: iptables: No chain/target/match by that name.] – Required for CONNLIMIT feature
Testing ipt_owner/xt_owner…FAILED [Error: iptables: No chain/target/match by that name.] – Required for SMTP_BLOCK and UID/GID blocking features
Testing iptable_nat/ipt_REDIRECT…OK
Testing iptable_nat/ipt_DNAT…OK

RESULT: csf will function on this server but some features will not work due to some missing iptable modules

Now, the quick remedy that we get to resolve this issue is to enable all the iptable modules in /etc/vz/vz.conf of the OpenVZ hardware node as follows:

IPTABLES=”ip_tables iptable_filter iptable_mangle ipt_limit ipt_multiport ipt_tos ipt_TOS ipt_REJECT ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_LOG ipt_length ip_conntrack ip_conntrack_ftp ipt_state iptable_nat ip_nat_ftp ipt_recent ipt_owner ipt_conntrack ipt_helper ipt_REDIRECT ipt_recent ipt_owner”

and restart all VM’s etc using  “service vz restart” to activate all modules to all VPS systems.

The other options we have is to enable these modules for a specific VPS/VM as follows: (PS: here 100 is a VPS id)

vzctl set 100 –iptables ipt_REJECT –iptables ipt_tos –iptables ipt_TOS –iptables ipt_LOG –iptables ip_conntrack –iptables ipt_limit –iptables ipt_multiport –iptables iptable_filter –iptables iptable_mangle –iptables ipt_TCPMSS –iptables ipt_tcpmss –iptables ipt_ttl –iptables ipt_length –iptables ipt_state –iptables iptable_nat –iptables ip_nat_ftp –iptables ipt_owner –iptables ipt_recent –save

If you run the above command with –setmode option, the modules will be applied.

Or you can add the IPTABLES line mentioned earlier (vz.conf entry) to VPS configuration file  (/etc/vz/conf/100.conf for the above example VPS) and restart VPS with the following command to make it effective.

vzctl restart 100

This was quite simple and known answer. But I have always found that it doesn’t go so smooth. This might be because of one simple reason that I quote here:

We keep removing OLD kernel packages etc and install the new ones to ensure that we have secure system with latest kernel and packages. During this process we end up loosing kernel modules required for the new modules. I figure this out once again while working on my hardware node just by typing the find command as follows under /lib

find /lib –name *ipt*

I was expecting the iptables modules to be listed under my current kernel but to my surprise I didn’t find them. I found them in one of the very old kernel that was installed on the box. Crazy. So, I decided to jump in and reinstall iptables packages quickly on the machine:

yum reinstall iptables-devel.i686 iptables-devel.x86_64 iptables-ipv6.x86_64 iptables.i686 iptables.x86_64

Here is the final output of my csf test after restarting my VM.

~# /etc/csf/csftest.pl
Testing ip_tables/iptable_filter…OK
Testing ipt_LOG…OK
Testing ipt_multiport/xt_multiport…OK
Testing ipt_REJECT…OK
Testing ipt_state/xt_state…OK
Testing ipt_limit/xt_limit…OK
Testing ipt_recent…OK
Testing xt_connlimit…OK
Testing ipt_owner/xt_owner…OK
Testing iptable_nat/ipt_REDIRECT…OK
Testing iptable_nat/ipt_DNAT…OK

RESULT: csf should function on this server

That’s it. Now you know why iptables doesn’t work even if you had not changed anything recently on hardware node (and forgotten that you restarted your system with a new kernel). Verify the iptables modules with lsmod and reinstall the packages if required.

SecurityException in Application.cpp:188: Do not have root privileges. Executable not set-uid

If you’re getting Internal server error all over the places on your websites on a cPanel server and PHP is configured to run as suphp CGI mode, then you might be observing the following error on error_log due to ModSecurity. It might be searching for the sticky/suid permission on suphp binary:

SecurityException in Application.cpp:188: Do not have root privileges. Executable not set-uid

To quickly get this fixed on your cPanel server execute the following command:

chmod +s /opt/suphp/sbin/suphp

This should fix the issue instantly.