RE: HDDs dividing rules
Behalf Of Peter Rosa said: Hi all, Everywhere I looked, I found only words as make your own choice of partitioning schema etc., but I think, there must be some rules. How you define your partitions and what mount flags you use is very much dependant on what you're using the box for. Only you can make this descision. And what if I have an HW RAID controller. Are there some difficulties or differences from normal dividing ? Nope. Tell us, please, something like Divide your HDD as follows: 1. create slices for /, /home, /etc .. It's good because Making a slice for /etc is a 'bad' idea. Kernel can't read all the rc scripts if they're not on root slice - not to mention /etc/fstab (thus not being able to find any other slices to mount). 2. mount / as RO.. This will do a pretty good job of making it impossible for anyone to change their pass (as /etc has to be on root slice) 3. mount /user as noexec+nosuid... If by this you mean /usr, this will break just about every application on the system (most binaries that aren't essential to core system live in /usr/(s)bin (or /usr/local/(s)bin if you install stuff yourself). A lot of these need to be suid/sgid too. I think hope these rules are well-known, but one must know where to look for Nope. Every box I setup has different slice schemes - its very dependant on the usage. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HDDs dividing rules
Hi,
Hi all,
please, could you explain for those of us, who are new to Unix,
are there some rules for partitioning of HDDs in accordance to
security needs ? I know, I can set nosuid+noexec on whole
partition (slice ?), I can mount something as read-only...
It's everything fine, but what exactly should we do ?
There are no specific rules on how you divide up your disk.
It really depends on how you will use the system. What you
need for a system only you will log in to is vastly different
from what is needed for a web site server. And that is completely
different from what you need for a system where you provide
accounts for users to log in. Plus partition sizes will depend
some on how much disk you have available.
As for security settings and procedures, the same is pretty much true.
But for each there are some minimal good ideas.
Just a note first: You seem to express a little confusion about
partition vs slice. That is a frequent problem because the
Microsoft does not follow the UNIX terminology. FreeBSD UNIX
has slices that are subdivided in to partitions. MS uses the
word partition to mean the same thing a UNIX slice then comes up
with an 'extended partition' scheme for other divisions.
Each disk can be divided in to as many as 4 main slices. Each
disk can have a Master Boot Record (MBR) that manages the boot process -
mainly allowing you to select which slice to boot from. Each slice
can have a boot block and be considered bootable. The MBR selects
a slice and transfers control to the boot block (also called a boot
loader) on the slice to continue booting.
Each UNIX slice can be divided in to as many as 8 partitions.
These subdivisions called partitions are what get mounted as
such things as '/' '/tmp' '/home' etc.
If you have two disks, each can have 4 slices and each slice can
officially have 8 partitions.
One additional note, though. By convention and expected in some
programs, some of the partitons have special uses. The '/' file
system must be an 'a' partition on a bootable slice (although the 'a'
partition doesn't have to be mounted as '/' if the slice is not the
one being booted), the 'b' partition on any slice is used for swap,
the 'c' partition is used to identify the whole slice and is otherwise
unused, the 'd' partition used to have a designated use, which now
seems to be defunct, so the 'd' partition is unused and finally
the 'e' partition is often used for '/tmp', but doesn't have to be.
So, although it is possible to divide the slice in to 8 partitions,
some of the labels ('b', 'c', 'd') are not really available making
an effective 5 partitions and on a bootable slice 'a' needs to
be root.
When you partition your FreeBSD disk slice[s] you need to make
a root file system that is large enough to hold everything
needed for bringing up the system before other stuff is mounted
and running. There is a lot of dissagreement on how much is
right because it depends a lot on what you include and what you
farm out to other file systems (partitions). You can probably
make a root system with as little as 50 - 100 MBytes if you put
most everything somewhere else. I am a little less hard core and
make one about 350 MBytes and only put /var, /usr/local and /usr/ports
somewhere else. But, convenience rates a little higher than super
maximum performance for most of my machines.
Secondly, you need some swap space. The convention is that it
should be 2 to 2-1/2 times the size of your ram, but people are
rethinking a little with the much bigger memory sizes we have nowdays.
Third, you need some tmp space. Some people put that inside some
other partition. I make a /tmp file system for it with size depending
on types of use, running from 200 MBytes to around 500 MBytes. At
least you do NOT want this to be in the roo partition because it can
suddenly grow and cause trouble with root. Plus, it must be
writable by any process that uses the machine.
Then you need some place for other things that grow such as /var.
user home directories, /usr/local and maybe /usr/ports and maybe
even /usr/src.
People treat these in different ways - sometimes making separate
partitions (File systems) for them or putting them in some big
file system and making links.The way I do it is to make
partitions for '/', '/swap', '/tmp' and a very large '/home'.
Generally '/home' takes up all the rest of the space.
Some people make that very large partition be the /usr file system
and put their user home diretories in there (typically in /usr/home).
Some even make a '/user' file system in addition to '/usr' but
that is entirely tooo messy for me.
I put all user home directories, plus /var, /usr.local, /usr/src
and /usr/ports in to it with soft links to them. That way they
can grow up to the size of /home for a short while if needed and
it gives me time to notice and whack down whatever is growing too
fast for some reason (whack down can mean fixing a
Re: HDDs dividing rules
On Saturday, 2 August 2003 at 13:06:52 +0200, Peter Rosa wrote: Hi all, please, could you explain for those of us, who are new to Unix, are there some rules for partitioning of HDDs in accordance to security needs ? I know, I can set nosuid+noexec on whole partition (slice ?), I can mount something as read-only... It's everything fine, but what exactly should we do ? I'm appending a section from The Complete FreeBSD which goes into some detail about this question. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers Defining file systems _ The next step is to tell the installation program what to put in your FreeBSD partition. First, we'll look at the simple case of installing FreeBSD by itself. On page 75 we'll look at what differences there are when installing alongside another operating system on the same disk. When you select Label, you get the screen shown in Figure 5-8. [Omitting PostScript image images/disk-label-0-a.ps 4i ] Figure 5-8: Label editor menu What partitions? In this example, you have 20 GB of space to divide up. How should you do it? You don't have to worry about this issue, since sysinstall can do it for you, but we'll see below why this might not be the best choice. In this section we'll consider how UNIX file systems have changed over the years, and we'll look at the issues in file system layout nowadays. When UNIX was young, disks were tiny. At the time of the third edition of UNIX, in 1972, the root file system was on a Digital RF-11, a fixed head disk with 512 kB. The system was growing, and it was no longer possible to keep the entire system on this disk, so a second file system became essential. It was mounted on a Digital RK03 with 2 MB of storage. To quote from a paper published in the Communications of the ACM in July 1974: In our installation, for example, the root directory resides on the fixed-head disk, and the large disk drive, which contains user's files, is mounted by the system initialization program... As time went on, UNIX got bigger, but so did the disks. By the early 80s, disks were large enough to put / and /usr on the same disk, and it would have been possible to merge / and /usr, but they didn't, mainly because of reliability concerns. Since that time, an additional file system, /var, has come into common use for frequently changed data, and just recently sysinstall has been changed to create a /tmp file system by default. This is what sysinstall does if you ask it to partition automatically: [Omitting PostScript image images/disk-label-default.1.ps 4i ] Figure 5-9: Default file system sizes It's relatively simple to estimate the size of the root file system, and sysinstall's value of 128 MB is reasonable. But what about /var and /tmp? Is 256 MB too much or too little? In fact, both file systems put together would be lost in the 18.7 GB of /usr file system. Why are things still this way? Let's look at the advantages and disadvantages: o If you write to a file system and the system crashes before all the data can be written to disk, the data integrity of that file system can be severely compromised. For performance reasons, the system doesn't write everything to disk immediately, so there's quite a reasonable chance of this happening. o If you have a crash and lose the root file system, recovery can be difficult. o If a file system fills up, it can cause lots of trouble. Most messages about file systems on the FreeBSD-questions mailing list are complaining about file systems filling up. If you have a large number of small file systems, the chances are higher that one will fill up while space remains on another. o On the other hand, some file systems are more important than others. If the /var file system fills up (due to overly active logging, for example), you may not worry too much. If your root file system fills up, you could have serious problems. o In single-user mode, only the root file system is mounted. With the classical layout, this means that the only programs you can run are those in /bin and /sbin. To run other programs, you must first mount the file system on which they are located. o It's nice to keep your personal files separate from the system files. That way you can upgrade a system much more easily. o It's very difficult to estimate in advance the size needs of some file systems. For example, on some systems /var can be very small, maybe only 2 or 3 MB. It's hardly worth making a separate file system for that much data. On the other hand, other systems, such as
