Migrating from gitlab mattermost to stand-alone

Troubleshooting
1

is there a way I can isolate Mattermost from Gitlab? I already have a production instance of Gitlab mattermost, and I dont want to lose the data with a fresh install of stand-alone mattermost.

It has become cumbersome to upgrade mattermost when gitlab is skipping versions. I dont update gitlab regularly, so when I update after 2 or 3 releases, it skips intermediate versions adn mattermost doesnt like that. Now, I’m not able to fix this situation. I’d rather have Mattermost separate so that I can keep its upgrade cycle independent from gitlab’s.

Any help? Thanks.

2

Hi @kirthi,

We just added a Migration Guide that gives instructions for moving Mattermost to a fresh installation.

We also plan to add support for skipping versions when upgrading, which should be in v1.5 or v1.6.

3

Hi!
I’m going through the same thing. The migration really seems to have gone well, however, I no longer want to log in via Gitlab, since my (new) Mattermost installation is on a separate server. Is there a way I can convert my old (Gitlab) users to “regular” users?

4

Hi @olegblecher,

just being on a separate server does not sound like that big of an argument for migrating from gitlab auth so something else. Depending on your target backend you can do that with the platform command, though:

Usage:
  platform user migrate_auth [from_auth] [to_auth] [migration-options] [flags]

Examples:
  user migrate_auth email saml users.json

Arguments:
  from_auth:
    The authentication service to migrate users accounts from.
    Supported options: email, gitlab, ldap, saml.

  to_auth:
    The authentication service to migrate users to.
    Supported options: ldap, saml.

  migration-options:
    Migration specific options, full command help for more information.

Flags:
      --auto     Automatically migrate all users. Assumes the usernames and emails are identical between Mattermost and SAML services. (saml only)
      --dryRun   Run a simulation of the migration process without changing the database.
      --force    Force the migration to occur even if there are duplicates on the LDAP server. Duplicates will not be migrated. (ldap only)
  -h, --help     help for migrate_auth

Global Flags:
  -c, --config string        Configuration file to use. (default "config.json")
      --disableconfigwatch   When set config.json will not be loaded from disk when the file is changed.
5

@olegblecher In addition to doing it from the CLI, individual users can switch their account type from the Sign-in Method section of the Account Settings > Security page.

6

Hi, thank you for your replies @hmhealey and @fbartels!

Unfortunately, platform user migrate_auth can only convert to ldap or saml, I would like to change it to email.

Account Settings > Security doesn’t show any options for modifying the Sign-In Method, and after googling around it seems that it’s a pretty common problem.

Could it have to do with the fact that Gitlab uses LDAP-authentication it its own turn?

I have managed to make a little work-around: simply change “gitlab” to “email” in the database dump itself, before importing it to the new host. After that, user platform user password, and voila, the login works perfectly. I hope it doesn’t brake anything though… Any suggestions, or will that just have to do?

7

You might need to turn on account creation and sign-in with email (and possibly sign-in with username if you want that) before the option in Account Settings appears. Those are found in the Authentication > Email section of the System Console. More info on those settings is available in our docs.

As for changing them in bulk through the database, changing the AuthService field in the Users table should work, but be sure to back up your database first just in case it breaks something. Also instead of using the CLI, the users could use the “I forgot my password” option on the sign in page to reset their password as well.