Le serveur Web sert aléatoirement différents vhosts


9

Nous avons nginx en cours d'exécution sur Ubuntu Trusty. Il dessert plusieurs sites Web via https, fonctionnant sur une seule adresse IP.

Au hasard, bien que cela semble légèrement lié à la charge de travail, des requêtes uniques se présentent parfois sur le mauvais vhost. Cela conduit à des demandes d' lustrum.thalia.nuêtre servi par thalia.nuet vice-versa. Cela donne alors des pages d'erreur désagréables car les utilisateurs se retrouvent soudainement sur un site Web différent. Lorsque vous appuyez sur F5, les utilisateurs se retrouvent à nouveau sur la cible d'origine.

Il ne semble pas lié au navigateur ou au système d'exploitation. Il a été confirmé que cela se produisait sur Firefox (Linux, Windows, Mac), Edge (Windows) et Chrome (Linux, Windows, Android) et Safari (iOS).

Le problème semble se produire plus fréquemment lorsque le système est mis sous charge, ce qui suggère une sorte de condition de concurrence.

lustrum.thalia.nu

server {
        server_name lustrum.thalia.nu;

        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/certs/lustrum.thalia.nu.crt;
        ssl_certificate_key /etc/nginx/certs/lustrum.thalia.nu.key;

        add_header Strict-Transport-Security "max-age=63072000; preload";

        root /var/www/thalia-lustrum/public_html;

        location / {
                index index.php;
                try_files $uri $uri/ /index.php?$args;
        }

        # Add trailing slash to */wp-admin requests.
        rewrite /wp-admin$ $scheme://$host$uri/ permanent;

        # Pass all .php files onto a php-fpm/php-fcgi server.
        location ~ [^/]\.php(/|$) {
                include         /etc/nginx/fastcgi_params;

                fastcgi_split_path_info ^(.+?\.php)(/.*)$;

                if (!-f $document_root$fastcgi_script_name) {
                        return 404;
                }

                fastcgi_pass    unix:/var/run/php5-fpm-thalia-lustrum.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME  /public_html$fastcgi_script_name;
        }
}

thalia.nu

server {
        server_name thalia.nu;    
        listen 443 ssl;

        ssl on;
        ssl_certificate /etc/nginx/certs/www.thalia.nu.crt;
        ssl_certificate_key /etc/nginx/certs/www.thalia.nu.key;

        add_header Strict-Transport-Security "max-age=63072000; preload";

        root /var/www/thalia/public_html;

        location / {
                try_files $uri $uri/ /index.php/$request_uri;
                index index.php index.html index.htm;
        }

        location ~ \.php($|/) {
                include         /etc/nginx/fastcgi_params;
                set  $script     $uri;
                set  $path_info  "";
                if ($uri ~ "^(.+\.php)(/.+)") {
                                set  $script     $1;
                                set  $path_info  $2;
                }
                fastcgi_read_timeout    120;
                fastcgi_pass    unix:/var/run/php5-fpm-thalia-www.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME  /public_html$fastcgi_script_name;
        }
}

Comme vous pouvez le voir, nous exécutons différents pools PHP5-FPM pour ces deux domaines. Ces pools sont chrootés dans différents dossiers et s'exécutent en tant qu'utilisateurs différents. La configuration de PHP-FPM est par ailleurs assez standard pour autant que je sache.

Nous avons essayé nginx 1.4.6-ubuntu3 et nginx 1.8.0-1 + trusty.

Télémétrie des journaux

266.266.266.266 - - [25/Nov/2015:09:24:40 +0100] "GET /committees/175 HTTP/1.1" 302 5 "https://thalia.nu/committees" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0" Host: "thalia.nu" Location: "https://thalia.nu/index.php//committees/wp-admin/setup-config.php"

Sur cette ligne, vous pouvez voir que la demande de page est /committeessoudainement redirigée vers wp-admin. Il semble que la demande de /committeessoit traitée par le thalia-lustrumpool PHP-fpm ...

Fichier de zone DNS

Nous ne voyons pas en quoi cela peut être pertinent, mais ...

;; MX Records
thalia.nu.    300    IN    MX    20    relay.transip.nl.
thalia.nu.    300    IN    MX    10    ivo.thalia.nu.

;; TXT Records
thalia.nu.    300    IN    TXT    "v=spf1 a mx a:mulgore.hexon-is.nl a:moonray.hexon-is.nl a:fred.thalia.nu a:ivo.thalia.nu ~all"

;; SPF Records (Sender Policy Framework)
thalia.nu.    300    IN    SPF    "v=spf1 a mx a:mulgore.hexon-is.nl a:moonray.hexon-is.nl a:fred.thalia.nu a:ivo.thalia.nu ~all"

;; CNAME Records
lustrum.thalia.nu.    300    IN    CNAME    thalia.nu.

