Date: Fri, 25 Jan 2002 05:39:18 -0600 From: "Mike Meyer" <mwm-dated-1012390758.50933b@mired.org> To: Brad Knowles <brad.knowles@skynet.be> Cc: chip <chip@wiegand.org>, freebsd-chat@freebsd.org Subject: Re: Bad disk partitioning policies (was: "Re: FreeBSD Intaller (was "Re: ... RedHat ...")") Message-ID: <15441.17382.77737.291074@guru.mired.org> In-Reply-To: <p05101242b876db6cd5d7@[10.0.1.3]> References: <20020123114658.A514@lpt.ens.fr> <20020123124025.A60889@HAL9000.wox.org> <3C4F5BEE.294FDCF5@mindspring.com> <20020123223104.SM01952@there> <p0510122eb875d9456cf4@[10.0.1.3]> <15440.35155.637495.417404@guru.mired.org> <p0510123fb876493753e0@[10.0.1.3]> <15440.53202.747536.126815@guru.mired.org> <p05101242b876db6cd5d7@[10.0.1.3]>
next in thread | previous in thread | raw e-mail | index | archive | help
Brad Knowles <brad.knowles@skynet.be> types: > At 9:24 PM -0600 2002/01/24, Mike Meyer wrote: > > Instead of having one moderate-sized thing that will create havoc on > > your system if it runs out of space, you now have two smaller things > > that can separately run out of space and create havoc. In other words, > > you've just doubled your chances of something creating havoc. > I disagree. There is no change in the probability of > programs running amok, what I have done is to partition the types of > amok-ness that can happen, and keep /var/tmp-filling amok-ness from > interfering with programs that may need to write to /var/log, and to > keep /var/log-filling amok-ness from interfering with programs that > may need to write to /var/tmp. That's a different issue from keeping /var, /usr and / separate. I actually do that by linking /var/tmp to /tmp, and mounting /tmp. That solves all the problems of what to do about /tmp if it's symlinked to /usr/tmp (which doesn't exist on my systems). If I'm expecting core dumps, I symlink /var/crash to someplace that isn't on any of the file systems in question. > If anything, by putting them on separate filesystems, I think > I've reduced the probability that the system will be seriously hosed > if a program runs amok, and if a program does run amok the damage > will be contained to a smaller portion of the directory structure. All you've really bought over what I do is that /var/log is partitioned off from everything else. The only other thing on the server is the mail gateway, which is qmail. So I guess someone could mailbomb the server and cause various things to stop logging. But it's a gateway, so the mail hits the disk and is sent on, which means your DoS has to do it with one message. But as soon as qmail realized that it had run out of space, it would return a temporary error and free the space back up, so basically no harm is done. Likewise, if the log files ran things out of space, qmail just starts returning temporary failures, so once again, no harm is done. It seems like all those extra partitions aren't providing any extra protection - at least for the server I've got here. On the other hand, as the various things in that slowly creep up in size, I won't have to deal with it until the total space allocated is gone, whereas you'll have to deal with it as soon as any one of them runs out of space. > > Actually, you don't need a separate /usr/local to mount /usr > > read-only. If you read my description carefully, you'll see that I do > > that. All you need is a fixed set of things in /usr/local. > True enough. And maybe once you've gotten systems stable > into production with no further changes planned for a long time, you > can do that. In my experience, things frequently change in > /usr/local on the systems I've managed recently, and while /usr could > be mounted read-only, it would not have been feasible to mount > /usr/local as read-only. In my experience, that's true of workstations, but not servers. Then again, I make sure that data files that need to change on servers are configured to be outside of /usr/local, just to avoid that problem. > > > When programs run amok, they run amok fast enough that *no* > > > amount of disk space is likely to give you enough additional time to > > > notice what's going on and to fix it. I've blown disk space > > > partitions that were in the tens of GB as a result of programs > > > running amok, and if I hadn't segregated them onto separate > > > filesystems, the entire machine would have been hosed. > > Tell me, what didn't quit working that putting /var and / on the same > > fs would have made quit working? Or possibly these were user programs, > > and were segregated from the system file, which I do believe is a good > > thing? > I try to run everything I possibly can as an unprivileged > user account, preferably in a chroot() jail. Logging output either > goes to syslog, or is otherwise directed to a suitable place in the > logging filesystem. Either way, the log filesystem filling up will > only prevent other programs from writing to the log filesystem and > not interfere with anything else. So what does this have to do with the case where you've blown 10s of GB vs. / and /var being on different file systems? <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15441.17382.77737.291074>