Building lighttpd as a SOAP server

Lighttpd, pronounced "lighty", is a powerful light-weight web server that makes an ideal candidate for use in building dedicated SOAP application server.  In this article, I explore the use of Lighttpd as the engine in serving SOAP requests.  The following criteria was used in selecting the candidates:

  • small operational and memory footprint
  • able to handle multiple simultaneous requests
  • capable of running HTTP and/or HTTPS over SSL for encryption
  • Perl CGI capable
  • easy to configure

With that said, lighttpd seemed the perfect fit.  As I worked more and more with lighttpd, I found that all of the criteria was met, with one caveat. SSL client-side certificate validation cannot be disabled in the current release 1.4.20 that I am running.  While this is not a show-stopper, it is a hindrance and is very annoying because it means you cannot use self-signed certificates.

Read more ...

Configuring stealth name servers in VitalQIP 7.1

A new feature exists in the VitalQIP product that provides great flexibility to DNS administrators in configuring stealth name servers on a zone-by-zone basis.  The purpose of this article documents how to configure this feature using the thick client(s), as well as, how to configure it for a large number of zones using SQL.  Currently, there doesn't appear to be a CLI that can configure stealth name servers, so we'll demonstrate how this can be done in SQL instead.  There should be a CLI created in support of configuring stealth name server configurations.  

Performing SQL writes to your VitalQIP database may be harmful.  Please ensure that the database is backed up prior to commencing on any SQL updates and/or writes to the database.  Netlinx, Inc. makes no warranty on the following SQL sequences documented in this article.

Read more ...

Implementing a logger in PHP

The purpose of this article is to document the creation of a logger using the incubation project Log4PHP from the Apache Foundation.  This logger is a port of the Log4J, and existed long before it became an incubation project at Apache.  Netlinx, Inc. has been using the 0.9.0 release for several years, and has been migrating to the Apache supported release.  Information on obtaining the Apache code can be found at http://incubator.apache.org/log4php/source-repository.html.

Read more ...

How to deal with arithmetic overflow errors in Sybase?

Following a recent port of a home-grown Perl Module that used DBI and Oracle, I noticed that I was getting arithmetic overflow errors in Sybase. The SQL code and database schema were largely the same, but the database platform had changed. I found a way to squelch the error messages in Perl DBI.  To do so, you must add the following:

#!/usr/bin/perl

my $dbh = DBI->connect($dsn, $uid, $pwd)
        or die "unable to connect to $dsn" . DBI::errstr();
        
# turn off those pesky Sybase Arithmetic Overflow errors on no results.
$dbh->do("set arithabort off");

While this worked to suppress the alert messages, it became clear to me that my script was still not working right.  Closer examination revealed that the size of a default INT or INTEGER datatype is 2^31 or 2147483648.  When converting Subnet Addresses to decimal equivalents, there are times when the decimal equivalents are going to exceed that since an IP address is a 32-bit number or 4294967296.  This caused errors in the script.  To resolve this properly, I needed to use the CONVERT function to convert the INT to a BIGINT.  The script was modified as follows:

 my $sql = "SELECT s.subnet_addr1, 
                   s.subnet_addr2, 
                   s.subnet_addr3, 
                   s.subnet_addr4
            FROM $dbo.subnet s, $dbo.networks n, $dbo.organizations o
            WHERE o.org_name = '$org'
            AND   n.org_id   = o.org_id
            AND   (CONVERT(BIGINT,s.subnet_addr1) * 256 * 256 * 256) +
                  (CONVERT(BIGINT,s.subnet_addr2) * 256 * 256) +
                  (CONVERT(BIGINT,s.subnet_addr3) * 256) +
                  (CONVERT(BIGINT,s.subnet_addr4)) <= $dec 
            AND   (CONVERT(BIGINT,s.last_address) - 1) >= $dec ";

How do I enable CGI in Tomcat server for VitalQIP?

The purpose of this HOW-TO is to explain the steps involved to enable perl cgi scripts in the Tomcat application server. 

  1. Uncomment the <servlet> tag for <servlet-name> cgi </servlet-name> in the $CATALINA_HOME/conf/web.xml file
  2. Uncomment the <servlet-mapping> for <servlet-name> cgi </servlet-name> in the same file
  3. Rename servlets-cgi.renametojar to servlets-cgi.jar in the $CATALINA_HOME/server/lib directory
  4. Create new directory structure in $CATALINA_HOME/webapps mkdir -p $CATALINA_HOME/webapps/CGI/WEB-INF/cgi
  5. Copy perl and cgi scripts to $CATALINA_HOME/webapps/CGI/WEB-INF/cgi
  6. Restart tomcat so that it re-reads web.xml
  7. Access the perl and cgi scripts at http(s)://hostname:port/CGI/cgi-bin/script.cgi

Building DBD::Sybase on Unix Systems

When building DBD::Sybase on UNIX, you have a few choices as to how you build it.  First the DBD::Sybase module can be used to connect to Microsoft SQL Server and/or it can be used to connect to Sybase 12.x or 15.x databases.  Let's assume that we want to be able to connect to both Sybase and Microsoft SQL server.  For that we'll need to have the FreeTDS library installed.  This is required to get DBD::Sybase working for Microsoft SQL Server, but it can also be used when connecting to Sybase.  You will lose some of the functionality as opposed to compiling directly against the Sybase libraries.

Assumming that FreeTDS is already installed in /usr/local, you would normally perform the following steps:

SYBASE=/usr/local;export SYBASE
perl Makefile.PL -prefix=/export/opt/my_perl_mods
make
make install

When attempting to build DBD::Sybase 1.0.8 against FreeTDS 0.82 it fails.  You MUST edit the dbdimp.c file in the DBD::Sybase source that you download.  Add the following to the top of the file:

#define BLK_VERSION_150 BLK_VERSION_100
#define BLK_VERSION_125 BLK_VERSION_100
#define BLK_VERSION_120 BLK_VERSION_100

Then repeat the steps above.  The module should compile and install without any problem.

When using DBD::Sybase to connect only to Sybase database servers, its recommended that you build it against the installed Sybase libraries.

Do this by:

SYBASE=/export/opt/sybase; export SYBASE
perl Makefile.PL prefix=/export/opt/my_perl_mods
make
make install