Migrer vers de Mattermost omnibus à Mattermost Standalone

Contribué par Pablo Rauzy

Le tuto officiel est là : https://docs.mattermost.com/administration-guide/onboard/migrate-gitlab-omnibus.html

Bon, installer postgres, ça va. Ensuite, étape par étape :

Step 1 : pour que ça fonctionne correctement j’ai dû virer le “–owner” et mettre “-d” à la place.

sudo gitlab-psql -- /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql -d mattermost_production | gzip > mattermost_dbdump_$(date --rfc-3339=date).sql.gz

Step 2 : dans le sous-tuto de préparation de la base de donnée, en fait la commande “locale-gen” ignore complètement ses arguments, c’est dans /etc/locale.gen qu’il faut aller décommenter la ligne en_US.UTF-8 avant le lancer la commande. Et ce n’est pas précisé mais il faut bien s’arrêter dans le sous-tuto avant “File storage preparation”, ne faire que la partie “Database preparation”, sinon y a des commandes plus tard qui ne fonctionnent pas.

Step 3 : ce n’est pas dit mais dans le dump il y a plein de “ALTER … OWNER TO gitlab_mattermost” qui vont échouer, faut les récupérer après coup (avec zgrep par exemple) pour les effectuer quand même et remplacer “gitlab_mattermost” par “mmuser”, si on suit les noms du tutoriel de migration.

Step 4 : il faut faire l’étape 5 avant, sinon on a le choix de modifier un fichier de config qui n’existe pas et qu’on va écraser à l’étape d’après, ou de modifier un fichier de config de façon incohérente…

Step 5 :

5.1 : Le bon tuto est là : https://docs.mattermost.com/deployment-guide/server/deploy-linux.html Attention avec Mattermost 11 on a une limite d’utilisateurs ridiculement petite et on a plus le SSO sur le GitLab, si on veut conserver ça faut prendre la dernière version ESR de la v10. Pour ça faut juste remplacer la version à télécharger par “Mattermost Team Edition v10.11.20 Extended Support Release (ESR)” qu’on trouve ici : https://docs.mattermost.com/product-overview/version-archive.html Il faut faire les étapes 3 “Download” et 4 “Install Mattermost server” uniquement, et dans la 4 il ne faut pas faire l’étape 4.3 où ont créé le dossier “data”, ou si on le fait faire gaffe plus bas quand on sera de retour à l’étape 4 du tuto migration.

5.2 : si l’installation se fait sur le même serveur pas besoin de faire toute la danse avec /tmp et scp, et c’est possible de juste faire un mv plutôt que de cp (ce qui peut être long). Attention si on suit leur commande on peut se retrouver avec le dossier de données dans le dossier /opt/mattermost/data plutôt que ce dernier soit le dossier de données. Et le fichier de config de GitLab Mattermost n’est pas à l’emplacement indiqué… (un dossier “config” de trop dans le tuto). Ce que je recommande de faire c’est simplement les deux commandes suivantes :

sudo cp /var/opt/gitlab/mattermost/config.json /opt/mattermost/config/
sudo mv /var/opt/gitlab/mattermost/data /opt/mattermost/data

(pour nous le dossier /opt/mattermost/data n’existe pas donc c’est bon, mais si il existe comme devrait le supposer le tutoriel puisqu’on l’a créé en 4.3 du tuto d’installation qu’on a suivi à l’étape 5.1 du tuto migration, ne pas l’indiquer à la fin du chemin de destination, sinon on se retrouve avec un dossier data dans le dossier data).

5.3 : là c’est bon on peut suivre !

Retour à l’étape 4 !

Step 4 : Ce n’est dit nul part dans le tutoriel mais en plus de modifier la config DataSource pour pointer vers la nouvelle base de données, faut aussi modifier la config “Directory” pour pointer vers le nouveau dossier où il y a les data (pour mettre “/opt/mattermost/data” à la place de “/var/opt/gitlab/mattermost/data”.

Et voilà c’est… quasi terminé, avant de tout relancer faut quand même indiquer au nginx de GitLab que le nouveau Mattermost existe, et lui faire gérer les certificats, ce qui n’est dit nul part non plus… Pour ça (en remplaçant partout “MATTERMOSTDOMAIN” par votre domaine pour Mattermost et GITLABDOMAIN par votre domaine GitLab) :

Dans gitlab.rb :

gitlab_rails['mattermost_host'] = "https://MATTERMOSTDOMAIN"
letsencrypt['alt_names'] = [… 'MATTERMOSTDOMAIN']

(y a pas littéralement “…” c’est juste pour dire qu’il faut l’ajouter à la liste existante)

Et ajouter un fichier pour Mattermost dans /etc/gitlab/nginx/sites-available/

Chez moi par exemple :

server {
    server_name MATTERMOSTDOMAIN;

    location / {
        proxy_pass http://127.0.0.1:8065;
        client_max_body_size 100M;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Frame-Options SAMEORIGIN;
        proxy_buffers 256 16k;
        proxy_buffer_size 16k;
        proxy_read_timeout 600s;
        proxy_http_version 1.1;
    }

    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    ssl_certificate /etc/gitlab/ssl/GITLABDOMAIN.crt;
    ssl_certificate_key /etc/gitlab/ssl/GITLABDOMAIN.key;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

Puis dans /etc/gitlab/nginx/sites-enabled/ mettre un lien symbolique vers ce fichier qui est dans ../sites-available/

Maintenant, tout relancer, le Mattermost standalone et le GitLab. Normalement tout devrait aller bien.