I normally use
/
/usr
/usr/local
/var
/tmp
/home # or /usr/home
/usr/ports # either it's own space, or link to /usr/local/ports
Here's the rational, / and /usr can be mounted read only, /root
shouldn't really get used, since you shouldn't be using the root
account. when you update the source and rebuild the system then you can
remount read-write. /usr/ports points to /usr/local/ports so it can be
read-write as needed. /var has logs that can get out of hand, and /tmp
gets out of hand due to all sorts of user/programer tricks that you
never count on. Those can be read-write at all times.
I haven't sized these in a while since well, I've got disk space like
it's going out of style, but 128 megs for /, and 512 for /var and /tmp
are good sizes. /home is as needed. The only question is how much you
really need in /usr which is probably somewhere around 1 GB, depending
on if you need to build sources on that system or not.
For the security concious, if /usr is read-only at all times (except
when mounted from single user mode) you can be more at ease leaving suid
programs there, and disable suid from /usr/local, not that you would
never have a problem, but... Also, having /etc/ ro is nice, but none of
that is a good substitue for tripwire or the like.
--
Michael Conlen
Richard Johannesson wrote:
Using the unlimited number of sub-disk that can be created using vinum,
what's a good way to separate the directory file structure to help limit
file system corruption? Or, what's the happy medium between limiting fs
corruption and complexity?
Here's my guess of which part of directory structure should be on its own
sub-disks/filesystem:
/ Probably
/root Overkill?
/usrProbably
/usr/local
/varProbably
/var/backups?
/tmpProbably - or should be on same as var?
/home Maybe - or should be under /usr?
/stand ?
/boot ?
Any feedback is very much appreciated. If there is document that discusses
this basic topic while taking vinum into account, please let me know so I
can bugger off. :)
Thanks again,
Richard
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
