Manoj Srivastava writes: > > I have a technical reason for wanting mail in /var/spool as > well. I have things in /var/spool that tend to grow to huge sizes (as > does /var/log, but I live with that). > > I genrally have /var/spool on a separate partition, and > generally have different policies for /var/spool that I do for /var > in general (I have news, mirrors, and mail -- the major uncontrolled > external data feeds feed into /var/spool/ partition). > > Personally, I am inclined to have /var/spool/log and have all > my unknown data size stuff be in the /var/spool partition, but I know > that is unlikely to fly.
Please correct me if I'm wrong, but as I understood it, the FHS was directed at distribution maintainers/integrators, so as to help them turn out a coherent distribution, compatible with industry practice, and also at application maintainers, so as to help them turn out an application that drops cleanly in to any distribution (or more ambitiously, any variant of Unix-like OS). I was also under the impression that it was not meant as gospel for individual site or system administrators. Just as users tweak their user environment so as to better meet their needs, we expect syadmins to tweak the setup of the boxes they administrate so as to better meet their needs. And I (at least, I hope many on the list feel the same) expect that frequently this will bend or even break FHS recommendations. That's fine -- it's on a per site basis. It's the local syadmin's prerogative to change whatever they want and their job to make sure nothing breaks because of it. If it makes sense for your site to store logs in /var/spool/log and you want to make a symlink /var/log -> spool/log , then that's great. It's your box, do whatever is most practical for you. As I see it, what we're trying to do here is influence, over time, the direction distributions and applications are going in terms of file location, and most definitely not mandate an overnight change for all installed sites. I just hate getting mired down in these "it doesn't work for my site" arguments. No one layout is going to be best for every site. We want a happy medium, a least-squares minimization of all the problems that could crop up in all the myriad individual installation situations, if you will. This makes for the aggregate least effort to customize out the local problems or desires of each individual site. This doesn't mean "it doesn't work for my site" is an entirely invalid post. Obviously, if everyone with a FHS-compliant system were to say that on one particular topic, then we've chosen the wrong solution. But a handful of "it doesn't work for my site"s does not an argument make in and of itself. Don't stress so much over changing your system setup right now. Relax. Have a virtual beer. When you upgrade to a newer distribution, or a newer version of the relevant software package, and the newer version happens to follow a more recent FHS recommendation that's different than the previous version, just change then, while you're monkeying with the system anyway. Or not. Or just customize around it to make your old setup work with the new software. It's your site; do what you want to do. If I'm way out in left field here, folks, please end the inning and bring me back to the dugout. --------------------------------------------------------------------------- Carl Miller ([EMAIL PROTECTED]) Software/Firmware Engineer System Design Group 9530 Padgett Street, Suite 109 San Diego, CA 92126 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
