Dans l’état des lieux des forges de l’ESR, il est apparu que la majorité des forges auto-hébergées de l’ESR sont des instances GitLab.
Ce document a vocation de partager les bonnes pratiques d’utilisation de ce logiciel dans le cadre de l’ESR.
Version imprimable multipages. Cliquer ici pour imprimer.
Dans l’état des lieux des forges de l’ESR, il est apparu que la majorité des forges auto-hébergées de l’ESR sont des instances GitLab.
Ce document a vocation de partager les bonnes pratiques d’utilisation de ce logiciel dans le cadre de l’ESR.
git bisect par exemple.
main, develop et feature dans un projet git.Il est possible de définir des limites sur le nombre de connexions authentifiées ou non authentifiées à GitLab, directement dans la console d’administration.
Ces limites sont désactivées par défaut. Il est conseillé de les activer.
Contribué par Mathrice.
Contribuée par Remy Dernat
Fichier /etc/fail2ban/filter.d/gitlab-llm-bots.conf:
[Definition]
failregex = <HOST> -.* "GET .*" 403.* ".*(AmazonBuyForMe|Amzn-SearchBot|Amzn-User|Anomura|ApifyBot|ApifyWebsiteContentCrawler|Aranet-SearchBot|AzureAI-SearchBot|Bravebot|BuddyBot|Channel3Bot|ChatGLM-Spider|Cloudflare-AutoRAG|Crawl4AI|DeepSeekBot|ExaBot|Google-Agent|Google-Firebase|Google-NotebookLM|IbouBot|KlaviyoAIBot|KunatoCrawler|LAIONDownloader|LCC|LingueeBot|LinkupBot|Manus-User|NotebookLM|Poggio-Citations|ShapBot|Spider|TavilyBot|TerraCotta|TwinAgent|WRTNBot|ZanistaBot|amazon-kendra|atlassian-bot|iAskBot|imageSpider|laion-huggingface-processor|meta-webindexer|webzio-extended|Grok|DeepSeekBot|OAI-AdsBot|Microsoft-Copilot|Googlebot-Genie|Databricks-Agent|GPTBot|ChatGPT-User|AppleBot-Extended|ClaudeBot|Claude-SearchBot|PerplexityBot|Perplexity-User|Google-Extended|OAI-SearchBot|AmazonBot|Meta-ExternalAgent|Bytespider|cohere-ai|DuckAssistBot|FacebookBot|Gemini-User|MistralAI-User|YouBot|CCBot).*"
# Alternative si le code statut n'est pas toujours présent ou si vous voulez juste capturer l'user-agent quel que soit le code
# Note: On utilise <HOST> au début pour capturer l'IP, et on cherche la chaîne dans le User-Agent (généralement après le code HTTP ou à la fin)
# Regex optimisée pour le format standard Nginx (Host - UserAgent [Date] "Request" Status "Referrer")
^<HOST> .+ ".*" .* ".*".*(AmazonBuyForMe|Amzn-SearchBot|Amzn-User|Anomura|ApifyBot|ApifyWebsiteContentCrawler|Aranet-SearchBot|AzureAI-SearchBot|Bravebot|BuddyBot|Channel3Bot|ChatGLM-Spider|Cloudflare-AutoRAG|Crawl4AI|DeepSeekBot|ExaBot|Google-Agent|Google-Firebase|Google-NotebookLM|IbouBot|KlaviyoAIBot|KunatoCrawler|LAIONDownloader|LCC|LingueeBot|LinkupBot|Manus-User|NotebookLM|Poggio-Citations|ShapBot|Spider|TavilyBot|TerraCotta|TwinAgent|WRTNBot|ZanistaBot|amazon-kendra|atlassian-bot|iAskBot|imageSpider|laion-huggingface-processor|meta-webindexer|webzio-extended|Grok|DeepSeekBot|OAI-AdsBot|Microsoft-Copilot|Googlebot-Genie|Databricks-Agent|GPTBot|ChatGPT-User|AppleBot-Extended|ClaudeBot|Claude-SearchBot|PerplexityBot|Perplexity-User|Google-Extended|OAI-SearchBot|AmazonBot|Meta-ExternalAgent|Bytespider|cohere-ai|DuckAssistBot|FacebookBot|Gemini-User|MistralAI-User|YouBot|CCBot).*$
ignoreregex =
Dans paths-common.conf rajouter :
gitlab_nginx_error_log = /var/log/gitlab/nginx/*error.log
gitlab_nginx_access_log = /var/log/gitlab/nginx/*access.log
Fichier /etc/fail2ban/jail.d/gitlab-llm-bots.conf :
[gitlab-llm-bots]
enabled = true
filter = gitlab-llm-bots
#logpath = /var/log/gitlab/nginx/gitlab_access.log
logpath = %(gitlab_nginx_access_log)s
maxretry = 1
findtime = 600
bantime = 86400
On teste avec
fail2ban-regex /var/log/gitlab/nginx/gitlab_access.log gitlab-llm-bots
puis
systemctl restart fail2ban.service
fail2ban-client status gitlab-llm-bots
tail -f /var/log/fail2ban.log | grep gitlab-llm-bots
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.
En plus de ces bonnes pratiques, il est important de s’adapter aux besoins spécifiques de votre équipe et de votre projet. Il n’y a pas de solution unique pour tous, et la meilleure façon d’organiser vos projets GitLab est de trouver ce qui fonctionne le mieux pour vous.
Voici quelques ressources supplémentaires qui pourraient vous être utiles :
Cette page regroupe des ressources pédagogiques sur les forges en général, des forges particulières, ou des composants spécifiques produites par des collègues.
Contact mail : biganzoli[at]laplace.univ-tlse.fr
Il s’agit de supports utilisés pour des enseignements à l’INSA de Toulouse.
N’hésitez pas à regarder dans les commentaires du présentateur (sous les slides), il y a plein d’info et de lien complémentaire pour approfondir le sujet :
Le CIRAD propose un ensemble de ressources concernant le fonctionnement de sa forge.