Heh we started a nice offtopic thread it seems...<div><br><div class="gmail_quote">On Mon, Dec 6, 2010 at 7:47 PM, Brian LaMere <span dir="ltr"><<a href="mailto:brian@cukerinteractive.com">brian@cukerinteractive.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">breaking apart the partitions isn't exclusive to BSD, it's considered mandatory best-practices in all UNIX systems. Heck, the DoD *mandates* it.<div>
<br></div></blockquote><div>sure thing,</div><div><br></div><div>any advanced unix-like clone supports and recommends that -except linux :) -</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></div><div>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*.</div>
<div><br></div></blockquote><div><br></div><div>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....</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div><div>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.</div>
<div><br></div></blockquote><div><br></div><div>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)</div>
<div><br></div><div>EBS is a different story, it was designed to be used like a backed for operating systems but there is no HTTP involved</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div></div><div>"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.</div><div><br></div><div>
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.</div>
<div><br></div><div>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 :)</div><div><br></div><div><font color="#888888">Brian</font><div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Mon, Dec 6, 2010 at 11:37 AM, István <span dir="ltr"><<a href="mailto:leccine@gmail.com" target="_blank">leccine@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<div><br>
</div>
<div><div><div>/dev/xvdc1 40G 401M 37G 2% /var</div></div><div><br></div><div>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.</div>
<div><br></div><div>But of course you could just modify mysql/apache/.... to sit on the pre-configured devices.</div><div><br></div><font color="#888888"><div>I.</div></font><div><div></div><div><div><br></div>
<br><div class="gmail_quote">On Mon, Dec 6, 2010 at 5:58 PM, Brian LaMere <span dir="ltr"><<a href="mailto:brian@cukerinteractive.com" target="_blank">brian@cukerinteractive.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 ;)<div>
<br></div><div><font color="#888888">Brian</font><div><div></div><div><br><br><div class="gmail_quote">On Sun, Dec 5, 2010 at 6:03 AM, István <span dir="ltr"><<a href="mailto:leccine@gmail.com" target="_blank">leccine@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Brilliant!<div><br></div><div>. In the meantime I am trying to resize the root fs somehow splitting /dev/xvdc for /var and so on.</div><div><br></div><div>Thank you guys.</div>
<div> </div><div>Regards,</div><div>Istvan</div><div><br></div><div><br><div class="gmail_quote">On Sun, Dec 5, 2010 at 1:39 PM, Marek Goldmann <span dir="ltr"><<a href="mailto:mgoldman@redhat.com" target="_blank">mgoldman@redhat.com</a>></span> wrote<div>
<div></div><div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Istvan,<br>
<br>
Yes, we've talked about this before. Whole 10GB will be used for S3-based AMIs once we publish updated AMIs, right Justin?<br>
<br>
Thanks!<br>
<br>
--Marek<br>
<div><div></div><div><br>
On 2010-12-05, at 13:10, István wrote:<br>
<br>
> Hey,<br>
><br>
> Don't you think it was a good idea to have at least 10G for / in FC14 EC2 image?<br>
><br>
><br>
> 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.<br>
><br>
><br>
> Regards,<br>
> Istvan<br>
><br>
> --<br>
> the sun shines for all<br>
><br>
> <a href="http://blog.l1x.me" target="_blank">http://blog.l1x.me</a><br>
</div></div>> _______________________________________________<br>
> cloud mailing list<br>
> <a href="mailto:cloud@lists.fedoraproject.org" target="_blank">cloud@lists.fedoraproject.org</a><br>
> <a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
<br>
_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org" target="_blank">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
</blockquote></div></div></div><div><div></div><div><br><br clear="all"><br>-- <br>the sun shines for all<br><br><a href="http://blog.l1x.me" target="_blank">http://blog.l1x.me</a><br>
</div></div></div>
<br>_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org" target="_blank">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org" target="_blank">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>the sun shines for all<br><br><a href="http://blog.l1x.me" target="_blank">http://blog.l1x.me</a><br>
</div></div></div>
<br>_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org" target="_blank">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@lists.fedoraproject.org">cloud@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/cloud" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/cloud</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>the sun shines for all<br><br><a href="http://blog.l1x.me" target="_blank">http://blog.l1x.me</a><br>
</div>