Bonjour à tou.te.s,
J'essaie d'installer Gitlab sur un réseau local, tout se passe bien mais lorsque j'essaie d'y accéder depuis firefox, l'écran reste blanc (pas de message d'erreur).
Voici ma procédure d'installation :
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo EXTERNAL_URL="http://gitlab.ip_serveur" apt install gitlab-ceComme je suis en local et que je n'ai pas de firewall configuré, je n'ai rien configuré d'autre.
sudo gitlab-ctl status ne renvoie par de défaut.
Est-ce que le problème peut venir du fait que le sous-domaine gitlab n'existe pas réellement?
Ou bien du fait que j'ai apache2 et nginx (installé par gitlab) qui tourne en parallèle?
# suivi le mode d'emploi ?
Posté par NeoX . Évalué à 3.
entre le curl et le sudo, il est précisé que tu dois avoir un domaine qui va faire pointer ton gitlab.ip_serveur vers la machine ou tu es en train d'installer le gitlab-ce
est-ce le ca ?
si tu n'as pas de domaine, la EXTERNAL_URL sera http://ip_de_ton_serveur
ex : http://192.168.0.124 si ton serveur est sur l'IP 192.168.0.124
à adapter chez toi évidemment
# Méthode d’installation alternative
Posté par vv222 (site web personnel) . Évalué à 7.
J’ai eu l’occasion d’installer de multiples instances de GitLab sur des bases Debian, et d’en migrer entre différentes machines.
Par contre, je ne suis pas pour ça la méthode à laquelle tu fais référence (Omnibus, fournissant GitLab et toutes ses dépendances dans un paquet "fourre-tout") mais la méthode proposée chez Debian se basant sur les paquets fournis par la distribution : gitlab - Buster Fast Track (Recommended) - Debian Wiki
La base utilisée est une Debian stable, et les paquets du systèmes sont utilisés autant que possible, en particulier pour nginx, PostgreSQL, les gems Ruby, les paquets Node.js… Ce qui évite de devoir faire confiance à l’équipe de GitLab pour maintenir tout ça en plus de GitLab lui-même.
[^] # Re: Méthode d’installation alternative
Posté par moi1392 . Évalué à 3.
J'ai utilisé gitlab fasttrack un moment, mais j'en suis revenu.
La raison principale est que la personnalisation de pas mal de choses fait que tu ne trouves que très difficilement de l'aide aux problèmes que tu as quand tu fais des recherches en ligne.
Je n'arrivais pas à faire fonctionner plusieurs fonctionnalités de base que j'estime importantes.
Je conçois bien que c'est plus du à mon incompétence qu'à autre chose, mais du coup impossible de régler mes soucis en passant par mon moteur de recherche habituel (ni par un autre d'ailleurs)
En plus, à chaque mise à jour, je passais une demi journée à refaire marcher ma config.
J'utilise maintenant une version docker, et j'en suis assez satisfait.
Pourtant je suis plutôt prompt à utiliser des versions packagées des logiciels qui m'intéressent quand elles sont disponibles, et à trouver une alternative quand elles ne le sont pas.
[^] # Re: Méthode d’installation alternative
Posté par vv222 (site web personnel) . Évalué à 3.
Ici ça a commencé à aller beaucoup mieux une fois que j’ai trouvé les commandes
gitlab-rakeetgitlab-rails-consolefournies par le paquet Debian ;)Il m’est aussi arrivé d’avoir des soucis, que j’ai donc rapportés sur l’outil de suivi des bugs pour ce paquet chez Debian : https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gitlab
Et à l’occasion je suis directement allé contribuer des patchs auprès des mainteneurs du paquet : https://salsa.debian.org/ruby-team/gitlab
Dans l’ensemble j’ai eu affaire à des personnes réactives et impliquées, je ne me suis jamais retrouvé avec un souci important qui persiste longtemps.
Je n’ai pas eu ce genre de souci, peut-être parce que j’utilise une base Debian stable qui ne fait quasiment rien tourner d’autre que GitLab ?
Les mises-à-jour des dépôts officiels Debian sont automatisés via unattended-upgrades + needrestart, et je fais manuellement les mises-à-jour de GitLab lorsqu’elles me sont signalées par la mise-à-jour de la page de wiki associée : https://wiki.debian.org/gitlab
(on peut "s’abonner" à une page du wiki Debian, pour être prévenu par e-mail à chacune de ses modifications)
[^] # Re: Méthode d’installation alternative
Posté par moi1392 . Évalué à 2.
C'est ce que je fais quand j'ai des soucis bien identifiés.
Mais pour gitlab, la pluspars du temps c'est du à mon incompétence, du coup je ne suis pas très chaud pour envoyer un rapport aux dev juste pour qu'ils me disent que j'ai raté une option quelque part.
Et ça me fait revenir à mon premier point, la façon de le configurer étant non standard : on configure directement le ruby, alors que la méthode qui me semble préconisée en ligne est de faire sa config dans la .yaml et ensuite de régénérer le ruby à partir de ça.
Je me retrouve bloqué assez vite sans solution facilement trouvable en ligne.
Ajoute à cela que ma connaissance de ruby se limite à ctrl+D pour quitter le prompt interactif (j'exagère à peine…), ça complique un peu les choses.
Effectivement je n'est pas fait mes tests sur une debian stable, du coup j'avais un mix un peu bizarre de paquets, et je pense bien que mes soucis de mise à jour venaient de cela.
Je retenterai peut-être à un moment. Mais pour l'instant, je reste sur ma config, je n'ai pas assez de temps à y investir en ce moment.
Mais merci pour les retours en tout cas.
[^] # Re: Méthode d’installation alternative
Posté par vv222 (site web personnel) . Évalué à 2.
Je comprends plus ou moins l’attrait des options à la Docker (ou Omnibus, qui est une approche très similaire), mais il est hors de question pour moi de perdre à ce point le contrôle sur les services que je fais tourner ;)
[^] # Re: Méthode d’installation alternative
Posté par moi1392 . Évalué à 2.
Qu'entends tu par perte de contrôle ? Mon ressenti personnel est plutôt l'inverse.
la version docker est plutôt bien isolé, je peux en installer 2 différentes et les tester en même temps, c'est aussi ultra pratique pour tester les nouvelles version avant de changer, je balance ma config (qui est entièrement contenue dans un volume) d'une instance à l'autre et je teste en bindant d'autres ports.
Le seul point pas cool, c'est que j'ai déjà un ssh qui tourne sur la machine , du coup pour utiliser git en ssh, je dois passer par un autre port, mais ça se fait bien.
[^] # Re: Méthode d’installation alternative
Posté par Marc Quinton . Évalué à 2.
le bundle Omnibus fonctionne parfaitement pour ce qui me concerne, sur une base Debian. Je n'ai aucun soucis concernant la production et les MAJ.
Si je devais installer une nouvelle instance maintenant, je m'orienterais certainement vers une solution Dockerisée. Je ne connaissais pas Fast Track.
# Un peu de config qui manque
Posté par fanto30 . Évalué à 2.
Je dirais les 2 mon capitaine.
Il faut forcément une résolution d'adresse sur le domaine en local.
D'ailleurs un sous-domaine sur une adresse IP je ne pense pas que ca fonctionne.
Donc un truc du genre gitlab.local que tu ajoutes dans ton /etc/hosts avec une IP locale (soit 192.168.[quelque chose] ou même tout simplement 127.0.0.1).
Et sans modifier leur port d'écoute, 2 serveurs HTTP ne peuvent pas répondrent en même temps sur le port 80 (ou 443).
Je pense que nginx ne démarre pas et que la page blanche est servie par apache.
C'est à vérifier dans les logs des 2 serveurs.
# Merci
Posté par paskalo . Évalué à 2.
Bon alors la solution de NeoX ne fonctionne pas, j'en déduis donc que fanto30 a raison nginx et apache ne sont pas partageurs. Je vais donc aller voir vers la proposition de vv222.
[^] # Re: Merci
Posté par moi1392 . Évalué à 2.
tu ne peux avoir qu'un serveur qui écoute le port 80 (ou 443)
du coup effectivement, installer apache et nginx sans prendre plus de précautions que cela mène à un des deux non disponible sur les ports standard.
avec un peu d'huile de coude, nginx peut faire reverse proxy pour des noms de domaine en particulier pour le serveur apache qui tournerait sur une autre port localement.
Mais si déjà à la base tu n'utilises pas de nom pour tes services web, ça te fait un premier souci à régler avant de t'attaquer à celui là.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.