Solaris permission problem(newbie)

[Mike Bilow]

On Fri, 28 Apr 2000, Jerry Feldman wrote:

> I generally do not use Solaris, but I had forgotten about the 't' bit for the 
> temp directories. I therefore stand corrected. 

This applies to any system and any directory which is world-writable.  The
only reason for not using the "sticky" bit in such a case is where the
operating system simply does not support it.  Since the "sticky" bit is an
informal convention and not part of POSIX, there may be systems which do
not honor it or which make it switchable for strict POSIX compliance.

> While /var is normally expected to be local, on a cluster or dataless 
> system, it will be exported and shared. If shared, there are many files 
> that are node specific, so the host OS must be able to allow /var to be 
> shared (between systems) with some files and directories to be specified 
> as node-specific. Additionally, some subdirectories on /var are normally 
> shared on large systems. /var/spool/mail is commonly NFS exported by 
> the central mail server, but /var/mqueue is normally local. Gets 
> complicated. 

The principle is that /var should be local.  Before /var existed, we had
/usr/tmp, /usr/spool, and so on.  If your intent is for the mail inbound
to be shared, then it should be /usr/spool/mail, not /var/spool/mail.  On
most systems, the cananoical mail inbound (/usr/spool/mail) is actually
just a symbolic link to /var/spool/mail, but this need not be the case.

The original reason for sorting the Unix tree like this was because disk
storage came in two flavors: fast and large -- choose one.  The /usr
volume was intended to be on the large, slow disk.  The /bin and /etc
volumes were intended to be on the small, fast disk.

-- Mike


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).