Custom Query (1181 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (166 - 168 of 1181)

Ticket Resolution Summary Owner Reporter
#593 fixed IZ2780: Move manager/operator setup out of CreateSGEStartupScripts dlove opoplawski
Description

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

        Issue #:      2780             Platform:     All       Reporter: opoplawski (opoplawski)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      current      CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    PATCH
                                   Target milestone: ---
      Assigned to:    dom (dom)
      QA Contact:     dom
          URL:
       * Summary:     Move manager/operator setup out of CreateSGEStartupScripts
   Status whiteboard:
      Attachments:
                      Date/filename:                                         Description:                                              Submitted by:
                      Thu Nov 6 09:15:00 -0700 2008: SetupDefaultUsers.patch Patch to create "SetupDefaultUsers" function (text/plain) opoplawski

     Issue 2780 blocks:
   Votes for issue 2780:


   Opened: Thu Nov 6 09:14:00 -0700 2008 
------------------------


Currently, the default manager and operator users are setup in
"CreateSGEStartupScripts".  This is confusing as it really doesn't have anything
to do with creating startup scripts.  The attached patch creates a new function
"SetupDefaultUsers" and calls it when appropriate.

This is helpful in my Fedora packages because I don't want to create startup
scripts, but I do want to setup the default users.

   ------- Additional comments from opoplawski Thu Nov 6 09:15:39 -0700 2008 -------
Created an attachment (id=182)
Patch to create "SetupDefaultUsers" function
#600 fixed IZ2803: Master installation with JMX support fails on DARWIN ernst
Description

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

        Issue #:      2803             Platform:     All        Reporter: ernst (ernst)
       Component:     gridengine          OS:        Mac OS X
     Subcomponent:    install          Version:      6.0u1         CC:    None defined
        Status:       NEW              Priority:     P2
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    dom (dom)
      QA Contact:     dom
          URL:
       * Summary:     Master installation with JMX support fails on DARWIN
   Status whiteboard:
      Attachments:

     Issue 2803 blocks:
   Votes for issue 2803:


   Opened: Fri Nov 21 05:02:00 -0700 2008 
------------------------


Master installation with JMX fails on DARWIN with:

Error: bootstrapping of rand command as user username failed (/tmp/.rand.67092
-> /var/sgeCA/port5000/default/private/rand.seed)
Error: CA initialization failed. Exit.

Reason for this is that the openssl binary which is used in the sge_ca script
during the installation tries to load the wrong shared library because
DYLD_LIBRARAY_PATH is not set in sge_ca.

To fix this the lines setting the LD_LIBARAY_PATH

if [ "$LD_LIBRARY_PATH"  = "" ]; then
   LD_LIBRARY_PATH=$ROOT_PATH/lib/$ARCH
else
   LD_LIBRARY_PATH="$ROOT_PATH/lib/${ARCH}:${LD_LIBRARY_PATH}"
fi
export LD_LIBRARY_PATH

have to be replaced with

shlib_path_name=`$ROOT_PATH/util/arch -lib`
old_shlib_path_name=`eval echo '$'$shlib_path_name`
if [ x$old_shlib_path_name  = x ]; then
   eval $shlib_path_name=$ROOT_PATH/lib/$ARCH
else
   eval $shlib_path_name="$ROOT_PATH/lib/${ARCH}:${old_shlib_path_name}"
fi
export $shlib_path_name

This might also be also an issue in 6.0 and 6.1 were sge_ca is used to install a
CSP system. It has also to be verified that architectures which do not used
LD_LIBRARAY_PATH as variable name (like AIX) behave correcly.

   ------- Additional comments from ernst Thu Dec 4 08:30:12 -0700 2008 -------
Fixed in maintrunc. Will be available with 6.2u2. Other versions still have to
be checked...
#601 fixed IZ2807: inadequate inst_qmaster/inst_execd diagnosis if binary and common packages are not in $SGE_ROOT mpospisil
Description

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

        Issue #:      2807             Platform:     All      Reporter: mpospisil (mpospisil)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0         CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    mpospisil (mpospisil)
      QA Contact:     dom
          URL:
       * Summary:     inadequate inst_qmaster/inst_execd diagnosis if binary and common packages are not in $SGE_ROOT
   Status whiteboard:
      Attachments:

     Issue 2807 blocks:
   Votes for issue 2807:


   Opened: Fri Nov 21 08:13:00 -0700 2008 
------------------------


The current SGE installation is designed to require SGE_ROOT pointing to the
root directory of the distribution and to be the parent directory of the <cell>
directory.

I suspect that the inadequate error checking was introduced with SGE 6.0! The
SGE 5.3 checked by default if this prerequsite is met.

The SGE 5.3 installation routine has a function which is called
"ProcessQsystRoot". In this shell function by default there is a checking if the
current working directory (the directory from which "inst_sge" is called)
matches the $SGE_ROOT directory.

In SGE 6.0/6.1 the shell function is in

   util/install_modules/inst_common.sh:ProcessSGERoot()

The code where the check is done is protected by a if clause which only does
this check if the variable "strict" is set to true:

      # do not check for correct SGE_ROOT in case of -nostrict
      if [ "$strict" = true ]; then
      [...]

As the comment indicates a command line parameter "-nostrict" would overwrite
this behavior. However the SGE 6.0/6.1 installation routine does not anymore
support the parameter "-nostrict" nor there is any evidence in the entire
installation routine
that the variable "strict" is set at all.

This is the root cause in my opinion why this problem occurred.
Note: See TracQuery for help on using queries.