MSP-10848
Use these locations, in order for
Metasploit::Framework::Application.config.paths['config/database']:
1. MSF_DATABASE_CONFIG environment variable
2. ~/.msf4/database.yml (if it exists)
3. config/database.yml
MSP-10848
Other railties, like jquery-rails, need 'action_view/railtie', but don't
require it themselves, so require it explictly in
`config/application.rb` to prevent msfconsole boot errors.
While helping Dave Maloney port the changes from lib/msfenv.rb to
config/boot.rb for the Gemfile.local support, I failed to notice that
root was only defined in the unless block when it is needed no matter
what.
MSP-9653
Extra config and initializers that can we shared between
Metasploit::Framework::Application and the future
Metasploit::Framework::Engine. Move the default encoding setup from
lib/msf/sanity.rb to a before_initialize callback for the shared config
so that gems, like gherkin that depend on the utf-8 default internal
encoding can be loaded.
MSP-9606
Catch LoadError in config/application.rb when trying to require
'active_record/railtie` so that end-users can run without any of the
database gems installed. NOTE: you can't run in the development or
test environment without the database because factory_girl needs
ActiveRecord.
MSP-9606
In order to support Metasploit::Credential correctly,
metasploit-framework needs to support Metasploit::Concern, which does
all its magic using a Rails::Engine initializer, so the easiest path is
to make metasploit-framework be able to use Rails::Engines. To make
Rails::Engine use Rails::Engine, make a dummy Rails::Application
subclass so that all the initializers will be run when anything requires
msfenv.
Actually let people get going out of the gate without forcing them to
puzzle out database.yml configurations. Also gives some hints on how to
set up a database.
Today, if you merely copy and paste from database.yml.example, you'll
get yelled at:
````
$ ./msfconsole -L -y config/database.yml
[-] No database definition for environment production
````
[#46224565]
The following rake tasks are added and work similar to how they work in
rails apps:
* db:create
* db:drop
* db:migrate
* db:migrate:status
* db:rollback
* db:schema:dump
* db:schema:load
* db:seed (but no db seeds defined at this time)
* db:setup
* db:version
The hidden task db:test:prepare is also available, which means `rake
spec` can depend on it so that the test database is dropped and
recreated from the development database when running specs (Although
there are yet to be database tests, this branch is in preparation for
that work that will be split between multiple developers.)