Re: default size of root fs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On Mon, Dec 6, 2010 at 7:47 PM, Brian LaMere <brian@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/cloud

_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud



--
the sun shines for all

http://blog.l1x.me

_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud



_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud




--
the sun shines for all

http://blog.l1x.me

_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud



_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud




--
the sun shines for all

http://blog.l1x.me
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud

[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux