Hello,
We are running two Red Hat 7 servers, one to run CF 2016 (Server A) and one to run Apache 2.4.6 (Server B). I’ve read instructions on how to get CF to run in distributed mode, but I’m not having any luck getting it to work. Is there a walkthrough on how to go about it?
I’ve installed CF on the Apache server (Server B) to get the connectors set correctly, and changed the workers.properties file to point to Server A, ensuring the cfusion.port is the same on both servers. On Server B I’ve installed our homegrown CF application, complete with Application.cfm and index.cfm files but when browsing to Server B it returns an error: ERR_EMPTY_RESPONSE
What am I missing? (I know I’m missing a lot!)
Thanks for any help you can provide
PG
I understand you have asked for the process using Linux/Apache, so you will need to translate the steps below from Windows/IIS speak into Linux/Apache speak, but it should at least give you a better idea of what is necessary. I would also recommend contacting the ColdFusion Support Team for help with this on CFsup@adobe.com
I hope this post helps though.
Installing ColdFusion 2016 in Distributed Mode under Windows/IIS:
- Install IIS (and URL Rewrite) on the Distributed Web Server
- Install Visual C++ 2012 x64 Redistributable on the Distributed Web Server
- Install IIS (and URL Rewrite) on the ColdFusion Server
- Install ColdFusion 2016 on the ColdFusion Server
- Run the Web Server Configuration Tool on the ColdFusion Server: but add the connector using the IP address of the ColdFusion Server for the “AppServer Host:” instead of using “localhost” – for example: 192.168.0.123
The resulting workers.properties configuration file that stores the AppServer Host and Port numbers will be copied from the ColdFusion Server to the Distributed Web Server as part of the next step. - Copy the following directories from the ColdFusion Server to the EXACT same location on the Distributed Web Server
- C:\ColdFusion2016\config
- C:\ColdFusion2016\cfusion\wwwroot\cf_scripts
- Open IIS on the ColdFusion Server and configure website as you normally would.
These are the files that CF will use to process the requests routed from the Distributed Web Server.
At this point the website should now be working correctly when accessed directly from the ColdFusion Server. Continue on to configure the Distributed Web Server… - Open IIS on the Distributed Web Server and repeat the step above using the EXACT same file paths.
These are the files that IIS will use to actually serve the content (request) and then forward to the CF server for processing then send back the resulting response.
Don’t forget to create the special Virtual Directories for: jakarta and cfscripts (as per the website on the ColdFusion Server). If you are using ColdFusion WebServices, you will also need to create the special Virtual Directory for cfws. Otherwise requests to these locations will not be passed through to the CF Server and will result in a 404.
NOTE: It is critical that the websites on the ColdFusion Server and Distributed Web Server are created exactly the same using the same file paths, etc. - On the Distributed Web Server, configure the following:
(NOTE: the …\wsconfig\1\… assumes that only one Web Server Connector exists on the ColdFusion Server, otherwise the number can change to 2/3/etc)- Handler Mappings – “Edit Feature Permissions” – Allow Execute
- Handler mappings (Add Script Map…) for the required extensions:
- cfcHandler – *.cfc – C:\ColdFusion2016\config\wsconfig\1\isapi_redirect.dll
- cfmHandler – *.cfm – as above
- cfmlHandler – *.cfml – as above
- cfrHandler – *.cfr – as above
- cfswfHandler – *.cfswf – as above
- hbmxmlHandler – *.hbmxml – as above
- ISAPI-dll – *.dll – IsapiModule (this File Module Mapping should already exist)
- StaticFile – *.* – StaticFileModule,DefaultDocumentModule,DirectoryListingModule (this File or Folder Module should also already exist)
- ISAPI Filters
- tomcat – C:\ColdFusion2016\config\wsconfig\1\isapi_redirect.dll
- ISAPI and CGI Restrictions
- tomcat_All – C:\ColdFusion2016\config\wsconfig\1\isapi_redirect.dll (Allow extension path to execute)
- Ensure the Application Pool on the Distributed Web Server has the same settings as the one on the ColdFusion Server
- On the Distributed Web Server, configure the relevant Windows Security Permissions (ACLs) for the Application Pool identity (e.g. IIS_IUSRS or IIS AppPool\{AppPoolName}) for the following locations:
- C:\ColdFusion2016\config\wsconfig – Read, Execute (RX)
- C:\ColdFusion2016\config\wsconfig\1\isapi_redirect.log – Read, Write (RW)
- C:\ColdFusion2016\config\wsproxy – Read, Execute (RX)
- C:\ColdFusion2016\cfusion\wwwroot\cf_scripts – Read, Execute (RX)
- C:\Path\YourWebsite – Read, Execute (RX)
- On the ColdFusion Server, add an Inbound Traffic Rule in Windows Firewall for the ColdFusion AJP Connector Port (usually 8016, but can be found in C:\ColdFusion2016\cfusion\runtime\conf\server.xml under AJP/1.3 protocol and C:\ColdFusion2016\config\wsconfig\1\workers.properties under worker.cfusion.port)
- Restart the services for “Windows Process Activation Service” and “World Wide Web Publishing Service”
- Confirm everything is now working.
The website should be working correctly both when accessed directly from the ColdFusion Server and also from the Distributed Web Server.
There are lots of potential pot holes along the way, and although the sequence of configuration steps can technically be altered and some steps event left out, we have found the above method works every time.
Be aware that the ColdFusion Lockdown process can cause you issues here, particularly with the requiredSecret attribute (in server.xml and workers.properties files) that must be the same on both the ColdFusion Server and Distributed Web Server otherwise you get a 403 Forbidden Access is denied error.
Firewalls can also cause issues here with the routed traffic – you can temporarily disable them during configuration and/or check the isapi_redirect.log file on the Distributed Web Server for additional error details in C:\ColdFusion2016\config\wsconfig\1\isapi_redirect.log.
Another diagnosis tip is to check static resources are resolving on the Distributed Web Server, because if they are not then the dynamic ones likely also wont work.
Good luck.
I’ll add a point of follow-up: back in 2015 Adobe did a blog post on the subject of setting up the distributed mode, and I will note that following their approach would eliminate several of the steps Benjamin laid out (in that you’d run the wsconfig tool on the web server machine, and IT would do all the creation of web server configuration for you).
But there are some aspects Benjamin has shared which are NOT covered in that other blog post (or in its comments, including some from me expanding on the blog post), so one would do well to consider both of them before undertaking the setup of this distributed mode.
You must be logged in to post a comment.