bacanapps/elmsln-config-vagrant

ELMSLN Config preconfigured for use with elmsln-vagrant

elmsln-config-vagrant

ELMSLN Config preconfigured for use with elmsln-vagrant. This is a separate repo so that elms-vagrant can pull down and replace the default elmsln/config/ directory on install.

Let's see if there's a font big enough for this... ###NEVER EVER EVER USE THIS IN PRODUCTION Hmm..let's try again. #NEVER. EVER. USE THIS IN PRODUCTION; GOT IT!?!????!! Much better. ##Seriously though.. This repo contains settings and configuration files that traditionally should be heavily gaurded and only version controlled in highly trusted, internal, protected, private repository hosting environments. The reason for this (paranoia) is that you'll want to create two things that are heavily gaurded from a security perspective that are included in this repo:

1. A config.cfg file that has priveledged information, most highly valued is a username and password for a user account that can request databases be generated.
2. A keychain of connection data for webservice calls between all the tools in your network.

The config.cfg file also has info about where elmsln is installed, email addresses for admins, admin names, email endings for new accounts, and apache / webgroup user names. All in all while this info is less critical then the db user account data, it's still info you could use to blueprint a webservice.

ELMSLN has gone out of its way in structure to ensure that all loose ends are tied up and that all data it stores (in code) that could have security implications only lives in one directory; config.

Also the keychain module, while dynamically generated into this directory, may eventually just be a standard vagrant keychain of usernames/passwords that live here. This is because currently the random u/p combos aren't really enhancing security in any way since this is purely for development purposes. As a result, teams working on a central instance would have to author their own keychain and put it in version control separate of what is generated by the vagrant instance anyway. so..ya..