HP Servers can be real fun
# hplog -v hplog: Cannot open /dev/cdt. Wellness driver may not be installed.
Should I take the Server to the next spa?
# hplog -v hplog: Cannot open /dev/cdt. Wellness driver may not be installed.
Should I take the Server to the next spa?
This happened today as I counted some IP information for a Apache access log.
cat access_log | grep ... | awk '{print $1}' | sort | uniq -c | sort -n ... 1 234.123.234.254 3 123.212.123.123 3 232.231.233.252 7 213.211.122.153 ...
Can you see it?
If you want to see the answer just click more ...
"What do you see in this log?" vollständig lesenWith 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.
[logserver] enableheaderparams=true headerparamslist=True-Client-IP:DCS_CLIENTIP
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
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.
http://www.oracle.com/technology/software/tech/oci/instantclient/index.html
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-11.1.0.7.0-1.i386.rpm rpm -ivh oracle-instantclient11.1-basic-11.1.0.7.0-1.x86_64.rpm rpm -ivh oracle-instantclient11.1-sdk-11.1.0.7.0-1.i386.rpm rpm -ivh oracle-instantclient11.1-sdk-11.1.0.7.0-1.x86_64.rpm # set the libraries on the searchpath for the entire system echo "/usr/lib/oracle/11.1/client/lib/" >> /etc/ld.so.conf.d/oracle.conf echo "/usr/lib/oracle/11.1/client64/lib/" >> /etc/ld.so.conf.d/oracle.conf ldconfig # see if the libraries are included ldconfig -p | grep oracle
Now you are ready either to run or build your application.
Have fun!
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.