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

        Issue #:      2845             Platform:     All           Reporter: opoplawski (opoplawski)
       Component:     gridengine          OS:        All
     Subcomponent:    build            Version:      6.2u1            CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     Need to be able to dynamically link to openssl
   Status whiteboard:
      Attachments:

     Issue 2845 blocks:
   Votes for issue 2845:


   Opened: Thu Dec 18 15:44:00 -0700 2008 
------------------------


Currently the build expects to link statically (at least some components) to
libssl.a and libcrypto.a.  To build for Fedora, I need to link dynamically.  I
currently use:

--- gridengine/source/aimk.ssl  2008-05-22 15:16:17.000000000 -0600
+++ gridengine/source/aimk      2008-05-22 15:18:06.000000000 -0600
@@ -337,7 +337,7 @@
 set SEC               = 1
 set SECFLAGS          = "-DSECURE -I$OPENSSL_HOME/include"
 set SECLIB            = ""
-set SECLIBS_STATIC    = "$OPENSSL_HOME/lib/libssl.a $OPENSSL_HOME/lib/libcrypto.a"
+set SECLIBS_STATIC    = "-lssl"
 set KLFLAGS           = "-L$OPENSSL_HOME/lib"

 set CORELIB           = ""

But it would be nice if I could specify this as a build option.

   ------- Additional comments from andreas Fri Dec 19 05:23:17 -0700 2008 -------
Adding this as build option should be possible. Reason for static linking is to
prevent someone foist invalid openssl libraries via LD_LIBRARY_PATH.
Have you thought about this?

   ------- Additional comments from opoplawski Fri Dec 19 08:27:35 -0700 2008 -------
Static linking in not scalable in the event of a security update to the openssl
libs.  Is there any distribution out there that statically links to openssl for
all of its applications?

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

        Issue #:      2847             Platform:     All      Reporter: torsten (torsten)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.2u1       CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    dom (dom)
      QA Contact:     dom
          URL:
       * Summary:     Execd install fails when hostname contains capital letters
   Status whiteboard:
      Attachments:

     Issue 2847 blocks:
   Votes for issue 2847:


   Opened: Tue Dec 23 04:02:00 -0700 2008 
------------------------


During an execd installation, step "Checking hostname resolving", the
installation produces a warning that the host, on which the execd is to be
installed, is not known as an administrative host:

This hostname is not known at qmaster as an administrative host.

However, the host is already part of the administrative host list (qconf -sh).
The hostname in this administrative host list contains uppercase letters. It is
reported exactly the same way (including the uppercase letters) by
'$SGE_UTILBIN/gethostname -aname'. Nevertheless, the installation procedure does
not recognize that the names are the same.

This happens in a system that uses FQDN with no default domain.

Suggested Fix
In util/install_modules/inst_execd.sh, line 285, the same tr command as in line
282 should be used on the hostname.

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

        Issue #:      2871             Platform:     All      Reporter: templedf (templedf)
       Component:     gridengine          OS:        All
     Subcomponent:    man              Version:      6.2         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    andreas (andreas)
      QA Contact:     andreas
          URL:
       * Summary:     SGE_COMPLEX_ hook should be documented
   Status whiteboard:
      Attachments:

     Issue 2871 blocks:
   Votes for issue 2871:


   Opened: Mon Jan 12 14:41:00 -0700 2009 
------------------------


The SGE_COMPLEX_ hook described in the workaround for Issue 409 should be
documented in the man page for qsub/qrsh.

   ------- Additional comments from templedf Mon Jan 12 14:58:27 -0700 2009 -------
I just tested this feature in 6.2, and it doesn't appear to work.  Perhaps this
should be a qsub issue instead.