It's all about the answers!

Ask a question

How to solve block in RRDI setup ?


Kevin Ramer (4.4k6160180) | asked May 29 '13, 1:20 p.m.
retagged May 31 '13, 2:58 p.m. by Laura W. Hinson (16126)
Setting up RRDI (I've done before w/o issue).  This is on an AIX server and I'm running the /rrdi/setup.  Step 1 goes ok, but on step 2 (setting up the content warehouse) I get:

CRRRA0077E: An error happened when validating the database. 'javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated'.

I have tried going into the setup uri both with http, https.  I did alter the ports for the http and https for the setup tool.   I get the expected SSL warning on the setup initialization step.

Thoughts?

p.s.  Seeing this in jts.log:

http-bio-12010-exec-14]  WARN sitory.service.internal.oauth.OAuthServiceProvider  - CRJAZ2115W The consumer application named "RRDI Setup (http://rtp-rrdi:12000/rrdi)" has been registered as "trusted", that is, for this consumer application it is not necessary to present to the user an authorization dialog requesting that user's permission to allow the application to access this server.  However, the callback URL "http://rtp-rrdi:12000/rrdi/oauthCallback?request_token_secret=S1HecWSXuHoVJiFmcCRnaVnXM1L41fvNcJIeFB2yLrg%3D" that was specified for request token authorization cannot be determined by this server to originate from any trusted consumer or application.  So for this authorization cycle, this consumer is not considered trusted and an authorization dialog will be issued. If you (the administrator) wish to assert that this callback is trusted, enter the callbackURL into the OAuthServiceProvider server configuration page section for trusted URIs, per the directions for that field.
2013-05-29 13:13:32,965 [        http-bio-12010-exec-17]  WARN sitory.service.internal.oauth.OAuthServiceProvider  - CRJAZ2115W The consumer application named "RRDI Setup (http://rtp-rrdi:12000/rrdi)" has been registered as "trusted", that is, for this consumer application it is not necessary to present to the user an authorization dialog requesting that user's permission to allow the application to access this server.  However, the callback URL "https://rtp-rrdi:12010/rrdi/oauthCallback?request_token_secret=HPNn7A8ViNPhwedvXlf8uCbWQQE93M89jc%2FAGaDz1R4%3D" that was specified for request token authorization cannot be determined by this server to originate from any trusted consumer or application.  So for this authorization cycle, this consumer is not considered trusted and an authorization dialog will be issued. If you (the administrator) wish to assert that this callback is trusted, enter the callbackURL into the OAuthServiceProvider server configuration page section for trusted URIs, per the directions for that field.

Have tried updating the jts configuration w/o much success.

2 answers



permanent link
Kevin Ramer (4.4k6160180) | answered Aug 26 '14, 4:41 p.m.
I hit this again and it turns out that there were a mix of http/https and or incorrect port in several of the URI in conf/rrdi/rrdi.properties

Once I got proper http[s] with port all is well.

permanent link
Indradri Basu (1.8k1514) | answered May 29 '13, 1:56 p.m.
Hi Kevin, to me it looks like your database system is configured with SSL and you need to import the reporting server SSL certificate in the database system trust store.

Comments
Kevin Ramer commented May 29 '13, 2:02 p.m.

Don't think DB2 is configured with SSL....

db2 get dbm cfg |grep SSL
 SSL server keydb file   (SSL_SVR_KEYDB) =
 SSL server stash file    (SSL_SVR_STASH) =
 SSL server certificate label    (SSL_SVR_LABEL) =
 SSL service name                 (SSL_SVCENAME) =
 SSL cipher specs                 (SSL_CIPHERSPECS) =
 SSL versions                        (SSL_VERSIONS) =
 SSL client keydb file              (SSL_CLNT_KEYDB) =
 SSL client stash file                  (SSL_CLNT_STASH) =



Indradri Basu commented May 29 '13, 2:02 p.m. | edited May 29 '13, 2:10 p.m.

Ahh, I jumped into conclusion. The way to circumvent the problem is mentioned in this article.


Kevin Ramer commented May 30 '13, 12:26 p.m.

I thought I tried that to no avail.   I'm trying again; is there a way to "reset" the setup to the point of fresh install w/o having to uninstall/re-install.  I have tried:

empty conf/jts/teamserver.properties
cleaning tomcat/work/Catalina/localhost



Francesco Chiossi commented May 31 '13, 3:44 a.m. | edited May 31 '13, 3:44 a.m.

Hello Kevin,

I think some of the data of the setup application is saved in the Derby repository used by its JTS.

I don't know how to cleanly restore it though.

Best Regards
Francesco


Kevin Ramer commented May 31 '13, 8:48 a.m.

Well, I removed the server directory from the setup tool and copied from another install location which was yet untouched.  Then I visited the setup URI under https, not http.  Seems to be moving along nicely now.

Your answer


Register or to post your answer.