Après onze mois à l’essai j’ai enfin prit le temps de trouver une demeure définitive à mon Gitlab. En effet plus les mois passent, plus il est devenu indispensable dans ma vie de tous les jours. Il me permet de garder un historique de mes scripts, fichiers de configurations et autres projets sur lesquels je travaille.
Gitlab est une sur-couche à git écrite en ruby qui permet de faire tourner un serveur git à la github chez soi. Beaucoup plus complet que ce propose github (avis très personnel), il est parfait lorsque l’on veut maintenir de petits fichiers de configurations. Il peut être aussi utilisé en complément de Github comme je le fais, ainsi je partage mes projets avec beaucoup plus de monde. Pour plus d’information rendez-vous sur le site officiel www.gitlab.com. Si vous voulez vous lancer dans l’aventure je vous conseille la “comunauty edition”.
Préparation
Sur l’ancien serveur j’effectue une sauvegarde totale (base de données, dépôts …)
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
Par défaut celle-ci se trouve dans “/home/git/gitlab/tmp/backups”, c’est un fichier compressé qui ressemble à ça :
[TIMESTAMP]_gitlab_backup.tar #[TIMESTAMP] fait référence au moment de la sauvegarde
Je fais une copie de ce fichier pour plus tard, l’idée est de restaurer cette sauvegarde sur le nouveau serveur fraîchement installé. Se nouveau serveur sera installé à la même version que l’ancien, dans mon cas la 6.7.5. Lors de mes tentatives de restauration j’avais fait l’inverse, mais la migration ne s’est pas déroulée correctement.
Pour installer le nouveau serveur j’ai tout simplement suivit la documentation sur le site.
Migration
Première étape j’importe le fichier [TIMESTAMP]_gitlab_backup.tar dans le dossier /root. A ne pas copier directement dans le dossier /home/git/gitlab/tmp/backups cela changera les droits. Ensuite la migration est très simple :
cd /home/git/gitlab/tmp
#Création du dossier de sauvegarde
mkdir backups
#Copie du fichier de sauvegarde
cp /root/[TIMESTAMP]_gitlab_backup.tar /home/git/gitlab/tmp/backups/[TIMESTAMP]_gitlab_backup.tar
#Attribution des droits à l'utilisateur git
sudo chown -R git:git /home/git/gitlab/tmp/backups/[TIMESTAMP]_gitlab_backup.tar
#Lancement de la restauration
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production
Après quelques secondes la restauration est terminée. Tout y est la base de données, les utilisateurs, les dépôts, toutes les données de l’ancien serveur.
Maintenant tout le travail de configuration reste à faire, afin basculer définitivement sur le nouveau serveur.
Configuration post migration
Gitlab
Dans un premier temps il faut indiquer à gitlab l’url à utiliser pour l’interface web. Deux fichiers sont à modifier, je profite aussi de l’occasion pour activer les connexions ssl de mon futur serveur.
Le premier se trouve dans /home/git/gitlab/config/gitlab.yml – ATTENTION avec les fichiers en Yaml les espaces sont très important il faut les respecter scrupuleusement !
## GitLab settings
gitlab:
## Web server settings
host: url.monserveur.tld
port: 443
https: true #activation des connexions ssl
Le second se trouve dans /home/git/gitlab-shell/config.yml – ATTENTION avec les fichiers en Yaml les espaces sont très important il faut les respecter scrupuleusement !
# Url to gitlab instance. Used for api calls. Should be ends with slash.
gitlab_url: "https://url.monserveur.tld/"
Pour valider les modifications un redémarrage du service gitlab.
service gitlab restart
Un peu plus haut j’abordais l’activation du SSL pour l’interface web mais aussi pour toutes les communication avec git. J’ai créé un certificat de classe1 signé chez StartSSL. Par la suite je me suis trouvé dans l’obligation de le modifier pour l’utiliser avec Nginx. Depuis le site de startSSL j’ai récupéré le certificat, la clef non chiffrée et le certificat intermédiaire. Afin d’utiliser conjointement le certificat et l’intermédiaire dans nginx il faut les combiner.
cat gitlab_ssl.crt sub.class.server.ca.pem > gitlab.combined.crt
Nginx
Activation des connexions ssl nginx. D’abords créer une sauvegarde de l’ancien fichier.
mv /etc/nginx/sites-available/gitlab /etc/nginx/sites-available/gitlab_bak
Pour récupérer le nouveau fichier :
git clone https://labo.olivierdelort.net/colmaris/gitlab-recipes.git
Ce fichier réécrit les requêtes entrantes sur le port 80 vers le port 443, de plus il corrige l’erreur 400 Bad request que j’ai eu lors du premier démarrage.
ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
service nginx restart
Hop un nouveau lien symbolique vers les sites activés, et je relance nginx.
Lors de ma première connexion j’ai retrouvé tous mes utilisateurs, les dépôts, comme si de rien n’était. Je dois encore mettre à jour mon nouveau serveur et profiter des dernières nouveautés de la 7.3.0 au moment où j’écris ses lignes.
Original post of Olivier Delort.Votez pour ce billet sur Planet Libre.
Un chemspill (pour « chemical spill », qu’on peut traduire par « fuite chimique ») est une parution de Firefox ou SeaMonkey faite en dehors du calendrier classique de 6 semaines ou hors calendrier pour Thunderbird. Il est souvent fait à la suite de la découverte d’un bogue sérieux ou d’un problème de sécurité public. Hier, Mozilla a réagi à la découverte d’une 
