1. Resolve the immediate problem; or
2. Resolve the underlying issue (wherein the problem reported by the customer is merely a symptom of a different problem)

A key question for transitioning from point 1 to 2 is “why?” E.g.

• Why did this problem occur?
• What data or environment change caused this?
• Why does the ( data or environment ) cause this issue?

Asking the questions and tracing symptoms to the source is invaluable. Once the source is identified, one can determine reproducibility and define a test, all of which can lead to a fix. Once the issue is fixed, we can Assure the problem will not reoccur in the future, for this customer or others.

A key thought to remember when writing a bug report is:

“The information provided must facilitate reproduction of the bug”

In other words, could a complete stranger read the report and be able to reproduce the bug in the system?

Many times, when reading bug reports submitted by customers, there are enough details missing that cause the report to marked as non-reproducible. Or it entails much back and forth with the reporter to obtain the missing details. Either method results in frustration for both the reporter and the tester.

The last few days I took the time to import all my old blog posts, dating from when I first started blogging in 2003. It is quite interesting, humorous rather, reading those older posts. It’s also surprising how many typos exist (although in truth some typos were likely caused by the conversion process).No comments were brought over and some of the post <-> category mappings are goofy.

With the conversion done, I can at last do something I’ve wanted and needed for quite a while: remove unused databases and application directories from my web site. I’ve a full backup in place (just in case).

Anyway, I hope this spurs a return to blogging.

The VMware server experience has soured me on the OS-in-a-loop-back-file method. Yes it can support LVM partitions, but only with some trickery, which I don’t want to do. Xen, however, needs no trickery.

With the help of LVM and images from jailme.org, I’ve been working out a nice routine which I will eventually automate. The process itself is rather simple:

