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.
>> >
>> >
>> >
>>
>
