I just updated our Roundcube-Stable Installation from 0.8.2 to 0.8.3 via ./bin/installto.sh and found 3 not so good thing in the main.inc.php.
- The Config-Line for the Useragent:
The old line was: $rcmail_config['useragent'] = 'Roundcube Webmail/'.RCMAIL_VERSION;
installto.sh sets it to:
$rcmail_config['useragent'] = 'Roundcube Webmail/0.8.3';
- Config-Lines from plugins that must be configure in the main.inc.php
are lost. Here it is the plugin show_additional_headers and the line $rcmail_config['show_additional_headers'] = array('Content-Type', 'Content-Transfer-Encoding', 'User-Agent', 'Mailer', 'X-Mailer', 'X-Newsreader', 'X-Posting-Agent', 'X-Http-User-Agent', 'X-MimeOLE');
- All user defined comments in the config are lost.
Am 11.11.2012 10:15, schrieb Martin Wodrich:
I just updated our Roundcube-Stable Installation from 0.8.2 to 0.8.3 via ./bin/installto.sh and found 3 not so good thing in the main.inc.php.
Our Roundcube-GIT (0.9-GIT) Installation have the same issues after update.sh
On 11/11/12 01:15, Martin Wodrich wrote:
I just updated our Roundcube-Stable Installation from 0.8.2 to 0.8.3 via ./bin/installto.sh and found 3 not so good thing in the main.inc.php.
- The Config-Line for the Useragent:
The old line was: $rcmail_config['useragent'] = 'Roundcube Webmail/'.RCMAIL_VERSION;
installto.sh sets it to:
$rcmail_config['useragent'] = 'Roundcube Webmail/0.8.3';
- Config-Lines from plugins that must be configure in the
main.inc.php are lost. Here it is the plugin show_additional_headers and the line $rcmail_config['show_additional_headers'] = array('Content-Type', 'Content-Transfer-Encoding', 'User-Agent', 'Mailer', 'X-Mailer', 'X-Newsreader', 'X-Posting-Agent', 'X-Http-User-Agent', 'X-MimeOLE');
- All user defined comments in the config are lost.
Issues like these are some of the reason I never update an existing installation, but always install fresh each time. I typically use a copy of the database for major version changes (0.7.x -> 0.8), but not for incrementals. I'll also do a diff on the main.inc.php.dist from the existing to the new version - if there are no diffs, I'll simply copy the previous main.inc.php to the new, otherwise I'll verify the changes and re-config as needed.
I've written a step-by-step document for myself to make sure I don't miss any of our customizations during version upgrades. It takes me about 20 minutes to bring up a new version, which I typically run in tandem with the prior version for a few days for testing before I roll it out to our users.
-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________
Am 11.11.2012 20:23, schrieb Arne Berglund:
On 11/11/12 01:15, Martin Wodrich wrote:
I just updated our Roundcube-Stable Installation from 0.8.2 to 0.8.3 via ./bin/installto.sh and found 3 not so good thing in the main.inc.php.
- The Config-Line for the Useragent:
The old line was: $rcmail_config['useragent'] = 'Roundcube Webmail/'.RCMAIL_VERSION;
installto.sh sets it to:
$rcmail_config['useragent'] = 'Roundcube Webmail/0.8.3';
- Config-Lines from plugins that must be configure in the main.inc.php
are lost. Here it is the plugin show_additional_headers and the line $rcmail_config['show_additional_headers'] = array('Content-Type', 'Content-Transfer-Encoding', 'User-Agent', 'Mailer', 'X-Mailer', 'X-Newsreader', 'X-Posting-Agent', 'X-Http-User-Agent', 'X-MimeOLE');
- All user defined comments in the config are lost.
Issues like these are some of the reason I never update an existing installation, but always install fresh each time. I typically use a copy of the database for major version changes (0.7.x -> 0.8), but not for incrementals. I'll also do a diff on the main.inc.php.dist from the existing to the new version - if there are no diffs, I'll simply copy the previous main.inc.php to the new, otherwise I'll verify the changes and re-config as needed.
issues like this are the reason to use a package manager it is quite easy to build a RPM fpr roundcube and the update from 0.8 to 0.9 is painless including switch back to the classic theme instead the overloaded new one which is the only needed config change
Am 11.11.2012 20:23, schrieb Arne Berglund:
On 11/11/12 01:15, Martin Wodrich wrote:
I just updated our Roundcube-Stable Installation from 0.8.2 to 0.8.3 via ./bin/installto.sh and found 3 not so good thing in the main.inc.php.
- The Config-Line for the Useragent:
The old line was: $rcmail_config['useragent'] = 'Roundcube Webmail/'.RCMAIL_VERSION;
installto.sh sets it to:
$rcmail_config['useragent'] = 'Roundcube Webmail/0.8.3';
- Config-Lines from plugins that must be configure in the main.inc.php
are lost. Here it is the plugin show_additional_headers and the line $rcmail_config['show_additional_headers'] = array('Content-Type', 'Content-Transfer-Encoding', 'User-Agent', 'Mailer', 'X-Mailer', 'X-Newsreader', 'X-Posting-Agent', 'X-Http-User-Agent', 'X-MimeOLE');
- All user defined comments in the config are lost.
Issues like these are some of the reason I never update an existing installation, but always install fresh each time.
For all of the above issues i have a Diff for the main.inc.php, but it will be better, if these issue were not. Issue 1 needs editing the Diff every time I need it.
On Sunday, November 11, 2012 at 10:15 AM, Martin Wodrich wrote:
I just updated our Roundcube-Stable Installation from 0.8.2 to 0.8.3 via ./bin/installto.sh (http://installto.sh) and found 3 not so good thing in the main.inc.php.
- The Config-Line for the Useragent:
The old line was: $rcmail_config['useragent'] = 'Roundcube Webmail/'.RCMAIL_VERSION;
installto.sh (http://installto.sh) sets it to:
$rcmail_config['useragent'] = 'Roundcube Webmail/0.8.3';
- Config-Lines from plugins that must be configure in the main.inc.php
are lost. Here it is the plugin show_additional_headers and the line $rcmail_config['show_additional_headers'] = array('Content-Type', 'Content-Transfer-Encoding', 'User-Agent', 'Mailer', 'X-Mailer', 'X-Newsreader', 'X-Posting-Agent', 'X-Http-User-Agent', 'X-MimeOLE');
- All user defined comments in the config are lost.
I am wondering if something like a main.inc.local.php would be a step in the right direction. This would be similar to the host specific configuration files1, but maybe more straightforward/simple?
It would basically be a file which is included (after main.inc.php) and then merged into the config array to override the settings from main.inc.php, etc..? This could be optional — only use it when it's there. With a little APC configuration and/or caching there are next to zero penalties for doing that.
If people wanted, we could do this for all configuration files — these files would obviously be off-limit to the installer etc..
main.inc.php > main.inc.local.php > host-specific
Food for thoughts!
Till
On Sunday, November 11, 2012 at 8:47 PM, Reindl Harald wrote:
Am 11.11.2012 20:45, schrieb till:
I am wondering if something like a main.inc.local.php would be a step in the right direction
YES
a good update-path will NEVER touch your personal config everything which does is crap
Well, I think that is already available with the host-specific configurations.
I just don't know if:
a) People know about it. :) b) It's too much hassle to setup.
Maybe our installer should create one of those instead of writing the usual to make it more obvious.
Till
Well, I think that is already available with the host-specific configurations.
I just don't know if:
a) People know about it. :) b) It's too much hassle to setup.
Maybe our installer should create one of those instead of writing the usual to make it more obvious.
It's not as easy when you have a few CNAMEs pointing to the same roundcube installation. Not only that, we have 15 servers running, and sometimes id like to go to a specific one to debug some issue on a specific server. So before you know it you have like 20 different possible HTTP_HOST options. Id much rather be able to load a main.local.inc.php file.
Issues like these is why i follow git release-0.8 :)
Cor
Reindl Harald wrote:
Am 11.11.2012 20:45, schrieb till:
I am wondering if something like a main.inc.local.php would be a step in the right direction
YES
a good update-path will NEVER touch your personal config everything which does is crap
I know, the current structure of config files isn't perfect and a legacy from the beginning of the project where we all used to be young and stupid. There are plans to fix this: http://trac.roundcube.net/ticket/1487311
~Thomas
-
Arne Berglund -
Cor Bosman -
Martin Wodrich -
Reindl Harald -
Thomas Bruederli -
till