[oi-dev] hipster a8: ILOM remote console broken

[Udo Grabowski (IMK)]

SOLVED !
These were, at last, helpful tips, though I now don't know
why that even worked on 157a7 before !

The problem was that I have installed Java 1.7.0_17 in parallel
to 1.6.0, but the main link via /usr/java to jdk/latest still
was fixed to the 1.6.0 version (I've to check again why I still
need that). JAVA_HOME and the symlinks point to the /usr/java
and should be all 1.6. Running the javaws on the jnlpgenerator-16 file
with the -verbose flag then showed that javaws began to mix
up 1.6 and 1.7 jar inputs for it's different option flags !
Setting jdk/latest to the 1.7 version and restarting firefox
then finally started ILOM again.
Since that mixup was also present in a7, I now really wonder
why that setup worked at all with javaws.....

On 13/06/2013 10:54, Jim Klimov wrote:
> On 2013-06-13 08:34, Udo Grabowski (IMK) wrote:
>> On 13/06/2013 00:07, Andrzej Szeszo wrote:
>>> What kind of ILOM are you connecting to? Perhaps I could try
>>> replicating your problem over here by connecting to our Sun gear.
>>
>> These are ILOM versions 3.0.x on a Sun Blade X6275, a Thumper X4540,
>> and a X4275. All of them worked with a7, but break on a8. I believe
>> that com.sun.javaws.LaunchDownload.validateResults may be related
>> to the certificate check, since the missing SUN certs are the obvious
>> change on a8, but I'm not sure, since there's no java source available
>> for ILOM.
>
> Well, I confess that I almost never used ILOMs from *nix systems but
> rather from Windows laptops and desktops with both Firefox and MSIE;
> in those cases there were two security-related requests from browser
> security:
> 1) Trust the HTTPS certificate? (Self-signed by default, corporate CA
> by further configuration - no explicit trusts needed then)
> 2) Trust the Java Applet provider (the ILOM host name often) and/or
> its code-signing? (Again, if I confirmed the security exception once
> and the browser remembered it, I had no further problems)
>
> Just in case, try an empty browser profile (perhaps from a new user
> account or with Private Browsing) to connect to the ILOMs and see if
> the newly-requested explicit trusts would suffice further on?
>
> Of course, the probem cause may be deeper down the road, including
> the Java version (i.e. Sun/Oracle JRE vs. OpenJDK) and its own cert
> store in $JAVA_HOME/{jre,}/lib/security/cacerts and/or the OS cert
> store - as you suspect... Then again, you say Java was unchanged and
> you've copied over the /etc/cert database...
>
> To debug further and rule the browser out, you might download the
> JARs to your local system and try running them with "java -jar ..."
> guessing the dependencies ("-cp file.jar:lib/file2.jar"...) and
> perhaps command-line options from the JNLP script ("argument" tags
> seems most likely).
>
> At least, if Java still produces errors about JAR loading, you may
> have more debug options available and rule out if it is a browser
> or OS problem... maybe :)
>
> HTH,
> //Jim Klimov

-- 
Dr.Udo Grabowski    Inst.f.Meteorology a.Climate Research IMK-ASF-SAT
www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology            http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2050 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20130614/410fff41/attachment-0005.bin>