• Create a new LVM partition for the OS ( e.g. lvcreate –size 20G -l OsName GroupName )
• Create a new LVM partition for swap ( e.g. lvcreate –size 1G -l OsSwap GroupName )
• Format the OS partition ( e.g. mkfs.ext3 -L OsPart /dev/GroupName/OsName )
• Format the Swap partition ( e.g. mkswap /dev/GroupName/OsSwap )
• Mount the Jailme.org image ( e.g. mount -o loop image.img /mnt )
• Mount the OS Partition ( e.g. mount /dev/GroupName/OsName /xen )
• Use rsync to copy the image contents to the OS Partition ( e.g. rsync -aP /mnt/* /xen )
• Make changes to some configuration files on the OS Partition
• Unmount the image and OS Partition
• Customize the Xen configuration file
• Start the image

My requirements only necessitate having a few setups like the above. My goal in automating the process is not just to remove the tedium, but to improve the speed. With a rough estimate, I think the above could be automated to occur in less than 10 minutes (accounting for load on the system).

Once that is automated, my next goal is to tackle taking ’snapshots’ of the Xen guest. I’m still undecided as to the exact method, although I am currently leaning toward creating a tarball of the partition.

Since there is only one developer, myself, I need to restructure my goals and the road map to reflect that. Hence, many features I’ve planned for Loquacity 1.0 will not be. What I am considering is:

• cleaning the current code
• fix known bugs
• removing code/features that don’t work
• make the installer work near flawless
• release

Along with the above, I need to remove people from the project that never did anything. This is more a management type thing, only on Berlios.

To start, I’ve fixed a nasty bug in the Comment admin interface. The SQL statement to retrieve the comments was very broken; a junior level mistake that caused a match of LIKE “%”. Of course, that won’t work.

Deleting comments is much faster now, as some redundant queries were removed.

In the interests of improving the speed of Loquacity, I’ve begin keeping a list of Database tables that need indexes added. These changes will be implemented in the Upgrader and base Database schema.

Running as a CGI presents other problems. For example, the majority of 3rdparty PHP Applications assume one is running PHP as an Apache module. To use a script via CGI, one has to use something called a she-bang. The first line in the script is a special line that points to the binary that actually executes the script. Thus, if the PHP CGI binary is /usr/bin/php, then the first line in the script must be:

#!/usr/bin/php

Another (mainly superficial) problem is often CGI scripts must be placed in a cgi-bin directory. This means the URI to your blog won’t be www.example.com or blog.example.com but www.example.com/cgi-bin/blog.php or blog.example.com/cgi-bin/ Not exactly pretty. There are ways around that particular problem. There are still bigger problems, even running PHP as a CGI binary: how to lock down the user? You are essentially giving the user a lot of system access (the same is true when running Perl, bash, Ruby and other Scripting languages), how can we prevent a user from stomping all over the system? Even as CGI, the scripts are still executed as the Apache user.

Two common ways are PHPSuExec(*) and SuPHP. Both provide means of changing the UID/GID of the executing process to that of the end user, and many, many other safeguards. However, they both fail on one common problem with PHP: by default, PHP allows users to place their own php.ini file in their Document Root, which will be used to the exclusion of the system php.ini Thus if you have disabled various functions (e.g. dl, system, passthru, etc), a user can easily override it by dropping a blank php.ini file in his Document Root (typically ~/public_html)

Disabling user php.ini files

There are several ways to disable user php.ini files.

• Configure php with –with-config-file-path=/usr/local/lib –with-config-file-scan-dir=/usr/local/lib
• ( Won’t work with PHP 4.4.x) Install the Zend Optimizer
• ( Won’t work with PHP 4.4.x) Create a wrapper script

As noted, only the first option works for all modern versions of PHP. The directory path provided should match where your system php.ini file is located. Once compiled with these options, PHP is essentially “jailed” into using a php.ini file where configure stipulated. One odd thing to note with this, phpinfo() will lie. Try the following in a user account:

• In your user Document Root directory, create an empty file named php.ini\
• In a separate file, place <?php phpinfo(); ?>
• Access the phpinfo file via your web browser
• Note that phpinfo() reports it is using the php.ini file located in your Document Root

An easy way to verify which is being used is to disable a function in the system php.ini file (such as ini_get). In the user php.ini, override that (disable_functions=). Create a short script that tries to use the disabled function. You’ll receive an error stating the function is disabled for security purposes.

What about the other methods? In PHP 5.2.x, installing the Zend Optimizer forces PHP to use the one stipulated in the Zend configuration, thus overriding the user php.ini file. And the wrapper script?

Locate your PHP CGI binary (we’ll use /usr/bin/php as an example) and rename it to php-cgi (thus /usr/bin/php-cgi). In the same directory, create a file named php. Give it the same permissions as php-cgi and insert the following contents:

#!/bin/sh/usr/bin/php-cgi -c /usr/local/lib/php.ini

The -c parameter instructs PHP to use the configuration file stipulated and ignore all others. Astute readers/users will notice this doesn’t filter out the possiblility of a user passing -c/path/to/user/php.ini If you are concerned with that, a script similar to the following will work (as contents of /usr/bin/php):

#!/usr/bin/perl --use strict;use warnings;die '-c not allowed' if grep { $_ } map { $_ eq '-c' } @ARGV;exec( qw(/usr/bin/php-cgi -c /usr/local/lib/php.ini), @ARGV );

Now, if a user attemps to pass -c/path/to/user/php.ini to the script, it will die. If done via a web-accessible script, Apache will return a 500 error and the die message will be in the error_log The use of Perl is just an example, you could do something in BASH, Python, C or whatever. Unfortunately, PHP 4.4.x ignores -c when compiled as a CGI binary, hence this trick only works on PHP 5.

Back in 1998 I took my first job in “the industry”: an EDI Clerk/IT Assistant. Being completly self-taught, from the corner or nowhere, I was extremely happy to have the job. It offered potential to learn about the IT field and would give me real-world experience, not only in solving problems, but dealing with users in a manufacturing environment.

Soon after being hired I was introduced to “Sears day.” This referred to every Wednesday when the Company shipped the orders to Sears, and only Sears. At that time, and still today, Sears has some of the worst Shipping requirements of the large retailers. It was nothing for them to generate 300+ 2 line orders, with a total value of ~USD$50 per order. To process the orders, from receiving them to closing the door on the truck, was very taxing. True, part of the processing was like ever other order, but there were aspects of the Sears orders that were unique.

For example, the Bill of Lading required a manifest, which was merely a list the cross-indexed each order with the Distribution Center (DC) that would receive the order. The stack of orders needed verified with the Manifest to be certain each was routed properly. This was done by comparing the order number and DC number as printed on the order, with the same information printed on the Manifest. The comparison was needed because the manifest was keyed to the Bill of Lading number. The Bill of Lading number was not known at time of order, but rather generated (read: invented by the Shipping Supervisor using a consistent pattern) when scheduling the pickup with the Carrier.

That was not the only comparison, two additional reports were generated, each needing data matched with the order, all to ensure correctness. To make matters worse, the entire cross-referencing was performed manually. It would take four people, myself, the shipping clerk, the IT Manager and the Assistant Plant Manager, the full ten hour work day, at minimum, to perform the entire process. Something needed done, the entire process was error prone, highly repetitive and consumed too many resources.

Taking stock of the situation, I considered the tools available. My workstation used DOS 6 and Windows 3.11. Our ERP (Enterprise Resource Planning) system was accessed via a Terminal application. Joy of joys, the Terminal application, wIntegrate could be scripted. The script file was a simple text file containing the raw text commands one would actually perform when using the ERP System. All I needed to do was find a way to take the order numbers and generate the necessary script.

The problem was there were no development tools available, save two: DOS Batch and MS Word. Being young, green really, I chose the lesser of two evils: MS Word. On reason I chose it was for the eroneous view ‘If someone else needs to use this program, they will be more comfortable using MS Word than typing a command on the commandline.’ A noble thought in a sense, but ultimately wrong