Keith's Web Blog RSS Feed

Typical Apache Build

Wed, 11 Feb 2004 17:07:22 -0700

Quickie for Apache 1.3.29 # apache configuration as dso ./configure --enable-module=most --enable-shared=max --prefix=/usr/local/apache1.3.29 make make install Afterwards, #cd /usr/local #ln -s apache1.3.29 apache I do this for version control.

mod_perl DSO installation

Thu, 12 Feb 2004 13:21:44 -0700

perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs EVERYTHING=1 --enable-EAPI make make install Be sure to change the WITH_APXS location depending on your apache root directory location.

PHP Installation

Thu, 12 Feb 2004 13:29:23 -0700

i generally create a small install script for my php installs: #!/bin/sh APACHE=/usr/local/apache APXS=${APACHE}/bin/apxs DB=/opt/databases MYSQL=${DB}/mysql PGSQL=${DB}/pgsql OPENSLL=/opt/openssl PHP_BASE=/usr/local/php VERSION=5.0.3 PHP_HOME=${PHP_BASE}-${VERSION} ./configure -prefix=${PHP_HOME} \ --with-apxs=${APXS} \ --with-openssl=${OPENSSL} \ --with-zlib \ --with-dom \ --with-xmlrpc \ --with-pgsql=${PGSQL} \ --with-mysql=${MYSQL} \ --enable-mbstring \ --enable-mbstr-enc-trans \ --enable-soap make make install cd /usr/local ln -s php-5.0.3 php cp /php.ini-dist /usr/local/php/lib/php.ini note: be sure to change the value of your php directory when copying the files over. I use this as a kind of standard. Also, you have to edit your httpd.conf file to tell apache to load certain extensions with php. add (after mod_negotiation.c): # # And for PHP 5.x, use: # AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps

HTML::Mason & Apache::Request

Mon, 30 Aug 2004 22:59:05 -0600

Had a problem involving getting HTML::Mason to work with Mod_perl. The issue was that despite having mod_perl installed, you need another library that really isn't talked about much. That library is libapreq. I'm a little surprised that the mod_perl guys haven't integrated this into the regular mod_perl distribution, but I guess it's just an extension at this point. But this library is a C/XS library that has Apache::Request and Apache::Cookie interfacing to the actual Apache C libraries. In turn, this makes the routines for accessing apache requests and cookies faster. HTML::Mason allows the user to either choose the normal CGI.pm module or Apache::Request.pm for handling these types of routines. With Apache::Request.pm, there is less memory usage and faster access. Hence, I chose this path. However, the basic libapreq install off of CPAN is a little buggy. Instead, you need to utilize the cvs repository to get the version with the corrected makefiles, etc.: cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login CVS password: anonymous cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co httpd-apreq as I am using mod_perl version 1, i'm going with this version. after grabbing it, just run perl Makefile.pl & make & make install. The good thing is that it should test properly so you probably want to run make test on top of that.

Success with mod_proxy

Mon, 21 Jan 2008 08:20:34 -0700

Today I managed to achieve a new milestone in my technical prowess: I successfully installed mod_proxy on two separate servers. The first time is always the most painful because you have to get used to the idiosyncrasies of a system and blunder your way through the solution. But once you manage to get the first one right, the second time usually isn't as meddlesome as the initial time.

The kind of architecture and problems I'm dealing with are purely technical and logistic at work. Having to deal with things like DNS, working inside a locked down, DMZ environment, even setting up on a production system with no backup. But I actually like these challenges because you get to hammer through an engineering issue, rather than dealing with unpredictable personalities.

The first time through, I read a good tutorial on setting up a proxy. However, there were quite a few difficulties that weren't well explained in the tutorial and I ended up simply using the sample version of mod_proxy given on their website. Because I'm using the Zend Framework at the office and dealing with mod_rewrite as well as having to mess with my /etc/hosts file, things got convoluted quite quickly. I really had to dig deep into how Zend created sessions while knocking out sessions and starting clean on my environment each time. A very tedious job, indeed. But after lunch, I managed to hook up my local box to our testing environment. While configuring that part of the proxy was painful, I managed to draw up a rough and dirty configuration for the production box.

The production box had a different set of challenges. Naturally, the first challenge is the age old support question of just even working off a production box. Luckily, we don't have many users at the moment for the system so restarting apache or re-compiling it to use the latest version weren't huge issues. The real issue was figuring out how to get the virtual host working while dealing with DMZ. We don't leave many ports open so testing the connection between the proxy server and the application server was going to be a challenge; meaning, you couldn't simply point your browser to the domain and check it out. You had to use various tools like telneting to port 80 and issuing a few GET commands.

Since we were just trying to get the configuration tested, we needed to wad through the httpd.conf file, which is like storming a swamp in Vietnam during the war. The thing is a big mess and we had some trouble just getting the domain setup properly. Eventually, we persevered hooking up the proxy server to a simple test page on the application server side.

But days like today are incredibly fulfilling. When you can get something like this working, it's a real triumph. After this, the next thing to do is configure the application and really optimize the mod_proxy and apache configurations. That should be interesting though.