On Jun 1, 2012, at 6:16 PM, Denis Gervalle wrote:

On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol <vincent@massol.net> wrote:

...

Hi devs,

This proposal is a restart of the thread I've sent, entitled "[Proposal] XWiki's Permanent Directory Strategy for Installations" in which I wasn't clear.

Executive Summary ================

Define 2 XWiki directories; one for holding configuration data and one for holding (permanent) data and allow various configurations for our distributions.

* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg, xwiki.properties, hibernate.cfg.xml * Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/, jetty log files

Should'nt we also consider a separate cache directory for stuffs like lucene which does not really require backup, and a log directory for logs file. This would better fit the FHS which concider /etc, /var/lib, /var/cache and /var/log. We could of course have defaults to the data directory for these unless specifically defined.

Yes we could. I agree that we would need those to be optional and default to the data dir to make it simple.

...

Rationale ========

This proposal below tries to answer the following general use cases: * Ability to easily backup an XWiki install * Ability to easily upgrade an XWiki install * Ability to install XWiki on various OSes, including OSes like Windows 7 which require a total separation of readonly binaries and generated data * Ability to have several instances of XWiki on the same machine

Note that I'm sending this email since I'm currently working on making our installer work on Windows 7 and I need an agreement on this before I can continue since I'm currently blocked.

You just not describe what you will do in the installer for Windows 7 ?

Indeed I wanted to separate manual installs from Installers. Ok so here's what I plan to do short-term in the Windows7 installer for 4.1RC1 (to be improved later): * Only handle data dir * Generate 2 version of start/stop shell scripts with one version being for Windows7 and the rest for the other OSes. The Windows7 version will have the system property xwiki.data.dir set to %PROGRAMDATA%\XWiki\data (leaving %PROGRAMDATA%\XWiki\config available for later on) * Don't set environment.permanentDirectory (again 2 set of files for xwiki.properties, one for Windows7 and the rest for other OSes) * Modify Environment module implementation to default to the system property when no environment.permanentDirectory is set * Copy HSQLDB data to %PROGRAMDATA%\XWiki\data\database Thanks -Vincent

...

Use Cases =========

The proposal below should allow the following use cases easily: UC1: use the standalone zip distribution UC2: upgrade a standalone zip distribution install UC3: Use the WAR production distribution UC4: Upgrade an existing WAR distribution

Short Term Proposal =================

* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir

* Use the following algorithm for resolving the Config dir (in Environment Module): ** Check if system property xwiki.config.dir is set, if so, use it ** Otherwise default to the WEB-INF directory (same as now)

* Use the following algorithm for resolving the Data dir (in Environment Module): ** Check if system property xwiki.data.dir is set, if so, use it ** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as now) ** If no environment.permanentDirectory exists, then use the temporary directory (same as now)

* Don't provide a default value for environment.permanentDirectory in xwiki.properties

* Note that we probably need to modify a bit Environment module to add support for a Configuration directory (not sure yet about this need).

Use Cases Walkthrough ===================

UC1: * user unzips, that's all * in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and xwiki.data.dir=[homedir]/data * environment.permanentDirectory is not defined in xwiki.properties

UC2: * user unzips new version in another directory and copy the old data and config directories over * Note that this use case is not really a valid one since the standalone zip is not meant to be a production zip at the moment

UC3: * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to set environment.permanentDirectory (same as now) * however the recommendation is for the user to put it's XWiki config dir and data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties in his startup/stop scripts, thus making it easy for UC4

UC4: * users replaces the older WAR with the new WAR and if he has applied the recommendation from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file to set environment.permanentDirectory

WDYT?

This sounds good. I would suggest that the debian package be updated to better respect the FHS, using /etc and /var appropriately. So +1 for this with a strong filling we should extend it more to allow full compliance with FHS.

...

Thanks -Vincent

On Jun 2, 2012, at 4:06 PM, Thomas Mortagne wrote:

On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol <vincent@massol.net> wrote:

...

Hi devs,

This proposal is a restart of the thread I've sent, entitled "[Proposal] XWiki's Permanent Directory Strategy for Installations" in which I wasn't clear.

Executive Summary ================

Define 2 XWiki directories; one for holding configuration data and one for holding (permanent) data and allow various configurations for our distributions.

* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg, xwiki.properties, hibernate.cfg.xml * Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/, jetty log files

Rationale ========

This proposal below tries to answer the following general use cases: * Ability to easily backup an XWiki install * Ability to easily upgrade an XWiki install * Ability to install XWiki on various OSes, including OSes like Windows 7 which require a total separation of readonly binaries and generated data * Ability to have several instances of XWiki on the same machine

Note that I'm sending this email since I'm currently working on making our installer work on Windows 7 and I need an agreement on this before I can continue since I'm currently blocked.

Use Cases =========

The proposal below should allow the following use cases easily: UC1: use the standalone zip distribution UC2: upgrade a standalone zip distribution install UC3: Use the WAR production distribution UC4: Upgrade an existing WAR distribution

Short Term Proposal =================

* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir

* Use the following algorithm for resolving the Config dir (in Environment Module): ** Check if system property xwiki.config.dir is set, if so, use it ** Otherwise default to the WEB-INF directory (same as now)

* Use the following algorithm for resolving the Data dir (in Environment Module): ** Check if system property xwiki.data.dir is set, if so, use it ** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as now) ** If no environment.permanentDirectory exists, then use the temporary directory (same as now)

