Custom Query (431 matches)
Results (16 - 18 of 431)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#293 | fixed | IZ1881: sgeCA should be outside of CELL directory | Dave Love <d.love@…> | roland |
Description |
[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. |
|||
#314 | fixed | IZ1949: 2 instances of non well-formed XML output from "qstat -xml" | Dave Love <d.love@…> | craffi |
Description |
[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)); } } |
|||
#340 | fixed | IZ2025: change behaviour of "admin_user" in bootstrap | Dave Love <d.love@…> | roland |
Description |
[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. |
Note: See TracQuery
for help on using queries.