Custom Query (431 matches)
Results (109 - 111 of 431)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#491 | fixed | IZ2506: Change default method to determine Linux libC version | dlove | brunner |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2506] Issue #: 2506 Platform: Other Reporter: brunner (brunner) Component: gridengine OS: All Subcomponent: install Version: 6.1u3 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: --- Assigned to: dom (dom) QA Contact: dom URL: * Summary: Change default method to determine Linux libC version Status whiteboard: Attachments: Issue 2506 blocks: Votes for issue 2506: Opened: Mon Feb 25 16:48:00 -0700 2008 ------------------------ When installing Grid Engine 6.1u3 on a fairly minimal Fedora 8 installation I noticed the "strings" dependency that the $SGE_ROOT/util/arch script has for linux boxes. Installing the binutils rpm got me past the installation issue but during my investigation into the $SGE_ROOT/util/arch script I saw the following: <snip> # verify the GNU C lib version # For an alternative means to determine GNU C lib version see # http://www.gnu.org/software/libc/FAQ.html#s-4.9 case $lxmachine in amd64) libc_string=`strings /lib64/libc.so.6 | grep "GNU C Library"` <snip> The alternative method, which is a simple replace of the strings call with a direct execution of libc thus elminating the strings dependency, should be the default method. Here is an example showing the identical ouput from the 2 commands: [cbrunner@cbrunner-f8 ~]$ strings /lib/libc.so.6 | grep "GNU C Library" GNU C Library stable release version 2.7, by Roland McGrath et al. [cbrunner@cbrunner-f8 ~]$ /lib/libc.so.6 | grep "GNU C Library" GNU C Library stable release version 2.7, by Roland McGrath et al. This bug was discussed on the users@gridengine.sunsource.net list here: http://gridengine.sunsource.net/servlets/BrowseList?list=users&by=thread&from=28420 and http://gridengine.sunsource.net/servlets/BrowseList?list=users&by=thread&from=28424 Note: The strings utility is also used in: $SGE_ROOT/util/install_modules/inst_qmaster.sh if CSP is enabled. |
|||
#492 | fixed | IZ2507: "root" should be able to submit jobs for arbitrary users via DRMAA | Dave Love <d.love@…> | andreas |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2507] Issue #: 2507 Platform: All Reporter: andreas (andreas) Component: gridengine OS: All Subcomponent: drmaa Version: 6.1u3 CC: [_] james [_] Remove selected CCs Status: STARTED Priority: P3 Resolution: Issue type: ENHANCEMENT Target milestone: Maintrunk Assigned to: templedf (templedf) QA Contact: templedf URL: http://gridengine.sunsource.net/servlets/BrowseList?list=dev&by=thread&from=28404 * Summary: "root" should be able to submit jobs for arbitrary users via DRMAA Status whiteboard: Attachments: Date/filename: Description: Submitted by: Thu Feb 28 16:15:00 -0700 2008: 2507.diff Patch to implement "drmaa_submit_as_euid" based on V61_BRANCH (text/plain) andreas Mon May 5 05:06:00 -0700 2008: Maintrunk_2507.diff Source diff against maintrunk (RD-2008-05-05-1) (text/plain) andreas Mon May 5 06:17:00 -0700 2008: MT_man2507.diff Man page diff against Maintrunk for drmaa_attributes(3) (text/plain) andreas Issue 2507 blocks: Votes for issue 2507: Opened: Thu Feb 28 16:11:00 -0700 2008 ------------------------ DESCRIPTION: "root" should be able to submit jobs for arbitrary users via DRMAA HOWTOFIX: Add a "drmaa_submit_as_euid" job template attribute, that causes effective user/group be used when drmaa_run_job()/drmaa_run_bulk_job() is being called. ------- Additional comments from andreas Thu Feb 28 16:15:52 -0700 2008 ------- Created an attachment (id=155) Patch to implement "drmaa_submit_as_euid" based on V61_BRANCH ------- Additional comments from andreas Fri Apr 25 05:44:10 -0700 2008 ------- According a short report I received from James Vanns he tried the attached patch and it did work. ------- Additional comments from andreas Mon May 5 04:33:26 -0700 2008 ------- Changed IZ-URL so that the mail thread where Dan, James, and I discussed implementation topics can easily be accessed by anyone. In informal discussion a number of concernes were raised against this RFE. As to give anyone a chance to participate in the debate I summarize those amongst the concerns that I consider as valid: (1) How can we sure this RFE introduces no new risks in terms of security? (2) Will this RFE work also in CSP-security mode? ------- Additional comments from andreas Mon May 5 05:06:20 -0700 2008 ------- Created an attachment (id=169) Source diff against maintrunk (RD-2008-05-05-1) ------- Additional comments from andreas Mon May 5 06:17:39 -0700 2008 ------- Created an attachment (id=170) Man page diff against Maintrunk for drmaa_attributes(3) ------- Additional comments from roland Mon May 5 06:46:25 -0700 2008 ------- I did a quick review on the patch and as it's implemented it will not work with SGE's CSP mode. In CSP mode on qmaster side the username provided by the certificate and the username saved in the GDI session is compared and must be identical. This check will fail if the context was created with the certificates of user X and the GDI request claim to come from user Y. ------- Additional comments from andreas Mon May 5 07:55:12 -0700 2008 ------- Specificatioon document draft now available under http://wiki.gridengine.info/wiki/index.php/Submission_for_arbitrary_jobs_via_DRMAA ------- Additional comments from andreas Tue May 6 06:01:48 -0700 2008 ------- Having investigated the certificate handling in qmaster I must confirm Rolands comments. After consultation with Andre I see three possibilities to deal with that issue: (1) Enhance the handling of GDI session certificates in a way that one can allow special rights be consigned from the GDI session owner to the user in whose procuration the GDI request was sent to qmaster. Imagination is this would require a general enhancement of SGE certificate schema. Yet as of now there is no real conception how this schema enhancement had to look like and it is therefore unclear whether it could be accordingly implemented at all. (2) Do a small code modification in qmaster where GDI session user and GDI request user matching ist done (i.e. sge_security_verify_user() and/or sge_security_verify_unique_identifier()) in a way that procuration is generally allowed, but only if the GDI session user could be verified as "root" through a certificate at the time when the GDI session was opened. (3) Accept the patch as it is and therefore mention in the release notes and the drmaa_attributes(3) man page, that "drmaa_submit_as_euid" does not function as of now. In addition a bug would be filed against "drmaa_submit_as_euid" to make sure this feature gap is not forgotten. In my opinion all three options could be justified. ------- Additional comments from andreas Thu May 8 09:00:02 -0700 2008 ------- Defered to a 6.2 follow-up version. Had needed more closer cooperation amongst different stakeholders for getting it into 6.2 beta. |
|||
#495 | fixed | IZ2530: execd: "ptf complains: Job does not exist" message in log file | jogoodma | |
Description |
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2530] Issue #: 2530 Platform: All Reporter: jogoodma (jogoodma) Component: gridengine OS: Linux Subcomponent: execution Version: 6.1u3 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: DEFECT Target milestone: --- Assigned to: pollinger (pollinger) QA Contact: pollinger URL: * Summary: execd: "ptf complains: Job does not exist" message in log file Status whiteboard: Attachments: Issue 2530 blocks: Votes for issue 2530: 5 Opened: Thu Mar 20 08:32:00 -0700 2008 ------------------------ This issue may be a duplication of http://gridengine.sunsource.net/issues/show_bug.cgi?id=1806. I'm seeing the same type of warning messages. In the execution host messages file I have: reaping job "54988" ptf complains: Job does not exist and then 1 second later in the qmaster file I have: "job 54988.1 finished on host <hostname>" I can reproduce the problem using the sleeper.sh script similar to what is described in 1806. Setting the sleep time to 1 doesn't result in any warning messages. The jobs do complete normally with correct output; however, every couple of weeks I will experience a complete queue lockup. Jobs will be shown as running but nothing is running on the exec host. Killing the jobs removes them from the queue but the next jobs that fill the slots get stuck in the same manner. Restarting SGE is the only solution I have found when this problem occurs. No other error messages have been observed in the logs to indicate a separate problem. I've have reproduced this with a single master/exec host setup running RHEL 5 and a separate master and exec host setup with both hosts running RHEL 4. All setups were tested with fresh installs of 6.1u3. |
Note: See TracQuery
for help on using queries.