[olug] Web Server, MySQL and security
dave at roweware.com
Wed Sep 1 19:33:42 UTC 2010
On Wed, Sep 1, 2010 at 2:23 PM, Christopher Cashell <topher-olug at zyp.org> wrote:
> On Wed, Sep 1, 2010 at 2:11 PM, T. J. Brumfield <enderandrew at gmail.com> wrote:
>> I've always gone through hosting companies, and I may be building a web
>> server box. Is there a nice checklist of security concerns for someone
>> building largely their first LAMP box?
> Most of this is going to be basic security practices. Remove or
> disable services you don't need, enable itpables, limit access to
> local hosts whenever possible, remove any default/demo web apps that
> might get installed, etc. There are lots of "Best Practices" guides
> and documents available on this (heck, even the NSA has one:
>> Specifically for a low-bandwidth site, I'm pretty sure any server I throw at
>> it will be overkill from a CPU and RAM perspective. I imagine disk I/O on
>> all the SQL calls are going to be my only bottleneck, if I have one.
>> Could I mount a partition directly into RAM to get fast SQL reads, but then
>> replicate that data back to physical disc? Can I do that with the actual web
>> site files as well?
I'd simply tweak the table engine for the DB to utilize RAM, etc.
>> I know you can do that with commercial offerings like TimesTen, but I wasn't
>> sure if I could do that with MySQL out-of-the-box.
> You can get most of the benefits here fairly easily by taking
> advantage of Linux. First, figure out how big your database will be.
> Then, pack as much RAM as you can afford/fit into your server. By
> default, Linux will utilize any unallocated memory as disk cache,
> automatically speeding up your database reads.
> Unless you know (through testing and benchmarking) that you have IO
> needs beyond this, I would bother with anything else.
You need to customize for InnoDB though. The default buffer pool size
of 8MB is too small and can/will choke your app. Generally, if memory
allows it, set the buffer pool size to 10 - 15% bigger than your DB
size (accounting for growth, etc) and you'll be a much happier camper.
Likewise, depending on complexity you can customize the settings to
get more performance out of the query optimizer (ie, if you have a
query with >6 table joins), etc.
>> -- T. J.
> OLUG mailing list
> OLUG at olug.org
More information about the OLUG