On 12/04/2012 03:38 PM, Aaron Weitekamp wrote:
On 12/04/2012 08:54 AM, Jiří Stránský wrote:
> On 4.12.2012 12:31, Tomas Sedovic wrote:
>
> This seems like a similar issue as including default image templates and
> deployables [1].
>
> Might be nice to include default templates, deployables and admin
> account when you are setting up Aeolus for development or evaluation,
> but not for production.
I think we should include default deployables and tepmlates in
production as well. Not so for the default admin account.
But this is exactly the scenario I fear: a customer uses
admin/password
for a quick eval install. After a while they start using Aeolus for
"real" but no one remembers to remove the default. It's classic and
happens all the time. Is it still their responsibility? Yes. But chances
are they would have chosen a more secure password during eval install if
prompted.
I worry about that as well. However, there are already differences
between the devel and prod setup mostly due to the way Rails works:
* exceptions are displayed in the browser in the devel mode
* all the routes, models and controllers are reloaded on every request
* assets are recompiled on every request, without any optimizations
* there is no caching whatsoever
Even without any performance tweaks, just using the default installation
of Conductor from the RPMs (which uses the production environment)
versus the checked-out version in the development mode has a *way*
better browsing speed.
Anyway, if you install the packaged version, it will be running in
production and absolutely must be secure by default.
But I don't think making it more convenient to the developers (either
via dev-tools[1] or environment-specific database seeds) is a bad thing.
[1]:
https://github.com/aeolus-incubator/dev-tools