Custom Query (431 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (154 - 156 of 431)

Ticket Resolution Summary Owner Reporter
#665 fixed IZ3005: jgdi SSL connections from one client jvm to different SGE cluster might not work rhierlmeier
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=3005]

        Issue #:      3005             Platform:     Sun      Reporter: rhierlmeier (rhierlmeier)
       Component:     gridengine          OS:        All
     Subcomponent:    jgdi             Version:      6.2         CC:    None defined
        Status:       NEW              Priority:     P2
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andre (andre)
      QA Contact:     andre
          URL:
       * Summary:     jgdi SSL connections from one client jvm to different SGE cluster might not work
   Status whiteboard:
      Attachments:

     Issue 3005 blocks:
   Votes for issue 3005:


   Opened: Sun Apr 19 22:34:00 -0700 2009 
------------------------


If in one jvm opens serveral jgdi connections to different qmasters at nearly the same time the SSL certificate validate can fail, even if
valid keystores and certificates are used.

The user see the following error message:

Caused by javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1518)
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:848
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:818)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1030)


The problem is a bug in class com.sun.grid.jgdi.management.SSLHelper. The following member
variables must not be declared static:

public final class SSLHelper {
...
    private static SSLContext ctx;
    private static final GECAKeyManager keyManager = new GECAKeyManager();
    private static final GECATrustManager trustManager = new GECATrustManager();
    private static final Lock lock = new ReentrantLock();
...
}

However they are static and hence each jgdi connection gets the same SSLContext for a short time frame.

This is not a security vulnerability because the SSLContext is mixed up the SSL validation fails always.
#676 fixed IZ3038: upgrade scripts do not handle fully qualified domain names shaas
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=3038]

        Issue #:      3038             Platform:     Sun         Reporter: shaas (shaas)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.2u3beta      CC:    None defined
        Status:       STARTED          Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    shaas (shaas)
      QA Contact:     dom
          URL:
       * Summary:     upgrade scripts do not handle fully qualified domain names
   Status whiteboard:
      Attachments:

     Issue 3038 blocks:
   Votes for issue 3038:


   Opened: Thu May 28 05:12:00 -0700 2009 
------------------------


Calling save_sge_config.sh or load_sge_config.sh on a host with a fully qualified domain name (eg. host.domainA.domainB.com) causes the
following error:
Load must be started on admin host (qmaster host recommended).

Calling inst_sge -upd on a host with a fqdn causes:
Upgrade must be started on a qmaster host!

   ------- Additional comments from shaas Thu May 28 06:55:16 -0700 2009 -------
I'll take it.

   ------- Additional comments from shaas Thu May 28 06:56:18 -0700 2009 -------
I'll do it.
#678 fixed IZ3046: cluster name check is failing in installation mpospisil
Description

[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=3046]

        Issue #:      3046             Platform:     All        Reporter: mpospisil (mpospisil)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.2alpha      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    mpospisil (mpospisil)
      QA Contact:     dom
          URL:
       * Summary:     cluster name check is failing in installation
   Status whiteboard:
      Attachments:

     Issue 3046 blocks:
   Votes for issue 3046:


   Opened: Thu Jun 11 06:59:00 -0700 2009 
------------------------


After starting a new Berkeley DB installation with inst_sge -db and entering
an unused cluster name I got this error:

Unique cluster name
-------------------

The cluster name uniquely identifies a specific Sun Grid Engine cluster.
The cluster name must be unique throughout your organization. The name
is not related to the SGE cell.

The cluster name must start with a letter ([A-Za-z]), followed by letters,
digits ([0-9]), dashes (-) or underscores (_).

Enter new cluster name or hit <RETURN>
to use default [p] >> dom_666
Specified cluster name >$SGE_CLUSTER_NAME=dom_666< is already used by your syste
m!
Detected a presence of old SGE RC scripts.
/etc/init.d/sgebdb

Do you want to remove them?

NOTE: Choose 'n' to select new SGE_CLUSTER_NAME  (y/n) [y] >>

The scripts detects the entered cluster name as already in use. The error also may appear due to the existing sgebdb file. I'm not sure.
Note: See TracQuery for help on using queries.