Security update...Explain this craziness...

[Guest]

Hi,

I just updated one of our CF 8.0.1 installations with the most recent security patch and it busted CFIDE instantly. When looking at the stack trace there are some suspect things going on. Please take a look at the bold print in the trace below...

1. why is it trying to run CFIDE from c:/work? My installation isnt even on the C: drive

2. Why the heck is "ColdFusioon" being referenced. Its obviously a type o . Not to mention the patch to CFIDE is once again completely wrong?

I figured id come to the forums and see people all over this subject.

Being that i didnt find any posts related to this whatsoever im wondering if this a personal problem and maybe im overlooking something. the update is so trivial im seeing how i could have overlooked anything.

Anyone out there care to chime in?

Stack Trace

java.lang.NoSuchMethodError: coldfusion.tagext.GenericTag.doFinally()V at cfl10n2ecfm1746172653.runPage(C:\work\ColdFusion\cf8_u1_final_hotfix\cfusion\wwwroot\CFIDE\administrator\cftags\l10n.cfm:153) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192) at coldfusion.filter.CFVariablesScopeFilter.invoke(CFVariablesScopeFilter.java:63) at coldfusion.tagext.lang.ModuleTag.doStartTag(ModuleTag.java:280) at cfApplication2ecfm1983805352._factor3(C:\p4\ColdFusioon\cf8_final_hotfix\cfusion\wwwroot\CFIDE\administrator\Application.cfm:101) at cfApplication2ecfm1983805352._factor7(C:\p4\ColdFusioon\cf8_final_hotfix\cfusion\wwwroot\CFIDE\administrator\Application.cfm:4) at cfApplication2ecfm1983805352.runPage(C:\p4\ColdFusioon\cf8_final_hotfix\cfusion\wwwroot\CFIDE\administrator\Application.cfm:1) at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192) at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:366) at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65) at coldfusion.filter.CfincludeFilter.include(CfincludeFilter

[Guest]

I forgot to mention.

Windows 2003/ IIS 6/ CF enterprise

Sorry

[Charlie Arehart]

Beyond that, is it also a MultiServer (multiple instances) deployment? If so, is this the Admin of one of the instances that you're trying to open? Or the cfusion instance?

As for the odd filename/path references, those reflect the original location of the files on the machine of the Adobe developer who precompiled the code (many CFML files in the CF Admin are precompiled or encoded so that you can't see the source. Errors that happen with them do show that original source location, which can be confusing.)

To your issue, whether you're using Server or Multiserver deployment, can you confirm what directory was updated by the security update? And do you know (for sure) what directory had been used as the CFIDE directory for the CF instance you're trying to run? I realize you can't get into the CF Admin to confirm, but you can look in the \lib\neo-runtime.xml for an entry with the name

, which has a child tag pointing to the location where that server expected to find its CFIDE directory.

Things can get confused based on choices of whether one does or doesn't use CF's built-in web server, how one configures an external web server (like IIS), any manual tweaks one may do after installation. All this could confuse the security update process (or the person who ran it).

Hope that helps get you started. Let us know what you find and perhaps I or others can help get you sorted.

/charlie

PS Can you clarify if you're trying this in a dev or test environment? Or is this production? And if so, had it worked in a previous dev/test attempt?

[Guest]

Mr Arehart,

This happened on both of our cf 8 development servers. One is multiserver while the other is CF8 Standard.

I should mention this is the first attemp at pushing this particular hotfix out.

The instance that im attempting to apply it to would indeed be 'cfusion' in both cases.

Thanks for clarifying the about the developers source code, that was helpful.

Here is the directory updated by the security update...

\\xxx\d$\Inetpub\wwwroot\CFIDE\administrator\cftags (It happens to be the same on both servers)

This is indeed the same directory that we have been using for CFIDE since day 1.

Heres what i lifted from the neo-runtime file...

<var name='/CFIDE'>

<string>D:\Inetpub\wwwroot\CFIDE</string>

</var>

It seems to coincide with what i specified above.

As far as the update goes , it's simply two cfm files which i have manually replaced in the follwong directory...

\\xxx\d$\Inetpub\wwwroot\CFIDE\administrator\cftags

Luckily i backed uo the files that were previously there. Simpley reverting back to the old files  clears up any issue after recycling services.

Thanks for the quick reply.

[Charlie Arehart · Accepted solution]

Call me Charlie, please.

I wonder if there may be still some potential confusion though.

First, to be clear, since you say you're running 8.0.1, are you sure that you downloaded the 8.01 zip (from http://kb2.adobe.com/cps/857/cpsid_85766.html)? There are zips for 9.0, 9.01, 8.0, and 8.01, so it seems important to be sure to use the right one.

Second, as important, are you positive that you're running 8.0.1? I've seen many people discover they are not running the release they think they are. The good news is that it's reported in the CF Admin, and since you say you can get things back to working, go ahead and run the CF Admin (that was failing and is now working) to make sure that the Setting Summary or System Information pages really do show it running 8.0.1. In this instance, please don't trust any assumptions you may have.

Third, about this admin that's now working, is it going through IIS? In other words, is there a port on the URL, such as 8500 or 8300? If so, then you're using the built-in web server and not IIS, and therefore you'd typically NOT be using the CFIDE that's in the inetpub\wwwroot but instead one within the wwwroot where CF is installed (such as c:\coldfusion8\wwwroot for CF8 Standard or Enterprise Server mode, or C:\JRun4\servers\cfusion\cfusion-ear\cfusion-war\CFIDE for the cfusion instance in CF8 Enterprise Multiserver). In that case, you may have applied the fix to the wrong place, which could explain a problem.

But then the fact that you say you revert back to the old files and suddenly it works does make it seem this is not the issue.

Still, as we keep exploring possibilities, you say that "This happened on both of our cf 8 development servers. One is multiserver while the other is CF8 Standard...The instance that im attempting to apply it to would indeed be 'cfusion' in both cases."

To be clear, there's no cfusion instance in the Standard (or Enterprise Server) deployment, only in Multiserver deployment. A server running CF 8 Standard (or Enterprise Server mode) would instead have a c:\coldfusion8 directory (on Windows, as you're running) with no cfusion directory within it (it has a \servers\coldfusion, technically). Since this fix goes into the CFIDE, it's not quite as big a deal.

But the bigger problem is that one could be updating the CFIDE in inetpub\wwwroot but having their CF Admin URL loading from (and looking for code in) the directory inside the CF instance instead. It's confusion that happens all the time, arising from CF's flexibility (to use or not use the built-in web server) and the fact that most people just don't spend their days diving into this level of detail.

I'll note as well that since you said you're using that inetpub\wwwroot location for your CFIDE, (there's nothing technically wrong with doing that, as long as you really are using IIS to open your CF Admin), this also means you could technically point a web site (any or all, or a virtual directory in IIS) to use that CFIDE directory, while then telling that web site to pass any CFM files it finds through any particular CF engine you have installed.

Again, I'm grasping at straws for you, but I could see how you might technically get an error if you tried to run this fix's code meant for one version against another (since they offer different versions). Looking at the CF Admin (assuming you run the CF Admin) to confirm the version (and the location of the CFIDE mapping indicated within it) should help.

Let us know what you find.

/charlie

Providing CF troubleshooting services at carehart.org/consulting

charlie@carehart.org

[Guest]

Charlie,

When going in to verify once more I realized that we are not running 8.0.1. Instead we are running 8.0.0.176276. Being that they look somewhat similar I probably would have continued to glance over this until someone pointed it out.I really need to get my eyes checked.

What threw me off was the unfamiliar path(s) that I found within the stack trace. The explanation you provided regarding that makes this thread time well spent being that I've seen a similar scenario on another server and wasted a considerable amount of time combing through files looking for wierd paths in the trace.

I really appreciate the time and detail that you've invested in this and should mention that my issue was quickly resolved once the correct patch was applied.

I still have much to learn.

Thanks

[Charlie Arehart]

Really great to hear, and thanks for the kind regards. Much appreciated.

/charlie