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

        Issue #:      1881             Platform:     Sun           Reporter: roland (roland)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0              CC:    None defined
        Status:       NEW              Priority:     P3
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    dom (dom)
      QA Contact:     dom
          URL:
       * Summary:     sgeCA should be outside of CELL directory
   Status whiteboard:
      Attachments:

     Issue 1881 blocks:
   Votes for issue 1881:


   Opened: Thu Nov 10 08:33:00 -0700 2005 
------------------------


The sgeCA directory located in $CELL/common/ should be outside of this
directory. At reinstallation time the CELL directory can be deleted and
therefore the certificates need to be newly installed on all hosts.

We had also a bug (CR 6347351) where the CELL directory was deleted and the
installation asked if the certs should be recreated. If the user answered no the
CA infrastructure was incomplete and not usable.

Because of this we should install ALL Ca infrastructure files outside the CELL
directory

   ------- Additional comments from opoplawski Thu Dec 18 15:50:22 -0700 2008 -------
It seems to have been moved to /var/sgeCA in 6.2, but this violates the FHS
scricture against creating new directories in /var.  It probably should be
/var/lib/sgeCA.

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

        Issue #:      1949             Platform:     All      Reporter: craffi (craffi)
       Component:     gridengine          OS:        All
     Subcomponent:    clients          Version:      6.0u7       CC:    None defined
        Status:       STARTED          Priority:     P2
      Resolution:                     Issue type:    DEFECT
                                   Target milestone: ---
      Assigned to:    roland (roland)
      QA Contact:     roland
          URL:        http://gridengine.sunsource.net/servlets/BrowseList?list=dev&by=thread&from=7191
       * Summary:     2 instances of non well-formed XML output from "qstat -xml"
   Status whiteboard:
      Attachments:

     Issue 1949 blocks:
   Votes for issue 1949:


   Opened: Mon Dec 19 08:30:00 -0700 2005 
------------------------


Discussed on the dev mailing list via this thread:

http://gridengine.sunsource.net/servlets/BrowseList?list=dev&by=thread&from=7191

================
Problem #1
================

Summary:
'qstat -j <jobID> -xml' produces non-compliant (not well formed) XML output

Reproduce:
Run "qstat -xml -j <jobID>" on a job ID that does not exist

Sample ouput showing error:

chrisdag:~/sgetest dag$ qstat -j 11 -xml
<?xml version='1.0'?>
<unknown_jobs  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <>
   <ST_name>11</ST_name>
 </>
</unknown_jobs>

 -- and --

qstat -j 1234 -xml
error: can't unpack gdi request
error: error unpacking gdi request: bad argument
<?xml version='1.0'?>
<unknown_jobs  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <>
    <ST_name>1234</ST_name>
  </>
</unknown_jobs>



================
Problem #2
================

Summary:
When there are Grid Engine communication or access problems, "qstat -f -xml"
does not produce XML at all, or in some cases will produce non-well-formed XML
similar to Problem #1 described above

Reproduce:
Less convenient than problem #1. My specific problem was caused by a changing IP
address on the qmaster/execd node. This problem may be reproducable by
intentionaly generating a different sort of error.

Example:

chrisdag:~/sgetest dag$ qstat -f -xml

error: commlib error: access denied (client IP resolved to host name
"chrisdag.local". This is not identical to clients host name
"chrisdag-wireless.private.sonsorol.net")
unable to contact qmaster using port 701 on host "chrisdag.local"

   ------- Additional comments from roland Mon Feb 13 01:42:34 -0700 2006 -------
changed priority

   ------- Additional comments from olesen Fri Jun 26 03:45:56 -0700 2009 -------
*** Issue 3057 has been marked as a duplicate of this issue. ***

   ------- Additional comments from olesen Fri Jun 26 03:49:33 -0700 2009 -------
increase priority
The badly formatted <> and </> tags should be fairly trivial to avoid.

   ------- Additional comments from templedf Thu Dec 3 06:56:05 -0700 2009 -------
From Mark Olesen:

I suspect that problem is in libs/cull/cull_xml.c
lWriteListXML_ (not lWriteELemXML_).


There is no check before the corresponding fprintf.
Eg,

{
  fprintf(fp, "%s<%s%s>", indent, lGetString(elem, XMLA_Name),
     (is_attr?sge_dstring_get_string(&attr):""));
  fprintf(fp, "%s", lGetString(elem, XMLA_Value));
  lWriteListXML_(lGetList(ep, XMLE_List), nesting_level+1, fp);
  fprintf(fp, "</%s>\n", lGetString(elem, XMLA_Name));
}


Wouldn't it just be a simple case of doing this?

{
  const char* tag = lGetString(elem, XMLA_Name);

  if (tag != NULL && strlen(tag))
  {
    fprintf(fp, "%s<%s%s>", indent, tag,
      (is_attr?sge_dstring_get_string(&attr):""));
    fprintf(fp, "%s", lGetString(elem, XMLA_Value));
  }
  lWriteListXML_(lGetList(ep, XMLE_List), nesting_level+1, fp);

  if (tag != NULL && strlen(tag))
  {
    fprintf(fp, "</%s>\n", tag));
  }
}

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

        Issue #:      2025             Platform:     Sun           Reporter: roland (roland)
       Component:     gridengine          OS:        All
     Subcomponent:    install          Version:      6.0u7            CC:    None defined
        Status:       NEW              Priority:     P2
      Resolution:                     Issue type:    ENHANCEMENT
                                   Target milestone: ---
      Assigned to:    dom (dom)
      QA Contact:     dom
          URL:
       * Summary:     change behaviour of "admin_user" in bootstrap
   Status whiteboard:
      Attachments:

     Issue 2025 blocks:
   Votes for issue 2025:


   Opened: Tue Apr 4 00:36:00 -0700 2006 
------------------------


We have always bugs because of wrong ADMINUSER handle in the install scripts.

The bootstrap file contains the admin_user. In case of admin user is root this
variable is set to "none" in bootstrap file. Inside the script the ADMINUSER
variable is set to "default".

This missmatch is error prone because if anyone want to use the ADMINUSER
variable inside the script one needs to check if it's set to "default".

To be consistent and less error prone the admin_user field in bootstrap should
always contain a valid user, incase of root the value "root". Also the ADMINUSER
variable inside the script should be set to "root" in this case.