Fix Cmd Exec Vulns

[Meatballs1]

This prevents the abuse of command exec vulns in the Apache commands. These values should be relatively static (even across environments) so there isn't really a good reason to have them dynamically configurable.

Configuration of Apache commands/paths now takes place in config/initializers/apache.rb

• GlobalSettings is now a Singleton and forced to be so in the database due to a uniqueness check.
• An ApacheController library class has been added which takes away some of the control burden from Campaign. This could probably go further to simplify the Campaign logic.
• Have moved to follow the Apache standard of writing to sites-available and creating a symlink when the site is activated.

[Meatballs1]

Only because I have defined instance !

[Meatballs1]

n.b. I expect code exec is probable when previewing emails via erb?

[zeknox]

Throwing a bunch of errors on the tests due to the unique validation. Perhaps we need to write a db cleaner between each test?

# rspec
.........................FFFFFFFFFFF......................F..FF..........FFF
Failures:
  1) Campaigns GET /campaigns/1 populate campaign options and ensure all settings saved to campaign
     Failure/Error: click_on("Save Settings")
     ActionView::Template::Error:
       Mysql2::Error: Duplicate entry '0' for key 'index_global_settings_on_singleton': INSERT INTO `global_settings` (`created_at`, `singleton`, `updated_at`) VALUES ('2015-07-20 22:51:02', 0, '2015-07-20 22:51:02')

[Meatballs1]

Not sure if the test is causing the object to be created, or if its just rspec doing something magic in the background to instantiate it?

[Meatballs1]

It could be a multithreading thing from rspec? Hmm. Maybe should try to access GlobalSettings.instance in a :before or some kind of rspec initializor. Will need to check up where best to do it :)

[zeknox]

I feel like the tests are not clearing the database upon each request. I believe it should purge the TEST db instance between each spec to alleviate this isssue. Just my hunch.

[technion]

Just as note here that for a user deploying on CentOS - none of these defaults are valid. It's perfectly fine of course to edit a config file and update them, but I wouldn't say they are static "across environments".

[Meatballs1]

Yes correct, maybe static across many environments :)