Fresh install - Incorrect groups auto-increment configuration!

[mightymicke]

Describe the bug
When run the setup I get this error msg,
"Incorrect groups auto-increment configuration! Should start at 0 and increment by 1. Contact your database administrator".

To Reproduce
Steps to reproduce the behavior:

1. Fresh install the lastest version
2. Start the server.
3. Access the setup guide via webgui on port 3000
4. Add the information and press "install"
5. See error

Screenshots

Host Info (please complete the following information):

• OS: CentOS 8
• Wiki.js version: 2.1.113
• Database engine: 10.3.17-MariaDB MariaDB Server

[NGPixel]

Does your MariaDB server have a custom configuration for auto-increment?

[mightymicke]

I don't know how to change it, or if I can have an custom conf for AUTO_INCREMENT.

This info is from "MariaDB Server Documentation",
The AUTO_INCREMENT attribute can be used to generate a unique identity for new rows. When you insert a new record to the table, and the auto_increment field is NULL or DEFAULT, the value will automatically be incremented. This also applies to 0, unless the NO_AUTO_VALUE_ON_ZERO SQL_MODE is enabled.

AUTO_INCREMENT columns start from 1 by default. The automatically generated value can never be lower than 0.

https://mariadb.com/kb/en/auto_increment/

[jhd85]

I also seem to have this same issue. I have a mariadb galera cluster version 10.4.12. Did not do anything to the auto increment setting. Are there other setting than NO_AUTO_VALUE_ON_ZERO? I do not have NO_AUTO_VALUE_ON_ZERO enabled btw.

[fenice2]

I'm also seeing this problem, I'm using Percona MySQL 8 galera cluster 8.0.19-10.1 for the back-end - that's a CentOS 8 server.

[NiceGuyIT]

The problem is how Galera handles AUTO_INCREMENT in a cluster. It's best described in Auto increments in Galera. TL/DR: if two transactions are started on separate nodes, the first transaction will succeed but the second one will fail because they both received the same AUTO_INCREMENT ID.

The AUTO_INCREMENT docs have the following to say:

To make master-master or Galera safe to use AUTO_INCREMENT one should use the system variables auto_increment_increment and auto_increment_offset to generate unique values for each server.

This is confirmed by running this on one of the nodes. I'm running a 3 node cluster.

$ echo 'SHOW VARIABLES like "auto_increment%";' | mysql
Variable_name   Value
auto_increment_increment        3
auto_increment_offset   1

My first attempt at overcoming this is changing setup.js to check for the new IDs.

      if (adminGroup.id !== 3 || guestGroup.id !== 6) {
        throw new Error('Incorrect groups auto-increment configuration! Should start at 0 and increment by 1. Contact your database administrator.')
      }
...
      if (adminUser.id !== 3 || guestUser.id !== 6) {
        throw new Error('Incorrect users auto-increment configuration! Should start at 0 and increment by 1. Contact your database administrator.')
      }

That did not work because the application is checking for hard-coded IDs with findById().

  static async getGuestUser () {
    const user = await WIKI.models.users.query().findById(2).withGraphJoined('groups').modifyGraph('groups', builder => {
      builder.select('groups.id', 'permissions')
    })
    if (!user) {
      WIKI.logger.error('CRITICAL ERROR: Guest user is missing!')
      process.exit(1)
    }
    user.permissions = user.getGlobalPermissions()
    return user
  }

  static async getRootUser () {
    let user = await WIKI.models.users.query().findById(1)
    if (!user) {
      WIKI.logger.error('CRITICAL ERROR: Root Administrator user is missing!')
      process.exit(1)
    }
    user.permissions = ['manage:system']
    return user
  }

The next attempt was to set the INSERT_ID before inserting the user and groups.

      // Create default groups

      WIKI.logger.info('Creating default groups...')
      await WIKI.models.knex.raw('SET INSERT_ID = 1')
      const adminGroup = await WIKI.models.groups.query().insert({
        name: 'Administrators',
        permissions: JSON.stringify(['manage:system']),
        pageRules: JSON.stringify([]),
        isSystem: true
      })
      await WIKI.models.knex.raw('SET INSERT_ID = 2')
      const guestGroup = await WIKI.models.groups.query().insert({
        name: 'Guests',
        permissions: JSON.stringify(['read:pages', 'read:assets', 'read:comments']),
        pageRules: JSON.stringify([
          { id: 'guest', roles: ['read:pages', 'read:assets', 'read:comments'], match: 'START', deny: false, path: '', locales: [] }
        ]),
        isSystem: true
      })
...

      // Create root administrator
      WIKI.logger.info('Creating root administrator...')
      await WIKI.models.knex.raw('SET INSERT_ID = 1')
      const adminUser = await WIKI.models.users.query().insert({
...

      // Create Guest account
      await WIKI.models.knex.raw('SET INSERT_ID = 2')
      WIKI.logger.info('Creating guest account...')
      const guestUser = await WIKI.models.users.query().insert({

This allowed Wiki.js to finish the setup. I was able to login and create the home page. Only time will tell if this solution has unforeseen consequences.

Note: I can add a diff if needed. I figured you can tell the context from the surrounding lines.

[NGPixel]

@NiceGuyIT While the root admin can technically be any ID, the guest user MUST have ID 2. Any other value will lead to major errors across the software.

[Sh1nto]

I ran into the same problem with Galera Cluster. If it's mandatory, the suggested solution from NiceGuyIT should be added. I disabled the the auto increment control

wsrep_auto_increment_control= off

And set Autoincrement 1. Then i did the setup and activated it again. This doesn't work for productive cluster,... so please make a patch.

[LeDistordu]

Hi, Are there any plans to patch this problem? Impossible for us to deploy wikijs without a DB cluster, while we want to migrate our mediawiki.

[NGPixel]

v3 will no longer rely on hardcoded ID 2 for guests.

[s-thoeni]

Sadly I am also unable to use wiki.js because we use a Galera Cluster in our company.