On Fri, Jun 1, 2012 at 3:30 PM, Vincent Massol <[email protected]> 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. > > 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 ? > > 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 > > > > > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
