XWiki LTS 16.10 -> 17.10 Debian Jetty Package Upgrade

Help / Discuss
1

While attempting to update to 16.10.16, I accidentally updated to 17.10.2, because 16.10.16 was not in the LTS repository any more, and thus my apt pin failed. Whoops.

I might have preponed the upgrade to 17.10.2 due to this, bug the problem is, I couldn’t get it to work.

While 16.10.x updates are always flawless, after the 17.10.2 upgrade the Xwiki server started and reported success in the jetty log (`Server gestartet, können Sie nun http://collab.example.com:1234/ in Ihrem Browser öffnen, um auf Ihr Wiki zuzugreifen`). However when accessing this page, any attempt to connect to the DB failed:

2026-01-08 22:41:47,029 [XWiki initialization] INFO  .HibernateDataMigrationManager - Storage schema updates and data migrations are enabled 
2026-01-08 22:41:47,149 [XWiki initialization] INFO  .HibernateDataMigrationManager - The following data migration(s) will be applied for wiki [xwiki] currently in version [160500000]: 
2026-01-08 22:41:47,149 [XWiki initialization] INFO  .HibernateDataMigrationManager -   R170400000XWIKI23160 - Cleanup XWikiProperties fields used as templates when they match the default values. 
2026-01-08 22:41:47,150 [XWiki initialization] INFO  .HibernateDataMigrationManager - Checking Hibernate mapping and updating schema if needed for wiki [xwiki] 
2026-01-08 22:41:47,315 [XWiki initialization] WARN  o.m.j.m.s.ErrorPacket          - Error: 1227-42000: Access denied; you need (at least one of) the PROCESS privilege(s) for this operation 
2026-01-08 22:41:47,317 [XWiki initialization] WARN  o.h.e.j.s.SqlExceptionHelper   - SQL Error: 1227, SQLState: 42000 
2026-01-08 22:41:47,317 [XWiki initialization] ERROR o.h.e.j.s.SqlExceptionHelper   - (conn=117468) Access denied; you need (at least one of) the PROCESS privilege(s) for this operation 
2026-01-08 22:41:47,323 [XWiki initialization] ERROR .HibernateDataMigrationManager - Failed to migrate database [xwiki]... 
com.xpn.xwiki.store.migration.DataMigrationException: Unable to update schema of wiki [xwiki]
(...)
Caused by: java.sql.SQLSyntaxErrorException: (conn=117468) Access denied; you need (at least one of) the PROCESS privilege(s) for this operation
        at org.mariadb.jdbc.export.ExceptionFactory.createException(ExceptionFactory.java:309)
        at org.mariadb.jdbc.export.ExceptionFactory.create(ExceptionFactory.java:403)
        at org.mariadb.jdbc.message.ClientMessage.readPacket(ClientMessage.java:196)
        at org.mariadb.jdbc.client.impl.StandardClient.readPacket(StandardClient.java:1411)
        at org.mariadb.jdbc.client.impl.StandardClient.readResults(StandardClient.java:1350)
        at org.mariadb.jdbc.client.impl.StandardClient.readResponse(StandardClient.java:1269)
        at org.mariadb.jdbc.client.impl.StandardClient.execute(StandardClient.java:1193)
        at org.mariadb.jdbc.ClientPreparedStatement.executeInternal(ClientPreparedStatement.java:91)
        at org.mariadb.jdbc.ClientPreparedStatement.executeQuery(ClientPreparedStatement.java:290)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:123)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:123)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:123)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:57)
        ... 57 common frames omitted

As far as I can tell, there were no merge errors in the DB config (`xwiki.cfg` and/or `hibernate.cfg.xml`).

XWiki Jetty Debian packages from XWiki SAS, MariaDB as DBMS.

I even enhanced my XWiki DB user’s permissions to `GRANT ALL TO …` in order to resolve the error, with no changes.

Fortunately, the failure was so complete that it wasn’t able to touch the schema - so I was able to downgrade XWiki to 16.10.16, and it immediately worked again like a charm.

