Opened 14 years ago
Last modified 10 years ago
#419 new defect
IZ2228: Installation fails on extra-secure servers
Reported by: | mathog | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | sge | Version: | 6.0u10 |
Severity: | Keywords: | Linux install | |
Cc: |
Description
[Imported from gridengine issuezilla http://gridengine.sunsource.net/issues/show_bug.cgi?id=2228]
Issue #: 2228 Platform: All Reporter: mathog (mathog) Component: gridengine OS: Linux Subcomponent: install Version: 6.0u10 CC: None defined Status: NEW Priority: P3 Resolution: Issue type: DEFECT Target milestone: --- Assigned to: dom (dom) QA Contact: dom URL: * Summary: Installation fails on extra-secure servers Status whiteboard: Attachments: Issue 2228 blocks: Votes for issue 2228: Opened: Mon Apr 2 09:59:00 -0700 2007 ------------------------ Installation of SGE 6.0U10 failed on Mandriva 2006 and the issue was eventually tracked down to certain directory protections. Mandriva comes with a security package called "msec" which among other things sets the directory protections, and on the machine in question the security level was 4 (out of 5), which is more secure than the typical server, as this machine normally has no interactive users. As a result of these directory protections certain "rm -rf" commands in the installation script failed and the installation aborted. (Note also that `which rm` would also have failed.) To work around this I did the following (assumes perm.local does not already exist): % cd /etc/security/msec cat >perm.local <<EOD / root.adm 755 /bin/ root.adm 755 /usr/ root.adm 755 /usr/* root.adm 755 /usr/X11R6/ root.xgrp 755 /tmp/ root.adm 1777 EOD % msec This reset the protections on the directories listed from 751 to 755, and from 1773 to 1777. After this the SGE install completed successfully. [Note, these settings are probably NOT required for SGE to run, only for it to be installed. I had been running 5.3p6, copied from an earlier system, for 7 months with the older protections with no issues.] In any case, since head nodes on clusters are frequently set up with extra security, so that this situation might occur on other machines, it would probably be a good idea to have the SGE install script check the directory protections on at least /tmp, /usr/bin, and /bin to verify that the script will be able to execute. The script already has a section which checks/sets the protections on its own files, and since the script had not yet failed by that point, that's a logical place to add this. It would be much better to be notified before the fact that "this installation cannot proceed because the protection on /tmp is 1773, it must be 1776", than to run into the mysterious message which appeared on my system, replicated with discrete commands here: % su - sgeadm % cd /tmp % mkdir foo2 % touch foo2/blah % ls -al foo2 total 8 drwxrwxr-x 2 sgeadm sge 4096 Mar 30 08:11 ./ drwxrwx-wt 10 root adm 4096 Mar 30 08:11 ../ -rw-rw-r-- 1 sgeadm sge 0 Mar 30 08:11 blah % rm -rf /tmp/foo2 rm: cannot get current directory: Permission denied
Note: See
TracTickets for help on using
tickets.