Skip to content

WebTrends SDC behind Reverse Proxy

With WebTrends SmartSource Data Collector it is possible to write log files of your Web Application, that include many client side parameters. Like: screen resolution, language settings and several other default and custom build parameters. This technology is also often called Pixel Tracking.

To build this logs, you get a custom Webserver (Apache on Linux and Solaris - A module for IIS on Windows) that is not really configurable. And especially you cannot update the Apache underneath. Or even worse, would you like to put a Windows Server in your DMZ?

So the solution seems simple. Just place a reverse Proxy in front of it and keep this Server up to date and secure. There is one major drawback with this way, you loose the Client IP Address! This is also the case if you use a CDN (eg. Akamai). Since a CDN acts like a reverse Proxy the same trade-offs apply.

Thankfully there are options within the SDC that let you pass the Client IP as a custom HTTP Header. If you use Akamai you simply need to set this in EdgeControl. The Option is called "True Client IP Header" and by default it is set to "True-Client-IP". So the HTTP Request Header "True-Client-IP" holds the original client IP and you only need to read it.

To tell SDC to read this Header instead of the normal IP you have to edit the configuration of SDC. In you SDC installation directory you should find the file cfg/sdc.cfg. There you have to edit the [logserver] section.


After this is done, SDC will log the right Client IP Addresses.

If you use a Apache reverse Proxy you can create the "True-Client-IP" header with some rewrite magic.

RewriteEngine on
RewriteCond %{REMOTE_ADDR} (.*)
RewriteRule .* - [E=REMOTE_ADDR:%1]
RequestHeader set True-Client-IP %{REMOTE_ADDR}e
RewriteRule ^/(dcs.*)$ http://SDCSERVER:SDCPORT/$1 [P,QSA,L] 

This configuration extracts the Client IP Address and saves it into a environment variable. Afterwards this variable is placed in the HTTP Header. I found no direct way to do this, only with the use of a environment variable.

Well, it works that's what matters :-)

installing Oracle Instant Client on Linux

The Oracle Instant Client is a package that brings everything you need to connect to a Oracle Database. You can download it from Oracle with this Link.

With current Intel XEON Servers you should take the x86-64 package. But for 32-bit application you need the x86 package. You can install both in parallel, so it doesn't hurt if you take both. There are also several sub packages. You will only need the "Basic" or "Basic Lite" package if you want to run applications. If you want to build a application (like Perl DBD::Oracle or the PHP Oracle connector) You will also need the "SDK" package. If you want to run sqlplus, you will also need that package. You may also want to pick the right version for your database, but I experienced no problems with the newest client.

If you downloaded all you need the installation is as follows (tested on CentOS 5.2).

# install the RPMs
rpm -ivh oracle-instantclient11.1-basic-
rpm -ivh oracle-instantclient11.1-basic-
rpm -ivh oracle-instantclient11.1-sdk-
rpm -ivh oracle-instantclient11.1-sdk-

# set the libraries on the searchpath for the entire system
echo "/usr/lib/oracle/11.1/client/lib/" >> /etc/
echo "/usr/lib/oracle/11.1/client64/lib/" >> /etc/

# see if the libraries are included
ldconfig -p | grep oracle

Now you are ready either to run or build your application.

Have fun!

VMWare ESXi 3.5 and time sync

As you might already know VMWare and time sync are two things that don't play well together. Most times the time is off by some seconds or minutes or even better the time is not synchronized at all. I discovered today that ESXi 3.5 does not enable time sync by default. Even if you installed the VMWare tools!

To enable it, you need to log in into the Guest OS and execute the graphical program to adjust this setting. The program is "vmware-toolbox" and you simply need to activate the option "Time synchronization between the virtual machine and the ESX Server". Quite simple, but to do this you need either a X Server installed in the Guest OS or a forwarded X connection to a Workstation with a X Server. I personally don't like this, because it is complicated and you can't automate it. So I searched for a method to do this in a CLI interface.

After a bit of searching I found the following solution.

# Linux
vmware-guestd --cmd "vmx.set_option synctime 0 1" # Enable
vmware-guestd --cmd "vmx.set_option synctime 1 0" # Disable

# Windows
vmwareservice --cmd "vmx.set_option synctime 0 1" # Enable
vmwareservice --cmd "vmx.set_option synctime 1 0" # Disable

If time sync is already enabled, you will get a error message saying that the previous state is already set.