Turns out this is a simple thing to fix, I had to add a line to MySQL’s config file: my.cnf. Mine was located at [MySQL installed root]\bin\my.cnf. The setting that needs to change is lower_case_table_names, I set the value to 2, like this:

lower_case_table_names=2

If you are interested, here are the different possible values:

On Windows the default is 1.

More information at http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

If you are not familiar with this method of reading Excel files, here is a short summary.
1) Create a system ODBC DSN using the MS Excel driver in your Windows ODBC control panel. Point it to an empty .xls file somewhere on your drive.
2) Create a datasource in ColdFusion (driver: “ODBC Socket”) and select your Windows ODBC DSN from the drop down.
3) Copy the XLS file you want to read on top of the empty file you setup in your ODBC DSN.
4) Use it like this in your CFML:

<cfquery name="myQuery" datasource="XLSPassThroughDSN">
SELECT *
FROM [Sheet1$]
</cfquery>

This usually works well but for some reason we were having problems. Digging through the Excel file turned up nothing out of the ordinary, except some rows (and not the ones causing problems) looked like they were double byte encoded (unicode).

Turns out this XLS driver determines the data type of each column in the spread sheet by looking through the first couple of rows and guessing a data type based on that data. In our case column B only contained values with less than 100 characters in the first few dozen rows. So the driver assumed it was a varchar type of some length. But much further down in the spread sheet, in a different row, that same column contained a value that was several hundred characters, thus overflowing the data type.

Normally this only results in truncated data. If that would have been the issue I probably would have found the fix much sooner. But instead we were ending up with garbled data, which was truncated as well but it was impossible to tell.

The fix is to adjust your registry to tell the driver to scan through more, preferably all, of the rows before guessing at a data type. In your odbc control panel you’ll notice a setting for this:

But, that doesn’t work! You need to change the registry value manually. I set mine to 1000, since that will cover the length of any of the spreadsheets we upload.

The registry keys are located at:

For Excel 97:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\Engines\Excel
For Excel 2000 and later versions:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel

Here is the MS knowledge base article for more detail: http://support.microsoft.com/kb/189897/

Now the driver scans through all the rows before determining a data type, and probably uses something like a “text” type for column B. I think our data may have been getting garbled, instead of just truncated, because of the double byte data.

It didn’t work when going directly through Tomcat, i.e. browsing on port 8080 would not pull it up, I think Tomcat is smart enough to know not to serve files from the WEB-INF directory. But browsing through Apache on port 80 bypasses Tomcat for anything thats not a .cfm or .cfc file, so it would happily return the xml file. Datasource passwords are stored encrypted but the administrator password is clear text. Its easy to lock this down, just add this to your Apache config file:

<location "/WEB-INF/">
deny from all
</location>

Unable to create collection MyCollection.
An error occurred while creating the collection: com.verity.api.administration.ConfigurationException: Failed to retrieve style path. (-6044)

Turns out the Verity installation did not complete correctly. I could tell by looking in the {cf-root}/verity/verity-install.log file. This problem is fixed by simply uninstalling and reinstalling verity.

In the {cf-root}/verity directory you’ll find a script named uninstall-verity.sh (on linux) or uninstall-verity.bat (on windows). Just run that and then run the install-verity.* file and you should be back in business.

[root@server tmp]# ./coldfusion-702-linux.bin
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
awk: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/bin/ls: error while loading shared libraries: librt.so.1: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
dirname: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
basename: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
Launching installer
grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
/tmp/install.dir.3348/Linux/resource/jre/bin/java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

There is a hard coded value in the installer thats causing things to get messed up. Fixing this is fairly easy, you can modify the installer like this:

cp coldfusion-702-linux.bin coldfusion-702-linux.bin.backup
cat coldfusion-702-linux.bin.backup | sed "s/export LD_ASSUME/#xport LD_ASSUME/" > coldfusion-702-linux.bin

That comments out the offending line in all places in the installation script.

More discussion on this here:
http://www.billmitchell.org/coldfusion/centos5/mx7_apache.php
http://www.talkingtree.com/blog/index.cfm/2006/12/6/Running-ColdFusion-MX-7-on-Fedora-Core-6-Linux

You will probably run into more issues installing CF7 on this version of CentOS but it can be done. I also had to upgrade the connector to work with Apache 2.2 (when CF7 came out the connector was designed to run on Apache 2.0). The Adobe KB article that discusses this is here: http://kb.adobe.com/selfservice/viewContent.do?externalId=8001e97&sliceId=1. Their example didn’t quite work for me because its defaulting to the version of Java thats on your OS, which won’t work unless its a Sun 1.4.2x version. So I just used the JRE that is bundled with ColdFusion to install the new connector:

/opt/coldfusionmx7/runtime/jre/bin/java -Dtrace.ci=1 -jar ../../runtime/lib/wsconfig.jar \
        -server coldfusion \
    -ws apache \
        -dir /etc/httpd/conf \
        -bin /usr/sbin/httpd \
        -script /etc/rc.d/init.d/httpd \
        -coldfusion -v

I thought that was the last hurdle but when we tried to log in to the ColdFusion administrator we got an error about “The Graphing service is not available”. The message in the log file was “Unable to initialize Graphing service: java.lang.UnsatisfiedLinkError: /opt/coldfusionmx7/runtime/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory”. This was fixed by installing the libXp library:

