Comme l’indique le titre, j’ai exécuté sudo apt install apache2.
Le serveur ne démarre pas et voici l’erreur :
(98) Adresse déjà utilisée : AH00072 : make_sock : impossible de se lier à l'adresse [::]:80
(98) Adresse déjà utilisée : AH00072 : make_sock : impossible de se lier à l'adresse 0.0.0.0:80
aucune socket d'écoute disponible, arrêt
AH00015 : Impossible d'ouvrir les journaux
L'action 'start' a échoué.
Le journal d'erreurs Apache peut contenir plus d'informations.
pam_unix(sudo:session) : session fermée pour l'utilisateur root
Le processus de contrôle a quitté, code=exited status=1
apache2.service : Échec avec le résultat 'exit-code'.
Échec du démarrage du serveur HTTP Apache.
Comment puis-je résoudre ce problème ? Merci d’avance à tous.
Donc, je devrais changer le port dans apache2.conf pour un autre ? Cela ne va-t-il pas causer de problèmes pour les futurs sites hébergés sur ce serveur web ?
Avant, il semble que vous faisiez tourner plusieurs sites web avec Apache. Apache écoutait sur les ports 80 et 443, puis « proxyait » (redirigeait) les requêtes en tant qu’« hôtes virtuels », ce qui vous permettait d’exécuter de nombreux sites web sur le même serveur, tous écoutant sur les mêmes ports (80 et 443). C’était le « LAMP 101 »… la méthode des hôtes virtuels.
Maintenant, supposons que vous installiez Discourse de la manière officielle OOTB (Out of the Box). Discourse OOTB tentera de se lier aux mêmes ports et échouera, car Apache les utilise déjà (y est lié). Vous avez le choix :
Exécuter Discourse sur un socket de domaine Unix et configurer Apache pour faire office de proxy inverse de l’application Discourse en tant qu’hôte virtuel.
Note : Je l’ai testé et cela fonctionne ; mais cette méthode n’est officiellement (ni même officieusement) prise en charge par Discourse.
Passer d’Apache à nginx et faire tourner tous vos serveurs web via nginx, en proxyant également l’application Discourse en tant qu’hôte virtuel, en utilisant un socket de domaine Unix pour l’application de production Discourse-Docker.
Note : Cette méthode n’est pas non plus officiellement prise en charge par Discourse ; et la plupart des personnes qui font tourner des sites Apache trouveront cela un peu « fastidieux » de porter tout leur code mod_rewrite Apache2 et les modules geo-ip encodés vers nginx ; mais c’est bien sûr réalisable, surtout si vos applications sont conçues pour fonctionner à la fois avec nginx et Apache2 (ce qui est plus simple, mais toujours non pris en charge officiellement).
Exposer le conteneur Docker de Discourse sur des ports autres que 80 et 443.
Note : Cela n’est (vraiment) pas recommandé non plus (mais c’est officiellement pris en charge, si ma mémoire est bonne). Cependant, la plupart des gens ne veulent pas accéder à une application web en tapant des numéros de port comme https://mon-super-app-discourse.org:3334, donc la plupart ne le font pas en production. Le développement est une autre histoire.
Ma recommandation « sans connaître tous vos détails », en tant que quelqu’un qui a beaucoup travaillé avec LAMP et de plus en plus avec Discourse, est de les exécuter sur des serveurs séparés (ce qui est officiellement pris en charge par Discourse) ; mais si vous êtes vraiment à court d’argent et devez tout faire tourner sur le même serveur (ou si vous aimez simplement avoir un gros serveur complexe), alors vous devrez apprendre à configurer Apache2 pour qu’il fasse office de proxy inverse vers un socket de domaine Unix depuis/vers l’application Discourse.
Je l’ai testé, et il est possible de configurer Apache2 pour qu’il fasse office de proxy inverse vers Discourse en utilisant un socket de domaine Unix ; mais cette solution n’est pas du tout officiellement prise en charge.
Note : Le lien pour configurer Apache2 avec HAProxy était une solution que je n’ai pas pu facilement faire fonctionner ; je l’ai donc abandonnée (pas besoin d’utiliser uniquement HAProxy, il existe des « anciennes méthodes » pour le faire). Cependant, vous feriez peut-être mieux de simplement suivre ce tutoriel Discourse :
La publication sur des ports non standard n’est absolument pas prise en charge. J’ai vu quelques sujets où, au lieu de se lier à un socket, les propriétaires de sites ont changé les ports et utilisent un proxy inverse pour mappage vers 80/443, mais si le résultat final nécessite :port, alors cela n’est pas pris en charge.