Hello!
RoundCube places its config files within its directory hierarchy. This
is a fine default, but for packages it's important to be able to
override the default. Why? Many sysadmins (and packagers, and package
systems) expect all binaries and data installed under the root of the
package tree to be read-only once they've been installed; think NFS
sharing, or package tools throwing warnings on delete/update when
files don't match the checksums recorded when they were installed.
Config files aren't read-only, and therefore it's important to be able
to place them elsewhere if desired (/etc, for instance.) I've patched
roundcubemail-0.1.1-dep's main.inc:rcmail_load_config() to inspect the
environment and prefix $RCMAIL_CONFIG_DIR if set, rather than
"config", when reading the config files. The default behavior remains
unchanged, of course!
http://netbsd.schmonz.com/patches/roundcube-config-dir.diff
To take advantage of the patch, I added "SetEnv RCMAIL_CONFIG_DIR /etc/
roundcube" to the RoundCube section of my Apache config, and placed
{db,main}.inc.php in /etc/roundcube where I like them. :-)
Sorry this is against an old version, but there's nothing at all
clever about the changes so they should be straightforward to bring up
to date. The installer would need similar help as well.
- Amitai
List info: http://lists.roundcube.net/dev/
OoO Pendant le journal télévisé du vendredi 11 juillet 2008, vers 20:59, Amitai Schlair schmonz@schmonz.com disait :
RoundCube places its config files within its directory hierarchy. This
is a fine default, but for packages it's important to be able to
override the default. Why? Many sysadmins (and packagers, and package
systems) expect all binaries and data installed under the root of the
package tree to be read-only once they've been installed; think NFS
sharing, or package tools throwing warnings on delete/update when
files don't match the checksums recorded when they were installed.
Config files aren't read-only, and therefore it's important to be able
to place them elsewhere if desired (/etc, for instance.) I've patched
roundcubemail-0.1.1-dep's main.inc:rcmail_load_config() to inspect the
environment and prefix $RCMAIL_CONFIG_DIR if set, rather than
"config", when reading the config files. The default behavior remains
unchanged, of course!
To take advantage of the patch, I added "SetEnv RCMAIL_CONFIG_DIR /etc/ roundcube" to the RoundCube section of my Apache config, and placed
{db,main}.inc.php in /etc/roundcube where I like them. :-)
Hi Amitai!
In Debian, we just use symlinks to achieve the same thing.
BOFH excuse #368: Failure to adjust for daylight savings time. _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jul 11, 2008, at 4:25 PM, Vincent Bernat wrote:
OoO Pendant le journal télévisé du vendredi 11 juillet 2008, vers
20:59, Amitai Schlair schmonz@schmonz.com disait :To take advantage of the patch, I added "SetEnv RCMAIL_CONFIG_DIR / etc/ roundcube" to the RoundCube section of my Apache config, and placed {db,main}.inc.php in /etc/roundcube where I like them. :-)
In Debian, we just use symlinks to achieve the same thing.
IIRC, we used to do likewise in pkgsrc. Because of the way in which we
auto-compare config files against their original installed versions
(in order to determine whether the sysadmin modified anything, which
tells us whether to keep or discard when uninstalling), the symlink
approach got complicated and we abandoned it. It'd be great if
RoundCube could incorporate the minor changes necessary to follow an
environment variable, if set, to find its config files.
_______________________________________________
List info: http://lists.roundcube.net/dev/
Please be aware that not everyone has access to the Apache
configuration. Actually most people using hosted services don't have.
lg, Mike
On Jul 12, 2008, at 3:54 PM, Michael Baierl wrote:
Please be aware that not everyone has access to the Apache configuration. Actually most people using hosted services don't have.
Sure, my proposal doesn't help those users, but neither does it make
things any worse for them. What would you suggest instead?
Thanks,
- Amitai
List info: http://lists.roundcube.net/dev/
On Sun, Jul 13, 2008 at 12:38 AM, Amitai Schlair schmonz@schmonz.com wrote:
On Jul 12, 2008, at 3:54 PM, Michael Baierl wrote:
Please be aware that not everyone has access to the Apache configuration. Actually most people using hosted services don't have.
Sure, my proposal doesn't help those users, but neither does it make things any worse for them. What would you suggest instead?
I think currently, this is a none issue. :)
But being productive I suggest that instead of an env variable (which setting is so system specific etc.), I think we could implement a constant in index.php which would direct the code to the location of the configuration files. If empty, fall back on "local" (which is roundcube/config/).
This could be overwritten/replaced with a simple sed by a package maintainer if he thinks this is absolutely necessary.
Bottom line is though, I feel like the advantage of roundcube is unzip and go (almost literally), what you are doing makes it harder for the end user to deal with it. Not everyone running roundcube is a system administrator - it's more the contrary.
And personally I don't want to support people - "my distro puts it in /etc", "my distro puts it in /usr/local/etc" etc. pp.. :-)
My two cents (currently USD) :D
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On Jul 13, 2008, at 7:55 PM, till wrote:
But being productive I suggest that instead of an env variable (which setting is so system specific etc.), I think we could implement a constant in index.php which would direct the code to the location of the configuration files. If empty, fall back on "local" (which is roundcube/config/).
This could be overwritten/replaced with a simple sed by a package maintainer if he thinks this is absolutely necessary.
Sure, that sounds great to me. I came up with my patch because I
wanted to be able to set the path in one place without knowing much
about RoundCube; if index.php is a better place, then yes please. :-)
_______________________________________________
List info: http://lists.roundcube.net/dev/
On Mon, Jul 14, 2008 at 3:42 AM, Amitai Schlair schmonz@schmonz.com wrote:
On Jul 13, 2008, at 7:55 PM, till wrote:
But being productive I suggest that instead of an env variable (which setting is so system specific etc.), I think we could implement a constant in index.php which would direct the code to the location of the configuration files. If empty, fall back on "local" (which is roundcube/config/).
This could be overwritten/replaced with a simple sed by a package maintainer if he thinks this is absolutely necessary.
Sure, that sounds great to me. I came up with my patch because I wanted to be able to set the path in one place without knowing much about RoundCube; if index.php is a better place, then yes please. :-)
Yeah, I totally see where you are coming from. If you want to revise your patch, that would be a great help. Then attach it to a ticket and let me know, I'll get to it. :)
Till _______________________________________________ List info: http://lists.roundcube.net/dev/
On 14 Jul, 2008, at 2:50 PM, till wrote:
On Mon, Jul 14, 2008 at 3:42 AM, Amitai Schlair
schmonz@schmonz.com wrote:On Jul 13, 2008, at 7:55 PM, till wrote:
But being productive I suggest that instead of an env variable
(which setting is so system specific etc.), I think we could implement a constant in index.php which would direct the code to the location of the configuration files. If empty, fall back on "local" (which is roundcube/config/).This could be overwritten/replaced with a simple sed by a package maintainer if he thinks this is absolutely necessary.
Sure, that sounds great to me. I came up with my patch because I wanted to be able to set the path in one place without knowing much about RoundCube; if index.php is a better place, then yes please. :-)
Yeah, I totally see where you are coming from. If you want to revise your patch, that would be a great help. Then attach it to a ticket and let me know, I'll get to it. :)
Might you (or another committer) have a chance soonish? It'd make my
life (as both a sysadmin and a packager) much easier if the upcoming
beta came with the patch in #1485215 already applied, and it's a low-
impact change that's easy to test.
Thanks,
- Amitai
List info: http://lists.roundcube.net/dev/
-
Amitai Schlair -
Michael Baierl -
till -
Vincent Bernat