|
|
J'ai installé ecombox avec un fichier de config qui contient notamment:
ADRESSE_IP_PRIVEE="10.0.0.6"
DOMAINE="ecombox2.mensa-formation.com"
RP_EXT="O"
CHEMIN="rne"
DOSSIER_MDP_KEY="/opt/e-combox"
DOSSIER_MDP_CHIFFRE="/opt/e-combox"
PORT_PORTAINER="8880"
PORT_RP="8800"
PORT_REGISTRY="5443"
ADRESSE_PROXY=""
NO_PROXY=""
NET_ECB="192.168.97.0/24"
DEL_IMAGES="false"
CHEMIN_CERT="/etc/letsencrypt/live/ecombox2.mensa-formation.com/fullchain.pem"
CHEMIN_KEY="/etc/letsencrypt/live/ecombox2.mensa-formation.com/privkey.pem" |
|
|
|
Quand je me connecte j'ai des timeouts de connexion lors de l'accès aux fichiers:
[Sun Oct 06 14:05:46.812593 2024] [proxy_http:error] [pid 10733:tid 10765] (70007)The timeout specified has expired: [client 10.0.0.6:40996] AH01102: error reading status line from remote server 10.0.0.6:443, referer: https://ecombox2.mensa-formation.com/rne/app/
[Sun Oct 06 14:05:46.812624 2024] [proxy:error] [pid 10733:tid 10765] [client 10.0.0.6:40996] AH00898: Error reading from remote server returned by /rne/app/main.4586f5d1ee5f2092.js, referer: https://ecombox2.mensa-formation.com/rne/app/
[Sun Oct 06 14:06:05.048421 2024] [proxy_http:error] [pid 10733:tid 10761] (70007)The timeout specified has expired: [client 10.0.0.6:41108] AH01102: error reading status line from remote server 10.0.0.6:443, referer: https://ecombox2.mensa-formation.com/rne/app/
[Sun Oct 06 14:06:05.048470 2024] [proxy:error] [pid 10733:tid 10761] [client 10.0.0.6:41108] AH00898: Error reading from remote server returned by /rne/app/favicon.ico, referer: https://ecombox2.mensa-formation.com/rne/app/ |
|
|
|
En pièce jointe vous trouverez un résultat de l'appel à la commande dockers logs nginx que Mantis n'a pas l'air d'accepter en mode textuel |
|
|
|
Auriez-vous une idée de comment débugger ou encore mieux corriger le problème? |
|
|
|
Bonsoir,
Est-ce que vous pouvez nous faire parvenir (éventuellement en note privée) la configuration de votre proxy externe ainsi que les logs de ce dernier quand vous essayez de vous connecter l'application ?
Par ailleurs, lorsqu' l'on utilise un proxy externe, ce n'est pas nécessaire de renseigner les variables CHEMIN_CERT, CHEMIN_KEY car le certificat mis en place sur le proxy est propagé aux sites mais je ne pense pas que ce soit ça qui pose problème.
Cordialement |
|
|
|
Bonsoir,
Votre problème a-t-il été résolu ?
Cordialement, |
|
|
|
Bonjour,
j'ai refait une installation from scratch et j'ai fini par réussir à configurer quasi correctement ecombox en mode reverse proxy externe en utilisant la conf nginx plutôt que Apache (j'avais pas mal d'erreurs en suivant la doc https://forge.apps.education.fr/e-combox/e-combox_scriptslinux/-/blob/4.3/README.md?ref_type=heads#12-avec-apache).
J'arrive à accéder à mon site https://ecombox-aws.mensa-formation.com/mensa/app/
J'arrive à créer un site wordpress de test, me connecter à l'interface admin.
Mais le seul problème qui me reste et que j'ai du mal à troubleshooter est que dans Wordpress, après avoir ajouté des articles, quand je clique sur le lien de l'article le navigateur me redirige vers l'hôte 127.0.0.1.
Par exemple, quand je lance le blog :
https://ecombox-aws.mensa-formation.com/mensa/blog-testalain/
le navigateur mouline et j'ai une erreur car je suis redirigé vers
https://127.0.0.1/mensa/blog-testalain/
qui évidemment ne fonctionne pas à partir du navigateur.
J'ai pensé à 2 choses possibles:
1) soit un problème avec mon /etc/hosts (je me demandais si ecombox ne résolvait pas ecombox-aws sur cette base
Mon fichier est très basique
127.0.0.1 localhost ecombox-aws ecombox-aws.mensa-formation.com
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
J'ai fait des tests en ajoutant des entrées avec l'IP publique mais ça n'a pas l'air de changer quoi que ce soit donc je ne pense pas que le problème vienne de là
2) un problème avec la configuration du reverse proxy (nginx).
J'ai suivi scrupuleusement les exemples https://forge.apps.education.fr/e-combox/e-combox_scriptslinux/-/blob/4.3/README.md?ref_type=heads#11-avec-nginx
Je l'ai revu plusieurs fois mais je ne vois pas de problème. Par contre je ne maitrise pas trop nginx donc il y a peut être quelque chose d'évident?
Je ne comprends pas ce qui pourrait différencier les filtres sur l'interface wp-admin par rapport aux sites publiés.
J'ai parcouru les sujets du forum mais je n'ai rien vu qui ressemblait à mon problème. Je joins le fichier /etc/nginx/sites-enables/default à tout hasard.
Auriez-vous une suggestion?
Merci d'avance
nginx default.txt (5,373 bytes)
atritschler@ecombox-aws:~/ecombox$ cat /etc/nginx/sites-enabled/default
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
server_name ecombox-aws.mensa-formation.com;
#listen [::]:80 default_server;
# SSL configuration
#
listen 443 ssl;
# Chemin vers les certificats (le nom des fichiers certificats est libre)
ssl_certificate /etc/letsencrypt/live/ecombox-aws.mensa-formation.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/ecombox-aws.mensa-formation.com/privkey.pem; # managed by Certbot
root /var/www/html;
index index.html index.htm;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
error_page 404 = @404;
return 404;
error_page 497 = @497;
return 497;
}
# Pour Odoo sinon les CSS ne sont pas chargés
location @404 {
add_header Vary Referer;
# À répéter pour chaque instance
if ($http_referer ~ ://[^/]*(/mensa/).*) {
proxy_pass https://127.0.0.1:8800;
}
}
# Pour Odoo avec le HTTPS sinon les CSS ne sont pas chargés
location @497 {
add_header Vary Referer;
# À répéter pour chaque instance
if ($http_referer ~ ://[^/]*(/mensa/).*) {
proxy_pass https://127.0.0.1:8800;
}
}
location /mensa/ {
proxy_pass https://127.0.0.1:8800;
proxy_redirect off;
}
# Config pour bloquer les robots (référencement)
# cf https://alanivey.com/posts/2017/robots.txt-disallow-all-with-nginx/
location = /robots.txt {
add_header Content-Type text/plain;
return 200 "User-agent: *\nDisallow: /\n";
}
add_header Strict-Transport-Security "max-age=31536000" always; # managed by Certbot
ssl_trusted_certificate /etc/letsencrypt/live/ecombox-aws.mensa-formation.com/chain.pem; # managed by Certbot
ssl_stapling on; # managed by Certbot
ssl_stapling_verify on; # managed by Certbot
}
server {
if ($host = ecombox-aws.mensa-formation.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name ecombox-aws.mensa-formation.com;
listen 80;
#listen [::]:80 default_server;
# SSL configuration
#
#listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
# Chemin vers les certificats (le nom des fichiers certificats est libre)
root /var/www/html;
index index.html index.htm;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
error_page 404 = @404;
return 404;
error_page 497 = @497;
return 497;
}
# Pour Odoo sinon les CSS ne sont pas chargés
location @404 {
add_header Vary Referer;
# À répéter pour chaque instance
if ($http_referer ~ ://[^/]*(/mensa/).*) {
proxy_pass https://127.0.0.1:8800;
}
}
# Pour Odoo avec le HTTPS sinon les CSS ne sont pas chargés
location @497 {
add_header Vary Referer;
# À répéter pour chaque instance
if ($http_referer ~ ://[^/]*(/mensa/).*) {
proxy_pass https://127.0.0.1:8800;
}
}
location /mensa/ {
proxy_pass https://127.0.0.1:8800;
proxy_redirect off;
}
}
|
|
|
|
Juste pour repréciser :
|
|
|
|
J'ai relancé l'installation en mode sans proxy externe et ça fonctionne.
Je ne comprends pas ce qui se passe et pourquoi certaines URIs sont translatées en 127.0.0.1 |
|
|
|
je veux dire pourquoi elles sont translatées en 127.0.0.1 quand je suis en mode reverse proxy externe. |
|
|
|
Bonjour, j'ai réinstallé ecombox sur un autre serveur et cette fois avec un fichier param.conf plutôt que la ligne de commande et désormais j'ai le site prestashop mais sans les images et les css. En PJ la config et la capture de mon site prestashop https://ecombox-test.mensa-formation.com/mensa/prestashop-art-testalain/fr/ |
|
|
|
Bonjour,
On avance un peu !
En me connectant à l'URL donné, je vois dans la console du navigateur (via l'outil "inspecter") : "Échec du chargement pour l’élément <script> dont la source est « https://127.0.0.1:8800/mensa/prestashop-art-testalain/themes/core.js »" ==> il y a encore une redirection vers 127.0.0.1.
Avez-vous le même comportement sur les blogs ?
Sinon, je vois dans la configuration du reverseproxy qu'il est sur le même serveur que l'e-comBox et qu'il n'est configuré que pour une instance de l'appli et pour aucune autre application. Pourquoi utiliser un reverse proxy dans ce cas là ? Ce dernier ce justifie quand on a plusieurs instances (c'est à dire plusieurs serveurs de l'e-comBox et qu'on veut utiliser le même nom de domaine).
Est-ce que vous avez essayé avec votre adresse IP privée dans le nginx et dans param.conf (il faut réinstaller l'appli si vous changer le paramètre) à la place de 127.0.0.1. Il y a peut-être quelque chose qu'on gère mal dans cette configuration que nous n'avons jamais testée (reverseproxy + ecomBox sur le même serveur avec 127.0.0.1).
Cordialement, |
|
|
|
Pour vous expliquer, la raison pour laquelle j'ai décidé d'installer un reverse proxy externe est qu'avec la version précédente (3) où ce n'était pas possible, on s'est rendus compte que notre domaine était pénalisé car les site des étudiants sont crawlés par les robots et je voulais donc pouvoir ajouter la config nginx qui va bien pour empêcher le référencement des sites étudiants.
En effet, comme ils sont souvent éteints, ça nous fait plein de remontées de 404 et ça jour sur notre score de référencement.
L'archi que j'ai mise en place ressemble à ce qu'il y a en PJ ici |
|
|
|
Pardon je me suis trompé sur le schéma mais je n'arrive pas à éditer; l'instance est dans le sous-réseau évidemment et pas l'inverse
. |
|
|
|
Oui j'ai le même problème avec les blogs wordpress - exemple https://ecombox-test.mensa-formation.com/mensa/blog-testalain/ |
|
|
|
Je n'ai pas répondu à cette question:
Est-ce que vous avez essayé avec votre adresse IP privée dans le nginx et dans param.conf
(il faut réinstaller l'appli si vous changer le paramètre) à la place de 127.0.0.1. Il y a peut-être quelque chose qu'on gère
mal dans cette configuration que nous n'avons jamais testée (reverseproxy + ecomBox sur le même serveur avec 127.0.0.1).
Il me semble que j'ai déjà essayé toutes les combinaisons possibles:
- mettre l'adresse privée (172.x.x.x) dans le nginx => je crois que ça s'est encore plus mal passé;
- mettre 127.0.0.1 dans le param.conf
Je vais ré-essayer ce soir par acquis de conscience. |
|
|
|
Bonjour, de mon côté je n'ai pas pu progresser, avez-vous une idée de comment résoudre le souci dans ma configuration?
Alain |
|
|
|
Bonsoir,
Je vais configurer un serveur ce we avec la même configuration que la vôtre (reverseproxy + ecomBox sur le même serveur avec 127.0.0.1 dans param.conf) pour essayer de reproduire le problème et pouvoir corriger.
Je vous tiens au courant.
Cordialement |
|
|
|
Bonjour, OK merci j'attends de vos nouvelles |
|
|
|
Bonsoir,
J'ai reproduit le problème avec 127.0.0.1 que je n'arrive pas à solutionner pour l"instant.
Mais j'ai réussi une combinaison qui fonctionne avec l'adresse IP privée :
- Mettre l'adresse IP privée dans param.conf et relancer le script de configuration
- Mettre l'adresse IP privée dans le nginx mais ajouter la directive proxy_set_header Host $host; (cela permet de conserver le header Host avec le domaine public). Ce qui donne par exemple :
location /test/ {
proxy_pass https://172.31.40.111:8800;
proxy_redirect off;
proxy_set_header Host $host; # Important pour conserver le host public
}
Cela a parfaitement fonctionné sur mon serveur de test. J'espère qu'il en sera autant de votre côté.
Cordialement |
|
|
|
Bonjour,
Avez-vous résolu le problème ? Pouvons-nous fermer le ticket ?
Cordialement, |
|
