Upgrading Debian Packages from Xwiki LTS Tomcat8 to Xwiki LTS Tomcat 9

Hi everyone,

I wish you a happy new year in a few hours! Get into 2020 well and don’t party tooooo hard. :wink:

Yesterday I finally upgraded my Debian servers from Stretch to Buster.

Buster does not contain Tomcat8 any more, so I thought it would be a good opportunity to also switch Xwiki from Tomcat 8 to 9.

Unfortunately, in https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation/InstallationViaAPT/ there are not any upgrading instructions to do so, and simply installing xwiki-tomcat9-mysql and adjusting the Tomcat server ports does not do the trick.

One thing I quickly figured out was that the data directory previously belonged to the tomcat8 user, but now has to be owned by the tomcat user (without any version indicator).

This still does not help, though, Xwiki spits out tons of Solr errors due to attachments which cannot be found and just presents a white page during login.

Before I post logs indicating that I missed the most basic adjustments, I’ll try it differently: Is switching from Tomcat8 to Tomcat9 a supported upgrade path (and if not, what should I do?) and if so, what are the basic requirements and upgrade steps I need to perform?



I don’t see any reason why not since XWiki does not really care much about the application server.

Just installing xwiki-tomcat9-mysql should do the job so I’m surprised you have issues.

This should not be a problem thanks to

Where is it searching the attachments it cannot find ?

Ok, then I’ll have a closer look…

Ok, obvious that this didn’t work - my xwiki data directory is somewhere else.

(BTW, why does the syntax chown -R tomcat.tomcat ... work - I didn’t know it and the manpage only seems to document : instead of . to separate username from group. Your syntax also seems to work, though.)

On a second look, Xwiki also still is not happy after I chowned the directory (the need of which was obvious from the first log messages of Xwiki).

It still logs

[2019-12-31 16:05:49] [info] 2019-12-31 16:05:49,263 [main] ERROR o.x.e.i.ServletEnvironment     - Configured permanent directory [/mnt/cstore/var_lib_xwiki/data] is not writable.
[2019-12-31 16:05:49] [info] 2019-12-31 16:05:49,264 [main] WARN  o.x.e.i.ServletEnvironment     - Falling back on [/var/cache/tomcat9/Catalina/localhost/xwiki] as the permanent directory.
[2019-12-31 16:05:49] [info] 2019-12-31 16:05:49,265 [main] INFO  o.x.e.i.ServletEnvironment     - Using permanent directory [/var/cache/tomcat9/Catalina/localhost/xwiki]

Then it’s also clear that Solr cannot find anything meaningful there.

Some googling lead me to Permanent directory is ignored and data is in Tomcat work directory - #7 by g3poandlsl, so apparently I’m not the first one bitten by this…

I’ll try to fix this and report back.

The solution to this issue is detailed here:

Summary: The Debian tomcat9 package uses systemd sandboxing features and disallows writing to most directories by default.

You are right, that’s the syntax I have been using for the last 15 years but the man page does not mention it indeed (at least on Ubuntu 19.10). Maybe it’s some deprecated syntax. I will check a few other systems and change it.

FirsI’m pretty sure the Tomcat 9 based package have been working just fine recently so maybe it’s specific to Debian Buster (but even that I think someone reported using Tomcat 9 package on Buster).

Would be great if you could create an issue on Loading... with everything related to can think of. If it’s the default now we’ll have to do something about it I guess.

Actually I created and hopefully fixed Loading....

I added a comment there:

Does your fix consider the case that someone successfully made a fresh install of Xwiki with Tomcat9, not even noticing that Xwiki fell back to using the Tomcat cache directory as its “permanent” directory?
If your fix just allows Xwiki to write to the actually configured permanent directory, all files stored so far in such installations will be “lost”. (Actually they probably still will reside in the cache directory, but the user will not know about it and will have no idea she/he even has to look for the files somewhere else!)
Is it really a good idea to fall back to another directory if the configured one is not writeable for some reason, or wouldn’t it be better to make this a critical failure and refuse to start Xwiki at all in this case? Then the user at least notices that something unexpected is going on…