I browsed through the upgrade documentation, but wasn’t able to immediately identify what I missed. Before spending hours on debugging, I thought that maybe someone already managed to resolve this or otherwise has an idea what may have changed in XWiki 17.10 which I need to consider to successfully upgrade…

Thanks a lot in advance, pointers to relevant documentation are also highly welcome.

2

Which Debian package are you using ? xwiki-xjetty-mariadb ?

There should not be much different between 17.10.2 and 16.10.16 at this level, except possibly a different version of the DB connector, which might have some regression. We upgraded myxwiki.org and xwiki.org to 17.10.2 Debian package (Tomcat here and not XJetty, but should not have any impact for the database side of things, which is provided by the same Debian package) and they are working fine.

It could be interesting to check the /etc/xwiki/hibernate.cfg.xml file you end up with after the upgrade, to see if it’s not broken in some way (maybe you customized it and the merge did not go well).

3

@tmortagne: I use the following packages:

# dpkg -l | egrep xwiki
ii  xwiki-common                            16.10.16                             all          XWiki is a free wiki software platform written in Java with a design emphasis
ii  xwiki-mariadb-common                    16.10.16                             all          XWiki is a free wiki software platform written in Java with a design emphasis
ii  xwiki-xjetty-common                     16.10.16                             all          XWiki is a free wiki software platform written in Java with a design emphasis
ii  xwiki-xjetty-mariadb                    16.10.16                             all          XWiki is a free wiki software platform written in Java with a design emphasis
#

Regarding the hibernate.cfg.xml, IIRC it was merged, but successfully by Debian’s 3-way-config-file merge during installation, and it didn’t “look” broken to me (I check config files after merge operations).

However, I’ll retry the upgrade, possibly on the weekend, and keep an extra eye on the DB configuration to see why it’s using the default XWiki DB name instead of the correct name configured by us.

Maybe something still went wrong with config file merge after all…

4

Are you saying that the root problem is that it’s trying to access the database xwiki ? It’s not really explicit in your first message.

In theory this is controlled by both the connection URL in /etc/xwiki/hibernate.conf.xml and the property xwiki.db in /etc/xwiki/xwiki.cfg and if all that is correct then maybe there is a regression we did notice yet (custom main wiki database is not something which is done that much).

5

@tmortagne: Ah, sorry - I meanwhile also asked through a support ticket via our bronce support contract, referring to this posting, and they noticed that the logs didn’t match the DB name I had given them.

I thought you were made aware of this posting by your support team member, so didn’t explicitly mention it here, but maybe this was just a coincidence.

So, yes, apparently XWiki 17.10 tries to use the wrong DB name, which indeed will lead to this error as the (also custom-named) XWiki DB user has full permission on our actual XWiki database, but not on the (non existing) database called `xwiki`.

I’ll try to cross check on the weekend if it’s really a configuration problem on my side, or if XWiki tries to use the `xwiki` database even though it’s configured differently. In the latter case I’ll open a Jira bugreport.

2 Likes
6

@tmortagne: I just made another upgrade attempt.

`xwiki.cfg` and `hibernate.cfg.xml` seem to have been upgraded just fine - see the diffs to backup copies I made immediately beforehand:

root@XXX:/etc/xwiki# diff -u xwiki.cfg.16.10.16 xwiki.cfg
--- xwiki.cfg.16.10.16  2026-01-08 22:48:15.591186725 +0100
+++ xwiki.cfg   2026-01-18 21:11:23.747993242 +0100
@@ -440,7 +440,6 @@
   com.xpn.xwiki.plugin.skinx.CssResourceSkinExtensionPlugin,\
   com.xpn.xwiki.plugin.skinx.LinkExtensionPlugin,\
   com.xpn.xwiki.plugin.feed.FeedPlugin,\
