CF10: Switched from Tomcat webserver to Apache2 - now cannot access ColdFusion Collections

Hello, Anit,

Thanks for your reply.

There was no migration.  When I originally installed CF10, I chose to use the built-in Tomcat webserver.  After a few months, I decided that I wanted to match (as much as possible) our production environment, so started looking for instructions on how to switch from the Tomcat server to Apache (without re-installing CF Server.)

All the logs show is what I've already mentioned - that it's a security issue, and the template was denied, apparently due to a java socketpermission issue.

I thought "localhost:0" meant a dynamic port, not necessarily trying to go through port 0.  I had found (can't find the link, now) an article that said something about editing the neo-security.xml file to turn off the built-in server, and did that.

At first, I was having issues with CreateObject(java) - until I discovered that one of the hotfixes I had applied then affected my Sandbox Security, pushing ALL cf functions into the "disable" column.  I've gone through everything in Sandbox, nothing is in the disable column, now.

V/r,

^_^

Hi, Charlie!  Thank you for your time.

Did not know that Solr is a distinct JVM from the rest of CF.  I've actually applied the Java update (to 7.55) twice - the first time I put it in Program Files; SA said that PF is locked, so I reinstalled to root of C:\ and pointed CF Admin Java/JVM to that location.  Could this be interfering with Jetty/Solr?

Solr Advanced settings:

Host Name: localhost

Solr Home: C:\ColdFusion10\cfusion\jetty\multicore

Solr Admin Port: 8985

Solr Webapp: solr

Buffer Limit: 120

Solr Connection: NOT checked for HTTPS connection (I'm not logging on to CFAdmin via SSL/TLS)

Solr Admin HTTPS Port: 0 (odd - I'm not connecting via HTTPS)

If I browse to 127.0.0.1:8985/solr/ then I get the "Welcome to Solr!" message and links to each collection.

V/r,

^_^

Charlie,

I did not make any changes to the Solr config files.

Switching back to CFs JVM (C:/ColdFusion10/jre) does allow me to view collections.

Yes, I did access the Solr admin from the same machine that CF is running on.

I should have checked the logs before switching back to the original CF JVM - both of those logs currently only show that the logs were initialized. 

Understood about the checkbox in advanced settings; but I'm confused because even though the admin settings are for HTTP, it apparently is still trying to access via port 0, which is the port set for HTTPS access.  So, I wonder if a config file was inadvertently altered that would push for port 0.

I'll reset back to the 7.55 JVM, trip the error message and then check the logs to see what they say.

V/r,

^_^

Okay.. all the -out and -error logs show is that they initialized, even after triggering the collection view error several times.

Looking at the exception log shows (basically) what I've already posted:

"error", "[instance name]", "07/14/14", "11:13:28", "cfadmin", "access denied (""java.net.socketPermission"" ""localhost:0"" ""listen,resolve"") The specific sequence of files included or processed is: C:\ColdFusion10\cfusion\wwwroot\CFIDE\administrator\solr\index.cfm"

Event Gateway log states nothing but "Event Gateway Disabled", from today back to the beginning.

Not sure what else to look at.

V/r,

^_^

Yes.  127.0.0.1:8985/solr/index.cfm brings up the "Welcome to Solr!" message and links to all collections on the server.

V/r,

^_^

Not feeling well.  Heading home, early, today.  Will pick up, tomorrow.  Thank you to everyone who has offered advice.

V/r,

^_^

Charlie,

Thank you.  I am feeling better, today.

If I set Java/JVM settings to use the JVM that came with CF, I can see collections; pointing CF to the update breaks collection administration in CF Admin.

But, yes, if I can keep the 7.55 update and have access to collections, that would be ideal.  If it's not possible, then it's not possible, but the thing is - I'm trying to get my DEV environment to match our production environment, and the production CF is using the 7.55 update and still has access to collections.  So, our SA and myself are stumped as to why this would be.  (I guess the OS, maybe, since I'm running Win7 64-bit and the production server is 2008 64-bit.  But that seems a bit of a stretch.)

Is it possible that when I point CFAdmin JVM to the newer/updated version that something in a Solr config file is being altered, as well?  OR, should be altered but isn't?

I'll type what details of my DEV installation I think may be pertinent:

Installation file: ColdFusion_10_WWEJ_win64.exe

Version: 10,0,13,287689

Tomcat Version: 7.0.23.0

Windows 7 (6.1)

Adobe Driver Version: 4.1 (Build 0001)

Java Version 1.7.0_55 (so, currently, collections cannot be administered)

Java File Encoding: Cp1252

Java VM Version: 24.55-b03

Java Class Version: 51.0

Java Ext Dirs:

     C:\Java7\jdk\jre\lib\ext

     C:\Windows\Sun\Java\lib\ext

If there is anything else that might help pinpoint the issue, please advise.

V/r,

^_^

Finally got around to editing the Jetty config files.  No change; the exact same error message about security and port 0.  Put everything back the way it was.

I'll give it a few more days to see if any other ideas pop.  If not, then I'll (begrudgingly) put my CF10 back to Java 6 and go from there.    I guess it's not CRITICAL that my dev matches prod exactly; but it might help with certain troubleshooting (esp if said troubleshooting involves Java.)

Thank you, all, esp. Charlie.

V/r,

^_^

Yes.  I made the change to the config file, stopped the Jetty service, restarted the Application service, then started Jetty and tested.

I'll give that idea (change lax to incorrect folder and restart) a go and report back what happens.  Thanks for another troubleshooting idea.

V/r,

^_^

!

Weird.  I made the change so that the JVM is pointing to C:\\Java7\\jdk\\jre\\fakefolder\\javaw.exe (it doesn't exist).

On the one hand, both Jetty and Application server started.  On the other hand, Event Viewer/Application shows:

The description for Event ID 3 from source ColdFusion 10 Application Server cannot be found.  (Ditto for Event ID 4)

So the services are starting, instead of failing and throwing an exception.

This makes me think that those edits are being seen by Jetty/Solr.  So changing Solr to the same JVM as the CF Server is using (the updated 7.55) makes no difference when it comes to administering the collections.. still the same error message about security and the template being denied.

V/r,

^_^

I've been Googling for some way to CFDUMP anything related to Jetty.  No luck, so far, but I'll keep searching.  There must be some way to CreateObject(java) the Jetty information.

V/r,

^_^

This has suddenly become an issue for production.

Apparently one of our production servers is CF9 (the rest are CF10) and on the CF9 server, every update after 7.45 is breaking Solr collections - every search triggers an email to the admin giving the exact same error message that my CF10 dev gives me when I try to go to the ColdFusion Collections in CFAdmin if the CFAdmin is pointing to 7.55 instead of the Java that comes with CF10.

Are there any recent known issues with CF9 or CF10 and the latest 3 or 4 Java updates??

V/r,

^_^

I filed a bug report with Adobe.  Please vote for it?

Bug#3795112 - CF9/CF10 - Java Updates 7.51+ break Solr collections

V/r,

^_^

Sorry for taking such a long time to respond.  Things have been hectic, and I just returned from vacation.

When browsing to 127.0.0.1/CFIDE/administrator/solr/index.cfm it will error (unable to determine the line of the template that caused the error) with the same message as if I accessed it via CFAdmin.

I did (just today) discover that Sandbox Security plays a role in this.  If I keep the JVM pointed to the updated Java and turn off Sandbox Security, I can access the Solr collections just fine.  But I cannot turn off Sandbox Security in production - big no-no. 

Editing JVM security and config files have not made a difference.

V/r,

I still have not found a way to output any of the Jetty specifics.  I have noticed that this is an issue if Sandbox Security is turned on.

I have modified the java.policy file in the 7.55 JVM as follows:

// set the following to java.policy
grant codebase "file:${{java.home}}/../db/lib/*"{
     permission java.net.SocketPermission "localhost:1024-","listen,resolve";
};

// added the following to "grant{};"
permission java.net.SocketPermission "localhost:0","connect,listen,accept,resolve";

permission java.net.SocketPermission "localhost:1024-","connect,listen,accept,resolve";

I have also modified jetty.lax as follows:

//changed lax.nl.current.vm=C:\\ColdFusion10\\jre\\bin\\javaw.exe to
lax.nl.current.vm=C:\\Java7\\jdk\\jre\\bin\\javaw.exe

//changed lax.nl.java.option.additional=-server -Xmx1024m -XX:+AggressiveOpts -XX:+ScavengeBeforeFullGC -XX:-UseParallelGC -DSTOP.PORT=8077 -DSTOP.KEY=cfstop -Dsolr.solr.home=multicore to
lax.nl.java.option.additional=-server -Xms1024m -Xmx1024m -XX:+UseConcMarkSweepGC -DSTOP.PORT=8077 -DSTOP.KEY=cfstop -Dsolr.solr.home=multicore

//changed lax.nl.win32.java.launcher.platform=0 to
lax.nl.win32.java.launcher.platform=2

I am still getting the access denied error message IF BOTH 7.55 JVM is selected AND Sandbox Security is on.

I have found ONE other person who is having this same issue.  (sigh)

HTH,

V/r,

A co-worker discovered the solution to the issue we've been having with Java 7.51+ breaking Solr collections on CF9/CF10.

I sincerely hope that Adobe plans on including this fix. I'll be updating my bugbase entry, soon.

Modify neo-security.xml as follows:

Locate the line that is

<var name=' { path to CFIDE } '>
(Obviously, enter the path to your CFIDE folder in place of above attribute value.)

The next line _should_ define the length of an array. Increase the value by 1.

Immediately below that, add the following:

2<struct>
3  <var name='CLASS'>
4      <string>java.net.SocketPermission</string>
5  </var>
6  <var name='TARGET'>
7      <string>127.0.0.1:0</string>
8  </var>
9  <var name='ACTION'>
10      <string>listen,resolve</string>
11  </var>
12</struct>

Save neo-security.xml, restart CF Application service, and test.

HTH,

V/r,

^_^

UPDATE: Okay.. this did correct the CFAdmin issue of being able to see the collections, but it broke CFSEARCH. So, we had to undo the manual neo-security.xml edit, go into Sandbox Security and click on the entry for CFIDE, then add "127.0.0.1" which enters as "connect,resolve". NOW, manually edit the neo-security.xml file, scroll down to the bottom of /wwwroot/ var, copy and paste the whole struct for 127.0.0.1, give both of them ":0-" to cover the whole range of ports, change the ACTION of the second struct to "listen,resolve", save the file, restart the CF Application service, and test.

I'm sure different setups will require different things, but this should serve as a template for what needs to be done.