Entries Tagged as 'CFML'

How to fix Lucee 'Handler "BonCode-Tomcat-CFM-Handler" has a bad module "ManagedPipelineHandler" in its module list' Error.

Handler "BonCode-Tomcat-CFM-Handler" has a bad module "ManagedPipelineHandler" in its module listFor whatever reason IIS likes to set the default version of .NET on some versions of IIS to 2.0. This is generally rediculous since 4.0 has been around for some time and even when 4.0 is installed and working, MS will default to 2.0.

If you install Lucee server on to your windows server and get this error, there are several possible causes:

1) You need to use a more recent version of .NET for your application pool. The fix is to adjust your .NET application pool version to 4.0 (or above) for that site, then restart the pool. Once you do that, your Lucee install should work perfectly.

IIS Application Pool Switch from 2.0 to 4.0

2) You need to ensure that you have .NET Extensibility turned on in your IIS Install. In windows 7, this is what the window looks like:

Enable .NET Extensibility

3) You have a .NET version cconflict. You'll need to remove all versions of .NET from your machine and re-install Lucee to let the installer handle installing .NET.

Hope this helps!

mod_cfml 1.1 is released! Fast, reliable, and new features!

For those of you familiar with the mod_cfml project, you know it consists of two separate sections: The web server adapter that provides information about the web site being served, and the Tomcat valve, which takes that information and automatically processes it within Tomcat - creating a new host, alias, etc as needed within Tomcat so that Tomcat will match the information coming from the web server. Both the web server adapter and the Tomcat valve have been greatly enhanced in version mod_cfml version 1.1.

New features in The Tomcat valve:

  • Speed: the process of creating a new host in Tomcat has been greatly reduced and has taken less than a second in all our tests - down from several seconds in previous versions of mod_cfml. Jar scanning is disabled by default.
     
  • Speed: the process of "waiting for context files" has been completely removed as it is no longer necessary.
     
  • Speed and memory footprint: only one Tomcat “Host container” is created per Apache/IIS virtualhost/context. All aliases / default site hosts / IP-based hosts, are now added as aliases. The process of creating a new alias is lightning fast.
     
  • Bugfix: Thread safety errors have been corrected, and hosts are now created reliably in every event.

 

Next, for the web server adapter, for Apache 2.4 the web server adapter has been completely re-written in C! This means that any system can run mod_cfml natively without the need for mod_perl. The mod_perl version of mod_cfml will still be available for Apache 2.2, but will no longer be maintained. With Apache 2.4 and a native C-module, mod_cfml can run natively on any system with extreme speed and only a few lines of config!

The new mod_cfml.so also includes the following enhancements:

  • Feature: SES URL support is now handled automatically using path_into. Previously, URLs like /some/page.cfm/id/123 would not work out of the box with Tomcat. With mod_cfml 1.1, now they do! This feature is supported in Lucee, OpenBD, and Railo.
     
  • Security: A shared secret key implementation has been added to prevent unauthorized context creation.
     
  • Feature: Virtual directories, or “Aliases” in Apache, are now passed by default from the mod_cfml.so file and handled automatically by Lucee for the current request. Check the documentation for more details on this.

 

Documenation for mod_cfml 1.1 is HERE.

Installation instructions for mod_cfml 1.1 is HERE.

 

Huge "Thank you!" to Paul Klinkenberg and Bilal Soylu for their amazing dedication to this project. You two are awesome!

 

So... what are you waiting for? Install! Upgrade! Stay secure and have fun with CFML!

Methods to address a slow Tomcat/Railo startup

Recently my technicians and I encountered an issue with a hosting customer who had an interesting situation between two VPS Accounts that he owns. The first VPS had a relatively quick startup time (under a minute), and the second VPS had an extremely slow startup time (above 5 minutes). Both VM's were relatively similar, and both served a great number of sites. The following are the two options that corrected the issue:


Slow Railo/Tomcat Server

Option 1

Set property in TOMCAT_HOME/conf/catalina.properties:

org.apache.catalina.startup.ContextConfig.jarsToSkip=*.jar

This will turn off jar scanning during the Tomcat startup.

Option 2

Configure the number of concurrent threads for Tomcat to use to create new contexts by adding the "startStopThreads" attribute to the <engine> tag in the Tomcat server.xml file. The number of threads should not be higher the number of CPU cores available to your server or the threads might overlap and you probably won't get the speed boost you were hoping for.

 

Once these options were implemented, both servers started up in just a few seconds.

Fixing "JRun too busy or out of memory" for PCI compliance

One of our servers here at Vivio is routinely scanned for PCI compliance purposes. Until just recently, we've been using FuseGuard (A Web Application Firewal, or "WAF"), to block intrusion attempts to our web application. With new PCI standards that force us to allow PCI scans through our WAF (or IDS or whatever), we had to allow these requests through, but that brought to light another, different, problem.

During the PCI scan, our Apache logs would get a lot of the following error messages:

[notice] jrApache[13857: 62679]  returning error page for JRun too busy or out of memory

Initially we thought that since the message was coming from the JRun connector, that the issue had something to do with the connector. However, after quite a bit more research, we found it had to do with JRun itself, and the specific number of post parameters it's configured to accept. Any more then the default "100" post parameters, and you'll get the error you see above.

To change the number of post parameters, you will need to update your neo-runtime.xml file. For our case, ours was found here:

/opt/coldfusion9/lib/neo-runtime.xml
NEO XML Example

IMPORTANT: Editing this file isn't particularly easy. Opening it in VIM gives you a big wall of text.

By increasing the following parameter from 100 to 300, we were able to succesfully complete our PCI scan:

<var name='postParametersLimit'><number>300.0</number></var>

Hopefully this helps anyone else having this issue.

Railo CGI remote_addr/remote_host says 127.0.0.1

When installed on to a Linux/Apache machine, the Railo installers will install mod_proxy_http as the default connector for Apache to Tomcat/Railo. The result is the same as you'd get with any other proxy, where the remote host is replaced with the address of the proxy (in this case 127.0.0.1) and the original requester's IP address is placed in the "X-Forward-For" header.

simplicityIf you need to find the original requestors IP address you can accomplish this in one of two easy ways.

Pull the IP from the X-Forward-For Header
This can be done easily using the following single line of code:

GetHttpRequestData().headers['X-Forwarded-For']

Use the Tomcat Remote IP Valve
This can be done simply by opening up your Tomcat server.xml file and adding a single line of code right under your "<Engine>" tag:

Change this:

<Engine name="Catalina" defaultHost="127.0.0.1">

To this:

<Engine name="Catalina" defaultHost="127.0.0.1">
<Valve className="org.apache.catalina.valves.RemoteIpValve" />

Restart Tomcat and you'll now see the IP address of the original requesting client populate your CGI scopes.