Re: partitions
On 05/02/10 21:20, Matthew Dempsky wrote: On Sun, May 2, 2010 at 6:46 PM, Chris Bennett ch...@bennettconstruction.biz wrote: Well, /usr/ports is updated, but never needs to be erased unless really messed up by user error That's true of /usr/src too though, right? Here is a guess: Perhaps this is true for xenocara also. The growth rate of ports is probably fast enough to make keeping a stable partition size a problem. /usr/src's size probably grows very slowly. Of course, I could be totally wrong.
Re: partitions
On May 02 10:03:21, Cantabile wrote: Hi, I'm new to openbsd. Sorry if the question is obvious to you but I couldn't find the answer in the docs. So here it is: what is the reason why the install suggests so many different partitions? Why not simply / and /home for example? Don't just read http://openbsd.org/faq/faq4.html#Partitioning read the whole thing.
Re: partitions
Cantabile cantabile...@wanadoo.fr writes: I'm new to openbsd. Sorry if the question is obvious to you but I couldn't find the answer in the docs. So here it is: what is the reason why the install suggests so many different partitions? Why not simply / and /home for example? you actually will find the answer in the faq (very close to the url Jan posted), but I'll offer this: pe...@deeperthought:~$ mount /dev/sd0a on / type ffs (local) /dev/sd0k on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) /dev/sd0e on /var type ffs (local, nodev, nosuid) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: partitions
On 05/02/10 05:23, Peter N. M. Hansteen wrote: Cantabilecantabile...@wanadoo.fr writes: I'm new to openbsd. Sorry if the question is obvious to you but I couldn't find the answer in the docs. So here it is: what is the reason why the install suggests so many different partitions? Why not simply / and /home for example? you actually will find the answer in the faq (very close to the url Jan posted), but I'll offer this: pe...@deeperthought:~$ mount /dev/sd0a on / type ffs (local) /dev/sd0k on /home type ffs (local, nodev, nosuid) /dev/sd0d on /tmp type ffs (local, nodev, nosuid) /dev/sd0f on /usr type ffs (local, nodev) /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) /dev/sd0e on /var type ffs (local, nodev, nosuid) - P Hey, at least throw in that /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) as partitions are for convenience, not strictly necessary as partitions. You NEED to understand why, though. Besides the FAQ, read the manual pages, over and over until they start to make sense. (Eventually all will become clear.) :)
Re: partitions
Thanks, everybody! Cantabile Le dimanche 02 mai 2010 C 10:03 +0200, Cantabile a C)crit : Hi, I'm new to openbsd. Sorry if the question is obvious to you but I couldn't find the answer in the docs. So here it is: what is the reason why the install suggests so many different partitions? Why not simply / and /home for example? Thanks. Cantabile
Re: partitions
On Sun, May 2, 2010 at 4:06 AM, Chris Bennett ch...@bennettconstruction.biz wrote: Hey, at least throw in that /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) as partitions are for convenience, not strictly necessary as partitions. One thing that I'm a little curious about is why the installer by default recommends dedicated partitions for /usr/src and /usr/obj, but not /usr/xenocara or /usr/ports.
Re: partitions
On 05/02/10 20:26, Matthew Dempsky wrote: On Sun, May 2, 2010 at 4:06 AM, Chris Bennett ch...@bennettconstruction.biz wrote: Hey, at least throw in that /dev/sd0g on /usr/X11R6 type ffs (local, nodev) /dev/sd0h on /usr/local type ffs (local, nodev) /dev/sd0j on /usr/obj type ffs (local, nodev, nosuid) /dev/sd0i on /usr/src type ffs (local, nodev, nosuid) as partitions are for convenience, not strictly necessary as partitions. One thing that I'm a little curious about is why the installer by default recommends dedicated partitions for /usr/src and /usr/obj, but not /usr/xenocara or /usr/ports. Well, /usr/ports is updated, but never needs to be erased unless really messed up by user error I would like to know why the xenocara stuff stuff isn't also offered as partitions. Next time I do a full fresh install, I plan on adding xenocara partitions
Re: partitions
On Sun, May 2, 2010 at 6:46 PM, Chris Bennett ch...@bennettconstruction.biz wrote: Well, /usr/ports is updated, but never needs to be erased unless really messed up by user error That's true of /usr/src too though, right?
Re: Partitions
On Sat, Jul 01, 2006 at 09:39:28PM +0200, Joachim Schipper wrote:
Yes, but /etc/rc doesn't:
# prune quickly with one rm, then use find to clean up /tmp/[lq]*
# (not needed with mfs /tmp, but doesn't hurt there...)
(cd /tmp rm -rf [a-km-pr-zA-Z]*
find . ! -name . ! -name lost+found ! -name quota.user \
! -name quota.group -execdir rm -rf -- {} \; -type d -prune)
Well spotted, solved:
$ diff /etc/rc /etc/rc.orig
450,451c450,451
(cd /tmp rm -rf [a-km-pr-uw-zA-Z]*
find . ! -name . ! -name lost+found ! -name vi.recover ! -name
quota.user \
---
(cd /tmp rm -rf [a-km-pr-zA-Z]*
find . ! -name . ! -name lost+found ! -name quota.user \
Why I started doing this is because one night when I was working at an
ISP, I found an SSH zombie had gotten onto one of our DNS servers
(sales:qwerty).
While /tmp and /home were mounted noexec, /var wasn't, so the zombie
compiled its own list driven sshd in /var/tmp and went scanning for more
hosts.
I thought that if /var/tmp was a symlink to /tmp, there would be no need
to repartition the disk and it would stop users messing about with their
own executables in /var/tmp.
--
Craig Skinner | http://www.kepax.co.uk | [EMAIL PROTECTED]
Re: Partitions
On Friday 30 June 2006 20:45, Craig Skinner wrote: I always symlink /var/tmp to my /tmp partition and mount /tmp with: nodev,noexec,nosuid,noatime,async - as it gets wiped at boot anyway. /var/tmp is not wiped at boot. --- Lars Hansson
Re: Partitions
From: Lars Hansson [EMAIL PROTECTED] On Friday 30 June 2006 20:45, Craig Skinner wrote: I always symlink /var/tmp to my /tmp partition and mount /tmp with: nodev,noexec,nosuid,noatime,async - as it gets wiped at boot anyway. /var/tmp is not wiped at boot. -No, but /tmp is and if you symlink /var/tmp to /tmp ... I kind of like the idea.
Re: Partitions
On Sat, Jul 01, 2006 at 05:32:27PM +0100, Stefan Olsson wrote: From: Lars Hansson [EMAIL PROTECTED] On Friday 30 June 2006 20:45, Craig Skinner wrote: I always symlink /var/tmp to my /tmp partition and mount /tmp with: nodev,noexec,nosuid,noatime,async - as it gets wiped at boot anyway. /var/tmp is not wiped at boot. -No, but /tmp is and if you symlink /var/tmp to /tmp ... I kind of like the idea. It doesn't sound too bad, but might break stuff. Notably, /var/tmp/vi.recover will be removed, which is quite annoying if you use vi(1). Joachim
Re: Partitions
On Fri, Jun 30, 2006 at 01:45:15PM +0100, Craig Skinner wrote: | On Fri, Jun 30, 2006 at 12:00:12PM +0200, Tobias Weisserth wrote: | | I never understood why putting /tmp on its own partition is good when nobody | notices /var/tmp. In addition to /tmp I always put /var/tmp on its own | partition too, so that I can mount it with nodev,noexec,nosuid. | | I always symlink /var/tmp to my /tmp partition and mount /tmp with: | nodev,noexec,nosuid,noatime,async - as it gets wiped at boot anyway. Not only at boot, see daily(8) : - Removes scratch and junk files from /tmp and /var/tmp. But anyway, /var/tmp is meant to be the temporary storage area that *survives* reboots, it's actually used for this purpose, it's where vi stores its recovery files. If you ever reboot your machine when a stubborn user has ignored the warnings (perhaps wasn't at his terminal at that time) shutdown(8) sends out, he'll be able to recover his very important document if /var/tmp is not wiped at boot. I'd advise against symlinking /tmp to /var/tmp (or the other way around). Just my 0.02EUR Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/ [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Partitions
On Sat, Jul 01, 2006 at 07:40:18PM +0200, Paul de Weerd wrote: | I always symlink /var/tmp to my /tmp partition and mount /tmp with: | nodev,noexec,nosuid,noatime,async - as it gets wiped at boot anyway. Not only at boot, see daily(8) : - Removes scratch and junk files from /tmp and /var/tmp. But anyway, /var/tmp is meant to be the temporary storage area that *survives* reboots, it's actually used for this purpose, it's where vi stores its recovery files. If you ever reboot your machine when a stubborn user has ignored the warnings (perhaps wasn't at his terminal at that time) shutdown(8) sends out, he'll be able to recover his very important document if /var/tmp is not wiped at boot. Nope. I maybe just a stupid list lurking user, but I did read /etc/daily and it performs similar sanity checks on /tmp as to what it wipes. If vi is an '80's song, it would be singing I will survive! And of course I use vim, what else is there? -- Craig Skinner | http://www.kepax.co.uk | [EMAIL PROTECTED]
Re: Partitions
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Brahy Sent: Thursday, June 29, 2006 11:00 PM To: misc@openbsd.org Subject: [misc] Partitions At first I didn't understand the reason for all the partitions ( http://archives.neohapsis.com/archives/openbsd/2001-01/1654.ht ml) now I can't have enough partitions In my official OpenBSD CD sleeve it says to create these partitions: / swap /tmp /var /usr /home and over time I have learned to appreciate these, but lately I have been creating more partitions /usr/src /usr/obj are two of the ones that are suggested when rebuilding my system and I definitely like the speed of doing a newfs to /usr/obj I also have been putting mysql on it's own partition and then I got a little crazier and added more partitions and my list has grown to this: / /home /tmp /var /var/mysql /usr /usr/local /usr/src /usr/obj /usr/Xbld /usr/XF4 /usr/local /virtualhosts So am I going overboard? or am I missing any good partions. when I first posted Nick Holland replied with several reasons to have multiple partions. Those being security, fragmentation, protecting the filesystem from overfilling, organization and space tracking. does increasing the amount of partitions increase access to the files on that partition? Any feedback would be appreciated. Thanks, John well, from my point of view: if your setup or the things you load on the server needs it - have as many partitions as you want! you'll at latest will see if you went overboard, if it comes to upgrades, restores, etc... your environment has to fit your needs. i've seen machines with just / and swap, and i've seen machines where for example for the database itself have been more than 30 partitions as well. both setups were fine - for their respective needs. if it's manageable, secure and last but not least - FAST, it's fine ;-)
Re: Partitions
Hi, So am I going overboard? or am I missing any good partions. I never understood why putting /tmp on its own partition is good when nobody notices /var/tmp. In addition to /tmp I always put /var/tmp on its own partition too, so that I can mount it with nodev,noexec,nosuid. I also try to split things up in a way that I can mount many things with the ro option where there should be no changes to the filesystems unless you perform an update, patch something etc. regards, Tobias W.
Re: Partitions
* Nick [EMAIL PROTECTED] [2006-06-30 03:33]: yes, I'd say you are going a bit overboard. very slightly, if at all. nor do I see any real-life benefit to a /usr/local partition. I do, a lot. prevent 3rd party crap shit from overflowing /usr. and, that way, you can even mount /usr RO unless you do upgrades. A long time ago, I had a nice little webserver set up, then my friend Henning said, Here, try this chroot'ed Apache patch...which absolutely hosed my grand plans, as my /var partition was too small, as all the web documents were served from /home/user directories. shalalalala... :) -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: Partitions
On Fri, Jun 30, 2006 at 12:00:12PM +0200, Tobias Weisserth wrote: I never understood why putting /tmp on its own partition is good when nobody notices /var/tmp. In addition to /tmp I always put /var/tmp on its own partition too, so that I can mount it with nodev,noexec,nosuid. I always symlink /var/tmp to my /tmp partition and mount /tmp with: nodev,noexec,nosuid,noatime,async - as it gets wiped at boot anyway.
Re: Partitions
On Jun 29, 2006, at 3:00 PM, John Brahy wrote: At first I didn't understand the reason for all the partitions ( http://archives.neohapsis.com/archives/openbsd/2001-01/1654.html) now I can't have enough partitions The main advantage of partitions is that you can isolate file systems that are growing and move them to a new slice if necessary without them disturbing other file systems. The most common extra partition must be /usr/local since one tends to build open source there. --- Jack J. Woehr Director of Development Absolute Performance, Inc. [EMAIL PROTECTED] 303-443-7000 ext. 527
Re: Partitions
On Thu, Jun 29, 2006 at 02:00:17PM -0700, John Brahy wrote: So am I going overboard? or am I missing any good partions. when I first posted Nick Holland replied with several reasons to have multiple partions. Those being security, fragmentation, protecting the filesystem from overfilling, organization and space tracking. It's hard to know if you're going overboard or not. To some degree it's a matter of personal preference, but mostly it's what the system will be doing. If mysql is there only for testing, then it can live in the normal /var partition. If mysql is heavily used it should not only have it's own partition, but you should move it to another disk (and even controller). Etc., etc... The more experienced I get, the better I am at choosing what to partition seperately, and how big to make the partitions. Some of the best advice is to partition what you think you'll need and leave the rest as free space. This gives you flexibility to adapt to unanticipated needs. I usually stick pretty close to the standard slicing, which gets you nice stuff like noexec, nosuid where you need it. Then I may do more partitions like for the mysql example above. I like things fairly simple. -- Darrin Chandler| Phoenix BSD Users Group [EMAIL PROTECTED] | http://bsd.phoenix.az.us/ http://www.stilyagin.com/ |
Re: Partitions
From: [EMAIL PROTECTED] At first I didn't understand the reason for all the partitions ( http://archives.neohapsis.com/archives/openbsd/2001-01/1654.ht ml) now I can't have enough partitions An example of a problem you can run into with overpartioning is being too carve-happy. You've got a finite amount of drive space, so slicing it up all over the place means that partitions have to be limited to what they get. You add a partition, you've either got to add drive space to it or borrow it from somewhere else. People who don't partition appropriately (plan!) end up hitting 100%+ space usage and b0rk. That was an argument at my last job as for why we had to have a single, monolithic root partition on our systems. We never ran out of space on our smaller partitions, but we got no advantages from segmentation either. I endorse the OpenBSD suggested layout. DS
Re: Partitions
On Thu, Jun 29, 2006 at 02:00:17PM -0700, John Brahy wrote:
At first I didn't understand the reason for all the partitions (
http://archives.neohapsis.com/archives/openbsd/2001-01/1654.html) now I
can't have enough partitions
In my official OpenBSD CD sleeve it says to create these partitions:
/
swap
/tmp
/var
/usr
/home
and over time I have learned to appreciate these, but lately I have been
creating more partitions
/usr/src
/usr/obj
are two of the ones that are suggested when rebuilding my system and I
definitely like the speed of doing a newfs to /usr/obj
Mwah... don't go overboard. rm'ing the whole thing doesn't take a
noticeable amount of time compared to *building* the tree, if you have
softupdates enabled at least.
I also have been putting mysql on it's own partition and then I got a little
crazier and added more partitions and my list has grown to this:
/
/home
/tmp
/var
/var/mysql
/usr
/usr/local
/usr/src
/usr/obj
/usr/Xbld
/usr/XF4
/usr/local
/virtualhosts
So am I going overboard? or am I missing any good partions.
I wouldn't use /usr/Xbld and /usr/obj - if you want a build partition,
just mount a /usr/bld, mkdir /usr/bld/{Xbld,obj}, and add symlinks where
appropriate. This is more efficient, too, as you would rarely need Xbld
and obj at the same time.
Similarly, I don't see the point in having /usr, /usr/XF4, and
/usr/local.
However, /virtualhosts suggests that you don't run Apache with chroot.
If this is the case, don't do that. ;-)
OTOH, I do strive to have one daemon - or, at least, 'function' per
partition, explicitly for the reason you mention below - protecting the
rest of the system from being brough to a halt by someone filling a
partition. So /var/mysql would be a good idea, though I personally
believe /var/postgresql to be a better idea.
In this vein, you could create a /var/log - as much to prevent the
logging daemon from the rest of the /var-using daemons as vice versa,
really, as log files can grow very fast under the 'proper'
circumstances.
Depending on functions, you may want to add /var/mail, /var/www, and so
on.
when I first posted Nick Holland replied with several reasons to have
multiple partions. Those being security, fragmentation, protecting the
filesystem from overfilling, organization and space tracking.
does increasing the amount of partitions increase access to the files on
that partition?
I don't really understand what you are trying to say here... but no, the
amount of accesses to a given file is independent on the partitions it
is on, all other things being equal.
Joachim
Re: Partitions
John Brahy wrote: ... and over time I have learned to appreciate these, but lately I have been creating more partitions /usr/src /usr/obj are two of the ones that are suggested when rebuilding my system and I definitely like the speed of doing a newfs to /usr/obj Certainly handy. On the other hand...I pretty much build by script files now, so I'm not waiting for the rm -r /usr/obj/* step anyway...just start and walk away for anywhere from an hour to a week. :) I also have been putting mysql on it's own partition and then I got a little crazier and added more partitions and my list has grown to this: / /home /tmp /var /var/mysql /usr /usr/local /usr/src /usr/obj /usr/Xbld /usr/XF4 /usr/local /virtualhosts So am I going overboard? or am I missing any good partions. yes, I'd say you are going a bit overboard. On the other hand, you can make a case for most of the examples you list under some circumstances, and I don't see any Blatently Bad ones (here are some Bad Examples: /usr/X11R6, /root /etc), though I can't think of any benefit to src or XF4 on separate partitions (though I do have an NFS src directory on my mvme88k, due to 4G not being nearly enough to build on anymore)...nor do I see any real-life benefit to a /usr/local partition. I also would not guess that you would be doing much building in /usr/src on the same system you had that was so busy you put mysql on its own partition...so again, just because you can make a case for a separate partition on system X doesn't mean every system will see any benefit from that same partition. when I first posted Nick Holland replied with several reasons to have multiple partions. Those being security, fragmentation, protecting the filesystem from overfilling, organization and space tracking. I think I over-convinced you. :) does increasing the amount of partitions increase access to the files on that partition? Not sure I know what you mean by this... It COULD increase access time if you have partitions which are commonly being used together at opposite ends of the disk -- for example, perhaps src and obj, or src and /usr (where the compiler and libraries are), though if speed really matters that much to you, get more disks. Any feedback would be appreciated. As with most things in life, ask why, don't just do by formula. There are still some cases where the / and swap solution fits for testing, even though I now use it rarely (though I've wished I did a couple times!). A long time ago, I had a nice little webserver set up, then my friend Henning said, Here, try this chroot'ed Apache patch...which absolutely hosed my grand plans, as my /var partition was too small, as all the web documents were served from /home/user directories. You may note the warnings about this in the FAQ are perhaps a little over-emphasized... if you read the FAQ carefully, you can sometimes guess when something has bitten me personally. :) There are other reasons I've since found for partitioning, however...data partitions have become my favorite lately. MULTIPLE data partitions, in fact. And yes, multiple data partitions for one application. Here's why: if your application can be forced to split data across multiple partitions, it can be easily expanded later. SO...you can start out with a 200G drive today, in a year add a 700G drive, and not have to migrate everything from one to the other (btw: it takes a long time for even a fast machine to migrate 200G of data). It also means if something goes Horribly Wrong on one partition or drive, you can (probably) get away with recovering only that one partition from backup. Just had that happen to me this week -- E-mail archive system with well over 1T of data blew out one of its drives in a most spectacular way (short across the power supply pins), blowing out a power supply and a RAID box in the process. So..the survivors of this drive set had to be migrated to a spare RAID box, and then I made an error -- I missed the fact that the new box was set for RAID0 rather than RAID5, so after I beat on it a bit, it finally gave in and did what I apparently told it to: initialized the remaining data to zeros. So, off to the backups we went. FORTUNATELY, this system had several drive modules, and the one that failed (fortunately again!) was the least full of the bunch, so I only had 40 or so days of restore to do. I'm rather glad the other nine months of data in the thing escaped injury! Even if the same event happened on one of the other storage modules, it wouldn't have been as catastrophic as if I had it all in one pile. Related reason: in the case of partitions that fill with data, then you move on to another, you can remount the filled partitions as RO, so if, for example, a disk tosses a dead short across the power supply and you have 2T of storage suddenly lose power, you don't have to fsck the entire 2T, just the part that was mounted RW.
