ColdFusion 11 update 1 was
out and blogged about here.
It included the fixes listed in the technote, out of
which two (Bug#
3777189 & Bug#
3758172) were related to IIS. We would like to share one of our Customer
experience and how we solved a connector issue after applying Update 1 in
ColdFusion 11.
The Challenge
Recently we were contacted by a customer from a larger organization, who wanted the IIS fixes. They weren’t aware about the release
of Update 1. Once we told them, they tried to apply the Update 1, but had
issues with it. We suggested them the alternatives that can
be used when there is a problem with direct application of the hotfix. The
update was installed successfully and was confirmed from ‘Settings Summary’
page in the CF Administrator. The next step was to reconfigure the connector. The
moment connector was re-configured, all the sites went down. There were
approximately 15-20 sites configured with ColdFusion and the entire production
went down. We checked the update logs and they were clean. The error reported
was “Error 403 Access Forbidden”
across all the sites.
The Solution
We tested the non CFM sites, and they
were functional. Only the ColdFusion based sites were giving the forbidden
errors. Thus we inferred that, the issue is either with ColdFusion or the connector
configuration. We enabled the internet port for ColdFusion and there we go, it
worked. This meant, ColdFusion was also working perfectly, but somewhere the
connector broke. Even after trying all the ColdFusion based troubleshooting
steps, basic windows troubleshooting, permissions check, ColdFusion logs etc.,
we were unable to fix the issue.
Then we decided to compare the
settings with one of the development servers they had. And bingo, we found the root
cause of the 403 error. “worker.cfusion.secret=yourSecret” was added by them in
their {cf.home}/config/wsconfig/[magic number]/workers.properties as a part of connector shared secret setting. This
is a part of ColdFusion
11 Lockdown Guide procedure. When the connector was re-configured, the
previous settings with configuration information were erased. But the
corresponding entry in the {cf.instance.home}/runtime/conf/server.xml was still
looking for the related entry in workers.properties and thus was throwing error.
The Result
Once the setting was updated, all the
sites were up and running in seconds. The customer was very happy, as their sites were back on production. If the connector needs to be
reconfigured, we have to first remove it and then re-configure it. Connector removal
means, the changes made by the user will be lost. When the user re-configures
the connector thereafter, we don’t have any means to identify what configuration
settings they previously had.
The Recommendation
Before
you re-configure the connector, we strongly recommend the following:
Ø Back up all connector configuration files. Connector
configuration files are available at {cf.home}/config/wsconfig/
Note: The same has also been
mentioned in the ColdFusion 11 Lockdown Guide as well.
Staff
9 posts
Charlie & Tom, this would be definitely worked upon and we completely agree that, it is important.
@Anit,
I sincerely hope that both Charlie and I are misunderstanding what you said in comment #3.
It seems the quality of this feature, if any, depends on votes on the bugbase for https://bugbase.adobe.com/index.cfm?event=bug&id=3783361. The impact of not having the feature, as this blog post states, is that all the CF sites can become unavailable.
Improving the web configuration tool to at least notify the user that user made changes will be overwritten is surely something that can be done without too much effort and time.
@Anit, I was so encouraged by the opening of your reply, but then wow, really? The priority of the bug report will be set “automatically” based on votes, not manually based on a human’s evaluation of its value? So that even an idea which is CLEARLY beneficial to ANYONE who modifies the connector settings might not be implemented simply because no one votes on it, and so its priority never rises?
Or am I misunderstanding? I hear you say first “we will definitely look into these” but then you say it will be based on “how many users would like these changes”.
These are not changes that should require popularity. Too few people may bother to read this blog entry, let alone randomly find the bugs reported. (And please don’t suggest that it’s up to me to promote the bug reports. It should not be based on the ability of anyone to generate interest.)
Look, the issue that led you to create this very blog entry is proof of the need to better solve the problem, whether anyone votes (or comments here).
Finally, you say “these enhancements will require some efforts and time” but the simplest one is quite trivial: add a warning to the connector tool that indicates that running it will lose any connector configuration modifications.
There’s more you could do, sure, like detecting if indeed changes have been made, or offering to preserve them. But let’s not let better stand in the way of “good enough”.
I’m just really dismayed that the response was not, “clearly we need to improve this, and we will begin steps in the next iteration of the connector tool”. Sure, there would be more you could do, but if you do nothing (for lack of votes), people will suffer for the very reasons you outline in this blog entry. That should not continue.
I agree with Charlie here. The wsconfig GUI tool needs to have an option to to preserve custom settings or to do a connector upgrade. Currently I run wsconfig via the command line with the -upgrade option to preserve tuning settings. Most people don’t even know you can run it via command line.
I also think that waiting to see how many users will want his change is a cop-out. I will argue that most don’t even know about this and will simply be bitten by this when they delete and recreate the connectors with the wsconfig GUI tool.
I’ve added my vote to the ER.
Regards,
Wil
@Ariel, Error 503 is from webserver, Apache in your case. The issue could be due to Apache or could be due to connector. Can you enable the built-in server for CF and test the functionality.
Steps to enable built-in server
In server.xml at ColdFusion11cfusionruntimeconf you can find the following connector block –
This is the connector for the built-in webserver. If it is not enabled through installer, uncomment this block to enable it later on. Restart server.
@Charlie, as always thanks again for thoughts improving the product stability. Yes, these two ERs are considered to be looked upon. These enhancements will require some efforts and time. We will definitely look into these. The “priority” will automatically change, based on the notes/votes on the bug, showing the numbers of users being impacted.
Let us see, how many users would like these changes to be implemented. We will decide the action plan, then.
@Anit, that’s a helpful story to share, with the moral being “rerunning the connector loses tweaks you may have made”. And thanks for reiterating it.
But I want to plead that rather than relying on folks to hopefully see this entry or learn of it the hard way, could you guys PLEASE change the connector tool so that IT warns of this, and perhaps even offers to save and re-use any changed connector tuning settings?
I had asked this in a comment in your previous blog entry about CF11 IIS connector tuning where you helpfully point out options to tweak the connector settings (https://coldfusion.adobe.com/post.cfm/coldfusion-11-iis-connector-tuning), specifically as part of my comment #24.
Now, I was sharing this suggestion among many other things that I’ve observed people having a problem with related to this connector tuning challenge. And I shared some things you guys might do in the tools to help the situation.
Since there’s a fair bit there and in my comment just prior to it, let me highlight this relevant point for you and readers here:
“Finally, and perhaps most important, everyone reading this blog entry and applying the changes Anit suggests should note that THOSE CHANGES WILL BE LOST if the web server configuration tool is run again. It always sets them back to the current defaults (which Anit is telling us to change.) This is why I think it’s important that the tool create better defaults, and/or prompt us to consider use cases and make better default choices.
But perhaps better still, related to this last point, perhaps the tools should detect if users have made non-standard changes to these files (workers.properties and server.xml) with respect to these settings, and it should prompt them to either preserve them or let them be overwritten.”
I wrote that on June 28 2014. Your reply was that I should create an enhancement request, and I did that:
https://bugbase.adobe.com/index.cfm?event=bug&id=3783361
Sadly, while others have commented there on the high value of this, there’s no reply from Adobe. It’s listed as “tofix”, but the priority is “0 unknown”. I gather that’s something you folks set, so I hope you may please reconsider that value.
(And while the frequency is listed as “unknown”, I really doubt I would have selected that, and I see on entering a new bug that we have to pick a value. I would have said “most users will encounter”, or at least “some users will encounter”. The fact is that ALL users who rebuild the connectors will encounter the problem if they had changed the default settings.)
And given that 2 CF team blog entries have shown how and why do do that (for CF 10 and 11), I really think it’s VITAL that this issue be addressed in the connector tool (a warning, at least, and an option to preserve settings if possible).
Again, I want to clarify that I appreciate your goal in this entry is to warn people of the issue, and I applaud that. But sadly too many people who will hit the problem will never see this. We need the tool to do a better job–and hopefully you can backport such a change to CF10 as well, since the problem happens there also.
Others, if you’re interested in this, either chime in here or in comments of the bug report (or that last blog entry from June). BTW, another related bug report (made in response to Anit’s request in those June blog comments) is at:
https://bugbase.adobe.com/index.cfm?event=bug&id=3783364
Since votes help drive resolution, we need those impacted to make their opinion known.
I installed CF from ColdFusion_11_WWEJ_win64.exe over Apache running under XAMPP. The administration panel and a simple helloworld.cfm both give me a 503 service unavailable error. I read the article, but I guess I don’t understand what the fix actually is. Can you describe a little more simply what steps I need to take? Thanks
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
