A ColdFusion Trick for Lost Datasource Password

Here's a quick trick if you don't have a datasource password when creating a new datasource but you do have another ColdFusion server with the same datasource.

Imagine you have two production servers running ColdFusion, each one with different datasources running different applications. What if you have a datasource on one server and you need to create that datasource on the second one but can't find (or don't have) the database password?

All recent ColdFusion versions use the same encryption algorithm for encrypting and decrypting passwords for datasources registered in the CF Administrator. This is why you can copy the ColdFusionX/lib/neo-datasources.xml from one ColdFusion 8 server to another ColdFuson 8 server, and the second server will have all the same datasources as the first. This is a quick way to mirror datasources across different ColdFusion servers.

But now, back to the problem where you have different datasources on each CF server, and you cannot copy over the whole datasource config file. If you don't have the database password, you can create a new datasource on the second server but without supplying a password. The datasource will then fail to verify. However, if you examine the datasource config file from the first server you can find the encrypted version of the password. A snippet from the ColdFusion8/lib/neo-datasource.xml file is shown below. Notice the encrypted version of the password in this xml sections:

view plain print about
1<var name="timeout">
4<var name="password">
7<var name="update">
8<boolean value="true"/>
10<var name="drop">
11<boolean value="true"/>
13<var name="pooling">
14<boolean value="true"/>
16<var name="url">

In this case the particular datasource has an encrypted version of the password shown as RgmrmRQhiQM=. You could find the datasource of interest in the config file, then find the encrypted version of the password, and copy it to the other neo-datasource.xml config file on the other server. Find the XML node for the failed datasource. It should have no value for the contents of the password field:

view plain print about
1<var name="password">

Then paste the encrypted version of the password in between:

view plain print about
1<var name="password">

For this to work, the ColdFusion server for where you are pasting the password should be stopped to avoid having ColdFusion overwrite your changes with a copy it already has in memory. Then start ColdFusion after pasting and the datasource will verify.

This can also work between ColdFusion versions. For example, ColdFusion MX 7 used neo-query.xml, and ColdFusion 8 restructured the file into neo-drivers.xml and neo-datasource.xml, but the encryption remained the same. You can copy the encrypted form of the password from a CF7 server and paste it into a CF8 or CF9 datasource config file.

This is a bit of a hack, but it does work.

Starting ColdFusion9 Solr: Using cfsolr in same directory

The cfsolr script for Mac, Linux, and Unix is written such that you must be in the ColdFusion9/solr/ directory when running the script. The script refers to the start.jar file without providing the full path.

The problem is that if you are not in the solr/ directory under the ColdFusion root directory, the cfsolr script echos that Solr has been started or stopped, even though it has not.

Since the standard error is redirected to the standard out with "2>&1" the problem is swallowed and the person performing the operation is led to believe that the operation has been carried out as expected.

Here's a snippet from the ColdFusion9/solr/cfsolr script showing that start.jar is referenced without a full path:

view plain print about
1SOLRSTART='nohup java $JVMARGS -jar start.jar > $SOLR/logs/start.log 2>&1 &'
2SOLRSTOP='nohup java $JVMARGS -jar start.jar --stop > $SOLR/logs/start.log 2>&1'

Looking at the logs, I see that the problem was quietly recorded in a solr log file:

view plain print about
1QAs-iMac:logs QA$ pwd
3QAs-iMac:logs QA$ cat start.log
4Unable to access jarfile start.jar

The script already has a variable defining the Solr directory path:

view plain print about

To fix the bug, prefix the reference to start.jar with ${SOLR}/start.jar like this:

view plain print about
1SOLRSTART='nohup java $JVMARGS -jar ${SOLR}/start.jar > $SOLR/logs/start.log 2>&1 &'
2SOLRSTOP='nohup java $JVMARGS -jar ${SOLR}/start.jar --stop > $SOLR/logs/start.log 2>&1'

With that fix, the cfsolr script can be called from any directory outside the solr directory.

Here is an examle of how the script falsely echos that the solr server has stopped or started when it has not (determined by grepping for the process):

view plain print about
1QAs-iMac:opt QA$ pwd
3QAs-iMac:opt QA$ ./ColdFusion9/bin/coldfusion stop
4Stopping ColdFusion 9, please wait
5Stopping coldfusion server.stopped
6ColdFusion 9 has been stopped
7QAs-iMac:opt QA$ ps -ef | grep solr
8 501 73310 1 0 0:00.25 ?? 0:02.64 /usr/bin/java -XX:+AggressiveOpts -XX:+ScavengeBeforeFullGC -XX:-UseParallelGC -Xmx256m -Dsolr.solr.home=multicore -DSTOP.PORT=8079 -DSTOP.KEY=cfsolrstop -jar start.jar

view plain print about
1QAs-iMac:opt QA$ ./ColdFusion9/solr/cfsolr start
2Starting ColdFusion Solr Server...
3ColdFusion Solr Server is starting up and will be available shortly.
4QAs-iMac:opt QA$ ps -ef | grep solr
5 501 78371 62961 0 0:00.00 ttys000 0:00.00 grep solr
6QAs-iMac:opt QA$ ps -ef | grep solr
7 501 78373 62961 0 0:00.00 ttys000 0:00.00 grep solr
8QAs-iMac:opt QA$ ps -ef | grep solr