On Thu, 25 Jul 2002 09:25:40 +0200, Evgeny Limarenko <[EMAIL PROTECTED]> wrote:

> Let's see. If your /tmp filesystem is getting full...

[Snipped: summation of an age old problem.]

> With the /home it's the same story... 

[Ditto]

> It's not just my speculations, it's my expirience. I've been working
> in big and small servers around me environment for about seven years.
> Every now and then I have a situation when I have to move data
> from one partition to another to cope or to prevent 'not enough free space'
> problem. Sometimes it means a complete reboot, other times it means
> certain amount of calls from users. And almost everytime the decision
> is made in haste, without proper preparations and thinking.

    Yep, until 2 years ago, this was strictly my policy as well.  Nothing ticks me off 
more than having to bring down a system with an uptime of a year or more, just because 
someone wants to park some files someplace and it 'can't' be moved.  It's a simple 
process, just annoying;  do the hardware step, copy the too-small directory to a new 
drive (if your boss will allow it) and mount it where it used to be.  But then you 
have another partition that's not being used, and it's not simple to resize'em.  Sure, 
there's FIPs, but I don't want to risk nuking a partition to add it, ya know?

    If anyone's had experience with this (good or bad) please let me know.

    But in the last two years I learned the reason why some people gripe and complain 
about this policy: let me share with you what I learned.  If it's for my own machine, 
screw it: I'm not messing with the durned partitions- it's gonna be almost completely 
/ and /boot (until the newer lilo is widely available) and swap.

    There are also occaisions where you're using massive drives; i.e. more than 80G 
still isn't enough.  Grafting multiple drives works well here, just based on the 'real 
estate' alone.  However there's another, really good, strong reason to over-partition: 
 security.  If you mount /home, for example, onto a seperate partition or drive, you 
get to specify that this partition can't allow device files (like young hackers like 
to try) nor will it allow SUID files to be effective there.

    I'm told this is also a great thing to do with /tmp, too, for the same reason: 
almost anyone can access /tmp.

    But putting /opt,  /var, or /usr (or whatever) onto seperate drives merely for the 
idea of making a recovery easier, well, it's about an even bet.  I tend to run servers 
with RPMs only, no tarballs to track down or looking for anything special that happens 
when you type "make install" as root.  So rebuilding a root partition is pretty easy 
for me- it's just the /home partition that becomes important.

> > 
> > So "it depends".
> > 
> > My own system has separate partitions for /home, /tmp, and /boot. This handles
> > my own particular concerns. I am not concerned with hacking or reliability per
> > se, but with my users (my family) dropping big files in /tmp and /home (where
> > they have mounts from Windows boxes). So having these separate partitions
> > protects my system against that. If I did a lot of development I would have a
> > /var partition too. If I had bunches of (potentially) hostile users I would
> > follow other recommendations on partitions too. The downside is that these
> > different partitions all reduce flexibility and when you run out of space on a
> > partition and need to increase its size, it is very inconvenient to get around
> > that. And having every partition with oodles of unused space really wastes
> > disk space. I have SCSI disks so this is an issue for me. With IDE who cares,
> > disks are so cheap these days - just get a bigger one.

    Whoa, chief:  Don't share your /tmp.  It's bad news.  The "right" way to do this 
is to have Samba use usernames and everyone owns thier own files.  And when they are 
public, make them something read-only if it's the slightest bit important.

    One day our company's purchaser downloaded a virus.  He was attached to my Linux 
box at the time, where I offered MP3 files for the local crew.  Hey, it's so much 
better than Musak.  The virus did other things, but the important thing was removing 
.com .exe and .mp3 files.  His machine was gutted like a fish.  My machine, safely 
marked a=r on the mp3's, was untouched.  Keep this in mind: the user may not want to 
erase files on your system, but Microsoft doesn't know the difference- everything runs 
as root, and there are no alternatives. (I'm aware of NT and the others.)

    Just keep this in mind; share publically only what you're willing to lose...or 
make it private to a user, aye?

> > If you are an institutional user, err on the side of safety. Better to have
> > less usable disk space than to lose a system. If a personal system, make your
> > life easy and have the minimum number of partitions to protect you against
> > reasonably forseeable boo-boos.
> > 
> > NEVER fill up your root disk. This really leaves you in a ditch.
> > 
> > This advice worth what you paid for it :-)

    Well, it's certainly not worthless; the sweet thing behind Linux and OpenSource is 
that we're allowed to share information, and programs, and elevate the useful parts of 
each to prominence, while letting the crappy stuff sink to the bottom....and we get to 
decide which is which, not a focus group in Redmond.

    Hey, did you see that "meetup" has a linux contingient?  See 
http://linux.meetup.com.  These places are great for swapping information.

------------------------------------------------------------------------
Brian Fahrländer              Linux Zealot, Conservative, and Technomad
Evansville, IN                    My Voyage: http://www.CounterMoon.com
ICQ  5119262
------------------------------------------------------------------------
I don't want to hear news from Isreal until the news contains the words
"Bullet", "Brain", and "Arafat".


-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.openprojects.net

Reply via email to