tallship

[Log in to get rid of this advertisement]

Let's get real here buoys and gulls,

The reason why you create separate partitions is to minimize the effects of hammering one of them. If you whack var because your log rotations aren't tuned correctly, then you lose your logging capabilities until you clear out some space. There are other reasons of course, but bad systems administration is no excuse for having to separate file systems in order to avoid problems.

The real advantage, is to move things, later when you need to.

And it's no substitute for watching your /usr or /var partitions' usage.

For example, /home is *somewhere* and you want to move it to a NAS volume somewhere that exists as an NFS mount - great! that NFS mount exists as a storage repository on a NAS volume which houses the mount points for 17 of your servers' users. No Problemo Constanino! Your particular UNIX system doesn't really care where your users' home partitions are, as long as the names of those users are unique.

So you hammer a box! or it is rooted. Guess what? all is well in userland coz their 'stuff' is still there, and you ca rebuild any machine and point to that resource to gain them access to their own files.

Or let's say that you want to combine all the log files for 375 different systems on a mount point that handles nothing but logging - /var/log/blah/blah/blah exists on that NAS box!

nuff said

tallship

Read this dudes post three times, and then you'll come to the realization that he's spot on.

/

/SWAP

for 87.35926% of the people installing UNIX, that's all you need to (or should)do!

Pupil

some really thoughtful info from true 'geeks'. I lucked out on this question (and I'm sure will help many others for long time to come). Thanks so much!! I've been elected for this as I have the 'most' computer knowledge, which is actually limited to admin./win security(HA!). No way we can hire anyone yet and not for some time.

I had gone back to ext3 when partitioning kept crashing, just to be sure ... but there's a lot more food here for thought. Let me take another look. Another idea I liked for more partitions was setting some 'read-only'.

I'm going to use the desktop as a server just to get started (don't laugh!), first year. I've been told that can be done ...and it won't hurt too much if it goes down; I'll have 3 other computers always running to load the crm/accounting backup on and the site is really just a 'perk' thus far altho we hope for it to automate some of our manual labor (most of our line of work has historically been by phone and in person, which is really what sets us apart ... but a site is more and more necessary for 'confirmation' and CYA, and good for prospects who'd prefer to get started themselves, and being able to write business out of state one day would be cool). I'll have the (stationary) laptop set up right next to the desktop; guess I'll learn to turn to it to do personal work.

MUCH appreciated, the insight from those who know. Thank you!! Let me go back and study it all. Maybe I need to move &/or break up that swap ... and I think I had where stuff s/b on the disk backwards ... hmmm.

CentOS, huh ... I started to look at that but saw it wasn't all free, which we need to get started ... and after my laptop struggling terribly with Fedora since Jan., I was starting to feel like a Guinea Pig, and looking for 'easy'. Let me peruse that ...

tallship

I won't. And what you're going to find out is that although it's against all of the *prudent* schematas, that machine will serve you very well as both a server and a workstation

Just don't forget that it's a mission critical machine.

Yeah, IMNSHO, Redhat is for bozos - and that includes Fedora. CentOS is good stuff though, if you are commercially minded and are going to be licensing things like cPanel and WHM that will cost you a bundle. It's a solid distro for a Linux OS, and prolly the best (again, IMNSHO), if you are insistant upon using an RPM based distro.

The problem with RPM based distros, as I have found, is that, if you're running them as a commercial production system, and you are usiing RPMs, after about a year and a half you won't be able to find security updates for your daemons at http://rpmfind.net - so you are still plagued w/having to create your own RPMs and then installing them, as the support for your platform wanes.

Redhat won't tell you this, and they'll even require that you pay them to do something as simple as a custom kernel compile, If you try to do it yourself, you'll void your *enterprise* support contract. So what's the point of Redhat?

CentOS, on the other hand, is, by definition, something that you are on your own from the start. Again, if you're using it in *some* commercial environments, where you have licensed things like cPanel, etc..., then maybe it's an easy and straight forward way to go for a couple of years (A COUPLE OF YEARS). After that, well, you've paid for the cPanel licenses, and good luck migrating three thousand user accounts - but at that point you're going to know how to do that anyway, and will deal with it.

My personal inclination, is to only provide free support here for people that have chosen to run Slackware. No problems as the years go on, and I have Slackware boxes that haven't been powered down for 10 years + in the field.

That's my suggestion - to stay away from RPM based distros if you're expecting them to last more than a couple of years.

tallship

I would stay as far away as I can, if I were you, from Ext3/4.

/boot (20 megs) Ext2 FS

/ XFS or ReiserFS

/SWAP Linux Swap

That's my recommendation until we finish porting DragonFlyBSD's Hammer FS to Linux.

And I've been running Linux since before 1.x

Pupil

guys always crack me up. this has (and continues to be) quite entertaining, as well as informative.

Yeah, I had identified Slackware as an option but something about telling people, "I use SLACKware ..." ... I just dunno about the sound of that ... but I guess I've been sufficiently provoked to take a look.

GREAT info ... thank you for being so helpful!!!!!!!!! Otherwise, I would be ... so ... utterly ... alone(!) Nobody around here knows anything about Linux. They all look at me like I'm an alien.

tallship

And then they will say about you, "Call that alien dude. his Kung Fu is strong!".

All the best...

Pupil

Alien CHICK, hun ... alien chick. the one in the FAST car. the car so hot it deserves for you to dress to match it (haha, twenty years, son's gone, finally got another one)

Pupil

but what I really always wanted is a hovercraft. maybe not too far away ??

Smartpatrol

Everyone is entitled to their own opinion of course; keep in mind some of us like to run linux as a hobby and to be different than the Windows crowd... you know the type "look at me i run linux i am 733t!" others on the other hand (that post here) have been running either linux or commercial Unix for more than a decade for all different sorts of large to medium sized businesses sometimes with thousands of users and hundreds of servers running all different types of operating systems. Some even are solely responsible for the entire Linux environment of their global company running such things as oh i dunno business critical database servers or maybe even business critical mail gateways using the distro evidently Bozo the clown prefers to use! Then again some like to do both.

catkin

Following that line of reasoning, how about making /tmp a symlink to /var/tmp and having a /var/tmp directory on the / file system? That way, under normal conditions with /var mounted, filling /tmp does not fill / (which is less problematic?) and in maintenance mode with only / mounted the normally hidden /var/tmp on the / file system is used. Would have to ensure /var/tmp on the / file system is cleaned out while /var is not mounted, as part of the boot process.

catkin

Another factor to take into account when partition and file system planning is that there may be more than one OS and associated applications, all with their own configuration files and data. In that case it is useful to separate the file systems into OS-specific and not-OS-specific.

That way, when installing a new OS (perhaps at upgrade time), the new OS can have its own OS-specific file systems (/, /usr, /var ...) and use the common not-OS-specific file systems (/home, /srv ...).