From: Alexander Skwar <listen@alexander.skwar.name>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] How many GB for / partition?
Date: Fri, 17 Feb 2006 07:33:26 +0100 [thread overview]
Message-ID: <43F56E36.2030109@mid.email-server.info> (raw)
In-Reply-To: <200602162123.26046.volker.armin.hemmann@tu-clausthal.de>
Hemmann, Volker Armin wrote:
> On Thursday 16 February 2006 20:40, Alexander Skwar wrote:
>> Hemmann, Volker Armin wrote:
>> > On Thursday 16 February 2006 17:18, Alexander Skwar wrote:
>> >> Hemmann, Volker Armin wrote:
>> >> > On Thursday 16 February 2006 15:45, Alexander Skwar wrote:
>> >> >> Hemmann, Volker Armin wrote:
>> >> >> > On Thursday 16 February 2006 14:06, Alexander Skwar wrote:
>> >> >> >> Izar Ilun wrote:
>> >> >
>> >> > Why should he make /tmp noexec,
>> >>
>> >> Security precaution.
>> >
>> > if you have 10+ users with access to the box. But a workstation, without
>> > even sshd running, it is not needed.
>>
>> "needed" - What's "needed", anyway?
>>
>> > And hey, why should /tmp noexec save you from anything?
>>
>> Because it does.
>
> so? how?
Think, you might find out. What does noexec do, hm?
Even *you* might find out...
Well... If I think about it... No, you're too clueless
to find out.
Hint 1: "noexec" nowadays makes it impossible to execute
programs stored on that filesystem.
Hint 2: /tmp (and /var/tmp) are (hopefully) the only places
where everybody can write.
>> > If someone is able to break into your box, he can build his tools in
>> > /home or /var/tmp or somewhere else. No need for /tmp.
>>
>> Wrong again. If tmp is the only place somebody can write, then
>> it might save you (and it DID save my ass more than once now).
>
> since /tmp is not the only place where someone can write (/var/tmp anyone?)
True. /var/tmp is a link to /tmp on my system. And if not, /var/tmp
could also easily be a seperate fs.
> it
> won't help you much.
That's of course wrong again.
>> >> Ah. Please explain how you mount /tmp noexec and /usr
>> >> readonly.
>> >
>> > I don't because it is wasted effort.
>>
>> Of course it's not.
>
> yes it is.
Jaja. Just because you've got problems, it doesn't mean
that there ARE problems.
>> So, how do you do that?
>
> I don't want to,
That's not the point.
So, how do you do that?
> because it is pointless.
Of course not.
> if he has enough rights, that you have to worry about rw /usr, he has enough
> rights, to circumvent ro mounting by remounting.
No, not necessarily.
>> > he has the rights
>> > to remount a ro /usr as rw
>>
>> That's of couse wrong again.
>
> no, that is correct.
No, it's not. Write permissions don't mean, that somebody is root.
Well - maybe on your systems. But not on well maintained systems.
>> > and can go on.. It just makes maintance harder.
>>
>> Not really.
>
> yes really, you have to remount /usr everytime you update something.
Jaja. You know, your exaggerations become boring...
>> >> Please also explain, how you seperate data areas (like
>> >> /var and /usr).
>> >
>> > I have /var and /usr?
>>
>> That's not the question.
>
> yes it is.
No, it's not. Please answer the question.
>> Please answer it. *YOU* are the one saying that a grossly
>> oversized filesystem offers more flexibility.
>
> I do, because they never fill up.
That's not the point. The question was, how do you optimize
so that the most often needed files are at the beginning of
the hd?
> But, hey, what are YOU doing, when your box does not boot anymore,
> because /tmp or /var/tmp are 100% full?
a) /tmp is cleaned during boot - so this won't happen anyway.
b) Don't let it happen in the first place.
c) Boot a rescue system like Knoppix and clean /tmp.
d) In reality, I NEVER had it happen that /tmp or /var/tmp
ran out of space. What happened "more often" is that /var
ran out of space, because of the logs in /var/log.
>> >> I see. Strange thing is, that about every server and workstation
>> >> I've seen more or less contradicts what you say.
>> >
>> > if you have 20+ users on each of them, and every single one is a little
>> > cracker in disguisse, it may make sense, but for a single user box?
>>
>> Why are you asking?
>
> because you are the one starting with 'server' and 'workstations'
Correct. So what? Why are you asking?
> and the OP
> never talked about one or the other.
His system MUST be the one or the other.
>> > If every partition takes a second, it will be very noticable.
>>
>> Hardly. (Notice that I'm not saying "No".)
>
> if mounting becomes the major 'hold up' in your booting process, it becomes
> VERY noticable.
Jaja. Do you actually expect to be taken seriously?
>> While what you're saying is true in theory, you're
>> exaggerating enourmously. And because of that, you're
>> wrong.
>
> no, I am right.
<stampf>!
No, you are not right in reality. Only in theory you are right.
> I have been there,
I doubt that.
> I have done lots of partitions for all and everything and I
> did it for a long time.
> It is just a waste of effort.
Jaja.
>> >> If you're *SO* low on hard disk space, I'd advice to buy
>> >> more harddisks.
>> >
>> > more harddisks = higher chance that one of them dies.
>>
>> Yep. Time to stop those bad backups. You're funny.
>> More of this, please! 8=)
>
> no, it is pure math.
Told ya - don't talk about maths, please!
> More harddisks=bigger chance that one of them dies.
True. So? What does this have to do with the fact, that the
available hd's are too small? Just as a reminder - that's
the scenario YOU are talking about.
>> > It is simple math.
>>
>> *LOL* _You_ should not talk about maths :)
>
> you obviously don't understand simple statistics.
Seems like. But maybe it's just, that I've got problems
following your nonsense, hm?
> Sad.
Thanks. I feel fine, though.
> Again: if every harddrive has a chance to die in 1:100 000 hours, every disk
> you add increases the chance that ONE of them dies.
True. So? You're the one with too small harddrives. If you need
more space, you'll either have to buy a bigger one or additional
drives.
If I'm bad in statistics, than you're very week in the area
of "logics".
>> > I haven't seen any good reason for a bazillion small partitions,
>>
>> That's of course not what I wrote. BTW: What's a "bazillion"?
>> More than you can count? More than 5? :) And *YOU* are talking
>> about maths?
>
> a bazillion is just more than needed. And more than needed on a single home
> computer is anything above 4 for the system
That's of course not true. Its good practice to put the "major"
directories on seperate filesystems, even if you're too dumb
to understand that, as you keep on demonstrating.
> yes, really, remount this, remount that, check that there is enough space
> in /var, check that there is enough space in /usr, check this, check that
> =
not much work, if any additional work at all
> more work.
Not really. Again, you're completely exaggerating - as usual.
>> > and have to be monitored constantly (f* /var is full,
>> > f* /tmp is full f* I have to remount /usr).
>>
>> What are you talking about? "constantly"?
>
> almost everyday,
True. A "df" is really hard. Yes, sure. And "almost everyday"
sounds VERY MUCH differently than "constantly". The latter
implies, that something is done very often. As you just said
now, you're rather thinking about doing something rather seldom.
Like "almost everyday", so maybe even just every other day.
Make up your mind please.
>> Well, you know, if "df" is too hard for you - sorry, pal,
>> tough luck. But you just cannot expect to be taken seriously.
>
> you forgot 'cp', 'mv' and, in the worst case 'tar everything up and change
> partition layout, because /usr became to small'
What do you mean? Why "cp", "mv" and "tar"?
> You are the one, who does not understand simple math,
Like "15% > 15%"? That kind of math?
If so, then yes, you're right, I don't understand your kind of simple
math.
> And as I said, I know what I am talking about.
You most certainly don't.
> I did the 'put everything on a
> dedicated partition', I even put them on different disks (/usr on
> one, /usr/lib on another for speeding up starting processes), and it hurts
> more than it gives you in the long run.
Of course not. It eases system administration very much, if not
completely overdone. /usr & /usr/lib would be a case, where I'd
say that this is overdone. Just another case of your exaggerations.
Alexander Skwar
--
gentoo-user@gentoo.org mailing list
next prev parent reply other threads:[~2006-02-17 6:37 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-16 12:19 [gentoo-user] How many GB for / partition? Izar Ilun
2006-02-16 12:34 ` Daniel da Veiga
2006-02-16 12:42 ` Neil Bothwick
[not found] ` <7ae6f8f0602160450i3d0b3973x437e82ff45c8606e@mail.gmail.com>
2006-02-16 12:51 ` Izar Ilun
2006-02-16 13:06 ` Alexander Skwar
2006-02-16 13:47 ` Neil Bothwick
2006-02-16 14:39 ` Alexander Skwar
2006-02-16 16:17 ` Neil Bothwick
2006-02-16 17:46 ` Alexander Skwar
2006-02-16 18:00 ` kashani
2006-02-16 20:11 ` Neil Bothwick
2006-02-16 20:24 ` Hemmann, Volker Armin
2006-02-17 7:52 ` Alexander Skwar
2006-02-17 9:41 ` Neil Bothwick
2006-02-17 1:59 ` Zac Slade
2006-02-17 9:38 ` Neil Bothwick
2006-02-16 14:19 ` Hemmann, Volker Armin
2006-02-16 14:45 ` Alexander Skwar
2006-02-16 15:34 ` Hemmann, Volker Armin
2006-02-16 16:18 ` Alexander Skwar
2006-02-16 18:46 ` Hemmann, Volker Armin
2006-02-16 19:40 ` Alexander Skwar
2006-02-16 20:12 ` Neil Bothwick
2006-02-16 21:07 ` Richard Fish
2006-02-16 23:37 ` Neil Bothwick
2006-02-17 6:02 ` Alexander Skwar
2006-02-17 7:14 ` Uwe Thiem
2006-02-16 20:23 ` Hemmann, Volker Armin
2006-02-17 6:33 ` Alexander Skwar [this message]
2006-02-17 18:04 ` Hemmann, Volker Armin
2006-02-17 18:19 ` Richard Fish
2006-02-17 18:38 ` Alexander Skwar
2006-02-17 19:18 ` Benno Schulenberg
2006-02-17 19:41 ` Daniel da Veiga
2006-02-17 22:15 ` Hemmann, Volker Armin
2006-02-17 18:35 ` Alexander Skwar
2006-02-17 22:15 ` Patrick Börjesson
2006-02-17 23:48 ` Hemmann, Volker Armin
2006-02-17 19:52 ` Maarten
2006-02-17 21:35 ` Alexander Skwar
2006-02-17 22:36 ` Rumen Yotov
2006-02-17 23:15 ` [gentoo-user] /usr as noexec? (was GB for / partition flamewar) Eric Bliss
2006-02-18 0:23 ` Maarten
2006-02-18 2:20 ` Ryan Tandy
2006-02-18 13:05 ` Maarten
2006-02-18 15:53 ` Uwe Thiem
2006-02-18 17:51 ` Maarten
2006-02-18 20:09 ` Hans-Werner Hilse
2006-02-19 19:50 ` kashani
2006-02-19 20:27 ` Alexander Skwar
2006-02-19 21:08 ` kashani
2006-02-19 21:18 ` Alexander Skwar
2006-02-19 21:37 ` kashani
2006-02-18 5:21 ` Rumen Yotov
2006-02-18 9:01 ` Neil Bothwick
2006-02-17 22:56 ` [gentoo-user] How many GB for / partition? Neil Bothwick
2006-02-16 14:58 ` jarry
2006-02-16 15:14 ` Robert Crawford
2006-02-16 15:36 ` Hemmann, Volker Armin
2006-02-16 14:47 ` jarry
2006-02-16 13:03 ` Alexander Skwar
2006-02-16 14:14 ` apn
2006-02-16 14:51 ` Alexander Skwar
2006-02-16 15:04 ` Martin Eisenhardt
2006-02-16 15:15 ` John Jolet
2006-02-16 15:29 ` Martin Eisenhardt
2006-02-16 15:10 ` jarry
2006-02-16 15:30 ` Alexander Skwar
2006-02-16 16:09 ` Martin Eisenhardt
2006-02-16 16:21 ` Alexander Skwar
2006-02-16 20:58 ` Martin Eisenhardt
2006-02-16 15:33 ` Martin Eisenhardt
2006-02-16 17:46 ` Jarry
2006-02-16 18:13 ` Alexander Skwar
2006-02-16 15:50 ` Richard Fish
2006-02-16 13:29 ` Emanuele Morozzi
2006-02-16 14:22 ` Hemmann, Volker Armin
2006-02-16 15:02 ` Richard Fish
2006-02-16 15:48 ` Hemmann, Volker Armin
2006-02-16 18:40 ` Richard Fish
2006-02-16 15:33 ` Alexander Skwar
-- strict thread matches above, loose matches on Subject: below --
2006-02-17 22:20 John Jolet
2006-02-23 11:07 joaoemanuel1981
2006-02-23 12:04 ` jarry
2006-02-23 13:55 ` Uwe Thiem
2006-02-23 14:05 ` John Jolet
2006-02-23 14:30 ` Dave Nebinger
2006-02-23 16:03 ` Richard Fish
2006-02-23 16:12 ` Dave Nebinger
2006-02-23 18:07 ` Alexander Skwar
2006-02-23 19:38 ` Uwe Thiem
2006-02-23 14:45 ` Abhay Kedia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43F56E36.2030109@mid.email-server.info \
--to=listen@alexander.skwar.name \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox