On Fri, May 25, 2012 at 7:12 PM, Vincent
Massol<vincent(a)massol.net> wrote:
On May 25, 2012, at 12:31 PM, Denis Gervalle wrote:
On Fri, May 25, 2012 at 11:32 AM, Thomas
Mortagne<
thomas.mortagne(a)xwiki.com
wrote:
> On Fri, May 25, 2012 at 8:16 AM, Vincent Massol<vincent(a)massol.net>
wrote:
>> Hi devs,
>>
>> Since I'm working on making XE work in Windows7 I've thought more about
> XWiki's install and configuration. Actually this is not a new topic, I
> remember starting a discussion about it a few years ago on the devs list
> but we didn't act on it so here it comes again ;)
>>
>> Rationale
>> ========
>>
>> The idea is to separate XWiki's binaries from its data. There are
> several reasons for wanting this:
>>
>> * Some OSes require this and don't allow writing in the binary
> directory. Windows 7 for example won't allow writing data in \Program
Files.
>> * It makes upgrading simpler since you
don't need to fish for
> configuration data and copy them somewhere before unpacking a new
> distribution over. Or if you unpack in a new directory you don't need to
> copy the data from the old directory to the new one.
>> * As a consequence of the previous point It allows easier auto upgrades
> of XE
>> * It makes it simpler to know what to backup: all you need to back is
> the data directory.
>>
>> Proposal
>> =======
>>
>> This is the simplest I've found (I've imagine a lot of more complex
> options which offer other small possibilities but in the end I went for
the
> simpler one for now). So here goes the
process when starting up XE:
>>
>> * XE looks for a XWIKI_DATA environment variable and if found it uses
it
> as its environment.permanentDirectory value
>
> Why not XWIKI_PERMANENTDIRECTORY since that's how we call it in XWiki ?
>
>> * If not found, XE looks in the user home directory for an XWiki
> directory. Now the name of this directory is environment-dependent. On
non
> windows systems it looks for
".xwiki" directory and on Windows systems
it
looks for
a "XWiki" directory.
> * If not found, then XE stops and prints a message in the console
explaining that it couldn't find the location of the XWiki Data dir with
explanations on how to set it.
>
> The recommendation is thus that users set the XWIKI_DATA environment
property.
I do not like this so much.
If you use filesystem attachement, properly locating this directory is
crucial, and leaving it to an environment variable is risky, IMO.
Funny :) Tomcat uses environment variables so if you don't set those
rights you don't even get XWiki ;)
So the solution is simple: you create a start script for your application
(start_xwiki.sh for ex) and inside it you set the XWIKI_DATA directory).
>> Notes:
>> * At startup XE prints as an INFO log the location of the permanent dir
> it is using.
>> * For the standalone distribution we would set the XWIKI_DATA env
> variable in the xwiki start file (start_xwiki.sh and start_xwiki.bat) to
> point to the data/ dir in the distribution.
>> * One aspect that is not covered here yet (the topic for another
email):
the
installer. I'll prepare another mail for that since it's independent
for me.
>
Note that for Debian installed I simply set the right directory in
xwiki.cfg/xwiki.properties.
Why not doing the same for the Windows installation ?
If you means, because the configuration file are on the read-only part of
your installation, then your need is to have local configuration files
for
users. This is absolutely not the same issue.
This proposal is independent of installers (I mentioned I'll send a
separate email for installers). The idea here was for me to propose a
solution that works without installers. Supporting installers is ok and
installers would be able to set the XWIKI_DATA env variable by asking
questions to you, whether you wish an install for all users, just for your
users, check if there's already some xwiki installs at the specified dir,
etc.
Thanks
-Vincent
PS: Seen the various answers, I've probably not expressed myself very
clearly. I apologize for that and I hope it's more clear from my various
answers. If not, I'll resend a more general email with the goal so that at
least we start by agreeing with the goal (i.e. separate data from binaries
- I thought it was a give but maybe that's not the case).
This was absolutely not clear from your initial proposal. And I am still
puzzled now, since the permanent directory and the place where the
configuration file are stored are two very different things.
If you intend to put the configuration files in what we currently call the
permanent directory, this is a big -1. Putting configuration in the same
location we write file at run-time is simply opening a major security hole.
I think, to the benefit of this proposal, that you start over, since most
comments here are not related to your real goal, and please talk about a
configuration directory and not permanent directory.