Je débute avec Discourse et je suis bloqué pendant l’installation. J’ai créé une machine virtuelle Ubuntu Server 18.04, puis j’ai suivi approximativement les instructions d’installation.
Quand je dis approximativement, cela signifie que, contrairement au serveur cloud, j’utilise Ubuntu Server. Je n’ai pas installé Docker moi-même, mais j’ai laissé discourse-setup le faire pour moi. De plus, je n’ai pas encore configuré de serveur de messagerie, bien que j’aie fourni des réponses raisonnables au processus de configuration. Je ne sais pas si c’est ce qui bloque tout ici. La configuration DNS est en place et le serveur dispose d’une adresse IP statique.
Après l’amorçage, lorsque je navigue vers le nom de domaine complet (FQDN) du serveur, j’obtiens la page « Bienvenue sur nginx ! » au lieu de la page « Félicitations, vous avez installé Discourse ! ».
Cette installation est destinée à un environnement de laboratoire et ne sera pas accessible publiquement.
Nginx est-il installé sur le serveur ? Il ne devrait pas l’être. Mais discourse-setup aurait dû le détecter. Êtes-vous sûr que votre configuration DNS est correcte ?
Nginx n’est pas installé sur le serveur. En ce qui concerne le DNS, j’ai un enregistrement A et un enregistrement PTR pour le serveur. Quelles sont les autres exigences ?
La seule façon de voir cette page est si vous avez dirigé le DNS vers le mauvais serveur, ou si NGINX se trouve en dehors du conteneur, occupant le port 80 et empêchant le conteneur de répondre.
Si j’ouvre directement l’adresse IP du serveur dans mon navigateur web, j’obtiens également la page de bienvenue de Nginx.
Lorsque je suis connecté en SSH au serveur Ubuntu : marc@community:~$ locate nginx /var/discourse/image/base/install-nginx marc@community:~$
De plus, depuis le serveur Ubuntu : sudo find / -iname "*nginx*"
…de nombreux fichiers sous /var/lib/docker/overlay2… /var/discourse/image/base/install-nginx /var/discourse/shared/standalone/letsencrypt/deploy/nginx.sh /var/discourse/shared/standalone/log/var-log/nginx
Si Docker écoutait sur le port 80, ce que toute installation réussie réaliserait (et qui est nécessaire pour que nginx à l’intérieur du conteneur puisse voir quoi que ce soit), vous verriez :
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
docker-pr 890 root 4u IPv6 961922 0t0 TCP *:http (LISTEN)
Si nginx n’est pas installé en dehors du conteneur et que Docker n’écoute pas sur ce port, la seule autre explication pour voir la page d’accueil de nginx est une mauvaise configuration du réseau.
Il semble que vous ayez raison. Résultat de l’exécution de nmap depuis mon ordinateur portable vers l’adresse IP du serveur :
Démarrage de Nmap 7.01 ( https://nmap.org ) le 2020-04-10 23:34 AEST
Rapport de scan Nmap pour community.aureus-group-sb.com (192.168.12.35)
L’hôte est actif (latence de 0,0010 s).
999 ports fermés non affichés
PORT ÉTAT SERVICE
22/tcp ouvert ssh
Adresse MAC : 0C:8B:FD:CD:AF:EB (Intel Corporate)
Nmap terminé : 1 adresse IP (1 hôte actif) scannée en 1,74 seconde
Rappelez-vous qu’un problème de réseau peut être, mais n’est pas limité à :
Une politique sur la machine virtuelle bloquant l’accès (ufw ou similaire)
Une politique sur le serveur virtuel bloquant l’accès (mode réseau mal configuré)
Une politique sur le réseau mal configurée (ACL entre les sous-réseaux)
Une configuration DNS incorrecte
Ce n’est un problème Discourse que si aucune des conditions ci-dessus n’est vraie. Vous suivez l’installation standard, mais selon vos propres dires, vous installez dans un environnement qui est loin d’être standard.
Si votre organisation peut dépenser 5 $ par mois, il pourrait être moins coûteux, en termes de temps, de déployer cela dans le cloud et de limiter le pare-feu du VPS cloud pour ne servir des pages que vers votre environnement.
Pour le moment, je le fais principalement pour apprendre à configurer ce système. Une fois que j’aurai maîtrisé cela, nous examinerons certainement les options d’hébergement.
En ce qui concerne les aspects réseau que vous avez énumérés :
ufw est inactif et iptables est en cours d’exécution : je n’ai apporté aucune modification à l’installation par défaut d’Ubuntu Server.
** En examinant la configuration d’iptables, la chaîne d’entrée a une politique d’acceptation de tout, tout comme la chaîne de sortie. La chaîne de transfert contient quelques références liées à Docker (voir ci-dessous).
La seule carte réseau virtuelle (vNIC) de la machine virtuelle est configurée en mode ponté, se connectant directement au réseau physique.
L’ordinateur portable sur lequel je travaille et la machine virtuelle sont sur le même sous-réseau.
Je ne suis pas certain des exigences exactes en matière de DNS. J’ai essayé de trouver ces spécifications, mais je n’ai pas réussi à trouver un document définitif. En ce qui concerne le DNS, je peux cependant faire un ping vers le serveur par son nom, son FQDN et son adresse IP. Je ne sais pas si d’autres éléments doivent être mis en place concernant le DNS.
Quelle stratégie réseau existe entre la VM et le monde extérieur ?
Si le git pull a réussi et que vous avez pu exécuter discourse-setup, est-ce que quelque chose aurait pu l’empêcher de se connecter à GitHub pour télécharger le contenu du conteneur ?
Si l’adresse du serveur n’est pas accessible, Let’s Encrypt échouerait. Avez-vous modifié le fichier YML pour désactiver HTTPS ?
La VM peut se connecter à Internet et il n’y a aucune restriction sur son accès à GitHub. Lors de l’exécution de discourse-setup, j’ai laissé l’option Adresse e-mail du compte Let’s Encrypt ? (Appuyez sur ENTRÉE pour passer) [me@example.com]: vide.
Laisser ce champ vide signifie que vous ne serez pas averti des problèmes de certificat ; cela n’empêche pas le conteneur de tenter d’activer Let’s Encrypt.
Bon, nous avons mis en évidence certains problèmes majeurs, mais ils ne concernent pas le sujet initial. Vous avez nginx quelque part sur votre réseau qui affiche une page, mais selon vos tests sur la machine virtuelle, nginx n’est pas installé et Docker n’écoute pas.
Une fois que vous aurez déterminé comment cela se produit, la deuxième étape consistera à configurer correctement le fichier YML. Pour l’instant, vous devez identifier la source de cette page.
Voici ce que j’ai appris. Si j’arrête le serveur, je ne peux pas le pinger (adresse IP, nom et FQDN). Lorsque j’essaie de me connecter à l’adresse IP via mon navigateur, j’obtiens la page standard « Impossible de se connecter » de Firefox.
Je conclus donc qu’il n’y a pas de conflit d’adresse IP.
Après avoir redémarré la machine virtuelle, je ne parviens plus à me connecter avec mon navigateur, et je reçois à nouveau la page standard « Impossible de se connecter ». Le comportement correspond désormais à ce que nous attendions de la sortie de la commande lsof -i:80.