Solved! After I've typed: /usr/local/apache-river-2.2.0/lib-ext# cp jsk-policy.jar /usr/local/jdk1.6.0_24/jre/lib/ext/
...the ssl-reggie.sh script is working now! My apologies for that last message! Kindest regards to everybody. Helcio. 2011/8/29 helcio silva <[email protected]>: > Hi, Ivan. > > Thanks a lot for your explanation. Indeed, that script was > successfully started after I've moved myself to the > $RIVER_HOME/examples/hello directory. > > I am interested on run the secure version of hello, and the > tutorial included on release presents the following steps to do that: > > C-6 SSL - client displays login dialog box > c. >> scripts/ssl-reggie.sh > d. >> scripts/ssl-server.sh > e. >> scripts/ssl-client.sh > > However, I've received the message below when starting ssl-reggie.sh script: > > /usr/local/apache-river-2.2.0/examples/hello# scripts/ssl-reggie.sh > + java -Djava.security.manager= > -Djava.security.policy=config/ssl-reggie.policy > -Djava.security.auth.login.config=config/ssl-reggie.login > -Djava.security.properties=config/dynamic-policy.security-properties > -Djavax.net.ssl.trustStore=prebuiltkeys/truststore > -Djava.protocol.handler.pkgs=net.jini.url -jar ../../lib/start.jar > config/start-ssl-reggie.config > Exception in thread "main" java.lang.ExceptionInInitializerError > at > net.jini.config.ConfigurationProvider.getInstance(ConfigurationProvider.java:180) > at > net.jini.config.ConfigurationProvider.getInstance(ConfigurationProvider.java:137) > at com.sun.jini.start.ServiceStarter.main(ServiceStarter.java:475) > Caused by: java.security.AccessControlException: access denied > (java.lang.RuntimePermission createSecurityManager) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:374) > at > java.security.AccessController.checkPermission(AccessController.java:546) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at java.lang.SecurityManager.<init>(SecurityManager.java:282) > at > net.jini.security.Security$ClassContextAccess.<init>(Security.java:965) > at > net.jini.security.Security$ClassContextAccess.<init>(Security.java:965) > at net.jini.security.Security$1.run(Security.java:167) > at java.security.AccessController.doPrivileged(Native Method) > at net.jini.security.Security.<clinit>(Security.java:165) > ... 3 more > > I don't know what's happening now. Any idea? > > Best regards. > > PS: the httpd.sh script is running when I've started ssl-reggie.sh. > > 2011/8/29 Иван Бишевац <[email protected]>: >> You are not on right path when try to execute this script. >> >> It's because httpd.sh script contains for example path >> to ../../lib/classserver.jar. Two dots (..) means one directory up. If you >> are executing this script from $RIVER_HOME/examples/hello/scripts then >> ../../lib/classserver.jar is equivalent to >> $RIVER_HOME/examples/lib/classserver.jar, but there is not that directory. >> >> Solution is to just cd one level up and then execute: >> scripts/httpd.sh >> >> 2011/8/29 helcio silva <[email protected]> >> >>> Hello, Peter. >>> >>> As a matter of fact, I've used the Jan Newmarch's book as a >>> reference. On chapter named 'Advanced Security', it suggests, for >>> example, the use of Loggers. Well, when I look the file generated by >>> loggers, I can see all that proxy verifiers listed below. However, I >>> am still receiving a message saying that the server's proxy is >>> untrusted. >>> >>> I've calculated the MD5 hash on a -dl.jar file using the >>> computedigest.jar application, as it's shown on Newmarch's book, and >>> put that hash in an HTTPMD URL. Next, I've started the classserver.jar >>> application, pointing it to that -dl.jar file. >>> >>> There is another remarkable point that I want to comment here: it >>> is about the hello demo application included on River distribution >>> releases. More specifically, I am talking about the >>> $RIVER_HOME/examples/hello directory. There is a directory named >>> 'scripts' inside the hello directory, containing (obviously) scripts >>> to running hello application using different scenarios. However, when >>> I try to run one of those scripts, httpd.sh, I receive the following >>> message: >>> >>> ./httpd.sh >>> + java -jar ../../lib/classserver.jar -port 8080 -dir lib:../../lib-dl >>> Unable to access jarfile ../../lib/classserver.jar >>> >>> In my opinion, that script would work just when we use >>> "../../../lib/classserver.jar" instead of "../../lib/classserver.jar". >>> It also would work if we move it (without modification) to directory >>> above. >>> >>> Is that an error to be fixed on next distributions? Or am I doing >>> something wrong here? >>> >>> Best regards. >>> >>> Helcio. >>> >>> 2011/8/28 Peter Firmstone <[email protected]>: >>> > Hi Helcio, >>> > >>> > Good to see your interest in River. The class files are definitely >>> there, >>> > I've given you a link to Jan Newmarch's online book, hopefully this will >>> > help you figure it out. The problem might have something to do with your >>> > policy or configuration. >>> > >>> > http://jan.newmarch.name/java/jini/tutorial/AdvancedSecurity.html >>> > >>> > The client needs to have a list of local verifiers that it trusts just >>> > because they are local. A standard set is given in the Jini library >>> > jsk-platform.jar file. This jar file contains the following verifiers: >>> > >>> > 1. >>> > >>> > ConstraintTrustVerifier >>> > >>> > 2. >>> > >>> > BasicJeriTrustVerifier >>> > >>> > 3. >>> > >>> > SslTrustVerifier >>> > >>> > 4. >>> > >>> > KerberosTrustVerifier >>> > >>> > 5. >>> > >>> > ProxyTrustVerifier >>> > >>> > 6. >>> > >>> > ConstrainableLookupLocatorTrustVerifier >>> > >>> > 7. >>> > >>> > DiscoveryConstraintTrustVerifier >>> > >>> > Cheers, >>> > >>> > Peter. >>> > >>> > >>> > >>> >> >
