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.
@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.
You must be logged in to post a comment.