hotfix application problems

[sduncanute]

I'm running Cold Fusion 9.01 and tried patching the system with the latest patch

http://kb2.adobe.com/cps/890/cpsid_89094.html

I ran the jar update without any problems and then proceeded to update the various other files as directed.  I restarted CF.  I couldn't get into the admin screens anymore (server 500 error) and although most pages on the website worked, anything with a form that had required fields that should have throw a user message, generated a server 500 error.

I restored the Cold Fusion directory as well as the IE directories for CF and restarted the server.  It is now running again, but if I go in to CF admin it shows the update level as hf901-00001.jar

So now the question is... is that .jar file actually still applied someplace and I missed something in my efforts to bring the system back to pre-update state?

Second question: How important is this patch in a non-shared environment?

Third question: is there any support to getting these patches working?

[Charlie Arehart]

You've raised 3 issues. Let me see if I can help:

1) As for why you still saw the hotfix applied, I guess it depends on what you mean when you say you "restored" the CF directory.

To be clear, when you apply a hotfix using the CF Admin, CF puts the file in a particular directory within CF (\lib\updates, or deep inside an instance in the Multiserver deployment).

So if by "restored the CF directory" you mean you did a copy or restore of files from a backup, that could have left the file that was added by your applying the hotfix, since copies and restores don't touch existing files in the destination directory.

But if instead you mean you deleted the current CF directory before doing the restore/copy, then yes that would be odd. The simplest thing is to check that directory to see if the jar is there. It would seem so (and the page where you see the jar listed does show its directory location, for you to confirm.)

2) As for the rest of the fix breaking things, it is easy unfortunately, because there are a lot of steps. And you're changing files in the CFIDE and other directories. There are definitely easy ways to mess things up, such as if you mistakenly remove (rather than add the new files to) the old CFIDE directories you're told to edit. Also, one can easily make a mistake of applying them to the WRONG cfide directory. I've seen many people who had more than one, depending on how they installed CF, or how updates were installed, or manual changes they may have made to move the CFIDE around for various security concerns.

To these I would just say: read the technote carefully, and make sure you're changing the CF Admin that CF points to. See the /cfide mapping in the CF administrator.

3) As for "How important is this patch in a non-shared environment?" well, these fixes are NOT about problems caused by other developers within your environment. Instead, they are about problems of people outside your environment leveraging holes in public directories, so I'm afraid it's still very important for anyone, certainly anyone on a public site, but even in a "private" site, you can't trust folks within your organization who have access to the web site: and to be clear, it's not about them having "admin access". It's about them simply being able to access the directories affected by the hotfix.

4) As for "is there any support to getting these patches working?", well, you found the right place to start at least. Folks here are quite generous in trying to help for free, as I have here.

But if you still struggle in considering the above, then if by "support" you mean, "I'd be willing to pay someone to help me get this solved", that's where there are in fact folks, like myself, who offer their services, remotely and on-demand. I provide more in my link below, and you can find still others listed in a category of troubleshooting consultants I keep at a site I manage: http://www.cf411.com/#cfassist

Hope some of that's helpful.

/charlie arehart

charlie@carehart.org

Providing on-demand troubleshooting services for CF and CFBuilder

at http://www.carehart.org/consulting

[sduncanute]

Charlie,

Thanks for the reply.  Yes, you are correct, the patch is in the cf\lib\updates directory as I just did a restore on top of the cf directory (with the exception of the databases).

I may have made an error in the update, after all we are all human, but I generally don't have an issue running updates and I've been dealing with CF since version 1.  I know I added files to and did not delete files from any of the directories.

I have a simple setup here: windows server with one instance of cf.

On the off chance that I had a brain fart while doing this the first time around, I'm willing to give it another go.  The next question becomes, should I delete the file in the cf'\lib\updates directory and go through the admin screen to re-apply, or does all the admin screen do is copy it to that updates directory?

If this doesn't work, then obviously I'll be looking for more help.  After I did the patching the last time, even the admin site wouldn't open.

Sue

[Charlie Arehart]

OK, so that explains why the hotfix was still in place. And I'm not sure if there's a problem with having it in place but not having the corresponding changes in the CFIDE directories also in place. Do if you have set them all back to what they were before, yes, you could just delete the jar from lib\updates and restart. The CF Admin feature for "installing" the jars does indeed do nothing more than "put them in the right place" for you.

As for your having done lots of hotfixes before and being only human, I hope you didn't read some "tone" into my note. I meant no offense. More important, though, is that it really doesn't matter if one's been doing CF hotfixes for years. These recent hotfixes are quite different than most of those in the past, which did not generally require such intricate surgery in the CFIDE and other directories holding CFML and other files. So it is in fact easier to make a mistake.

And the complication of multiple possible CFIDE locations is a real one. You say you only have one. Can you just confirm that the CF Admin mapping that points to CFIDE is in fact the "one" that you were modifying? It's just a sanity check.

I've applied the fix and things are working, as have many others. I really have feared (since its release) that it was too easy to make any of a few mistakes with the CFIDE directory edits. Those could lead to the 500 error you were seeing.

I'll only add as another thought, should you decide to try again (and for the security benefits, you really should), if you do get the errors again, check out the application.log in the \logs directory. Since many only look at those logs with the Admin, they may not think/know of them being in a file you can look at even when you can't get into the admin. There may be error messages in there that could help you. Similarly, look also in the \runtime\logs if you find nothing in the normal \logs. There are often useful errors in there that do not get into the application.log.

Hope that helps.

/charlie

[EmailAndTextGateways]

I found the 500 error occurred on CentOS when the CFIDE directory was written without execute permissions or group write permissions. After resolving that , I received a 404 for administrator/index.cfm.

It seems the DocumentRoot is modified during the hotfix. Permisssions and security context were the same. The path given in the error is relative, so it's only a guess.

This was my second attempt. I had to abort, Datsources were also corrupted during the process.

What file is the DocumentRoot for ColdFusion stored in for CF9?

Greg

[EmailAndTextGateways]

Looking for the DocumentRoot helped me resolve this. The new CFIDE directory contains only a partial listing ot the old. I should have only overwritten those directories under CFIDE that were provided instead of moving the old CFIDE directory.

Greg