yum install libXp

MySQL: access denied for user: username (Using password: YES)

I got this when connecting via the command line client and via ColdFusion. Finally after some googling I came across this blog post suggesting to change the privilege details to allow connecting from ‘localhost’ instead of ‘%’. The % indicates a wildcard and should allow connections from any host. But for some reason this was not working for me. Changing it to ‘localhost’ fixed the problem and allowed me to connect. I think it may have had something to do with the fact that I checked a box when installing that would only allow connections from the localhost.

I used this SQL to fix the host setting after connecting to the ‘mysql’ database:

update user set Host=’localhost’ where User=’myUserName’

Here is a simple way to do it on Linux:

rm -rf `find . -name .svn`

That might not work if you have hundreds or thousands of folders, as it might be too many arguments for the rm command. I still like it because its simple. But a more robust way would be:

find . -name .svn -prune -exec rm -rf {} \;

This calls rm on each file separately.

I haven’t tried the following, but on Windows you may be able to:

Create a cleanSVN.cmd file in the root containing these lines:

for /f “tokens=* delims=” %%i in (’dir /s /b /a:d *svn’) do (
rd /s /q “%%i”
)

You could also try browsing to the files in Windows Exporer and then:
Right click on the folder and click Search..
Enter .svn as the filename to search for.
Click “More advanced options” and select:
- Search hidden files and folders
- Search subfolders
Press search button and delete the folders you find appropriate.

The Windows tips came from Axel’s blog at http://www.axelscript.com/2008/03/11/delete-all-svn-files-in-windows/

I tried to modify the example script, but I’m pretty bad with shell scripting. I looked for a perl one, which I knew I could easily modify, but couldn’t find any. So I whipped this one up:

#!/usr/bin/perl

# config section
$minchars = 4;
$svnlook = '/usr/bin/svnlook';

#--------------------------------------------
$repos = $ARGV[0];
$txn = $ARGV[1];
$comment = `$svnlook log -t "$txn" "$repos"`;
chomp($comment);

if ( length($comment) == 0 ) {
  print STDERR "A comment is required!";
  exit(1);
  }
elsif ( length($comment) < $minchars ) {
  print STDERR "Comment must be at least $minchars characters.";
  exit(1);
  }

exit(0);

Those error messages get sent back to the client and display just fine in TortoiseSVN or whatever you use.

My subversion server is running on Linux, but the script should run on Windows with little modification, if you have perl installed.

I’ve gotten through a couple, and will be posting reviews of a few of them. This week I finished Apache Security, from O’Reilly. I found this book while browsing the programming section of Borders (the programming section of my local Borders is amazing!), and I’ve found it to be a real gem.

The book covers so much more than just Apache security. It covers installation and configuration, and explains a little of how Apache works along the way. There are also chapters or sections on:

- Understanding and securing PHP
- An explanation of SSL
- DOS attacks
- Traffic shaping in Apache
- Logging is covered extensively
- There’s a chapter on web security in general, where all the common attacks are explained
- Using Apache as a proxy or a reverse proxy

I especially enjoyed the Web Security Assessment chapter where the author explained how to systematically analyze and probe web applications/servers, with many real world examples.

There is a large section discussing mod_security, which is an amazing Apache module. Mod_security is an intrusion detection and prevention engine for web applications (a web application firewall). The book is written by the author of mod_security (Ivan Ristic), so he really knows what he’s talking about in this area. Also covered is mod_dosevasive, which, obviously helps prevent against denial of service attacks.

I would not hesitate to recommend this book to any Apache administrator, user, or web programmer.

Configuring the web server connector (Launched on the first run of the ColdFusion MX 7 start script)
Running apache connector wizard...
=======================================
There was an error while running the connector wizard
Connector installation was not successful

The connector may or may not actually be installed. In some cases it is, but you still get this error. If it is installed, you should know it. Restart apache to make the httpd.conf changes take effect, then try browsing to a .cfm page. If it displays correctly, the connector was installed.

In this case, all you need to do to get rid of the error message is rename the /opt/coldfusionmx7/bin/cfmx-connectors.sh script. Thats normally what happens when the connector is successfully installed – ColdFusion renames that script to “cfmx-connectors-run.sh”.

If your connector did not successfully install, there are a few additional steps to get it properly installed. Change into the /opt/coldfusionmx7/bin/connectors directory. Open the apache_connector.sh file, and fix the paths to be correct to your system.

By default the file contains these lines (among others):
../../runtime/bin/wsconfig \
-server coldfusion \
-ws apache \
-dir /usr/local/apache2/conf \
-bin /usr/local/apache2/bin/httpd \
-script /usr/local/apache2/bin/apachectl \
-coldfusion

On RedHat/CentOS, they should usually look like this:

../../runtime/bin/wsconfig \
-server coldfusion \
-ws apache \
-dir /etc/httpd/conf \
-bin /usr/sbin/httpd \
-script /etc/rc.d/init.d/httpd \
-coldfusion

Even though those are the values I entered during the install, they don’t always make it to this connector script for some reason.

Save the script and run it. Restart apache, and browse to a .cfm file, or to the Administrator to verify that it is installed properly.