[dev] default backends

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> I can only repeat myself. We do this all the time already. We add  
> new feature, we change behavior, sometimes even without any  
> configuration option.

But not with respect to **currently existing config values**.  That's  
the key difference.  Unless, every time you upgrade, you copy foo.php  
-> foo.local.php to ensure that those default values are never changed  
without your notice.  But then how is this any different than *.dist  
files?  (It isn't).

> Also, since this might not be clear from the discussion, this does  
> not affect the main configuration in conf.php at all. That is still  
> done through conf.xml and the configuration UI, and you can still  
> verify the diff between the old the new configuration before saving  
> it.

This is understood.  And I don't have any problems with this because  
the admin has the burden of upgrading this file; it is not done  
automatically.

> This only affects backends.php and stuff like  
> turba/config/attributes.php or ingo/config/fields.php, the latter  
> which really don't impose *any* security concerns at all.

I would doubt that it doesn't impose any security concerns, at least  
at a theoretical level (every action has security concerns).  But I  
will go along with the idea that those files you listed don't raise  
any practical security concerns.

But what about mime_drivers.php?  All sorts of security concerns in  
there.  And prefs.php?  Definitely shouldn't be changing preferences  
defaults, for example, without admin interaction.

Summarizing my positions:

1. Having reasonable defaults for initial setup is good.
2. Automatically upgrading configuration options is bad.
3. *.local.php files are terrible for most users - they should be  
editing the *.php files directly

I still believe a *.dist regime is the way to go.  I am not convinced  
that the H3 method is   However, we can make improvements to make this  
process easier for admins on initial install.  Example:

   - Each app ships with a 'config/defaults' directory.  This  
directory contains the default config files.
   - App does not have config files in 'config' by default
   - Theoretically, could have Horde::loadConfiguration() copy  
defaults over automatically if config file doesn't exist, but that's a  
potential security issue with file/directory permissions.
   - Instead, require the admin to run a command (e.g.  
/horde/bin/init_app [app]) that does the necessary copying, permission  
checking, and/or other install necessary for the app - each app could  
extend a base Horde_Install class that would allow for other  
install-time actions.

IMHO, it is not asking the admin too much to run ONE additional  
command-line argument to copy default config files when installing an  
application.  Users are already going to have to do some command-line  
stuff to install/upgrade (e.g. PEAR install commands; DB migration) so  
adding an additional command is not a deal killer, as long as the  
command is easy to run and clearly documented.  In fact, DB migration  
should probably be a part of this process anyway.  So this process  
would involve ZERO additional commands.

This method allows users to directly alter *.php files.  It removes  
the need for *.local.php files.

Then, on upgrade, no config options are overridden automatically.  We  
could provide a tool that walks the admin through any config option  
changes (for many upgrades, there won't be any).

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]