* Don't provide a default value for environment.permanentDirectory in xwiki.properties

* Note that we probably need to modify a bit Environment module to add support for a Configuration directory (not sure yet about this need).

Use Cases Walkthrough ===================

UC1: * user unzips, that's all * in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and xwiki.data.dir=[homedir]/data

There is something missing here. XWiki is not going to find anything in [homedir]/config obviously when starting so how does he knows about proper hsqldb configuration for example ? Is the configuration copied from the war the first time it starts ?

The zip contains everything. Its structure would be: [homedir]/ |_ data/ |_ config/ |_ jetty/ |_ webapps/ |_ start_xwiki.sh |_ … In the start/stop shell scripts, we will have: -Dxwiki.data.dir=data and -Dxwiki.config.dir=config Hope it's more clear :) Thanks -Vincent

...

* environment.permanentDirectory is not defined in xwiki.properties

UC2: * user unzips new version in another directory and copy the old data and config directories over * Note that this use case is not really a valid one since the standalone zip is not meant to be a production zip at the moment

UC3: * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to set environment.permanentDirectory (same as now) * however the recommendation is for the user to put it's XWiki config dir and data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties in his startup/stop scripts, thus making it easy for UC4

UC4: * users replaces the older WAR with the new WAR and if he has applied the recommendation from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file to set environment.permanentDirectory

WDYT?

Thanks -Vincent

+1 btw On Mon, Jun 4, 2012 at 10:41 AM, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:

On Mon, Jun 4, 2012 at 10:06 AM, Vincent Massol <vincent@massol.net> wrote:

...

On Jun 2, 2012, at 4:06 PM, Thomas Mortagne wrote:

...

On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol <vincent@massol.net> wrote:

...

Hi devs,

This proposal is a restart of the thread I've sent, entitled "[Proposal] XWiki's Permanent Directory Strategy for Installations" in which I wasn't clear.

Executive Summary ================

Define 2 XWiki directories; one for holding configuration data and one for holding (permanent) data and allow various configurations for our distributions.

* Config dir is where xwiki configuration files is located. Examples: xwiki.cfg, xwiki.properties, hibernate.cfg.xml * Data dir is where xwiki writes permanent data. Examples: database/, extension/ lucene/, jetty log files

Rationale ========

This proposal below tries to answer the following general use cases: * Ability to easily backup an XWiki install * Ability to easily upgrade an XWiki install * Ability to install XWiki on various OSes, including OSes like Windows 7 which require a total separation of readonly binaries and generated data * Ability to have several instances of XWiki on the same machine

Note that I'm sending this email since I'm currently working on making our installer work on Windows 7 and I need an agreement on this before I can continue since I'm currently blocked.

Use Cases =========

The proposal below should allow the following use cases easily: UC1: use the standalone zip distribution UC2: upgrade a standalone zip distribution install UC3: Use the WAR production distribution UC4: Upgrade an existing WAR distribution

Short Term Proposal =================

* Add 2 system property variables: xwiki.config.dir and xwiki.data.dir

* Use the following algorithm for resolving the Config dir (in Environment Module): ** Check if system property xwiki.config.dir is set, if so, use it ** Otherwise default to the WEB-INF directory (same as now)

* Use the following algorithm for resolving the Data dir (in Environment Module): ** Check if system property xwiki.data.dir is set, if so, use it ** Otherwise use value of environment.permanentDirectory in xwiki.properties (same as now) ** If no environment.permanentDirectory exists, then use the temporary directory (same as now)

* Don't provide a default value for environment.permanentDirectory in xwiki.properties

* Note that we probably need to modify a bit Environment module to add support for a Configuration directory (not sure yet about this need).

Use Cases Walkthrough ===================

UC1: * user unzips, that's all * in start/stop xwiki scripts we use xwiki.config.dir = [homedir]/config and xwiki.data.dir=[homedir]/data

There is something missing here. XWiki is not going to find anything in [homedir]/config obviously when starting so how does he knows about proper hsqldb configuration for example ? Is the configuration copied from the war the first time it starts ?

The zip contains everything. Its structure would be:

[homedir]/  |_ data/  |_ config/  |_ jetty/  |_ webapps/  |_ start_xwiki.sh  |_ …

In the start/stop shell scripts, we will have: -Dxwiki.data.dir=data and -Dxwiki.config.dir=config

Hope it's more clear :)

Yes, was actually understanding [homedir] as the user home directory (like the HOME env var on unix systems, not sure about its names on Windows).

...

Thanks -Vincent

...

...

* environment.permanentDirectory is not defined in xwiki.properties

UC2: * user unzips new version in another directory and copy the old data and config directories over * Note that this use case is not really a valid one since the standalone zip is not meant to be a production zip at the moment

UC3: * user deploys war in container's webapps dir and edits WEB-INF/xwiki.properties to set  environment.permanentDirectory (same as now) * however the recommendation is for the user to put it's XWiki config dir and data dir somewhere on his system and use the xwiki.config.dir and xwiki.data.dir system properties in his startup/stop scripts, thus making it easy for UC4

UC4: * users replaces the older WAR with the new WAR and if he has applied the recommendation from UC3 that's all he has to do. Otherwise he needs to edit the xwiki.properties file to set  environment.permanentDirectory

WDYT?

Thanks -Vincent

_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

-- Thomas Mortagne