New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Ideal Configurations
Alright so I'm looking for some configuration files for:
- Nginx
- PHP
- MySQL
Preferably these configurations would be your "perfect config" for maintaining multiple websites while still being RAM efficient. I'd like to compare them with my current configs and see if there's anything that can be tweaked.
Pastebin/Pastie when appropriate and if you can tell me the RAM usage for that config (or series of configs) that'd be great.
Why do I want these configs? I'm developing a single user, multiple domain control panel (Neon) and while it currently has it's own configs, I'd like to see some other people's examples so I can improve mine...
Comments
All depends on the load you are doing.
Nginx + MyBB on PHP-FPM: http://pastebin.com/PFFuKP8U
The MyBB config has rules to block a DDoS that I've seen multiple times with POST against /index.php causing a bitch of a load to MySQL. It also allows for seamless integration of MyBB's native "pretty-url's" and the Google SEO URL's plugin.
I use Debian 6.0 Minimal 32-bit template with untouched MySQL, dotdeb nginx and php running ~5 websites at only 85MB used.
Reading the docs is going to give you the best insight n understanding.
@BlueVM - For Nginx you should read this: http://www.phoenixvps.com/guides/2013/04/nginx-configuration-examples
I actually use this strategy heavily and have for eons on a number of projects. Haven't read config in total detail, but caching that index.php page for set time should eliminate other GET style attacks from piling/hitting MySQL.
Caching is everyones friend. Well at least for index/home pages, normally.
That's developer incompetency though. If your stuff is vulnerable over a certain request method,
a) The obvious step should be to fix said vulnerability.
b) If that's impossible, filtering with something like $_SERVER['REQUEST_METHOD'] should be implemented, in the very least.
Some directives I find particularly useful for nginx:
return 444;
}`
http://wiki.nginx.org/IfIsEvil
limit_except GET HEAD POST OPTIONS { return 444; }
From http://wiki.nginx.org/IfIsEvil, it used request_method for an example of what's acceptable:
I will look into limit_except, though. Thanks for pointing it out.
Still best to avoid if at all possible.