-  com.xpn.xwiki.plugin.mail.MailPlugin,\
   com.xpn.xwiki.plugin.packaging.PackagePlugin,\
   com.xpn.xwiki.plugin.fileupload.FileUploadPlugin,\
   com.xpn.xwiki.plugin.image.ImagePlugin,\
root@XXX:/etc/xwiki# diff -u hibernate.cfg.xml.16.10.16 hibernate.cfg.xml
--- hibernate.cfg.xml.16.10.16  2026-01-08 22:48:22.939548022 +0100
+++ hibernate.cfg.xml   2026-01-18 21:11:32.280413757 +0100
@@ -105,6 +105,15 @@
     <property name="hibernate.connection.driver_class">org.mariadb.jdbc.Driver</property>
     <property name="hibernate.dbcp.poolPreparedStatements">true</property>
     <property name="hibernate.dbcp.maxOpenPreparedStatements">20</property>
+    <!-- Control whether or not the compression of some tables (like the history table) is enabled.
+         The default behavior depends on the database, currently:
+         * enabled by default for MySQL/MariaDB
+         * disabled by default for Oracle
+         * this property has no effect in other databases
+     -->
+    <!--
+    <property name="xwiki.compressionAllowed">true</property>
+    -->
 
     <property name="hibernate.connection.charSet">UTF-8</property>
     <property name="hibernate.connection.useUnicode">true</property>
@@ -225,6 +234,7 @@
              see https://community.jboss.org/wiki/HibernateCoreMigrationGuide36
            - if you want the main wiki schema to be different than "xwiki"
              you will also have to set the property xwiki.db in xwiki.cfg file
+           - switch the xwiki.compressionAllowed property to true if compression is enabled in Oracle
 
     <property name="hibernate.connection.url">jdbc:oracle:thin:@localhost:1521:XE</property>
     <property name="hibernate.connection.username">xwiki</property>
root@collab:/etc/xwiki#

The `hibernate.connection.url` lists the correct DB name, as well as the `xwiki.db` property in `xwiki.cfg`. (No surprise, as the file’s don’t have changes at these places compared to the previous state, as can be seen in the diffs.)

However, if the DB name written to the log is the actual DB name - and not just a placeholder for “XWiki database”, which I assumed previously - then it’s really trying to migrate the incorrect DB again (i.e. DB called `xwiki` instead of the proper name).

I had assumed that the logged name is just a placeholder name for “XWiki DB” instead of the actually configured name, but according to the support team member, it’s really the actual DB name.

7

If the log you have in mind is Unable to update schema of wiki [xwiki], then your first assumption is correct and this is the wiki identifier, not the database name.

@nikpetrenko shared with me the full log, but I don’t see the database name in there, unfortunately.

Another things I see in the full log (or more accurately, deduce) is that the query which fail is

SELECT DISTINCT NAME, ROW_FORMAT FROM information_schema.INNODB_SYS_TABLES WHERE LOWER(NAME) LIKE 'thedatabasename/%'

So more of a global query, not targeting the XWiki database. So the lack of right is apparently on database information_schema. This is indeed a new step in the upgrade (but also on install) and I did not think about the use cases where XWiki is not allowed to access the global metadata table. Might need to find another way to list the row formats of the database tables…

8

@tmortagne: Ok, after granting

GRANT PROCESS ON *.* TO ``my_xwiki_username@127.0.0.1``;

I was able to perform the update. (Only granting the PROCESS privilege on a specific DB like information_schema is not possible, but also would not make sense in the context of this privilege.)

However, the MySQL documentations warn about the PROCESS privilege:

With the PROCESS privilege, a user has access to information about all threads, even those belonging to other users.

PROCESS can be used to view the plain text of currently executing statements, including statements that set or change passwords.

The MariaDB documentation does not seem to warn that explicitly about it, but I assume the behaviour is the same. (Not checked.)

There seem to be specific DB security audits implemented which require non-admin users not to have PROCESS privilege also in MariaDB: 5.3 Ensure 'PROCESS' is Not Granted to Non-Administrative Users<!-- --> | Tenable®