;; A Records (IPv4 addresses)
thalia.nu.    300    IN    A    131.174.31.8
www.thalia.nu.    300    IN    A    131.174.31.8
ivo.thalia.nu.    300    IN    A    131.174.31.8

1
Veuillez vérifier vos paramètres DNS pour les domaines.
Diamond

1
@bangal, il s'agit d'un enregistrement A et CNAME, pointant vers la même IP. Je ne vois pas comment cela est lié, cependant; ceux-ci se résolvent très bien, et il semble peu probable qu'un problème DNS se manifeste de manière si incohérente.
Joost

2
@ThomWiggers, pouvez-vous ajouter à votre fichier journal le contenu de l'en- Host:tête http et de l'agent utilisateur? Voir ici pour savoir comment: serverfault.com/questions/636790/… . En fait, j'ai essayé de faire des demandes à vos sites Web, mais je ne pouvais pas reproduire votre problème. Quel client utilisez-vous pour reproduire cela?
Fredi

3
Est-ce le fait que je viens de recevoir du «contenu tiers non installé» ou quelque chose parce que vous y travaillez, ou est-ce que je me suis retrouvé dans un autre pool PHP ou quelque chose (déclenchant le même bug)? J'ai également reçu une brève erreur sur config.phpintrouvable.
Halfgaar

2
@kasperd serverfault.com/questions/737349/… . Il semble n'affecter que les scripts PHP.
Thom Wiggers

Réponses:


4

Après des heures de débogage de ce problème, nous avons finalement pu le retrouver jusqu'à la cause. Il semble que la cause ne soit pas nginx, mais PHP-fpm. Nous exécutons la php5-fpmversion 5.5.9-1ubuntu4.14. Il semble que lors de la recherche de nouveaux travailleurs, quelque chose se passe parfois mal et les travailleurs exécutent (en partie?) Le code des différents travailleurs.

Notre solution était de copier /etc/php5/fpm/php5-fpm.confsur différentes copies avec leurs propres pool.ddossiers, puis de copier /etc/init.d/php5-fpmpour lancer avec le nouveau fichier de configuration (créant également des fichiers dans /etc/init/). Cela signifie que nous avons maintenant un php5-fpmgestionnaire de processus par pool. Le fait d'avoir des chroots et des sockets séparés ne semble pas séparer suffisamment les choses.


Notez qu'il n'est actuellement pas clair si c'est un problème dans notre configuration ou dans (cette version de) php5-fpm, bien que ce dernier ne semble pas probable étant donné le manque de rapports similaires. Si nous finissons par trouver la raison de ce problème, cette réponse sera mise à jour.
Joost

1

Je suis confronté au même problème mais sur Debian avec Apache2.4.25 et PHP7.1-FPM. Voici un moyen de séparer les processus https://ma.ttias.be/a-better-way-to-run-php-fpm/

Pour ceux comme moi qui pourraient trouver cette solution trop lourde pour les petits sites Web, ajoutez php_admin_value[opcache.revalidate_freq] = 0à la fin du fichier de configuration du pool php-fpm. Cependant, cela peut avoir un impact sérieux sur les performances ...

Voici le rapport de bogue officiel: https://bugs.php.net/bug.php?id=67141


0

Nginx prend-il en charge SNI? Vous pouvez exécuter nginx -V et devriez voir quelque chose comme le support TLS SNI activé. Si vous ne le faites pas, c'est peut- être la raison pour laquelle le nom d'hôte est envoyé après la poignée de main et je suppose que vous disposez d'un certificat générique pour * .thalia.nu


Bien sûr, sans SNI, cela tournerait mal 100% du temps au lieu de très occasionnellement. (et j'ai également vérifié cela, il est définitivement activé)
Thom Wiggers

FWIW, notez que nous ne servons pas de certificat générique, mais utilisons des certificats individuels pour les sous-domaines séparés. Ceci est inclus dans la configuration répertoriée dans la question.
Joost

..même si le certificat lustrum.thalia.nu est également valable pour Thalia.nu
Thom Wiggers

Pouvez-vous essayer d'ajouter le paramètre includeSubDomains comme ceci? add_header Strict-Transport-Security "max-age = 63072000; includeSubDomains; preload";
Mugurel

@ThomWiggers Si le certificat est valide pour plusieurs domaines, il est possible de prendre en charge plusieurs domaines sur une seule IP sans avoir besoin de SNI.
kasperd

-1

Il semble que le certificat ne soit pas correct: Firefox me dit qu'il est délivré pour www.thalia.nu, pas thalia.nu.

C'est à mon humble avis ce qui cause des problèmes. Essayez avec un autre certificat ou essayez d'activer les connexions HTTP sans SSL.


Nous ne pouvons pas reproduire cela. Le certificat a servi sur www.thalia.nuet thalia.nuinclut les deux domaines, avec et sans www. Quelle version de Firefox utilisez-vous et sur quelle plateforme?
Joost
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.