Et dire que j’ai passé plusieurs jours sur ça …
M’étant mis à GIT récemment au taf, je me suis dit que c’était le bon moment pour me lancer dans l’installation d’un serveur de repositories un peu pimp, histoire d’éviter de se taper de la ligne de commande. Pas que j’ai quoi que ce soit contre la ligne de commande, s’pas ? Mais, honnêtement, je deviens fainéant, et je préfère avoir de l’interface graphique, autant que possible. C’est plus friendly quand-même.
Je connais deux solutions: GOGS (Go Git Service) et Gitlab. GOGS est en Go, il faudra que je me mette à ce langage. Un jour. Pour l’instant j’ai décidé de rester sur un truc “un peu plus standard” et de m’attaquer à Gitlab.
Voici un compte-rendu de l’installation, des problèmes que j’ai rencontré et des solutions que j’ai trouvé.
Installation du package
C’est un package qui n’est pas dans les repositories Debian, donc il faut ajouter à la main. Rien de sorcier, il suffit de suivre la procédure. Pourtant, il manque quelque chose avant de pouvoir se connecter à la page d’accueil. En effet, par défaut Gitlab embarque son propre serveur web, qui n’est autre que Nginx. Or, moi j’ai Apache déjà installé, donc on ne va pas être copains. Il faut configurer ça.
Configuration du serveur web
Situation : Gitlab m’a installé Nginx alors que j’ai déjà Apache sur le serveur. Il faut donc désactiver Nginx et configurer un virtual host sous Apache.
Désactiver Nginx
Ca se fait dans les fichiers de config de Gitlab, la procédure est décrite ici. Puis un coup de gitlab-ctl reconfigure, et on doit voir dans les messages que Nginx a été désactivé.
Configurer un virtualhost pour Gitlab sur Apache
On récupère les fichiers de config d’exemple pour Apache (2.2 dans mon cas) ici. On les copie dans /etc/apache2/sites-available et on remplace Your_SERVER_FQDN par l’adresse à laquelle on veut avoir Gitlab (gitlab.randagodron.eu dans mon cas). Normalement il faut aussi, bien entendu, configurer le NDD pour pointer dessus. Sauf si on est un gros bourrin dans mon genre et qu’on a mis un \*.randagodron.eu pour ne pas être emmerdé. Là, pas besoin.
Sur le fichier de config SSL (HTTPS donc), il faut aussi mettre les bon noms de fichiers de certificats et clés. Et donc les créer, idéalement, ou réutiliser un certificat d’un autre site. Perso, je vais créer un certficat spécifique pour ce sous-domaine. Là on suit n’importe quel tuto genre ça.
Note : en vrai j’ai un problème avec la version https, le certificat merdoie. C’est visiblement un problème avec Apache et la gestion de plusieurs certificats pour plusieurs sous-domaines. Il faudra que je règle ça, comprendre que je retrouve dans mes notes comment j’avais fait précédemment sur mes autres sous-domaines. Pas le temps de m’en occuper pour le moment, donc pas de https à court-terme le temps que je gère ça.
Puis le bazar habituel quand on créé un nouveau site avec Apache.
a2ensite gitlab-apache22.conf
a2ensite gitlab-ssl-apache22.conf
service apache2 restart
Maintenant on peut aller sur gitlab.randagodron.eu, on a la page d’accueil, on se loge avec les identifiants root par défaut, on change le mot de passe root, et on a un beau Gitlab qui marche, la vie est belle.
On va donc créer un utilisateur, et là "The password has been sent to the user by email".
Et là, doute. Yavait pas un problème avec les mails, genre, gros ? Check la boîte mail, rien reçu. Check les logs postfix : No route to host. Et meeeeerde.
Configuration postfix
Honnêtement, il y a deux façons de régler le problème.
- Configurer Gitlab pour qu’il n’envoie pas de mail et transmettre les mots de passe aux users à la main. Pas top.
- Faire fonctionner postfix.
Je suis du genre orgeuilleux, donc j’ai choisi la deuxième option.
Plusieurs problèmes se posent:
- Il faut configurer postfix d’une façon générale.
- Je suis chez Orange donc le port 25 est bloqué.
- Il faut ouvrir ~~les chakras~~ le port 25.
Pour la config postfix, voir ici un tuto pas dégueu. [EDIT] Attention ! Ne pas faire la config des adresses virtuelles ! Ça ne sert à rien.
Pour contourner le blocage du port 25 par Orange, encore une fois, deux possibilités:
- Passer par un autre port (587 en général).
- Passer par les serveurs SMTP Orange.
Je ne pense pas que la DCRI ait grand-chose à foutre des mails de mon Gitlab, et puis bon, ça leur fera du bruit à traiter en plus, j’ai donc choisi la facilité et la deuxième option ([EDIT] de toutes façons il semble que le serveur smtp d’Orange n’accepte pas les connexions sur ce port). Voir ça et ça. Sachant que la bonne adresse du relai SMTP c’est smtp.orange.fr (et pas sma-smtp.orange.fr comme on le trouve sur certains forums, de toutes façons un ping permet de vérifier que cette deuxième adresse est vide). On met son login / mdp orange, on hashe et on est bien.
Pour ouvrir le port 25, c’est dans UFW : ufw allow 25 ou ufw allow smtp.
[EDIT] Pour que ça marche, j’ai du désactiver toute la partie adresses virtuelles. Ca me mettait un bazar pas possible. Donc tous les items avec du “virtual” dans le fichier de config main.cf sont commentés. Il n’y a que le relayhost qui est défini (smtp.orange.fr:25), et les credentials associés.
On peut tester un envoi de mail, avec une commande du genre echo \"body of your email\" | mail -s \"This is a Subject\" -a \"From: you@example.com\" recipient@elsewhere.com
A partir de là, on peut créer des utilisateurs et ils vont automatiquement recevoir un mail leur demandant de mettre à jour leur mot de passe, comme ça le root n’a pas accès à leur mot de passe (sauf takeover).
A noter que j’ai découvert un site sympathique au cours de ces périples : https://www.mail-tester.com
Ça créée une adresse mail temporaire, sur laquelle on peut envoyer un message, ça nous dit si le message est reçu, et d’une façon générale ça donne une note pour savoir si un mail envoyé par ce biais est susceptible d’être bloqué (format, blacklist, etc).