partition advice

I'm about to install FreeBSD (again). The box I'm using has a 2.1 and an 8GB and was wanting suggestions on how best to partition them.

That depends on what you're going to install on it. Please provide a list of services/daemons plus the estimate traffic on each. In addition, how many users? How fast Internet connection? Other hardware components such as RAM, CPU and type of disk could also be a major factor for partition space allocation.

Hardware:

Athlon K6-III 400
256 MB RAM (will be upgrading to 512)
Disks are both EIDE
CD-ROM
3C905-TP 10/100

Internet connection via router/cable modem 1500/128K

Services:
Apache
PHP
MySQL
PostgreSQL
JSP
SSH
FTP

The box will be used for development. I will be accessing via both LAN and remotely. The remote locations have fixed IPs so I'll be limiting connections to those. The router will pass relevent port requests to my cable IP address to this box.

Any non-SCSI disk including ATA100 has a poor performance on disk I/O speed. Based on the services you will be running, create a /var/db and /var partition. This isolates logging and databases. Note, pgsql's HOME is set to /usr/local/pgsql by default. With above dedicated /var/db partition, you should change its HOME to /var/db/pgsql at post-install. Putting a directory under /usr/local violates BSD's path layout rule -> heir(7).
Next, create a unique partition like /www for Apache. The default places your docroot to /usr/local/www/data which is plain bad for performance wise.
You say FTP, say it's as a file server for anonymous access, you then should create another unique partition. Or else leave the default settings.

Here is how much space I would allocate to each partition:

/dev/ad0s1a / 100M
/dev/ad0s1b SWAP 1024M
/dev/ad0s1e /usr 4G
/dev/ad0s1f /var 100M # logs rotated by newsyslog should be moved to /opt/*
/dev/ad0s1g /var/db 1.5G
/dev/ad0s1h /www 1.5G
/dev/ad1s1e /opt 2.1G's disk for backup or file server

>> The remote locations have fixed IPs so I'll be limiting connections to those.

Trust nobody and IP Address can always be spoofed. So setting IPSec with transport-mode (non-VPN) is almost a must.

Hey freebsd, why no /tmp?

Because /tmp should be a directory under your / partition. Start here -> http://forums.devshed.com/showthrea...31402&forumid=5

Oddly enough, the book that came with my boxed copy of FreeBSD mentions symlinking /tmp to /usr/tmp in two places (pages 87-88 and 229). The reasons given are as follows:

1. Since most processes that create temporary files write to the /tmp directory, this avoids writing to the root file system. Quote from the book: "If you have a small root file system with only enough on it to get the machine running in single user mode, you can subsequently recover the /usr file system relatively easily. If you also almost never write to your root file system, the chances of damaging it are remote." So the reasoning behind symlinking to /usr/tmp is to avoid writing to the root file system as much as possible.

2. The files in /tmp may become large and fill up the root file system.

The book mentions that programs that create large files should create them in /var/tmp rather than /tmp. But it also notes that unfortunately, the location of temporary files is usually not in the user's hands.

Incidentally it also says that while it is tempting to link /tmp to /var/tmp, this is a bad idea. The reason is that the contents of /tmp may be cleared by the OS after a reboot, whereas the contents of /var/tmp will remain.

Thoughts anyone??

Well, we have a RAID utility that I don't consider mission critical, but one that can greatly accelerate RAID rebuild times, and offers advanced diagnostics and autorebuild functionality. Unfortunatley, it needs 40MB of temp space in /tmp to run.

Today I was playing around with the RAID, and messed up its partitions. Even though these are on a separate controller from our boot disks, it did drop into the single user scenario freebsd mentioned in the other thread, where you could not mount the other partitions. / was the only one that was mounted.

On the other hand, we can't get by with a 128MB / , and still use it for temp space, it's just too small. My other options include increasing the size of / to 256, creating a separate /tmp, or sym linking it to somewhere else like /var/tmp or /usr/tmp.

This FreeBSD tuning manual actually says to link /tmp to /var/tmp:

http://apollo.backplane.com/FreeBSD.old/tuning.html

I also noticed the 4.5 default install will create a separate 256MB /tmp.

There seems to be alot of differing opinions both ways.

Here is freebsd's advice from the other thread.

>> the book that came with my boxed copy of FreeBSD mentions..

Personally I don't care what the books say, they ain't perfect anyway. If I have a need for a large /tmp directory I'd mkdir a ./tmp dir under /usr/local/tmp or perferably /var/tmp, just to isolate that from the system-wide /tmp directory. Like mysql and mod_php, you can always change that to another directory other than /tmp directory. I just don't think it's a wise decision to mess with /tmp directory at all.

Whilst we're covering the issues surrounding where to mount various fs hierarchies and directories, what is the overhead involved in:

Sorry if this is a naive question, perhaps it has to do with security in a full-time multi-user environment/locking down ro / partition on a production server etc etc???

Interesting thread.

Okay freebsd you have won me over.

Mounting a separate /tmp is a dangerous thing indeed, I have seen this firsthand.

The error I was experiencing with lack of temp space was actually a remote X error. The error was confusing me because it was complaining about being unable to create a file in the /tmp directory. But that was because I was logging into the X desktop through VNC, and not on the console. Not only that, the documentation for the application in question mentioned that it needed 40MB of temp space or it would not run.

I will check through my core apps and make sure none of them do excessive writing to the /tmp directory.

Hey, is there any tradeoff for rerouting an application's temp space from to /tmp to say, /usr/tmp? (I was thinking that since /usr/tmp is usually on a large partition and not close to the edge of the disk, there might be a performance tradeoff, though temp files are not constantly being hammered on like normal files).

>> what is the overhead involved in ln -s /home/root /root

If /home is a dedicated partition, you can't do that because /root should be part of / partition.
If /home is already a symlink from /usr/home, you also can't do that.

>> rerouting an application's temp space from to /tmp to say, /usr/tmp?

I think that's a very common practice but I'd use /usr/local/tmp or /var/tmp, not /usr/tmp though.
Like I said, 100mb in / partition should be more than enough for any type of server/desktop setup. If a particular application alone uses 40mb of temp space, recompile/reinstall it and change that tmp dir to somewhere else.

Just wanted to add something here though this thread is old, but this is the first time I've browsed through these forums...

Anyways could someone please enlighten me how you could loose data by having a separate /tmp partition? When you boot into single-user mode nothing should write anything anywhere and you can always mount /tmp by hand before doing anything.

Before you mount your partition under /tmp, /tmp will only be a part of your root parition and if some program needs it that's not going to be a problem. You wont loose anything important if you loose your /tmp partition as you can always reformat it (as there shouldn't have been anything there anyway after you rebooted).

I myself always have a separate /tmp partition just because I want to have every place on my harddrive writable by users mounted with nodev,nosuid and noexec too on many systems. If /tmp is a part of root, then you can't do this (as you'll have binaries with the suid/sgid bit set under /bin & /sbin). I know using these flags wont really protect your system, because you need root to create a suid root file... although they can help against really clueless people (though if they can break root, then the admin is pretty clueless too). Anyways this combined with denying all normal users access to /sbin and /usr/sbin and moving all sgid binaries to /sbin and /usr/sbin and limiting access to all suid binaries to admins only, gives you a pretty secure box (though a few binaries like passwd needs to be accessible by everyone).

This is basically how I've used to install servers like the shell box of my university's computer science guild. And we've managed to run the box for a year without being affected by any local exploit (running OpenBSD), though the OpenSSH vulnerability was a problem to us.