default size of root fs

Mon Dec 6 20:02:57 UTC 2010

Heh we started a nice offtopic thread it seems...

On Mon, Dec 6, 2010 at 7:47 PM, Brian LaMere <brian at cukerinteractive.com>wrote:

> breaking apart the partitions isn't exclusive to BSD, it's considered
> mandatory best-practices in all UNIX systems.  Heck, the DoD *mandates* it.
>
> sure thing,

any advanced unix-like clone supports and recommends that -except linux :) -

> But...the "cloud" isn't the same.  One of the most dangerous things one can
> do is create the perception of security; it's one of the problems I have
> with the naked-pic cancer machines; a dog and a metal detector would be
> infinitely more effective, and less obtrusive, but doesn't look as cool as a
> machine that sees through your clothes.  The false sense of security is
> *dangerous*.
>
>
agreed, but to skip one layer of security because it is not the saint grail
it not a smart move. I was catching many automatic attacks with /tmp  folder
with noexec flag on them, it just helps to avoid a mass deface attack but
you are right it wont stop chuck norris....

> S3-backed images are using S3...there aren't real "partitions" anyway.
>  It's all http requests to a massive web server, that just handles
> put/post/delete/head/etc requests.  It's not discrete storage.  One
> shouldn't consider that it's "secure," nor should one worry about breaking
> apart "partitions" for performance reasons when using S3.  There's really,
> in the end, no reason to have more than a single volume for an S3-backed
> instance.
>
>
well this is not the case. S3 is used to store the linux image and during
the instance creation the system downloads the image and creates a local
copy of it and the FS is created on the local hard drives. S3 is not
suitable to store you root filesystem and operates a running system from
there for multiple reasons(one is latency)

EBS is a different story, it was designed to be used like a backed for
operating systems but there is no HTTP involved

> "cloud" is a different paradigm, and it's important to not try to shoe-horn
> old-school best-practices on to the new platforms that are, really, not at
> all the same.
>
> That said - an EBS is a SAN-like interface, from my understanding.  It is
> (supposedly) a discrete-ish volume specific to you.  You can even encrypt
> it, with barely any more overhead than a normal encrypted SAN device would
> have.  So yes - break apart the volumes for an EBS-backed instance.  Amazon
> actually recommends this - because it spreads out the I/O.  If you create 2
> volumes, they won't be in the same SAN, which through usage normalization
> means your spikes won't line up with other people's spikes, and you can
> distribute those high-impact periods.  EBS-backed instances are a bit less
> "cloud" like, and somewhat more like what people are used to.
>
> Oh, while we're on the subject - NEVER use S3 for swap.  You're better out
> running out of ram than trying to swap to a web server somewhere else -
> think about it :)
>
> Brian
>
>
> On Mon, Dec 6, 2010 at 11:37 AM, István <leccine at gmail.com> wrote:
>
>> Yeah it is viable solution as well, but it requires a bit more attention
>> from the admin side. I just used the xvdc device for /var and it was easier.
>> I hit two birds with one stone since logging also goes there.
>>
>> /dev/xvdc1             40G  401M   37G   2% /var
>>
>> I also like the BSD sort of installation when everything is separated so
>> can specify different behavior for /tmp /home /var like enable noexec or
>> nosuid parameters which are typically applied to mount points.
>>
>> But of course you could just modify mysql/apache/.... to sit on the
>> pre-configured devices.
>>
>> I.
>>
>>
>> On Mon, Dec 6, 2010 at 5:58 PM, Brian LaMere <brian at cukerinteractive.com>wrote:
>>
>>> you could always just deploy the lamp stuff to the other two dirs mounted
>>> - no reason mysql databases couldn't be in /data, for instance.
>>>  /var/lib/mysql doesn't really make that much sense for a place to actually
>>> /leave/ it, after all ;)
>>>
>>> Brian
>>>
>>>
>>> On Sun, Dec 5, 2010 at 6:03 AM, István <leccine at gmail.com> wrote:
>>>
>>>> Brilliant!
>>>>
>>>> . In the meantime I am trying to resize the root fs somehow splitting
>>>> /dev/xvdc for /var and so on.
>>>>
>>>> Thank you guys.
>>>>
>>>> Regards,
>>>> Istvan
>>>>
>>>>
>>>> On Sun, Dec 5, 2010 at 1:39 PM, Marek Goldmann <mgoldman at redhat.com>wrote
>>>>
>>>> Hi Istvan,
>>>>>
>>>>> Yes, we've talked about this before. Whole 10GB will be used for
>>>>> S3-based AMIs once we publish updated AMIs, right Justin?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Marek
>>>>>
>>>>> On 2010-12-05, at 13:10, István wrote:
>>>>>
>>>>> > Hey,
>>>>> >
>>>>> > Don't you think it was a good idea to have at least 10G for / in FC14
>>>>> EC2 image?
>>>>> >
>>>>> >
>>>>> > 2G is a bit small comparing the available many 100G space, it is
>>>>> hardly enough for typical LAMP installations or any kind of production
>>>>> server even if you store the content in /mnt.
>>>>> >
>>>>> >
>>>>> > Regards,
>>>>> > Istvan
>>>>> >
>>>>> > --
>>>>> > the sun shines for all
>>>>> >
>>>>> > http://blog.l1x.me
>>>>> > _______________________________________________
>>>>> > cloud mailing list
>>>>> > cloud at lists.fedoraproject.org
>>>>> > https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>>>
>>>>> _______________________________________________
>>>>> cloud mailing list
>>>>> cloud at lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> the sun shines for all
>>>>
>>>> http://blog.l1x.me
>>>>
>>>> _______________________________________________
>>>> cloud mailing list
>>>> cloud at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>>
>>>>
>>>
>>> _______________________________________________
>>> cloud mailing list
>>> cloud at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>>
>>>
>>
>>
>> --
>> the sun shines for all
>>
>> http://blog.l1x.me
>>
>> _______________________________________________
>> cloud mailing list
>> cloud at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/cloud
>>
>>
>
> _______________________________________________
> cloud mailing list
> cloud at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud
>
>

-- 
the sun shines for all

http://blog.l1x.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20101206/79b78e92/attachment.html>