[dev] default backends

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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).

Why would you copy foo.php to foo.local.php? That *would* be  
overwriting your local settings.

>> 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.

I don't think we are going to ever agree on this :)

> 3. *.local.php files are terrible for most users - they should be  
> editing the *.php files directly

I agree that editing a complete configuration file is easier than  
creating a .local.php that only overwrites certain settings,  
especially if you are not good at PHP. I was against this kind of  
configuration layout for quite some time too. But I had to realize  
that the advantage of easier installation and upgrading outweighs the  
more complex editing of .local.php files. We can help admins with that  
by providing good documentation and examples of common configuration  
changes. And by really creating a UI for that at one point.

> 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.

It's still going to be possible to install Horde without any command  
line access, so this really isn't an option, plus it seems to make  
things more complex again.

> 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]
>
> -- 
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>



Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/